我有两台由 T1 分隔的 AD 服务器。
位置 A，承载主要 AD/DNS/漫游配置文件服务器，子网为 192.168.0
位置 B 是辅助 AD 服务器（我正在尝试配置但......），位于子网 192.168.1 上
我知道这可能是 DNS 问题。我通过 Sonicwall 上的 DHCP 为该子网分配的唯一 DNS 服务器是位置 A 中的 AD 服务器。我在 ping 和 nslookup 中的 DNS 测试中得到了肯定的结果。
我已加入、退出、重新加入该域。
所有事件查看器都告诉我登录时间太长，耗时 931 秒，注销时间太长，并且无法加载 csc 资源...
是不是因为配置文件对于 T1 来说太大了？我已启用文件夹重定向 - 但仍然耗时太久，停留在“等待用户配置文件服务”的状态。
请注意，这在位置 B 的 Win2k8R2 和常规 Windows 7 上都会发生。
现在也发生在位置 A...[可能已修复 - 它可能只是原始配置文件大小，即使打开了文件夹重定向]
解决该问题的最佳方法是什么？
答案1
我不会对原因做出任何假设，除非您了解实际情况的更多细节。如果您在两个位置都看到登录速度很慢，那么很难将责任完全归咎于 WAN 基础设施（尽管我确信它应该承担一些责任……T1 过去感觉所以很快……现在它们对我来说只是痛苦的)。
任何认识我的人都能听懂：拿起嗅探器，观察网络上发送的内容。在这些缓慢的登录场景中，查看有多少流量在移动（不要介意流量的组成——只要看总量）就能告诉你很多问题。如果你看到少量流量，那么你可以开始调查为什么你看到的只是涓涓细流。如果你看到的是洪水，那么你就可以开始想办法减少发送的数据量。不过，除非你知道幕后发生了什么，否则你只是在摸黑摸索。在我看来，客户端和服务器上的事件日志在这种情况下并不是特别有用。
我不清楚托管漫游配置文件共享的服务器是否运行 W2K8（或更新版本）。如果是，您的 Windows 7/W2K8R2 客户端应该使用 SMB2 并很好地完成流水线操作以更好地利用 T1。话虽如此，任何大小的漫游配置文件（特别是如果 AppData 目录中充满了 Flash Player 和 Java 运行时环境喜欢在其中堆积的垃圾）在 T1 上同步都会很麻烦。您可以将内容重定向出配置文件并使其变得相当小，但这仍然很麻烦。
获取 Wireshark 的副本，对连接测试客户端的交换机端口进行端口镜像，然后开始嗅探。您应该能够立即获得有关总流量的一些详细信息。然后，您可以开始深入了解具体细节。