物件的元資料在複製過程中如何被更改
讓我們看一下4步驟的乙個例子：
1.server a上乙個物件（乙個使用者）被建立
2.物件被複製到b
3.物件接著在b上被修改
4.在b上的修改被複製給a
整個過程如圖：
how metadata is modified during replication
step1:a上使用者的建立
當在a上建立乙個使用者物件時，a就是原始dc，在建立新使用者的活動目錄事務動作中，乙個usn (1000)被分配
給該事務，使用者物件的usncreated和usnchanged屬性自動被設定為1000.所有該使用者物件的其他屬性
被一些資料初始化，如下：（注：物件初次建立所有的屬性都有相同的usn）
物件屬性值根據系統的預設值或者在建立過程中提供的引數被設定
物件屬性的usn被設定為1000
物件屬性的版本號被設定為1
物件屬性的時間戳被設定為物件建立時的時間
物件的原始寫server的guid屬性被設定為server a的guid
物件的原始寫server usn屬性被設定為 1000 (該事務的usn號)
你可以從中知道這個使用者物件在事務處理1000中被建立。--usncreated=1000
這個使用者物件最後一次修改是在事務處理1000中。 --usnchanged=1000
這個使用者物件從來沒有被更改過原始值 version number=1
這個使用者物件的每個屬性的值被設定的原始出處是server a,事務號1000(原始serverguid,原始server usn)
物件的屬性值可以用repadmin,adsiedit,ldp等工具檢視
step2.複製原始寫到server b
物件被複製到server b, b增加使用者物件到活動目錄副本--以複製寫的方式。
在這個事務中，usn 2500被分配。使用者物件的usncreated和usnchanged屬性值被修改為server b上相應的事務usn 2500.
由此可知這個使用者是在事務2500中被建立在serverｂ上的。物件從來沒有被修改過，應為version number =1
還可以看出物件的每個屬性的原始寫server和原始usn.
step3. server b上修改使用者密碼
originating write原始寫（密碼修改）發生在server b上的replicated-write複製寫使用者物件上，該事務的usn為3777，使用者物件的usnchanged屬性也改為3777.
同時：密碼的版本號由1變為2
密碼usn被設定為3777
密碼時間戳被修改
密碼的原始寫server從a改為b,原始usn改為3777
step4.密碼修改被複製給server a
注意更新發生在屬性級別而非物件級別。因此僅僅密碼屬性被複製。
類似於step2. a上被分配usn 1333，物件的usnchanged屬性值被修改為a上的事務號1333
在真實的dc複製過程中，有2處不同：
1.從a複製到b，cn屬性會顯示原始寫來自b而不是a,這牽涉到後台的實現細節，
僅此一處發生這樣的差異
2.密碼的修改實際上更新了好幾個屬性，而非僅僅1處，這涉及到dbcspwd,unicodepwd,ntpwdhistory,lmpwdhistory等屬性。
這也牽涉到後台的實現細節。對於其他屬性，單個的修改只會影響單個屬性和複製。密碼只是乙個特殊的例子。
不是活動目錄的Azure活動目錄！
摘要 在現代雲時代的大環境下，雲服務的概念已經是無人不知無人不曉了。像阿里雲 谷歌雲 aws azure等等已經深入日常的方方面面。那對於雲中的身份，我們今天特別的介紹一下azure active directory aad 的概念，希望可以幫助您了解的更加清晰。azure活動目錄是一種新的現代化身...
Ldap之活動目錄介紹二
執行 active directory 安裝嚮導將 windows 2000 server 計算機公升級為域控制器會建立乙個新域或者向現有的域新增其他域控制器。建立域控制器可以 建立網路中的第乙個域。在樹林中建立其他的域。提高網路可用性和可靠性。提高站點之間的網路效能。要建立 windows 200...
監測目錄活動
監測目錄活動 c 中有類 filesystemwatcher 不但能夠知道指定目錄樹中的檔案 目錄的改變，而且能夠知道是哪個檔案 目錄在改變，而我用findfirstchangenotification等win api 卻不能實現第二個功能，虛耗了不少時間，昨日在msdn中發現 readdirect...