App-V 5.0: Launching Native/Local Processes Within the Virtual Environment


Update 12/6/2014: With the release of App-V 5.0 SP3, there is an additional option now available. You can now use the RunVirtual registry for user-targeted applications. You might prefer this to the /appvve switch. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

Back in 4.x, we pretty much had one of two ways to launch an application inside the virtual environment or “bubble” as it is often called. One way was through the use of a pre-launch script. This was cumbersome in that you had to either modify the cached OSD or even worse, modify the original OSD file and re-deploy/refresh. Since I always used this for troubleshooting purposes, I found it easier to modify the cached copy of the OSD file. Starting in version 4.5, we also had a way of launching an alternative native executable inside the virtual environment by simply adding parameters to the SFTTRAY.EXE command:

C:\Program Files (x86)\Microsoft Application Virtualization Client\sfttray.exe" /exe cmd.exe /launch "DefaultApp MFC Application 1.0.0.1

App-V 5 offers us even more flexibility in this regard. To start off, do not use the scripting elements in the dynamic configuration XML. It is completely unnecessary and a waste of time. APP-V 5 offers many ways of getting inside "the bubble."

Powershell

You can use the Start-AppVVirtualProcess cmdlet such as the following example to retrieve the package name and start a local process within the specified package's virtual environment:

$AppVName = Get-AppvClientPackage *name*

Start-AppvVirtualProcess -AppvClientObject $AppVName cmd.exe

This way allows you to do something similar to the previous variant of SFTTRAY in which you can initialize an App-V virtual environment substituting a local command as the process running within that virtual process.

 

The Command Line Hook Switch “/appvpid”

This allows you to apply the /appvpid switch to any command which will allow the command to run within the virtual process of the virtual process you selected by its PID (Process ID) as in the example below:

cmd.exe /appvpid:8108

The Command Line Hook Switch “/appvve”

Where the /appvpid switch requires the virtual process to already be running, this switch allows you to start a local command and allow it to run within the virtual environment of an App-V package and will initialize it. The syntax is as follows:

cmd.exe /appvve:<PACKAGEGUID_VERSION_GUID>

The syntax is a but cumbersome as it requires both the package GUID and the version GUID:

cmd.exe /appvve:bcfdbe1b-8bff-4502-b4e2-5a773e82d86c_2ef3aaf9-9864-44a3-85dd-bf99a6b4d8f2

Run Virtual

If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual

For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID> or such as in the figure below:


 
Each native process that needs to run locally will require its own subkey beneath the Run Virtual key. As long as there is one version of the EXE on the system, placing the package\version GUID combination in the default key value will suffice. If there is more than one version of the EXE installed on the machine, you will need to create a new REG_SZ value beneath the subkey and specify the value name by using the full path to the EXE.

Flexibility

The above options give you much flexibility in how you merge native processes with virtual environments. With App-V 5, these not only add interoperability options, but they enhance our troubleshooting toolkits.  There will not be any reason to go into dynamic configuration XML in order to do this.

PS: Yes, I know I have not been blogging enough on APP-V 5. I promise to change that. I do have customers to tend to, you know! 😉

Update 12/6/2014: With the release of App-V 5.0 SP3, there is an additional option now available. You can now use the RunVirtual registry for user-targeted applications. You might prefer this to the /appvve switch. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

 

Comments (24)

  1. How about creating an empty package with the local office applications as shortcuts and virtual applications – then joining them into the connection group? You could also just sequence the application on a machine that has Office installed using the Add-in
    workflow. Then ensure that the local Excel is added as a virtual application in the package.

  2. Suraj Malusare says:

    I have 2 or more than that excel add-in package ( without shortcuts ) which I have virtualized and I want after launching of Excel shortcut on client both packages add-in should display then how I can achieve that ? Note that Office is not virtualized
    here. Also I don’t want both excel should be part of single connection group.

    I tried with Run virtual subkey but it accepts only one default key resulting into only one add-in display.
    Can someone please help me ? It would be really appreciated.

  3. Anonymous says:

    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

  4. Anonymous says:

    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

Skip to main content