组策略：映射的驱动器无法加载，Windows Server 2012 Active Directory和Windows Pro 10

网络：

• 多站点域。
• 每个站点都有2个本地（站点，同一子网）Windows Server 2012 R2域控制器。
• 在Windows站点和服务中正确定义了站点。
• 每个站点的DNS记录仅定义了两个本地DNS服务器。
• 所有客户端都是具有所有更新的Windows 10 Pro 64位。
• 这两个网络都是完全千兆的，运行在经过认证的CAT6电缆的Cisco交换机上。
• 每个站点都有一个本地（站点上相同的子网）Synology存储服务器。
• 作为组策略的一部分，两个网络驱动器映射到Synology服务器上的共享。

连接诊断：

• dcdiag /test:dns /v /c /ePASS所有服务器和所有测试的报告
• echo %logonserver% 总是返回本地DC
• nltest /dsgetdc 始终显示本地DC和正确的本地IP
• 在站点A上，两个网络驱动器均出现，可能出现故障的可能性为0.5％（我经历了几次启动，这些驱动器无法正确显示）。

问题：

在站点B，网络驱动器可能无法显示30％的时间。有时是两个驱动器，有时是一个或另一个。该问题主要是随机的，并且似乎没有跟随任何特定的用户或工作站。

症状：

在出现问题的30％的时间中：

• 5％的时间a gpupdate或gpupdate /force将解决问题，驱动器将立即出现。如果gpupdate在第一次尝试中不起作用，那么在此之后它将几乎不再起作用（对于该引导）
• 在时间的5％gpupdate或gpupdate /force将导致只有一个驱动器出现
• 20％的时间，a gpupdate不能解决问题，但是下次启动会很好
• 50％的时间，a gpupdate不能解决问题，但是在一次引导和另 一次引导之后gpupdate，驱动器将出现

• 在20％的时间中，驱动器将出现多次重新引导（gpupdate每次引导）。有时是2次引导，但是有时驱动器出现之前我很少需要重启计算机6到7次。

  • 在最后20％的时间内，我有时会从gpupdate进程中得到错误。

    The processing of Group Policy failed. Windows attempted to read the file 
    \domain\SysVol\domain.local\Policies{5898270F-33D0-41E8-A516-56B3E6D2DBAB}\gpt.ini 
    from a domain controller and was not successful. Group Policy settings may not be 
    applied until this event is resolved. This issue may be transient and could be 
    caused by one or more of the following:  
    
    a) Name Resolution/Network Connectivity to the current domain controller.  
    b) File Replication Service Latency (a file created on another domain controller 
       has not replicated to the current domain controller).  
    c) The Distributed File System (DFS) client has been disabled.
    

  • 实际上，通常但并非总是此错误是一个好兆头，因为通常在收到此错误后，下一次“ gpupdate”或下一次引导和“ gpupdate”将使驱动器重新出现。

驱动器地图诊断：

1. gpresult /h gpresult.html 显示：

   Drive Map (Drive: X)
    The following settings have applied to this object. Within this category, settings nearest the top of the report are the prevailing settings when resolving conflicts.
      X:
       Winning GPO  DriveMaps 
        General Settings
         Result: Success
   

2. 我启用了组策略环境调试日志记录（根据 http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx创建的注册表项[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002）。日志文件中c:\Windows\debug\UserMode\gpsvc.log没有显示任何明显的错误，也无法通过Google找到很多帮助。这是我收到的一些有趣的消息：

   GPSVC(158.33c) 23:33:24:921 CheckGPOs: No GPO changes but extension Group Policy Drive Maps's returned error status 183 earlier.  
   GPSVC(158.c24) 23:38:12:203 ProcessGPOs(Machine): Extension Group Policy Drive Maps skipped with flags 0x110057. 
   GPSVC(158.157c) 23:08:08:216 ProcessGPOs(User): Extension Group Policy Drive Maps ProcessGroupPolicy failed, status 0xb7.
   

3. 我已为云端硬盘地图启用了组策略首选项调试功能（根据http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx设置Drive Map Policy Processing为，Enabled并Event Logging在的属性中启用\Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing。日志文件C:\ProgramData\GroupPolicy\Preference\Trace\User.log未返回任何错误。

   2015-11-21 17:47:38.849 [pid=0x22c,tid=0xcd0] Starting class <Drive> - X:.
   2015-11-21 17:47:38.864 [pid=0x22c,tid=0xcd0] Adding child elements to RSOP.
   2015-11-21 17:47:38.880 [pid=0x22c,tid=0xcd0] Beginning drive mapping.
   2015-11-21 17:47:38.896 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] User does not have a split token.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] Drive doesn't exist (full token).
   2015-11-21 17:47:39.114 [pid=0x22c,tid=0xcd0] Connected with access name x:.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification Session ID is 2.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification discovered drive mask of 8388608.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] SendNotification drive event broadcast sent.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] SendNotification to Shell.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Properties handled.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Handle Children.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] EVENT : The element of user preferences 'X:' of the group policy object 'DriveMaps {06FEB8B9-632C-4A1C-A7C9-5A05E1041BEE}' was applied correctly.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] Completed class <Drive> - X:.
   

