我的问题是，客户端刚启动时未应用组策略。启动后，客户端会在事件日志中发布一条错误消息，其来源为“GroupPolicy (Microsoft-Windows-GroupPolicy)”，事件 ID 为 1058：“组策略处理失败。[...]”。在“详细信息”选项卡中，ErrorCode 为 50，代表 ERROR_NOT_SUPPORTED。这不仅仅是一个表面问题：策略确实没有正确应用：例如，映射的网络驱动器不存在。等待一段时间后，执行“gpupdate”即可，策略可正常应用：映射的网络驱动器出现。
我能够重现该问题的最简单的场景是：在新安装的 Windows Server 2012R2 上新建域，客户端是新安装的 Windows 10 64 位计算机。该域仅由一个域控制器组成，与其他域没有任何关系。
由于错误消息表明 Windows 无法从域的 Sysvol 共享中读取 .GPT 文件，因此我尝试从命令提示符访问同一个文件。事实上，当我在启动后立即打开命令提示符时，我得到了以下信息：
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
等待一两分钟后，执行相同的命令将给出目录列表。此时运行 gpupdate 就可以了。
我确实将组策略设置“在计算机启动和登录时始终等待网络”设置为“已启用”，并且我知道此策略已应用：在同一个策略对象中指定了注册表设置，并且当我在客户端上检查注册表时，指定的设置就在那里。
其他可能相关因素：
- NTLM 在域中受到限制，但这似乎并不重要：即使启用它、更新策略并重新启动所有机器后，症状仍然相同。
- 服务器是使用 DHCP 配置还是静态配置都没有关系。
- 域的 DNS 服务器不支持动态更新。必要的记录已手动添加（来自 C:\Windows\System32\config\netlogon.dns）
- 客户端上禁用休眠功能（使用
powercfg /h off），因此每次启动都是完全启动，而不是快速启动 - 策略启动策略处理等待时间设置为 120 秒
- 与 DC 的连接正常。Ping 可以正常工作。关闭客户端，禁用 AD 中的我的帐户，打开客户端将导致客户端无法登录：它会立即注意到该帐户已被禁用。
- 除了这个问题之外，我没有发现任何异常。
这似乎更像是 SMB 问题，而不是组策略问题。嗅探服务器端的连接会显示一些有趣的东西：我第一次执行该命令时dir \\domain.example.com\sysvol，DC 上的 Microsoft Message Analyzer 中显示以下内容：
- 客户端与 DC 的 445 端口建立 TCP 连接，并成功执行 ComNegotiation（DialectRevision：0x02FF）。
- 紧接着，协商成功。DialectRevision 为 0x0302。
- 此后，客户端立即使用 TCP RST（??）关闭 TCP 连接。
每次我发出命令并出现错误时，都会发生步骤 2 和 3。
当命令开始工作时，会发生步骤 1 和 2，但客户端不是发送 TCP RST，而是执行 SessionSetup，然后执行 TreeConnect，然后发生大量（看似正常的）SMB 聊天。
因此，看起来客户端在启动后一两分钟内无法正确地与 DC 进行 SMB 通信，这导致组策略处理失败。
有人知道我该如何调试并解决这个问题吗？
答案1
从 Windows 8 开始，微软引入了“快速启动”的概念，即当您关闭操作系统时，它们会休眠操作系统的内存占用，就像休眠在正常休眠情况下的工作方式一样。这会导致操作系统启动速度更快，但它也有副作用，即在启动时禁用每台计算机的 GP 处理。这可能是您所看到的，可以通过禁用“计算机配置\策略\管理模板\系统\关机\要求使用快速启动”下的策略来禁用它
如果这不能解决问题，那么很可能是网络堆栈计时问题，即计算机的 GP 处理在网络堆栈完全初始化之前就开始了。这个问题从 XP 开始就存在，从 Windows 7 开始，Microsoft 在计算机配置\策略\管理模板\系统\组策略\启动策略处理等待时间下添加了一个策略，您可以在其中增加 GP 在启动前等待的时间。尝试将其设置为 60 秒，看看是否有帮助。
达伦
答案2
我自己设法解决了这个问题。参考以下解决了我的问题：
首先，我错了，禁用所有 NTLM 阻止会导致同样的症状。它导致了不同的症状，碰巧有同样的效果。没有任何 NTLM 阻止策略生效，该dir命令现在导致拒绝访问错误。组策略仍然不适用，这是有道理的：SYSVOL 仍然无法访问。
不过，经过一番网络搜索，我发现有一个更常见的问题。显然，Windows 10 客户端在访问域控制器的 SYSVOL 共享（可能还有 NETLOGON 共享）时会遇到问题。据说 Windows 10 改变了访问这些共享的方式，这可能会导致问题。解决方法是禁用客户端上这些共享的 UNC 路径强化，方法是为 Windows 10 客户端设置“强化 UNC 路径”组策略，如下所示：
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
（如果您在从 Windows 10 客户端访问 Netlogon 共享时遇到问题，则将该共享的所有三个参数都设置为零也会有所帮助。）
查看Microsoft 关于 MS15-011 的文章了解更多信息。它很好地描述了更改此设置的安全隐患，以及如何更改策略的详细步骤。
警告：请注意上面的设置禁用针对 MS15-011 安全问题的部分或全部保护措施已创建！不要只是盲目地复制/粘贴它们，但要根据所涉及的风险做出明智的决定。此外，这个问题很可能在未来的某个时候得到解决。当这种情况发生时，不要忘记将此策略设置为 MS15-011 中描述的推荐值。
答案3
仅供其他找到此帖子的人参考，通过将相互身份验证设置为 0 来关闭 UNC 强化会禁用部分安全性。我们在使用 win7 客户端时遇到了同样的问题，我试图与 Microsoft 合作解决它。他们告诉我这是一个错误，但到目前为止还没有给我一种方法来跟踪何时会解决该错误。
请参阅此其他主题以获取更多信息 https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64
答案4
我尝试了几种建议，包括更改注册表和更改本地组策略，但都没有解决问题——映射驱动器在启动时仍然被 X 化。每次使用 gpupdate 都会修复它，但这对于用户来说是一个额外的步骤。
最终修复该问题的方法是手动映射网络驱动器，替换每个驱动器上的 GPO 条目。无需断开连接并替换，我按照与映射时相同的方式映射它们，只是手动操作。