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

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

网络:

  • 多站点域名。
  • 每个站点有 2 个本地(现场、同一子网)Windows Server 2012 R2 域控制器。
  • 站点在 Windows 站点和服务中正确定义。
  • 每个站点的 DNS 记录仅定义了两个本地 DNS 服务器。
  • 所有客户端均为 Windows 10 Pro 64 位并已包含所有更新。
  • 两个网络均为全千兆网络,运行在配有经过认证的 CAT6 电缆的思科交换机上。
  • 每个站点都有一个本地(现场,同一子网) Synology 存储服务器。
  • 作为组策略的一部分,两个网络驱动器被映射到 Synology 服务器上的共享。

连接诊断:

  • dcdiag /test:dns /v /c /ePASS所有服务器和所有测试的报告
  • echo %logonserver% 总是返回本地 DC
  • nltest /dsgetdc 总是显示本地 DC 和正确的本地 IP
  • 在站点 A 上,两个网络驱动器均显示出来,发生故障的概率大概为 0.5%(我经历过几次启动时驱动器无法正确显示的情况)。

问题:

在站点 B,网络驱动器大约有 30% 的时间无法显示。有时两个驱动器都出现问题,有时只有一个驱动器出现问题。该问题大多是随机的,似乎与任何特定用户或工作站无关。

症状:

在这 30% 中问题出现的时间:

  • 5% 的时间gpupdate,或gpupdate /force将解决问题,驱动器将立即出现。如果gpupdate第一次尝试不起作用,那么此后它几乎永远不会起作用(对于该启动)
  • 5% 的时间 agpupdategpupdate /force只会导致一个驱动器出现
  • 20% 的情况下,gpupdate无法解决问题,但下次启动就会正常
  • 50% 的情况下,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没有显示任何明显的错误,我也没有通过谷歌找到太多帮助。以下是我收到的一些有趣的消息:

    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 tracingC:\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。

答案1

由于我几乎没有声誉,所以我还不能提问,所以我会尝试在发布答案的同时提出问题,并希望我不会被解雇。;)

我假设您已确保此案例的 GPO 部分不是问题,方法是在另一个 Windows 系统上针对“传统”UNC 共享测试此 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 路径访问共享,而以前这是不可能的。

这就是为什么我之前说过,解决方案的路径取决于您的 NAS 是否可以参与域。如果它们可以参与,那么 DNS 和“SMB”组策略对您来说应该不是问题,因此解决方案就在别处。如果它们不能参与(就像我的 NAS 一样),那么这可能是您的解决方案。

答案2

好吧,我发现了这些线索,听起来和我的情况几乎相同:

Windows 10:组策略在启动后无法直接应用,稍后成功

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

显然,这个问题是由于微软默认在 Windows 10 中启用 UNC 强化而引起的。这是为了修复一个安全漏洞,但显然无意中导致映射驱动器安装不可靠。毫不奇怪,微软似乎还没有解决这个问题(或者他们已经解决了吗?)

这也解释了为什么我在站点 A 没有遇到任何问题。由于那里的所有计算机都已从 Windows 8.1 Pro 升级到 Windows 10,因此我认为有关 UNC 强化的设置已从 Windows 8 转移并保留下来离开而全新安装 Windows 10 的计算机则使用默认的 UNC 强化

我还没有真正尝试过这个解决方案,但它似乎太完美地适合我的症状了,所以不相关。我担心这个解决方案会让我的系统面临更多的安全威胁,所以我正在寻找替代方案。我不喜欢通过组策略设置它的想法,我想知道是否可以通过手动编辑注册表来关闭 UNC 强化。我想先在几台电脑上试验一下,然后再决定下一步怎么做。但是,我目前只能找到通过 GPO 或 GPP 更改设置的步骤……

有什么想法吗?

答案3

我只想更新一下,说一下,Windows 10 的某个主要更新在某个时候修复了这个问题。这是一个老问题,但我不想把事情悬而未决,以防万一。

答案4

在阅读了 Daniel 更新中提供的所有内容后,我实际上认为 UNC 强化虽然相关,但并不是根本原因,实际上可能是第二篇帖子的 OP 所说的“fastboot”选项解决了他的问题。所有关于 UNC 强化的信息都提到了默认情况下强化 SYSVOL 和 NETLOGON 共享。虽然该问题会阻止您的客户端接收 GP 更新,但事实是 Drive Map GPO 已至少应用于相关客户端一次,并且不需要在每次重新启动后重新应用(即使它确实需要)来执行映射。

显然,您需要独立地测试每个选项,但无论哪个选项可能有效或无效,这种推理似乎接近问题的根本原因。

相关内容