恢復損壞的本機網域控制器

當網域控制器損壞或復原錯誤時，後果不堪設想： 登入失敗，群組原則物件停止套用，複製功能失效，幾乎沒有任何線索。好消息是，只要遵循公認的備份和復原方法，恢復實體或虛擬資料中心都有明確的程序。

在現代 Windows Server 環境中，還原網域控制站需要對下列概念有深入的了解： 系統狀態、權威/非權威恢復、SYSVOL、DFSR/FRS 和 USN 回滾如果草率處理這些問題，或使用不相容的成像工具，結果可能會出現大量難以診斷的隱性不一致之處。

為什麼正確保護和恢復網域控制站至關重要

Active Directory 是 Windows 網域中驗證和授權的核心。它儲存使用者、電腦、群組、信任關係、群組原則、憑證和其他關鍵元素。這些資訊主要儲存在資料庫中。 Ntds.dit以及相關的日誌檔案和資料夾 系統卷以及其他構成所謂「系統狀態」的組成部分。

系統狀態包括（但不限於）： Active Directory 日誌檔案和資料、Windows 註冊表、系統磁碟區 (SYSVOL)、憑證資料庫（如果有 CA）、IIS 元資料庫、啟動檔案以及受保護的作業系統元件因此，任何認真的業務連續性策略都必須包括定期備份每個資料中心的系統狀態。

當 Active Directory 資料庫實際損壞、嚴重複製失敗或出現其他問題時， 權限 系統卷網域控制站可能會停止處理查詢、無法啟動 Active Directory 服務，或在整個林中引發級聯錯誤。在這些情況下， 快速且妥善的災後復原是避免嚴重事故演變成曠日持久的災難的關鍵。.

在嘗試復原之前，區分真正的資料庫問題和更常見的故障至關重要。很多時候， 原因在於 DNS、網路變更、防火牆或使用諸如此類工具修改的路由。 netsh 命令因此，在對 AD 資料庫進行任何操作之前，最好先排除這些因素。

基本診斷和複製控制工具

如果出現資料損壞或複製失敗的症狀，首先明智的做法是使用本地工具檢查環境狀態。 DCDiag、Repadmin、ReplMon（舊版）和事件檢視器 在考慮採取激進的修復措施之前，他們是你最好的盟友。

同 DCDiag 對所有網域控制器進行全面檢查，找出複製、DNS、AD DS 服務等方面的問題。 Repadmin 它允許您查看複製狀態、複製夥伴、USN浮水印並偵測持久物件。在舊版的Windows中， ReplMon 它以圖形方式展示了域內的複製錯誤。

除了這些工具之外，還必須查看事件檢視器中的「目錄服務」和「DFS 複製」事件。 諸如 467 和 1018 之類的事件表明資料庫確實已損壞。而事件 1113/1115/1114/1116 與啟用或停用輸入/輸出複製有關。

如果懷疑某個資料中心需要暫時隔離以防止其傳播腐敗，我們可以 使用 Repadmin 停用入站和出站複製:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

要恢復正常的複製功能，只需刪除這些選項即可：

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

支援網域控制器上的系統狀態備份

為了能夠有保障地恢復資料中心，擁有以下條件至關重要： 使用與 Active Directory 相容的工具執行系統狀態備份這些工具以受支援的方式使用 Microsoft 的備份和還原 API 以及磁碟區複製服務 (VSS)。

最常見的解決方案包括： Windows Server Backup，與 VSS 整合的第三方解決方案（例如 NAKIVO、Backup Exec 等）或較舊的公用設施，例如 Ntbackup 在 Windows 2000/2003 中，無論何種情況，都必須遵守 AD API，以確保資料庫及其副本在復原後的一致性。

Windows Server 2012 及更高版本新增了一項重要功能： Hyper-V 世代 ID (GenID)此標識符允許虛擬網域控制器偵測到其磁碟已回滾到先前的某個時間點。發生這種情況時， AD DS 產生一個新的 InvocationID，並將這種情況視為已從成功的備份中還原。通知其複製夥伴，從而允許安全重寫而不會導致 USN 回滾。

尊重這一點至關重要。 墓碑的一生這表示系統狀態備份可以保留多久而不會重新引入很久以前刪除的物件。在現代版本中，通常為 180 天，建議至少每 90 天執行一次備份，以確保足夠的安全裕度。

導緻美國海軍逆轉的未經授權的方法

Active Directory 中導致靜默不一致的最危險原因之一是： 美國海軍復原當使用不受支援的技術回溯 AD 資料庫的內容，而沒有復原 InvocationID 或通知複製夥伴時，就會發生這種情況。

