站台間複寫延遲診斷路徑指引

Question

我們的 Active Directory 環境中，即使已設定緊急複寫，仍發現項關鍵屬性變更（例如：群組成員資格以供存取）在遠端站台的複寫時間，遠比預期長。

請問在此情況下，針對「站台間複寫延遲」的正確診斷流程（diagnostic path）應該如何進行？

目前擔心的重點：

1. 關鍵屬性變更（如群組成員資格）延遲很久才複寫到遠端站台
2. 已設定緊急複寫，但成效明顯不如預期
3. 需要確認是否為拓撲、連線、複寫佇列或站台設定導致延遲

希望社群或 Microsoft 專家能分享套建議的診斷路徑，協助找出站台間複寫延遲的根本原因並給予改善方向。

如有需要，我可以提供更多環境細節。感謝各位的協助！

Answer 1

歡迎來到 Microsoft Q&A 論壇！

感謝您分享對環境的觀察。

當關鍵的 Active Directory 變更（例如群組成員資格更新）在啟用緊急複寫（urgent replication）後，仍需要比預期更長的時間才能複寫到遠端站台時，建議採取有系統的診斷流程，而不是僅專注於單一複寫設定。

站台間複寫延遲通常與下列一項或多項因素有關：

• 複寫拓撲與站台連結（Site Link）設定
• 網路連線與 RPC 通訊
• DNS 名稱解析
• 複寫積壓（Replication Backlog）或佇列飽和
• 站台排程與複寫間隔
• Bridgehead Server 的效能與可用性
• 目錄資料庫處理延遲

請注意，若站台間排程設定過於嚴格、複寫佇列發生壅塞，或 Active Directory 拓撲無法準確反映實際 WAN 架構設計，都可能造成複寫延遲。

我建議依照以下步驟進行診斷：

1. 確認實際複寫延遲情況

首先，確認延遲是否僅影響特定屬性，還是所有目錄變更都受到影響。

執行：

repadmin /replsummary repadmin /showrepl

檢查下列項目：

• 最大複寫延遲（Largest Replication Delta）
• 複寫失敗情況
• 涉及的來源與目的網域控制站（DC）
• 發生延遲的命名內容（Naming Context）

這些指令可提供整個樹系的複寫健康狀態概覽，協助判斷問題是否只侷限於特定站台，或影響多個網域控制站。

2. 驗證站台拓撲與連線物件

使用 Active Directory Sites and Services 檢查：

• 子網路與站台對應是否正確
• Site Link 定義是否正確
• Site Link Cost 是否適當
• Site Link 複寫間隔設定
• NTDS Connection Object 是否有效

建議執行：

repadmin /kcc repadmin /showconn

這有助於確認 KCC（Knowledge Consistency Checker）所建立的複寫拓撲是否正常運作。

3. 檢查站台連結排程與複寫間隔

一個常見誤解是：緊急複寫會移除所有站台間排程限制。

請檢查：

• Site Link 排程
• 複寫間隔（Replication Interval）
• 是否已在 Site Link 上啟用變更通知（Change Notification）

預設的站台間複寫間隔為 180 分鐘（3 小時）。

在某些環境中，過於積極的排程搭配大量複寫工作負載，反而可能導致複寫積壓。

此外，也需留意多跳（Multi-hop）複寫路徑，因為整體延遲可能會受到複寫鏈中最長間隔的影響。

4. 檢查是否有複寫佇列積壓

如果緊急變更仍然延遲，請確認目標網域控制站是否正忙於處理其他複寫要求。

執行：

repadmin /queue

檢查：

• 佇列深度（Queue Depth）是否過大
• 是否存在 PREEMPTED 作業
• 是否有等待時間過長的複寫要求

過載的複寫佇列可能導致變更傳播延遲，表示複寫工作正被迫延後，以優先處理更高優先級的工作。

同時也請檢查 Directory Service 事件：

• Event ID 1839
• Event ID 2094

這些事件可能表示複寫工作負載已達飽和狀態。

5. 驗證網路、RPC 與 DNS 相依性

Active Directory 複寫高度依賴網域控制站之間穩定的通訊。

執行：

dcdiag /test:dns dcdiag /test:replications repadmin /showrepl

並確認：

• 網域控制站之間的 DNS 解析正常
• RPC 連線正常（TCP 135 與動態 RPC 連接埠）
• 防火牆設定正確
• WAN 延遲與連線穩定性正常

DNS 設定錯誤與 RPC 連線問題，仍然是最常見的複寫延遲與失敗原因之一。

6. 檢查 Bridgehead Server 是否成為瓶頸

針對站台間複寫，請確認 Bridgehead Server：

• 處於上線狀態
• 未發生效能過載
• 能夠正常與遠端站台交換更新內容

一台負載過重的 Bridgehead Server 可能成為整個站台的效能瓶頸，特別是在 Hub-and-Spoke 架構中，更容易造成大範圍延遲。

7. 檢查 Directory Service 事件記錄

請查看來源與目標網域控制站上的 Directory Service 記錄，特別留意下列事件：

• Event ID 1311
• Event ID 1566
• Event ID 1722
• Event ID 1864
• Event ID 2042
• Event ID 2087
• 與 8461 相關的警告訊息

事件記錄通常是找出複寫問題最快速的方法之一。

8. 關於群組成員資格變更的重要說明

即使複寫已成功完成，使用者仍可能遇到存取問題，原因包括：

• Kerberos 權杖（Ticket）內含快取的群組成員資訊
• 使用者可能需要登出後重新登入
• 現有的服務票證（Service Ticket）可能需要重新取得

因此，在認定問題是由複寫造成之前，務必區分：

• 複寫延遲（Replication Delay）
• Kerberos 權杖重新整理延遲（Kerberos Token Refresh Delay）

在排查群組成員資格相關的存取問題時，這是非常常見的誤判來源。

依照上述診斷流程，您可以判斷延遲究竟源自：

• 拓撲設計（Topology Design）
• Site Link 設定
• 網路相依性問題
• 複寫積壓（Replication Backlog）
• 網域控制站效能限制

而不只是單純由緊急複寫設定所造成。

如需更多資訊，請參閱：

針對 Active Directory 複寫進行疑難解答的指引 - Windows Server | Microsoft Learn

Active Directory 複寫概念 | Microsoft Learn

針對復寫錯誤 8461 進行疑難解答 - Windows Server | Microsoft Learn

Active Directory 復寫錯誤 8464 - Windows Server | Microsoft Learn

進行 Active Directory 複寫問題疑難排解 | Microsoft Learn

希望以上資訊能協助您釐清問題。若您覺得此回覆對您有所幫助，請考慮接受此答案（Accept the Answer）。

感謝您在 Microsoft Q&A 提出您的問題！