Sequencing a shortcut is a commonly used method in App-V 4.x to get virtual packages to interact with something local. Especially when the local element is the parent in the relationship.
For example local Internet Explorer and virtualised Adobe Flash Player or local Microsoft Office and virtualised plugins.
The first thing to do on your sequencer is make sure the local package you want your virtual package to interface with is already installed locally. In this case I’m using Internet Explorer which has already been installed on the OS. The next step is to go ahead and sequence your application, in this case I am packaging the Flash Player plugin for IE.
When you sequence such a package on a pre-App-V 4.6 SP1 sequencer you may find you reach this part of the sequencing wizard with a very blank looking capture. This is perfectly normal as your install may not have registered any unique shortcuts or FTAs, alot of addins may not.
In this case you need to manually pull in the shortcut for the executable that the virtual application can expect to find locally on the client machine as shown:
With SP1 for App-V 4.6, we have this method built into the workflow, all we have to do select Add-on or Plugin here:
This will mean we will get a nice friendly prompt further down to actually specify what the parent program is and where the virtual application can expect to find it:
Once we have the shortcut for the locally installed application here we can chose to edit it’s name if we prefer to differentiate it from the normal Internet Explorer shortcuts that may exist on the client, more on that later.
We then need to then specify what shortcuts we want to present on the client machine. Again considering whether we want to differentiate this application or camouflage it as if it was the local application.
Now we have set the shortcut name and where it will be stored we can go through the rest of the sequencing process as usual. If we investigate the OSD of the package we have just created you will notice that although the package itself only contains Flash Player it is set to launch via the local Internet Explorer executable:
Once delivered to the client machine we will see the shortcuts as specified during sequencing:
Launching this application will load up the virtual environment that contains Flash Player and then call the local Internet Explorer executable as in the OSD. It is very important that the executable exists on the client exactly as specified in the OSD otherwise you will get the following error message:
Now we have Internet Explorer launched we should find that Flash Player is also present.
However should our end user launch Internet Explorer anyway other than our shortcut, Flash Player will not be loaded in. For example if the user had their own shortcut for IE on the taskbar or if they ran iexplore.exe from the start menu.
And that is the downfall of this technique, the user has to use your delivered shortcuts. Sure, you can try and circumvent this by disguising your shortcut as the local one and second guessing where users normally launch it from, however my experience is that users will tend to have different ways of the launching the local application. In which instance it is a case of re-educating the user base to use your delivered shortcut, this is often not ideal as it becomes an unnatural process for the user.
The same concepts apply when we talk about locally installed Office and virtualised plugins or document management systems. The same benefits and the same pitfalls.
In App-V 5.0 this story has improved somewhat with a feature called RunVirtual, whereby the logic is reversed; instead of the App-V package launching and pulling in the local process we can now monitor for the local process and pull in the virtual application. This makes more sense as it allows for the natural launch of the locally installed application and doesn’t rely on the placement of shortcuts, read more about it here.