December 29, 2012

App-V 5.0 delivers Internet Explorer Plugin Nirvana

One of the great promises of application virtualization is dynamic delivery of software to end-points; however delivering plugins or add-ons to installed (i.e. not virtualized) software has thus far been a stumbling block.

Internet Explorer has been particularly challenging due to the inability to separate the browser from the OS in a supported manner. So using App-V to deploy plugins like Flash or Java has meant changing the user experience with virtualization or falling back to standard install methods.

App-V 5.0 delivers some good news though, with the ability to seamlessly run an installed application inside a specified virtual environment. This means that the Flash plugin can be delivered as a virtual package and made available to Internet Explorer without resorting to hacks or changing the user experience by providing a special shortcut. Providing Office add-ins would also benefit from the same approach.

Sebastian Gernert recently posted about the new RunVirtual feature in App-V 5.0 that can be used to launch a specified process or processes within a specific App-V package. RunVirtual is simple to implement but does require packages to be global.

RunVirtual works by the App-V client intercepting the process launch (CreateProcess) with AppvVemgr.sys and loading the process into the specified virtual environment.

Implementing RunVirtual

To illustrate implementing the RunVirtual feature, I’ll demonstrate delivering plugins to a Windows 7 client running Internet Explorer 9. In this example, I’m managing the App-V client with PowerShell to show what’s going on under the hood. This process would be simplified with Configuration Manager or the native App-V infrastructure.

Publishing Packages

Before deployment to a client PC, I’ve sequenced the follow applications into App-V 5.0 packages and saved them to the network:

  • Adobe Reader X
  • Adobe Flash Player 11
  • Oracle Java 7

During sequencing I’ve not performed any special steps to prepare the environment – there is no bearing on deployment during the sequencing stage.

Each package has been added to the client and published globally with the following commands:

Add-AppvClientPackage –Path \\server\Packages\AdobeReaderX_pkg\AdobeReaderX.appv | Publish-AppvClientPackage -Global<br>Add-AppvClientPackage –Path \\server\Packages\AdobeFlashPlayer11\AdobeFlashPlayer11.appv | Publish-AppvClientPackage -Global<br>Add-AppvClientPackage –Path \\server\Packages\OracleJava7\OracleJava7.appv | Publish-AppvClientPackage -Global

Whilst Adobe Reader can be used just like any other application, Flash and Java aren’t particularly useful on their own.

Enabling a Connection Group

Only a single package can be applied to a process with the RunVirtual feature. This means that to provide Internet Explorer with access to several packages, we need to first add each package to a Connection Group and add that to the client.

Connection Groups are defined via XML files that list each member package. If we’re managing the App-V client with PowerShell, the Connection Group descriptor files need to be created manually. I won’t go into detail here; however below is the listing for the descriptor file for a Connection Group that contains the Internet Explorer Plugins:

<?xml version="1.0" ?>
DisplayName="Internet Explorer Plugins">
<appv:Package DisplayName="Adobe Flash Player 11" PackageId="6a22f839-2d22-46dc-9c63-2649e370fce2" VersionId="792c8000-509c-4b1a-b4d7-58be65436d1a" />
<appv:Package DisplayName="Adobe Reader X" PackageId="abf1cd38-03cf-42af-8b27-564c4b9fcd1e" VersionId="818bc4eb-50f2-4fd4-90e4-9c8ed097e1e9" />
<appv:Package DisplayName="Oracle Java 7" PackageId="7112a4ca-2fe9-4606-b673-e13ea8589294" VersionId="4887ecd0-ce7b-48f6-bad6-4d8197e3821e" />

Save the file as InternetExplorerPlugins.xml and copy to the client PC. The Connection Group is added and enabled (most importantly, globally), with the following command:

Add-AppvClientConnectionGroup -Path .\InternetExplorerPlugins.xml | Enable-AppvClientConnectionGroup -Global

PackageId/GroupId and VersionId from the Connection Group descriptor file are important to note when configuring RunVirtual.

