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.
When the action is complete, an empty key RegistryStagingFinished is generated.
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!
My first approach was a simple script in the package. That also helped in this case:
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.
Now we found the registration key NoBackgroundRegistryStaging in a blog from 2014:
Data Type: DWORD
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:
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
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.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.