使用 Hyper-V 將網域控制站虛擬化

適用於：Windows Server 2022、Microsoft Hyper-V Server 2019、Windows Server 2019、Microsoft Hyper-V Server 2016、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

Windows Server 2012 和更新版本支援使用具有保護措施的虛擬化網域控制站 (DC)，以防止虛擬 DC 上的更新序號 (USN) 復原，以及複製虛擬 DC 的能力。 虛擬化會將不同的伺服器角色合併到單一實體機器上。 如需詳細資訊，請參閱安全地將 Active Directory Domain Services (AD DS) 虛擬化。

本指南描述如何以 32 位元或 64 位元客體作業系統形式執行 DC。

規劃虛擬化

下列各節包含虛擬化 DC 時應該知道的規劃考量，包括硬體需求、架構、設定，以及管理安全性和效能。

Hyper-V 需求

若要安裝和使用 Hyper-V 角色，您的硬體必須符合下列需求：

• 您必須有 x64 處理器。

• 您的處理器必須可讓您啟用硬體輔助虛擬化功能。

  • 此設定通常稱為 Intel 虛擬化技術 (Intel VT) 或進階微裝置虛擬化 (AMD-V)。

• 您的處理器必須支援硬體資料執行防護 (DEP)。

  • 您只能在啟用 Intel 執行停用 (XD) 位元或 AMD 無執行 (NX) 位元時使用 Hyper-V。

避免單一失敗點

規劃虛擬 DC 部署時，您應準備策略以避免建立單一失敗點。 您可以藉由實作系統備援，避免引入潛在的單一失敗點，或停機會導致整個系統停止運作的區域。

下列建議有助於防止單一失敗點。 不過，請務必記住，遵循這些建議會增加系統管理成本。

• 在不同的虛擬化主機上，每個網域至少執行兩個虛擬化 DC。 如果虛擬化主機停止運作，此設定可降低遺失所有 DC 的風險。

• 使執行 DC 的硬體多樣化。 例如，使用不同的 CPU、主機板、網路介面卡等等。 不同的硬體可防止裝置和硬體故障或廠商設定造成損害。

• 如果可能，請在位於不同區域的硬體上執行 DC。 此方法可減少影響其中一個裝載 DC 之網站的災害性後果。

• 將實體 DC 新增至您的所有網域。 設定您的系統讓實體 DC 可防止主機系統發生虛擬化平台故障。

安全性考量

您必須像管理可寫入 DC 一樣仔細管理執行虛擬 DC 的主機，即使電腦只是加入網域或工作群組的電腦。 這項需求是出於安全性考量。 管理錯誤的主機很容易遭受權限提高攻擊，惡意使用者會獲得高於其應有權限的存取權，因為系統管理員將錯誤的權限層級指派給較低層級的角色指派。 這些攻擊可能會危害受影響電腦所裝載的所有虛擬機器 (VM)、網域和樹系。

當您規劃虛擬化 DC 時，請記住以下安全性考量：

• 裝載虛擬可寫入 DC 的電腦的本機管理員認證應被視為等於這些 DC 所屬的所有網域和樹系的預設網域管理員。

• 我們建議您將系統設定為執行 Windows Server 的 Server Core 安裝的主機，除了 Hyper-V 之外沒有任何應用程式。 此設定限制了在伺服器上安裝的應用程式和伺服器的數量。 這項限制會導致更好的系統效能，也會建立降低的攻擊面，其中透過應用程式和服務進行惡意攻擊的進入點較少。

• 對於難以保護的分公司或其他位置，建議您使用唯讀 DC (RODC)。 如果您有單獨的管理網絡，我們建議您僅將主機連接到管理網絡。 如需 RODC 的詳細資訊，請參閱 [安裝 Windows Server Active Directory 唯讀網域控制站 (RODC) (等級 200)]。

• 您可以使用 BitLocker 保護您的 DC。 在 Windows Server 2016 及更新版本中，您也可以使用虛擬可信任平台模組 (TPM) 功能，該功能提供解鎖系統磁碟區所需的客體金鑰資料。

• 受防護網狀架構和受防護的 VM 可以提供其他控制項來保護您的 DC。

如需保護 DC 的詳細資訊，請參閱保護 Active Directory 安裝的最佳做法指南。

主機和客體設定的安全性界限

