[1703, cu] PC intermittently fails to contact DCs

[technodan]

Every now and then one of our PCs will completely fail to apply any group policies. In the event viewer Windows\System log we get the following:

 

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.

 

When logging in the user doesn't get any mapped drives etc (we first noticed it when users reported SIMS didn't work). The machine then won't apply policies for any users until I do a gpupdate /sync and restart. What's odd is the gpt.ini link in the error message is clickable - and when I click it, the file opens, so there is obviously communication occurring. I can also ping both DCs and browse to NETLOGON and SYSVOL.

 

We have the same Windows 10 image (1703 Education) on everywhere, and the issue has cropped up on a couple of different models of machine. It's not reliably happening on the same machines either.

[3s-gtech]

I have had this a lot recently, and I took steps that I think have helped (too soon to know for sure).

 

The key was to remove that policy that fails (was always the same one for us). I subsumed the settings into a different GPO and deleted the link to the faulty one. You can link the GUID {31B2F 340-016D-11D2-945F-00C04FB984F9} to the offending GPO by looking on the Details tab of each policy until you find it.

 

Give that a shot and let me know how it goes - will be interested to hear.

[technodan]

Running Get-GPO on that GUID tells me that it's the Default Domain Policy. You would think that if THAT was broken, every machine would whinge surely? I'll have a dig through it and see if there's anything amiss.

Thanks for the tip - we will do some testing this half term!

[3s-gtech]

My research on other forums showed that it was frequently the default domain policy that caused this fault. Agreed on the extent - but then I was finding that when machines did a background refresh of GP that they succeeded without errors!

 

I was finding that my PCs were booting to the login screen without fully processing startup scripts (often because certain network chipsets would drop connection on bootup before GP processing, then re-establish halfway through). I set GPs to extend the wait for network and set the registry value

 

HKEY_LOCAL_MACHINE/SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GpNetworkStartTimeoutPolicyValue to DWORD 60

[technodan]

Interesting. We've actually already got the wait for network stuff in our policies, as I thought it might be related to that.

When we first deployed Windows 10 we had a lot of trouble getting machine policies applied consistently - we solved that by disabling fast startup in the registry (as Group Policy only seems to let you force it on, not off)

 

Set the registry key

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled to DWORD 0

 

Be warned though that on HDD-based systems especially it really is quite a lot slower!

[ozydave]

Be interested in this as I am getting it randomly.

The majority of PCs & laptops don't have a problem so I know the permissions on the GPO are ok and the GPO is readable.

I can gpupdate and reboot and all policies are the applied.

[TwistedHelixis]

I would just double check that the IP is not double assigned in DNS & DHCP on your server.