Sometimes the application of Group Policy doesn't occur as expected. For example, a Group Policy object might apply unexpected restrictions to a computer or user. This lesson outlines a methodology you can use to troubleshoot Group Policy application and locate the undesired Group Policy object.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
One common reason that Group Policy application doesn't always work as expected is that there's been a misapplication of the Block Policy Inheritance or No Override attributes to Group Policy. Take the following steps to troubleshoot Group Policy application:
Using Gpresult
The Gpresult utility shows which Group Policy objects were applied to a user or a computer. The Gpresult utility uses the following parameters:
gpresult [/V] [/S] [/C | /U] [/?]where:
/V runs Gpresult in verbose mode
/S runs Gpresult in super verbose mode
/C displays only the Group Policy objects applied to the computer
/U displays only the Group Policy objects applied to the user
In addition to showing which Group Policy objects were applied, the Gpresult utility also lists all group memberships of the user or computer being analyzed. The group membership information is useful in troubleshooting security group filtering, as demonstrated in Figure 7.10.
Figure 7.10 Gpresult output for a user named Michael
Use the decision matrix shown in Table 7.3 to troubleshoot Group Policy application.
Table 7.3 Troubleshooting Group Policy Application
To | Do the Following |
---|---|
Determine all possible locations where Group Policy objects may be defined | Inspect the Active Directory structure to determine the site, domain, and OUs that could have Group Policy applied to the user or computer. |
Determine whether the Group Policy that was applied is a user or computer configuration setting | Use the Gpresult utility from the Microsoft Windows 2000 Server Resource Kit to determine which Group Policies were applied to the computer or user. |
Determine why a higher-level Group Policy isn't applied | Look for Block Policy Inheritance settings or conflicting settings at an OU closer to the user or computer object than where the higher-level Group Policy is defined. Alternatively, determine if any Group Policy filtering has been configured. If the affected computer or user isn't a member of a security group that has the Read and Apply Group Policy permissions assigned, the Group Policy object won't be applied. |
Determine why a lower-level Group Policy isn't applied | Look for a Group Policy object with the No Override attribute set at an OU, domain, or site higher in the hierarchy. As an alternative, determine if any Group Policy filtering has been configured. If the affected computer or user isn't a member of a security group that has the Read and Apply Group Policy permissions assigned, the Group Policy object won't be applied. |
Determine why a Group Policy doesn't apply to all computers or users within a site, domain, or OU | Inspect the Group Policy object's Security tab to determine which security groups have been assigned the Read Group Policy and Apply Group Policy permissions. To apply Group Policy, you must assign both permissions. |
As a member of the Accounting department, Don Funk should have the accounting software assigned to his computer and should have had Office assigned to his user account. Because the accounting software is working as expected, there's no reason to troubleshoot the associated Group Policy objects. Assuming that Don is now a member of the Accounting department in Toronto, perform the following tasks:
When Group Policy application doesn't take place as expected, you must have a methodology for determining the reason. Using the Gpresult utility and inspecting the Active Directory hierarchy allows you to determine where Group Policy objects have been applied to a user or computer. Once you identify where Group Policy objects can be applied, you can identify which Group Policy objects are applied.