您可以在許多不同類型的 DC 設定上實作虛擬機器 (VM)。 因此，您必須仔細考慮這些 VM 如何影響 Active Directory 拓撲中的界限和信任。 以下清單介紹了可以為 Hyper-V 伺服器上的 Active Directory DC 和主機，以及做為 Hyper-V 伺服器上執行的 VM 的客體電腦設定的兩種設定：

• 具有 DC 之客體之工作群組或成員電腦的主機。
• 屬於工作群組或成員電腦的主機，其客體也是工作群組或成員電腦。

下圖示範了 Hyper-V 伺服器上裝載的三個客體 DC VM 的設定。

根據上圖中的範例設定，以下是規劃部署時應有的一些重要考量，如下所示：

• 管理員存取權

  • 主機電腦上的管理員認證應與可寫入 DC 上的網域管理員認證相同。 對於 RODC 客體，主機電腦的管理員認證應與客體 RODC 上的本地管理員認證相同。

• 主機電腦上的 DC 管理權限

  • 如果您將虛擬化 DC 的主機加入同一網域，則該主機的管理員對主機具有管理權限。 不過，如果惡意使用者能夠存取 VM 1，此存取權限也可以讓惡意使用者有機會入侵所有 VM。 此案例會建立可能的攻擊媒介。 您可以確定針對多個網域或樹系設定的任何 DC 具有所有網域信任的集中式管理網域，並讓虛擬化主機成為高度特殊權限系統管理網域的成員，以防止此攻擊媒介。 此方法可防止個別網域系統管理員控制主機，進而控制其他網域。

• 避免攻擊

  • 即使您將其安裝為 RODC，惡意使用者還是可能會攻擊 VM 1。 儘管 RODC 管理員沒有明確擁有網域管理員權限，他們仍然可以使用 RODC 將策略套用到主機。 例如，這些策略可能包括啟動指令碼。 如果惡意執行者找到取得 RODC 系統管理員權限的方法，並使用惡意啟動指令碼傳送原則，他們可能會危害主機電腦，並用它來入侵主機上的其他 VM。

• 虛擬硬碟 (VHD) 檔案安全性

  • 虛擬 DC 的 VHD 檔案就像實體 DC 的實體硬碟。 您應該謹慎保護 VHD 檔案，就像使用硬碟一樣。 請確保僅允許可靠且受信任的管理員存取這些 VHD 檔案。

• RODC

  • 您可以將 RODC 放置在無法保證實體安全性的位置，例如分公司。 您可以使用 Windows BitLocker 磁碟機加密來保護其 VHD 檔案，免於攻擊涉及竊取實體磁碟的主機。 不過，這些保護不適用於 RODC 內的檔案系統。

效能考量

Microkernel 64 位元架構在先前的虛擬化平台上具有更佳的 Hyper-V 效能。

VM 效能取決於您所使用的工作負載。 建議您測試特定的 VM 拓撲，以確保您對 Active Directory 部署效能感到滿意。 可以使用可靠性和效能監視器 (Perfmon.msc) 或 Microsoft 評估和規劃 (MAP) 工具組等工具評估特定期間內工作負載下的效能。 MAP 工具還可以説明您清點目前網路中的所有伺服器和伺服器角色。

為了讓您了解測試虛擬化 DC 效能的運作方式，我們使用 Active Directory 效能測試工具 (ADTest.exe) 建立範例效能測試。

輕量型目錄存取通訊協定 (LDAP) 測試是使用 ADTest.exe 在實體 DC 上執行。 相同的測試是在虛擬 DC 上執行，此 DC 是由裝載在與實體 DC 相同之伺服器上的 VM 所組成。 此範例中只使用一個邏輯處理器來建置實體電腦，而 VM 只使用一個虛擬處理器。 此設定允許部署輕鬆達到 100% 的 CPU 使用率。

下表列出實體和虛擬 DC 的測試結果。 測試名稱旁括弧中的字母和數位是其標籤 ADTest.exe。 此資料顯示，虛擬化 DC 效能為實體 DC 效能的 88% 至 98%。

為了將測試部署中的效能最大化，我們在此測試組建中安裝了整合元件 (IC)，以允許客體 OS 使用 Hypervisor 感知綜合驅動程式。 當您安裝 IC 時，有時需要使用模擬的整合式電子驅動介面 (IDE) 或網路介面卡驅動程式。 在生產環境中，您應該將這些模擬的驅動程式取代為綜合驅動程式，以提升效能。

根據這項測試，請考慮下列改善效能的建議：

