Real-World GPMC Troubleshooting

The Group Policy Management Console can be a powerful troubleshooting too—if you know how to use it.

With nearly 1,000 settings available in Windows Server 2003 Group Policy, troubleshooting is a burdensome and often frustrating experience for administrators. The most frequent problem—by far—for group policy application is failure of the policy to work as expected.

So Many Policies, So Little Time
Microsoft gave us some rudimentary tools in Windows 2000 Server to help, including:

  • Gpotool
  • Userenv.log
  • Gpresult

As good as these tools are, there are some serious deficiencies. For instance, debugging a GPO failure involves getting the user to log on to the computer with his account; running Gpresult.exe; saving it to a file; then passing the file to the administrator for analysis. Multiplying that process several times during testing quickly becomes frustrating for everyone concerned.

Also, because there was no way to dump GPO settings to an external file, determining the configuration settings required editing the GPO and picking through the settings to see what was enabled. This was a time-consuming problem for remote support staff. In addition, managing GPOs across multiple domains required bringing up multiple instances of the Microsoft Management Console (MMC) snap-in, editing each GPO independently and trying to keep track of it all.

A Better Troubleshooter
Fortunately, Microsoft felt our pain and gave us the Group Policy Management Console (GPMC). The GPMC has addressed the limitations of previous tools and gone beyond them, advancing the debugging of Group Policy in general. Among the things the GPMC can do:

  • It allows you to see and manage all the GPOs in all domains in the forest, from a single console.
  • It allows you to run the powerful Group Policy application-troubleshooting tool Gpresult for any user logging on to any computer. This doesn't require the user's password or contacting the computer. It's an accurate simulation that considerably shortens Gpresult analysis.
  • It can dump Gpresult output to an HTML file, which can be viewed outside of GPMC.
  • It can dump the GPO settings to an HTML file. This allows you to see security settings, Registry settings and values such as the "no override" switch and Block Inheritance.

Let's look at some examples of using GPMC to solve typical "Why doesn't this policy (or some setting) apply?" problems.

The first step is to define the scope of the problem: Does this policy fail on all users or computers for which it's intended? If not, what do the failures have in common? Perhaps they're all in a common security group or at the same site.

GPMC to the Rescue
Now let's get down to the nitty-gritty and see how GPMC can solve some common group policy application problems. The first step is to run Gpresult and save, as HTML files, GPOs and Gpresult for one or more users with the problem.

To save the GPO:

  • Open the GPMC console. As shown in Figure 1, expand the Forest icon, followed by the Domains icon, then expand the icon of the domain in which the GPO lives (in the case of Figure 1, this is Remember that GPOs are stored in the domain container, so all GPOs from all OUs will be exposed here.

    Under the icon in Figure 1, you can see all the domain level GPOs; but if you expand the Group Policy Objects icon, all the GPOs in the domain, including the ones linked to OUs, are exposed. Likewise, you can expand the OUs to see the GPO at each OU.

  • Right-click on any icon for the desired GPO and select Save Report.
Figure 1. The Group Policy Management Console, showing inheritance for the Americas Organizational Unit.
Figure 1. The Group Policy Management Console, showing inheritance for the Americas Organizational Unit. (Click image to view larger version.)

To get the Gpresult, go to the "Group Policy Results" icon in the GPMC snap-in:

  • Right-click on the Group Policy Results icon and select the Group Policy Results Wizard.
  • The Wizard will prompt you first for a computer, then a user. This allows you to have GPMC test any user logging onto any computer and get the Gpresult output in HTML format. Again, this is done without having the user actually log on to the computer.
  • To save the Gpresult, go to the Group Policy Results icon, right-click and select Save Report.

Now that we have the HTML files, let's see how we can use them. I've created several GPOs in HP's test forest, Qtest, and put different filters and restrictions on them. The user account is olseng, and olseng is a member of the Americas OU. He's having trouble getting some of the policies. The policies assigned to Americas include:

  • Americas Desktop Basic: This is a user policy defining desktop restrictions for all users in Americas OU.
  • Computer Basic: A policy that applies only to computers.
  • Region Admin Policy: A policy that applies to system admins in the region.
  • SAFER: A Software Restriction Policy that applies to all users in the OU.

Problem No. 1
The initial problems facing olseng are that his toolbar is locked and his username removed from the Start menu. Both settings are disabled in the Americas Desktop Basic policy, meaning the toolbar should be unlocked and the username displayed in the start menu for the logoff feature (see Figure 2). Without GPMC, the admin would have to open the Users and Computers snap-in; find the Americas OU\Properties\Group Policy tab; double-click on the Americas Desktop Basic link; then drill down through the policy settings (which may take a while if you don't remember exactly where these settings are).

Figure 2. An HTML representation of the Americas Desktop Basic policy.  The
Figure 2. An HTML representation of the Americas Desktop Basic policy. The "Disabled" listing reveals why the policies aren't being applied. (Click image to view larger version.)

With GPMC, simply save the Americas Desktop Basic policy as an HTML file, then open it, as shown in Figure 2. Under User Configuration\ Administrative Templates, only the sections of the template with Enabled or Disabled settings are shown. The figure shows an expanded Start Menu and Taskbar at the bottom, including the two settings in question here—both are disabled. Very quickly we can see the settings, which is a great help. We've verified the settings are disabled as expected, but they haven't been applied to the olseng account. This could be due to a) a higher-level GPO overriding the policy, b) the olseng account being filtered from using it or c) the olseng account is not in the Americas OU.

