Group Policy application seems straightforward enough: Group Policy Objects (GPOs) are linked to organizational units (OUs); users and computers are in OUs. All the GPOs from a user's OU hierarchy filter down to the user. Easy enough.
Things get more complicated, though, when you remember that GPOs can be linked to a domain and to sites—meaning you'll have to open a whole new console to see what's going on. You also have to consider local security policies, which exist solely on the client computer and are applied before any domain-based policies arrive. Throw in options such as Block Policy Inheritance, No Override, and loopback processing, and it's no wonder why there's such a robust market for third-party GPO tools. However, with some patience and a methodology, you can do quite a bit of quality troubleshooting on your own.
Too many administrators try to start at the top, working their way down the hierarchy of GPOs and figuring out which ones apply. That method is time-consuming, error-prone, and just plain boring. It's a lot easier to start at the bottom—the client—and work your way up the tree.
Windows XP's Gpresult tool, for example, is a great troubleshooting tool. Run from the command line, it will tell you which groups the current user is a member of (which can affect GPO application), and give you a list of every GPO that is currently affecting the user. You'll also see the last time that GPOs were applied to the computer. What Gpresult is displaying is called resultant set of policy (RSOP). It sorts through all the blocked inheritance, no overrides, and conflicting policies to sort out exactly which policies are being applied.
By default, Gpresult doesn't show you which individual policies are applied or what they are set to; because GPOs successively overwrite one another as they are applied, you can still be left with a troubleshooting task to figure out which of the GPOs listed is responsible for the settings you're seeing. Fortunately, Gpresult has a "superverbose" mode, enabled by running
This mode not only displays which GPOs have been applied, but lists every single policy that's enabled in each GPO, allowing you to see which GPO modified which setting, and which GPO finally won out in the end. Figure 36.1 shows a portion of Gpresult's superverbose output. In this example, the GPO being applied is Local Group Policy, and you can see exactly which registry keys each setting is modifying.
Figure 36.1: Gpresult's superverbose mode.
Superverbose mode also breaks down the user and computer policies, allowing you to see every setting that is affecting the current users or their machines.
For Windows Server 2003, Microsoft introduced a sort of server-side Gpresult. It's called RSOP, and it's built into the Active Directory Users and Computers console. With this tool, you can actually view applied policies in a graphical user interface, which can be a bit easier to work with than the text-only Gpresult output.
The Windows Server 2003 version of the Active Directory Users and Computers console will work fine against Windows Server 2000 domains running Service Pack 3 (SP3) and later; however, you might need to purchase a copy of Windows Server 2003 to be able to legally use the new the new Active Directory Users and Computers console.
To launch the new tool, open the Active Directory Users and Computers console and select a user or computer. Right-click the object, and select Resultant Set of Policy (Planning) from the All Tasks menu. The RSOP wizard will step through a number of screens that allow you to specify the user or computer account location, determine whether you want to simulate the effect of a slow network link or loopback processing, choose a specific site, or modify either the user's or computer's security group memberships. The final result, which Figure 36.2 shows, is a console that looks a lot like the Group Policy Object Editor, displaying each of the policies that have been applied to the user. For each policy, you'll see which GPO was responsible for the final application of the policy, making it easy to see where you need to go to make changes.
Figure 36.2: Output from the new Active Directory Users and Computers RSOP tool.
Remembering the pecking order of GPOs can be helpful when troubleshooting. In general, the least specific policies apply first; those which are more specific to a user or computer apply last and have the opportunity to overwrite policies applied earlier. That's an important concept: The last policy applied remains effective, even if an earlier policy had a contradictory setting.
Local policies apply first; they have the advantage of living right on the computer, so they don't have to wait for the user to log on. Next comes the Active Directory (AD)-based policies, and of those, site policies apply first. Domain policies, which are more specific, apply next. Finally, OU policies apply starting at the topmost OU and working down. OUs can block policy inheritance, meaning higher-up policies will not apply from that point on down. However, higher-up policies can also be marked as No Override, meaning they'll break through Block Policy Inheritance and be inherited anyway.
If users are experiencing inconsistent GPO application, the problem is most likely a failure in Active Directory's (AD's) GPO replication process. Although AD defines GPO links in the AD database, the GPOs themselves are contained in normal files, which are replicated from domain controller to domain controller by the File Replication Service (FRS). A failure in the FRS can result in inconsistent GPOs on domain controllers, which results in users having inconsistent GPO application.
Perhaps the simplest way to verify that the GPOs have replicated consistently is to check the files themselves, located in each domain controller's SYSVOL share. Provided each domain controller has the same files, with the same date and time stamps (which are replicated by FRS, not recreated on each domain controller), then everything should be consistently applied to all users.