AD DS數據庫復制排錯

AD DS數據庫復制原理

為了盡可能降低AD DS數據復制的延遲時間，在不同的域控之間復制時，途經的域控不能超過三臺。例如，從DC1開始復制，經過DC2，DC3到達DC4等。而且DC1并不會同時通知自己的所有直接復制伙伴，而是每隔三秒，依次通知自己的復制伙伴，這樣可以防止DC1負擔過大。即使出現新增域控的情況，KCC也會遵循上述規則，重新創建復制拓撲結構，保證從源域控到目標域控之間的域控數量不超過兩臺。

對于同一個站點中的所有控制，往往通過高速網絡連接，這可以保證快速高效地在彼此之間復制AD DS數據庫信息。通過更改通知的方法，當同一站點中的某臺域控的AD DS數據庫出現變動時，系統會等待15秒才會通知自己的直接復制伙伴。收到通知的域控如果需要同步變更信息，會發送更新數據的請求給源域控，當源域控收到并確認請求后，就會通過KCC程序來復制所需的數據。

但是，對于用戶賬戶密碼變動、賬戶鎖定策略變更、賬戶變動、密碼策略變化等情況，系統會利用緊急復制機制，立即通知自己的復制伙伴執行AD DS數據的更新操作。此外，當KCC在創建復制拓撲結構時，會針對AD DS數據庫中的不同目錄分區，來創建不同的復制拓撲結構。例如，對于DC1，當復制AD DS數據庫中的配置目錄分區時，DC2可能使其直接復制伙伴。當復制應用程序目錄分區時，DC6可能使其直接復制伙伴。

解決AD DS數據庫復制故障

在復制AD DS數據庫時，可能因為各種原因出現沖突的情況。例如，多個具有系統管理員權限的用戶在不同的域控上建立相同的對象（例如賬戶名等），因為AD DS數據庫中的很多數據是利用多主機復制模式執行復制操作的，任何一臺域控中的AD DS信息發生變動，都會自動更新到其他的域控中。這樣，產生復制沖突的情況就在所難免了。為了有效解決該問題。活動目錄域服務使用了STAMP戳記這一方法來化解矛盾。戳記由版本號，修改事件，域控的GUID等參數組成。每一個屬性值的版本號初始值為1，當每次修改該屬性值時，版本號數值就會增加。

當屬性值被修改時，原始的時間即作為修改時間被保存起來。當操作者在某臺域控上執行修改操作時，原始域控的GUID值即是域控的GUID參數值。所謂GUID是全局惟一標識符，每臺計算機都擁有惟一的GUID值。當操作者修改了AD DS數據庫中的某個對象的屬性信息后，與該數據值對應的戳記就會發生變化。當出現AD DS復制沖突時，是按照戳記值最高的為準。在兩臺域控中，目標屬性值的版本號誰最高，就以誰為準。如果兩者的版本號信息相同，就比較兩者的修改時間，誰的修改事件靠后就以誰為準。如果修改時間相同，就繼續比較兩者的原始域控制器的GUID值，誰的GUID值高就以誰為準。

例如，當兩位管理員在不同的域控上分別修改了A賬戶的辦公室部門信息值。 執 行 和“repadmin /showmeta CN=A賬戶,OU=XXX部 門,DC=XXX,DC=com”命令，在項目列表中的“版本屬性”列中“physicalDelivery OffName”的版本號信息，其中的“A賬戶”表示具體的賬戶名，“XXX部門”標識具體的部門，“xxx.com”標識具體的域名。可以看到，在這兩臺域控上部門屬性的版本號的變化是相同的，所以需要比較兩者的修改時間，誰修改的事件靠后就已誰的為準。

有時會出現某個管理員在某臺域控上，將AD DS數據庫中的某個OU刪除，但是別的管理員卻并不知情，繼續在該OU中創建新的賬戶，或者將其他OU中的賬戶移動到該OU中，因為該OU已經消失，所以系統會將這些賬戶信息自動存儲到名為“LostAndFound”文件夾中。如果兩個管理員在兩臺域控上分別創建相同的賬戶名，那么這兩個賬戶名其實都會保存下來。所不同的是，根據戳記值（版本號，修改事件，域控GUID）來確定優先級較高的賬戶名，將其作為正常的賬戶信息使用，對于優先級較低的賬戶，其賬戶全名會按照具體的格式進行修改，具體的格式為“對應的相對可分辨名稱 通用名：對象的GUID”。