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: https://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: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key
Comments
Anonymous
January 01, 2003
Ah yes, an excellent example of using dynamic configuration to control OS extension points (FTA's)Anonymous
January 01, 2003
Thanks, I think it would be a nice addition to the methods of starting local applications within virtual environments. Right now I have found an alternative solution for my 'problem'. You can use dynamic configuration XML files to overwrite local file type associations. By using userconfig.xml within an App-V 5 package to assign a file type association to a local installed application, you can assign file type associations to local installed applications. AppV will start the specified local application within the Virtual Environment of the App-V package. The following UserConfig.Xml section assigns the .XLSX file type to Excel, but starts it within the virtual environment of the App-V package that it belongs to. <Extension Category="AppV.FileTypeAssociation"> <FileTypeAssociation> <FileExtension> <Name>.xlsx</Name> <ProgId>ExcelLocal</ProgId> <ShellNew /> </FileExtension> <ProgId> <Name>ExcelLocal</Name> <Description>Excel 2010</Description> <DefaultIcon>C:Program Files (x86)Microsoft OfficeOffice14Excel.exe</DefaultIcon> <ShellCommands> <DefaultCommand>open</DefaultCommand> <ShellCommand> <ApplicationId>Excel</ApplicationId> <Name>open</Name> <CommandLine>"C:Program Files (x86)Microsoft OfficeOffice14Excel.exe"</CommandLine> <DdeExec /> </ShellCommand> </ShellCommands> </ProgId> </FileTypeAssociation>Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Thanks for the feedback. As RunVirtual is new and designed for machine-targeted RDS/Citrix farms that adds flexibility, we are always looking for ideas for improving and expanding these new features. I will be sure to forward this along from the field.Anonymous
July 05, 2013
Interesting article, I was aware of the first three options to start a native application within a virtual environment, the 'RunVirtual' option is very interesting. However it is unfortunate that it is only possible to use these keys in HKLM and not in HKCU. We have several business units on the same XenApp farm and they all use different Office add-ins. If it were possible to add RunVirtual in HKCU, it would be possible to start Office applications within a different virtual environment without too much of a hassle, now I have to use custom PowerShell scripts for each business unit.Anonymous
October 11, 2013
Can thios feature be used to launch exes on a network share.. say client server appsAnonymous
October 22, 2013
Yes, using the /appvve switch but you will have to specify the shortcut using an UNC path.Anonymous
December 03, 2013
The comment has been removedAnonymous
December 03, 2013
The comment has been removedAnonymous
December 06, 2013
Steve, I noticed your post on Oct 22 that you could use EXE /appve:PKGGUID_PKGVGUID to launch a process off a network share but you have to use UNC. Doesn't work for me, generates a 18005 error in the Virtual Applications APP-V log. Have you confirmed this works? BTW, tried it on SP1, SP2 Beta, and SP2 clients, all failed with the error listed below. I am assuming it has something to do with the APP-V client process running under the SYSTEM context and not being able to gain access to the share. I confirmed this by granting the client machine's computer AD object read access to the share, once I do that it works. The virtual application '\Servernamesharenameexe.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02225-0x5}Anonymous
December 06, 2013
@Angel_PRU - The share will still be accessed by the AppvClient process under the SYSTEM context and not impersonating the user account. I should probably point that out more specifically.
- Format must be UNC \servershareapp.exe /appvve:<PACKAGEGUID_VERSION_GUID> 2.The Top Level Share and NTFS directory – has to have the Computer system account set to at least read – \ServerTopLevelsubdir you need to set permission on the top-level not just on sub-directory on the NTFS permission side of things. Again this is due to the non-impersonation.
Anonymous
December 06, 2013
Steve, I appreciate the clarification. But that requirement would prevent, IMO, most mid/large size companies from using a feature they had available to them in 4.x. Our security team would not approve granting a computer object (especially with free seating) access to business owned shares. And in a pooled VDI environment, this approach would be unmanageable. Thank you for your help.Anonymous
December 08, 2013
I understand your concern and we've received much feedback on all of the variants of what I refer to as "the impersonation issue." I will keep you all posted if there is any changes or developments.Anonymous
December 28, 2013
Pingback from How to Prepare for a Migration to App-V 5.0 - Dynamics AX Sustained Engineering - Microsoft Dynamics AX - Microsoft Dynamics CommunityAnonymous
December 29, 2013
This is the first post in a series of posts around migration of App-V from 4.x to 5.0. Introduction SinceAnonymous
January 21, 2014
Thank you very much!But i don't clear knowledge in Run Virtual section. please help to make it clear more.in case, i have 2 off add-in. what must i do?Anonymous
January 21, 2014
Thank you very much!But i don't clear knowledge in Run Virtual section. please help to make it clear more.in case, i have 2 off add-in. what must i do?Anonymous
April 07, 2014
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?Anonymous
April 26, 2015
Throughout the past 15 years, from its origins in Softricity, one of App-V’s primary use casesAnonymous
April 26, 2015
Throughout the past 15 years, from its origins in Softricity, one of App-V’s primary use casesAnonymous
June 30, 2015
~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d likeAnonymous
June 30, 2015
~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d likeAnonymous
April 05, 2016
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.Anonymous
April 19, 2016
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.