典型場景是從…啟動網域控制器 磁盤映像 或過去拍攝的虛擬機器快照。無需使用相容的系統還原。或直接複製 Ntds.dit 文件，使用 Ghost 等映像程序，從損壞的磁碟映像啟動，或在陣列層級重新應用儲存快照。

在這些情況下，網域控制站繼續使用與先前相同的 InvocationID，但其 本地美國海軍計數器倒退其他資料中心會記住接收的更改，最高可達較高的 USN 值，因此當回滾的資料中心試圖發送已被識別的 USN 值時， 他們的合作夥伴認為自己已經掌握了最新消息，不再接受任何實質的改變。.

結果是某些修改（例如， 使用者建立、密碼變更、裝置註冊、群組成員變更、新的 DNS 記錄這些錯誤不會從恢復後的資料中心複製到網路的其他部分，但監控工具可能不會顯示明顯的錯誤。這是一種極度危險的靜默故障。

為了偵測這些情況，Windows Server 2003 SP1 及更高版本的驅動程式會記錄日誌。 目錄服務事件 2095 當偵測到遠端資料中心發送已確認的 USN 但 InvocationID 未發生變化時，系統會發出警報。 它會隔離受影響的網域控制器，暫停 Netlogon，並阻止進一步的變更發生。 無法正確復現。

作為額外的法醫證據，它可以 可於登記冊中查閱 鑰匙 HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 和價值 Dsa 不可寫如果設定了此值（例如 0x4），則表示透過 USN 反轉偵測將 DC 置於禁止寫入狀態。 手動修改此值以“修復”它是完全不受支援的。 這會導致資料庫永久處於不一致狀態。

網域控制器發生損壞或回滾時的一般策略

處理損壞或復原錯誤的網域控制站時應遵循的步驟取決於以下幾個因素： 網域/林中的網域控制站數量、系統狀態有效副本的可用性、其他角色（FSMO、CA、全域編錄）的存在以及問題的時間範圍。.

如果域中還有其他健康的資料中心，且 受損域控制站上沒有獨特的關鍵數據通常情況下，最快捷、最乾淨的方法是刪除該網域控制站並重建它。但是，如果它是唯一的網域控制器，或者它託管敏感角色和數據，則需要更謹慎地進行恢復（權威恢復或非權威恢復）。

一般來說，選項包括：

• 強制降級腐敗的網域控制站並將其從網域中移除。然後進行元資料清理，並在適用情況下進行新的推廣。
• 從有效的系統狀態備份中恢復無論是以權威模式或非權威模式。
• 使用 IFM（從介質安裝）從另一個 DC 重建 DC當沒有最近的副本，但有其他正確的 DC 時。
• 使用虛擬資料中心的 VHD 快照應用其他步驟將資料庫標記為從備份中還原（從備份中還原的資料庫 = 1），並確保產生新的 InvocationID。

如果明顯懷疑發生了 USN 回滾（例如，在未遵循最佳實踐的情況下從快照恢復虛擬機後），並且出現了事件 2095，那麼最明智的做法通常是： 將該資料中心從服務中移除，不要嘗試在現場「修復」它。除非能夠恢復到回滾之前所取得的受支援系統狀態的備份。

強制降職和元資料清理

當網域控制器損壞嚴重，無法正常降級，或復原過程出現錯誤，而您希望防止問題擴散時，您可以採取以下措施： 強制降職.

在舊版本中，此操作是透過以下方式執行的： dcpromo /forceremoval， 什麼 刪除 AD DS 角色，而不嘗試將變更複製到林中的其他部分。在現代環境中，嚮導程式已經改變，但概念是一樣的：從 AD 拓撲中刪除有問題的 DC，而不讓它參與進一步的複製。

強制降級後，必須從運作正常的網域控制器執行命令。 元資料清理 使用工具 Ntdsutil此程序會從 AD 資料庫中刪除對已刪除 DC 的所有參考（NTDS 設定物件、DNS 參考等），以便： 沒有「幽靈」殘餘物會幹擾複製。.

如果降級的控制器具有 FSMO 角色（PDC 模擬器、RID 主伺服器、模式主伺服器等），則需要： 轉移或接管這些角色 根據具體情況，可以在降級之前或之後將其遷移到另一個網域控制器。之後，可以在該伺服器上重新安裝作業系統，並將其提升回原來的網域控制站。

Active Directory 中的非權威還原與權威還原

