• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Creating a Shortcut to an Exe in Another Package in a Connection Group

Written by Dan Gough. Posted in App-V v5.x

Nyan

There are a few use cases where you might want to create a connection group that involves calling an executable from one package from a shortcut belonging to another package.

For example you could have an application with a bunch of shortcuts that call the same exe with different parameters to connect to different servers. Back in App-V 4.x, you might have employed one of the following methods:

  1. Use one package with multiple custom OSD files and deploy each one to its own AD group.
    We have UserConfig.xml files in App-V 5, but they do not offer the same level of flexibility. Each XML file can contain its own set of custom shortcuts; but the major drawback is that if a user belongs to more than one of the groups, the client does not know which UserConfig to apply so it applies none, instead using whatever the default settings are.
  2. Create a bunch of shortcut packages that DSC link to the main application.
    We could in theory do this with connection groups, but as this article demonstrates, the resulting shortcut does not work without resorting to workarounds.

In this example below, I will be using a very simple application, the terminal emulator PuTTY. I have created a sequence with putty.exe installed to C:\Program Files (x86)\PuTTY; I also have a custom shortcut that launches PuTTY with a parameter to connect to a server, which I want placed in a standalone package. The custom shortcut path is:

“C:\Program Files (x86)\PuTTY\putty.exe” telnet://nyancat.dakko.us

When this works this is what we should expect to see!

Nyancat

This shortcut was sequenced by simply selecting ‘Add-On or Plug-In’, expanding the PuTTY package, then creating the shortcut whilst monitoring. After publishing the package to the client, the shortcut has changed to show one of the following paths, depending on if it was published to the user or the machine:

%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\<PackageID>\Root\VFS\ProgramFilesX86\PuTTY\PuTTY.exe telnet://nyancat.dakko.us

%ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\<PackageID>\Root\VFS\ProgramFilesX86\PuTTY\PuTTY.exe telnet://nyancat.dakko.us

The PackageID is from the shortcut package, which does not contain the exe, so the shortcuts are now pointing to a non-existent file. Putting both packages in a Connection Group does not update the shortcut either. When you launch it you will see the error below:

Missing Shortcut

So how can we get this to work in a Connection Group? To stop the App-V client from changing the path, we need to point the shortcut to an exe that already exists at publish time. There are two working solutions that I know of:

1. Recreate the App-V client paths on the sequencer and point the shortcut there instead.

There are three potential paths we could select, each with a unique drawback:

  • %LOCALAPPDATA%\Microsoft\AppV\Client\Integration\<PackageID>
    This path is only valid if the app is published to the user.
  • %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\<PackageID>
    This path is only valid if the app is published globally.
  • %PROGRAMDATA%\App-V\<PackageID>\<VersionID>
    This path works for either publishing method, but the path is now dependent on the VersionID, so it’s more likely to change in future. Unless you are 100% sure that the app is only to be published either per-user or per-machine, this is the way to go.

To create the package, before you start sequencing, recreate the exact same path that you see on the client, on the sequencer. Then whilst monitoring, create the shortcut pointing to this path, e.g:

C:\ProgramData\App-V\<PackageID>\<VersionID>\Root\VFS\ProgramFilesX86\PuTTY\putty.exe telnet://nyancat.dakko.us

This method has some advantages and disadvantages:

  • If your shortcut package is a pure shortcut with no other files or registry entries required (as in this example), you don’t even need a Connection Group! The shortcut will launch PuTTY in its own virtual environment and with the necessary parameter to connect to the server.
  • The package containing the target exe must be published before the shortcut package, otherwise the shortcut will be created with a blank target path. If they are published in the wrong order, this can be remedied by repairing the shortcut package.
  • The shortcut package is dependent on the PackageID and perhaps the VersionID of the target package. If you had a lot of shortcuts, that’s a lot of work to update them if the target package is resequenced with a new version.

2. Use CMD.exe or a script to launch the application directly from Program Files

If you point your shortcut to some other middleman, such as cmd.exe, once it is up and running in the virtual environment it can see the original install path within the virtual file system. You could use a script to do this, but the simplest method is to just call cmd.exe directly like this:

C:\Windows\System32\cmd.exe /c START “” “C:\Program Files (x86)\PuTTY\putty.exe” telnet://nyancat.dakko.us

The double quotes are necessary after the START command to supply a blank window title if there are spaces in the paths that follow, this is just a peculiarity of cmd.exe. You should also change the icon of the shortcut to match the original exe, and you may also have to set the working directory to the application folder if the application requires it.

Crafting the shortcut in this way means it always needs to be put in a connection group. But there are no dependencies on the package GUIDs or installation order, making this the recommended method!

 

Powershell Scripts For Testing App-V Packages

Written by Dan Gough. Posted in App-V v5.x

