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.
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.
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).
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.
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.
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 MDMandGPanswers.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
Manage App-V applications dynamically with Group Policy video transcript
Hi, this is Jeremy Moskowitz, Founder of PolicyPak Software and Group Policy MVP. I want to show you in this video how you can use PolicyPak and Group Policyto deliver settings to any Microsoft App-V virtualized application.
Let’s go ahead and run this first one. This is “WinZip.” You can see it’s launching WinZip for the first time coming down from the server. What you’ll notice if you consider what users see, they go to “Options/Configuration…” and there’s a lot of stuff for users to get wrong here.
You might have a situation where you want to deliver the settings separately for one OU versus another OU, and we can talk about any kind of application. Of course, this application stores its things in the virtual registry.
Let’s go ahead and look at another application, which would be Firefox. If you run Firefox, you can see it’s launching Firefox from the server, coming on down from the App-V streaming server, and it will launch. The thing about this application is that, just to make things difficult, Firefox doesn’t store its items in a registry. No, it stores its stuff in the file system – in a very strange place in the file system, no less.
What we want to try to do is to see if we can use application virtualization plus PolicyPak to deliver settings to these applications. To do this, to get started here we’re going to go over to this other machine, which is acting in multiple capacities. One of the things that it’s doing is it has our PolicyPak Creation Station utilities on it, called the PolicyPak Design Studio.
We’ll go ahead and click “Start,” and fire up the “PolicyPak Design Studio” utilities. We can see the “Group Policy Management” console here in the background. We’ll get to that in a moment. On the download for PolicyPak, what we’ll see is a bunch of our PreConfigured PolicyPaks. Now PolicyPak can either be used with a PreConfigured PolicyPak, or you can design your own with the PolicyPak Design Studio.
To get started here, what we’re going to do is we’re just going to take over the “Firefox” Pak. I’ll just copy that XML file here. I’ll also take over the “WinZip” Pak, which I’ve got here. What I’m going to do is I’m going to “Load a project from XML file.” Again, these are PreConfigured Paks. You could start a new project if you want to, but we’re just going to “Load a project from XML file” here.
We’ll go ahead and click on “WinZip” first. Now when WinZip comes up in the PolicyPak Design Studio, it’s already prebuilt from our company ready to rock. But the one thing we don’t know is what the App-V application GUID is, because when you repackaged your version of WinZip and somebody else repackaged their version of WinZip, it’s going to have a different App-V GUID.
On my server here, in the “C:SGContent” directory, I have a bunch of virtualized applications. I can see I’ve got WinZip and Firefox and a bunch of other things here. Well, with PolicyPak Design Studio, we make this super easy. Like I said, we’ve already preconfigured this Pak for all the knowledge we need.
But when we click on the “Project Properties” here, we can see the “Microsoft AppV compatibility” flyout. We’ll go ahead and click on the “GUIDs.” We can either “Add GUID manually” or “Add GUID automatically from OSD file.”
All we’re going to do is bang in the “C:sgcontent” directory. We can see we’ve got WinZip 14, Firefox and a couple of other applications there. I’ll click on “WinZip 14” here. It jams in the GUID. This is a registry virtualized application, so we’re going to be able to punch in all these items right into the virtual registry.
No changes are required on the App-V package. All we’re going to do is take our PolicyPak and “Save pXML and Compile” it. We’ll use it in just a moment. We’re going to do the same thing for also Firefox, because the idea is again somebody in Company A might have created the App-V package and it has one GUID and another person might have a different one.
Let’s go to “Desktop” here. We’ll click on “firefox.” There’s our Firefox Pak. Again, it’s preconfigured, ready to rock right out of our company here. We’ll click on “Project Properties.” I have a GUID in there already, but I’ll show you how we do this. I’ll go ahead and “View, edit or delete existing GUIDs” just for fun. We’ll get rid of this guy here.
Now what I’ll do is I’ll click on the same thing “…” and I will “Add GUID automatically from OSD file,” pick “C:sgcontent” and there is my “Firefox” application, and it jams in the correct GUID there. That’s it. I’ll go to “Compilation,” and I’ll “Save pXML and Compile.” Again, this is preparing it for use inside of Group Policy.
Alright, now all we’re going to do is to “Create a GPO” here. We can call this Group Policy Object “Configure Winzip and Firefox.” Two separate things, but we can do that in the same PolicyPak if we want to. We’ll go ahead and click “Edit…” here. This is hooking right into the Group Policy infrastructure. We’ll go to “New/Application,” and we’ll do “PolicyPak for WinZip 14 and 15” first.
In WinZip, we’ll go ahead and we’ll deliver some “Passwords” settings. We’ll go ahead and check all these guys here. We’ll jam this guy up to 11, but we’re going to go an extra mile here. We know that it’s in the virtual registry, but we can also on the fly make sure users can’t manipulate the settings.
So we’ll “Disable corresponding control in target application.” We’re literally going to gray it out. We’ll also gray it out here, and we’ll also “Hide corresponding control in target application” on this last one just for fun.For Cameras, we’ll right click over “Cameras” and we’ll also”Disable whole tab in target application.”So we’re actually manipulating that guy on the fly.
That’s it. We’re delivering settings to both a virtualized registry based application and a file based application. We’re logged in as the correct user here. Let’s go ahead and run GPUpdate. We could also log off and log back on, if we were so inclined. As soon as this is done, we have locked and loaded everything we need.
We’ll start out by running “WinZip” here. Again, this application is being launched from the App-V server. We’ll go ahead and click “Options/Configuration…” here. Click on “Passwords,” and sure enough it has dictated the settings directly into the virtual registry. We can see here we’ve also manipulated the application so it can’t be changed. We can’t change that as a user. Also, we’ve eliminated that tab from being checked upon.
What’s more, if the user unchecks these checkboxes and goes to rerun the application, just as soon as they rerun the application we keep those settings permanent. So if they do figure out a way to work around those settings or you decided not to configure them, the next time the application runs we jam those settings directly back in.
Let’s go ahead and check out Firefox since we’re here. We’ll go ahead and run “Mozilla Firefox” here. If all went well, we see that we’ve got the “www.Test1.com” as we expected. Even if a user decides they want to go in here, change this to “www.test5.com” or something that they shouldn’t really be doing, again the very next time that they try to run Firefox what’s going to happen? We’re going to ensure that the settings that we set using PolicyPak are back for the user.
One last thing, let’s go ahead and make this policy fall out of scope. We’ll go ahead and “Delete” this GPO, which means that none of the users in the OU will get affected anymore. Let’s go ahead and run GPUpdate again on this machine. What do we expect to happen? Well, the settings that we said to revert will revert back. The settings that we said to leave alone will be left alone. All the App Lock stuff, all those lock out functions that we have, will be removed from the client machine.
Let’s go ahead and check it out. Let’s go ahead and run “WinZip” first. Go to “Options/Configuration…” here, and sure enough we’ve got all the lock out stuff removed. We didn’t tell it to revert the settings back, but it absolutely would. PolicyPak has a superpower to revert the setting to the default value when it’s no longer applied.
Let’s go ahead and check that out in Firefox, and sure enough. If you go to “Tools/Options…” here, you’ll see that it got delivered back to “about:blank,” which is the absolute default that Firefox has.
So the key takeaway with regards to PolicyPak and App-V is you get to sequence your application one time and then change the settings to various OUs on the fly. We’ll deliver the settings, lock out the applications UI so users can’t possibly work around it. Even if they do, we replace those settings back the very next time that the application is run.
I hope that gives you a lot of insight. A lot of folks love the idea of being able to tap into both the virtual registry and the virtual file system on the fly using technology they already have, which is the Group Policy infrastructure.
Thank you very much for watching, and looking forward to seeing you test out PolicyPak Software.
Thanks so much.