In an AD domain with Windows Server 2008 R2 DCs users are complaining about delays in the bootup process of the clients. The group policy log reveals that the client is waiting ~ 20-50 seconds for "the network subsystem":
Event 5322, GroupPolicy
Group policy waited for 29687 milliseconds for the network subsystem at computer boot.
This appears to be domain-specific as machines joining a different domain from the same network do not experience any delays and Event 5322 reports <1000 ms wait times at startup. It happens on virtual and physical machines alike, so it does not look like a hardware- or driver-related issue.
Further investigation has shown that the client was taking its time before issuing DHCP requests. In the network traces, I can see IPv6 router solicitations and multicast DNS name registrations as soon as the network driver is loaded and the network connection is reported "up" in the event log (e1cexpress/36). Yet, the DHCPv4 client service seemed to take another 15-50 seconds to start (Dhcp-Client/50036), so the IPv4 address remained unconfigured for a while.
The DHCP client's startup messages in the event log were succeeding the service start of the "Sophos Anti-Virus" service (Sophos Endpoint Security 10.3.7), so I suspected dependencies of the DHCP client service to be the culprit:
But an uninstall of all Sophos components did not remedy the issue. Checking for possible further 3d party drivers which might be messing up, I used NirSoft DriverView, to check for other non-Microsoft drivers and have removed the DameWare remote control and Citrix ICA packages in the result, leaving the system with hardware-related 3rd party drivers only (Intel chipset, network & SATA stuff, Mirage video driver, Macrovision driver).
I also have removed DHCP client's dependency on Tdx – this has led to the Dhcp client service starting significantly earlier, yet the Group Policy is still "waiting for the network subsystem"
Where could I look next?
Best Answer
First off, something to keep in mind: If I remember correctly, the group policy client determines the "network availability" by a successful connection to the domain controller, not simply by the client having a network connection. You may indeed have a network connection that is initialized in a timely manner, but a slow-responding domain controller could still cause the "waiting for network" issue. This could explain why clients on different domains are not experiencing the issue. You might want to check the event log on your DCs. As Evan said, a protocol analyzer will show you which side is causing the delay.
Now, for some short-term advice that doesn't address the root problem, but might get the users off your back temporarily:
Outside of a domain controller, Group Policy processing should run asynchronously unless you've specifically told it otherwise, either through a GP setting, or manually with the /sync flag. In asynchronous mode, policy processing shouldn't hold up the boot or logon process. You might want to check if you, by chance, enabled the "Always wait for the network at computer startup and logon" policy. It's located in Computer Configuration > Administrative Templates > System > Logon. Try running RSoP on the client and see if comes up enabled - if so, disable it. You might also want to take a look at the "Startup policy processing wait time" policy in the same location.
This doesn't address why the network is not initialized in a timely fashion, but perhaps it will at least get the users off your back in the meantime. Asynchronous processing does wait a little bit to try to contact the domain controller to get the policy list, but it shouldn't be waiting more than a few seconds.