1

Been pulling my hair out trying to figure this one out, and although I’ve found many posts with similar errors, none of the resolutions has worked for our situation. This is almost certainly operator error on my part, as I’m not an AD expert, but I’m spinning my wheels trying to solve this so I am hoping for some advice from someone much more skilled in AD and GPOs than myself.

We have a simple SOHO domain with only one DC and 7 client workstations. For GPOs there are only 4 total for the domain. They all apply properly to the domain controller, but any workstation trying to apply them gets the following two error messages:

The processing of Group Policy failed. Windows attempted to read the file \\xxxxxxx.com\sysvol\xxxxxxx.com\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.
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://CN=User,cn={31B2F340-016D-11D2-945F-00C04FB984F9},cn=policies,cn=system,DC=xxxxxxx,DC=com. 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.

I’ve tried the following with no luck so far:

  • Verified client computers can ping DC with both ip and DNS name
  • Ensured policies were linked to the correct OUs
  • Verified that Authenticated Users and Domain Computers have read/write access to all policies applicable
  • Verified the SYSVOL permissions weren’t broken (from what I read, at least)
  • Created a new GPO with only one computer policy configuration, and unlinked and disabled all other policies. I receive the same error on this clean test GPO as well.
  • Disabled and unlinked the policy referenced in the GUIDs above, and then i receive the same errors on the next policy in the list

Seems to be an issue or misconfiguration on the DC, but I just don’t have enough experience here to know where to start debugging further. Any ideas would be greatly appreciated.

11 Spice ups
2

What DNS do the clients use.

If they have anything other than only the DC, there’s your issue.

For domains to work, clients need to use ONLY the DC(s) for DNS and never any Google DNS or other 3rd party DNS services.

If a client pings yourdomain.com does it resolve?

Is yourdomain.com the same as yours or someone else’s public domain name?

3

Yes all client dns settings point to the sole DC in the domain and there are no other servers named in the client settings. The DC points to its own IP address and 127.0.0.1 The DNS server in the DC points to the router as a forwarded server to resolve addresses that aren’t within the domain. The router is the only device explicitly using public DNS in the entire network, but any traffic that lands at the router DNS addresses would have (in theory) already been attempted to resolve on the domain first. That’s setup correctly, right?

4

Thanks - that seems good.

Can the clients resolve the domain name - not just the DC or IP

Can they ping and return domain.com = ip-of-dc

1 Spice up
5

Yes a ping of XXXXX.com from a client machine returns the proper IP address for the DC.

6

Also recently tried to reset the BurFlags to reinitialize FRS, according to this article - Use BurFlags to reinitialize File Replication Service (FRS) - Windows Server | Microsoft Learn

but, the keys mentioned here were not present in my registry. I assume because I’m only running one DC, and replication isn’t part of the process on this domain?

7

Can any of the 7 clients access the netlogon and sysvol shares from the DC?
If on a client you browse to \ad-domain-name\ does it work? are the sysvol and netglogon shared shown?

What changed before the GPOs stopped applying?

It appears that the clients cannot access the sysvol to read the GPOs.

1 Spice up
8

Yes and No, so we may be on to something here…

When browsing from the client machines, they all can view the shares from the domain. There is a NETLOGON and SYSVOL share available there when clients (or the DC) browse into the domain level shares. However, when I open these shares from the client machines or the DC, NETLOGON appears empty. I verified the location of the NETLOGON share from server manager as: C:\WINDOWS\SYSVOL\sysvol\domain.com\SCRIPTS. Authenticated users have read/write permissions to that folder. But when I look at that location, it is an empty folder?

SYSVOL appears to be correct, having the domain folder that contains policies, scripts, and starterGPO folders, and corresponding guid folders for each policy, just a blank SCRIPTS folder where I’d expect NETLOGON to be.

9

Netlogon may well be empty if nothing has ever been placed there. As long as the sysvol share is accessible - and a client can browse into the folders containing the GPOs then they should be able to read them.

I recommend following the GPO troubleshooting guide Applying Group Policy troubleshooting guidance - Windows Server | Microsoft Learn

First however do a gpresult to see if it gives any clues:
gpresult /h GPResult.htm
gpresult /r > GPResult.txt

and check the results.