• 當您使用 Perfmon.msc 工具監視 VM 效能時，有時 VM 的 CPU 資訊並不完全準確。 此不準確是由於虛擬 CPU 在實體處理器上的執行安排方式所造成的。 若要取得在 Hyper-V 伺服器上執行的 VM 的更準確的 CPU 資訊，請改用主機磁碟分割中的 Hyper-V 虛擬機器管理程式邏輯處理器計數器。 如需 AD DS 和 Hyper-V 效能微調的詳細資訊，請參閱 Windows Server 的效能微調指導方針。

• 建議您避免在設定為 DC 的 VM 上使用差異磁碟 VHD，因為差異磁碟 VHD 會降低效能。 若要深入了解 Hyper-V 磁碟類型，包括差異磁碟，請參閱新增虛擬硬碟精靈。

• 我們也建議您閱讀在虛擬裝載環境中裝載 Active Directory DC 時要考慮的事項，以熟悉有關如何在虛擬裝載環境中使用 AD DS 的資訊。

部署考量

下列各節描述部署 DC 時應避免的常見 VM 做法，以及時間同步處理和儲存體的特殊考量。

部署建議

Hyper-V 等虛擬化平台具有許多功能，讓管理、維護、備份和移轉電腦變得更加容易。 不過，您必須遵循某些建議，才能利用虛擬 DC 的這些功能。

• 為了確保 Active Directory 寫入的持久性，請勿在虛擬 IDE 磁碟上部署虛擬 DC 資料庫檔案，例如 NTDS.DIT Active Directory 資料庫、記錄和 SYSVOL。 相反地，請建立連接至虛擬小型電腦系統介面 (SCSI) 控制器的第二個虛擬硬碟 (VHD)，並在安裝 DC 時確定資料庫檔案位於 VM SCSI 磁碟上。

• 不要在設定為 DC 的 VM 上實作差異磁碟 VHD。 雖然這種方法可以輕鬆地將部署還原到以前的版本，但它也會降低效能。 如需 VHD 類型的詳細資訊，請參閱新增虛擬硬碟精靈。

• 在未先使用系統準備工具 (sysprep) 準備部署的情況下，請勿在 Windows Server 作業系統的複本上部署 Active Directory 網域和樹系。 如需執行 Sysprep 的詳細資訊，請參閱 Sysprep (系統準備) 概觀。

  警告

  不建議在已升級的 DC 上執行 Sysprep，因為它可能會對 AD 資料庫和相關元件造成負面影響，並造成下列問題：

  • 資料遺失
  • AD 資料庫損毀
  • 穩定性和功能問題
  • 應用程式、服務和驅動程式問題

• 請勿使用您部署之 DC 的 VHD 檔案複本來部署其他 DC。 不使用複本可防止潛在的 USN 復原案例。 如需 USN 復原的詳細資訊，請參閱 [USN 和 USN 復原]。

  • 在 Windows Server 2012 及更新版本中，管理員可以複製 DC 映像來部署更多 DC，但前提是他們使用正確準備的映像。

• 請勿使用 Hyper-V 匯出功能來匯出執行 DC 的 VM。

  • 在 Windows Server 2012 和更新版本中，系統像非權威還原一樣處理匯出和匯入 DC 虛擬客體。 此程序會偵測世代識別碼是否變更，以及 DC 是否未設定為進行複製。

  • 當您匯出客體 VM 時，您必須確定沒有人正在使用它。 為了簡化工作，您可以使用 Hyper-V 複寫來建立 DC 的非使用中複本。 當您開始使用複寫的映像時，您也必須執行清理，就像在匯出 DC 客體映像後對來源映像所做的那樣。

實體到虛擬轉換

System Center VM Manager (VMM) 可讓您以統一的方式管理實體機器和 VM。 您也可以使用 VMM 將實體機器移轉至 VM。 此移轉程序稱為 實體到 VM 的轉換或 P2V 轉換。 若要啟動 P2V 轉換程式，您必須確定您要移轉的 VM 和實體 DC 不會同時執行。 確保兩部機器未同時執行，能夠防止 USN 復原案例，如 USN 和 USN 復原中所述。

您應該在離線模式下執行 P2V 轉換，以便在重新開啟 DC 時保持目錄資料一致。 您可以在 [轉換實體伺服器] 安裝程式中切換離線模式。 如需如何使用離線模式的詳細資訊，請參閱 [P2V：將實體電腦轉換成 VMM 中的 VM]。

