Problem:
We were seeing high numbers of GroupPolicy Event ID 1055 (indicates Group Policy processing failed) that were preceded by NetLogon Event ID 5719 (indicates NetLogon unable to reach any of the domain controllers). This was found initially on VMs where the failure rate was high, but further investigation showed it was occurring on physical desktops/laptops. However, in the majority of cases the system sorts itself out by the next background refresh cycle, although this does not always help startup scripts from launching.

Cause:
There is a race condition going on between when the underlying network signals that it is available and when Active Directory and Group Policy try to access the network. Unfortunately there are cases where the network is not yet available and so both AD and GP processing fail. The problem is most likely because link status fluctuates as the network adapter driver initialises and as the network adapter hardware negotiates a link with the network infrastructure. The Group Policy application stack executes before the negotiation process is completed and can fail because of the absence of a valid link.

Solution:
There is a Group Policy setting that will force the Group Policy engine to try executing every two seconds up to the value (in seconds) defined in the policy. This is covered in KB2421599 - Windows 7 Clients intermittently fail to apply group policy at startup.

Policy Location: Computer Configuration > Policies > Admin Templates > System > Group Policy
Setting Name: Startup policy processing wait time
Registry Key: HKLM\Software\Policies\Microsoft\Windows\System!Gp NetworkStartTimeoutPolicyValue

However, if you look in the Group Policy description it's a bit misleading - “If you disable or do not configure this policy setting, Group Policy will use the default wait time of 30 seconds on computers running Windows Vista operating system.” is true only under certain scenarios, for example the client is part of a workgroup. A domain joined client gets a bit complex and they are not going to use the default wait time of 30 seconds as described in the explain text. In this scenario, the time out period can be defined at two locations:

Manual --> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Group Policy --> HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Win dows\System

If you haven’t defined the Group Policy or you have set it as “Disabled” then it looks at a 3rd registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Group Policy\History

Since this time out period is always defined, the system now uses its algorithm to calculate and arrive at an Average time out period. This could vary from system to system as it depends on several factors.

We found that setting the Group Policy value to 30 seconds works best in our environment.

Failed solutions:
There are a few other recommendations that we reviewed, but we were either unable to implement or they just did not work -

1. Ensure NIC drivers are updated
2. Ensure PortFast is enabled (KB247922)
3. Disable DHCP Media Sense (KB239924)
4. Delay the start of netlogon (KB938449)