使用 Hyper-V 虚拟化域控制器

• 适用于:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Windows Server 2012 及更高版本支持附带安装措施的虚拟化域控制器 (DC) 来防止虚拟 DC 回滚更新序列号 (USN) 以及克隆虚拟 DC。 虚拟化会将不同服务器角色合并到单个物理计算机上。 有关更多信息，请参阅《安全虚拟化 Active Directory 域服务 (AD DS)》。

本指南介绍如何将 DC 作为 32 位或 64 位来宾操作系统来运行。

规划虚拟化

以下各节包含虚拟化 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 2012 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 的配置。

包含三个虚拟机 (VM) 和 Hyper-V 服务器的示例部署示意图。 这三个 VM 均位于标记为“来宾计算机”的蓝色矩形内。 这三个 VM 均为域控制器。 VM 1 位于 Corp 域和 Contoso.com 林中。 VM2 位于 Fabrikam 域和 Fabrikam.com 林中。 VM 3 位于 HQ 域和 Fineartschool.net 林中。 Hyper-V 服务器位于蓝色矩形之外。 它是位于 Corp 域和 Contoso.com 林中的一个成员服务器。

根据上图中的示例配置，规划部署时应关注的部分重要注意事项如下：

• 管理员访问权限

  • 主机上的管理员凭据应视为与可写 DC 上的域管理员凭据相同。 对于 RODC 来宾，主机的管理员凭据应视为与来宾 RODC 上的本地管理员凭据相同。

• 主机的 DC 管理权限

  • 如果将主机加入同一域，虚拟化 DC 的管理员则具有该主机的管理权限。 但是，如果恶意用户可获得 VM 1 的访问权限，则此访问特权还可能会让恶意用户入侵所有 VM。 此时便会形成潜在的攻击途径。 可通过确保为多个域或林配置的所有 DC 均具有受到所有域信任的集中式管理域，并使虚拟化主机成为高度特权管理域的成员，从而阻止此攻击途径。 此方法可防止单个域管理员控制主机，从而控制其他域。

• 避免遭受攻击

  • 即使将 VM 1 安装为 RODC，恶意用户也会攻击该 VM。 虽然 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 和虚拟 DC 的测试结果。 测试名称旁的括号内的字母和数字为这些测试在 ADTest.exe 中的标签。 此数据表明，虚拟化 DC 的性能为物理 DC 性能的 88% 到 98% 之间。

度量	测试	物理	虚拟	增量
搜索次数/秒	在基本范围内搜索通用名称 (L1)	11508	10276	-10.71%
搜索次数/秒	在基本范围内搜索一组属性 (L2)	10123	9005	-11.04%
搜索次数/秒	在基本范围内搜索所有属性 (L3)	1284	1242	-3.27%
搜索次数/秒	在子树范围内搜索通用名称 (L6)	8613	7904	-8.23%
成功绑定次数/秒	执行快速绑定 (B1)	1438	1374	-4.45%
成功绑定次数/秒	执行简单绑定 (B2)	611	550	-9.98%
成功绑定次数/秒	使用 NTLM 执行绑定 (B5)	1068	1056	-1.12%
写入次数/秒	写入多个属性 (W2)	6467	5885	-9.00%

为了最大限度地提高测试部署的性能，我们在此测试版本中安装了集成组件 (IC)，从而允许来宾 OS 使用虚拟机监控程序感知合成驱动程序。 安装 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) 来为部署准备 Active Directory 域和林的情况下，在 Windows Server 操作系统副本上部署这些域和林。 更多有关运行 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 虚拟来宾的导出和导入。 此流程会检测生成 ID 是否更改，以及是否未配置 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 回滚情况。 为避免出现回滚，如果已至少有一个虚拟 DC，则可以通过定期提升、“从媒体安装”(IfM) 提升以及克隆 DC 来设置新的虚拟 DC。 此举也可避免 P2V 转换的虚拟来宾可能出现的硬件问题或平台问题。

警告

为防止 Active Directory 复制出现问题，请确保在任意时间点的特定网络上仅存在一个物理或虚拟 DC。 可以通过以下方法之一来降低旧克隆出现问题的可能性：

• 当新的虚拟 DC 正在运行时，运行以下命令两次可更改计算机帐户密码：

  netdom resetpwd /Server:<domain-controller>
  

• 导出再导入新的虚拟来宾，以强制它成为新的生成 ID 和数据库调用 ID。

测试环境和 P2V 迁移

可将 P2V 迁移与 VMM 结合使用来创建测试环境。 借助此方法，可将生产 DC 从物理机迁移到虚拟机以创建测试环境，而无需永久关闭生产 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) 驱动器上禁用写入缓存。 有关详细信息，请参阅事件 ID 1539 – 数据库完整性。

