Group Policy: Troubleshooting Overview

This article describes the high-level steps to troubleshoot issues that you might have deploying a Group Policy to target machines or target users. For a rough understanding what Group Policy is and what it tries to do, seehttp://technet.microsoft.com/en-us/library/cc725828(WS.10).aspx 

Table of Contents

• Introduction
  • Group Policy Core Processing
  • Group Policy CSE Processing
• Basic verification
• Troubleshooting Steps
• Related Topics

Introduction

Group Policy processing happens in two phases:

1. Group Policy Core Processing
2. Group Policy CSE Processing

Group Policy Core Processing

Where the client enumerates all Group Policies and settings that need to be applied. It reaches out to the Domain Controller to access Active Directory and SYSVOL in order to gather required data for policy processing.

Group Policy CSE Processing

When the Client Side Extensions (CSEs), the little pieces of software in Windows make sure that settings configured by administrators get enforced on the operating system to reflect them.

Basic verification

Before Group Policy can be troubleshooted, basic verification of functionality of Active Directory should be performed and that the client fulfills Active Directory requirements.

• The client is joined to the domain controller.
• The client has Domain Controllers configured as its primary and secondary source for DNS queries in the properties of the network adapter.
• The client can resolve the domain name, for example “contoso.com” using the command line tool nslookup, by typing “nslookup contoso.com” in cmd.exe.
• The client can ping the domain name using the command line tool ping, by typing “ping contoso.com”.
• The client can access the SYSVOL share by typing \\contoso.com\SYSVOL in explorer.

Troubleshooting Steps

• On the target client, can you open gpresult.exe form the command line and verify, that the Group Policy is there and listed under “Applied Group Policy”?
  • If not, is the Group Policy listed under “Not applied”?
    • Is the reason for “Not applied that it’s “Empty”? If so, you probably have linked a User Configuration GPO to an OU with computers or the other way around. Link the GPO to the corresponding, correct OU.
    • Is the reason for “Not applied” that it’s “Security Filtering”? If so, make sure you have the correct objects (Authenticated Users) in “Security Filtering” in GPMC. Target objects need at least “Read” and “Apply Group Policy” permissions.
    • Is the reason for “Not applied” that it’s “WMI Filtering”? If so, make sure you configure the WMI filter accordingly so that the GPO works with the WMI filter.
    • Is the reason for “Not applied” that it’s “Blocked SOM”? If so, make sure if you have configured the "Block Inheritance" option on any of the parent/child OU where resides your user or computer account.
    • If the Group Policy isn’t listed in gpresult.exe at all, verify the scope of management by verifying that either the user or computer object in Active Directory reside in the OU tree the Group Policy is linked to in GPMC.
    • If the group policy is new and not listed, or an older version is applied, verify SYSVOL of the logonserver is up-to-date. If not, verify SYSVOL replication (DFSR).
• On the target client, is the Group Policy setting shown in “rsop.msc”, called from the command line?
                     
• If not, verify that the scope of management is correct and that the target objects (either computer or user object in Active Directory) are in the OU tree you linked the policy in GPMC to.
• If not, is there an error sign in one of the nodes in rsop.msc shown?
  • A yellow warning sign?
  • A red circle with a red cross?
  • If so, right-click the corresponding root node and select “Properties” from the context menu. It’ll show detailed information on the problem and error.

• On the client, does Group Policy processing report any errors in the Eventlog? The “System” log in Windows XP and Server 2003 provides information on this, for Windows Vista and newer operating systems, the “Group Policy\Operational” log in “Applications and Service Logs\Microsoft\Windows”.                        
  • In case you see Event ID 1058, follow http://social.technet.microsoft.com/wiki/contents/articles/event-id-1058-group-policy-preprocessing-networking.aspx
  • In case you see Event ID 1030, follow http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1030&EvtSrc=Userenv&LCID=1033 

• On the client, Enable Group Policy Processing verbose logging according to KB http://support.microsoft.com/kb/944043/ (see the last paragraph) for Windows Vista and newer operating systems and KB http://support.microsoft.com/kb/221833  and earlier operating system versions. Re-run Group Policy processing, by using the “gpupdate” command. Review the log file in %windir%\system32\UserMode.
• If the problem may be CSE-related, rather than Core processing related, review the following article to enable CSE logging: http://technet.microsoft.com/de-de/library/cc775423(WS.10).aspx 
• For Group Policy Preference CSE logging, which can be enabled with the Group Policy settings found in “Computer Configuration\Administrative Templates\System\Group Policy\Logging and Tracing”. Enable the corresponding Group Policy setting for the GP Preference CSE in question.

Related Topics

• “Group Policy Troubleshooting”, http://technet.microsoft.com/en-us/library/cc736961(WS.10).aspx 
• “Interpreting Userenv log files”, http://technet.microsoft.com/de-de/library/cc786775(WS.10).aspx