dcdiag /test:dns /v /c /e报告所有服务器和所有testing的PASS echo %logonserver% 总是返回一个本地DC nltest /dsgetdc 总是显示本地DC和正确的本地IP 在B站点，networking驱动器可能无法显示30％的时间。 有时它是两个驱动器，有时是一个或另一个。 问题大多是随机的，似乎并不遵循任何特定的用户或工作站。
在问题出现的30％的时间里：
gpupdate或gpupdate /force将解决问题，驱动器将立即出现。 如果gpupdate在第一次尝试时不起作用，那么之后几乎不会起作用（对于该引导） gpupdate或gpupdate /force将导致只有一个驱动器出现 gpupdate不会解决这个问题，但下一次启动将罚款 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'会使驱动器重新出现。
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
我已启用组策略环境debugging日志logging（每个http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx创build的registry项[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002 ）。 在c:\Windows\debug\UserMode\gpsvc.log的日志文件没有显示任何明确的错误，也没有能够通过谷歌find很多帮助。 以下是我收到的一些有趣的消息：
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.
我已经为云端硬盘地图启用了组策略首选项debugging（根据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并在\Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing属性中打开Event Logging 。 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:.
我也有几个netmon捕获的login驱动器加载失败，但捕获有这么多的信息，我不知道从哪里开始。
如果在登入失败后，我试着直接浏览到\\SynologyServer\ShareName\ ，共享总是立即载入，没有任何错误。 没有连接或权限问题的迹象。
为什么这个问题在一个站点上频繁发生，但是几乎从不在另一个站点上，这两个站点都在同一个域上，具有相同的策略，并运行着相同的软件？
我能想到的惟一软件差异是在A站点，所有的计算机都运行Windows 8.1 Pro，并升级到了Windows 10 Pro，而在B站点，所有的计算机都安装了新的Windows 10 Pro。
由于我几乎没有代表，所以我现在还不能提出问题，所以我会试着在提问的同时提出问题，希望我不会得到jar装。 ;）
我假定您已经通过testing此GPO针对另一个Windows系统上的“传统”UNC共享来确保GPO部分不是问题。 虽然在我看来，重要的缺失信息是Synology设备是否join到域中。 Synology，QNAP等许多基于Linux的NAS设备都embedded了允许其参与Active Directory域的软件组件。 无论该设备是否参与该域，都会影响解决scheme。
也就是说，我在我的networking中有与T1电路相连的远程设备。 由于系统要求，我们要求在所有系统上使用Acronis映像备份。 因此，通过T1远程备份Windows工作站的多GB映像是非启动器。 所以我们在每个本地网段都放置了Drobo NAS单元来克服这个问题，并给了我们一点容错性。 这些特定的Drobos不具备参与AD域的能力。
为了configurationUNC股票，我们必须设置两个主要的东西。 首先，我们在DNS服务器上创build了静态DNS条目，以便进行适当的名称parsing。 其次，我们必须“放宽”DISA通常为大多数域名成员推荐的两个政策。 我们只是放松了备份服务器上的这些策略，并且在“慢速链接”站点上备份工作站，因为这些是唯一需要访问相应共享的系统：
“如果经过协商数字签署通信”的GPO仍然设置为“已启用”，可以减轻一些涉及的安全风险。 一旦我们启用这些更改，可以立即通过UNCpath访问共享，而以前这是不可能的。
这就是为什么我之前说过，取决于你的NAS是否可以参与这个领域，或者不能确定解决scheme的path。 如果他们能够参与进来，那么DNS和“SMB”小组政策对你来说应该不是问题，因此解决办法就在别处。 如果他们不能参与（像我的NAS），那么这可能是你的解决scheme。
那么，我发现这些线程，这听起来像一个几乎相同的情况下，我的：
Windows 10：组策略启动后无法直接应用，稍后成功
Windows 8.1 / 10 GPO映射的驱动器将不能连接
显然这个问题是由微软默认启用Windows 10中的UNC Hardening造成的。 这是为了解决安全漏洞，但显然无意中导致映射的驱动器安装不可靠。 毫不奇怪，似乎微软还没有解决这个错误（或者他们？）
这也解释了为什么我在网站A没有问题。因为那里的所有电脑都已经从Windows 8.1 Pro升级到了Windows 10，所以我认为有关UNC加强的设置从Windows 8转移了下来 ，而新鲜的电脑Windows 10的安装使用了默认的UNC Hardening。
实际上我还没有尝试过这个解决scheme，但是似乎完全适合我的症状，而不是相关的。 我担心一个解决scheme，打开我的系统，以更多的安全威胁，所以我正在寻找替代品。 我不喜欢通过组策略设置这个想法，我想知道是否可以通过手动编辑registry来closuresUNC强化。 在我决定下一步做什么之前，我想先试用一些电脑。 但是，我只能find通过GPO或GPP当前更改设置的步骤…
有什么想法吗？
在阅读Daniel提供的更新内容之后，我会真的build议UNC强化，虽然相关，但并不是这里的根本原因，它可能实际上是“fastboot”选项，第二篇文章的OP表示解决了他的问题。 所有关于UNC加固的信息都是在默认情况下使用SYSVOL和NETLOGON共享的。 虽然这个问题会阻止您的客户端接收GP更新，但事实上，Drive Map GPO已经向相关的客户端应用了至less一次，并且在每次重新引导（即使它）执行后都不需要重新应用映射。
很明显，你会想要独立于另一个testing每个选项，但无论哪个选项可能或不可能工作，这条推理似乎接近你的问题的根源。