訪問 DFS 命名空間時長時間停頓
我們最近遷移了我們的 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 秒過去了）。因此，這些廣播名稱查找顯然是我們延遲的原因。
現在我們知道問題出在哪裡，我們開始嘗試找出為什麼會發生這些廣播名稱查找。經過更多的Google搜尋和一些反複試驗，我們找到了答案：我們沒有將域控制器上的 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 並且沒有遇到同樣的問題。儘管如此，我們已經解決了我們的問題，所以我們很高興。
我希望這對遇到類似問題的其他人有所幫助 - 並再次感謝那些一路提供建議的人。