If you think that title is a handful, it simply a summary of most of the ways we allow local processes to interact with virtual environments in App-V 5. Whether or not you need to use these features will depend on factors such as targeting or if you want to take advantage of features introduced in App-V 5 SP2. Last year, I gave a primer in a blog on how to run a native process inside an App-V 5 package’s virtual environment. Well, recent question regarding internals as well as product developments have warranted a further discussion on the functionality of “running virtual: in App-V 5.
Run Virtual (RDS Run Virtual)
Designed really for RDS, I prefer to call this RDS Run Virtual as it was designed for RDS\XenApp\Terminal Servers. Why do I say that? Often application servers will be siloes for specific applications therefore they will likely be published globally. Through a simple registry key, you can have a local process interact with a specific virtual environment. As I mentioned in that blog from last year. 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>)
If the package is also in a connection group, the native process will be launched into the virtual environment (connection group) where that package belongs. NOTE: The connection group obviously has to be published globally as well. If the GUID pair is invalid or not found, the application will launch natively.
Run Virtual on Demand (using switches /appvve)
I have received feedback on the fact that only global publishing is supported with the RunVirtual registry key. If the application is user targeted and you want a “Run Virtual” equivalent for a native process, you can use the /appvve switch. This is a nice option because it allows an application be brought into the virtual environment regardless of publishing target type. Unlike the RunVirtual key in the registry, you will have to manage this on a per-application basis. Thanks to the VirtualizableExtensions option in the registry, if you simply call the native process through a shortcut extension in the package’s dynamic deployment configuration file, it will run virtual automatically.
Virtualizable Extensions
Speaking of Virtualizable Extensions: This is a special registry value which determines which application extensions will be treated with “Run Virtual” if configured as an application extension point within an App-V application. The extensions are registered under the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Integration
The value is VirtualizableExtensions and it consist of a REG_SZ data type where all of the supported extensions are listed separated by commas. For example, when you sequence an application like the IBM DB2 client, you may notice that some of the shortcuts are .BAT and .CMD files. In order for those applications to be treated as App-V applications that register properly as extension points, those extensions need to be registered under VirtualizableExtensions. The defaults are: exe, com, bat, cmd, vbs, ps1, cpl, jar, wsf, and wsh. You could add a .TXT extension, but given that a TXT file is not executable by FTA design in Windows, it would be pointless as the most it would do is open up Notepad in the bubble with this extension. But let's say your script interpreter of choice was something like Visual Cobol and you wanted to process a script using a .CBL file. You would have to add in this extension. If a Visual Cobol is locally installed when a CBL script is called through an extension point, it will run it virtually.
Dynamic Virtualization
This was introduced in App-V 5 SP2 in order to give us shell extension support and native interaction with virtualized ActiveX controls. The registry value that toggles this on or off is EnableDynamicVirtualization and it is located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization
In addition, those processes that are specified for this feature are listed in the ProcessesUsingVirtualComponents registry value located in the same key. By default, Explorer.exe and Internet Explorer are listed there. You can see this in action by using a tool from SysInternals called LISTDLLS.EXE. For example, let’s say I’m on a client configured with the virtualization defaults for App-V 5 SP2 and I currently have one program launched: Notepad++ (yes, I admit it – I use it.)
When I run Get-AppVClientPackage from PowerShell, it shows I only have one application in use:
However, when I run the LISTDLLS.EXE command to find out which processes have the AppVEntSubsystems32.dll injected (or AppVEntSubsystems64.dll for 64-bit processes) you will see both notepad++ and Explorer have been hooked.
And if I were to launch Internet Explorer, I would see the same thing. Do not confuse this interaction with RunVirtual. Dynamic Virtualization has a limited scope of interaction designed for features introduced in App-V Service Pack 2.