Dan Gough rambles on about application packaging and virtualisation

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

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:

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.

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!

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:

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:

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:

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:

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!

Post navigation

8 responses on “Creating a Shortcut to an Exe in Another Package in a Connection Group”

I have three applications one main application and two secondary applications.Main application does not have any shortcut but both secondary application have shortcuts.We have created two separate connection groups for testing the packages .In connection group 1 we have main package and 1st secondary package.In other connection group 2 we have main package and 2nd secondary package.When we are publishing each connection group on different machines both packages are working fine..but when published both connection group together on same machine shortcuts are not launching. Though main app which is a part of both connection group doesnt have any shortcut

An app cannot belong to more than one connection group. Sounds like you need to set up a single group and make the two shortcut packages non-mandatory.

If you can’t do this because the shortcut packages conflict, then you will either have to forget connection groups altogether and bundle the apps into single packages, or come up with a way to avoid the conflict (e.g. changing install dir, or using a startup script to set variables or registry).

Love the blog, you’ve helped me massively so far! I have a problem that I can’t seem to resolve… I have sequenced Java v8 u131 which works fine virtually when running java within IE using APPVVE however I cannot for life of me get .jnlp files to run virtually. I’ve tried multiple combinations of APPVVE, pointing the javaws.exe to the .jnlp path etc. Really hoping you can give me a hand here.

JNLP files launch via file association, so you have to ignore the step in the recipe which deletes these file associations. But bear in mind that will then register that version of Java to be the default handler for ALL JNLP files. If you go this route, you don’t even need to virtualise IE – treat the JNLP file like a document – you browse to it in regular IE, click it, then virtual Java steps in to open it.

Another way I’ve done before when the web page just has a simple link to one or more JNLP files is to forget about IE altogether and create a shortcut pointing to javaws.exe followed by the path of the JNLP file a a parameter.

Another thing to watch out for with JNLP files – they often try to cache dll files under AppData\LocalLow. If you have this folder in your VFS as per the recipe you may run into problems there since you cannot write to dll files in the bubble.

Check that you have deployment.properties in your package? If not, the system will read that to determine the path to the latest version of Java, which will point to the local install.

If you already have that in your package, try deleting the local copy of that file to see if it fixes the problem. If it does, and it doesn’t contain anything vital, one workaround could be a StartVirtualEnvironment script to delete the file before launching your virtual browser.

Thanks for the quick response 🙂 Our browser isn’t virtualised, we just run Internet Explorer with /appvve which works fine for java apps within the web. We have the deployment.properties within the VFS however i’m not too confident that the contents of the file is correct. What should the contents look like for this set up?

Could you explain what you mean by creating a shortcut to javaws.exe pointing to the .JNLP file please.