您也應該在 P2V 轉換期間中斷 VM 與網路的連線。 您應該僅在完成轉換程序並驗證一切正常後啟用網路介面卡。 此時，您應該關閉實體來源機器。 在您重新格式化硬碟之前，請勿將實體來源機器重新開啟並重新連線到網路。

避免 USN 復原

當您建立虛擬 DC 時，應該避免建立 USN 復原案例。 為了避免復原，您可以透過定期升級、從媒體安裝 (IfM) 升級來設定新的虛擬 DC，或者如果您已經擁有至少一個虛擬 DC，則可以透過複製 DC 來設定。 此方法也可以讓您避免 P2V 轉換的虛擬客體可能遇到的硬體或平台問題。

測試環境和 P2V 移轉

您可以將 P2V 移轉與 VMM 結合使用來建立測試環境。 透過此方式，您可以將生產 DC 從實體機器移轉至 VM，以建立測試環境，而不需永久關閉生產 DC。 但是，您必須在與生產環境不同的網路上建置測試環境，以允許相同 DC 的兩個執行個體存在。 使用 P2V 移轉建立測試環境時，避免 USN 復原非常重要。

建立測試環境

當您使用 P2V 建立測試環境時，建議您執行下列動作：

• 根據實體到虛擬轉換中的建議，使用 P2V 將生產階段 DC 從每個網域移轉至測試 VM。

• 當您將實體生產機器和測試 VM 重新連線時，請將它們放置在不同的網路中。

• 若要避免測試環境中的 USN 復原，請中斷您計劃從網路移轉的所有 DC 連線。 您可以透過停止 NTDS 服務或在目錄服務還原模式 (DSRM)中重新啟動電腦來中斷 DC 的連線。

• 當您中斷 DC 與網路連線之後，請勿對環境引入任何新的更新。

• 在 P2V 移轉期間，請勿將任何機器連線到網路。 完成所有機器的移轉後，您只能重新連線它們。

• 您應該只將 P2V 轉換之後所做的測試 DC 升級為測試環境中的複本。

時間服務和同步處理

針對設定為 DC 的 VM，我們建議您停用主機系統和充當 DC 的客體 OS 之間的時間同步。 如果客體 DC 未與主機系統同步，則會改為與網域階層同步。

若要停用 Hyper-V 時間同步提供程式，請關閉 VM，然後前往 VM 設定，選取 [整合服務]，並取消核取 [時間同步] 核取方塊。

儲存體和最佳化

建議您遵循本節中的記憶體建議，將您的 DC VM 效能最佳化，並確保 Active Directory 寫入是永久性的。

• 對於客體儲存，將 Active Directory 資料庫檔案 (Ntds.dit)、記錄檔和 SYSVOL 檔案儲存在與 OS 檔案不同的虛擬磁碟上。 我們建議您將這些檔案儲存在連結至虛擬 SCSI 控制器的第二個 VHD 中虛擬 SCSI 磁碟。 虛擬 SCSI 磁碟會增加效能，並支援強制單位存取 (FUA)。 透過 FUA，OS 可以直接從媒體寫入和讀取資料，略過任何快取機制。

• 如果您使用 BitLocker 來保護虛擬 DC 客體，請使用 Enable-BitLockerAutoUnlock PowerShell Cmdlet 來設定自動解鎖的額外磁碟區。

• 將 VHD 檔案儲存在主機上時，您應該使用其他服務或應用程式不常使用的磁碟，例如主機 OS 的系統磁碟。 將每個 VHD 檔案儲存在與主機 OS 和其他 VHD 檔案不同的分區上，最好儲存在單獨的實體磁碟機上。

• 您的主機實體磁碟系統必須至少符合下列條件之一，才能符合虛擬化工作負載資料完整性需求：

  • 主機使用伺服器等級磁碟，如 SCSI 或光纖通道。

  • 主機確保磁碟連接到電池供電的快取 HBA。

  • 主機會使用記憶體控制器，例如獨立磁碟的備援陣列 (RAID) 系統做為其儲存裝置。

  • 主機會使用不斷電供應系統 (UPS) 來為磁碟供電。

  • 主機預設會停用磁碟的寫入快取功能。

• 使用 VHD 檔案時，建議您使用傳遞磁碟或固定大小的 VHD，因為它們已針對效能進行最佳化。 我們不建議動態擴充和差異磁碟，因為它們可能會在高磁碟活動期間造成延遲、效能降低，以及在復原到先前的快照集時可能會遺失資料。