Figure 3 shows the Gpresult report for the olseng account. Here we just clicked on the olseng icon in the GPMC console, though we could have saved it as HTML and looked at it that way. On the right pane in the figure, we've drilled down through the User Configuration Summary and expanded the Applied GPOs and Denied GPOs.

This useful option lets you see not only a complete list of applied GPOs, but also the ones denied—and the reasons they're denied. In this case, the Default Domain Policy, Domain Desktop Policy and the Americas Desktop Policy are all applied. So you know the settings in the Americas Desktop Policy are correct, and that the policy is applied to olseng.

Going back to Figure 1 shows all GPOs in the Americas OU, and also the order of precedence and link status. Note that the Domain Desktop Policy is listed as the highest priority and "Enforced," meaning the "no override" option is selected. Saving the Domain Desktop policy as an HTML file and searching it for these two settings revealed that they were both enabled at this level. Since it has highest priority and is enforced, it overrides the Americas Desktop Policy and explains why olseng didn't get the settings.

Problem No. 2
Another problem: Although olseng is a member of the Region Admin staff, he's not getting the Region Admin or SAFER policies. A little exploration through the Gpresult report from Figure 3 finds that the SAFER policy isn't listed in the Applied GPOs or Denied GPOs sections. There is a policy in the Denied GPOs list, identified by its Globally Unique Identifier (GUID), with the reason listed as "Disabled Link."

Figure 3. The report generated from running Gpresult for a fictional user.  Displayed are the GPOs the user was denied, along with an explanation of why.
Figure 3. The report generated from running Gpresult for a fictional user. Displayed are the GPOs the user was denied, along with an explanation of why. (Click image to view larger version.)

Figure 4 shows the result from right-clicking on the SAFER policy in GPMC, then clicking the Details tab. Note the GUID of the SAFER policy shown here is the same as the GUID in the Denied GPOs list; thus, SAFER is being denied because it's disabled.