This is a gide to logging on the client which should state why it is not finding the GPOs A Treatise on Group Policy Troubleshooting–now with GPSVC Log Analysis! - Microsoft Community Hub

more GPO loggin Windows Group Policy | NXLog Docs

1 Spice up
10

Much appreciated. I’ll try these now and share any results/findings!

11

Thanks again.

To report back, I ran a GPresult on a client machine and the only errors referenced mirrored the output from gpupdate/force listed at the top of this post. So, no new information there, unfortunately. At the bottom of the report, it does show that Default Domain Policy has been applied, yet the CLI on a GPupdate command errors out, so I’m assuming it hasn’t truly been applied.

I went through the troubleshooting list you referenced from Applying Group Policy troubleshooting guidance - Windows Server | Microsoft Learn on both the client and server event logs.

  • The server only showed one error during a gpupdate /force from a client machine. This error may not be related to the issue, but interesting nonetheless. I say possibly unrelated because it is not consistent on each gpupdate session. But just so happens that the error was reported during one of my tests.
<Data Name="ErrorCode">183</Data> 
  <Data Name="ErrorDescription">Cannot create a file when that file already exists.</Data>
  • The client machine operational logs directly after a gpupdate/force shows the following (anonymized), in order:

    • successful gpo service initialization

    • GP service started

    • GP receives notification to create session from winlogon

    • GP session returned to winlogon

    • GP session started

    • successfully completed the GP service initialization phase

    • GP client service is currently configured as a standalone service

    • Initializing and reading current service configuration for the Group Policy Client service.

    • Initializing service instance state to detect previous instances of the service.

    • Group policy session completed successfully.

    • A previous instance of the Group Policy Client Service was detected. Parameter: 07602719-68a6-41a8-afa2-53650989a752

    • Group policy session completed successfully.

    • Starting manual processing of policy for computer DOMAIN\CLIENTMACHINENAME$.
      Activity id: {8fb9d708-5e06-4912-bd78-a1e787024278}

    • The Group Policy processing mode is Background.

    • Attempting to retrieve the account information.

    • Making system call to get account information.

    • The system call to get account information completed.
      CN=CLIENTMACHINENAME,CN=Computers,DC=DOMAINNAME,DC=com
      The call completed in 47 milliseconds.

    • Retrieved account information.

    • Group Policy is trying to discover the Domain Controller information.

    • Retrieving Domain Controller details.

    • Making LDAP calls to connect and bind to Active Directory.

    • The LDAP call to connect and bind to Active Directory completed.
      DOMAINCONTROLLERNAME.DOMAIN.com
      The call completed in 78 milliseconds.
      DOMAINCONTROLLERNAME.DOMAIN.com

    • Domain Controller details:
      Domain Controller Name : DOMAINCONTROLLERNAME.DOMAIN.com
      Domain Controller IP Address : 192.168.1.XX

    • Group Policy successfully discovered the Domain Controller in 422 milliseconds.

    • Computer details:
      Computer role : 2
      Network name :

    • Account details:
      Account Name : CN=CLIENTMACHINENAME,CN=Computers,DC=DOMAIN,DC=com
      Account Domain Name : DOMAIN.com
      DC Name : \DOMAINCONTROLLERNAME.DOMAIN.com
      DC Domain Name : DOMAIN.com

    • The loopback policy processing mode is “No loopback mode”.

    • Group Policy receiving applicable GPOs from the domain controller.

    • Starting to download policies.

    • Estimated network bandwidth on one of the connections: 419828 kbps.

    • A fast link was detected. The Estimated bandwidth is 3358 kbps. The slow link threshold is 500 kbps.

    • Making system calls to access specified file.
      \DOMAIN.com\sysvol\DOMAIN.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

    • ERROR - The system calls to access specified file completed.
      \DOMAIN.com\sysvol\DOMAIN.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
      The call failed after 94 milliseconds.

    • NOTE: This file actually does exist and is accessible via the DC file explorer and the client’s file explorer. The only difference is the capitalization in the file name, which I don’t think matters in a Win environment.- Downloaded policies with error.

    • Group Policy successfully got applicable GPOs from the domain controller.

    • Completed manual processing of policy for computer DOMAIN\CLIENTMACHINENAME$ in 1 seconds.

    • Starting manual processing of policy for user DOMAIN\MYUSERACCOUNT.
      Activity id: {ef732ad4-9a64-4326-a2d3-8fa02febe218}

    • The Group Policy processing mode is Background.

    • Attempting to retrieve the account information.

    • Making system call to get account information.

    • The system call to get account information completed.
      CN=My Name,CN=Users,DC=DOMAIN,DC=com
      The call completed in 172 milliseconds.

    • Retrieved account information.

    • Group Policy is trying to discover the Domain Controller information.

    • Retrieving Domain Controller details.

    • Making LDAP calls to connect and bind to Active Directory.

    • The LDAP call to connect and bind to Active Directory completed.
      DOMAINCONTROLLERNAME.DOMAIN.com
      The call completed in 15 milliseconds.

    • Domain Controller details:

    • Domain Controller Name : DOMAINCONTROLLERNAME.DOMAIN.com
      Domain Controller IP Address : 192.168.1.XX

    • Group Policy successfully discovered the Domain Controller in 328 milliseconds.

    • Computer details:
      Computer role : 2
      Network name :

    • Account details:
      Account Name : CN=EMy Name,CN=Users,DC=DOMAIN,DC=com
      Account Domain Name : DOMAIN.COM
      DC Name : \DOMAINCONTROLLERNAME.DOMAIN.com
      DC Domain Name : DOMAIN.COM

    • The loopback policy processing mode is “No loopback mode”.

    • Group Policy receiving applicable GPOs from the domain controller.

    • Starting to download policies.

    • Estimated network bandwidth on one of the connections: 419828 kbps.

    • A fast link was detected. The Estimated bandwidth is 3358 kbps. The slow link threshold is 500 kbps.

    • Making system calls to access specified file.
      \DOMAIN.com\sysvol\DOMAIN.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

    • The system calls to access specified file completed.
      \DOMAIN.com\sysvol\DOmain.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
      The call completed in 187 milliseconds.

    • Successfully completed downloading policies.

    • Starting to save policies to the local datastore.

    • Successfully saved policies to the local datastore.

    • Group Policy successfully got applicable GPOs from the domain controller.

    • List of applicable Group Policy objects:

      Default Domain Policy

    • The following Group Policy objects were not applicable because they were filtered out :

      Local Group Policy
      Not Applied (Empty)

    • Checking for Group Policy client extensions that are not part of the system.

    • Service configuration update to standalone is not required and will be skipped.

    • Finished checking for non-system extensions.

    • Starting Registry Extension Processing.

      List of applicable Group Policy objects: (Changes were detected.)

      Default Domain Policy

    • ERROR - Completed Registry Extension Processing in 31 milliseconds.

    • No error message provided in the event itself, but this is the detail view that does provide a code.

    • Error Code 2147500037

    • CSEExtensionName Registry

    • CSEExtensionId {35378eac-683f-11d2-a89a-00c04fbbcfa2}

    • Completed manual processing of policy for user DOMAIN\MYUSERNAME in 1 seconds.

    • Starting manual processing of policy for computer DOMAIN\CLIENTMACHINENAME$.
      Activity id: {77c776d6-5a99-47e7-b885-98aac7b916c6}

    • The Group Policy processing mode is Background.

    • Attempting to retrieve the account information.

    • Making system call to get account information.

    • The system call to get account information completed.
      CN=CLIENTMACHINENAME,CN=Computers,DC=DOMAIN,DC=com
      The call completed in 78 milliseconds.

    • Retrieved account information.

    • Group Policy is trying to discover the Domain Controller information.

    • Retrieving Domain Controller details.

    • <… similar event info messages as loops above until the following…>

    • ERROR - The system calls to access specified file completed.
      \DOMAIN.com\sysvol\DOMAIN.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
      The call failed after 31 milliseconds.