I thought I’d share these as some of you may find them useful! When I am testing App-V packages, I generally either have them on a network share in one folder, or have copied them to my desktop, and want a simple way to add and remove them. These Powershell scripts do just this:

  • Add-AppvPackages.ps1 – Searches recursively for all .appv files under the same folder as the script, adds them (without config files), and publishes them globally.
  • Remove-AppvPackages.ps1 – Looks for all published App-V packages, and Stops/Repairs/Unpublishes/Removes any that have the path of the .appv file matching a package found under the same folder as the script.

Both scripts do these jobs in one line of code, even though that makes them harder to read! But then there are a few lines to relaunch the script with admin rights, which ruins my single-line elegance, but makes it much easier to use. For example, copy these scripts and a bunch of packages to your desktop, right-click the script and select Run with Powershell, and it will automatically prompt for elevation if you have UAC turned on (which you should).

Download them here.

 

Automate Your App-V Client / Sequencer Test Builds With Boxstarter!

Written by Dan Gough. Posted in App-V v5.x

Boxstarter

I recently decided to rebuild my App-V lab from scratch. I also work on various client sites and often have to whip up an App-V sequencer and test client from scratch, and in the past this has always been a manual process. So this time I decided to automate it!

There’s a lot of buzz around automation frameworks at the moment – you may have heard of Chocolatey, Boxstarter, Chef, Vagrant, PuppetDSC, etc. I started writing my own script in PowerShell before realising that one of the features I wanted to implement – applying Windows Updates and rebooting with autologon until the process had completed – was already implemented in Boxstarter. Boxstarter is written in Powershell so a lot of my existing code could be ported over too, with some of it replaced with Boxstarter’s own built-in functions.

This script will be constantly evolving but here is what it does at the moment:

  • Prompt the user to ask if the machine is a client or sequencer if it cannot find out from looking at HKLM\SOFTWARE\Microsoft\AppV
  • Installs pre-reqs for App-V via Chocolatey:
    • .Net 3.5 & 4.5.2
    • Powershell 4.0
  • Enables Microsoft Update
  • Applies all Windows Updates except those that need the user to accept a license (e.g. language packs, Skype, Silverlight)
  • Disable automatic updates
  • Sets execution policy to Unrestricted
  • Disables Security Centre and hides task tray icon
  • Disable System Restore and deletes any existing restore points
  • Optimises the OS for running on an SSD
  • Disables computer password change (to prevent falling off the domain when reverting)
  • Configures power options to disable screen off and standby timers
  • Enables remote desktop
  • Sets Explorer options to show file extensions and hidden files
  • Sets Windows 8 to boot to desktop, show all apps view by default, etc
  • Pins Command Prompt, Powershell, Regedit, Notepad, and Snipping Tool to the taskbar
  • Disables Internet Explorer Enhanced Security Configuration (for server OS)
  • Disables IE first run prompts and sets home page to blank
  • For a Client build:
    • Install App-V Manage, ACE, InstEd, 7-Zip and Sysinternals Suite via Chocolately
    • Pin App-V Manage and ACE to the task bar
  • For a Sequencer build:
    • Disable UAC
    • Disable Windows Defender
    • Disable Windows Search
    • Disable over a dozen scheduled tasks
    • Create empty ODBC Data Sources registry keys
  • Run ngen.exe to optimise .NET assemblies
  • Perform disk cleanup via cleanmgr.exe
  • Wipe %TEMP% and C:\Windows\Temp
  • Run sdelete.exe to zero unused bytes on disk (allows the VHD to be compacted more efficiently when complete)

Note that this does not actually install any App-V components, since these are not available via any public download locations and I am not authorised to distribute them. But who knows, with Microsoft’s adoption of OneGet in Powershell v5, we may be able to install those components that way in the future! Anyhow, it’s a good idea to take a snapshot of the clean base configuration before any App-V components are installed, plus not all environments will be running the latest version.

There are a few known issues at present:

  • Sometimes checking for Windows Updates can return an error on the first attempt – hence running the command twice in a try / catch block as a workaround.
  • Disabling Defender on Windows 8 is difficult as the service is locked down, so for now it drives the GUI… which does highlight a flaw in Windows that you can disable the built in antivirus without admin rights! The timings of this may need fine tuning as I have seen it stall once or twice. Perhaps I will just figure out how to do it properly instead.
  • UAC still seems to be left enabled when configuring a sequencer build on Windows 7, yet it works on Windows 8.

The great thing about this is that it can be run from a simple URL – which I have plugged into an easily memorable URL shortener. So to run this script on a machine, all you have to do is hit Win + R to get the run box and enter:

http://tiny.cc/appvboxstarter

Easy, eh?

Of course you may want to customise this for your own needs – just download the script as a text file and head over to Boxstarter.org to learn how to run your own version from your own URL. You can even run it from a network share or USB key if internet access is an issue on the test VMs.

Please comment below if you find any issues or have any other suggestions. I hope you find this useful and it saves you some time, or if not perhaps it will expose you to some cool tools that you might not have heard of before. I used Chocolatey for example to reinstall a bunch of tools on one of my machines after reinstalling the OS!