Knowing your GPPs from your GPSes

Advanced group policy management in Windows

SGI logo hardware close-up

Sysadmin Blog In my last set of articles I discussed why managing systems via Group Policy Objects (GPOs) is easier, especially for junior administrators who either don’t know the scripting languages or the ins and outs of the operating systems and applications they manage.

Today we're focussed on what the Windows NT6 operating systems, (Vista, 2008, Windows 7 and 2008 R2) bring. As NT6 is so different from its predecessors there naturally are changes to the ability to manage these operating systems from within Active Directory (AD).

As far as I am concerned, the most important change to group policy management in NT6 isn’t even available unless you are a Microsoft volume licensing customer - although MSDN and Technet subscribers are allowed to download it for fun. The Microsoft Desktop Optimisation Pack (MDOP) brings Advanced Group Policy Management (AGPM), perhaps the biggest advance Microsoft has made in systems management since System Center.

Like some members of the System Center suite, this “advancement” was not made by Microsoft. AGMP is a partial rebadging of the GPOVault and most of the PolicyMaker family by developer DesktopStandard. I say “most” because initially Microsoft took a phenomenal product by an excellent company, and then drove it off a cliff.

While Microsoft cut some of the best features from PolicyMaker, and futzed up the initial re-launch of AGMP, it was such a great product to begin with that it couldn’t ruin it too thoroughly. I’d go so far as to say that the latest updates for AGMP have nearly restored it to its former glory. As with any Microsoft acquisition, if you avoid the first post-acquisition version, you’re usually good.

While AGMP brings with it many important features, the key feature is Group Policy Preferences (GPP). This is separate from what we normally think of with GPOs. I'm going to refer to that other bit of GPOs as Group Policy Settings (GPS). GPPs and GPSes are treated differently, and the differences are sometimes confusing.

GPPs can also be used on (later) NT5. While Microsoft is requiring an NT6 operating system’s version of the Group Policy Management Console (GPMC) to use them, GPPs will work on XP and Server 2003. This is because DesktopStandard’s software was designed during the NT5 era but acquired by Microsoft just prior to the launch of Vista.

So let’s define the idea of an AGMP “preference” as opposed to a “setting”.

Services integrated into all domain-joinable Windows operating systems are responsible for applying GPOs. They are applied at different times; on start-up, at logon, at logoff and “refreshed” periodically throughout the day when the system polls for changes. NT6 can use network location awareness to speed up change detection.

When the computer starts up, Windows checks the AD to see what GPSes it should apply to the computer regardless of the user. If changes are made to GPSes in the AD after the computer has started, those settings may be updated during a refresh check of the AD while the system is running. They will, for certain, be applied on next reboot.

When users log on to that computer, they bring with them their own GPSes. These GPSes are applied to the computer after it has applied its “computer wide” settings, and so they supersede them. When the user logs off the changes made to the system are rolled back.

Similarly, if the computer were moved around in the Active Directory, and some of its GPOs were no longer applicable, they would be “rolled back” to whatever the local settings of that system were before the GPO was applied.

In contrast, by default GPPs stay around until changed. GPPs are equivalent to simply opening the registry editor and punching in values. With the additional wrinkle that unless ordered otherwise, they rewrite themselves with every AD refresh. There’s nothing particularly elegant about it. The elegance comes with the ability to mix and match the default behaviours with "remove this item when it is no longer applied,” and “apply once do not reapply.”

Because GPPs simply alter the registry, they don’t remember the previous settings the way that GPSes do. When a GPP is removed, whatever setting it changed will revert to the application default settings, not to previously configured values. GPP settings are applied based on the action you choose for them: create, delete, update or replace.

Let’s use a real world example, and see how altering the home page in IE value would change depending on what was used to do the deed. Let us assume that the default IE homepage is left at the “MSN portal” abomination that Microsoft sets as default in the local policy of the computer.

Scenario 1: I set a GPS to apply to the computer object and change that homepage to http://icanhascheezburger.com. Presuming no users logging on have any GPSes which override this setting, all users of this computer will have http://icanhascheezburger.com as their homepage. If I remove this GPS, the homepage will revert to the MSN portal the next time the computer is rebooted. The user cannot alter the homepage setting.

