Windows Insider

Extend the Limits of Group Policy

Don't let either the real or perceived limitations in Microsoft's default Group Policies prevent you from taking full advantage of this technology.

• By Bill Boswell
• 05/01/2005

You've certainly worked with Group Policies if you have Windows 2000 or Windows Server 2003 deployed anywhere in your organization (and the clock is ticking on NT4, by the way, in case you haven't yet completed your migration). You've probably customized password policies, locked down a few security settings, instituted a login script and possibly redirected the My Documents folder. However, quite a few of you stop short of getting the full value out of Group Policies because of their perceived limitations.

Scavenger Hunt
Let's review a few terms and processes before we talk about how to overcome some of those limitations—perceived or otherwise. Group Policies control member servers and desktops in much the same way that a host directs participants in a scavenger hunt. You give the players clues for finding certain items in certain locations. Some of those items are themselves clues for finding other locations with even more clues, all of which eventually lead to a prize—or the edge of an unfinished freeway overpass if the player incorrectly interprets any of the clues.

Group policy "clues"—by which I mean the configuration information—come in the form of Group Policy Template (GPT) files stored in the Sysvol folder on each domain controller. Each type of Group Policy uses a unique GPT file format. For example, security policies are stored in Gptmpl.inf files, folder redirection policies are stored in Fdeploy.ini files, and the Logon/logoff-Startup/shutdown scripts use Script.ini files as well as the scripts themselves.

The Group Policy Editor (GPE) is the tool for creating and modifying the GPT files. Figure 1 shows the GPE display you'll see when setting a policy to prohibit creating new jobs in Task Scheduler.

Figure 1. The Group Policy Editor console, showing a modification to an Administrative Template setting. (Click image to view larger version.)

Enabling this Prohibit New Task Creation policy makes an entry in a file called Registry.pol. The entry looks something like this:

[Software\Policies\Microsoft\Windows\TaskScheduler5.0; TaskCreation;^A;^D;^D]

Group Policies rely on a set of client/server transactions to deliver GPT files to computers within the domain for processing. A service called the Client Side Extension (CSE), running on each member computer, manages the client side of the transaction. A CSE downloads and processes only the type of GPT files it needs from Sysvol.

Targeting Group Policy
For Group Policies to work effectively, each CSE needs a way to distinguish between "GPT files I need to download," and "GPT files that don't concern me." To help clarify this distinction, Microsoft uses a term called Group Policy Object, or GPO.

A GPO is not a "thing." You can't point your finger at a certain data structure and say, "That's a GPO." Instead, GPOs distinguish one set of GPT files from another in Sysvol and in Active Directory.

In Sysvol, GPT files are stored in separate folders with names that correspond to each GPO's Globally Unique Identifier (GUID). You can see these GPO folders from any member computer within a domain by opening an Explorer window and entering this path: \\\sysvol\\Policies

Each GPO is represented in AD by a Group Policy Container (GPC) object. You can see these objects in Active Directory Users and Computers. Select View | Advanced Features from the main menu then drill down to System | Policies. See Figure 2 for an example of this view.

Figure 2. The Active Directory Users and Computers console, showing the Group Policy Container objects. (Click image to view larger version.)

You can link GPC objects to the domain object, as well as OUs and site objects. CSEs use these links to determine which GPOs contain GPT files that should be processed. You can also filter access to GPC objects based on GPC access permissions and by Windows Management Instrumentation (WMI) selection criteria.

So here's a quick synopsis of the Group Policy delivery mechanism: CSEs at member servers and desktops download GPT files from GPO folders in Sysvol based on links and filters associated with GPC objects in AD. Whew.

Policy Extension Limitations
By default, Windows 2003 has 11 CSEs that appear to encompass most operations required for centralized management, but the stock CSEs have some distinct limitations. For example, Administrative (ADM) Template policies manipulate the Registry by placing entries in four special Policy keys, two in HKEY_CURRENT_USER and two in HKEY_LOCAL_MACHINE. The Administrative Template CSE updates the entries in these volatile policy areas so the entries don't "tattoo" (or make changes to) the Registry.

