Udostępnij za pośrednictwem

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

  • Artykuł

fyiI 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

Comments

  • Anonymous
    January 01, 2003
    This post leads to an interesting question. Does App-V now support Group Policy Preference Extensions since virtual apps will now read the native registry for GP settings? I read in Jeremy Moskowitz's excellent book Creating the Secure Managed Desktop that v 4.2.1 would honor traditional GPO settings (such as are used in MS Office) with the exceptions noted in the post, but that version does not support GPPEs. Your insight on this would be appreciated. Thanks!

  • Anonymous
    September 14, 2010
    I am deeply saddened by the fact all keys or values under the policy roots are obliterated. Is there any workaround to override group policy with less restrictive settings on a per-application basis?

  • Anonymous
    October 11, 2011
    @Kid:  Yes there is a workaround.  Captured newly created keys in the sequencer are marked "override local".  Manually change them to "Merge with local".