The purpose of this document is to describe the support for registry pass-through functionality that exists in Microsoft Application Virtualization (App-V) version 4.6. Registry pass-through functionality is used when applications running inside a Virtual Environment (VE) need to read/write the contents of the native registry on a client.
The problem registry pass-through functionality addresses is when an application needs to write values to the native, non-virtual registry such that those values are created on the client system and are then visible to programs that have access to the native registry (e.g. natively installed applications).
While the isolation provided by the VE is normally desired and is a cornerstone of the functionality delivered by App-V, there are cases where an application needs to have read/write access to the native system and update its state. Registry pass-through functionality provides the ability to write-through, or pass-through, registry operations from applications running inside the VE. Values that are written to pass-through locations from inside the VE can subsequently be used by other applications.
Declaring a pass-through
Pass-through keys are defined in the following location on the client system:
The VirtualRegistryPassThroughEx key should contain REG_MULTI_SZ type values identifying the registry keys on the client that should be accessed natively by an application in the VE.
All registry values read or written at these levels, or anywhere in the tree underneath, will go to the native registry on the system on which the VE is running.
Package overlaps with pass-through
In all cases, the registry values in the package take precedence over the pass-through locations. This means that locations that are defined in both locations – pass-through location and virtual registry – will create a runtime environment that ignores the pass-through location. For example, if a package has HKEY_LOCAL_MACHINE\Software\Microsoft\DirectDraw\KeyName\VRegValue=5 and a registry pass-through is defined for HKEY_LOCAL_MACHINE\Software\Microsoft\DirectDraw then VRegValue will have value 5 inside the VE regardless of its value on the target machine.
DSC packages overlap with pass-through
DSC packages (i.e. packages using Dynamic Suite Composition), either primary or secondary, will have the same behavior as with the non-DSC case for which there is overlap between pass-through and native.
For more information on DSC see How To Use Dynamic Suite Composition (http://technet.microsoft.com/en-us/library/cc843662.aspx)
Strings defined as pass-through registry keys are not modified via 32-on-64 Operating System functions such as redirection. The strings will be processed verbatim.
Existence of key on local system
In order for this functionality to operate predictably, the key that is specified in the pass-through must also exist on the local system.
For the most current version of this article please see the following:
J.C. Hornbeck | Knowledge Engineer | Management and Security Division
App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/