访问DFS命名空间时长时间停顿

我们最近迁移了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和补丁程序。

实际的文件夹目标（即SMB共享我们的DFS文件夹所指向的文件夹）分散在多个文件和应用程序服务器上，它们都运行Windows 2008，而只有两个运行Windows 2003 R2的应用程序服务器，根本没有复制设置（例如，当前所有DFS文件夹）只有一个文件夹目标）。

有关此问题的更多详细信息：

名称空间访问延迟通常为1到10秒长，并且似乎是在特定计算机大约五分钟或更长时间未访问请求的名称空间时发生的。

例如，如果用户超过五分钟未访问\\ domain.name \ namespace1 \并尝试通过Windows资源管理器访问\\ domain.name \ namespace1 \，则资源管理器窗口将冻结1-10秒，最后恢复并显示\\ domain.name \ namespace1中存在的文件夹。如果他们随后关闭资源管理器窗口并尝试在5分钟内再次访问\\ domain.name \ namespace1 \，则内容将立即显示-如果他们等待的时间超过5分钟，它将再次经历1到10秒的暂停。

一旦“进入”命名空间，一切都将变得好看且活泼，这只是到命名空间的初始连接很慢。

浏览延迟似乎会影响我们使用的所有Windows变体（Windows 2008 x64 SP2，Windows 2003 R2 x86 SP2，Windows XP Pro x86 SP3）-Windows XP / 2003中的浏览延迟可能比Windows 2008中的差一些，但是我不确定差异是否只是心理上的。

直接访问基础文件夹目标根本没有延迟-即，如果直接访问（绕过DFS）访问DFS指向的SMB共享，​​则不会暂停。

在进行故障排除期间，我注意到所有DFS根目录的“缓存持续时间”都设置为300秒-5分钟。鉴于这与触发暂停所需的时间相同，因此我认为此缓存在某种程度上是相关的，尽管我不确定究竟在客户端上缓存了什么，因此需要在5分钟后再次查找。

在尝试解决问题时，我已经尝试/检查了以下内容（未成功）：

• 在两个域控制器上运行dcdiag-未发现问题
• 完成一些基本的DNS服务器检查而没有发现任何问题-我不知道如何详细检查DNS服务器，但我要补充一点，网络没有表现出任何其他奇怪的行为，可能表明DNS问题
• 客户端和服务器上已禁用防病毒
• 从几个命名空间中删除一个命名空间服务器-没什么区别

所以这就是我的专长-而且我没有想法。谁能说出造成延迟的原因和/或我下一步应该尝试什么？

好吧，我们终于似乎在我们的环境中解决了这个问题。为了他人的利益，这是我们发现的问题以及解决问题的方法：

为了尝试进一步了解延迟之前/期间/之后发生的情况，我们在客户端计算机上使用Wireshark在客户端尝试访问DFS共享时捕获/分析了网络流量。

这些捕获显示出一些奇怪的现象：每当发生延迟时，在从客户端向DC发送DFS请求和从DC返回到客户端的DFS根服务器的引用之间，DC都会发出多个广播名称查找网络。

首先，DC将为DOMAIN广播NetBIOS查找（其中DOMAIN是我们的Windows 2000 Active Directory以前的域名）。几秒钟后，它将广播DOMAIN 的LLMNR查找。接下来是对DOMAIN的另一个广播NetBios查找。在广播了这三个查找（我认为已超时）之后，DC最终将通过（正确的）对DFS根服务器的引用来响应客户端。

仅当打开DFS共享的时间过长时才发送DOMAIN的这些广播名称查找，并且从Wireshark捕获中我们可以清楚地看到，直到发送完所有三个查找之后，DC才不会将引用返回给DFS根服务器（大约7秒过去了）。因此，这些广播名称查找显然是造成我们延迟的原因。

现在我们知道了问题所在，我们开始尝试找出为什么发生这些广播名称查找。经过更多谷歌搜索和反复试验之后，我们找到了答案：我们没有将域控制器上的DfsDnsConfig注册表项设置为1，这是在仅DNS环境中使用DFS所必需的。

当我们最初在环境中设置DFS时，我们确实阅读了有关如何为仅DNS环境（例如Microsoft KB244380等）配置DFS的各种文章，并且知道此注册表项，但是却误解了有关何时/如何进行操作的说明。用它。

KB244380说：

必须将DFSDnsConfig注册表项添加到将参与DFS命名空间的每台服务器，以使所有计算机理解标准名称。

我们认为这意味着只能在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服务器将被赋予DFS服务器，因为DNS服务器不知道站点IP边界。您需要告诉DNS服务器使用哪个子网掩码来标识要响应的IP地址。

请参阅http://support.microsoft.com/kb/842197

Active Directory团队博客的文章共三部分，有关DFS延迟。

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