After looking through all this, with no luck, I read through this suggestion @matt7863 ​ provided - A Treatise on Group Policy Troubleshooting–now with GPSVC Log Analysis! - Microsoft Community Hub and enabled GPsvc logging on a client machine. I’ve attached those anonymized results of a manual gpupdate/force here as well.

Between the event viewer logs and the GPsvc log attached here, I’m unfortunately, no closer to solving this one.

  • I don’t think its a dns issue at all, considering everything is setup as expected, and the client machines have no trouble pinging, browsing, or navigating the DC and the domain itself.
  • Permissions issues don’t make sense either. As you can see in the event viewer logs above, the gpt.ini file is inaccessible at one point in the process and then accessible later, and then inaccessible toward the end again. I created a blank GPO and mirrored those permissions to my default domain policy, and still receive the same errors.

I’m truly stumped, but I appreciate your help with those possible debug options.

8c366c42-263c-4ada-8e62-3b65f372f121-gpsvc.txt (579 KB)

12

tldr: googling suggests that dcgpofix will re-create the defualt policy. dcgpofix | Microsoft Learn
dcgpofix /ignoreschema /target:domain

It is a strange one. Specifically it is the computer context that cannot access the object/file:\DOMAIN.com\sysvol\DOMAIN.com\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

But when the user context completes successfully for exactly the same object/file.

