我们最近将 Windows 网络迁移到使用 DFS 共享文件。DFS 运行良好，但有一个恼人的问题：当用户尝试访问他们有一段时间没有访问过的 DFS 命名空间时，会遇到明显的延迟。我尝试过解决该问题，但目前还没有成功，我希望这里有人可以提供一些建议来帮助解决该问题。
首先，介绍一下我们的网络背景：
网络使用 Windows 2008 功能级别 Active Directory 域，该域包含两个 Windows 2008 DC 和两个 DNS 服务器（每个 DC 上一个）。网络仅 DNS - 没有 WINS。所有计算机都位于同一站点并通过千兆以太网连接。我们在 Windows 2008 模式下有大约 20 个基于域的 DFS 命名空间，每个 DFS 命名空间都有两个 Windows 2008 DFS 命名空间服务器（所有命名空间都有相同的两个服务器）。所有命名空间服务器都处于 FQDN 模式，并且所有文件夹目标都使用其 FQDN 指定。所有计算机都已安装最新的 Service Pack 和补丁。
实际的文件夹目标（即我们的 DFS 文件夹指向的 SMB 共享）分散在多个文件和应用程序服务器上，所有服务器都运行 Windows 2008，但两台应用程序服务器运行 Windows 2003 R2，根本没有设置复制（例如，所有 DFS 文件夹当前只有一个文件夹目标）。
有关该问题的更多细节：
命名空间访问延迟通常为 1 到 10 秒，似乎发生在某台计算机大约五分钟或更长时间内未访问请求的命名空间时。
例如，如果用户超过五分钟未访问 \\domain.name\namespace1\，并尝试通过 Windows 资源管理器访问 \\domain.name\namespace1\，则资源管理器窗口将冻结 1 - 10 秒，然后最终恢复并显示 \\domain.name\namespace1 中的文件夹。如果他们随后关闭资源管理器窗口并在五分钟内再次尝试访问 \\domain.name\namespace1\，则内容将几乎立即显示 - 如果他们等待的时间超过五分钟，它将再次经历 1 - 10 秒的暂停。
一旦“进入”命名空间，一切都会变得顺利而敏捷，只是与命名空间的初始连接速度较慢。
浏览延迟似乎影响我们使用的所有 Windows 版本（Windows 2008 x64 SP2、Windows 2003 R2 x86 SP2、Windows XP Pro x86 SP3） - Windows XP/2003 可能比 Windows 2008 更糟糕一些，但我不确定这种差异是否仅仅是心理上的。
直接访问底层文件夹目标完全不会出现延迟 - 即，如果直接访问 DFS 指向的 SMB 共享（绕过 DFS），则不会出现暂停。
在故障排除过程中，我注意到我们所有 DFS 根目录的“缓存持续时间”都设置为 300 秒 - 5 分钟。鉴于这是触发暂停所需的相同时间，我假设此缓存在某种程度上是相关的，尽管我不确定客户端上缓存了什么，因此 5 分钟后需要再次查找什么。
在尝试解决该问题时，我已经尝试/检查了以下内容（但没有成功）：
- 在两个域控制器上运行 dcdiag - 未发现任何问题
- 做了一些基本的 DNS 服务器检查，没有发现任何问题 - 我不知道如何详细检查 DNS 服务器，但我想补充一点，网络没有表现出任何其他可能指向 DNS 问题的奇怪行为
- 在客户端和服务器上禁用防病毒软件
- 从几个命名空间中删除一个命名空间服务器 - 没有区别
这就是我要做的事情 - 但我没有任何主意。有人能建议是什么原因导致延迟和/或我下一步应该尝试什么吗？
答案1
嗯，我们最后似乎已经在我们的环境中解决了这个问题。为了其他人的利益，以下是我们发现的问题以及我们解决问题的方法：
为了尝试进一步了解延迟之前/期间/之后发生的情况，我们在客户端计算机上使用 Wireshark 来捕获/分析网络流量，同时该客户端尝试访问 DFS 共享。
这些捕获显示了一些奇怪的事情：每当发生延迟时，在从客户端发送到 DC 的 DFS 请求和从 DC 返回到客户端的 DFS 根服务器的引用之间，DC 都会向网络发送多个广播名称查找。
首先，DC 将广播对 DOMAIN 的 NetBIOS 查找（其中 DOMAIN 是我们的 Windows 2000 之前的 Active Directory 域名）。几秒钟后，它将广播法律硕士DOMAIN 的查找。接下来是另一个广播的 DOMAIN NetBios 查找。广播完这三个查找后（我假设超时），DC 最终会向客户端响应（正确的）DFS 根服务器引用。
只有在打开 DFS 共享出现长时间延迟时，才会发送这些针对 DOMAIN 的广播名称查找，我们可以从 Wireshark 捕获中清楚地看到，直到发送所有三个查找（大约 7 秒后），DC 才返回对 DFS 根服务器的引用。因此，这些广播名称查找显然是造成我们延迟的原因。
既然我们知道了问题所在，我们就开始尝试找出这些广播名称查找发生的原因。经过更多的 Google 搜索和反复试验，我们找到了答案：我们没有将域控制器上的 DfsDnsConfig 注册表项设置为 1，而这是在仅 DNS 环境中使用 DFS 时所必需的。
当我们最初在环境中设置 DFS 时，我们做过阅读有关如何为仅 DNS 环境配置 DFS 的各种文章（例如微软 KB244380以及其他人）并且知道此注册表项，但误解了有关何时/如何使用它的说明。
KB244380表示：
必须将 DFSDnsConfig 注册表项添加到将参与 DFS 命名空间的每台服务器，以便所有计算机都能理解完全限定的名称。
我们认为这意味着必须在 DFS 上设置注册表项命名空间服务器只是，没有意识到域控制器上也需要它。在我们将域控制器上的 DfsDnsConfig 设置为 1（并重新启动“DFS 命名空间”服务）后，问题就消失了。
显然，我们对这个结果很满意，但我要补充一点，我仍然不能 100% 地确信这是我们唯一的问题 - 我想知道将 DfsDnsConfig=1 添加到我们的 DC 是否只是解决了问题，而不是解决问题。我不明白为什么 DC 会在 DFS 引用过程中尝试查找 DOMAIN（域名本身，而不是域中的服务器），即使在非仅 DNS 环境中也是如此，而且我也知道我没有在其他（当然更小/更简单）仅 DNS 环境中的域控制器上设置 DfsDnsConfig=1，也没有遇到同样的问题。不过，我们已经解决了问题，所以我们很高兴。
我希望这对遇到类似问题的其他人有所帮助 - 并再次感谢那些在此过程中提供建议的人。
答案2
这可能是由 DNS 服务器网络掩码排序引起的。我们最近在 Server 2003 中遇到了这个问题。这取决于您当前的子网划分。
例子。
站点 1：IP 子网 10.0.0.0/24 站点 2：IP 子网 10.0.1.0/24
站点 2 中的客户端针对您的基于域的命名空间进行 DNS 查询，并将默认获得站点 1 中的 DFS 服务器，因为 DNS 服务器不知道站点 IP 边界。您需要告诉 DNS 服务器使用哪个子网掩码来识别要响应的 IP 地址。
答案3
Active Directory 团队博客有一篇由三部分组成的文章，全部涉及 DFS 延迟。
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-1-3/ba-p/397167（https://archive.is/OeRqo）
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-2-3/ba-p/397171（https://archive.is/cojW4）
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-3-3/ba-p/397175（https://archive.is/E9Dov）
它涵盖了转诊流程的基础知识，然后展示了如何使用各种工具（包括 dfsUtil 和 dfsDiag）来发现延迟的实际原因。
它帮我找到了问题所在。原来是域用户对共享目录没有读取权限。
HTH，丹尼尔
答案4
客户端会缓存 DFS 引用，即当您输入 \domain.name\namespace 时，它将缓存 domain.name 所引用的实际服务器。一旦缓存中的引用过期，客户端基本上必须重新“发现”您的 DFS 拓扑，因此会产生延迟。
请看这里：http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx和这里http://blogs.technet.com/filecab/archive/2006/01/20/417832.aspx了解有关其工作原理的更多信息。
可能的解决方案？一种比较老套的解决方法可能是编写一个小程序，每隔几分钟执行一次“保持活动”操作；例如，一个 C 程序，打开它找到的第一个文件并立即关闭它。我还没有尝试或测试过这种方法，如果你要这样做，你肯定需要仔细考虑。