The processing of group policy failed windows attempted to read the file

In this article, we’ll look at how to troubleshoot and fix Group Policy processing errors on Windows computers in an Active Directory domain.

If one of the domain computers fails to apply the new Group Policy settings, try to force the update of the GPO settings on this computer by using the command:

gpupdate /force

The most common errors that appear with the description: “Group Policy processing failed…” are as follows:

• Windows attempted to read the file …gpt.ini from a domain controller (Event ID 1058);
• Because of a lack of network connectivity to a domain controller (Event ID 1129);
• Windows attempted to retrieve new Group Policy settings for this user or computer (ID 1030);
• Windows could not determine the computer account to enforce Group Policy settings (Event ID 1097).

In brackets are Event Viewer error codes that you can use to trace these GPO processing errors (Event Viewer > Windows Logs > System). You should get an idea of the underlying problem from the descriptions of the specific errors on an affected machine.

Windows Can’t Read the GPT.INI File when Processing GPO

The full description of the error with event ID 1058 is as follows:

User policy could not be updated successfully. The following errors were encountered.

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\SysVol\domain.local\Policies\{Policy_GUID}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved.

• This issue may be transient and could be caused by one or more of the following:
  Name Resolution/Network Connectivity issues with the current domain controller;
• Distributed File System (DFS)/File Replication Service (FRS) latency (a file created on another domain controller has not been replicated to the current domain controller);
• The DFS client has been disabled.
  

Find out the name of the domain controller (the logon server) that your computer was trying to download the GPO files from. Open a command prompt and run the command:

systeminfo | find "Logon Server"

In this example, your DC name is xxx-dc01.

Use the nslookup, ping (or the Test-Connection cmdlet) to check if your DC and DNS service are available and responding.

Ping xxx-dc01

Nslookup xxx-dc01

Make sure both commands return a successful response. Try to reset the DNS resolver cache on affected computers:

ipconfig /flushdns

Check availability of DC via RPC protocol using the command:

nltest /dsgetdc:yourdoman.com

Make sure your domain controller is accessible via RPC protocol:

nltest /dsgetdc:your_domain_name

Hint. You can use the following post to resolve common RPC errors on Windows: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA).

1. Check that you can open the Sysvol and Netlogon shared folders on this DC:

   Win +R -> \\xxx-dc01\SysVol
   

   

2. Make sure that the file \\xxx-dc01\SysVol\domain.local\Policies\{Policy_GUID}\gpt.ini file exists on your domain controller. If the gpt.ini file is missing, then most likely the GPO is corrupted. You can get GPO name by its GUID with PowerShell:

   Get-GPO -id {Policy_GUID}|select DisplayName

3. Delete the corrupted GPO folder from the affected domain controller and wait for it to be replicated from another DC.
   

   Hint. If the policy files are missing on all domain controllers, you can restore the GPO from the AD backup.

4. Then check the permissions on the gpt.ini file for your user and computer accounts. They must have read+execute permissions. If not, fix the GPO permissions.
   After that, try running gpupdate /force and it should succeed!
   User Policy update has completed successfully.
   Computer Policy update has completed successfully.

Group Policy Processing Failed: Lack of Network Connectivity to a DC

Another common GPO error has an event ID 1129:

Computer policy could not be update successfully. The following error were encountered.

The processing of Group Policy failed because the lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

First, check that you are connected to the domain controller as described in the previous section.

If the error appears only on Windows startup, it probably means that the computer didn’t have time to initialize network before applying GPOs. There are several ways to solve the problem:

• The easiest way is to enable PortFast mode on the network switch. In this case, the switch port to which the user’s computer is connected immediately goes into the forwarding state, bypassing the learning phase;
• If the first method is not possible, you can apply a Group Policy setting called “Always wait for the network at computer startup and logon setting” (this policy forces the computer to wait for full network connectivity before logon and apply GPO).

1. Open the Group Policy Management Console (gpmc.msc), edit the policy linked to the Active Directory OU with computers, or create a new one;
2. Go to Computer Configuration > Administrative Templates > System > Logon;
3. Enable the policy Always wait for the network at computer startup and logon setting.
   