• 我們建議您使用虛擬 SCSI 控制器來減少 Active Directory 資料損毀的可能性。

  • 在裝載虛擬 DC 的 Hyper-V 伺服器上，您應該使用 SCSI 實體磁碟機。 如果您的案例未讓您使用 SCSI 磁碟機，您應該停用您正在使用的進階技術附件 (ATA) 或整合式電子驅動介面 (IDE) 磁碟機上的寫入快取。 如需詳細資訊，請參閱事件識別碼 1539 - 資料庫完整性。

VM 網域控制站的操作限制

在 VM 上執行的網域控制站具有不適用於在實體機器上執行的 DC 的作業限制。 當您使用虛擬化 DC 時，必須遵循下列指導方針：

• 不要在 VM 中暫停、停止或儲存 DC 的已儲存狀態，時間長於樹系的標記存留期。 繼續您已暫停或已儲存超過標記存留期的已儲存狀態可能會干擾複寫。 若要了解如何判斷樹系的標記存留期，請參閱判斷樹系的標記存留期。

• 請勿複製或重製 VHD。

• 請勿擷取或使用虛擬 DC 的快照集。 您應該改用更永久且可靠的備份方法。

• 請勿在執行 DC 的 VM 上使用匯出功能。

• 請勿使用不支援的備份方法來還原或復原 DC 或 Active Directory 資料庫的內容。

備份和還原考量

您必須備份 DC，以避免因災害案例或系統管理錯誤而遺失資料。 Active Directory 支援的備份方法是使用備份應用程式來還原從 DC 目前安裝所建立的系統狀態備份。 此應用程式應該是與 Active Directory 相容的應用程式，例如 Windows Server Backup。 如需支援備份方法的詳細資訊，請參閱 [AD DS 備份和還原逐步指南]。

在虛擬化部署中，您必須特別注意 Active Directory 備份作業的特定需求。 例如，如果您使用 VHD 檔案的復本還原 DC，而且在還原 DC 之後不會更新 DC 的資料庫版本，它可能會導致複寫問題，因為 DC 複本中的追蹤號碼不正確。 在大部分情況下，複寫不會偵測到此問題，而且不會報告任何錯誤，但 DC 之間的不一致可能會在特定案例中造成問題。

備份和還原虛擬化 DC 的建議方法

我們建議您用於備份和還原虛擬化 DC 的方法，就是在客體 OS 中執行 Windows Server Backup。 如需詳細資訊，請參閱 [還原虛擬網域控制站]。

雖然您在技術上可以使用快照集或 VHD 檔案的複本來還原備份，但我們不建議出於下列原因使用這些方法：

• 如果您複製或重製 VHD 檔案，資料庫就會變成過時，因為其資料庫版本號碼不會在您還原它時自動更新。 追蹤編號中的這種不一致表示如果您以正常模式啟動 VHD，可能會造成 USN 復原。

• 雖然 Windows Server 2016 和更新版本與快照集相容，但快照集不會提供在災害案例期間持續還原系統所需的穩定、永久備份歷程記錄類型。 您可以在 Windows Server 2016 Hyper-V 和更新版本中，建立的磁碟區陰影複製服務 (VSS) 型快照集也與 BitLocker 不相容，這可能會導致潛在的安全性問題。 此問題會防止 Active Directory 資料庫引擎在 Hyper-V 嘗試掛接快照集磁碟區時存取包含快照集的資料庫。

USN 和 USN 復原

本節描述可能因為使用舊版 VM 不正確地還原 Active Directory 資料庫而發生的複寫問題。 如需 Active Directory 複寫程序的詳細資訊，請參閱 Active Directory 複寫概念。

AD DS 和 DC 如何使用 USN

AD DS 會使用 USN 來追蹤 DC 之間的資料複寫。 每次變更目錄中的資料時，USN 都會遞增以指出新的變更。

目的地 DC 會使用 USN 來追蹤其儲存的每個目錄分割區更新。 USN 也會追蹤儲存這些目錄分割區複本的每個 DC 的狀態。 當 DC 相互複寫變更時，它們會向其複寫夥伴查詢，是否存在 USN 大於 DC 從其夥伴收到的最後變更的變更。

您可以在最新向量和上限標記中找到包含 USN 的複寫中繼資料表。 來源和目的地 DC 都使用這些資料表來篩選目的地 DC 所需的更新。

