Partager via

App-V: On Registry Staging and how it can affect VDI Environments

  • Article

UPDATE: PLEASE READ THIS AFTER READING THIS ARTICLE: https://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%Microsoft\AppV\Client\VREG. 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: HKLM\Software\Microsoft\AppV\Client\Packages\<PACKAGE_GUID>\Versions\<VERSION_GUID>

Connection Group Registry Staging: HKLM\Software\Microsoft\AppV\Client\PackageGroups\<CG_GUID>\Versions\<VERSION_GUID>

 

User:

Package Registry Staging: HKCU\Software\Classes\AppV\Client\Packages\<PACKAGE_GUID>\Versions\<VERSION_GUID>

Connection Group Registry Staging: HKCU\Software\Classes\AppV\Client\PackageGroups\<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_MACHINE\Software\Microsoft\AppV\Subsystem key

 

Value: NoBackgroundRegistryStaging

Data Type: DWORD

Data: 1

This is showing to improve first launch experiences in App-V 5 VDI environments.

Comments

  • Anonymous
    January 01, 2003
    @Carlitog - I do recommend the Full Infrastructure for both publishing and reporting reasons.

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    Thanks for the post, this explains a few things for us hopefully... Keep this kind of thing up!

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    September 25, 2013
    Thank you for this post! I'll learn more by this theme. I found info on http://dynaboot.com/

  • Anonymous
    October 01, 2013
    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.

  • Anonymous
    October 22, 2013
    You certainly could, although let me ask, are you seeing this when publishing?

  • Anonymous
    October 23, 2013
    This behaviour is seen during synchronizing the client with the publishing server. So yes :)

  • Anonymous
    October 25, 2013
    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

  • Anonymous
    December 09, 2013
    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?

  • Anonymous
    December 15, 2013
    Pingback from App-V 5 and Citrix | The knack

  • Anonymous
    December 15, 2013
    Pingback from App-V 5 and Citrix | The knack

  • Anonymous
    December 15, 2013
    Pingback from App-V 5 and Citrix | The knack

  • Anonymous
    August 21, 2014
    Last year, I wrote a blog post on registry staging in App-V and how it can affect initial publishing