4. 我还对登录进行了几次netmon捕获，但驱动器加载失败，但是捕获的信息太多，我不确定从哪里开始。

5. 如果登录失败后，我尝试直接浏览到\\SynologyServer\ShareName\，则共享总是立即立即加载而没有任何错误。没有连接或权限问题的迹象。

题：

当两个站点都位于同一域，具有相同的策略并且运行相同的软件时，为什么在一个站点上如此频繁地发生此问题，而在另一个站点上却几乎从未发生过此问题？

我能想到的唯一软件差异是，在站点A上，所有计算机都运行Windows 8.1 Pro并已升级到Windows 10 Pro，而在站点B上，所有计算机都重新安装了Windows 10 Pro。

由于我几乎没有代表，所以我还不能提出问题，所以我会在发布答案的同时尝试提出问题，希望我不要罐头。;）

我将假设您通过针对另一Windows系统上的“传统” UNC共享测试此GPO来确保本案的GPO部分不是问题。我认为重要的缺失信息是Synology设备是否已加入域。许多基于Linux的NAS单元（例如Synology，QNAP等）都嵌入了软件组件，使它们可以参与Active Directory域。此设备是否参与域会影响解决方案。

就是说，我的网络中有与T1电路互连的远程设施。由于系统要求，我们要求在所有系统上使用Acronis映像备份。因此，通过T1远程备份Windows工作站的多GB映像是不容易的。因此，我们将Drobo NAS单元放置在每个本地网段上，以解决此问题并为我们提供一些容错能力。这些特定的Drobos没有参与AD域的能力。

要启用配置的UNC共享，我们必须设置两个主要内容。首先，我们在DNS服务器上创建了静态DNS条目，以进行正确的名称解析。其次，我们不得不“松开” DISA通常建议大多数域成员使用的两个策略。我们仅放松了备份服务器上的这些策略，并在“慢速链接”站点上备份了工作站，因为这些是唯一需要访问各自共享的系统：

• 计算机配置\ Windows设置\安全设置\安全选项：
  • Microsoft网络客户端：数字签名通信（始终）=禁用
  • Microsoft网络客户端：向第三方SMB服务器发送未加密的密码=启用
  • Microsoft网络服务器：数字签名通信（始终）=禁用

仍将“协商时进行数字签名通信”的GPO设置为“已启用”，从而减轻了所涉及的一些安全风险。一旦启用了这些更改，就可以立即通过UNC路径访问共享，而以前是不可能的。

这就是为什么我之前说过，根据您的NASes是否可以参与域来确定解决方案的路径。如果他们可以参与，那么DNS和“ SMB”组策略对您来说将不是问题，因此解决方案将摆在其他地方。如果他们不能参加（例如我的NASes），那么这可能是您的解决方案。

好吧，我找到了这些线程，这听起来与我的情况几乎相同：

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

Windows 8.1 / 10 GPO映射的驱动器无法连接

显然，此问题是由Microsoft默认情况下在Windows 10中启用UNC强化引起的。这是为了修复安全漏洞，但显然是无意间导致映射驱动器安装不可靠。毫不奇怪，微软似乎尚未解决此错误（或已经解决了？）

这也解释了为什么我在站点A上没有任何问题。由于那里的所有计算机都已从Windows 8.1 Pro升级到Windows 10，因此我认为有关UNC强化的设置已从Windows 8转移并保持关闭状态，而具有最新功能的计算机安装Windows 10使用UNC硬化的默认上。

我实际上还没有尝试过该解决方案，但是它似乎太适合我的症状，没有相关性。我担心一种解决方案会使我的系统面临更多的安全威胁，因此我正在寻找替代方案。我不喜欢通过组策略进行设置的想法，我想知道是否有可能仅通过手动编辑注册表来关闭UNC强化。在决定下一步要做什么之前，我想先在几台计算机上进行实验。但是，我目前只能找到通过GPO或GPP更改设置的步骤...

有什么想法吗？

我只想更新此内容，并说某个主要Windows 10更新在某个时候解决了此问题。这是一个古老的问题，但是我不希望把事情挂掉，以防万一。

阅读完您在更新Daniel中提供的所有内容后，我实际上建议UNC强化（虽然相关）不是这里的根本原因，并且它实际上可能是“ fastboot”选项，第二篇文章的OP说过解决了他的问题。有关UNC强化的所有信息都涉及SYSVOL和NETLOGON共享，它们在默认情况下会得到强化。虽然该问题将阻止您的客户端接收GP更新，但事实是Drive Map GPO已经至少对相关客户端应用了一次，并且不需要在每次重新启动后重新应用（即使确实如此）也可以执行映射。

显然，您将要独立于每个选项进行测试，但是无论哪个选项可能有效或无效，这一道理似乎都与问题的根本原因很接近。