GLADIATOR@MSFT

Adventures in Desktop, Application, and User State Virtualization

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

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

  • Comments 18
  • Likes

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
  • Hi Steve - just posted this on a Citrix forum (http://discussions.citrix.com/topic/348733-publishing-app-v-50-app-with-appvve-switch/), in response to another Citrix/App-V user's suggestion re: the RunVirtual key:

    The RunVirtual key is only good for locally-installed apps that you want to run inside a single virtual environment all the time.

    For instance, let's say you have have a vanilla version of IE10 installed across your RDS/Citrix servers. You have some users who run just that Plain-Jane version (for instance, to access the company intranet), but also users who run it with App-V app #1 which has some ActiveX controls, App-V app #2 which has a custom JRE, and so on. I might have dozens of different browser-based apps, all of which have specific (and different) add-on requirements and all of which call the natively-installed browser. In that scenario, I don't think that the RunVirtual key helps me at all.

    Am I correct here, or have I misread the purpose and usage of the RunVirtual key?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment