How App-V Handles Group Policy And Group Policy Preferences

Understanding AppV’s interaction with Group Policy has always been a little challenging. There isn’t a lot of documentation on this, but there have been some blog entries from Microsoft.

For instance, I have read, read, and re-read this Microsoft blog entry which describes how AppV does or doesn’t embrace Group Policy directives.

It basically says Group Policy settings are never embraced. But even after that, I wasn’t totally clear under what conditions App-V would embrace Group Policy settings.

So I tested it out. (And, for what it’s worth I asked the App-V product team inside Microsoft to validate my testing and methodology to make sure I wasn’t “making anything up.”)

So, here goes. I set out to perform three tests: Test 1: Deliver Group Policy Administrative Template setting that Microsoft ships.

    • Example: “Remove Help Menu from Start Menu”
    • Example registry key: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerNoSMHelp = 1

Test 2:  Deliver registry entries to proper “Group Policy” ‘Policies’ keys for 3rd party application

    • Example: Office 2010 setting
    • Example registry key: HKEY_CURRENT_USERSoftwarePoliciesMicrosoftoffice14.0wordoptions

Test 3: Deliver registry entries “anywhere else” ..where an application would pick them up.

    • Example: HKEY_CURRENT_USERSoftwareNico Mak ComputingWinZipPolicies

After I deployed each of these using Group Policy, my test would be to look inside the REAL and App-V registries and see what I could see. Let’s see each test, and examine the results.

Test 1: Deliver Group Policy Administrative Template setting that Microsoft ships.

In this first test, the goal is to see if “garden variety” Group Policy settings were embraced by App-V. To do this, I’m using the Group Policy setting entitled “Remove Help Menu from Start Menu” which happens to put it’s registry data as follows: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerNoSMHelp And the REG_DWORD value is 1. Test 1 Results: App-V embraces “Proper Policies Keys” Group Policy settings

Since this is a proper “Policies” key (there are four “sanctioned” Policies keys), this setting appears in both REAL and Virtual registries as seen here.

how-app-v-handles-group-policy-and-group-policy-preferences-0

What does this mean for you? Well, not much.

Even though an App-V sequence will, indeed, “see” these settings, there’s not many applications which are looking for Microsoft’s preset policies like “Remove Help Menu from Start Menu.”

Test 2:  Deliver registry entries to proper “Group Policy” POLICIES keys for 3rd party application

In this example, I’m trying an ADM or ADMX template for an application which is properly “policy enabled.” There aren’t many applications like this, but Office 2010 is, in fact, one of them.

So, here I’m testing delivering a registry punch into: HKEY_CURRENT_USERSoftwarePoliciesMicrosoftoffice14.0wordoptions Test 2 Results: Same as Test 1! App-V embraces “Proper Policies Keys” Group Policy settings Similar to Test 1, since this key is a proper “Policies” key. The setting is seen in both real registry and in all AppV bubbles.

how-app-v-handles-group-policy-and-group-policy-preferences-1

What this means: If the application, like Office stores its keys in “Policies” as seen here, then your App-V application should pick it up. The bad news, of course, is that hardly any applications have ADM templates which affect the “proper” policies keys like Office does.

The more common case is where the application’s registry items are stored “somewhere else”, like Acrobat Reader, WinZip, Lync client, and pretty much all other apps that use the registry. That’s what Test 3 is all about.

Test 3: Deliver registry entries “anywhere else” (where most applications store their settings.)

There are a million applications which store their settings in the registry.For this example, I’ve chosen WinZip, which specifically stores its items in: HKEY_CURRENT_USERSoftwareNico Mak ComputingWinZipPolicies You could deploy settings here using ADM files, ADMX files or Group Policy Preferences. The “delivery” result is all the same.

Test 3 Results: Application setting is delivered to real registry (as expected), and obliterated in AppV registry (like what Microsoft’s blog entry says).

how-app-v-handles-group-policy-and-group-policy-preferences-2
how-app-v-handles-group-policy-and-group-policy-preferences-3 What this means: For the majority of application – bad news.

Again, WinZip or Acrobat Reader or Lync client, or most other registry-based applications settings won’t be seen in App-V. Since the application stores it’s settings “anywhere else” then AppV will not honor it’s settings.  Those settings are not seen in the App-V bubble.

Final Thoughts

So, sometimes Group Policy settings will make it thru to your App-V sequences. By default that only occurs for “proper Policies keys” as seen in test #1.

Also note that for tests #1 and #2, there is potential that a registry key could be present if Group Policy was (oops!) applied during the sequencing process. However, this risk is eliminated through the best practice of Sequencingan application using an offline, non-domain joined machine.

For test #3 – it IS possible to make entries visible to the virtual application. To do this, in the Sequencer, you need to mark the Policies key as “Merge with Local” then also delete any of the keys underneath Policies in the package at the end of Sequencing.

The downside here is that you have to do this for each package you want Group Policy to work with, and even worse, the changes you make inside the app will filter back to the real world, and you likely don’t want that.

In short, the only way to truly manage your App-V applications using Group Policy is using PolicyPak. PolicyPak can deliver (and undeliver) settings anywhere in the registry – the way you would expect. Besides, PolicyPak can deliver settings to non-registry based applications, like Firefox, OpenOffice, Flash, Java and more.

Watch this video of an overview of PolicyPak’s App-V superpowers and see how quickly and easily you can manage your App-V applications – without resequencing, making any changes, or re-deploying anything.

Click here for Video Transcript

You can create your own PolicyPak for your applications to manage all the application’s settings, or use one of our pre-configured Paks for lots of common applications like Firefox, WinZip, Office 2010 and more.

You’ll be managing your App-V sequences’ settings using Group Policy – quickly and easily.

There’s nothing extra to buy – this functionality is all included when you’re a PolicyPak Professional customer.

PolicyPak was designed by Group Policy MVP Jeremy Moskowitz – who “wrote the book” on Group Policy, runs GPanswers.com, and lives and breathes Group Policy and enterprise software deployments and desktop lockdown.

When you’re ready to manage your App-V packages using Group Policy, PolicyPak is here for you.

Click on Download to get the software and try it out for yourself