目的地 DC 維護最新向量資料表，以追蹤它從所有來源 DC 接收的原始更新。 當目的地 DC 要求變更目錄磁碟分割時，它會將其最新向量提供給來源 DC。 接著來源 DC 會使用此值來篩選傳送至目的地 DC 的更新。 成功的複寫週期完成後，來源 DC 將其最新向量傳送到目的地 DC。 來源 DC 使用 USN 追蹤目的地 DC 是否與每個 DC 的原始更新同步，以及目的地的更新是否與來源處於同一級別。

目的地 DC 會維護上限標記資料表，以追蹤它從特定分區的特定來源 DC 接收到的最新變更。 上限標記資料表會防止來源 DC 送出目的地 DC 已從中接收的變更。

目錄資料庫身分識別

除了 USN 之外，DC 也會追蹤來源複寫夥伴的目錄資料庫。 系統將伺服器上執行的目錄資料庫的身分識別與伺服器物件本身的身分識別分開維護。 每個 DC 上的目錄資料庫身分識別都會儲存在 NTDS Settings 物件的 invocationID 屬性中，其位於輕量型目錄存取通訊協定 (LDAP) 路徑 cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain* 底下。

系統將伺服器物件身分識別儲存在 NTDS Settings 物件的 objectGUID 屬性中。 伺服器物件的身分識別永遠不會變更。 不過，在下列情況下，目錄資料庫的身分識別會變更：

• 伺服器上發生系統狀態還原程序時。

• 當您將應用程式目錄分割區新增至伺服器時，請將其移除，然後再新增一次。

• 當 Hyper-V 執行個體在包含虛擬 DC VHD 的磁碟分割上觸發其 VSS 寫入器時。

  在此案例中，客體會觸發其自己的 VSS 寫入器。 此動作與備份和還原程序所使用的機制相同。 這個方法會重設 invocationID 屬性。

invocationID 屬性會將 DC 上的一組原始更新與目錄資料庫的特定版本相關聯。 最新向量和上限標記資料表會分別使用 invocationID 和 DC GUID，讓 DC 辨識複寫資訊的來源 Active Directory 資料庫複本。

invocationID 屬性是全域唯一識別碼 (GUID) 值，在您執行命令 repadmin /showrepl 之後，會在輸出頂端附近看見。 下列文字代表命令的範例輸出：

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

當您在 DC 上還原 AD DS 時，系統會重設 invocationID 屬性。 此變更會增加複寫流量，其持續時間與您要複寫的磁碟分割的大小有關。

為了示範此案例，下圖說明虛擬網域控制站 VDC1 和域控制站 DC2 是相同網域中的兩個 DC 的範例環境。 此圖顯示在受支援的還原案例中重設後，DC2 如何偵測 VDC1 中的 invocationID 值。

USN 復原

當系統無法正常更新 USN、使用者規避 USN 更新，或 DC 嘗試使用低於其最新更新的 USN 時，將發生 USN 復原。 當系統偵測到 USN 復原時，它會在不相符導致樹系中出現分歧之前停止複寫。

許多因素可能會導致 USN 復原。 例如，如果您使用舊的 VHD 檔案或執行 P2V 轉換，而未在轉換後永久中斷實體機器的連線，則可能會發生這種情況。

防止 USN 復原

您可以採取下列預防措施來防止 USN 復原：

• 未執行 Windows Server 2012 或更新版本時，請勿擷取或使用 DC VM 的快照集。

• 請勿複製 DC VHD 檔案。

• 未執行 Windows Server 2012 或更新版本時，請勿匯出執行 DC 的 VM。

• 僅使用受支援的第一方備份解決方案 (如 Windows Server Backup) 還原 DC 或復原 Active Directory 資料庫的內容。

有時候系統在可能會導致複寫錯誤之前，無法偵測 USN 復原。 當您遇到複寫錯誤時，必須識別問題的範圍，並盡快加以解決。 如需如何移除因 USN 復原而發生的延遲物件的詳細資訊，請參閱 [Active Directory 複寫事件識別碼 1388 或 1988：偵測到延遲物件]。

USN 復原偵測

大多數情況下，系統可以透過追蹤 DC 還原導致的 invocationID 屬性不一致來偵測 USN 復原，而無需重設該屬性。 Windows Server 2008 在不受支援的 DC 還原操作後提供針對複寫錯誤的保護。 當不受支援的還原建立低於原始版本的 USN (代表複寫夥伴已收到的變更) 時，將觸發這些保護。

