KB: Allowing applications running inside an App-V Virtual Environment (VE) to read from or write to the native registry

imageHere’s a new Knowledge Base article we published. This one explains how to allow applications running inside an App-V Virtual Environment to read from or write to the native registry on a client.



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.

More Information

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)

64-bit Considerations

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:

2750869 - Allowing applications running inside an App-V Virtual Environment (VE) to read from or write to the native registry

J.C. Hornbeck | Knowledge Engineer | Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

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/

Comments (2)

  1. While this works for the local (or real as you say it) I would advise against leveraging WMI for virtual registry access since WMI exists outside the bubble.

  2. Dark Vador says:

    You can also access Real or Virtual Registry in a same vbs using Wscript.shell and Wmi

    Read Virtual Registry

    Set objRegistry = CreateObject("Wscript.shell")

    Value = objRegistry.RegRead("HKCU" & RegKey & "" & RegValueName)

    Read Real Registry

    const HKEY_CURRENT_USER = &H80000001

    Dim StrComputer,oReg,dwValue

    strComputer = "."

    Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\.rootdefault:StdRegProv")

    dwValue = ""

    oReg.GetStringValue HKEY_CURRENT_USER,RegKey,RegValueName,dwValue

    ReadUserRRegistryKey = dwValue

Skip to main content