In-Depth

Real-World GPMC Troubleshooting

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

• By Gary Olsen
• February 01, 2005

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 Qtest.cpqcorp.net). Remember that GPOs are stored in the domain container, so all GPOs from all OUs will be exposed here.
  
  Under the Qtest.cpqcorp.net 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. (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 "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. (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. (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. (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 Qtest.cpqcorp.net\Configuration\Sites\Atlanta. The second instance is linked to Qtest.cpqcorp.net\Americas. So it appears there are two links for this GPO. Right-clicking on the Qtest.cpqcorp.net 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 (Qtest.cpqcorp.net\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. (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.