我正在尝试解决已加入域的远程计算机的一些组策略启动处理问题，这些计算机在启动时和登录前建立 Zscaler/VPN 连接。这会导致域连接出现短暂延迟，而当计算机物理连接到网络时，通常不会出现这种延迟。
我设置了几个 GPO：
- 计算机启动和登录时始终等待网络
- 指定启动策略处理等待时间 = 60 秒
这会导致以下类型的事件日志条目：
组策略在计算机启动时等待网络子系统 17031 毫秒。
但是，有时该数字会达到 60000 毫秒，这与我的 GPO 一致。因此，本质上，有时 GPO 会检测到“网络子系统”可用，有时则不会。但是，它总是在此时间之后成功下载并应用 GPO。
为了尝试确定组策略如何确定网络可用性，我查看了 netlogon 服务调试日志，认为 DC 发现和连接正在发挥作用。但是，netlogon 在与组策略事件日志条目不一致的时间指示与 DC 的会话设置成功。例如，当 GP 等待 60 秒时，netlogon 在那之前就已经指示与域控制器的连接成功。其他时候，当 GP 等待的时间少于 60 秒时，netlogon 仍未完成与 DC 的成功会话。
组策略如何确定网络子系统何时可用？
答案1
嗯，我想我们必须猜测一下，因为这没有很好的记录......
首先，让我们看一下GPSvc调试日志：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
DWORD 值：GPSvcDebugLevel设置为30002 (Hexadecimal)
并在日志文件中搜索Connectivity。这将让您了解正在发生的事情。
在这个日志文件中我们还可以看到：
CoCreateInstance for INetworkListManager succeeded
因此，我认为可以安全地假设网络列表管理器用于确定计算机上可用网络的状态。最重要的是，网络列表管理器可以向各种系统组件发送有关网络连接变化.
网络列表管理器还可以告诉如果我们连接到域网络。
话虽如此，我认为您也可以在 NlaSvc 日志（网络位置感知，与网络列表管理器相关）中找到有用的信息：
在事件查看器 -> 查看 -> 显示分析和调试日志。然后：
应用程序和服务日志 -> Microsoft -> Windows -> NlaSvc -> 诊断（右键单击以启用此日志）并查看是否可以在其中找到有用的信息。您应该能够看到 NLA 是否能够找到域（DsGetDcName）。
组策略如何确定网络子系统何时可用？
我的猜测是，当网络连接发生变化（插入/拔出网线、启用/禁用网络适配器、接收 IP 地址等）时，组策略服务会监听网络列表管理器发送的通知，我认为网络列表管理器/ NLA 是负责确定网络是否提供域连接的。
答案2
看起来组策略利用了网络列表管理器 API，并且网络列表管理器 API 在确定网络状态和连接时利用了网络位置感知服务和 NETLOGON。
我认为这个问题的核心在于 Zscaler 的行为。虽然使用 Zscaler 连接到域与 VPN 类似，但与 VPN 不同的是，Zscaler 不会在系统上创建辅助网络接口。因此，当 Zscaler 建立隧道时，不存在触发域检测的“变化”。
似乎发生的情况是，如果隧道在启动后上线稍晚，则寻找域连接的服务将处于等待状态，以检测网络变化 - 例如新的网络接口上线或路由更改。但 Zscaler 在使隧道上线时不会触发这些变化。相反，“等待连接”过程会超时，并且不会检测到域已可用。
经过大量研究和测试，我相信以下注册表更改是解决该问题的关键。但是，它没有记录，所以我不知道它到底起什么作用。我的理解是，它使 NLA 服务更积极地寻找域，这使得它能够在 Zscaler 建立隧道后检测到与域的连接，无论时间如何。
HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
(DWORD) AlwaysExpectDomainController = 1
在进行此更改之前，组策略似乎需要等待 13 到 20 秒才能实现域连接，而 Zscaler 延迟超过该时间的任何操作都会在 60 秒时超时。进行此更改后，我能够看到组策略等待 33 秒才能实现域连接而不会超时。
以下类似相关文章引用了此注册表更改： https://community.zscaler.com/zenith/s/question/0D54u00009jYrfzCAC/windows-network-location-awareness