That file is the default domain policy. This is quite a common issue, the typically fix is restore from backup (probably too long ago for you to do that now without affecting other stuff - but you could try restoring just that directory) or to force replication from another known DC - not applicable to you.

Fairly sure I have had this in an environment that was a sbs2003 upgrade to 2008 to 2011. Think I recreated the policy on the newer DC.

Make sure that the delegaiton is correct - not just actual security permisions. Delegate Permissions for a Group or User on a Group Policy Object | Microsoft Learn
The computer needs to be able to read it - so delegate read for computers specifically or “authenticated users” which includes computer objects.

1 Spice up
13

Thanks for the suggestion. It’s still not working, but I’m closer…I think.

  1. I backed up all 4 GPO objects before running the dcgpofix command, so that I could recreate my current settings on the base policy that the command writes to the domain. 3 of the 4 backups completed successfully, and the 4th gave me some errors about a user GUID referenced in the Default DC Policy that no longer exists. This may be coincidental, but I’m mentioning it nonetheless. So, I went in to the Default DC policy, found the references to a user that had been deleted previously, but was still named in a couple of the security settings manually. I did a Gpoupdate /force on the DC, and it applied as usual with no errors. I then backed that last policy up without error.
  2. Next, I ran the gcgpofix command you provided. It rewrote the policy successfully. I went to a client machine, cleared the GPO cache, DNS cache, and logged out and logged back in. Then ran a gpoupdate /force. I got the same errors!
  3. So, I went back to ADUC to hunt for anything that I could be overlooking. I moved my test client computer from an OU we created called “workstations” to the default “Computers” container instead. (Just thinking here that the error causing all this might not be GPO related, but AD setup related instead.) After retrying a GPO update on the test client computer, I still get the error about the Computer Policy not applying, BUT… the user policy applies successfully, and the original LDAP (second error from original post) has gone away.
  4. After this small success, I ran a GPresult on the test client and noticed one interesting thing that might be contributing to the problem, or at least preventing the solution above from working… The computer name in the gpresult report does not match the computer name in the control panel or active directory. This machine was renamed at some point, and for whatever reason, the GPO sees the old name. I verified the name parameters in ADSI edit for that device. They were all correct. So, I went to the device, removed it from the domain all together, and then rejoined it, flushed and registered dns just in case. After rejoining, I still get the same GPO error when applying computer policy, and the computer name in the gpresult is still incorrect.

So… I’ve gotten the user policy to apply, but still not the computer policy. Does this look like an AD setup (CN/OU/Naming) issue at this point, or am i going down an entirely different rabbithole here?

14

Just wanted to follow up here and thank all of you who provided input. Despite every test I could find coming up clean with respect to DNS, the issue was somehow still DNS. I’m not fully certain what the issue was, but I was able to finally resolve it and get client computer GPOs to start applying.

Since this is a small domain with only one DC, I ended up just wiping the DNS server role from the DC, rebooting, and then reconfiguring the DNS role from scratch. In most domains, I’d assume a full authoritative restore of a zone would suffice. However, in this use case, starting from scratch wasn’t the end of the world.

Again, no idea what the issue was or how it was tied to DNS, but after the rebuild of that role, everything started working magically. I’ve spent enough time scratching my head on this one, so I’ll let it lie. I’ll possibly spin up a secondary DC for replication purposes and hopefully, this won’t be an issue in the future. Thanks everyone!