VM 域控制器的操作限制

VM 上运行的域控制器存在一些不适用于物理机上运行的 DC 的操作限制。 使用虚拟化 DC 时，必须遵循以下准则：

• 在 VM 中暂停、停止或存储 DC 的已保存状态的时长不得超过林的逻辑删除生存期。 恢复暂停或保存时长超过逻辑删除生存期的已保存状态可能会干扰复制操作。 若要了解如何确定林的逻辑删除生存期，请参阅《确定林的逻辑删除生存期》。

• 请勿复制或克隆 VHD。

• 请勿创建或使用虚拟 DC 的快照。 应改用更永久且可靠的备份方法。

• 请勿在运行 DC 的 VM 上使用导出功能。

• 请勿使用不支持的备份方法来还原或回滚 DC 或 Active Directory 数据库的内容。

备份和还原注意事项

必须备份 DC，以免因灾难或管理错误而导致数据丢失。 Active Directory 支持的备份方法是：使用备份应用程序来还原从 DC 的当前安装所创建的系统状态备份。 此应用程序应与 Active Directory 兼容，例如 Windows Server 备份。 有关受支持备份方法的详细信息，请参阅 AD DS 备份和恢复分步指南。

在虚拟化部署中，需特别注意针对 Active Directory 备份操作的某些要求。 例如，如果使用 VHD 文件的副本来还原 DC，且在还原 DC 后未更新 DC 的数据库版本，则可能会导致因 DC 副本中的跟踪数字不准确而出现复制问题。 大多数情况下，复制操作不会检测到此问题，且不会报告任何错误，但各 DC 之间的不一致却可能导致在某些情况下出现问题。

备份和还原虚拟化 DC 的建议方法

建议用于备份和还原虚拟化 DC 的方法是：在来宾 OS 中运行 Windows Server 备份。 有关详细信息，请参阅还原虚拟域控制器。

虽然其实可使用 VHD 文件的快照或副本来还原备份，但因以下原因不建议使用这些方法：

• 如果要复制或克隆 VHD 文件，数据库则会变为过时状态，因为还原数据库时数据库版本号不会自动更新。 跟踪编号不一致意味着，在正常模式下启动 VHD 时可能会导致 USN 回滚。

• 虽然 Windows Server 2016 及更高版本与快照兼容，但快照不提供在灾难情况下以一致的方式还原系统所需的稳定且永久的备份历史记录。 在 Windows Server 2016 Hyper-V 及更高版本中创建的基于卷影复制服务 (VSS) 的快照也与 BitLocker 不兼容，而这可能会导致潜在安全问题。 此问题可防止 Active Directory 数据库引擎在 Hyper-V 尝试装载快照卷时访问包含快照的数据库。

注意

受保护的结构和受防护的 VM 中所述的受防护的 VM 项目会将由 Hyper-V 主机驱动的备份作为一项对来宾 VM 进行最大程度数据保护的非目标。

USN 和 USN 回滚

本部分描述由于使用旧版 VM 错误还原 Active Directory 数据库而可能出现的复制问题。 更多有关 Active Directory 复制的信息，请参阅《Active Directory 复制概念》。

AD DS 和 DC 如何使用 USN

AD DS 使用 USN 跟踪 DC 之间的数据复制。 每次对目录中的数据进行更改时，USN 均会递增以表示一项新更改。

目标 DC 使用 USN 来跟踪它们存储的每个目录分区的更新。 USN 还会跟踪用于存储这些目录分区的副本的所有其他 DC 的状态。 当各个 DC 相互复制更改时，它们会以大于其上次从其伙伴处收到的 USN 的 USN 来查询其复制伙伴是否出现更改。

可在最新矢量和高水位标志中找到包含这些 USN 的复制元数据表。 源 DC 和目标 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 值进行检测。

一个示意图，其中描绘了 VDC1 的自身视图以及 DC2 的 VDC1 视图的流程图。 在 VDC1 行上，VDC1 以 USN 1000 开头，且调用 ID 为 B。然后，它会还原到其以前的版本，而此时其 USN 为 500，调用 ID 的值为 B。VDC1 会出现更改，从而使其回到 USN 600，而调用 ID 则保持不变。 在名为“VDC1 的 DC2 视图”行中，DC2 会以 VDC1(A)@USN1000 调用 ID 开头。 还原 VDC1 后，DC2 会将其预计 USN 从 1000 重置为 500，从而使其值对应于调用 ID B VDC1(B)@USN500。 接着，它会继续同时跟踪调用 ID A 和调用 ID B。而在 VDC1 上出现下一组更改后，DC2 此时便会跟踪 VDC1 的调用 ID A (USN 1000) 及其新的调用 ID B (USN 600)。

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 备份）来还原 DC 或回滚 Active Directory 数据库的内容。

