主页 / server / 问题 / 738085
Accepted
Daniel
Asked: 2015-11-22 15:46:09 +0800 CST

组策略：映射驱动器加载失败、Windows Server 2012 Active Directory 和 Windows Pro 10

  • 772

网络：

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

连接诊断：

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

问题：

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

症状：

在出现问题的 30%的时间里：

  • 5% 的时间 agpupdate或gpupdate /force将解决问题，驱动器将立即出现。如果gpupdate在第一次尝试时不起作用，那么之后它几乎永远不会起作用（对于那个启动）
  • 5% 的时间 agpupdate或gpupdate /force将导致只出现一个驱动器
  • 20% 的情况下，agpupdate无法解决问题，但下次启动就可以了
  • 50% 的情况下，agpupdate无法解决问题，但在一次又一次 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. 我已启用 Drive Maps 的组策略首选项调试（根据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。

group-policy

4 个回答

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

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

    话虽如此，我的网络中有远程设施与 T1 电路互连。由于系统要求，我们要求在所有系统上使用 Acronis 映像备份。因此，通过 T1s 远程备份 Windows 工作站的多 GB 映像是不可能的。因此，我们在每个本地网段上放置了 Drobo NAS 单元来克服这个问题并给我们一些容错能力。这些特定的 Drobo 没有参与 AD 域的能力。

    要按照配置启用 UNC 共享，我们必须设置两个主要内容。首先，我们在 DNS 服务器上创建了静态 DNS 条目以允许正确的名称解析。其次，我们不得不“放宽” DISA 通常推荐给大多数域成员的两项政策。我们只是放松了备份服务器上的这些策略，以及在“慢速链接”站点上备份的工作站，因为这些是唯一需要访问相应共享的系统：

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

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

    这就是为什么我之前说取决于你的 NASes 是否可以参与域来确定解决方案的路径。如果他们可以参与，那么 DNS 和“SMB”组策略对您来说应该不是问题，因此解决方案将在别处。如果他们不能参与（比如我的 NASes），那么这可能是您的解决方案。

    • 1

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

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

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

    显然，此问题是由 Microsoft 默认在 Windows 10 中启用 UNC Hardening 引起的。这是为了修复一个安全漏洞，但显然无意中导致映射驱动器安装不可靠。毫不奇怪，微软似乎还没有解决这个错误（或者他们有吗？）

    这也解释了为什么我在站点 A 没有问题。由于那里的所有计算机都已从 Windows 8.1 Pro 升级到 Windows 10，我假设有关 UNC Hardening 的设置从 Windows 8 转移并保持关闭，而新的计算机安装 Windows 10 时使用了默认的 UNC Hardening on .

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

    有什么想法吗？

    • 1
  3. Best Answer

    我只是想更新它，并说在某个时候，Windows 10 的主要更新之一修复了这个问题。这是一个老问题，但我不喜欢让事情悬而未决，以防万一。

    • 1

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

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

    • 0

相关问题