Whether you’re faced with configuring 10 Windows servers and desktops or 10,000, you know that Group Policy offers valuable assistance to ensure you complete the task in time for you to head home and have a life. But you’ve probably also heard the horror stories of Group Policy’s complexity, where a sys admin made changes without understanding their consequences and paid the price in making life more difficult instead of easier. For example, ever look to modify the “Logon Locally” user right on a Group Policy Object (GPO) to remove unnecessary groups, only to discover that you did it on a GPO that applies to everyone in the domain, and now no one can log on? I can tell you that that has happened more than once.

Problems such as these are common. But you can ensure that Group Policy lives up to its potential—just by making sure you nail down a few essential concepts: how GPOs are processed, how permissions and filtering work, the difference between policies and preferences, and how to use some basic troubleshooting steps.

Understanding Group Policy Processing
How the client processes GPOs is fundamental to ensuring that everything goes according to plan. Let’s start by realizing that, despite the fact that the feature is named Group Policy, policies are processed only by computers and users. So, when you link a Group Policy Object (GPO) to an Active Directory (AD) object, the computer portion of that GPO is read only by computer objects in AD and the user portion is read only by user objects. You can use security groups to filter which users and computers are subject to a given GPO, but you can’t target GPOs at specific security groups.

Confused? Just think of it this way: Whenever you link a GPO to an object, domain, or organizational unit (OU) in AD, make sure that the user or computer that you want the GPO to apply to is beneath the linked container within the AD tree. If it isn’t, then the user or computer won’t see the GPO and can’t process it.

The process of linking a GPO is different from the process of creating it. When you created a GPO from the Microsoft Management Console Active Directory Users and Computers snap-in in Windows 2000, you linked the GPO to the AD container you were focused on in the same step. The ability to create a GPO without linking it came with the advent of Group Policy Management Console (GPMC). With GPMC, you can create GPOs without linking them, and then link them later.

You can also re-use a GPO by linking it to multiple AD containers—for example, you might link one desktop lockdown GPO to four or five OUs. A big benefit of linking a GPO to multiple containers is that any change you later make to that GPO will affect the users and computers in all the linked OUs. However, because you can link GPOs to multiple containers in AD, a given user or computer might process multiple GPOs. To know which policy applies in that case, you need to know the answer to a couple of questions: How doesGroup Policy know which GPO to process first, and which settings ultimately apply if the different GPOs have different settings?

Group Policy processing follows a specific order. The local GPO on a given computer is processed first, followed by GPOs linked to AD sites, then GPOs linked to an AD domain, and finally those linked to OUs. Because OUlinked GPOs are processed last, they “win” the contest that determines which GPO’s settings actually apply to the computer or user. For example, if a domain-linked GPO removes the Run option from the Windows Start menu and an OU-linked GPO adds the Run option back to the menu, the OU-linked GPO will apply because the user processes it second, and the Run option will appear in the user’s Start menu.

Group Policy uses both foreground and background processing. For a computer, foreground processing happens when the computer initially starts up, typically—but not always—before the user sees a logon dialog. For a user, foreground processing occurs when the user logs on, typically—but again not always—before the user sees his or her desktop. Background processing takes place periodically to refresh Group Policy. On domain controllers (DCs), background processing for computers and users occurs every five minutes. On member servers and workstations, it occurs by default every 90 to 120 minutes. Although Group Policy is refreshed automatically during background processing, not all policy areas run during background processing. For example, neither software installation nor Folder Redirection policy runs in the background.

Group Policy Permissions and Filtering
As I mentioned earlier, GPOs are processed only by users and computers, but they can be filtered by security groups that contain user or computer accounts. By default, when you create a GPO, the Authenticated Users group receives Read and Apply permissions to that GPO, which gives all users and all computers the ability to see, and thus to process, the GPO. But you might sometimes want only a subset of users or computers in a given OU to process a GPO. In that case, you can use security groups to filter the GPO. That process is easily done by using a must-have tool: Group Policy Management Console (GPMC), which ships with Windows Vista and can be downloaded by searching in System Tools at www.microsoft .com/downloads.

As Figure 1 shows, you can modify the security filtering on a given GPO by simply adding and removing groups from the Security Filtering section in GPMC.