Scenario 2: I set a GPS to apply to the computer object and change that homepage to http://icanhascheezeburger.com, but a user logs on with a GPS setting the homepage to http://www.funnycatvideos.net. The homepage for that user will, thanks to “last writer wins” GPS precedence, be http://www.funnycatvideos.net. If that user logs off, the homepage for that computer is reset to http://icanhascheezeburger.com. This occurs because the precedence of the user GPS has been removed from the equation, but the original computer GPS is still valid. The user cannot alter the homepage setting.

Scenario 3: I want to set a GPP to change the homepage for all users on a given computer object. I can’t, because GPP by default doesn’t let you alter chunks of the local computer policy (Disregard for now the part where you theoretically could write a GPP item to modify the registry item directly. The default options don’t let you change the IE homepage for a whole computer).

Scenario 4: I set a specific user's homepage to http://icanhascheezburger.com using GPP, and "remove this item when it is no longer applied" is not checked. The setting is applied the first time the user logs on, but the user can change their home page to whatever they want. During the next Group Policy refresh, the user's configuration will be set back to the GPP's value of http://icanhascheezburger.com. If I were to remove the GPP from the ADD, then on the next Group Policy Refresh, it would stay set to http://icanhascheezburger.com until the user chooses to change it.

Scenario 5: I set a specific user's homepage to http://icanhascheezburger.com using GPP, and this time I do check "remove this item when it is no longer applied." The setting is applied the first time the user logs on, but the users can change the home page to whatever they want. During the next Group Policy refresh, the user's configuration will be set back to the GPP's value of http://icanhascheezeburger.com. If I were to remove the GPP from the ADD, then on the next Group Policy Refresh, it would reset back to the MSN portal, as this is the system default.

Scenario 6: I set a specific user’s homepage to http://icanhascheezburger.com using GPP, and this time I do not check "remove this item when it is no longer applied.” In addition, I check “apply once and do not reapply.” The setting is applied the first time the user logs on, but users can change the home page to whatever they want. The setting is never reapplied by the system. Should they choose to override the default value I provided, their choice will stick.

Now let’s take this a step further.

Let us say that I have an Organisational Unit (OU) called “New Users.” I set up a series of GPPs to cover every conceivable default setting I might want; however they are mostly settings I feel the user should be able to change, such as the homepage. I can create these GPPs in the New Users OU with the "remove this item when it is no longer applied.”

I log the user on once while their user object is still in the New Users OU. This will default all the settings to what I want them to be, at which point I move the user object to another OU where they will stay from then on. That OU could have GPSes, or other GPPs on it, depending on the needs of that specific group. By loading up the new user for the first time while they were in the “New Users” OU however, it pre-configured a series of default settings that could be very useful.

You can also do this without the OU hopping using the “apply once and do not reapply” feature. Personally, I have found OU hopping for initial user creation easier on my brain because all my “default settings” are in the “New Users” OU. Everything not in that OU is a “production setting” and not exactly a polite suggestion.

GPPs apply much more often than GPSes. GPSes apply to Group Policy-aware applications and Windows components. In other words: they change the settings Microsoft provides you templates for, and nothing more. GPPs work with practically anything. If the template doesn’t exist, create it yourself. They can change any registry setting, modify INI files, create shortcuts, map drives, change folder options, modify various things in the control panel create files, folders and scheduled tasks and even more.

You can even use GPPs to modify local users and groups, a useful feature if you want to, for example, change the local administrator password on all systems on your entire network all at once. This is where “apply once and do not reapply” comes in handy.

GPP can be used to run scripts via its ability to manipulate scheduled tasks), and it can even execute under different user contexts. By default it runs with the context of the system account, but it can be set to run as the logged-in user.

So the GPP enhancements that ship with AGPM as part of the MDOP for NT6 are not a replacement for GPSes, but an overall enhancement to GPO systems management. They help enhance the value of using Microsoft’s AD. ®

Correction

This article mentions that Group Policy Preferences are only available with Advanced Group Policy Management, which itself is only available as part of the Microsoft Desktop Optimisation Pack. This is in error; Group Policy Preferences are in fact available as part of the standard Group Policy Management Console shipped with Server 2008 and Server 2008 R2.

Sponsored: Designing and building an open ITOA architecture