它介绍了推荐过程的基础知识，然后介绍了如何使用各种工具（包括dfsUtil和dfsDiag）来发现延迟的实际原因。

它帮助我找到了问题。事实证明这是对域用户的共享目录没有读取权限。

HTH，丹尼尔

闻起来像DNS问题，但是一切正常。我非常喜欢旧的FRS，因为像Ultrasound这样的诊断工具是如此有用：7

您是否在目标的DFS复制事件日志中得到了任何东西？（DFS运行状况报告将从事件日志中提取警告）

没有WINS的运行是一个不错的目标，令人钦佩，但是如果周围有任何Vista / 2008以前的Windows系统，我非常反对，因为根据我的经验，在没有WINS的情况下事情总是无法按预期或以最快的速度运行-尽管确实如此没关系。

客户端缓存DFS引用，即，当您输入\ domain.name \ namespace时，它将缓存实际的服务器domain.name所引用。一旦引用从缓存中过期，则客户端基本上必须重新“发现”您的DFS拓扑，因此会产生延迟。

在这里查看：http : //technet.microsoft.com/zh-cn/library/cc758234 ( WS.10) .aspx和此处http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx，以获取有关其工作原理的更多信息。

可能的解决方案？解决这个问题的一种不明智的方法可能是编写一个小程序，每隔几分钟执行一次“保持活动”。例如，一个C程序，它将fopen是找到的第一个文件，然后立即fclose。我没有尝试过或测试过，如果要这样做，您肯定需要仔细考虑。

我们遇到了一个类似的问题，即用户在单击映射到DFS共享的驱动器与看到和浏览到共享中的文件夹之间会遇到延迟（最多一分钟）。

用户还将主驱动器映射到同一卷上的不同DFS共享，并且访问那里的文件夹没有延迟。

两者之间的区别是基于访问的枚举（ABE）-已启用问题共享（这是用户的通用驱动器，具有成千上万个文件夹-ABE意味着用户只能看到他们拥有权限的那些文件夹）。

禁用ABE可以完全解决问题。显然，这不是解决方案，因为用户随后会看到所有文件夹，使它们混乱。我已经将DFS共享复制到具有一些备用磁盘的服务器上，作为临时措施，即使在这个新目标上启用了ABE，延迟也已经消失了。

问题服务器为2k3R2，正常运行时间超过150天（！），因此它将重新启动并在有问题的卷上运行CHKDSK。如果这对问题有任何影响，我将在此发布。新目标位于2k8服务器上。

在多站点网络中，dfsutil / spcflush和dfsutil / pktflush也可以是一个解决方案，请确保主站点的DFS链接来自本地服务器而不是来自缓存。

我知道原来的海报没有使用WINS，但是我为了其他人的利益而张贴信息，因为我们最常使用该信息来解决一个非常相似的问题。对我们而言，最终还是有人决定使用与域相同的名称来命名其工作站。因此，DC每次在DFS引用的域名上进行查询时，都想解析到该工作站，这将导致相当长的10s秒的延迟。在WINS中将一个静态20条目指向DC，这已解决了该问题。如果没有WINS，则可以尝试将域名作为计算机名称放置在指向DC的LMHOSTS文件中，以进行20查找，并设置优先级以使LMHOSTS成为解决netbios名称的第一个位置。

http://technet.microsoft.com/zh-cn/library/cc780950(v=ws.10).aspx 如果有帮助，此页面实际上同时提到了域控制器和DFSN。

DFS域控制器和根服务器注册表项

以下注册表项位于

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

在根服务器和域控制器上。所有条目均为REG_DWORD。

因此，我在搜索中使用了这篇文章。我进行了所有设置，但仍然有问题。花了几天的时间调查问题并排除了所有“微软”之后，我猜想这与网络有关。原来我们的WAN Accelerator是问题所在。我让网络工程师关闭了域控制器的加速功能，一切都变得更好了。

有很多控制器，脚本（dnsdfs.cmd servername）也有：

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

您提到您有20台DFS服务器，但是如果所有服务器都在同一设施中，则不会提及。

如果这些服务器不在同一设施中，并且每个其他站点都有其自己的域，则可能需要确保启用客户端故障回复。

对于那些最终通过谷歌搜索并遇到相同问题的人...

首先，检查您命名空间中的所有链接均可用并且良好。在我的情况下就是这样，在名称空间中仍然有一个服务器宕机的链接，因此打开DNS的长时间停顿是因为它正在搜索该服务器而失败。一旦我禁用了DFS中的链接，长时间的停顿就消失了。

验证Authenticated Users组是否有权列出您映射到的根目录的内容。例如，如果x：驱动器映射到\ domain.local \ departents \ Marketing，则用户将需要\ domain.local \ departments的列表权限。在2008/2012中，您可以在高级权限下指定它适用于“仅此文件夹”，以便不允许他们列出任何可能继承权限的子文件夹的内容。