Some network card drivers ignore this policy. In this case, it is recommended to set the following parameter in the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
“GpNetworkStartTimeoutPolicyValue”=dword:0000003c

This parameter allows you to enable a startup delay in seconds (in our case, 60 seconds) before applying Group Policies (total Windows boot time will increase). You can deploy this registry parameter to computers in the domain through GPP.

If the error “The processing of Group Policy failed …” with code 1129 persists, increase the value of the GpNetworkStartTimeoutPolicyValue parameter until the problem goes away.

Also, the “lack of network connectivity to a domain controller” error may indicate that your client cannot connect to the Lightweight Directory Access Protocol (LDAP) service on the domain controller. Check if the TCP and UDP ports 389 are listening on the domain controller. Execute the following netstat command on DC, it should return LISTENING.

Make sure that the LDAP port is not blocked by the firewall between the client and the server (the command should return TcpTestSucceeded : True):

Test-NetConnection DC01 –port 389

Then run the ldp.exe tool and check the LDAP connectivity to the domain controller. Select Connection, enter a DC name, and click Connect.

If the LDAP service is running on the DC and is accessible from the client, a message will appear in the ldp.exe console:

ld = ldap_open(“192.168.79.129”, 389);

Established connection to 192.168.79.129.

Retrieving base DSA information…

Getting 1 entries:

Dn: (RootDSE)

configurationNamingContext: CN=Configuration,DC=theitbros,DC=com;

The Processing of Group Policy Failed: Windows Could Not Resolve the Computer Name

Another common error when applying Group Policy is the Event ID 1055:

The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one or more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

The error description may contain the following entry:

ErrorCode 1331
Logon failure: account currently disabled.

In this case, check if your computer account is enabled in Active Directory:

1. Get the name of your computer by running the command:

   hostname

2. Open the Active Directory Users and Computers snap-in (dsa.msc), find your computer account. Make sure it’s enabled. If not, right-click on it and select Enable account.
   

A secure channel issue may prevent a computer from authenticating with a domain controller and usually shows up as an “Access Denied” error when a computer tries to access domain resources, including Group Policy files. You can check and reset the secure channel between your computer and Active Directory using the Test-ComputerSecureChannel cmdlet:

Test-ComputerSecureChannel -Verbose

Reset the secure channel with the domain controller using the command:

Reset-ComputerMachinePassword -Server dc2 -Credential corp\domain_admin_account

Here are a few rarer GPO processing errors on the client and their associated Event IDs:

• Event ID: 1002: The processing of Group Policy failed because of a system allocation failure. Please ensure the computer is not running low on resources (memory, available disk space). Group Policy processing will be attempted at the next refresh cycle.
  This error indicates that your computer does not have enough resources to process the request. Check if your computer has enough free memory and disk space.
• Event ID: 1006: The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the Details tab for error code and description.
  Open the event description and look for the error code number, which may indicate the cause of the problem:
  Error code 5 (Access is denied) — user doesn’t have permission to access Active Directory;
  Error code 49 (Invalid credentials) — try changing the user’s password, or unlock AD account or computer account;
  Error code is 258 (Timeout) — check DNS health on DC.
• Event ID: 1030: The processing of Group Policy failed. Windows attempted to retrieve new Group Policy settings for this user or computer. Look in the Details tab for error code and description. Windows will automatically retry this operation at the next refresh cycle. Computers joined to the domain must have proper name resolution and network connectivity to a domain controller for discovery of new Group Policy objects and settings. An event will be logged when Group Policy is successful.
  Check if the TCP and UDP LDAP ports on the domain controller are available to the client (discussed above);
• Event ID: 1053: The processing of Group Policy failed. Windows could not resolve the user name.
  This could be caused by one or more of the following:
  1. Name Resolution failure on the current domain controller.
  2. Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).
  Check the error code on the Details tab:
  Error code 5 (Access is denied) and Error code 525 (The specified user doesn’t exist) — check if the user and/or computer has sufficient permissions to read the contents of the Organizational Unit in Active Directory;
  Error code 14 (Not enough storage) — check if your computer has enough free memory and disk space;
  Error code 1355 (The specified domain either doesn’t exist or couldn’t be contacted) — check the name resolution in Active Directory;
  Error code 1727 (The remote procedure call failed) — check the RPC connectivity to DC;
