Group Policy Preferences (GPPs) first came out with the Windows Server 2008 Group Policy Management Console (GPMC) introducing an array of configurable items not available in earlier native policy objects. Microsoft calls these “preferences” or “unmanaged settings” because after the preference has been applied, the end-user can change it back again.
In my opinion, however, these aren’t the best terms to apply here. The next time the Group Policy Objects (GPOs) update again, perhaps the default of 90 minutes or the next time the user logs on, or the computer reboots, the preferences get applied once more. When I first heard about GPP, I thought this was a perfect way to set all those things we used to modify in the Default User profile, for example, the Internet Explorer Home Page. We would set that to the corporate intranet in the Default Profile, new users would get that setting, but afterwards they could change their Home Page as desired and it would remain there.
One of our specialties is making applications (perhaps historically misbehaved applications) work well with Terminal Services and Citrix. We often used the Default Profile method of setting minimum registry entries required by an application (if Terminal Services “install mode” didn’t quite work), but that must be customisable by the end-user through the front-end Graphical User Interface (GUI). Managing the Default Profile, however, can be messy, and Microsoft doesn’t really like that practice anymore. In fact, you can’t even overwrite the Default Profile in Windows 7 anymore without going through a bit of a procedure. At least one Microsoft employee has posted on a TechNet forum that overwriting has not been supported by Microsoft since Windows XP/2003. It’s not hard to manually add registry entries to the Default Profile, but I thought these new GPPs would save us from all that.
But if GPPs get reapplied at GPO update time, how can we re-create this requirement of “suggesting” settings, but allowing the user to permanently change them? Microsoft has an answer to this: the Apply once and do not reapply setting of a GPP, available in the Common tab. This works fine and does exactly that. There are management problems, however, and some unexpected behaviour when using this feature. It’s still a step in the right direction, and it is better than modifying Default Profiles, but you need to be aware of these “glitches” to keep on top of settings defined this way.
This article will delve into this Apply once and do not reapply feature, demonstrate its shortcomings, and provide some suggestions in overcoming them. It will also explore the Remove this item when it is no longer applied feature and discuss its particular dangers.
GPP Review
No software or services need to be run at the back-end nor does your Active Directory (AD) domain need to be running any Windows 2008 Domain Controllers in order to implement Group Policy Preferences (GPP). You must, however, deploy the GPP client-side extension (CSE) to any client computer to which you want to deploy preferences. The CSE is available as an optional update in Windows Update, or it can be downloaded from the Microsoft web site and installed manually. There are versions for the following operating systems:
· Windows XP with SP2 or later
· Windows Vista
· Windows Server 2003 with SP1 or later
Windows Server 2008 and Windows 7 already include the CSE. You must also install the Microsoft Remote Server Administration Tools (RSAT) on the workstation from which you will be managing the GPPs, or use the Group Policy Management Microsoft Management Console (MMC) snap-in on a Windows Server 2008 server.
In the Group Policy Management Editor, the Preferences section looks very much like the ScriptLogic Desktop Authority software, a fairly common third-party solution used to fill this historical void in Group Policy.
The action of creating a new entry under any of these Windows or Control Panel Settings will launch an entry GUI that differs depending upon the type of entry. For example, adding a new mapped drive will look like this:
We’re going to be using a custom registry entry as an example later in this document, so let’s take a look at its GUI:
Let’s create something to work with.
a. First I installed the Microsoft RSAT onto my Windows 7 workstation.
b. On my Windows 2003 AD domain I created a “TestGPP” user account in the “Users” Organisational Unit (OU) and also created a “TestGPPgroup” security group for later use. The user is not a member of this group at this time.
c. I created a “TestGPP” GPO and linked it to my “Users” OU.
d. I then removed the “Authenticated Users” group from the GPO’s Access Control List (ACL) and added only my test user account, “TestGPP” to the ACL with Read and Apply rights so that I wouldn’t accidently mess anyone up except my test user.
e. I then edited the new GPO and added a new Registry item preference. In this example, I’m going to set the user’s Desktop background colour to be red. I expanded User Configuration, Preferences, Windows Settings, and selected Registry. then I right-clicked and added a new item, getting the screen similar to that shown above.
f. The hive and path are “HKCU\Control Panel\Colors”, the value name is “Background”, the value type is “REG_SZ”, and the value data is “255 0 0” (red).
g. My AD site here only has one Domain Controller (DC), so I did not need to synchronise my domain in order to begin testing.
Remember where GPO values are stored?
h. In the Group Policy Management window, highlight the GPO in question and select the Details tab. Note its Unique ID.
i. In Windows Explorer, navigate to “\\DomainName.Name\SYSVOL\DomainName.Name\Policies”. (Replace “DomainName.Name” in the path with your own fully qualified AD domain name.) Then navigate to the folder with the same name as the Unique ID as noted above.
j. Under that folder, navigate to either the “Machine” (for Computer Configuration) or “User” (as in the example above, for User Configuration) folders, and then to the “Preferences” sub-folder. This folder may be empty until some preferences are defined. Mine has a folder called “Registry”, which has a “registry.xml” file in it.
k. When I edit that file with a text editor such as Notepad, I see contents similar to this (I have added hard returns for readability):
name="Background"
status="Background"
image="7"
changed="2010-02-10 14:13:09"
uid="{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
bypassErrors="1">
displayDecimal="0"
default="0"
hive="HKEY_CURRENT_USER"
key="Control Panel\Colors" name="Background"
type="REG_SZ"
value="255 0 0"/>
l. If I were to add more GPP types other than Registry, I would see other folders under that GPO folder such as “Drives”, “Files”, “Environment Variables”, etc., each with their own “*.xml” file.
m. When I log onto my computer as user “TestGPP”, my Desktop background has been successfully set to red.
Results of GPP Options
With the standard actions and options of the GPP defined above, the test user can change their background colour to something else, but the next time they log in, it will be red again. There are certain other types of GPPs that will be reset back to the value defined every time Group Policy refreshes, which is every 90 minutes by default (a background colour change requires a re-logon to take effect regardless of when the value changes).
What happens when the GPP is disabled or removed? I’ll create this scenario by disabling the specific preference, as shown below. We don’t have to disable the entire GPO.
With the default settings, and assuming that the user has not changed their background colour, it will remain red until they change it. I logged back on with my test account and it was indeed red. I changed it to brown, logged off and on again, and it remained brown.
Remove this item when it is no longer applied
If we look at the properties of the GPP, we will see that the default Action in the General tab is to “Update”. The difference between “Update” and “Replace” is that first “replace” will remove all values before re-creating them. If we go to the Common tab and select the Remove this item when it is no longer applied option, we’ll get a warning that it will also set the Action to “Replace”.
I enabled the GPP again, set the options as discussed, and logged on as the test user to ensure that it was taking effect again. Then I disabled the GPP and logged back on as the test user. The background colour was now black, or 0 0 0, the colour set in the Default Profile of this computer. Also, if I manually look at the registry key, “HKCU\Control Panel\Colors”, there is no “Background” value (there was in all previous sessions). There won’t be until I set the colour to something else. This proves that the “Replace” Action does what it’s supposed to do. The GPP CSE runs and analyses GPPs even if they are disabled. This behaviour would also occur if the entire GPO was disabled or filtered from being applied to that user.
This is important to remember. Consider the following scenario.
a. A user has set some preferences within an application, perhaps required to make it function at all (maybe setting up an ODBC DSN, for example), that results in some registry changes in their profile.
b. IT decides to control this centrally by creating those preferences in a Registry GPP, and selects the Remove this item... option described above.
c. Time passes and for some reason IT decides to remove or disable the GPP, or maybe the computer has lost communication with the DC and GPOs do not run.
d. The end user not only loses those controlled settings, but they also lose the settings they had originally manually set, and receive generic settings from that computer’s Default Profile. In a bad case, this could even break the application and result in a call to the Help Desk.
There are exceptions. Not all GPP types can have this option set.
· I could not create an Applications GPP to test. I don’t have any application preference plug-ins installed. Note from the Microsoft TechNet library:
Group Policy includes the Applications preference extension. For users, this extension allows you to configure settings for a specific version of an application for which you have installed a preference plug-in. The available settings vary with the application and version.
Software developers can create plug-ins for other applications using the Group Policy Software Development Kit (http://go.microsoft.com/fwlink/?LinkId=144).
· For the Devices type, the Remove this item... option is only available if the Action is set to “Disable”.
· When selecting the Remove this item... option for the Local Users and Groups type, you get two options: it will set the Action to “Replace” in order to completely remove the group, or to “Update” to simply remove a member. Keep this in mind if the GPP is to add a member to a built-in group such as “Administrators”. Would the GPP be able to remove that group if the Action is set to “Replace” and the GPP falls out of scope? I was unwilling to test this on my computer.
· With the Power Options GPP type, you get a warning saying that you cannot select the Remove this item... option if you try to, however, if you click OK it does seem to take effect.
The bottom line is to use this Remove this item when it is no longer applied option with care. Understand the ramifications of removal if the user or computer loses access to the GPP.
Item-level targeting
This option is mentioned here before the next one merely to remind us of its capabilities, since it will feature in the upcoming example scenario. There are no hidden surprises in this feature, so I won’t be expanding upon it. Basically, you can filter if the individual GPP gets applied depending on a range of criteria, including items such as AD site, IP subnet, user group membership, OU, and many others. (It would be best practice to write a plain English summary of the criteria in the
Description field of the GPP.)
This targeting is on top of the targeting that is being applied at the entire GPO level, such as with OU links or ACLs.
Apply Once and do not reapply, Issue One
As its name implies, this feature will only apply one time to a computer if it’s a
Computer Configuration, or one time to a user’s profile if it’s a
User Configuration. How does the computer then know not to apply this GPP anymore? This option comes with its own special bag of tricks. Let’s proceed with setting it and see what happens.
a. I modified the existing “TestGPP” GPO I created in the “GPP Review” section above, the one that sets the user’s Desktop background to red (255 0 0). I set the Action back to “Update” and cleared the Remove this item when it is no longer applied option.
b. I then selected the Apply Once and do not reapply option.
c. After the user logged on one time and received this GPP again, a new registry value got created in the user’s profile, under HKCU. Note the value created for my test user:
key: HKCU\Software\Microsoft\Group Policy\Client\RunOnce
value name: {11950636-4A63-46A1-9A52-3854F61C6149}
value data: empty
If this was a Computer Configuration as opposed to a User Configuration, the registry value would be under HKLM. For the duration of this article, I will refer to this registry value as the registry “flag”. This is a flag that tells the GPP CSE not to process that GPP again.
d. Note an additional entry in the “registry.xml” file of that GPP, located in the domain’s SYSVOL folder, under the GPO’s GUID folder (discussed in detail in the “GPP Review” section above):
id="{11950636-4A63-46A1-9A52-3854F61C6149}"/>
Notice the matching numbers. Next time when the user logs on, the GPP CSE will still process that GPP. However, it will not apply values of the GPP because the ID number in the user’s profile (the flag) matches the “RunOnce” ID in the “registry.xml” file.
The usual GPO or scripting behaviour applies when modifying settings and this Apply Once and do not reapply option is selected. If it is a Computer Configuration GPP, the GPP will run once for each computer the first time it receives this GPO. If it is a User Configuration GPP, it will run once for that user’s profile the first time they receive the GPO. This is not to say that it will run once per user. It depends on the profile scenario in place. If Roaming or Terminal Services profiles are in place, then it will run once for that user, but if local profiles only are used, it will run once per user per computer (or per profile).
All right, let’s get fancy. Let’s apply Item-level targeting to this GPP and let it apply only to members of the “TestGPPgroup” user group. Note that our “TestGPP” user is not yet a member of this group.
a. First, let’s set the user back to as if this GPP had never run. We will do this manually for now. I logged on as the test user, changed the background colour to brown again, ran “regedit.exe” and removed the flag “HKCU\Software\Microsoft\Group Policy\Client\RunOnce\{11950636-4A63-46A1-9A52-3854F61C6149}”, and then logged off.
b. Then I modified the existing registry GPP in the “TestGPP” GPO. In the Common tab, selected Item-level targeting and clicked the Targeting button to add criteria.
c. I added a Security Group criteria where the user must be a member of the “TestGPPgroup” group, and then closed the GPO Editor.
d. I logged back on as the test user and, as expected, my background was still brown. The GPP had not changed it to red. But wait! The test user received that registry flag once again with the ID of the GPP not to process.
e. I then decided that I wanted the “TestGPP” user to be a member of the “TestGPPgroup” group so that he has to have a red background on his Desktop. I added that user to the group.
f. I logged on as the test user and still saw a brown background. The GPP did not apply, even though I was now a member of the criteria group.
This behaviour is important to remember. The fact that the user had that registry flag of the ID of the GPP not to apply took precedence over the group membership of that user matching targeting criteria. This makes sense. The next time the user logs on, or Group Policy updates, the user will probably still be a member of that group, yet if it was a valid “apply once” the first time, we would not want it to run again. (What would seem to make more sense is if the GPP CSE didn’t add the registry flag if the contents of the GPP did not, in fact, get applied in the first place.)
You cannot pre-configure a GPP, set it to Apply once..., and set targeting criteria where all future intended recipients do not currently match that criteria.
Issue One Work-Around
There is a work-around if you need to reapply the GPP to intended users, if it is possible to reapply it to
all users that match any targeting criteria or who are within scope of the GPO filtering. Reset the
Apply Once and do not reapply option. Un-check it from the GPP and click
Apply, then check it again and click
Apply. This will generate a new “RunOnce” ID for the GPP, as can be seen in the updated “registry.xml” file.
If it’s not possible to run the GPP again for all users, it gets a bit messier. You would either need to manually remove the existing ID from the user’s “HKCU\Software\Microsoft\Group Policy\Client\RunOnce” registry flag or in fact create an “Apply once” GPP to do this, targeting a new specific group called “RemoveTestGPP”, or similar.
Apply Once and do not reapply, Issue Two
You can copy and paste GPPs from the context menu.
a. I simplified our existing registry GPP in the “TestGPP” GPO. I removed Item-level targeting.
b. I then right-clicked on it and selected Copy, and pasted it in the same area. I modified the registry value, namely “Active Title” to red, 255 0 0.
c. Look at the “registry.xml” file now. I have removed the irrelevant bits for this point.
name="Background"
id="{11950636-4A63-46A1-9A52-3854F61C6149}"/>
name="ActiveTitle"
id="{11950636-4A63-46A1-9A52-3854F61C6149}"/>
Note that the “RunOnce” IDs are the same for both values.
This means that though this is a brand new value to modify, because the “RunOnce” IDs are the same and because the user has that ID in their registry flag from our exercise above, this new value will never be applied to that user.
Issue Two Work-Around
Similar to the work-around for Issue 1, reset the Apply Once and do not reapply option. Un-check it from the GPP and click Apply, then check it again and click Apply. This will give the new GPP a new “RunOnce” ID, as can be seen in the updated “registry.xml” file.
Apply Once and do not reapply, Alternatives
Repeating my hopes in the introduction, I was really glad to hear about this Apply once... feature of GPPs. I thought that finally there was a way we could “suggest” settings to new users, but allow them to change it later on, for good. This, I thought, was a good alternative to modifying Default Profiles.
Doubtless there are situations where this feature will work perfectly, but if we want to avoid having to worry about resetting “RunOnce” registry flags, we will have to go back to the tried and true methods.
Microsoft doesn’t want us overwriting Default Profiles (although, there are ways to do it), but we can still modify it. A recap on how to do this:
a. On the computer with the Default Profile to modify, make sure we can see hidden and system files, as well as their file extensions. Modify Folder Options accordingly.
b. Run “regedit.exe” and select “HKEY_USERS” in the left pane.
c. Click File, Load Hive, and browse to “c:\users\default” and double-click on the “ntuser.dat” file. (This is for Windows Vista/7/2008. For Windows 2000/XP/2003, the default folder will be “c:\Documents and Settings\Default User”.) Give it any Key Name at all, so long as you remember what you named it. I’m naming mine “DefUser”. There will now be an “HKEY_USERS\DefUser” key. Expand this, and the keys under there will match those found under HKEY_CURRENT_USER (or HKCU).
d. You can directly modify registry values in there, or if there are a lot of changes as you have set them in your current profile, you can export keys (not the whole hive) into a registry file, replace all text strings “HKEY_CURRENT_USER” with “HKEY_USERS\DefUser”, and import it again.
e. Select “HKEY_USERS\DefUser” in the left pane and click File, Unload Hive, to save the values to the Default Profile.
Alternatively, you can implement login scripts that make use of flag files. In the example below, H: drive is the user’s network Home Directory and G: drive is a common location.
@echo off
ifmember.exe Background
if not errorlevel 1 goto Skip
if exist h:\flags\Background.flag goto skip
regedit.exe /s g:\share\configs\Background.reg
echo Background flag file created >> h:\flags\Background.flag
echo From %computername% - %date% %time% >> h:\flags\Background.flag
:Skip
The difference in logic here is that the flag does not get created if the targeting criteria is false, unlike the GPP Apply once... feature.
Summary
Group Policy Preferences are a nice tool to have, and will save many administrators having to write login scripts or make custom Group Policy Object Administrative Templates to accomplish the same thing. The separate GUIs shown for each type of preference is very handy and saves us having to figure out registry keys, and the item-level targeting will prove to be an extremely useful tool for most of us.
There are four possible actions for a GPP to take and five additional options that can be selected, though not all are available for all types of settings. There are two options in particular that need special attention.
The Remove this item when it is no longer applied feature should be used with care because if that GPP becomes out of scope of the client, for any reason including network disconnection, the values associated with it will not revert back to how they were before, but they will be deleted completely, leaving the user receiving new settings from the Default Profile.
The Apply Once and do not reapply feature displays some behaviour that might be unexpected. If it is used in conjunction with Item-level targeting and the intended recipients do not yet fit that criteria (for example, they have not yet been added to a specified group), they will not get settings from that GPP even once. It will run, filter criteria and not apply values, but still place a “RunOnce” registry flag in the user’s profile or in the computer registry hive.
If you copy a GPP with this option, it retains the original ID and thus users who have already run the original GPP will have their registry flag set to also exclude this new copy. There are work-arounds to all of these behaviours and issues, but they important enough to remember because they could have serious ramifications if the values in question are there to configure critical settings in a business application.
