10/13/2004 -- I recently had a consulting client who was trying to centralize the configuration of a line-of-business application they’d written years ago. The application utilized registry keys for its configuration, so they reasoned that Group Policy would be a good way to centralize that configuration for their Win2000 and WinXP clients. They spent days creating an ADP template, finally importing it successfully into a new Group Policy object (GPO), only to find that… well, they couldn’t find it. None of their settings showed up. I was on-site for some other work, and helped them figure out the problem.

Turns out the problem came from a misunderstanding about the way that GPOs work, and in a shortsighted (in my opinion) decision on Microsoft’s part.

There Are Policies, and Then There Are Policies
First, some terms: A GPO is a file that sits on the disk of a domain controller and is linked to one or more domains, sites, or organizational units (OUs). A policy setting lives inside a GPO and basically hacks one or more registry keys. But GPOs actually define two species of setting: A policy and a preference. A policy is what Microsoft intended for use in GPOs: They hack a very specific section of the registry, that being a key under SOFTWARE\Policies in either HKEY_LOCAL_MACHINE (for computer-specific policy settings) or HKEY_CURRENT_USER (for user-specific policy settings). The trick with policies is this: They can be removed. From a logical viewpoint, the policies are applied when a user or computer logs in, and removed when they log out. This removal is possible because they’re all conveniently located in the SOFTWARE\Policies key; were they scattered throughout the registry, removing them would be much more complex.

The other trick, of course, is that applications have to be programmed to look in that section of the registry for their configuration settings. Most applications—Microsoft Office, for example—will maintain registry keys under something like SOFTWARE\Microsoft\Office, as well, using the SOFTWARE\Policies keys as an override only if they’re present—because, if there’s no GPO, they won’t be present. Apps not specifically designed to take advantage of this feature, however, are untouchable by policies.

Which is where preferences come in. Just like policies, they hack the registry, but they don’t go into the special SOFTWARE\Policies area. Instead, they hack any old part of the registry you want them to, allowing them to configure applications that weren’t specifically written to work with GPOs. The problem with preferences is that they can’t be unapplied: If you apply a bunch of them in a GPO and then un-link that GPO, your preferences remain configured. They don’t get removed, as they would if they were policies. So there’s a downside to using these things, and you have to be careful with them.

Ignore the Policy Behind the Curtain
So my consulting client’s problem was that their ADM template was defining preferences, not policies, and here’s where the shortsighted decision by Microsoft comes into play: By default, the GPO Editor doesn’t show preferences. I suppose in an effort to hide things that might hurt or alarm you, the GPO Editor by default only shows managed policies—that is, those which live in SOFTWARE\Policies. Import all the ADM templates you like and they’ll all appear empty in the GPO Editor if they only contain preferences (or, in Microsoft lingo, unmanaged policies).

To correct this, you have to expand the Administrative Templates folder in the User Configuration or Computer Configuration sections of a GPO (each section maintains its own settings; do this for both if necessary). Making sure the Administrative Templates folder is selected, select Filtering from the View menu, and clear the checkbox Only show policy settings that can be fully managed. Poof, my client’s ADM template-defined settings magically appeared, allowing them to configure their application via GPO.

Policies, Preferences and You
The downside to using preferences, as I’ve mentioned, is that they don’t go away on their own. If you ever need to de-configure them, you must do so by applying a GPO which resets the registry keys to whatever you need them to be. Then, and only then, can you safely unlink the GPO (after it’s applied to your clients, of course); if you just remove the GPO then the preferences will hang around until you manually fix them or create a new GPO to do so.

One irritating point is that Microsoft continues to produce software which doesn’t utilize the preferred, managed, policy-based way of handling configuration. Windows Script Host (WSH) 5.6, which includes great new registry-configured security settings, is a prime example of this, because it uses regular old registry keys to configure its operation. That means if you want to centrally configure it, you have to create an preference-based ADM template, rather than one which uses the more elegant policies. It does leave you sort of wondering why every product Microsoft puts out wouldn’t just use SOFTWARE\Policies as a matter of course, but there you have it.