虛擬化域控制器系列(2) - 了解域控制器的DSA object GUID和InvocationID
這篇其實適合用於所有域控制器.
要進一步了解虛擬化的Windows Server 2012域控制器, 最好先了解幾個名詞.
上一篇我們看到USN如果影響了域控制器的資料覆寫, 也看了兩個錯誤的結果.
其中一個結果是DC2知道了DC1進行了回溯的動作, 繼而告訴它要把服務關閉避免破壞投產AD的運作.
這裡DC2其實除了從DC1告知的USN知道它使用了曾經用過的USN來查詢外,
還會比較一組叫Invocation ID的東西從而得知DC1使用了舊的資料庫.
要知道一台DC的Invocation ID, 我們可以打repadmin /showrepl 這個檢查域控制器覆寫狀況的指令.
如果你建立了第一台新的DC在新的林中, 例如這台DC01, 你會發現兩組相同的序號, 它們名稱分別是
DSA object GUID (也叫DC GUID) 和 DSA invocationID. 而DSA的全寫是Directory Service Agent.
DSA object GUID是DC自身的身份證明文件, 這個ID會從一台服務器提升(Promote)為域控開始使用,
直到這台域控被降級(Demote)成普通的成員服務器, 它的作用就正如身份證一樣,
在跟其他域控制器進行覆寫時證明自己是DC1還是DC2的身份. 除了以repadmin查看,
你也可以到AD Site and Service, 找每一台DC的NTDS Settings來看看它的DNS Alias.
在查看覆寫報告時, 我們會見到域控制器在跟那一個Object GUID的DC進行同步,
這個GUID能很快速的讓我們知道出問題的DC是那一台, 但Invocation ID在系統自動處理如USN Rollback的情況時就更重要.
InvocationID, 是每一台個體DC上現時使用中的AD資料庫識別碼,
如果這台DC是這個林中的第一台域控制器, 它的DSA Object GUID和Invocation ID會一樣,
往後加入的DC, 例如這台新加入到testlab.com網域的DC02, 產生出來的InvocationID就跟DSA Object GUID不一樣
而這個InvocationID也可以在NTDS Settings裡看到
Invocation ID跟DSA Object GUID最大不同在於它是可以改變的, 在以下情況下它會改變數值
1. Active Directory的資料庫由支持備份AD的備份軟件(例如Windows Server Backup)備份後, 再回復到AD上, 注意只有回復這個動作會改變Invocation ID.
2. Active Directory資料庫增加新的Partition.
改變後的Invocation ID會取代之前的值, 而舊的ID不會就這樣刪除, 而是放到retireReplDSASignatures裡做記錄
知道這兩個會改變Invocation ID的動作後, 我們又回到第一章所說的情況,
由於DC1是從快照中醒來的, 自然就沒有我們所說, 從備份軟件中修改了Invocation ID,
所以DC2才會那麼肯定DC1是從不支援的方法出回復出來, 而且提供曾經用作同步的USN.
跟它進行同步可能會帶來災難性的影響, 因為這個覆寫一定比備份DC2現在正常資料來的快, 所以DC1就被停權處分了.
就是因為這兩個元素加起來才令事情那麼清析. (簡單就像金田一漫畫的結局一樣 )
但是在不改變這些行為下, Windows Server 2012怎樣令我們可以為虛擬化的2012域控制器進行快照,Clone,匯出匯入VHD等動作呢?
我就在下一章再來看看Windows Server 2012的本領了
轉個情況, 如果DC1的資料庫曾經跑進Directory Service Restore Mode(DSRM)以Windows Server Backup回復出以前的System State備份,
Windows Server Backup會改變DC1上的Invocation ID, 如果DC2見到DC1的Invocation ID改變了,
就知道它是正常地回復出來, 那才不會出現封瑣覆寫連線, 關閉NetLogon服務等行為.
而DC1也要做一連串的動作, 去證明自己是由ADMIN主導去做回復動作的, 在再次啟動時就能通過覆寫拿回同步數據.
在進行備份回復後, 正常會出現事件ID 1109, 訊息是通知Invocation ID的改變, 及進行了備份回復