Windows 10: Group Policy fails to apply directly after boot, succeeds later

group-policywindows 10windows-server-2012-r2

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:

  1. Client sets up a TCP connection to port 445 of the DC, and a
    ComNegotiation is successfully performed (DialectRevision: 0x02FF).
  2. Immediately after that, a Negotiate is successfully performed. The
    DialectRevision is 0x0302.
  3. 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?

Best Answer

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

Related Topic