• Event ID: 1097: The processing of Group Policy failed. Windows could not determine the computer account to enforce Group Policy settings. This may be transient. Group Policy settings, including computer configuration, will not be enforced for this computer.
  Check if the time on your computer is synchronized with the domain controller (how to configure NTP time synchronization in Active Directory?). Try to sync time with domain controller manually.
• Event ID: 1096: The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. This means that the local GPO settings file on the computer is corrupted. Simply delete the file C:\Windows\System32\GroupPolicy\Machine\Registry.pol. It will be rebuilt the next time you restart your computer.

Fixing Group Policy Replication issues

I ran into an issue where GPUpdate kept returning the error below:

«Computer policy could not be updated successfully.  The following errors were encountered: The processing of Group Policy failed.  Windows attempted to read the file \\COMPANY.LOCAL\sysvol\<FQDN>\Policies\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\gpt.ini from a domain controller and was not successful.  Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

To diagnose the failure, review the event log or invoke gpmc.msc to access information about Group Policy results.»

In my case the DCs got out of sync and the fix was to complete an authoritative restore of SYSVOL

Solution:

Backup your SYSVOL folders before following any of these steps. If something goes wrong during the process all files could be deleted.

See replication status

• Make sure SYSVOL is advertising
• Dcdiag /e /test:sysvolcheck /test:advertising
• For /f %i IN (‘dsquery server -o rdn’) do @echo %i && @wmic /node:»%i» /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername=’SYSVOL share’ get replicationgroupname,replicatedfoldername,state
• All servers should be in state 4 (Normal)
• https://support.microsoft.com/en-us/help/2958414/dfs-replication-how-to-troubleshoot-missing-sysvol-and-netlogon-shares
• Use Active Directory Replication Status Tool to find issues
• https://www.microsoft.com/en-us/download/details.aspx?id=30005

Fix SYSVOL

• perform authoritative restore of SYSVOL
1. Follow the steps EXACTLY. You should also disable the service so that it does not auto start while you are making changes. 
2. The <the server name to replicate from> does not have to be the PDC, it can be any server that has the correct copy of SYSVOL.
3. I never saw events 2002 and 4602 on the secondary servers, but everything worked as expected. 
4. Ran: For /f %i IN (‘dsquery server -o rdn’) do @echo %i && @wmic /node:»%i» /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername=’SYSVOL share’ get replicationgroupname,replicatedfoldername,state 
1. All servers were in state 4(Normal)
5. http://jackstromberg.com/2014/07/sysvol-and-group-policy-out-of-sync-on-server-2012-r2-dcs-using-dfsr/
6. https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo

   

Popular posts from this blog

Hello everyone.

I’ve recently run into this specific problem, and I just can’t seem to find any answer.

My current setup:

MainDC (Server 2012)

OffShore DC 1 (Server 2012)

OffShore DC 2 (Server 2012 R2)

OffShore DC 3 (Server 2008 R2 about to be shut-down)

All the OffShore DC’s are communicating with MainDC, replicating via DFS.

I just migrated our FRS to DFRS (we need to move to Server 2019)

Dcdiag /e /test:sysvolcheck /test:advertising

returns the following:

—————————————————————————————————————
Directory Server Diagnosis

Performing initial setup:
  Trying to find home server…
  Home Server =
MainDC

  * Identified AD Forest.
  Done gathering initial info.

Doing initial required tests

  Testing server:
MainDC

      Starting test: Connectivity
        …………………….
MainDC

passed test Connectivity

  Testing server:
OffShore DC 1

      Starting test: Connectivity
        …………………….
OffShore DC 1

passed test Connectivity

  Testing server:
OffShore DC 2

      Starting test: Connectivity
        …………………….
OffShore DC 2

passed test Connectivity

  Testing server:
