虛擬化域控制器系列(3)–Windows Server 2012虛擬域控制器的Invocation ID和VM Generation ID
在舊的時代, 設計域控制器邏輯時並不是那麼容易把一整套裝載AD的域控做個1比1的對照映像,
慢慢有些軟體令這個衝動成為有可能, 虛擬化快照技術更令這個動作變得輕而易舉.
現在很多公司(甚至微軟自己)也把域控制器虛擬化, 所以全面支援所有虛擬技術就變得順理成章了.
上一篇文章提及過DSA Object GUID和Invocation ID如何幫助偵測出USN Rollback問題.
這一篇我們看看微軟如何在既定遊戲規則下令Windows Server 2012的域控制器也可以進行快照回復.
以下是一台Windows Server 2008 R2 SP1的域控制器, 查看DSA InvocationID是下圖
現在我把這台處於虛擬機的DC製造一個檢查點(Checkpoint), 又把它倒回到未做快照的狀態.
回復快照前的狀態, 再打一次repadmin /showrepl, 結果DSA InvocationID仍然是一樣的,
這印證了前一篇所敘述, 回復快照, 或複製VHD, 匯出匯入等等行為都不會改變DSA Invocation ID.
現在戲肉來了, 下面是一台Windows Server 2012 的域控制器, 同樣是一台虛擬機器,
同樣是在開機的狀態製造檢查點再退回去以前的狀態.
神奇的事情發生了, 上面部份是未做快照前的InvocationID, 第二個repadmin /showrepl是倒回後發出的
DSA InvocationID變更了, 我可沒有做Windows Server Backup回復, 也沒有進過DSRM噢~
也正如前篇所說, 舊的InvocationID已經掉進retireReplDSASignatures欄位裡了,
那就是說Windows 2012的確做了些動作令這台電腦避免受到停權處分, 而且能繼續跟其他DC同步.
究竟魔法在那裡呢? 原來Windows Server 2012的DC會檢查自己是不是一台虛擬系統,
而如果底層的Hypervisor是支援一個叫VMGID的產品, 域控制器就會改變一些行為
而微軟暫時支援以下的微軟產品, 清單可以在這裡找到
而VMware也支援這一個功能, 相關文件在這裡
而確認這個狀況我們可以到DC的事件裡, 找事件ID 2168, 裡面會說明DC 正運行在支援的虛擬產品上.
而這個VMGID會以另外的形式儲存到這個DC的電腦帳號內, 名稱叫msDS-GenerationId
Hyper-V Guest的Generation ID會在幾個情況下改變
1. Guest OS進行快照倒回
2. 匯入虛擬機器, 而且在起動時選擇這個Guest OS是複製出來的 (非常重要的選擇)
如果你用的是VMware WorkStation, 也要選擇機器是複製出來的, 這樣VMware WorkStation才會變更虛擬機器的UUID.
當Domain Controller Service偵測到Generation ID有改變時, 就會出現以下事件ID 2170
首先ADDS會停止進行交易
繼而進行一系列的動作來避免發生錯誤, 分別是
1. 產生一個新的Invocation ID
2. 把分配到這台DC的RID池清除 (RID會由RID FSMO角色預先分配給每一台DC)
3. FSMO Role會在進行下一次覆寫時檢測, 如果這台DC擁有FSMO Role, FSMO角色將會暫時失效.
4. SYSVOL會進行Non-Authoritative Restore
5. 向其他DC要求覆寫到最新的狀態
6. 向RID角色要求新的RID Pool
從事件ID 1109中可以看到新舊InvocationID的轉變
SYSVOL也要進入Non-Authoritative Restore才能避免如群組原則物件出現錯誤的狀況.
現在這台域控制器已經算是重新投入服務了, 我們看到如果DC是FSMO的話, FSMO是會失效的
所以我們還是不太適合在擁有FSMO的服務器上進行以上的事, 但總體來說,
Windows Server 2012的域控制器已經完全能夠解決以往會引致錯誤的根源問題了
解決了這個問題是很有前瞻性的, 進入雲端和私有雲時代, 快速佈置系統變得渴求,
下一篇我們來看看如何快速把一台域控制器複製出更多能夠使用的虛擬域控, 事先說明不是匯出匯入那麼簡單噢~