當存在有效的系統狀態副本時，AD 恢復可以透過兩種方式進行： 非權威的和權威的了解其中的差異是避免錯過最新變化或重複使用過時數據的關鍵。

在一個 非權威性恢復DC 會回到之前的某個點，但一旦它開始運行， 其他網域控制器被視為參考網域控制器換句話說，啟動後，復原的網域控制站會要求入站複製，並使用其他網域控制站中缺少的變更更新其資料庫。此選項在以下情況下非常理想： 還有其他健康的控制器，我們希望修復後的控制器能夠趕上它們。.

在一個 威權復闢然而，文中明確指出： 恢復後的資料才是最終版本。 高於其他網域控制站的版本號。這意味著，恢復後，恢復的物件將具有更高的版本號，以強制它們從該網域控制器複製到網域中的其他部分。這是在以下情況下的合適選擇： 我們可能不小心刪除了物件或組織單元，或者我們想要將 SYSVOL 和 GPO 的內容還原到先前的狀態並進行複製。.

一個重要的細節是，權威復原並不一定需要針對整個資料庫。使用該實用程式 Ntdsutil 可以將單一物件、子樹（例如，組織單元）或整個網域標記為權威物件。這為例如以下情況提供了相當大的靈活性： 僅檢索使用者、群組、組織單元或子樹 dc=mycompany,dc=local.

資料中心系統狀態復原的一般步驟

使用相容工具復原資料中心（無論是實體資料中心或虛擬資料中心）系統狀態的基本方案始終類似： 啟動進入目錄服務還原模式 (DSRM)，使用備份工具進行還原，然後重新啟動.

總之，虛擬網域控制器的典型步驟如下：

1. 在 Windows 啟動管理器中啟動虛擬機 （通常在啟動時按 F5/F8）。如果虛擬機器由虛擬機器管理程式管理，則可能需要暫停虛擬機器才能擷取按鍵操作。
2. 在進階啟動選項中，選擇 目錄服務恢復模式 （目錄服務還原模式）。此模式啟動伺服器，但不以任何功能方式掛載 Active Directory 資料庫。
3. 使用 DSRM 管理員帳號登入 在 DC 最初提升期間定義（不是使用標準網域管理員帳戶）。
4. 運行備份工具 使用（Windows Server Backup、NAKIVO 或其他相容的備份軟體），並選擇將系統狀態還原到所需的備份點。
5. 完成恢復精靈並 以正常模式重啟 DC在非權威還原中，伺服器將啟動複製以與其他網域控制站保持同步。

當我們談到第三方備份產品時，例如 NAKIVO 備份和復制它的“應用程式感知”模式能夠識別出正在恢復的機器是資料中心，並且 自動調整流程以保持 AD 一致性在大多數具有多個控制器的場景中，非權威模式下的完全恢復就足夠了。

使用 Ntdsutil 進行權威恢復

如果您希望已復原的網域控制站上的變更優先於其他更改，則需要在非權威復原之後新增額外的步驟： 使用 Ntdsutil 將物件標記為權威對象.

簡化後的流程圖如下：

1. 以標準方式恢復系統狀態，並保持伺服器處於運作狀態。 DSRM模式 （暫時不要以正常模式重啟）。
2. 打開一個 以管理員權限執行命令提示符 並運行 ntdsutil.
3. 使用以下命令啟動 AD 實例 啟動實例 ntds.
4. 進入權威修復的脈絡 權威恢復.
5. 使用類似命令 restore object <DN_objeto> o restore subtree <DN_subarbol>其中 DN 是要權威地恢復的物件或子樹的專有名稱。
6. 確認交易，交易完成後， 以正常模式重啟 DC 以便優先複製已標記的對象，而不是網域中的其他對象。

這種修復方式需要格外謹慎。 如果整個網域已權威恢復，但備份檔案較舊。備份後可能會遺失合法變更（例如，使用者建立、密碼變更或群組修改）。因此，通常的做法是將權威還原限制在絕對必要的物件或樹中。

SYSVOL 恢復與還原（FRS 與 DFSR）

SYSVOL 是網域控制站的關鍵元件： 它儲存啟動腳本、群組原則、安全範本和其他重要的共用資源。權限故障、檔案損壞或複製問題都可能導致 GPO 無法使用或導致客戶端出現異常行為。

根據 Windows Server 版本和遷移狀態，SYSVOL 可能會被複製。 FRS（檔案複製服務） 為什麼 DFSR（分散式檔案系統複製）SYSVOL 的權威恢復程序取決於使用的​​是哪一個。

