How to troubleshoot situations where GPO settings are not applying to packages in App-V 4.5 and later
Hi, Steve Thomas here. Back in April of 2009, J.C. Hornbeck posted a blog on the changes that 4.5 brought with regards to how group policies affect registry settings:
Since the policies are no longer automatically applied to the virtual registry inside the package, additional adjustments will need to be made to packages to ensure that registry policies are applied properly from the local native registry. What we will need to do is adjust the package to not include any policy settings. We can do this at the key level but not at the value level so if you are ok with a policy or virtualized approach to these settings, we can certainly adjust the sequence to exclude these policy settings and that the GPO settings will always take precedence. For most common policies, those keys or values are not captured during the launch phase. However, we have found that there may be some exceptions where these values do get populated during sequencing. This is often due to external factors such as the design of some registry tattooing with some ADM templates or the application was not launched during sequencing.
In a recent case I worked, the customer could not seem to get the domain-supplied policies for Office Communicator to apply to the virtual package. As with any of these issues, the first thing we did was to isolate the registry locations of all potential policy settings. In the case of Communicator, we found them in the following key locations:
· HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator
· HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
· HKEY_USERS\.DEFAULT\Software\Policies\Microsoft\Communicator
The issue with the problem package was that these settings were captured and either had the “Override Local key” or “Merge with Local Key” setting. We did not want either in this case. We wanted these keys excluded from the sequence so the values will defer to what is local (passed by policy.)
For example, as you can see in the example below, the Messenger policy sub-keys were actually caught during sequencing and the keys were set to “Override Local Key.”
What we did with the customer’s package was to delete those keys from the package. (I would advise deleting the entire Policies key if it exists.) If you wanted to re-sequence to ensure that these keys would not get captured then you would need to re-sequence Office Communicator with the SPRJ file modified to exclude those keys. These can be adjusted by adding these new ones (Under Tools – Options – Exclusion items.)
You will need to add in the following exclusions with a mapping type of VREG:
· REGISTRY\MACHINE\SOFTWARE\Policies\Microsoft\Communicator
· REGISTRY\USER\%SFT_SID%\Software\Policies\Microsoft\Communicator
· REGISTRY\USER\S-1-5-18\Software\Policies\Microsoft\Communicator
Then start the monitoring phase and sequence Communicator as normal.
For more information on policies and App-V see the following: https://blogs.technet.com/b/appv/archive/2009/04/23/some-insight-into-how-softgrid-and-app-v-4-5-handle-group-policies.aspx
Steve Thomas | Senior Support Escalation Engineer
The App-V Team blog: https://blogs.technet.com/appv/
The WSUS Support Team blog: https://blogs.technet.com/sus/
The SCMDM Support Team blog: https://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: https://blogs.technet.com/operationsmgr/
The SCVMM Team blog: https://blogs.technet.com/scvmm/
The MED-V Team blog: https://blogs.technet.com/medv/
The DPM Team blog: https://blogs.technet.com/dpm/
The OOB Support Team blog: https://blogs.technet.com/oob/
The Opalis Team blog: https://blogs.technet.com/opalis
The Service Manager Team blog: http: https://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: https://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: https://blogs.technet.com/b/systemcenteressentials