App-V: On Registry Staging and how it can affect VDI Environments
UPDATE: PLEASE READ THIS AFTER READING THIS ARTICLE: http://blogs.technet.com/b/gladiatormsft/archive/2014/08/22/app-v-5-revisiting-registry-staging.aspx
The App-V 5.0 Virtual Registry is isolated for each application (or virtual environment when using Connection Groups.) With this release, there is a better view into the Virtual Registry subsystem. In fact, the App-V 5 virtual registry is divided into two main parts: The Virtual Registry itself (VREG) and the registry staging subsystem.
The APPV package file is a human-readable set of assets. As many of you may have already figured out, you can simply rename the file to a ZIP extension and browse it from within Explorer. Some of you have discovered the hard ay that you destroy the package once you try to modify it this way. Yes – it is a mechanism for VIEWING ONLY. If you have had a chance to do this, you have probably noticed that each APPV package contains its own registry hive file (.DAT)
This is where all of the registry assets captured during sequencing reside. When a package is being published, part of the overall package publishing includes the staging of the registry. Both registry machine data and user data will occur. The staging allows the virtual registry not just to be made available, but to also set up the opacity configuration and other important relationships with the native registry. This is to ensure that the applications have a consistent view of both. If you launch REGEDIT.EXE inside one of the App-V bubbles, you will see this converged registry.
If you are using a traditional App-V 5 server-based infrastructure, you might find yourself in an interesting situation. When synchronizing with a publishing server for the first time, all of the publishing blocks for all of the applications targeted to that machine or user will be passed down and each application will be published on the App-V client either to the user or globally depending on the target methodology. In addition to shortcuts, file type associations, and other extension point registrations, there will also be the staging of the virtual registry occurring in the background. This staging can produce some significant overhead during these sync and on first launch – and when many applications are being used (as well as applications with thick registries) this overhead can delay availability of those applications. This can be especially critical when using pooled VDI scenarios incorporating SCS (Shared Content Store) because you also have the additional overhead of sparse file creation.
Registry staging occurs upon the initial launching of a package if it has not been completed. It extracts the .DAT file from the APPV Package Root (which was copied from the APPV file) and then copies it again over to %PROGRAMDATA%MicrosoftAppVClientVREG. It will then mount the hive file through a background thread and recreate it in the package registry location inside the native registry. Registry staging will occur for both individual packages and connection groups. The time it takes depends on several factors including the size of the hive.
The native registry locations where these are stored are:
Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
Package Registry Staging: HKCUSoftwareClassesAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKCUSoftwareClassesAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
You will also be able to tell if the registry staging for a specific application has been completed as there will be an additional key called RegistryStagingFinished (beneath the <VERSION_GUID> entry.) Registry staging can occur in the background or on-demand. In VDI environments, we are seeing heavy CPU utilization with background staging in some circumstances. You can gain significant improvement by switching to on-demand staging. You can do this by adding the following registry value in the HKEY_LOCAL_MACHINESoftwareMicrosoftAppVSubsystem key
Data Type: DWORD
This is showing to improve first launch experiences in App-V 5 VDI environments.