爲了結合以下示例進行說明，我們將只討論站點內複製。基本上，站點內複製旨在將更改快速複製到同一站點的 DC 內，然後使用更改通知來執行。在站點內複製的情況下，DC1 將通知 DC2 有需要複製的更改，然後 DC2 從 DC1 中拉出這些更改。同樣，當 DC2 有任何更改時，它也會通知 DC1，然後 DC1 從 DC2 中拉出這些更改。您可以看到，所有的 Active Directory 複製都通過“拉”操作而不是“推”操作進行。
因爲 Active Directory 可擴展至幾十萬甚至數百萬個對象，所以有必要將 Active Directory 數據庫劃分爲多個部分（稱爲命名上下文）。每個域控制器可在 Active Directory 數據庫的本地副本中存儲至少三個 NC。
架構 NC 此 NC 將被複制到林中的其他各個域控制器中。它包含有關 Active Directory 架構的信息，該信息又定義了 Active Directory 內不同的對象類和屬性。
配置 NC 此 NC 也會被複制到林中的其他各個 DC 中，它包含林範圍內有關 Active Directory 的物理佈局的配置信息，以及有關顯示標識符和林範圍內 Active Directory 配額的信息。
域 NC 此 NC 將被複制到單個 Active Directory 域中的其他各個 DC 中。正是此 NC 中包含最常訪問的 Active Directory 數據：實際用戶、組、計算機以及其他駐留在特定 Active Directory 域中的對象。
爲了更好地優化複製通信量，將單獨複製每個命名上下文，以使更改不頻繁的 NC（如架構 NC）不佔用域 NC（更改很可能更加頻繁）所需的網絡帶寬。
由於可從任何 Active Directory DC 進行目錄更改，因此 Active Directory 複製需要跟蹤兩種類型的寫入操作。一種類型是原始寫入，在直接對特定 DC 執行特定更改時進行的寫入。例如，如果您連接到 DC1 並更改用戶的密碼，此更改便被視爲 DC1 上的原始寫入。Active Directory 還必須跟蹤複製的寫入，正如您能想像到的，這表示會將特定更改從其他域控制器中複製過來。被視爲 DC1 上的原始寫入的更改在被複制到 DC2、DC3 以及域範圍內的其他任何 DC 中後，便被視爲複製的寫入。
Active Directory 域控制器通過使用複製元數據管理目錄更改的傳輸。這表示 Active Directory 除了將已更改的實際數據從一個 DC 傳輸到另一個 DC（對 John Smith 的描述更改爲“人力資源主管”），還會傳遞關於該更改的其他信息（如更改源自的 DC、進行更改的時間以及其他關鍵信息）以使域控制器以最高效的方式管理複製。
我們要討論的第一個複製元數據項目是更新序列號 (USN)。每個域控制器都維護特定於該域控制器的 USN。每當從該 DC 對 Active Directory 進行更改，USN 都會增加 1。因此如果某 DC 的 USN 在上午 11:00 時爲 1000，而在上午 11:30 時爲 1005，您就會知道已在該 DC 上對 Active Directory 數據庫進行了 5 次更改。事實上，進行什麼樣的更改對 USN 來說並不重要 — 您可以修改 5 個不同的對象、創建 5 個對象、刪除 5 個對象或前述操作的任意組合，該 DC 的 USN 都會增加 5。此外，USN 僅是特定域控制器的內部項目，與其他 DC 相比較時沒有任何參考價值。域中的某個 DC 可能在上午 11:30 時進行更改，並指定 USN 爲 1051；而相同域的另一個 DC 可能在同一時刻進行更改，並指定 USN 爲 5084。儘管兩個 DC 對於幾乎同時進行的更改很明顯具有完全不同的 USN，但這與如何複製這些更改並不相關；就不同變更之間的比較來說，某個 DC 的更新序列號對其他任何 DC 而言都毫無意義。
但這並不是增加 DC 的 USN 的唯一方式。請記住，對 Active Directory 數據庫的更改可包括原始寫入或複製的寫入。兩種類型的寫入操作都可增加域控制器上的更新序列號，這意味着每當從其他 DC 複製了更改時，該序列號都會增加。現在，很明顯可以看出，每個 DC 都需要一種方法來跟蹤已複製的更改，否則每個 DC 在每次複製時都會通過纜線發送整個 Active Directory 數據庫。爲避免發生這種情況，每個 Active Directory 域控制器都爲其他用於進行復制的域控制器維持一個稱爲高水準矢量 (HWMV) 的值。每個 DC 都將此高水準矢量與遠程 DC 的全局唯一標識符 (GUID) 相關聯，以防止在遠程域控制器被重命名或從目錄中刪除後產生混淆。
我們從一個簡單的示例開始，假設您在 contoso.com 域中配置了兩個域控制器 dc1.contoso.com 和 dc2.contoso.com。因爲 contoso.com 域中只有兩個 DC，所以 DC1 和 DC2 只能彼此複製。（請注意這只是一個簡化的示例，並不能完全說明 Active Directory 複製的所有細節。隨着講述的深入，我們會添加更多詳細信息。）
我們再假設 DC1 的當前 USN 爲 3000，DC2 的當前 USN 爲 4500，在開始我們的示例時兩個 DC 對彼此而言都已處於最新狀態：
步驟 1：DC1 和 DC2 對彼此而言均處於最新狀態。DC1 對於 DC2 的高水準矢量爲 4500，DC2 對於 DC1 的高水準矢量爲 3000
管理員在 DC1 上創建了一個新對象，DC1 的 USN 增加到了 3001，如圖 2 所示。請注意 DC1 針對 DC2 的 HWMV 沒有更改，因爲 DC1 尚未通知 DC2 自己有正等待中的更改
DC1 通知 DC2 自己有可用更改。隨後 DC2 啓動對 DC1 的複製來請求任何可用的更新。作爲此請求的一部分，DC2 將向 DC1 發送其針對 DC1 存儲的高水準矢量，如圖 3 所示。
步驟 4：DC1 向 DC2 發送與 USN 3001 相對應的更改，即在步驟 2 中在 DC1 上創建的對象。DC2 將自己的 USN 更新爲 4501 並將針對 DC1 的 HWMV 更新爲 3001，如圖 4 所示。
圖 4 更改和更新 (單擊該圖像獲得較小視圖)
到目前爲止都沒有問題吧？但現在問題就來了。DC2 有一個需要複製的更改。如果原來進行的只是 USN 和高水準矢量的更改，那麼現在 DC2 要聯繫 DC1 以將 DC1 剛纔複製到 DC2 的相同更改複製回 DC1，這將形成一個無窮的複製循環，並會不斷佔據越來越多的帶寬。爲防止此種情況，我們需要再多用幾個矢量來解決難題，第一個是最新矢量（UTD 矢量或 UTDV）。
UTDV 是另一個用於強化抑制的複製元數據，即其目的是防止相同的更改通過網絡一再重複被複制而耗費帶寬。每個 DC 針對其他每個 DC 維護一個 UTDV 表，其中存儲相關命名上下文的副本。對於域 NC，域中的各個 DC 針對該域中的每個 DC 維護一個 UTDV；對於配置和架構 NC，則針對林中的每個 DC 維護一個 UTDV。該 UTDV 表不僅會跟蹤每個 DC 從其複製合作伙伴接收的最大 USN，還會跟蹤從複製給定 NC 的各個 DC 中接收的最大 USN 值。爲此，每個複製的更改還需要包括以下信息：
要複製更改的 DC 的 GUID。這個要複製的更改可以是原始寫入或複製的寫入。
要從中複製更改的 DC 的 USN。同樣，此更改既可以來自原始寫入，也可以來自複製的寫入。
引起更改的 DC 的 GUID。如果此 GUID 與複製更改 DC 的 GUID 相同，表明它是原始寫入。否則，UTDV 表就起作用了。
引起更改的 DC 的 USN。同樣，如果此 USN 與複製更改的 DC 的 USN 相同，就表明這是原始寫入。否則，它就不是 UTDV 表。
爲了更好的說明此過程，我們添加第三方域控制器 (DC3) 增加示例的複雜性。在本示例中，DC1、DC2 和 DC3 是相互的複製夥伴；DC1 與 DC2 和 DC3 互相複製，DC2 與 DC1 和 DC3 互相複製，DC3 與 DC1 和 DC2 互相複製：
步驟 1：DC1、DC2 和 DC3 對彼此而言都處於最新狀態。
步驟 2：DC3 通過重置 jsmith 用戶帳戶的密碼執行單個原始寫入。DC3 通知 DC1 和 DC2 自己有可用更改。DC1 和 DC2 從 DC3 拉出原始寫入，然後更新各自針對 DC3 的 HWMV 和 UTDV 表，如圖 5 所示。
圖 5 更新 HWMV 和 UTDV 表 (單擊該圖像獲得較小視圖)
步驟 4：當 DC2 通知 DC3 自己有可用更改時以及當 DC1 以類似方式通知 DC2 和 DC3 時，便會發生相同的傳播抑制情況。這三個 DC 將更新各自針對自已的複製夥伴的 HWMV 條目，如圖 8 所示，但因爲實際數據已在步驟 2 中傳送到各個 DC，所以不會再度通過纜線傳輸。
多主機環境中的衝突解決方案
到目前爲止，我們的示例依然存於一個完美的世界中，每次只有一個管理員對 DC 進行更改，從不會出現衝突情況。我們知道這在現實世界中很罕見。既然對 Active Directory 對象的更新可以來自域中的任何域控制器，那麼，如果兩個管理員從兩個不同域控制器執行的更新相互衝突時會發生什麼情況？Active Directory 環境中可能發生三種類型的衝突，它們使用不同的衝突解決方案方法。
衝突的屬性變更 . 如果兩名管理員用相互衝突的方式更新相同的對象，便會發生此類型的衝突：一名管理員將用戶描述設置爲“市場”，另外一名管理員在另一 DC 上將用戶描述設置爲“銷售和市場”。
創建衝突的新對象 . 如果兩個管理員同時使用相同的名稱創建對象，例如，兩個名爲 jsmith 的用戶，便會發生此類型的衝突。
將對象移動到刪除的容器 . 這種類型的衝突較爲少見，如果管理員在容器內（例如，OU）創建或移動對象，與此同時另一名管理員在另一 DC 上刪除了該容器，便會發生此類型的衝突。
爲了解決前兩種類型的衝突，下面介紹另外兩個主要用於衝突解決方案的複製源數據。爲對象中每個單獨的屬性分配 versionID 值，初次創建對象時，該值的起始值爲 1。只要一修改任意 DC 中的某個屬性，versionID 就會增加 1。因此如果特定用戶的描述屬性已從默認值（空白或 <未設置>）更新爲“市場部”，則描述屬性的 versionID 會變成 2。如果稍後該描述修訂爲“銷售和市場部”，則描述屬性的 versionID 會變成 3，依此類推。此 VersionID 與我們之前介紹的其他元數據一起包含在每個複製項目中。
此 versionID 也可用於進一步減少複製通信量。例如，如果 DC2 上的管理員已對某個屬性進行多次更改（可能該管理員幾次鍵入錯誤更改），使 DC2 具有與 versionIDs 2、3、 4、和 5 對應的原始寫入，在此情況下 DC2 將僅複製與最後一個版本 versionID 5 相對應的寫入。由於早期更改難逃被覆蓋的命運，因此這樣可便捷地減少不必要的帶寬佔用。
對 Active Directory 所做的每個更改中還包含衝突解決方案使用的第二個附加元數據，這是一個時間戳，屬於複製元數據的一部分，指示修改是何時進行的。
也可將時間戳屬性用作檢測 Active Directory 複製運行情況的主動措施。如果 DC 使用相對較新的時間戳未發現特定 DC 中有任何更改，就會開始生成錯誤消息指示相關 DC 中可能存在問題。
那麼，如何在衝突解決方案中使用這兩個屬性？我們來依次檢查每種衝突類型。