Windows 10: Group Policy fails to apply directly after boot, succeeds later
My problem is that Group Policy is not applied when a client is freshly booted. Directly after boot, the client posts an error message in the event log with source "GroupPolicy (Microsoft-Windows-GroupPolicy)" and Event ID 1058: "The processing of Group Policy failed. [...]". In the Details tab, the ErrorCode is 50, which stands for ERROR_NOT_SUPPORTED. It is not just a cosmetic issue: the policies really aren't applied properly: the mapped network drives aren't there, for example. After waiting a while, executing "gpupdate" works and the policies are applied normally: the mapped network drives appear.
The simplest scenario in which I was able to reproduce the problem: Newly created domain on freshly installed Windows Server 2012R2, client is a freshly installed Windows 10 64-bit machine. The domain consists of just the one domain controller and does not have any relations with other domains.
Since the error message states that Windows can't read a .GPT file from the Sysvol-share of the domain, I tried to access the same file from a Command Prompt. And indeed, when I open a Command Prompt right after boot I get this:
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
After waiting a minute or two, executing the same command will give a directory listing. Running gpupdate at this point will work just fine.
I did set the Group Policy setting "Always wait for the network at computer startup and logon" to "Enabled", and I know that this policy is applied: in the same policy object a Registry setting is specified, and when I check the Registry on the client the specified setting is there.
Other factors that could be relevant:
- NTLM is restricted in the domain, but this doesn't seem to matter: even after enabling it, updating policies and rebooting all machines, the symptoms remain the same.
- It doesn't matter whether the server is configured using DHCP or with a static configuration.
- The DNS server for the domain does not support Dynamic Updates. The necessary records were added manually (from C:\Windows\System32\config\netlogon.dns)
- Hibernation is disabled on the client (using
powercfg /h off) so each boot is a full boot, not a Fast Boot - The policy Startup Policy Processing Wait Time is set to 120 seconds
- Connectivity to the DC works fine. Pings will work. Turning off the client, disabling my account in AD, turning on the client will result in the client not logging me in: it immediately notices that the account is disabled.
- Apart from this issue, I don't notice anything out of the ordinary.
This seems to be more of an SMB issue than a Group Policy issue. Sniffing the connection on the server side shows something interesting:
The first time I perform the command dir \\domain.example.com\sysvol, the following shows in Microsoft Message Analyzer on the DC:
- Client sets up a TCP connection to port 445 of the DC, and a ComNegotiation is successfully performed (DialectRevision: 0x02FF).
- Immediately after that, a Negotiate is successfully performed. The DialectRevision is 0x0302.
- Immediately after that, the client closes the TCP connection with a TCP RST (??)
Every following time I issue the command and get the error, steps 2 and 3 occur.
When the command starts to work, steps 1 and 2 occur, but instead of the client sending a TCP RST a SessionSetup is performed, then a TreeConnect, and then a whole lot of (seemingly normal) SMB chatter occurs.
So, it looks like somehow the client will not properly talk SMB to the DC until a minute or two after boot, and this causes Group Policy processing to fail.
Anybody know how I can debug and solve this issue?
Solution 1:
Starting with Windows 8, Microsoft introduced this notion of "fast boot", where, when you shut down the OS, they hibernate OS memory footprint just like Hibernate works in normal hibernation scenarios. This results in the OS coming up faster, but it also has the side effect of disabling per-computer GP processing on startup. That is probably what you're seeing and this can be disabled by disabling the policy under Computer Configuration\Policies\Administrative Templates\System\Shutdown\Require use of fast startup
If that doesn't solve the problem then it is most likely a network stack timing issue, where GP processing for the computer is kicking off before the network stack is fully initialized. This has been around since XP and starting in Windows 7, Microsoft added a policy under Computer Configuration\Policies\Administrative Templates\System\Group Policy\Startup Policy Processing Wait Time where you can increase the time that GP waits before initiating. Try setting it to 60 seconds and see if that helps.
Darren
Solution 2:
I managed to solve this problem myself. For reference here's what solved my problem:
First, I was wrong in that disabling all blocking of NTLM resulted in the same symptoms. It resulted in a different symptom, that happened to have the same effect. Without any NTLM blocking policies in effect, the dir command now resulted in an access denied error. Group Policy still wouldn't apply, which makes sense: SYSVOL was still not accessible.
A bit of web searching told me that I know had a more common problem. though. Apparently, Windows 10 clients can have problems accessing the SYSVOL share of domain controllers (and perhaps the NETLOGON share as well). Supposedly Windows 10 changed something in the way it accesses those shares, which can result in problems. The workaround is to disable UNC Path Hardening on the client for these shares, by setting the "Hardened UNC Paths" Group Policy for the Windows 10 clients like this:
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(If you're experiencing problems with accessing the Netlogon share from Windows 10 clients, it could help setting all three parameters to zero for that share as well.)
See the article from Microsoft about MS15-011 for more information. It contains a good description of the security implications of changing this setting, as well as detailed steps of how to change the policy.
Warning: Note that the settings above disable some or all of the protections against the security issue MS15-011 was created for! Do not just blindly copy/paste them, but take an informed decision based on the risks involved. Also, this issue is likely to be solved sometime in the future. When that happens, don't forget to set this policy to the recommended values as described in MS15-011.