我们最近迁移了我们的 Windows 网络以使用 DFS 来共享文件。DFS 运行良好，除了一个烦人的问题：用户在尝试访问他们已经有一段时间没有访问过的 DFS 命名空间时会遇到明显的延迟。我试图解决这个问题，但到目前为止还没有成功，我希望这里的人可能有一些指示来帮助解决这个问题。
首先，我们网络的一些背景：
该网络使用具有两个 Windows 2008 DC 和两个 DNS 服务器（每个 DC 上一个）的 Windows 2008 功能级别 Active Directory 域。网络只有 DNS - 没有 WINS。所有计算机都位于同一站点并通过千兆以太网连接。在 Windows 2008 模式下，我们大约有 20 个基于域的 DFS 命名空间，每个 DFS 命名空间有两个 Windows 2008 DFS 命名空间服务器（所有命名空间都使用相同的两台服务器）。所有命名空间服务器都处于 FQDN 模式，并且所有文件夹目标都使用它们的 FQDN 指定。所有计算机都装有最新的服务包和补丁。
实际的文件夹目标（即我们的 DFS 文件夹指向的 SMB 共享）分散在多个文件和应用程序服务器上，它们都运行 Windows 2008 以及两个运行 Windows 2003 R2 的应用程序服务器，根本没有复制设置（例如，当前的所有 DFS 文件夹只有一个文件夹目标）。
有关该问题的更多详细信息：
命名空间访问延迟通常为 1 到 10 秒，并且似乎发生在特定计算机大约 5 分钟或更长时间未访问请求的命名空间时。
例如，如果用户超过 5 分钟未访问 \\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 问题的奇怪行为
- 在客户端和服务器上禁用防病毒
- 从几个命名空间中删除一个命名空间服务器 - 没有区别
所以这就是我要做的——而且我没有想法。谁能建议可能导致延误的原因和/或我接下来应该尝试什么？
好吧，我们似乎终于在我们的环境中解决了这个问题。为了他人的利益，以下是我们的发现和解决问题的方法：
为了进一步了解延迟之前/期间/之后发生的情况，我们在客户端计算机上使用 Wireshark 来捕获/分析网络流量，同时该客户端尝试访问 DFS 共享。
这些捕获显示了一些奇怪的东西：每当延迟发生时，在从客户端发送到 DC 的 DFS 请求和从 DC 到客户端返回到 DFS 根服务器的引用之间，DC 会发送几个广播名称查找网络。
首先，DC 会广播 DOMAIN 的 NetBIOS 查找（其中 DOMAIN 是我们的 Windows 2000 之前的 Active Directory 域名）。几秒钟后，它将广播一个LLMNR查找 DOMAIN。紧随其后的是另一个广播 NetBios 对 DOMAIN 的查找。在这三个查找被广播（并且我假设超时）之后，DC 最终将通过（正确）引用到 DFS 根服务器来响应客户端。
这些针对 DOMAIN 的广播名称查找仅在打开 DFS 共享的长时间延迟发生时才发送，我们可以从 Wireshark 捕获中清楚地看到，在发送所有三个查找之前，DC 没有返回对 DFS 根服务器的引用（大约 7 秒过去了）。因此，这些广播名称查找显然是我们延迟的原因。
现在我们知道了问题所在，我们开始尝试找出为什么会发生这些广播名称查找。经过一番谷歌搜索和一些反复试验，我们找到了答案：我们没有将域控制器上的 DfsDnsConfig 注册表项设置为 1，这是在仅 DNS 环境中使用 DFS 时所要求的。
当我们最初在我们的环境中设置 DFS 时，我们确实阅读了有关如何为纯 DNS 环境（例如Microsoft KB244380和其他）配置 DFS 的各种文章，并且知道此注册表项，但误解了有关何时/如何进行的说明用它。
KB244380 说：
我们认为这意味着只能在 DFS命名空间服务器上设置注册表项，而没有意识到域控制器上也需要它。在我们将域控制器上的 DfsDnsConfig 设置为 1 后（并重新启动“DFS 命名空间”服务），问题就消失了。
显然我们对这个结果很满意，但我要补充一点，我仍然不是 100% 相信这是我们唯一的问题 - 我想知道将 DfsDnsConfig=1 添加到我们的 DC 是否只能解决问题，而不是解决它. 我无法弄清楚为什么 DC 会在 DFS 转介过程中尝试查找 DOMAIN（域名本身，而不是域中的服务器），即使在非仅 DNS 环境中也是如此，我也知道我没有在其他（诚然更小/更简单）仅 DNS 环境中的域控制器上设置 DfsDnsConfig=1 并且没有遇到同样的问题。尽管如此，我们已经解决了我们的问题，所以我们很高兴。
我希望这对遇到类似问题的其他人有所帮助 - 并再次感谢那些一路提供建议的人。
这可能是由 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 地址。
请参阅http://support.microsoft.com/kb/842197
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，丹尼尔
闻起来像 DNS 问题，但一切正常。我更喜欢旧的 FRS，因为像超声波这样的诊断工具非常有用：7
您是否在目标上的 DFS 复制事件日志中得到任何信息？（DFS 健康报告将从事件日志中提取其警告）
在没有 WINS 的情况下运行是一个不错的目标并且令人钦佩，但如果周围有任何 Vista/2008 之前的 Windows 系统，我非常反对这一点，因为根据我的经验，如果没有 WINS，事情并不总是按预期工作或一样快——尽管它真的应该没关系。
客户端缓存 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 程序，它打开它找到的第一个文件并立即关闭它。我没有尝试或测试过这个，如果你要这样做，你肯定需要仔细考虑。
我们遇到过类似的问题，用户在单击映射到 DFS 共享的驱动器与能够查看和浏览共享中的文件夹之间会遇到延迟（最多一分钟）。
用户还将家庭驱动器映射到同一卷上的不同 DFS 共享，并且在访问那里的文件夹时没有延迟。
两者之间的区别在于基于访问的枚举 (ABE) - 问题共享已启用此功能（它是用户的公共驱动器，具有数千个文件夹 - ABE 意味着用户只能看到他们有权访问的那些文件夹）。
禁用 ABE 完全消除了该问题。显然这不是一个解决方案，因为用户随后会看到所有文件夹，从而使他们感到困惑。我已经将 DFS 共享复制到带有一些备用磁盘的服务器作为临时措施，即使在这个新目标上启用了 ABE，延迟也消失了。
问题服务器是 2k3R2，正常运行时间超过 150 天（！），因此它将重新启动并让 CHKDSK 在有问题的卷上运行。如果这对问题有任何影响，我会在这里发帖。新目标位于 2k8 服务器上。
dfsutil /spcflush 和 dfsutil /pktflush 也可以是多站点网络中的解决方案，确保主站点的 DFS 链接来自本地服务器而不是来自缓存。
我知道原始发帖人没有使用 WINS，但我发帖是为了其他人的利益，因为我们最常使用这篇文章来帮助解决一个非常相似的问题。对我们来说，最终有人决定用与域相同的名称来命名他们的工作站。因此，每次 DC 查找 DFS 引用的域名时，它都希望解析到该工作站，这会导致相当多的 10 秒延迟。在指向 DC 的 WINS 中放置了一个静态 20 条目，这就解决了问题。如果您没有 WINS，您可以尝试将域名作为机器名称放在指向 DC 的 LMHOSTS 文件中以进行 20 查找，并设置优先级以使 LMHOSTS 成为解析 netbios 名称时首先查看的位置。
http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx 这个页面实际上提到了域控制器和 DFSN，如果有帮助的话。
DFS 域控制器和根服务器注册表项
以下注册表项位于
在根服务器和域控制器上。所有条目都是 REG_DWORD。
所以我在搜索中使用了这篇文章。我设置了一切，但仍然有问题。在花了几天时间调查问题并排除所有“微软”之后，我猜它与网络相关。原来我们的WAN 加速器是问题所在。我让我们的网络人员关闭了域控制器的加速，一切都变得更好了。