OffShore DC 3

      Starting test: Connectivity
        …………………….
OffShore DC 3

passed test Connectivity

Doing primary tests

  Testing server:
MainDC

      Starting test: Advertising
        …………………….
MainDC

passed test Advertising
      Starting test: SysVolCheck
        …………………….
MainDC

passed test SysVolCheck

  Testing server:
OffShore DC 1

      Starting test: Advertising
        …………………….
OffShore DC 1

passed test Advertising
      Starting test: SysVolCheck
        …………………….
OffShore DC 1

passed test SysVolCheck

  Testing server:
OffShore DC 2

      Starting test: Advertising
        …………………….
OffShore DC 2

passed test Advertising
      Starting test: SysVolCheck
        …………………….
OffShore DC 2

passed test SysVolCheck

  Testing server:
OffShore DC 3

      Starting test: Advertising
        …………………….
OffShore DC 3

passed test Advertising
      Starting test: SysVolCheck
        …………………….
OffShore DC 3

passed test SysVolCheck

——————————————————————————————————

Now, here’s the issue.

gpupdate on OffShore DC 2 is not getting the Default Domain Policy, which is getting through just fine on everything else.

The folder is browseable from all the DC’s and client machines.

I tried to Edit the GPO, update it with a new setting, restoring it, copy -> delete -> insert but to no avail. I just can’t seem to figure out what’s wrong with my OffShore DC 2. Replication is running as usual, no errors to track.

The whole error message:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

Anyone got a clue?

I’m using a Samba4 domain controller, and on the machines joined to the domain I’m seeing this message:

The processing of Group Policy failed. Windows attempted to read the file \\mydomain.org\sysvol\mydomain.org\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: 
a) Name Resolution/Network Connectivity to the current domain controller. 
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). 
c) The Distributed File System (DFS) client has been disabled.

Running gpupdate gives me the same error. If I open the run box and type notepad \\mydomain.org\sysvol\mydomain.org\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini, I get Notepad opened up with the file in it. The contents are these:

[General]
Version=14

Clearly the file exists, and is accessible (by the domain administrator, anyway). The mydomain.org name resovles to the IP address of my domain controller. If I run GPRESULT /H GPReport.html, the resulting file says:

Group Policy Infrastructure failed due to the error listed below.

Access is denied. 

Note: Due to the GP Core failure, none of the other Group Policy components processed their policy. Consequently, status information for the other components is not available.

I’ve checked the ACL via smbcacls on the domain folder under the sysvol share, and got this output:

pi@dc-rpi1 ~ $ smbcacls //mydomain.org/sysvol mydomain.org -U [email protected]
Enter [email protected]'s password:
REVISION:1
CONTROL:SR|PD|DP
OWNER:MYDOMAIN\Administrator
GROUP:BUILTIN\Administrators
ACL:BUILTIN\Administrators:ALLOWED/OI|CI/FULL
ACL:BUILTIN\Server Operators:ALLOWED/OI|CI/READ
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI/FULL
ACL:NT AUTHORITY\Authenticated Users:ALLOWED/OI|CI/READ

If I try to get the ACLs on the gpt.ini file itself, I get this:

pi@dc-rpi1 ~ $ smbcacls //mydomain.org/sysvol mydomain.org/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/gpt.ini -U [email protected]
Enter [email protected]'s password:
REVISION:1
CONTROL:SR|PD|DP
OWNER:MYDOMAIN\Domain Admins
GROUP:MYDOMAIN\Domain Admins
ACL:MYDOMAIN\Domain Admins:ALLOWED/OI|CI/FULL
ACL:MYDOMAIN\Enterprise Admins:ALLOWED/OI|CI/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:MYDOMAIN\Domain Admins:ALLOWED/OI|CI/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI/FULL
ACL:NT AUTHORITY\Authenticated Users:ALLOWED/OI|CI/READ
ACL:NT AUTHORITY\ServerLogon:ALLOWED/OI|CI/READ

Why won’t group policy processing work? Are the ACLs not working because my DC isn’t running the right filesystem, or some other obscure configuration problem?