A few weeks ago, one of our customers experienced the problem that some App-V applications were not started until the second start. This seemed to be caused by the registry staging of the App-V application. With App-V Registry Staging, data from the application is copied to the following area of the registry when the application (Publish AppVClientPackage) is released.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages\<PACKAGEID>\Versions\VERSIONID\REGISTRY

When the action is complete, an empty key RegistryStagingFinished is generated.

Registry Staging Finished

The loading of the application registry apparently didn't work with some applications anymore, as the customer found out himself. At the first start the entry RegistryStagingFinished is not available. The App-V Registry subsystem was inactive after the first start. With the second start the application worked. Only Citrix terminal servers provided by Citrix Provisioning Services were affected. However, given the nature of the problem, it is very likely that other systems provided via Non Persistent Images (e.g. MCS) will also be affected. Some applications were still running. Of course not all applications use the registry but also applications that use the registry were affected!

Start the App-V Package with a simple script first?

My first approach was a simple script in the package. That also helped in this case:

Simple Script in App-V Package

This could then be improved by waiting for the registry key RegistryStagingFinished to be created. So in PowerShell for example like this:

until (Test-Path "HKLM:\SOFTWARE\Microsoft\AppV\Client\Packages\$package\Versions\$VERSIONID\RegistryStagingFinished")

Of course the approach is not quite practicable because then all packages have to be provided with scripts.

NoBackgroundRegistryStaging

Now we found the registration key NoBackgroundRegistryStaging in a blog from 2014: 

https://blogs.technet.microsoft.com/gladiatormsft/2013/09/25/app-v-on-registry-staging-and-how-it-can-affect-vdi-environments/

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Subsystem
Value: NoBackgroundRegistryStaging
Data Type: DWORD
Data: 1

This is where it gets interesting. The article describes that in VDI environments a high CPU load may be generated with BackgroundRegistryStaging. The conversion to on-demand staging is intended to achieve considerable improvements. The key also means that the registry settings are only loaded when the application is started. Really a nice thing - why has nobody told me that so far?Well, if you're looking... "The knack" has written a nice article about it and pointed out the improvements of the CPU load:

https://www.applepie.se/app-v-5-and-citrix

Unfortunately, this again poses a problem. At the customer we use the Deployment.xml intensively, in order to set Registry keys for example for the ODBC settings. This doesn't work anymore with this registry key and hasn't been fixed yet. A description can be found here:AppV 5 registry keys not applying when set in DynamicConfiguration.xml

https://theorypc.ca/2014/06/

Those were workarounds but why is it now?

Christian and Rene, two employees at the customer's have found out for themselves with a lot of testing and analysis - many thanks for that and for the great information! I don't want to withhold their findings from you, especially as there doesn't seem to be any information on the Internet yet. In the past we had similar problems for example in an MCS environment. At that time I circumvented this by a global release of the application and put the problem on the CtxAppVLauncher.exe. Well, from today's point of view it wasn't the fault. In the master image and in the registration of the master image there were previously published App-V applications. This apparently led to an inconsistency. If the master image is clean, the release will always work with RegistryStaging.So maybe as a last step before updating the master image you could schedule the following command to clean up the system?:

Get-AppVClientPackage *-all | Unpublish-AppVClientPackage -ea SilentlyContinue
Get-AppVClientPackage * -all | Unpublish-AppVClientPackage -Global -ea SilentlyContinue
Get-AppVClientPackage * -all | Remove-AppVClientPackage -ea SilentlyContinue

in my German App-V book I printed a script that can radically delete all App-V files and registration keys. So if nothing works anymore.