Chapter 8: How to set up the App-V Cache with PVS?
An on-going set of experiences in helping customers implement App-V in Citrix environments.
Scenario:
Customer is using PVS to provide Operating System image boots for XenApp or non-persistent Xen Desktop. App-V works initially, but then they notice that they are having issues with App-V applications after a reboot.
Time-Frame:
Citrix 7.x, App-V 5.x
Considerations:
First, in case you haven’t read the memo yet, if you are using App-V inside the data center on virtual machines, the App-V Client should be configured to use Shared Content Store (SCS) mode. Doing this should improve performance and is unrelated to using PVS; and whether you do this or not does not change the issue or solution the customer has. It is just a good thing to do to reduce IOPS. Now on to this problem!
When users log in to the machine with the VDA, the assigned App-V package(s) will be added to the VM and “published” from an App-V perspective. This will result in a lot of file “placeholders” created in the App-V cache area, (without SCS mode enabled these placeholders will have real content cached also). These are small, but there are a lot of them. Even with SCS mode enabled, some of the file contents must come down into the cache, such as the virtual registry file, and without SCS mode enabled these placeholders will have full content cached as well.
By default, the App-V cache would be placed in the folder “C:\Program Data\App-V”. If allowed to cache there, and assuming this is the Windows drive, this would result in significant changes monitored by PVS and help fill up the PVS RAM cache. So the current best practice is to configure the App-V cache to a secondary drive when PVS is in use. And this customer had followed this practice.
But we need to keep in mind that in addition to placing files in the cache, the App-V client also records package information in the HKLM hive of the Windows Registry! In this scenario, after PVS reboot, the registry changes are missing but the packages remain in that persistent App-V Cache. And this confuses the App-V Client.
When the first App-V app is added to an otherwise non-existent, the App-V client creates the cache folder and sets special security options such that only the App-V Client running in the context of the system SID can make modifications. This is a very important security setting! We often tune anti-malware software to exclude the App-V cache from routine scanning in order to improve system performance. If you add that exclusion, you really want to ensure secure control over rights to this area.
With PVS involved, after rebooting and joining the domain again, the system has a different SID and subsequently the new App-V client doesn’t have the rights that it requires. This is the cause of the customer’s issue.
Solution:
We asked the customer to add a boot-up script to delete the main App-V cache folder on the persistent drive. This causes the App-V client to recreate the folder automatically from its configuration and set the correct security settings. As the customer previously used Citrix Streaming Apps on 6.5 PVS systems, their response was “oh yeah, we should have thought about that ourselves,” as this is exactly what they used to have to do with the Citrix Streaming cache.
Adding a third “non persistent” drive might be an optional solution to the issue. In addition to the App-V cache, there are a number of things that can be redirected to this drive, keeping them out of the PVS RAM cache and off the persistent drive where they are not needed.