gpupdate fail - error "access denied" sporadically - event 1058 and 1096

Question

Hello there,

I'm asking some help about a problem that we are facing since ages.

The problem :

PC on domain sometimes can't do a gpupdate /force and get the following error in terminal :

The processing of Group Policy failed. Windows attempted to read the file "\our.domain.fr\sysvol\our.domain.fr\Policies{GPO-UID}\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.

Sometimes, its the gpt.ini that cannot be read, sometimes its the \Machine\registry.pol file. Always the same error.

When i get this error in terminal, i then go the event viewer and see that two events :

• 1058 : (With same message found in the terminal)

Event data : ErrorCode 5
ErrorDescription access denied
DCName DC2.ourdomain.fr
GPOCNName cn={GPO-UID},cn=policies,cn=system,DC=ourdomain,DC=fr
FilePath \ourdomain.fr\SysVol\ourdomain.fr\Policies{GPO-UID}\gpt.ini

• 1096 :

The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://CN=User,cn={GPO-UID},cn=policies,cn=system,DC=ourdomain,DC=fr. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.
Event data : ErrorCode 5
ErrorDescription access denied
DCName \DC2.ourdomain.fr
GPOCNName LDAP://CN=User,cn={GPO-UID},cn=policies,cn=system,DC=ourdomain,DC=fr
FilePath \ourdomain.fr\SysVol\ourdomain.fr\Policies{GPO-UID}\User\registry.pol

What's important :

This error don't happen all the time, but when it happen, it's for the next few gpupdate /force (For exemple, it will not work until like 5 or 10 minutes, or after 1,2 or even 3 reboot). It's really anoying beacuse i cannot test new GPO, or edit existing GPO as i don't have consistent way to test theses, because i cannot tell for sure if the GPO will be apply to all computer on domain

This error can happen on all computer in the domain. But it's not all at the same time. For exemple i can have the error on my computer, but the other it technician can do a gpupdate just fine, or in reverse.

We have 2 DC. DC1 and DC2. ourdomain.fr points to both of them (as it should be), and the error mostly happen when the computers ask the DC2 to do gpupdate, but i have also sometimes seen this error on DC1.

When the error occur, i've checked that the computer can access the file marked as "access denied", and he can access it and open it manually, but the gpupdate can't for some reason.

It's been only 4 month that i started working for this company, but i can tell this problem is far older than 2023

At one time, i know that the old technician had replace the old DC2 Windows server 2012 and installed a new Windows server 2016 with the same name (DC2).

I'm really struggling with this, i need to rework the entire domain policy, but it's a pain for me as i can't trust no more the gpupdate process.

Thanks to other forums comments, i know that my 2 DC and my domain is in good health, i don't have permission problems on the GPO (Authenticated user has read access to all GPO).

I also know that the replication between the two DCs are fine.

Any other suggestions ?

Thank you for your reading time and for your help !

Answer 1

Hello

Thank you for your question and reaching out.

1. Verify the DNS configurations on the impacted machines: Verify that your domain controllers' IP addresses are listed correctly in the DNS server entries. Using the command "ipconfig /flushdns" on the impacted

machines, you can also try flushing the DNS cache.

2. Examine the FRS logs (file replication service): Make sure there are no replication issues by checking the FRS logs with the command "repadmin /showrepl". You must analyse the FRS service for issues if there are any.
3. Verify the DFS client configurations: Verify that the impacted machines have the DFS client service activated and functioning. This can be verified using the Services console.
4. Verify the SYSVOL folder permissions: Ensure that the GPOs are kept in the appropriate location and that the Authenticated Users group has read access to the SYSVOL folder.
5. Verify the time synchronisation: Verify that the time on the impacted machines and the domain controllers are in sync. Run the command "w32tm /query /source" on the affected machines to verify this.
6. Check the firewall settings: Verify that no necessary ports for the domain controllers are blocked by the firewall settings on the impacted devices.

--If the reply is helpful, please Upvote and Accept as answer--