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

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

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.