How does group policy know when the network subsystem is ready?

Question

I'm trying to troubleshoot some group policy startup processing issues on domain joined, remote computers that establish a Zscaler/VPN connection at startup and before logon. This causes a short delay in domain connectivity that is not typically present when the machine is physically on the network.

I've set a couple of GPOs:

1. Always wait for the network at computer startup and logon
2. Specify startup policy processing wait time = 60 seconds

This results in the following type of event log entries:

Group Policy waited for 17031 milliseconds for the network subsystem at computer boot.

However, sometimes that number hits 60000 milliseconds which coincides with my GPOs. So, essentially, sometimes GPO detects the "network subsystem" is available, and other times it doesn't. Yet, it always successfully downloads GPOs and applies them after this time.

To try to determine how Group Policy determines network availability, I targeted the netlogon service debug logs thinking that DC discovery and connectivity was coming in to play. But, netlogon indicates successful session setup with a DC at times that do not coincide with the group policy event log entry. For instance, when GP waits 60 seconds, netlogon has already indicated successful connections to domain controllers well before that. Other times when GP waits less than 60 seconds, netlogon has still not completed a successful session to a DC.

How does Group Policy determine when the network subsystem is available?

Answer 1

Well, I think we'll have to guess a bit because this is not well documented...

First, let's take a look at the GPSvc debug logs:

Enable Group Policy Service (GPSvc) logging

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
DWORD value: GPSvcDebugLevel set to 30002 (Hexadecimal)

and search for Connectivity in the log file. This will give an insight about what's happening.

In this log file, we can also see: CoCreateInstance for INetworkListManager succeeded

So, I think it's safe to assume that the Network List Manager is used to determine the status of the networks available on the computer. Most importantly, Network List Manager can send notifications to various system components about changes in network connectivity.
Network List Manager can also tell if we are connected to a Domain network.

That being said, I think you may find useful informations in the NlaSvc logs too (Network Location Awareness, related to Network List Manager):

In the Event Viewer -> View -> Show analytic and debug logs. Then:
Applications and Service logs -> Microsoft -> Windows -> NlaSvc -> Diagnostic (right click to Enable this log) and see if you can find useful bits in there. You should be able to see if NLA was able to find a Domain (DsGetDcName).

How does Group Policy determine when the network subsystem is available?

My guess is that the Group Policy Service listens for notifications sent by Network List Manager when Network connectivity changes (network cable plugged/unplugged, Net adapter enabled/disabled, received an IP address, ...), I think Network List Manager / NLA are the ones doing the job to determine if the network provides domain connectivity.

Answer 2

It does seem that Group Policy leverages the Network List Manager API, and that the Network List Manager API leverages the Network Location Awareness service and NETLOGON when determining network status and connectivity.

I believe the core of this problem is the behavior of Zscaler. Although the connectivity to a domain using Zscaler is similar to that of a VPN, unlike a VPN, Zscaler does not create a secondary network interface on the system. Therefore, when Zscaler establishes a tunnel, there is no "change" to trigger the domain detection.

What seems to happen is that if the tunnel is a little late coming online after boot, the services that were looking for domain connectivity are sitting and waiting to detect a network change - such as a new network interface coming online, or routes changing. But Zscaler doesn't trigger those changes when it brings a tunnel online. Instead, the "wait for connectivity" process times out and doesn't detect that the domain has become available.

After a lot of research and testing, I believe the following registry change was key to resolving the issue. However, it is not documented so I have no idea exactly what it does. My understanding is that it makes the NLA service look for the domain more aggressively which allows it to detect connectivity to the domain once Zscaler establishes a tunnel, regardless of timing.

HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters

(DWORD) AlwaysExpectDomainController = 1

Prior to this change, it seemed that Group Policy would wait between 13 to 20 seconds for domain connectivity, and anything Zscaler delay over that it would timeout at 60 seconds. After this change, I was able to see Group Policy wait 33 seconds for domain connectivity without timing out.

This registry change is referenced in the following similarly related articles: https://community.zscaler.com/zenith/s/question/0D54u00009jYrfzCAC/windows-network-location-awareness

https://learn.microsoft.com/en-us/answers/questions/400385/network-location-awareness-not-detecting-domain-ne