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:
Machine:
Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
User:
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
Value: NoBackgroundRegistryStaging
Data Type: DWORD
Data: 1
This is showing to improve first launch experiences in App-V 5 VDI environments.
madvirtualizer
The Mad Virtualizer at Microsoft 
@Carlitog – I do recommend the Full Infrastructure for both publishing and reporting reasons.
Please note that I am still curious as to your situation. We would like to nail down any other potential causes of these CPU spikes hence my questions.
Thanks for the post, this explains a few things for us hopefully… Keep this kind of thing up!
Your mileage may vary and there could even be other factors at play. This only addresses delays and spikes from background registry staging. Others have seen some benefit from this. Is the 30 seconds the time it takes for initial refresh and application availability? How many applications? Are you using Shared Content Store?
Hi there Steve, good article! So this could also speed up publishing (FB0) performance for big registry apps that are NOT "Optimized for streaming"? I've seen optimized packages with a 9Mb registry.dat taking 14-15 secs to be published, and during this time taking a 100% CPU time. My thought is that by not optimizing this package, I can take advantage of this registry ondemand setting during execution time. Can you confirm this?
Thank you for this post! I'll learn more by this theme. I found info on http://dynaboot.com/
We have tested this reg value and it does not seem to make any difference. We see a 25% CPU spike when logging in with a new profile across 4 vCPUs for about 30 seconds or longer sometimes.
You certainly could, although let me ask, are you seeing this when publishing?
This behaviour is seen during synchronizing the client with the publishing server. So yes 🙂
So two things come to mind generally that slow down client-side publishing sync (outside of network latency, server overload, and other external forces)
Large amounts of data processing (Heavy registries can attribute to this) and delays in processing the actual sync vbs script. The script is signed so ensure the issue is not tied to that verification (CRL checking.)
I advise my VDI customers, especially non-persistent VDI users of App-V to survey registry sizes and publishing blocks (especially those with a lot of extension points) and to understand how they handle Authenticode and signing within their environment: technet.microsoft.com/…/cc960600.aspx
Hi Steve, for non-persistent VDI do you recommend using App-V in the full infrastructure mode or sccm 2012 integrated. We use App-V integrated with SCCM 2012 SP1 and it is slow to enumerate user targeted app-v packages at logon. As we use floating pools it is slow at every logon to display the application shortcuts etc. Do you have any recommendations around this or are there improvements coming to make this a much faster experience?
Pingback from App-V 5 and Citrix | The knack
Pingback from App-V 5 and Citrix | The knack
Pingback from App-V 5 and Citrix | The knack
Last year, I wrote a blog post on registry staging in App-V and how it can affect initial publishing