有时，在出现可能导致复制错误的 USN 回滚之前，系统无法检测到此回滚。 出现复制错误时，必须确定此问题的程度并尽快解决。 有关如何删除因 USN 回滚而导致的滞留对象的详细信息，请参阅 Active Directory 复制事件 ID 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 暂停网络登录服务，防止用户帐户和计算机帐户更改帐户密码。 如果在执行不当还原后发生此类更改，此操作可防止丢失这些更改。

• AD DS 禁用入站和出站 Active Directory 复制。

• AD DS 会在目录服务事件日志中生成事件 ID 2095 以记录出现的情况。

下图显示了在 VDC2（在 VM 上运行的目标 DC）上当 AD DS 检测到 USN 回滚时所出现的一系列的事件。 在此图中，当复制伙伴检测到 VDC2 已发送一个目标 DC 已看过的最新 USN 值时，便会检测到 VDC2 出现了 USN 回滚。 此情况表示 VDC2 数据库已出现回滚。

一个示意图，其中描绘了 VDC2 更新的流程图以及 VDC2 的 DC1 最新值。 VDC2 会以 USN 100 和调用 ID A 开头。然后，它会将其 USN 从 101 更新到 200，并将此更改复制到 DC1。 但是，用户还会创建 VDC2 USN 200 的 VHD 副本。 接下来，VDC2 会将 USN 201 更新到 350，并将这些更改复制到 DC1。 但是，VDC2 随后失败。 然后，用户使用其为 USN 200 VHD 创建的副本来还原 VDC2。 之后，用户针对 201-355 的新版本 USN 对 VDC2 进行另一更新。 DC1 请求从 VDC2 获取大于 USN 350 的更改并复制这些更改，因为 VDC2 上的 USN 大于 DC1 上的 USN。 但是，201 到 350 的新版本 USN 与 DC1 上的 USN 不同，从而导致出现 USN 回滚。

解决事件 ID 2095 问题

如果在目录服务事件日志中发现事件 ID 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。 林中的这种分歧很难检测到，会导致不可预测的目录响应。 如果物理机和虚拟机在同一网络上运行，则在执行 P2V 迁移后可能会出现这种情况。 如果从同一个物理机创建了多个 DC 且 DC 都在同一网络上运行，则也可能会发生这种情况。

如果是 USN，则会将一系列 USN 应用于两组不同的更改。 这种情况可能持续很长时间而不被检测到。 修改在此期间创建的对象时，系统会检测到一个滞留对象，并在事件查看器中将其报告为事件 ID 1988。 下图演示了 DC 在此场景中可能无法检测到 USN 回滚的原因。

显示示例生成中回滚检测流程的流程图的示意图。 有两个域控制器，而它们分别被标记为“VDC1”和“DC2”。 流程图的初始阶段表明虚拟 DC VDC1 在其 USN 为 2000 时创建了一个快照。 创建快照后，VDC1 创建了 100 个用户，而更新后的 VDC1 现在的 USN 则为 2100。 VDC1 上的更新会复制到 DC2，而此时它的 USN 也为 2100。 但是，VDC1 随后会使用其创建的快照来恢复为 USN 2000 版本。 还原后的 VDC1 版本会创建 150 个新用户，从而使其 USN 达到 2150。 更新后的 VDC1 会复制到 DC2，但 DC2 未检测到不匹配的更改，因为它的 USN 大于 DC2 的 USN (2100)。 底部所示文本为：“未检测到 USN 回滚，从而导致两个域控制器之间从 2001 到 2100 的 USN 出现不一致，即已出现未检测到的分歧。”

只读 DC

只读域控制器 (RODC) 是指在 Active Directory 数据库中托管只读分区副本的 DC。 RODC 能避免大多数的 USN 回滚问题，因为它们不会向其他 DC 复制更改。 但是，如果 RODC 从受 USN 回滚影响的可写 DC 进行复制，则该回滚也会影响此 RODC。

不建议使用快照来还原 RODC。 应仅使用与 Active Directory 兼容的备份应用程序来还原 RODC。 此外，与可写 DC 一样，须确保不让 RODC 的脱机时间超过逻辑删除生存期。 这种状况可能会导致 RODC 上出现延迟对象。

更多有关实现 RODC 的信息，请参阅《只读域控制器分步指南》。

其他内容

通过还原虚拟化域控制器来了解如何还原虚拟化 DC。