要確定這一點，您可以檢查註冊表中的鍵值。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState如果此子鍵存在且其值為 3（已刪除），則表示正在使用 DFSR。如果該子鍵不存在或其值不同，則表示目前環境仍在使用 FRS。

在採用 FRS 的環境中，SYSVOL 的權威恢復通常涉及調整該值。 布爾弗拉格斯 en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process 將其轉換為特定值（例如，十進制 212 / 十六進位 0xD4），以表示此 DC 是權威來源。

如果 SYSVOL 由 DFSR 複製，則過程會稍微複雜一些：它涉及使用 ADSI編輯 修改 SYSVOL 訂閱物件（屬性） 已啟用 msDFSR y msDFSR選項在權威網域控制站和其他網域控制站上，強制執行 AD 複製。 dfsrdiag pollad 並在事件日誌中確認出現 事件 4114、4602、4614 和 4604 證明 SYSVOL 已正確初始化和複製。

從 VHD 還原虛擬網域控制器

在虛擬化環境中，這種情況非常普遍。 網域控制器的 VHD/VHDX 文件如果您沒有系統狀態備份，但有一個可用的「舊」VHD，您可以從該磁碟掛載新的DC，但您必須非常小心地執行此操作，以避免導致USN回滾。

建議是 請勿直接以正常模式啟動該虛擬機相反，你應該從之前的 VHD 啟動。 數字資源管理系統開啟登錄編輯程式並導航至 HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters在那裡，建議檢查一下數值。 先前DSA修復次數統計 （如果存在）且最重要的是，建立一個名為 的新 DWORD（32 位元）值 從備份中還原的資料庫 值為 1。

選擇此值後，Active Directory 將被告知資料庫已從備份還原，這將強制執行此操作。 在正常模式下啟動時產生新的 InvocationID這樣，其他資料中心就會將其解釋為新實例，並正確調整其複製浮水印，從而防止 USN 回滾。

以正常模式重新啟動網域控制器後，建議檢查事件檢視器，特別是日誌。 目錄服務正在尋找 事件 1109此事件確認伺服器的 InvocationID 屬性已更改，並顯示舊值和新值，以及備份時的最高 USN。此外，該值還顯示了 先前DSA修復次數統計 它應該增加1。

如果這些事件沒有出現，或者計數沒有增加，則應檢查作業系統版本和服務包，因為 某些修復行為取決於特定的斑塊。總而言之，最好始終在原始 VHD 的副本上進行操作，保留完整版本以備需要重複該過程時使用。

實際場景和補充建議

在實踐中，腐敗或不當修復等問題經常出現在日常生活中： 手動修改 SYSVOL 中的權限、嘗試更新 ADMX/ADML 範本、GPO 變更未同步等等。如果手動修改共用資料夾，就很容易造成不一致，例如： SYSVOL\Policies 不考慮複製。

如果主網域控制器複製中斷（AD 資料和 SYSVOL 均中斷），並且出現“資料庫復原使用了不支援的操作步驟。可能原因：USN 回滾明智的做法是：

• 檢查 診斷 y 代表管理員 錯誤的程度以及是否存在「持久性物件」。
• 檢查事件 2095 及其值 Dsa 不可寫 在註冊表中。
• 評估是否可行 移除該資料中心並重建它 （如果有三名或更多其他健康的兒童，這通常是最佳選擇）。
• 如果這是唯一的DC或評論家，請提出… 系統狀態恢復 從相容的備份中備份，最好是最近的備份，並且備份日期在系統終止日期之前。

在具有多個控制器的網域中，強烈建議盡可能保持網域控制器的「純淨」狀態： 無需額外角色或本地用戶數據這樣，如果一個網域控制器發生故障或損壞，就可以基於另一個網域控制器或透過 IFM 格式化並提升一個新的網域控制器，從而大大降低復原的複雜性。

此外，值得注意的是，還存在一些局限性，例如： 系統狀態副本僅在墓碑期間內有效。 （根據配置不同，保留 60、90 或 180 天）以避免恢復已刪除的對象，且 NTLM 機器金鑰每 7 天變更一次。對於非常舊的恢復操作，可能需要… 重置團隊帳戶 「Active Directory 使用者和電腦」出現問題，甚至刪除它們並重新加入網域也會出現問題。

制定定期備份系統狀態的程序， 清晰地記錄 FSMO 角色、全域編錄和複製拓撲。在實驗室環境中測試復原步驟是一項耗時的投資，當網域控制器損壞或有人未經思考就應用快照時，可以避免很多麻煩。