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

我们最近迁移了我们的Windowsnetworking以使用DFS共享文件。 DFS运行良好,除了一个恼人的问题:当用户尝试访问他们一段时间没有访问过的DFS名称空间时,他们遇到了很大的延迟。 我试图解决这个问题,但到目前为止还没有取得任何成就,我希望这里有人可能有一些指导来帮助解决问题。

首先,我们networking上的一些背景:

networking使用Windows 2008function级别的Active Directory域和两个Windows 2008数据中心和两台DNS服务器(每台数据中心都有一台)。 networking只有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资源pipe理器访问\\ domain.name \ namespace1 \,资源pipe理器窗口将会冻结1-10秒恢复并显示\\ domain.name \ namespace1中存在的文件夹。 如果他们closures浏览器窗口并尝试在五分钟内再次访问\\ 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根目录的“caching时间”设置为300秒-5分钟。 由于这与触发暂停所需的时间相同,因此我认为这种caching在某种程度上是相关的,尽pipe我不确定在客户端上caching了什么,因此在5分钟后需要再次查找什么。

在试图解决这个问题,我已经试过/检查以下(没有成功):

  • 在两个域控制器上运行dcdiag – 没有发现问题
  • 做一些基本的DNS服务器检查没有发现任何问题 – 我不知道如何检查DNS服务器的详细信息,但我会补充说,networking并没有performance出任何其他奇怪的行为,可能指向一个DNS问题
  • 禁用客户端和服务器上的防病毒
  • 从几个命名空间中删除一个命名空间服务器 – 没有区别