在 Windows Server 中，當目的地 DC 使用以前使用的 USN 請求變更時，目的地 DC 會將複寫夥伴回應解釋為意味著其複寫中繼資料已過期。 過期的中繼資料表示來源 DC 上的 Active Directory 資料庫復原為先前的狀態，因此系統會據此回應。

例如，假設 VM 的 VHD 檔案復原為舊版。 在這種情況下，目的地 DC 會對它識別為經歷了不受支援的還原的 DC，啟動以下隔離措施：

• AD DS 會暫停 Net Logon 服務，其會防止使用者帳戶和電腦帳戶變更帳戶密碼。 此動作可防止在還原不當之後發生此情況時遺失這類變更。

• AD DS 會停用輸入和輸出 Active Directory 複寫。

• AD DS 會在目錄服務事件記錄檔中產生事件識別碼 2095 以記錄發生的情況。

下圖顯示當 AD DS 偵測到 VDC2 (VM 上執行的目的地 DC) 上的 USN 復原時，所發生的事件順序。 在此圖中，當複寫夥伴偵測到 VDC2 已傳送目的地 DC 先前看到的最新 USN 值時，就會在 VDC2 上發生 USN 復原偵測。 此情況表示 VDC2 資料庫發生復原。

解決事件識別碼 2095 問題

如果您在目錄服務事件記錄檔中看到事件識別碼 2095，請立即遵循下列指示：

1. 隔離記錄來自網路錯誤的 VM。

2. 檢查回報的變更是否源自此 DC 並傳播至其他 DC。 如果事件是由於使用 VM 快照集或複本導致的，請嘗試找出 USN 復原發生的時間。 一旦得知時間，您可以檢查該 DC 的複寫夥伴以確定復原後是否發生複寫。

   您可以使用 Repadmin 工具來檢查變更的來源。 如需如何使用 Repadmin 的詳細資訊，請參閱使用 Repadmin 監視和疑難排解 Active Directory 複寫。 如果您無法做出判斷，請連絡 Microsoft 支援服務以尋求協助。

3. 強制降級 DC。 此作業牽涉到清除 DC 的中繼資料，並擷取作業主機角色，也稱為彈性單一主機作業或 (FSMO) 角色。 有關詳細資訊，請參閱 [從 USN 復原中還原]。

4. 刪除 DC 的所有先前 VHD 檔案。

未偵測到的 USN 復原

在下列案例中，DC 可能不會偵測到 USN 復原：

• VHD 檔案同時連結至多個位置中執行的不同 VM。

• 已還原 DC 上的 USN 增加超過其他 DC 收到的最後一個 USN。

在 VHD 檔案案例中，其他 DC 可能會使用其中一個 VM 進行複寫，而在另一個 VM 上可能發生變更，而不會複寫到另一個 VM。 樹系的此分歧難以偵測，而且會導致無法預測的目錄回應。 如果實體 DC 和 VM 都在相同網路上執行，P2V 移轉之後就會發生此情況。 如果從相同的實體 DC 建立多個虛擬 DC，然後在相同網路上執行，也可能會發生此情況。

在 USN 案例中，有各種 USN 適用兩組不同的變更。 此案例可以在未偵測到的情況下繼續一長段時間。 當您修改在此期間建立的物件時，系統會偵測到延遲物件，並在事件檢視器中將其報告為事件識別碼 1988。 下圖顯示為什麼 DC 無法偵測到此案例中的 USN 復原。

唯讀 DC

唯讀網域控制站 (RODC) 是裝載 Active Directory 資料庫中磁碟分割唯讀複本的 DC。 RODC 會避免大部分 USN 復原問題，因為它們不會將任何變更複寫到其他 DC。 但是，如果 RODC 從受 USN 復原影響的可寫入 DC 進行複寫，則復原也會影響 RODC。

不建議使用快照集來還原 RODC。 您應該僅使用與 Active Directory 相容的備份應用程式來還原 RODC。 此外，與可寫入 DC 一樣，您不得允許 RODC 離線時間超過標記存留期。 此條件可能會導致 RODC 上的延遲物件。

如需實作 RODC 的詳細資訊，請參閱唯讀網域控制站逐步指南。

其他內容

了解如何在還原虛擬化網域控制站中虛擬化 DC。