Share via

Troubleshooting Group Policy Problems

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This topic introduces the recommended framework for troubleshooting Group Policy.

Understanding Group Policy Processing

Before discussing Group Policy troubleshooting, you need to develop a general understanding of how Group Policy is processed at the client. Group Policy processing has two distinct phases:

  • Core Group Policy processing. When a client begins to process Group Policy, it must determine whether it can reach a domain controller, whether any GPOs have changed, and what policy settings (based on client side extension) must be processed. The core Group Policy engine performs the processing of this in the initial phase.

  • Client side extension (CSE) processing. Policy settings are grouped into different categories, such as Administrative Templates, Security Settings, Folder Redirection, Disk Quota, and Software Installation. The settings in each category require a specific CSE to process them, and each CSE has its own rules for processing settings. The core Group Policy engine calls the CSEs that are required to process the settings that apply to the client.

High level steps to troubleshoot Group Policy

  1. Check the required infrastructure. Make sure required services and components are running and configured as expected.

  2. Check the core configuration. Verify that the computer is connected to the network, joined to the domain, and has the correct system time.

  3. Check Group Policy exceptions. Verify that exceptions (scope of management) such as security filtering, WMI filters, block inheritance, enforcement , loopback processing and slow link settings are not affecting normal GPO processing.

  4. Use tools like GPResult.exe, GPOTool.exe and the GPMC to ensure that Group Policy settings that are expected to be delivered are actually delivered and that Group Policy objects on domain controllers are consistent and available.

  5. Use event logs, userenv logs, and CSE logs to analyze the problem and find a solution.

After checking network connectivity, it's recommended to first verify whether a problem can be traced to core Group Policy. Because CSEs cannot begin to work until core Group Policy processing is completed, the issues described in the topics in Fixing Core Group Policy problems apply regardless of which CSE processes the setting. Therefore, you should make sure that your problem is not a core Group Policy problem before you begin to troubleshoot the other areas listed above.

To help determine what kind of Group Policy problems you have, do the following:

  1. Generate a Group Policy Results report using GPMC.

  2. Examine the results of the report to find the answers to three questions that are used in navigating the flowchart:

    • Does Group Policy Results list the GPO as applied?

    • Is the setting listed in Group Policy Results Report?

    • Is the GPO listed in the Denied List?

  3. Compare the results of the report to the flowchart in Figure 1.

  4. Most of the results in the report map to core Group Policy problems in the flowchart. Investigate the core Group Policy problems first, even if the results of your report point to a specific CSE.

  5. If the problem persists, assess whether a CSE is involved.

  6. If you still haven't located the problem, you might need to look at log files to determine the cause.

  7. If you experience a component failure, check the userenv log and see if the Local Security Authority has logged any events.

Group Policy Troubleshooting Flowchart

For more information about running the Group Policy Results Report and interpreting the flowchart, see Fixing Core Group Policy problems.

To troubleshoot Group Policy, you need to address one or more of the following areas:

Asynchronous Processing and Logon Optimization in Windows XP

Group Policy can be applied during startup and logon (synchronous processing) or as a background task after startup or logon has completed (asynchronous processing). Changes received during periodic Group Policy refresh or in response to the gpupdate command are processed asynchronously. On computers running Windows XP, group policies received during logon are also processed asynchronously by default, so that the logon is completed more quickly.

Software Installation and scripts processing must be applied during startup or logon. Folder Redirection assigned to the user must be applied during logon. By default, Windows XP logs a user on in asynchronous mode. Group Policy is then applied in the background after the user is logged on. This results in faster logons. However, when a new GPO setting for Software Installation, Scripts, or Folder Redirection arrives at a computer running Windows XP, the user has already logged on by the time Group Policy has been evaluated. It is too late to apply the Software Installation setting. In this case a flag is set so that the next time computer is rebooted or the user logs on Group Policy will be evaluated and applied before the startup or logon is completed.

In situations where you need for users to receive software, implement folder redirection, or run new scripts in a single logon, apply a GPO with the setting Always wait for the network at computer startup and logon to the computer. This setting is located under Computer Configuration\Administrative Templates\System\Logon in the Group Policy Object Editor. For this setting to take effect, Group Policy must be refreshed or the computer restarted.

Table 1 Timing of Synchronous and Asynchronous Processing

By default, how is policy processed on the client? At Startup At Logon At Policy Refresh

Windows 2000




Windows XP Pro




Windows Server 2003





Servers do not perform asynchronous processing.

For more information about different types of client side extension problems, see the following: