Some insight into how SoftGrid and App-V 4.5 handle group policies

I came across an interesting nugget of information about how GPOs are applied in a SoftGrid/App-V environment so I thought I’d pass it along here just in case any of you were curious how these things worked.  The short version is that in 4.2 and earlier, policies were applied to the VReg and now in 4.5 they’re not, but here’s the full explanation from Matt Young, a senior SDE on the App-V team:

========

Each Group Policy Object (GPO) is manifested in the registry, in the form of keys/values, and they typically live under { HKCU || HKLM }\Software\Policies. These registry keys are pushed down from Active Directory upon user logon and in response to other events, as configured by the domain administrator.

For SoftGrid 4.2x and earlier, we would process the local policy files during launch and apply the keys/values to the virtual registry. Specifically, we used to apply group policy to the VReg as the last step in the launch sequence, after loading the read-only registry from section 9 of the sft file, deltas from cp file(s) and any keys defined in the <REGISTRY> tag the OSD file. We would apply GPO’s by parsing the .pol files and applying the keys/values to the VReg from the listener. This data was never cleaned out of the vreg (as it is in the native registry), and as policies change over time would result in a “union set” of the registry key manifestations of all GPO’s ever set. This caused issues for some, as policies when changed would update a portion of the VReg with a new value – in place. However other GPO’s will set a new value, sometime adjacent to the old value, causing indeterminate behavior depending on the specifics of the GPO.

When we looked at the various issues with our handling of GPO’s, we decided that GPO’s are not something that belong in the virtual registry at all. They belong in the native registry, where the existing mechanisms in Windows keep them secure and current. What was needed was not a series of “fixes” for how we duplicate these settings in the virtual registry, but to not have them present at all. If a virtualized application reads GPO values from the registry (either intentionally or as a result of some other action), the virtual registry should not ever provide an alternate view of these keys and values from that which is persisted in the native/real registry. Any deviation would be an instance of App-V altering policy settings defined by the Domain Admins.

In 4.5, we no longer process the local .pol files and apply them to the virtual registry. Furthermore, as the last step of the launch sequence, we forcibly obliterate any keys or values under the policy roots. This handles the case where a pre-4.5 package is loaded on a 4.5 client. Note: we do not delete them, as a deleted key or value “exists” in the VReg as deleted value. This has the side effect of not being able to intentionally set GPO values / keys in a package, however this was the goal.

J.C. Hornbeck | Manageability Knowledge Engineer