Windows 10：组策略启动后无法直接应用，稍后成功

我的问题是组策略不适用于客户端刚引导时。直接引导后，客户端在源“GroupPolicy（Microsoft-Windows-GroupPolicy）”事件日志和事件ID 1058：“组策略处理失败[…]”的事件日志中发布错误消息。在Details选项卡中，ErrorCode是50，代表ERROR_NOT_SUPPORTED。这不仅仅是一个表面上的问题：这些策略确实没有得到正确应用：例如，映射的networking驱动器不在那里。等待一段时间后，执行“gpupdate”工作，策略正常应用：映射的networking驱动器出现。

我能够重现该问题的最简单的情况：在新安装的Windows Server 2012 R2上新创build的域，客户机是新安装的Windows 10 64位机器。该域由一个域控制器组成，与其他域没有任何关系。

由于错误消息指出Windows无法从域的Sysvol共享中读取.GPT文件，我试图从命令提示符访问相同的文件。事实上，当我开机后立即打开一个命令提示符，我得到这个：

C:\Users\username>dir \\domain.example.com\sysvol The request is not supported.

等待一两分钟后，执行相同的命令会给出一个目录列表。在这一点上运行gpupdate将会正常工作。

我没有设置组策略设置“始终等待networking在计算机启动和login”为“已启用”，并且我知道这个策略是适用的：在同一个策略对象中指定了一个registry设置，当我检查registry在客户端指定的设置在那里。

其他可能相关的因素：

NTLM在域中受到限制，但这似乎并不重要：即使在启用它之后，更新策略并重新启动所有机器，症状仍然相同。
服务器是使用DHCP还是使用静态configuration来configuration并不重要。
域的DNS服务器不支持dynamic更新。必要的logging手动添加（从C：\ Windows \ System32 \ config \ netlogon.dns）
hibernate状态在客户端被禁用（使用powercfg /h off ），因此每次启动都是完全启动，而不是快速启动
策略启动策略处理等待时间设置为120秒
与DC的连接正常工作。坪将工作。 closures客户端，在AD中禁用我的帐户，打开客户端将导致客户端不能login我的帐户：它会立即注意到帐户被禁用。
除了这个问题，我没有注意到任何不寻常的事情。

这似乎是一个中小企业问题比组策略问题。在服务器端嗅探连接显示了一些有趣的事情：第一次执行命令dir \\domain.example.com\sysvol ，DC上的Microsoft Message Analyzer中显示以下内容：

客户端build立到DC的端口445的TCP连接，并且成功执行ComNegotiation（DialectRevision：0x02FF）。
紧接着，一个谈判成功执行。 DialectRevision是0x0302。
紧接着，客户端用TCP RST（??）closuresTCP连接

每隔一段时间我发出命令并得到错误，步骤2和3发生。

当命令开始工作时，执行步骤1和步骤2，但不是客户端发送TCP RST，而是执行SessionSetup，然后发生TreeConnect，然后发生大量（看似正常）的SMB喋喋不休。

因此，看起来客户端在启动后一两分钟内就无法正确地与SMB交谈，导致组策略处理失败。

任何人都知道我可以如何debugging和解决这个问题？

从Windows 8开始，微软引入了“快速启动”的概念，当你closures操作系统的时候，就像Hibernate在正常的hibernate情况下一样，hibernate操作系统内存。这会导致操作系统速度更快，但是它也具有在启动时禁用每台计算机GP处理的副作用。这可能是您所看到的，可以通过禁用“计算机configuration\策略\pipe理模板\系统\关机”下的策略来禁用此function。要求使用快速启动

如果这不能解决问题，则最有可能出现networking堆栈计时问题，即在networking堆栈完全初始化之前计算机的GP处理正在启动。从XP开始并在Windows 7中开始，Microsoft在计算机configuration\策略\pipe理模板\系统\组策略\启动策略处理等待时间下添加了一个策略，您可以在启动之前增加GP等待的时间。尝试将其设置为60秒，看看是否有帮助。

达伦

我自己设法解决了这个问题。作为参考这里是什么解决了我的问题：

首先，我错误地认为禁用NTLM的所有阻塞导致了相同的症状。它导致了不同的症状，碰巧有相同的效果。如果没有任何NTLM阻止策略生效，则dir命令现在会导致访问被拒绝错误。组策略仍然不适用，这是有道理的：SYSVOL仍然无法访问。

一些networkingsearch告诉我，我知道有一个更常见的问题。虽然。显然，Windows 10客户端可能会遇到访问SYSVOL共享域控制器（也可能是NETLOGON共享）的问题。据说Windows 10改变了访问这些共享的方式，这可能会导致问题。解决方法是通过为Windows 10客户端设置“硬化的UNCpath”组策略来禁用这些共享的客户端上的UNCpath强化，如下所示：

 \\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0 \\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

（如果您在从Windows 10客户端访问Netlogon共享时遇到问题，则可以帮助将该共享的全部三个参数设置为零。）

有关详细信息，请参阅Microsoft的MS15-011文章。它包含了对改变这个设置的安全影响的一个很好的描述，以及如何改变这个策略的详细步骤。

警告：请注意，上面的设置会禁用部分或全部保护措施，以防MS15-011的安全问题！不要盲目地复制/粘贴它们，而是要根据所涉及的风险做出明智的决定。此外，这个问题很可能在未来的某个时候得到解决。发生这种情况时，请不要忘记将此策略设置为build议值，如MS15-011中所述。

我尝试了几个build议，包括registry更改和本地组策略更改，其中没有一个解决了问题 – 映射驱动器仍然在启动时被X. 一个gpupdate会每次修复它，但这是用户的一个额外的步骤。

最终修复的是手动映射networking驱动器，replace每个GPO条目。没有必要断开和replace，我把它们映射成相同的，只是手动。

对于任何发现此线程的人员，仅供参考，通过将相互身份validation设置为0来closuresUNC强化将禁用您的一些安全性。我们运行与win7客户端相同的问题，我试图与微软合作。他们告诉我这是一个bug，但到目前为止，还没有给我一个方法来跟踪错误何时得到解决。