Article Summary: This article provides information on troubleshooting Group Policy processing errors on Windows machines in an Active Directory domain.
Members of an Active Directory (AD) domain can experience problems applying Group Policy for a number of reasons. This article discusses some of the more common ones and provides guidelines for troubleshooting the underlying issues.
The first step in troubleshooting these issues should be to determine their extent. If only one machine is unable to process Group Policy, the problem likely stems from a malfunction or misconfiguration of that machine rather than a problem with a domain controller (DC) or AD itself. In the case of a machine-specific problem, it may be useful to run gpupdate /force on the affected machine before troubleshooting further, to make sure the failure wasn't caused by a temporary network issue that has since been resolved.
When a machine is unable to process Group Policy, it will typically generate one or more Userenv errors in its Application log. Common event ID numbers include 1030, 1053, 1054, and 1058. The descriptions of the particular errors on an affected machine should give some idea of the underlying issue.
Perhaps the most common cause of Group Policy failures (and numerous other issues in AD) is a name-resolution problem: a client tries to update its Group Policy settings but can't determine the name of a DC in the domain, can't resolve a DC's name to an IP address, or resolves that name to the address of a machine that isn't really a DC and may not even exist. If the Userenv errors on an affected machine include the phrase "Network path not found" or "Cannot locate a domain controller," DNS may be to blame. The following are a few tips for troubleshooting this type of issue:
Secure Channel Issues
This type of issue generally occurs when a domain-joined machine has been offline for long enough that the password of its computer account in AD no longer matches the machine's locally cached copy of that password, but it can arise in other situations as well. A secure-channel problem will prevent a machine from authenticating with a DC and will typically manifest itself as an "Access denied" error whenever that machine attempts to access domain resources, including Group Policy updates. Of course, not all "Access denied" events are due to secure-channel issues, but if an affected machine has Userenv errors in its Application log with "Access denied" in their description, the secure channel is worth testing.
Problems with SYSVOL
Group Policy files are stored in the SYSVOL share on all DCs in the domain - specifically, in subfolders of the SYSVOL\domain\Policies folder. If the SYSVOL share is not present on a DC, this typically indicates a problem with either the File Replication Service (FRS) or Distributed File System Replication (DFS-R), depending on which one is being used to replicate SYSVOL.
This article can't provide an exhaustive guide for troubleshooting FRS or DFS-R, but the following links may be useful:
By default, if the time on an affected machine is different from the time on a DC by more than five minutes when corrected for time-zone differences, that machine will be unable to authenticate with the DC and will therefore be unable to process Group Policy. Domain members should be configured to synchronize their clocks with a DC, and DCs in turn should synchronize their clocks with the DC holding the PDC Emulator role. For this reason, the PDC Emulator should be the only machine in a domain configured to synchronize with an external source, such as a public NTP server.
More information on configuring the Windows Time service is available here.
Missing Group Policy Files
One or more Group Policy files may have been deleted from their storage location in SYSVOL. The easiest way to check this is to open SYSVOL\domain\Policies in Windows Explorer and check for the specific files mentioned in the Userenv errors that appear on affected machines. The files for each GPO are located in a subfolder of the Policies folder. Each subfolder is named after the GUID of the GPO whose files it contains.
If policy files are found to be missing from all DCs, they can be restored from a backup. If the Default Domain Policy or Default Domain Controller Policy files are missing and no backup is available, the dcgpofix command can restore both policies to their default settings. More information about dcgpofix can be found in this article.
Article ID: SLN163816
Last Date Modified: 09/05/2014 02:07 PM
Thank you for your feedback.