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

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! ;)

 

 

Comments
  • 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.

  • 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.

  • 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 Office\Office14\Excel.exe</DefaultIcon>

                  <ShellCommands>

                    <DefaultCommand>open</DefaultCommand>

                    <ShellCommand>

                      <ApplicationId>Excel</ApplicationId>

                      <Name>open</Name>

                      <CommandLine>"C:\Program Files (x86)\Microsoft Office\Office14\Excel.exe"</CommandLine>

                      <DdeExec />

                    </ShellCommand>

                  </ShellCommands>

                </ProgId>

              </FileTypeAssociation>

  • Ah yes, an excellent example of using dynamic configuration to control OS extension points (FTA's)

  • Can thios feature be used to launch exes on a network share.. say client server apps

  • Yes, using the /appvve switch but you will have to specify the shortcut using an UNC path.

  • Hi,

    We use this to provide some users in our citrix environment with a specific plugin in Excel. However, when they start excel with the /appvve switch, they can't use the send mail functionality any more. Is there an explanation for this or better yet, a solution? :-)

    Kind regards,

    Rogier de Jong

  • @Roger - Is Excel virtualized as well? This may be a known issue?

  • 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 '\\Servername\sharename\exe.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02225-0x5}

  • @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.

    1. Format must be UNC \\server\share\app.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 – \\Server\TopLevel\subdir  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.

  • 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.

  • 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.

  • 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?

  • 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?

  • Well a few quick questions: 1) Assuming Office is local, will all users hitting this RDS box need these add-ins? 2) If so, are there any restrictions as to which add-ins can be used by certain users?

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