我有两个由T1分隔的AD服务器。
主AD / DNS /漫游configuration文件服务器的位置A是子网192.168.0
位置B，这是辅助AD服务器（我试图configuration，但是…）在子网192.168.1
我明白这可能是一个DNS问题。 在Sonicwall上通过DHCP分配给该子网的唯一DNS服务器是位置A中的AD服务器。我在ping和nslookup中获得了DNStesting的正面结果。
我join了，未join，重新join了这个领域。
所有的事件查看器告诉我，login过长，花了931秒，需要很长时间才能注销，并且有一个csc资源无法加载…
简单地说，这个轮廓对于T1来说太大了？ 我已经启用了文件夹redirect – 仍然在永久，坚持在“等待用户configuration文件服务”。
请注意，这发生在位置B的Win2k8R2和常规Windows 7上。
现在正在发生在地点A以及… [可能修复 – 它可能只是原始configuration文件的大小，即使在文件夹redirect]
解决此问题的最佳方法是什么？
我不会对这个原因做出任何假设，除非你得到有关实际发生的更多细节。 如果你在这两个地方看到login缓慢，那么就很难把责任完全归咎于WAN基础设施（虽然我敢肯定它有一些责难… T1以前感觉如此之快……现在，它们只是痛苦的我）。
任何认识我的人都可以在这里唱歌：抓住一个嗅探器，看着电线上发出的东西。 看到在这些缓慢login的情况下有多lessstream量正在移动（不必介意stream量组成是什么 – 仅仅是总量）会告诉你负载这个问题。 如果你看到stream量涓涓细stream，那么你可以开始调查为什么你只看到一个滴stream。 如果你看到一个洪水，那么你可以开始计算如何调整发送数据的大小。 但是，直到你知道幕后发生了什么事情，你才会在黑暗中进行刺探。 在我看来，在这种情况下，客户端和服务器上的事件日志并不是特别有用。
我不清楚托pipe漫游configuration文件共享的服务器是否运行W2K8（或更新版本）。 如果是你的Windows 7 / W2K8R2客户端应该使用SMB2，并做一个体面的工作stream水线操作，以更好地利用T1。 话虽如此，任何大小的漫游configuration文件（特别是如果AppData目录充满了Flash播放器和Java运行环境喜欢堆积在那里的那种垃圾），将会很难在T1上同步。 你可以重新定向这个概要，并把它弄得很小，但是它仍然很痛苦。
抓住一个Wireshark的副本，端口镜像的交换机端口，testing客户端连接，并嗅探。 你应该能够立即得到关于交通总量的一些细节。 然后，您可以开始深入了解具体情况。