Configure RunVirtual

Enabling the RunVirtual feature for a process is achieved via a Registry key in HKLM: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual. Each target process requires a key below the RunVirtual key and then the package ID and version ID listed in the default value.

So using Internet Explorer (iexplore.exe) and the Connection Group for the plugins, listed above, the data to add to the Registry would look like this:

  • Key: HKLM\SOFTWARE\Microsoft\AppV\Client\RunVirtual\iexplore.exe
  • Default Value: 61be9b14-d2b4-41ce-a6e3-a1b658de7000_e6b6aa57-f2a7-49c9-adf8-f2b5b3c8a42f

(Note the underscore between Package ID and Version ID to make up the data stored in the registry value.)

However – I have found that RunVirtual doesn’t start the virtual environment (VE) if details for a Connection Group are supplied. Documentation on this feature is scant, so it’s hard to tell whether this behaviour is by design or not.

If the Package and Version ID are of a member package are provided, then the Connection Group VE is loaded, so we do get the desired effect. In my test case, I’ve added the Package and Version ID of the primary package (Flash) to the registry.


Once the key is created and populated, start or restart the target process and the plugins will be available. Internet Explorer add-ons can now be virtualized and delivered to IE seamlessly. Even Adobe Reader can now be virtualized and embedded PDFs will still work.

The End to installing Plugins?

RunVirtual is a great new feature of App-V 5.0 that has only been possible with the re-architecture of App-V. The ability to provide add-ons or plugins for installed software without changing the user experience is brilliant. A feature that agent-less application virtalization solutions won’t be able to match.

However it’s still early days for App-V 5.0, so it remains to be seen how widely this feature will be used. At this point, it only works with global (i.e. not user targeted) packages and requires a change to the real registry. It is though, a feature with a lot of promise and I’m looking forward to it simplifying desktop images.

Print Friendly
  • Roel Beijnes

    Aaron, I do like this feature. I have tested this feature in the past with a plugin for Internet Explorer. The plugin works fine, but my Metro interface wouldn’t start up. The funny thing is… if my Metro IE was running, i didn’t have any problems opening pages.

    Starting a new Metro Interface, he isn’t able to start up and the IE logo stays. Maybe the Metro interface isn’t able to coop with App-V?

    • I’m aware of the issue and am chasing an answer.

  • Danny Clarke

    Definitely a big improvement over 4.x, but unless all users have same add-ins will need some further development to be ‘nirvana’! ; )

  • I’ve yet to try this but I have a question and wonder if you may already know the answer! What would happen if you set this up as above and then had another package which tried to open IE to read local HTML help files in its own bubble? Would IE open up in the ‘plugin bubble’ and come up with file not found?

    • I would be that IE would be restricted to one bubble, i.e. the CG bubble.

  • It was possible to launch a local application from within the Virtual bubble in Softgrid, Granted that it took some editing of the OSD files but it could be done.
    Is that right that you need to set the RunVirtual with a package ID in HKLM? Really?

    There was (and I bet still is) the issue of users having to launch the local application in the right way to get the plugin active. Also due to the isolation of bubbles you would only be able to have one plugin at a time in any given application unless you cross connect all the possible plugin packages.

    Folks, there are other Virtualization solutions out there that don’t have this issue. The apps look and run like they are native…

    • Hi Kris, RunVirtual is transparent to the user and can launch multiple plugins that are part of a connection group.

      • GrGR

        Hello Aaron, but you’re basically stating that only 1 plug-in can be linked at this time and connection groups do not work.

        Not much of an improvement in terms of functionality, but does looks more seamless for users, at least for 1 plug-in. 😉

        • RunVirtual doesn’t work if the GUID for a Connection Group is specified however if the GUID of a package is used and that package is part of a Connection Group (with other plugins) then all plugins in that Connection Group will be available to IE.

  • jc

    Will something like this work for multiple versions of the same plugin? For example, Java?

    • If those versions of the plugin can coexist in the same virtual environment then yes, otherwise no.