(Note in Figure 4 that GPO Status is "Enabled." This isn't the link status, but rather the status of the settings.)

Figure 4. Drilling down into policy specifics in the GPMC. In this case, it's the Details  property of the SAFER Group Policy.
Figure 4. Drilling down into policy specifics in the GPMC. In this case, it's the Details property of the SAFER Group Policy. (Click image to view larger version.)

Clicking on the "Scope" tab in the GPMC for SAFER (see Figure 5) confirms the link to the Americas OU is disabled but the link to another OU—US Users—is enabled. The problem can be corrected in the snap-in by right-clicking on the Americas entry, then selecting "Link Enabled."

After enabling the link, the SAFER policy name will show up in olseng's Gpresult report. First, though, you'll have to run GPUpdate to refresh the policy on the DC and the client, and refresh the report by right-clicking on the olseng icon under Group Policy Reports in the GPMC and selecting Rerun Query.

Figure 5. The Scope tab of the group policy SAFER shows that there are  disabled links.
Figure 5. The Scope tab of the group policy SAFER shows that there are disabled links. (Click image to view larger version.)

Problem No. 3
Now let's see why olseng isn't getting the Region Admin Policy. Figure 3 shows that the Region Admin Policy is listed twice. Let's start at the top: The first one lists the reason for denial as "Blocked SOM." SOM, or Scope of Management, refers to the site, domain or OU and includes actions such as blocking inheritance.

The next instance says it's blocked due to security filtering. Note that the Link Location shows the first instance of Region Admin Policy linked to\Configuration\Sites\Atlanta. The second instance is linked to\Americas. So it appears there are two links for this GPO. Right-clicking on the icon brings up an option for Block Inheritance; in this case, it's checked. The problem, therefore, was that the Region Admin Policy was linked to the site (\Configuration\Sites\Atlanta), but the domain had blocked inheritance. That's easy enough to fix by deleting the link.

(Note: Block Inheritance is set by default at the domain level.)

Figure 6. A close look at the Security Filtering section of the Region Admin group  policy shows which users the policy will be applied to.
Figure 6. A close look at the Security Filtering section of the Region Admin group policy shows which users the policy will be applied to. (Click image to view larger version.)

Next up is the link to the Americas OU. The denial in this case is due to security filtering. Going back to the policy listed on the left pane of GPMC, clicking the Region Admin Policy and then the Scope tab brings the result shown in Figure 6. The Security Filtering section in the middle of the right pane lists three users. Since the Authenticated Users group is not in the list, the policy only applies to these three users, and user olseng is not on the list. That's why the policy was denied.

These examples are just a taste of what the GPMC can do. There's more information in the online version of this article, and you can find lots more on the Web. Just remember that the GPMC is your friend. Use it.

More Information


GPMC Shortcomings
As great as GPMC is, it has a serious restriction in that it cannot perform Resultant Set of Policy (RSoP) operations on Windows 2000 clients. You can only run the Gpresult feature against a Windows 2003 or XP machine, and GPMC itself can only run on a Windows 2003 or XP computer.

Once you install GPMC, the old way of opening group policy via the Active Directory Users and Computers snap-in is disabled. You have to uninstall GPMC to get that old feature back. This is a small price to pay, however, since GPMC can do so much more than using the hordes of snap-ins.

Gary Olsen

A Brief History of Group Policy Troubleshooting
Group policy, first introduced by Microsoft in Windows 2000 Server, was a huge step forward in manageability of users and computers. But it was far from perfect, and troubleshooting could be a nightmare. Microsoft gave us some rudimentary tools in Windows 2000 to help answer this problem, including:

  • Gpotool
  • Userenv.log
  • Gpresult

Note: Gpotool, Userenv.log and Gpresult output are included in the DirSvcs version of MPSReports (see for details.)

Gpotool is a resource kit utility that runs on a domain controller and checks the integrity of the GPOs on the DC. It checks to see if the sysvol version is the same as the AD version of the GPO, and flags version mismatches and other inconsistencies. It does a nice job of mapping the GPO GUID to the friendly name. It's a decent tool, but I've never had a case where it really helped me debug a GPO problem.

Userenv.log is a log of all group policy- and profile-related activity taking place in the user's environment. This log is found on every Win2K, Windows 2003 Server and Windows XP computer, and is located in the %systemroot%\debug directory. It's a very useful tool, and not terribly difficult to read and interpret. It's important to enable verbose logging per Microsoft Knowledge Base article 221833, as the vanilla version is of little use in debugging group policy problems.

Gpresult.exe was first provided as a Win2K Resource Kit utility. A very useful group policy application troubleshooting tool, it had a large drawback: since it's a reskit utility, the reskit or a copy of Gpresult.exe has to be copied on every computer that needs it. This is a problem when trying to diagnose a problem remotely.

An additional shortcoming with the Win2K version of Gpresult is its inability to enumerate security settings. If a policy designed to set the password length isn't working correctly, for example, it's impossible to see what setting is getting applied from the GPO except through labor-intensive workarounds. Gpresult simply lists the GPO from which it received the security settings, far from what you need. Also, it doesn't report if a user or computer is denied or allowed GPO access through filtering.

— Gary Olsen

New! Improved!
Windows 2003 and Windows XP both include a new improved version of Gpresult.exe, built in to the OS. This means, among other things, that there's no more copying it from a Web site or via e-mail. This version has several powerful features that the previous version didn't have:

  • RSoP results. Resultant Set of Policy evaluates the resultant Registry settings applied to the user or computer as a result of all the applicable GPOs being applied. RSoP is at the heart of Group Policy. A sample Gpresult output shows a Registry setting enabled for the Marketing Users Policy for a user:

Resultant Set Of Policies for User:

    Administrative Templates
      GPO: Marketing Users Policy
        Setting: Software\Policies\Microsoft\Messenger\Client\{83D4679F-B6D7-11D2-BF36-00C04FB90A03}\_Default
        State:   Enabled

  • GPO Filtering. Gpresult will show if the user or computer is being denied access to a GPO, as you can see in the following example. This wasn't possible in the Win2K version of Gpresult. Here's an example.

The following GPOs were not applied because they were filtered out
    Local Group Policy
      Filtering: Not Applied (Empty)
       InetLock Policy
       Filtering: Access Denied (Security Filtering)

  • Enumerated security settings. Gpresult lists all settings applied and effective on a computer, such as the example in Figure 1. Here we can see the values defined for these settings—a great help in seeing exactly what's getting applied at the client. Security settings such as password length, account lockout settings, etc. are enumerated:

Account Policies
      GPO: Default Domain Policy
        Policy:       PasswordHistorySize
         Computer Setting: 6

In addition, it contains other information from the previous version, such as:

  • Distinguished Name (DN) of the user and computer. This helps determine the OU and domain containing the user and computer account.
  • Security group membership. Helpful in determining if a GPO filter applies.
  • Registry settings (using verbose mode). Identifies policy settings applied to a user or computer.
  • GPOs applied. Names of the GPOs applied to a user or computer. This is very helpful in seeing if the policy itself is being applied, or if, perhaps, a setting is just not working.
  • Group Policy Extension applications. GPEs such as security, scripts, folder redirection and EFS settings are detailed.

The Windows 2003/XP version of Gpresult can be run in a Win2K domain, but must be run from an XP client or Windows 2003 server.

(Note: Remember that Windows 2003 uses the command gpupdate.exe to refresh policies after a new change to the GPO. Under Win2K, the command was Secedit/RefreshPolicy. )

Gary Olsen

Problem Definition
Common GPO application problems include:

  • Policies applied to the wrong domain or Organizational Unit (OU). Remember that the user or computer only gets a policy where the actual account lives. Take the user account Caroline, for instance. This account exists in the USA OU and is a member of a group in the Atlanta OU. If there's a policy called Lockdown Policy in the Atlanta OU, it will not apply to Caroline since she'll only get policies from the USA OU (and above in the OU structure).
  • A policy is applied but the settings don't work. This could be caused by a number of issues:
    • The policy setting is trumped by a lower-level GPO (remember the LSDOU processing order: Local/Site/Domain/OU, and that the last writer wins.) Domain settings, for instance, can be overwritten by OU settings.
    • The lower-level policy is trumped by a higher level policy with the "no override" flag set.
    • A higher-level (domain or parent OU) policy setting doesn't apply to the lower-level OU users or computers because the OU has the "block inheritance" flag set.
      (Note: If the "no override" rule is set at the parent container (domain or OU) and "block inheritance"is set at the child OU, "no override" takes precedence.)
  • A policy isn't applied due to filtering.
    • Access Control List (ACL) filtering allows you to deny or allow certain users or groups from getting a policy.
  • A policy isn't applied because it's disabled. It's possible to disable the policy without deleting the link. You can also disable just the user configuration or   computer configuration settings.
  • Settings may not apply if multiple GPOs are applied at the domain or OU level and ordered incorrectly. Remember that "last writer wins," and with multiple GPOs you have to pay attention to the ordering to see who overwrites whom.
  • A policy may not apply because it hasn't been replicated. Each domain controller (DC) holds its copy of the policies in the \%windir%\sysvol\ policies directory. If AD or FRS replication fails, policy changes may not be applied to a user's authenticating DC and the user won't get it. Replication Monitor is a good way to determine if a policy has been replicated, and Gpresult can show when the policy was last applied. Also look for the Event 1704 Information events (source: SCECLI) on the DC and the client. Gpresult will also list the settings applied so you can see the end result (make sure to use the "/v" flag).

— Gary Olsen


comments powered by Disqus

Subscribe on YouTube