Jump to content

Recommended Posts

Posted

Greetings to all. Apologies if this is in the wrong area.

 

Lately ive been coming accross the same Group policy error over multiple machines. Both Windows 10 and Windows 11. Though on only select machines. And all atemps to find out whats going on are stumping me.

The error is below:

 

"The processing of Group Policy failed. Windows attempted to read the file \\******\sysvol\******\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."

 

Bit of background. We have 2 domain controllers. All PC's are imaged with either Windows 10 or recently Windows 11 using SCCM. Which has been syspreped before capture. Then joined to the domain using SCCM. Have been using the same Windows 10 image for a while now, and only recently have we started getting problems. Specifically on brand new machines that are much newer than anything else we have. Ive checked for duplicate SID's and thats clear. We have no doplicates.

 

The issue is it seems to hit at random times. We could have 10-15 machines in a room and about half of them will come up with this. Then an hour later they are working fine no issues. All PCs are the same version (Win10 Edu 22H2) going through the same switch.

When i get this error, i can manually get to the policy in question and it opens fine. I look for it on both domain controllers and its there.

 

Ive checked for duplicate SID's.

DNS seems fine and resolves both domain controllers.

Replication between both domain controllers seems to be working ok.

DC Diag on the domain controllers shows no errors.

We have a GP that specifies to wait for network before processing anything.

 

Anything i may have missed here? As stupid as it sounds, could these PC's be too quick for the domain controllers? As they are far better than anything else we have on site.

 

Any help would be apreciated. If this is the wrong area, just point me in the right place and ill post there.

 

Thanks

Posted

In the voice of Lumiere singing in Beauty and the Beast:

 

D....N....S

DNS!

Put the (Windows) service to the test!

 

It's a good place to look for quirks here. Refresh and no-refresh intervals, purging, and name resolution to the DCs (check DHCP settings too).

  • Thanks 1
Posted (edited)
I came across something similar recently. It was DNS. The servers static IP was different to the IP listed in DNS, someone had changed it which was very odd. Edited by Patrick
Posted
In the voice of Lumiere singing in Beauty and the Beast:

 

D....N....S

DNS!

Put the (Windows) service to the test!

 

It's a good place to look for quirks here. Refresh and no-refresh intervals, purging, and name resolution to the DCs (check DHCP settings too).

 

I have came across something similar recently. It was DNS. The servers static IP was different to the IP listed in DNS, someone had changed it which was very odd.

 

Thanks for the replys.

 

We have checked both DNS and DHCP. We have 2 of each. Server IP'S are what they are meant to be, and the entries in DNS and DHCP point directly to them.

Posted
Is sysvol replication working properly across your DCs?

 

It is yes, as this was one of the first things we checked

Posted
I've come across a similar issue before and it turned out to be a corrupt GPO and making a small change to the GPO so it could re-save fixed the issue for me.
Posted
I've come across a similar issue before and it turned out to be a corrupt GPO and making a small change to the GPO so it could re-save fixed the issue for me.

 

We thought this too. So we altered the named policy it was referencing. Even deleted and remade but unfortunatly didnt seem to have an effect.

Posted

We've been battling this issue for about 6 months and I've made some progress on it recently.

 

We checked all the same things as you've already checked.

What we observed was if a machine was rebooted and you logged in and tried to access the SYSVOL volume you would get a credentials prompt. You could try any credentials and it would always fail basically making the SYSVOL inaccessible! NETLOGON was fine though. If you leave the machine for an hours SYSVOL suddenly then becomes available again.

A lot of forums will point you down disabling UNC hardening, we didn't want to do that for security reasons so I persevered and eventually stumbled across 3 registry keys that have eradicated the issue for us.

Hive:HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters

Value: AlwaysExpectDomainController

Type: REG_DWORD

Data: 1

Hive:HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

Value: MaxNegativeCacheTtl

Type: REG_DWORD

Data: 0

Hive:HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Value: NegativeCachePeriod

Type: REG_DWORD

Data: 0

 

It may not be the same for you or suitable for your environment but may be worth trying the above in a tiny controlled test and see how you get on.

  • Thanks 1
Posted
We've been battling this issue for about 6 months and I've made some progress on it recently.

 

We checked all the same things as you've already checked.

What we observed was if a machine was rebooted and you logged in and tried to access the SYSVOL volume you would get a credentials prompt. You could try any credentials and it would always fail basically making the SYSVOL inaccessible! NETLOGON was fine though. If you leave the machine for an hours SYSVOL suddenly then becomes available again.

A lot of forums will point you down disabling UNC hardening, we didn't want to do that for security reasons so I persevered and eventually stumbled across 3 registry keys that have eradicated the issue for us.

Hive:HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters

Value: AlwaysExpectDomainController

Type: REG_DWORD

Data: 1

Hive:HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

Value: MaxNegativeCacheTtl

Type: REG_DWORD

Data: 0

Hive:HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Value: NegativeCachePeriod

Type: REG_DWORD

Data: 0

 

It may not be the same for you or suitable for your environment but may be worth trying the above in a tiny controlled test and see how you get on.

 

Interesting, thanks for the reply. Where would you set these, on the DC or on the PC's themselves?

We have a room of new PC's where this keeps beeing an issue. So i can set it to just that room for now and see how things go.

Posted
I've only applied to PC's and that seems to have done the trick for us. Fingers crossed it works for you as well. Please read up on the keys so you fully understand what they do and let me know if you notice any improvements.
  • Thanks 1
Posted
I've only applied to PC's and that seems to have done the trick for us. Fingers crossed it works for you as well. Please read up on the keys so you fully understand what they do and let me know if you notice any improvements.

 

Ive currently got them set to one roomk that was particulally troublesome. So will see over the day how that goes.

Posted
Ive currently got them set to one roomk that was particulally troublesome. So will see over the day how that goes.

 

Unfortunately it seems this did not work. But i am now looking into the Hardened UNC path option. So will give that a try and see what comes of it

Posted
Do you use UE-V by any chance? We had this issue for months, tried all sorts even new DCs, GPOs, reimaging machines etc. Turned out to be UE-V being enabled on our machines. We no longer used it, so disabled it and issue went away once machines applied the new policy.
Posted
Do you use UE-V by any chance? We had this issue for months, tried all sorts even new DCs, GPOs, reimaging machines etc. Turned out to be UE-V being enabled on our machines. We no longer used it, so disabled it and issue went away once machines applied the new policy.

 

We do actually. Though like you im not sure its needed anymore with Office 365. So ill look into getting rid, and who knows. Thanks for the suggestion

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...