所以那就是我所要做的 – 而且我没有想法。 任何人都可以提出什么可能造成的延误和/或我应该尝试下一步?

    那么,我们终于看起来在我们的环境中解决了这个问题。 为了别人的好处,下面是我们发现的以及我们如何解决这个问题:

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

    这些捕获显示了一些奇怪的现象:每当发生延迟时,在从客户端发送到DC的DFS请求和从DC回到客户端的DFS根服务器的引用之间,DC发出几个广播名称查找networking。

    首先,DC会广播DOMAIN(其中DOMAIN是我们的Windows 2000之前的Active Directory域名)的NetBIOS查询。 几秒钟后,它将广播DOMAIN的LLMNR查找。 接下来是DOMAIN的另一个广播NetBios查找。 在这三次查询被广播后(我假定超时),DC将最终响应客户端(正确的)引用到DFS根服务器。

    DOMAIN的这些广播名称查询仅在发生DFS共享的长延迟时才被发送,并且从Wireshark捕获中我们可以清楚地看到,在所有三个查找被发送之前DC没有将引用返回给DFS根服务器并且〜7秒过去了)。 所以,这些广播名称查询显然是我们拖延的原因。

    现在我们知道问题出在哪里了,我们开始试图找出为什么这些广播名称查询正在发生。 经过多一点Googlesearch和一些反复试验,我们发现我们的答案是:我们没有将域控制器上的DfsDnsConfigregistry项设置为1,这是在仅DNS环境中使用DFS时所要求的。

    当我们最初在我们的环境中设置DFS时,我们阅读了关于如何为仅DNS环境(例如Microsoft KB244380等)configurationDFS的各种文章,并且知道此registry项,但是错误地解释了何时/如何用它。

    KB244380说:

    必须将DFSDnsConfigregistry项添加到将参与所有计算机的DFS名称空间的每个服务器以了解完全限定的名称。

    我们认为这意味着只能在DFS 名称空间服务器上设置registry项,而不是意识到它在域控制器上也是必需的。 在我们的域控制器上设置DfsDnsConfig为1(并重新启动“DFS命名空间”服务)后,问题消失了。

    显然我们对这个结果感到满意,但是我想补充一点,我仍然不是100%确信这是我们唯一的问题 – 我想知道是否将DfsDnsConfig = 1添加到我们的DC只能解决问题,而不是解决问题。 我不知道为什么在DFS转诊过程中,为什么DC要尝试查找DOMAIN(域名本身,而不是域中的服务器),即使在非DNS的环境中,我也知道没有在域控制器上设置DfsDnsConfig = 1在其他(公认小得多/更简单)仅DNS的环境,并没有相同的问题。 不过,我们已经解决了我们的问题,所以我们很高兴。

    我希望这对正在经历类似问题的其他人有所帮助 – 并再次感谢那些一路提出build议的人。

    这可能是由DNS服务器networking掩码sorting造成的。 我们最近在Server 2003中遇到了这个问题。这取决于您当前的子网划分。

    例。

    站点1:IP子网10.0.0.0/24站点2:IP子网10.0.1.0/24

    站点2中的客户端为您的基于域的名称空间进行DNS查询,并且默认情况下会在站点1中为DFS服务器提供DNS服务器,因为DNS服务器不知道站点IP边界。 您需要告诉您的DNS服务器使用哪个子网掩码来确定要响应的IP地址。

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

    闻起来像一个DNS问题,但什么都可以。 我非常喜欢旧的FRS,因为像Ultrasound这样的诊断工具非常有用:7

    目标上的DFS复制事件日志中是否有任何内容? (DFS健康报告将从事件日志中提出警告)

    没有WINS的运行是一个不错的目标和令人钦佩的,虽然我非常反对这个,如果有任何Vista / 2008之前的Windows系统,因为事情并不总是按预期的那样工作,或者没有WINS,应该没关系。

    Active Directory团队博客有关于DFS延迟的三篇文章。

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

    它涵盖了推荐stream程的基础知识,然后展示了如何使用各种工具(包括dfsUtil和dfsDiag)来发现延迟的实际原因。

    这帮我find了我的问题。 原来对域用户的共享目录没有读权限。

    HTH,Daniel

    客户端caching一个DFS引用,即当你input\ domain.name \ namespace时,它会caching实际的服务器domain.name引用的内容。 一旦推荐从caching到期,客户端基本上必须重新“发现”您的DFS拓扑,因此延迟。

    看看这里: http : //technet.microsoft.com/en-us/library/cc758234 ( WS.10) .aspx和这里http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx有关如何工作的更多信息。

    可能的解决scheme? 一个讨厌的方法可能是编写一个小程序,每隔几分钟就“保持活力” 例如一个C程序,它打开了它find的第一个文件,并立即发现它。 我没有试过或者testing过这个,如果你打算这样做的话,你一定要仔细考虑一下。

    我们遇到了类似的问题,用户在点击映射到DFS共享的驱动器之间可能会遇到延迟(最多一分钟),并且能够查看和浏览共享内的文件夹。

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

    两者之间的区别是基于访问枚举(ABE) – 问题共享启用了这个function(这是用户常见的驱动器,数以千计的文件夹 – ABE意味着用户只能看到他们有权限的文件夹)。

    禁用ABE完全消除了这个问题。 显然,这不是一个解决scheme,因为用户会看到所有的文件夹,混淆他们。 我已经将DFS共享复制到了一个备用磁盘作为临时措施的服务器上,即使在这个新目标上启用了ABE,延迟也没有了。

    问题服务器是2k3R2,并具有超过150天(!)的正常运行时间,所以它将被重新启动并且CHKDSK运行在违规的卷上。 如果这对问题有任何影响,我会在这里回复。 新的目标是在2k8服务器上。

    在多站点networking中,dfsutil / spcflush和dfsutil / pktflush也可以成为解决scheme,确保主站点的DFS链接来自本地服务器,而不是来自caching。

    我知道原来的海报没有使用WINS,但是我发布的是为了他人的利益,因为我们使用这个post最能帮助解决一个非常类似的问题。 对我们来说,最终是有人决定用与域相同的名称命名他们的工作站。 所以,每次DC对DFS引用的域名进行查询时,都想要parsing到该工作站,并且会导致相当多的几十秒延迟。 一个静态的20条目被放在WINS指向一个DC,这已经解决了这个问题。 如果您没有WINS,则可以尝试将域名作为计算机名称放在指向DC的LMHOSTS文件中以获得20查找,并将优先级设置为使LMHOSTS成为parsingnetbios名称的首要位置。

    http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx本页实际上提到了域控制器和DFSN,如果有帮助。

    DFS域控制器和根服务器registry项

    下面的registry项位于下面

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

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

    所以我在我的search中使用这篇文章。 我设置了一切,仍然有问题。 花了几天的时间来研究这个问题,排除一切“微软”,我猜测它是networking相关的。 原来我们的广域网加速器是个问题。 我有我们的networking人closures加速我们的域控制器,一切都变好了。

    你提到你有20台DFS服务器,但是如果所有的服务器都在同一个设施里,就没有提及。

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

    对于那些最终在这里通过谷歌search和谁有同样的问题…

    首先检查你的命名空间中的所有链接是否可用和好。 这就是我的情况,在命名空间中还存在一个closures服务器的链接,所以打开DNS时长时间停顿是因为它正在search该服务器并失败。 一旦我在DFS中禁用了这个链接,长时间的停顿就消失了。

    有很多控制器,脚本( dnsdfs.cmd servername )也是这样:

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

    validationAuthenticated Users组是否有权列出您映射到的根目录的内容。 例如,如果x:驱动器映射到\ domain.local \ departents \ Marketing,那么用户将需要\ domain.local \ departments的列表权限。 在2008/2012年,您可以在高级权限下指定它适用于“仅此文件夹”,以便不允许列出可能具有inheritance权限的任何子文件夹的内容。