Let’s say, for example, that you have a GPO linked to the Marketing OU, which contains 200 user accounts. You want to deliver some user policy settings to a subset of those users—the users who are also members of the Marketing Special Projects group. Using GPMC, this task is easy. Start GPMC by entering

gpmc.msc

in the Run dialog box on the Start menu. Under the Group Policy Objects node in the tree pane, select the GPO you want to filter. Remove the Authenticated Users group from the GPO because that group lets all users and computers process that policy. To do so, highlight that group in the Security Filtering dialog box and press the Remove button. Then add the Marketing Special Projects group to the security filtering list by clicking the Add button and entering or searching for the “Marketing Special Projects” group in your AD domain. GPMC takes care of granting the Read Group Policy and Apply Group Policy permissions on that GPO.

Security filtering permissions control which computers and users can process a GPO; there are also security permissions that control who can edit that GPO. You can see those security permissions by highlighting a GPO in GPMC and selecting the Delegation tab, as in Figure 2.

The Delegation tab is a bit confusing because it shows the security filtering permissions from the previous Security Filtering dialog box, as well as the permissions to edit or modify the GPO. In fact, you can grant both kinds of access here: granting permission to process a GPO here (as well as from Security Filtering) and also controlling who can edit a GPO. Furthermore, the Advanced button that you see at the bottom of the screen is the only place in GPMC where you can set Deny access to the GPO. Remember that security permissions can either allow or deny access—and both types of Access Control Entries (ACEs) are valid for GPO permissions. However, by default, the GPMC interface lets you set only allow permissions. So, for example, if you need to deny Read Group Policy and Apply Group Policy permissions to a group of users or computers that you want to exclude from processing a GPO, you’d need to do that by clicking the Advanced button, which brings up the familiar Access Control List editor that you use to set permissions on files or in AD.

The final type of filtering that you have access to in Vista, Windows Server 2003, and Windows XP is the Windows Management Instrumentation (WMI) filter. WMI is a set of instrumentation in Windows that you can leverage to filter GPO processing. For example, let’s say you want a GPO to apply only to XP systems. Using GPMC, you can create a WMI filter by right-clicking the WMI Filters node in the tree pane and selecting New. A WMI filter must take the form of a WMI query. (For more information about WMI filters, see technet2.microsoft.com/WindowsServer/en/library/dfba1dc6-6848-4ed8-96da-f4241c1acfbd1033.mspx; for more information about WMI queries, see “Sesame Script: WMI Query Language,” www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx.)

You can link just one WMI filter to a given GPO. If the query that’s specified in the filter evaluates to True when the GPO is read, the GPO is applied. The evaluation of a WMI query takes place on the client computer that’s processing the GPO. It interrogates its own local WMI repository to see if the query evaluates to true or false. If the query evaluates to False, the GPO is denied to the user or computer. Whether the WMI filter applies to a user or a computer depends upon the query. For example, if the query asks whether the computer is running XP, that’s a computer-specific question, and if the computer is running XP, the GPO will apply whether the user is logged on or not. However, if the query asks whether “Joe Smith” is the currently logged on user on the computer, the GPO will apply only when Joe Smith is actually logged on.

Policies vs. Preferences
Perhaps the most popular area of Group Policy is Administrative Templates, or registry policy. This policy area lets you control many aspects of your Windows systems. The best part of registry policy is that it no longer “tattoos” or gets stuck in, the registry when the policy no longer applies, as it did in NT 4.0 system policy. What the end of tattooing means is this: Let’s say you enable (or disable) a registry policy item in a GPO and apply it to a user or computer, then remove that GPO or security filter it away from the user or computer. During the next foreground or background processing cycle, that policy setting will automatically be removed, rather than being stuck in the registry until you explicitly delete.

Behind the scenes, this removal process works this way because Microsoft has specifically set aside four special registry keys where all policies are written, and they are removed when they no longer apply. There are two keys for computer registry policy:

HKEY_LOCAL_MACHINE\Software\Policies
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

and two for user registry policy:

HKEY_CURRENT_USER\Software\Policies
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