This trick only works if an application developer writes the code so the app looks for Registry settings in both the volatile Policies keys and keys in the normal Registry location for that application. For example, the Prohibit New Task Creation policy only works because the developer of Task Scheduler coded the application to look for a TaskCreation entry under: \Software\Policies\Microsoft\Windows\TaskScheduler5.0.

Customize Those Group Policies
Some Microsoft applications include support for ADM template Group Policy settings. For example, Microsoft Office components, including Visio, have ADM template files available for download here.

You can also create custom ADM template files using Microsoft's ADM files as a guide. I often do this when a Microsoft application recognizes a policy entry in the Registry, but the canned ADM file doesn't include the setting. For example, Outlook 2003 has a Registry setting that forces Outlook (running in Cached Mode) to query a Global Catalog server to view the Global Address List, rather than caching a copy of the Offline Address Book. This lets desktop users see address list changes immediately, rather than waiting for the daily update to the Offline Address Book. The Outlook 2003 ADM file does not have a setting for this Registry entry. Here is a custom ADM file that makes the required entry:

CLASS USER
CATEGORY "Microsoft Office Outlook 2003 Custom Settings"
POLICY "NoOABDownload"
KEYNAME Software\Policies\Microsoft\Office\11.0\Outlook\Cached Mode
    PART "Use local cache for address lists" CHECKBOX
                        VALUENAME DownloadOAB
                        VALUEON NUMERIC 1
                        VALUEOFF NUMERIC 0
    END PART
    END POLICY
END CATEGORY
END CLASS

Third-Party Options
Most third-party applications aren't coded to take advantage of volatile Policy entries in the Registry. If you want to use Group Policies to control Registry entries for these applications, you can create custom ADM templates that change the Registry values directly. This makes a permanent change that has to be reversed before removing the policy setting. It's similar to the way classic NT system policies behaved.

However, trying to manage dozens or hundreds of applications using relatively permanent Registry hacks isn't necessarily a passport to stable and happy professional employment. Also, you might be frustrated by other built-in group policy limitations, like the inability to use Software Restriction Policies as a general purpose desktop lockdown tool and the complexity of provisioning and de-provisioning users as they move from one department to another within a large organization.

Given these drawbacks, it's not surprising that most third-party vendors have published Group Policy add-ons to fill the gap in Microsoft's offerings. For example, DesktopStandard (formerly AutoProf) has a utility called Policy Maker that is essentially a suite of Client-Side Extensions that enhance and expand the functionality of group policies. You can find that at www.desktopstandard.com. Full Armor Software also has many useful group policy extensions at www.fullarmor.com.

One of the DesktopStandard extensions is available for free. It lets you manage Registry entries without the need to create custom ADM files. It's available here.

This Registry extension, along with the remaining 20 or so DesktopStandard extensions, uses the existing plumbing in Group Policies so it doesn't require a special database, Schema modifications or other support infrastructure. It does make additions to the Group Policy Editor (shown in Figure 3) and requires additional CSEs on each client. These CSEs come in an MSI package that can be deployed with—you guessed it—Group Policies.

Figure 3. Group Policy Editor showing a few of the additional extensions installed by DesktopStandard's Policy Maker. (Click image to view larger version.)

Both Microsoft's and Policy Maker's group policy extensions use text files to communicate setting changes to CSEs. Each extension stores configuration settings in an xml file in Sysvol.

If you use Microsoft's Group Policy Management Console (GPMC)—available as a free download from here—you'll notice the GPMC doesn't display third-party extension settings like those used by DesktopStandard and Full Armor. The GPMC can't interpret the GPT files used by those extensions. Individual vendors supply their own tools, but if you just want to see Resultant Set of Policy (RSoP) information, you can use Microsoft's GPInventory tool. This is also a free download from here.

Flex Those Group Policy Muscles
Don't let either the real or perceived limitations in Microsoft's default Group Policies prevent you from taking full advantage of this technology. For just a few dollars per node, you can get highly granular control of your users, desktops and servers—with very little effort in the initial configuration.

If you have your own favorite Group Policy management tool or custom ADM file, feel free to send it along. We'll publish them on Redmondmag.com.