As long as registry policy settings write to one of these four keys, they will not tattoo the registry when the GPO is removed. Of course, to write policies to these four keys, the underlying applications or components in Windows had to be written to look in these keys for policy settings. However, you can still create custom ADM (or ADMX in Vista) template files that can write to any keys in the registry (under HKEY_ LOCAL_MACHINE or HKEY_CURRENT_ USER). Policies that do this are called preferences and will indeed tattoo the registry, even if the GPO containing them is removed. So, if you need to undo a preference that was enabled, you would need to disable it in the Group Policy Editor (GPE) interface or manually delete the registry value.

Now this tattooing stuff is most commonly associated with registry policy, but other policy areas exhibit this behavior as well. For example, security policy effectively tattoos a system when it’s applied. That is, if you set user rights assignments on a given system, for example, (using the policy found in Computer Configuration\Windows Settings\Security Settings Local Policies\User rights assignment), and then you remove the GPO that applied those settings from where the computer was processing it, then those user rights assignments remain until you explicitly change them. This is important to understand because each policy area behaves a little differently with respect to their tattooing of your systems. In some cases, such as Folder Redirection or Software Installation policy, you have to tell the policy specifically what to do when the GPO no longer applies, as Figure 3 shows. Understanding the tattooing nature of each policy area will help you know how to manage the application and removal policy better.

Troubleshooting Group Policy
Because Group Policy is complex, sometimes it doesn’t work the way you expect. You might have inadvertently misconfigured something, or it might not work because something is simply broken. Group Policy processing requires several elements to work in harmony. Your AD infrastructure must be healthy, your workstations must be healthy, and the various settings that you configure must be compatible with the applications running on your desktops.

When any of that is out of whack, you might see Group Policy processing failures. When failure happens, how do you find out what is amiss? The first step is to create a Resultant Set of Policy (RSoP) report on the problem computer. RSoP is gathered using the Group Policy Results Wizard within GPMC. You can also use the command-line utility gpresult.exe that comes with Vista, Windows 2003, and XP, to generate an RSoP report. The easiest thing to do is to run the Group Policy Results wizard from GPMC. The wizard lets you pick a local or remote computer to connect to, then pick a user who has logged onto that computer.The wizard then connects to that remote computer and gathers information about Group Policy processing that occurred during the last processing cycle. The most useful part of that report is the Summary tab, which you can see in Figure 4.

The summary tab shows you which GPOs were applied to the computer and user, and most importantly, which GPOs were denied and why. In the Component Status section, the report can give you information about whether any specific portions of Group Policy processing failed and why. The Group Policy Infrastructure item you see in that section tells you whether the basic setup of Group Policy processing succeeded. If this step fails, then it usually indicates some infrastructure problem that’s preventing any Group Policy processing from occurring. If the error occurs in one of the so-called client-side extensions that implement the various policy areas, then you might be able to isolate the problem by using the error messages provided. If you want to see which individual policy settings are being delivered to the computer or user, then you can view the Settings tab in the Group Policy results report to see which settings “won” and are being processed. However note that just because the RSoP report says the setting has been applied doesn’t actually guarantee that the setting was successfully made. It’s best to sometimes check the underlying setting, be it a registry value or security setting, to be sure.

You can also look in the Application event log on a given Windows system (note that Vista puts Group Policy events into the System event log and the Group Policy Operations log) to see additional errors related to Group Policy processing.

With Knowledge Comes Power
Group Policy is complex and powerful. By understanding how Group Policy is processed, you can get a better handle on using its power. Remember that Group Policy is processed in order of local GPO, AD site, domain, then OU (sometimes referred to as LSDOU) and that typically, the “last writer wins” when there are conflicting settings. Policies and preferences can affect how policy stays on your systems when the GPO is removed, and making explicit choices about using each is important. The registry policies delivered by Microsoft in their standard ADM and ADMX files don’t typically tattoo the registry, but any custom ADMX files you use might. In addition, other policy areas such as security do tattoo your systems and must be explicitly “un-done”, while some policy areas must be told to be undone when they no longer apply. Finally, if policy is still not doing what you expect, fall back to the Group Policy Results wizard in GPMC to tell you what’s actually going on with your problem system and to point you toward a solution.