wangjiliang

Active Directory 灾难恢复

Active Directory 灾难恢复
操作系统

白皮书

摘要

Active Directory™ 服务以及保证其顺利运行所需的系统是 Windows® 2000 Server 操作系统的核心。系统管理员必须了解如何使这些关键的系统保持正常运行，以及在出现故障时如何采取应对措施。

在 Active Directory 基础结构中，域控制器可以充当多种角色 — 全局编录 (GC)、操作主机 (OM) 以及单一域控制器。本文中介绍了在出现故障后恢复 Active Directory 数据库的步骤，而且还介绍了将服务器还原为特定角色所必需的特殊要求。

本文档中介绍的步骤已经经过了 Compaq QTEST Windows 2000 机构进行的恢复操作的验证。QTEST 是基于 Windows 2000 的服务器的全球部署，Compaq 顾问用它来验证和测试不同的部署方案。

引言

本文讨论将域控制器从灾难状态（例如由于硬件或软件故障引起的数据库故障）进行恢复的步骤。此类灾难通常会导致域控制器失效，而且会使计算机无法正常引导。导致灾难的另一个原因是人为因素，例如将包含错误的数据复制到公司的其它域控制器上。

本文提供有关对运行 Active Directory 的域控制器（不运行其它服务）进行恢复的信息。如果该计算机上还安装有其它服务，例如域名系统 (DNS) 或 Internet 信息服务 (IIS)，则可能还需要其它步骤，但是这些步骤不包括在本文中。

本文中的大多数示例都是基于 Windows 2000 备份实用程序 (ntbackup.exe) 的，该程序是 Windows 2000 中附带的默认备份应用程序。有关该工具的更多信息，可以在附录 IV 中找到。用户可以有自己喜欢的备份应用程序，但是本文中的内容仍然适用。

本文不讨论涉及 Active Directory 的故障排除问题。而是用于解决如下情况：所有的故障排除手段都已经失败，并且 Active Directory 无法正常运行，在这种情况下用户无法将域管理器引导到正常模式。

本文假定用户具有关于 Active Directory 及其相关组件的预备知识。有关 Active Directory 的信息，请阅读 Windows 2000 Server Resource Kit 中的 Distributed Systems Guide 一书。

系统管理员可以使用本文中的信息来制定灾难恢复规划，但是本文还必须与本单位内部环境以及现有灾难恢复策略中的具体信息相结合。

Active Directory 概述

Active Directory 服务是 Windows 2000 的目录服务。它是操作系统的核心组件，为企业和操作系统中的其它组件提供基本数据。

Active Directory 为管理员提供组织网络资源，管理用户、计算机和应用程序所需要的中心服务。

在 Active Directory 中可以存储许多不同的对象，包括：

用户。
组。
安全凭据，例如证书。
系统资源，例如计算机（或服务器）和打印机。
复制组件，设置本身也是 Active Directory 中的对象。
COM 组件配置，以前它存储在 Windows NT 中的注册表中，现在则存储在 Active Directory 的类中。
控制工作环境的规则和策略。

下面的图 1 描述了集中存储在 Active Directory 中的许多不同对象。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV01.GIF" frameborder="0" width="95%" height="299">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 1 可以存储在 Active Directory 中的许多不同对象。

Active Directory 数据库

Active Directory 是一个事务处理数据库系统，它使用日志文件来支持回滚语法，从而确保将事务提交到数据库中。与 Active Directory 关联的文件包括：

Ntds.dit — 数据库。
Edbxxxxx.log — 事务日志。
Edb.chk — 检查点文件。
Res1.log 和 Res2.log — 预留的日志文件。

Ntds.dit 会随着数据库的填充而不断增大。但是，日志的大小却是固定的 (10 MB)。对数据库进行的任何更改都会被追加到当前的日志文件中，而且其磁盘映像会不断保持更新。

Edb.log 是当前的日志文件。对数据库进行更改后，会将该更改写入到 Edb.log 文件中。当 Edb.log 文件充满事务之后，它会被重新命名为 Edbxxxxx.log。（从 00001 开始，并使用十六进制累加。）由于 Active Directory 使用循环记录，所以在旧日志文件写入数据库之后，这些旧日志文件会及时删除。在任何时刻都可以找到 edb.log 文件，而且还可能有一个或多个 Edbxxxxx.log 文件。

Res1.log 和 Res2.log 是“占位符”— 用来在此驱动器上预留（在此情况下）最后的 20 MB 磁盘空间。这是为了给日志文件提供足够的空间，以便在其它所有磁盘空间都已使用的情况下可以正常关机。

Edb.chk 文件存储数据库的检查点，这些检查点标识数据库引擎需要重复播放日志的点，通常在恢复或初始化时。

出于性能考虑，日志文件应该位于数据库所在磁盘以外的其它磁盘上，以减少磁盘争用情况。

在进行备份时，可能会创建新的日志文件。如前所述，由于要进行循环记录，所以需要删除该日志文件（如常规旧日志文件）。

Active Directory 服务器和角色

authentication service域控制器 (DC) 是上面驻留有域数据库并执行验证服务的服务器。在 Windows 2000 Server 中，域数据库是 Active Directory 数据库的一部分。在 Windows 2000 中，对象更改可以在该环境内的任何 DC 上执行，而不是象在 Windows NT Server 4.0 中那样，只能在主域控制器 (PDC) 上进行。

DC 必须启动并执行复制操作，以确保环境中的所有 DC 上都驻留有当前和正确的目录版本。另外，在特定目录林中的所有域控制器上都驻留有目录林配置和架构容器的副本。

域控制器还可以作为全局编录或充当如下所述的特定角色。为应对可能出现的故障情况，知道特定 DC 是一个 GC 还是承担了操作主机角色非常重要，因为只有这样才能采取正确的行动。

全局编录

全局编录的主要功能是在整个 Active Directory 目录林内进行快速和有效的搜索。GC 拥有它所属的域中所有对象的可读/写的完全副本，以及目录林中其它每一个域中的只读部分副本（所有对象，但不包括部分属性集）。因此，全局编录使目录林内的目录结构对于最终用户而言是透明的，从而为用户创造了一个使得在目录中查找对象变得简单和有效的搜索机制。

另外，为在本机 Windows 2000 域中进行通用组成员和用户主要名称 (UPN) 枚举，也需要全局编录。因此，如果 DC 不能在客户端登录时联系到 GC，则客户端将只接收到缓存的本地登录凭据，而对远程资源进行的访问将被拒绝。

注意若要知道 DC 是否为全局编录服务器，请查看站点和服务管理单元中的 ntdsDSA 对象的属性。（在域控制器的 Ntds 设置上单击鼠标右键，然后选择属性。）如果选中全局编录复选框，则该 DC 就是一台全局编录服务器。可以在任何现用的 DC 上查看该管理单元，以检查出现故障的 DC 是否为 GC。

操作主机服务器

Active Directory 支持多主机更新。在每一个 DC 上都驻留有其目录分区的可读/写版本。因此，Active Directory 必须可以进行存在冲突的更改，例如在不同的 DC 上同时对目录中同一对象进行的更改。Active Directory 使用定义完善的冲突解决方法，从而使所有的 DC 最终都趋近相同的值。

尽管具有该定义完善的方法，但有时防止出现冲突比在出现问题之后解决冲突要好。在冲突解决方法不适用时，Active Directory 中的操作主机会防止进行冲突更新。

Active Directory 定义了五种操作主机角色：

架构主机
域命名主机
相对标识号 (RID) 主机
主域控制器模拟器 (PDCE)
基础结构主机

架构主机和域命名主机是按目录林分配的角色，表示在整个目录林中只有一个架构主机和一个域命名主机。其它操作主机角色都是按照域分配的角色，表示目录林中的每一个域都有自己的 RID 主机、PDCE 和基础结构主机。

若要检查哪一台 DC 具有域命名主机角色，请打开“域和信任”管理单元。若要检查架构主机，请打开“架构”管理单元。对于任意按照域分配的角色，请检查“用户和计算机”管理单元。在每一个管理单元的最高层容器（在左侧窗格中），单击鼠标右键并选择操作主机。

“架构”管理单元不是随 Windows 2000 Server 一起提供的默认 MMC 管理单元。若要使它出现在可用管理单元列表中，必须从 Windows 2000 Server CD 中安装管理工具软件包 (Adminpak.msi)。

若要注册“架构”管理单元，请在命令提示符下或在开始菜单上的运行命令中键入 Regsvr32 schmmgmt.dll。

架构主机

具有架构主机角色的 DC 是可以更新目录架构的唯一 DC。这些架构更新会从架构主机复制到目录林中的所有其它域控制器中。

域命名主机

具有域命名主机角色的 DC 是可以执行以下任务的唯一 DC：

相对标识号 (RID) 主机

此操作主机负责向其它 DC 分配 RID 池。只有一个服务器执行此任务。在创建安全主体（例如用户、组或计算机）时，需要将 RID 与域范围内的标识符相结合，以创建唯一的安全标识符 (SID)。

每一个 Windows 2000 DC 都会收到用于创建对象的 RID 池（默认为 512）。RID 主机通过分配不同的池来确保这些 ID 在每一个 DC 上都是唯一的。通过 RID 主机，还可以在同一目录林中的不同域之间移动所有对象。

PDCE

主域控制器模拟器提供以下主要功能：

向后兼容低级客户端和服务器，允许 Windows NT4.0 备份域控制器 (BDC) 加入到新的 Windows 2000 环境。
本机 Windows 2000 环境将密码更改转发到 PDCE。每当 DC 验证密码失败后，它会与 PDCE 取得联系，以查看该密码是否可以在那里得到验证，也许其原因在于密码更改还没有被复制到验证 DC 中。
时间同步 — 目录林中各个域的 PDCE 都会与目录林的根域中的 PDCE 进行同步。

基础结构主机

基础结构主机确保所有域间操作对象的一致性。当引用另一个域中的对象时，此引用包含该对象的全局唯一标识符 (GUID)、安全标识符 (SID) 和可分辨的名称 (DN)。如果被引用的对象移动，则在域中担当结构主机角色的 DC 会负责更新该域中跨域对象引用中的 SID 和 DN。

Active Directory 复制

由于 Windows 2000 DC 拥有其所在域中的所有对象的副本，并且具有这些对象的读/写权限，所以通过该域中的任一 DC 都可以对该域进行管理。这些操作会影响对象的状态，因此必须要将这些操作复制到其它 DC 中。

复制是在 DC 中传播对象更新的过程。

已更改对象的复制并不会立即执行。在一段时间后，复制操作会触发，该操作将收集所有的更改并将这些信息提供给集合中的其它 DC。因此在正常操作中，可以认为任何 DC 上的 Active Directory 始终处于松散的一致状态。也就是说，由于复制更改可能正处在从其它 DC 传送的过程中或正在等待触发，所以有关 Windows 2000 环境中所有 DC 的信息很可能是不同的。最终，这些更改会到达，每一个 DC 会与其它 DC 同步。

在考虑 Active Directory 的恢复技术时，复制和松散一致性是非常重要的概念。

Active Directory 备份

Active Directory 灾难恢复规划的一个重要部分，是理解 Active Directory 备份的含义和注意事项。

系统状态

Active Directory 会被作为系统状态的一部分进行备份，而系统状态是相互依赖的系统组件的集合。这些组件必须一起备份（和还原）。

组成域控制器上系统状态的组件包括：

系统启动文件（引导文件）。这些文件是引导 Windows 2000 所必需的文件。它们会作为系统状态的一部分自动进行备份。

系统注册表。当您备份系统状态数据时，会自动备份注册表的内容。另外，注册表文件的副本保存在 %SystemRoot%/Repair/Regback 文件夹中，您可还原注册表，而不用还原整个系统状态。

COM+ 的类注册数据库。组件对象模型 (COM) 是一个二进制标准，用于在分布式系统环境中编写组件软件。组件服务类注册数据库与系统状态数据一起进行备份和还原。

SYSVOL。系统卷为那些必须在域中共享以供访问的文件，提供默认的 Active Directory 位置。域控制器上的 SYSVOL 文件夹包括以下内容：

Net Logon 共享。（其中通常驻留着用于基于非 Windows 2000 网络客户端的登录脚本和策略对象。）
文件系统联接。
基于 Windows 2000 Professional 的客户端以及运行 Windows 95、Windows 98 或 Windows NT 4.0 的客户端的用户登录脚本。
Windows 2000 组策略。
需要在域控制器上可用并需要在域控制器间同步的文件复制服务 (FRS) 分段目录和文件。

Active Directory。包括：

Ntds.dit。Active Directory 数据库。
Edb.chk。检查点文件。
Edb*.log。事务日志；每一个大小为 10 MB。
Res1.log 和 Res2.log。预留的事务日志。

注意如果您具有集成 Active Directory 的 DNS，则区域数据会作为 Active Directory 数据库的一部分进行备份。如果您没有集成 Active Directory 的 DNS，则区域文件必须单独进行备份。但是，如果您与系统状态一起备份系统磁盘，则该数据会作为系统磁盘的一部分进行备份。

如果域控制器上安装了群集服务或证书服务，则它们会作为系统状态的一部分进行备份。这些组件的详细信息不属于本文的讨论范围。

备份类型

Windows 2000 中的备份工具支持多种类型的备份，包括：

普通备份
副本备份
增量备份
差异备份
每日备份

但是，由于 Active Directory 作为系统状态的一部分进行备份，所以 Active Directory 可用的备份类型只有普通备份。在域控制器联机时，普通备份会创建整个系统状态的备份。另外，它还会将每一个文件都标记为已备份，这样就会清除文件的存档属性。

什么才算是好的备份？

为确保能从备份中成功进行还原，了解什么备份才算是“好的备份”十分重要。对于 Active Directory，必须考虑两件事情：

内容
时限

内容

备份的首要方面是它的内容。好的备份至少包括系统状态、系统磁盘的内容以及 SYSVOL 文件夹（如果不在系统磁盘上）。如前所述，系统状态包括许多用于还原域控制器的关键文件和设置。备份系统磁盘和 SYSVOL 文件夹结构，可确保成功还原所需的所有系统文件和文件夹都位于备份中。

注意为获得最佳性能，Active Directory 的日志和数据库文件应位于单独的磁盘中。如果您是按这种方式配置 DC 的，则 Active Directory 的各个组件会分散在多个驱动器中，例如 D:/Winnt/NTDS 用于存储日志，而 E:/Winnt/NTDS 用于存储数据库。

由于 Active Directory 日志文件和数据库作为系统状态的一部分进行备份，所以只须备份系统磁盘和系统状态，即可获得一个好的备份，即使是在这种分布式安装的情况下。

时限

如果备份的时限超出在 Active Directory 中设置的逻辑删除时限，则该备份就不能算是一个好的备份。

在 Windows 2000 中删除一个对象后，在其上删除了该对象的 DC 会通过称为“逻辑删除”的复制来通知环境中的其它 DC，告知它们已执行了此次删除操作。

逻辑删除表示已删除的、但并没有完全从目录中删除的对象。根据逻辑删除存留时间设置（默认设置为 60 天），最终会删除该逻辑删除。如果将 DC 还原到对象删除之前的状态，而在该对象的逻辑删除到期之前，没有将该逻辑删除复制到已还原的 DC 上，则该对象只在该还原 DC 上存在，这样就会导致不一致的情况。因此，必须在逻辑删除到期之前还原该 DC，而且要保证在该逻辑删除到期之前，完成从包含该逻辑删除的 DC 中到已还原的 DC 的入站复制。

Active Directory 可以通过禁止执行还原操作，来防止其自身还原比逻辑删除存留时间长的数据。因此，备份的可用时限与企业的“逻辑删除存留时间”设置相等。

出于这种考虑，备份的间隔应该是在逻辑删除存留时间内至少有一次。但是，Microsoft 强烈建议管理员要更加频繁地备份系统状态和系统磁盘，以确保在任何给定的时间都有包含最新版本数据的备份。

重要信息 某一 DC 的备份数据只能用于还原该 DC。不能使用一个 DC 的备份来还原另一个 DC。为确保对环境进行彻底的备份，必须对每一个域控制器都进行备份。在制定备份策略时应切记这一点。最低的要求是要备份所有的 OM 角色和 GC。而且，始终要备份根域中的第一个域控制器。

所需权限

在 Windows 2000 中，备份和还原权限是相互独立的。要想备份 Active Directory，您必须是 Backup Operators 或 Administrators 组的成员。

备份性能

了解备份某一活动 DC 所需的时间，是确定企业最佳备份策略的重要方面。为便于理解这一点，下面的图 2 说明了备份不同大小的 Active Directory 数据库所需的表征时间。

由于在 DC 联机时对域控制器进行备份，在这种情况下，时间不应是主要考虑因素。但是，建议不要将备份安排在高峰期进行，因为这样会影响域控制器进行其它活动的性能。

在下面提及的测试中备份的数据只针对系统状态。由于好备份的定义还包括系统磁盘和 SYSVOL 的备份，所以根据附加文件的大小，好备份所需的时间会稍稍长一些。此外，所需要的时间可能会根据磁带驱动器速度和系统配置的不同而不同。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV02.GIF" frameborder="0" width="95%" height="451">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 2 备份不同大小的 Active Directory 数据库所需的时间。

Active Directory 灾难恢复流程图

本文的以下篇幅将带您完成实施涉及 Active Directory 灾难恢复规划的概念所需的步骤和注意事项。图 3、4、5 和 6 是这些步骤的示意图。在下面几页将详细说明这些步骤。

注意下面的流程图并没有说明每一种灾难情况。而是说明可用的做法及其正确的用法。

灾难类型

在面临灾难时，必须首先确定灾难的类型。本文主要介绍两种灾难的故障排除方法：

数据库损坏 — 在这种情况下发生以下几种情况之一：

磁盘损坏，例如由于电源故障和坏电池而导致没有保存写回缓存。
域控制器出现严重的硬件故障，需要进行更换。
软件故障使得计算机无法以正常模式进行引导。

数据损坏 — 在这种情况下，管理员或具有适当权限的某个人意外地删除了某一对象，而且该删除操作已经复制到环境中的其它 DC。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV03.GIF" frameborder="0" width="95%" height="109">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 3 灾难恢复方案

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV04.GIF" frameborder="0" width="95%" height="1099">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 4 磁盘损坏灾难恢复步骤。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/aDRECV05.GIF" frameborder="0" width="95%" height="855">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 5 域控制器硬件故障灾难恢复步骤。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV06.GIF" frameborder="0" width="95%" height="816">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 6 数据损坏灾难恢复步骤。

恢复 Active Directory

还原 Windows 2000 DC 的方法主要有两种：

通过重新安装进行还原。
从备份中进行还原。

本节将详细介绍执行这些操作的步骤以及与之相关联的注意事项。

通过重新安装进行还原

此方法依赖 Active Directory 复制将 DC 还原到工作状态，而且只有在同一域中存在另一台运行正常的 DC 时此方法才有效。一旦安装了 Windows 2000 操作系统，则该计算机在故障发生之前又一次被提升为所在域的 DC。在此过程中，在常规（提升过程）DCPROMO 操作时执行复制操作，以确保该 DC 具有 Active Directory 数据库的最新而且正确的副本。建议只有在没有域控制器的好备份可用的情况下才采用此方法。

通过重新安装还原 DC 的注意事项

带宽问题

通过复制操作恢复 DC 的主要问题是带宽。通过复制操作还原 DC 所需的带宽与 Active Directory 数据库的大小以及需要该 DC 处于正常工作状态的时间直接相关。

下面的图 7 说明了在不同网络速度下将一个新 DC 复制到现有域中所需的时间。本次测试中使用的 Active Directory 数据库 ntds.dit 的大小为 2 GB。

注意用来收集数据的系统是 Compaq Proliant 1600s，其配置为双 Pentium II 266Mhz 处理器、256 MB RAM 和一个硬盘驱动器。使用不同的系统可能会影响测试结果，但是其总体趋势应该是一致的。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV07.GIF" frameborder="0" width="95%" height="368">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 7 在不同网络带宽的情况下复制 2 GB 数据库所需的时间。

通过重新安装还原 DC 所需的步骤

通过重新安装进行恢复的步骤和创建新 DC 的步骤相同。要通过重新安装进行还原，在目标域中必须至少有一台工作正常的 DC。理想情况下，此 DC 应该和要复制的 DC（新的 DC）位于同一 Active Directory 站点中，以减少网络的影响和与此方法相关的还原次数。有关带宽对此还原方法的影响的详细信息，请参见上面的图 7。

此过程中的步骤有：

清除操作，例如从 Active Directory 中删除出现故障的 DC 对象。
安装全新的 Windows 2000 Server 副本。
运行 DCpromo.exe（AD 安装工具），以将此计算机提升为域控制器角色。

清理操作如下所述。步骤 2 和步骤 3 是在阅读本文时假设您已具备的知识。有关提升过程的更多信息，可以在 Windows 2000 Server Resource Kit 的 Distributed Systems Guide 中获得。清除操作与新 DC 的名称是否与故障计算机的名称相同有关。

如果新 DC 的名称与故障 DC 的名称相同，则必须删除故障 DC 中的 ntdsDSA 对象：

在命令行中，键入 ntdsutil。
在 ntdsutil: 提示符下键入 metadata cleanup，然后按 Enter 键。
现在，需要连接到现有的域控制器，以便在上面删除故障 DC 中的 ntdsDSA 对象。
在 metadata cleanup 提示符下键入 connections，然后按 Enter 键。
键入 connect to server <服务器名>，然后按 Enter 键。其中 <服务器名> 是从其上清除元数据的 DC（同一域中的任何工作正常的 DC）。
键入 quit，然后按 Enter 键。将返回元数据清除菜单。
键入 select operation target，然后按 Enter 键。
键入 list domains，然后按 Enter 键。将列出目录林中所有的域，其中每一个域都和一个编号相关联。
键入 select domain <编号>，然后按 Enter 键，其中 <编号> 是与故障服务器所在的域对应的编号。
键入 list sites，然后按 Enter 键。
键入 select site <编号>，然后按 Enter 键，其中 <编号> 是指该 DC 所在站点的编号。
键入 list servers in site，然后按 Enter 键。将列出该站点中所有的服务器，其中每一个服务器都有一个对应的编号。
键入 select server <编号>，然后按 Enter 键，其中 <编号> 是指要删除的 DC。
键入 quit，然后按 Enter 键。将显示元数据清除菜单。
键入 remove selected server，然后按 Enter 键。
此时，应出现一条说明该 DC 已成功删除的确认信息。如果接收到一个错误，指出没有找到该对象，则可能该对象已经从 Active Directory 中删除了。
键入 quit，然后重复按 Enter 键，以返回到命令提示符。

注意由于此过程需要修改配置命名上下文，所以此操作需要企业管理员权限。

如果新的 DC 名称与故障 DC 的名称不同，则应该执行以下附加步骤：

从站点和服务管理单元中删除故障服务器对象：

打开站点和服务管理单元。
选择适当的站点。
删除与故障 DC 相关联的服务器对象。

从用户和计算机管理单元中删除故障计算机的帐户：

打开用户和计算机管理单元。
选择域控制器容器。
删除与故障 DC 相关联的计算机对象。

警告如果新计算机的名称与故障计算机的名称相同，请不要执行上述附加步骤。确保问题不是由硬件故障引起的。如果不更换故障硬件，则通过重新安装进行还原的方法会无济于事。

从备份中进行还原

此方法主要依赖在故障前对 DC 制作的最后的好备份。使用 Windows 2000 备份实用程序或所选的受支持的第三方应用程序，都可以启动还原过程。还原过程会使 DC 返回到备份时的状态；随后，DC 会向其复制伙伴查询自从该时间起进行的所有更新。如果进行过更改，则会复制这些更改，以确保该 DC 具有 Active Directory 数据库的最新且正确的副本。

另外，从备份中还原 Active Directory 还可以使用另外两种方法：

非权威性还原
权威性还原

这两种方法使您可以在还原过程中操纵系统状态的两个重要组件：Active Directory 和 SYSVOL。尽管这两个组件一起进行还原，但是在这里我们将对它们分别进行讨论。

非权威性还原

Active Directory

非权威性还原是还原 Active Directory 的默认方法，可以用于大多数还原操作。使用此方法，域、架构、配置中存在的设置和条目，以及全局编录命名上下文（可选）都会保持它们在备份时的版本号。

在进行非权威性还原之后，DC 将使用常规复制技术进行更新。即，如果某一属性的版本号低于其复制伙伴数据库中同一属性的版本号（表明该对象在上次备份之后进行过更改），则还原的服务器上的该对象将使用自从上次备份之后对该对象进行过的更改来更新自身。这样就确保数据库是最新的版本。

SYSVOL

使用非权威性还原方法来还原 SYSVOL 时，系统会将还原的 DC 上的本地副本和其复制伙伴的副本进行比较（使用 MD5 校验和）。一旦重新引导该 DC，它将和其复制伙伴进行联系，比较 SYSVOL 信息，并复制所需的更改，然后使用域中的其它 DC 对其进行更新。

使用此方法的条件是在域中至少有另一台工作正常的 DC。这是 SYSVOL 的默认还原方法，如果执行非权威性的 Active Directory 还原，该方法将自动执行。

如果域中没有其它工作正常的 DC，则应该对 SYSVOL 执行 PRIMARY 还原。PRIMARY 还原通过加载本地 DC 的 SYSVOL 下的数据来创建一个新的 ntfrs（Windows NT 文件复制服务）数据库。除了将 SYSVOL 标记为 PRIMARY 外，此方法与非权威性还原相同。

权威性还原

Active Directory

权威性还原就本质而言是非权威性还原过程的扩展。在启动它之前，需要执行非权威性还原的所有步骤。这两种方法的主要区别在于：权威性还原可以提高整个目录中所有对象、子树中所有对象或单个对象（如果它是叶对象）的属性的版本号，以便使其在目录中是权威性的。

与非权威性还原一样，一旦 DC 重新回到联机状态，它就会与其复制伙伴联系，以查看自从上次备份之后有哪些内容进行过更改。但是，由于您希望是权威性的对象属性的版本号将高于复制伙伴上的属性的现有实例，所以还原的 DC 上的对象版本会显得比较新，因此随后会将它复制到环境中的其余 DC 上。

与非权威性还原不同的是，权威性还原需要使用单独的工具 (ntdsutil.exe) 才能运行。备份实用程序（包括本机 Windows 2000 实用程序）不能执行权威性还原。

在出现人为错误时应该使用权威性还原，例如：管理员意外地删除了一些对象；所作的更改已经被复制到所有的 DC 中，这些对象都已经从域中删除；管理员重新创建这些对象十分困难。

权威性还原不会覆盖在进行备份之后创建的新对象。它只能在配置和域上下文中的对象上执行。不支持架构命名上下文的权威性还原。

SYSVOL

在对 SYSVOL 进行权威性还原时，您便已指定从备份中还原的 SYSVOL 副本对域来说是权威的。在进行了必要的配置之后，本地 SYSVOL 将被标记为权威的，而且将被复制到域中的其它 DC 上。

与 Active Directory 权威性还原相同，此方法通常在出现人为错误而且错误已经传播到其它域控制器的情况下使用。例如，在管理员意外地删除了 SYSVOL 中的某一对象（如“组策略”对象）的情况下。

SYSVOL 的权威性还原不能在 Active Directory 的权威性还原之后自动执行，它需要执行一些附加步骤。

所有这些还原方法的确切过程将在本文的下文中进行讨论。

还原 Active Directory 所需的权限

要还原系统状态数据，执行此过程的人员必须为本地管理员。

从备份中还原 DC 的注意事项

从备份中还原 DC 的最大优点在于它比从复制进行还原所需的时间短。为说明这一点，下面的图 8 提供了从备份（数据库大小的范围从 500 MB 到 2 GB）中还原 DC 所用的时间。测试所用的计算机为 Compaq Proliant 800，其配置为：一个 400MHz 处理器、256 MB RAM 和一个 4/8 GB DAT 驱动器。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV08.GIF" frameborder="0" width="95%" height="216">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 8 从备份中还原不同大小的 DIT 文件所需时间。

注意此图所示的时间只是还原系统状态的时间；在还原好的备份（如前定义）时，随系统磁盘的大小不同，所需的时间会更长。

Active Directory 备份的使用寿命

确保要还原的备份没有超出它的逻辑删除存留时间，该存留时间默认为 60 天。有关 Active Directory 备份的使用寿命的更多信息，请参见本文中的“什么才算是好备份？”一节。

在不同的硬件上还原备份

可以将 DC 还原到不同的硬件上。但是，在执行该操作之前，需要考虑一些问题。

不同的 HAL— 默认情况下，Hal.dll 并不作为系统状态的一部分进行备份，但 Kernel32.dll 却相反。因此，如果要尝试将备份还原到需要不同 HAL 的计算机上（例如，为了支持多处理器环境），则会遇到新 HAL 和初始 Kernel32.dll 的兼容问题。解决此问题的唯一方法，是从原始计算机中复制 Hal.dll，然后将其安装在新计算机上。其缺点是新计算机将只能使用一个处理器。
Boot.ini 文件不兼容— 如果备份然后还原 boot.ini 文件，则新的硬件配置中可能会出现不兼容问题，从而导致引导故障。在还原之前，确保 boot.ini 文件适用于新的硬件环境。
不同的网卡或显卡— 如果新硬件有不同的视频适配器或多个网络适配器，请在还原数据之前将它们卸掉。重新启动计算机时，常规的即插即用功能将进行必要的更改。

磁盘空间和分区配置

除了在不同硬件上还原 DC 的问题之外，使新计算机上的分区和原始计算机分区相同也是十分重要的。特别是所有的驱动器映射必须相同，而且分区大小必须与原始计算机的分区相同。

权威性还原的其它注意事项

从备份中还原 DC 时，除了上述注意事项外，在执行权威性还原时要特别注意以下几点。

对组成员身份的影响

使用权威性还原方法进行灾难恢复时，由此产生的最严重的后果就是对组成员身份的影响。组成员身份信息可能会丢失。

由于组成员身份是多值属性，由于在 Active Directory 中处理链接、后部链接和删除的方法不同，所以权威性还原对组成员身份重新表达的影响可能会不同。这些不同取决于在权威性还原之后第一个进行复制的对象：用户对象或组对象。

如果首先复制用户的未删除部分，那么组（所包含的成员）和用户（他/她所属的组）的组成员身份信息就会正确地重新表达。

如果首先复制组的未删除部分，那么复制伙伴就会从组成员身份中删除（本地）已删除用户的其它部分。唯一的例外情况是用户的主要组，无论从用户还是从组引用，该组都会正确地重新表达。

不幸地是，没有办法定义在执行权威性还原之后首先复制哪一个对象。如果您的环境受到此情况的影响，唯一的选择就是对执行了权威性还原的 DC 的组成员身份属性进行修改。

此问题不回由还原的数据的完整性引起，而会由复制数据的方法引起。通过查看此 DC，管理员可以查看目录的显示方式，并可以采取步骤将正确的目录信息复制到域中的其它 DC 中。

执行此过程的最佳方法是添加一位伪用户，然后再从参与权威性还原的每一个组中删除该伪用户。

这里的“参与”的定义，表示任何权威性地恢复其自身的组，以及还原了其成员的组，这些成员并没有将该组定义为他们的“主要组”。

通过执行此操作，可以强制从源 DC 复制正确的组成员身份信息（在上面执行最初的权威性还原的 DC），并更新其复制伙伴上的组成员身份信息。这些更新的对象将反映出正确的成员身份，并对还原的用户对象的隶属于选项卡中的信息进行更正。

确保没有对环境中的任何其它 DC 上的（受影响的组和用户的）组成员身份进行添加。

如果做不到这一点，进行还原的 DC 中的目录的正确版本可能会被不正确的成员身份信息损坏。一旦发生这种情况，您必须手动更新组成员身份，或者使用 verinc 选项再对这些对象进行一次权威性还原，并再次执行上述的过程。

对信任和计算机帐户的影响

在 Windows 2000 中，信任关系和计算机帐户密码在指定的时间间隔内（对于信任关系和计算机密码，默认值为 30 天）会进行协商。

在使用权威性还原方法时，可能会还原 Active Directory 中维护信任关系和计算机帐户的对象以前使用的密码。

对于信任关系而言，这可能会影响与其它域中的其它域控制器之间的通讯，该情况表现为在尝试跨域边界访问资源时会出现权限错误。要修正此错误，必须删除 Windows 2000 或下级域的 NTLM 信任关系，然后再重新创建。

对于计算机帐户密码而言，这会影响成员工作站或服务器与该域的 DC 之间的通讯。这种情况通常表现为 Windows NT 或 Windows 2000 计算机上的用户由于计算机帐户无效而遇到验证问题。

为帮助重新创建信任以及重新设置计算机帐户密码，请使用在 Windows 2000 CD 的支持工具中包括的 NETDOM 实用程序。

注意 Windows NT 4.0 计算机会每七天更改一次它的密码。

SYSVOL 复制的带宽问题

在执行 Active Directory 的权威性还原时，还应该执行 SYSVOL 的权威性还原。通过此操作，您将通知域中其它的 DC：还原的 DC 上的 SYSVOL 信息是权威性的。因此，会将还原的 DC 上的整个 SYSVOL 复制到域中所有其它的 DC 上（通过复制伙伴）。

只有在广泛使用大型组策略和脚本的域中，才需要考虑与这种复制相关联的带宽。另外，与 Active Directory 复制不同，FRS 复制并不在站点之间进行压缩。

非权威性还原所需的步骤

要使用 Windows 2000 本机备份实用程序执行非权威性还原，请执行本节中的步骤。

警告如果重新安装操作系统，您可（也可不）将该计算机加入到域中，并可在安装操作系统时为该计算机指定任意的名称。不要将该计算机提升为域控制器。在重新安装操作系统之后，请直接执行下面的步骤 4。

重新引导目标系统，在系统启动时按 F8 键，进入目录服务恢复模式。
选择目录服务恢复模式（仅对于 Windows 2000 域控制器）。
选择想要以恢复模式启动的操作系统。
以管理员（本地系统帐户，没有域可供选择）身份登录。
运行 Windows 2000 备份实用程序，并选择还原向导按钮。
选择适当的备份位置，并确保至少选中了系统磁盘和系统状态容器。
单击高级按钮，并确保要还原交接点（步骤 9）。如果不进入高级菜单，还原过程将不会成功。
在“将文件还原到”下拉框中选择原位置。
在高级还原选项窗口中，选中还原安全机制；还原交接点，并将交接点下的文件和文件夹数据还原到原始位置；保留现有卷的装入点旁的复选框。请参见下面图 9 中的图例。

图 9
单击完成按钮。
在完成之后，单击是以重新启动计算机。

系统将重新引导，并通过其复制伙伴复制自从上次备份以后的任何新信息。

在 Active Directory 上执行非权威性还原时，将自动执行 SYSVOL 的非权威性还原 — 而不需要其它步骤。对于 SYSVOL 的 PRIMARY 还原，确保选中“高级还原选项”对话框中以下内容旁的复选框：

当还原复制的数据集时，将还原的数据作为所有副本的主要数据。

只有在要还原的 DC 是域中的唯一 DC 时才需要进行 PRIMARY 还原。

权威性还原所需的步骤

权威性还原可以用来还原整个目录、目录中的子树或单个对象（如果该它是叶对象）。下述的示例将详细介绍如何还原整个目录以及目录的子树。

权威性还原 — 整个目录

整个目录的权威性还原是一个重要操作，应该在执行之前咨询 Microsoft 支持的专业人员。如果 DC 是域中的唯一 DC，则不应该执行整个目录的权威性还原。

请按照非权威性还原的前 10 个步骤执行。在提示您重新启动计算机时，拒绝重新启动。这是因为如果这样就必须将系统状态再次还原到备用位置。为继续进行，请执行以下步骤：

单击还原选项卡
确保在“将文件还原到”下拉列表中选中了备用位置。
选择备用位置会将系统状态还原到备用的位置。不需要将系统磁盘还原到备用位置，因此，您就应该只对系统状态选中该框。将系统状态还原到备用位置时，只是将 SYSVOL、引导文件和注册表还原到备用位置（而不是 Active Directory）。执行此操作之后，就可以进行 SYSVOL 的权威性还原了。一旦还原了整个目录，则可以删除备用位置中的文件。
还原过程结束之后，关闭备份应用程序。
打开命令提示符，键入 ntdsutil，然后按 Enter 键。
在下一个提示符下，键入 authoritative restore，然后按 Enter 键。
在下一个提示符下，键入 restore database。
在“权威性还原确认对话”框中，单击确定。
重复键入 Quit，直至退出该应用程序。
重新启动服务器。
该服务器现在为域的权威性 DC。所作的更改将复制到环境中的其它 DC 上。
一旦重新引导了系统，而且在公布了 SYSVOL 共享之后（SYSVOL 共享及其子文件夹需要几分钟时间才能出现在域控制器中），把复制到备用位置的 SYSVOL 目录中的所需文件/文件夹复制到原位置。这样，被覆盖的文件将被复制到其它域控制器中，以便 SYSVOL 和进行备份时的 SYSVOL 相同。

下面是一个把备用位置的 SYSVOL 复制到原位置的示例。您的系统不同，驱动器和文件夹信息也可能会不同。

从下列位置中复制脚本目录的内容：

c:/<备用 Sysvol 位置>/sysvol/c_/winnt/Sysvol/Domain/scripts/

将其添加到如下位置：

c:/Winnt/SYSVOL/Sysvol/domain/scripts/

从下列位置中复制策略目录的内容：

c:/<备用 Sysvol 位置>/sysvol/c_/winnt/Sysvol/Domain/policies/

将其添加到如下位置：

c:/Winnt/SYSVOL/Sysvol/domain/policies/

通过以权威性地还原 SYSVOL，还原的 DC 上的文件对于域而言是权威性的，因而将被复制到其它 DC 上。在备份之后对任何策略所作的更改都将丢失。

例如，在上次备份时有一个名为“财务策略”的组策略，它按 SYSVOL 目录中的一个文件夹引用：

C:/WINNT/SYSVOL/Sysvol/Domain.com/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}

但是，在上次备份后不久，管理员对“财务策略”进行了编辑，尽管该策略的属性更改了，但是 GPO 的 GUID 却保持不变。因此，该策略仍然按同一个目录名 {31B2F340-016D-11D2-945F-00C04FB984F9} 引用。

在对该目录进行权威性还原时，备用 SYSVOL 位置中的 {31B2F340-016D-11D2-945F-00C04FB984F9} 文件夹将被复制到原 SYSVOL 位置。此操作替换了旧的文件夹，于是管理员在备份之后所作的更改都已丢失。但是，此步骤是使 Active Directory 与 SYSVOL 保持同步所必需的步骤。

权威性还原 — 子树

这种权威性还原的方法可以还原 Active Directory 的特定组件，并将这些组件标记为对于目录而言是权威性的。预计这是权威性还原的最常见方式，因为需要还原整个目录的情况很少见。

要执行某一子树的权威性还原，请按照本文中“整个目录的权威性还原”一节中的步骤执行，但是要用下面的步骤来替换步骤 6：

6. 键入 RESTORE SUBTREE <路径> 例如：RESTORE SUBTREE OU=Sales,OU=Sydney,DC=Whitepaper,DC=com

此服务器现在为指定路径的权威性 Active Directory 域控制器。所作的更改将复制到域中的其它 DC 上。

由于只还原 Active Directory 的一部分，所以不需要执行 SYSVOL 的权威性还原。但是，如果由权威性还原操作还原的子树或对象包含 SYSVOL 中的元素，例如组策略，则还应该通过权威性还原操作来还原 SYSVOL 的那一部分。

如果需要执行该操作，则必须执行本文“整个目录的权威性还原”一节中的步骤 10。

注意只有当目录中的单个对象是叶对象时，才对其执行权威性还原。对象及其子对象将一起进行权威性还原。

即使已经对目录的某一子树进行了权威性还原，还必须使用非权威性还原方法对整个目录进行完全还原，然后，才能使用 ntdsutil 工具将该子树标记为权威性的。

成功还原的验证

尽管查看域控制器在还原后是否工作正常的测试手段有许多种，但是下面所列出的是两种基本的测试，应该执行其中之一来验证还原操作的成功与否。

以正常模式重新引导

如果域控制器可以成功地以正常模式进行引导，那么目录就能够成功地初始化。特别是在还原之前该 DC 不能正常引导的情况下，这就更加正确。

检查目录服务事件日志是否存在错误消息

应该检查目录和系统事件日志，以查看是否存在关于还原过程的错误消息。

检查域控制器是否能通过其邻居的验证

使用 repadmin 工具可以验证。这种方法主要用于检查还原的域控制器是否能通过另一台域控制器的验证，并复制更改以更新它的目录副本。能够执行该任务是它作为域控制器的关键因素。

第一项检查是获得还原的域控制器的入站伙伴。所使用的选项是：

D:/>repadmin /showreps testlab/test-machine3 DSA Options : (none) objectGuid : a07b44e6-76ba-4f03-80c9-5a4a256347bb invocationID: 6037d0c3-2194-4f27-95ed-578b38861414 ==== INBOUND NEIGHBORS ====================================== CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microsoft,DC=com testlab/test-machine1 via RPC objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 Last attempt @ 2000-09-08 14:10.16 was successful. CN=Configuration,DC=testdom,DC=nttest,DC=microsoft,DC=com testlab/test-machine1 via RPC objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 Last attempt @ 2000-09-08 14:10.16 was successful. DC=testdom,DC=nttest,DC=microsoft,DC=com testlab/test-machine1 via RPC objectGuid: 465848f9-5446-4176-a504-59629c7a8fd8 Last attempt @ 2000-09-08 14:10.16 was successful.

在上例中，还原的 DC 是 test-machine 3。测试在还原的计算机上进行，但是该工具可以在任何域控制器上使用。在上例中，test-machine 1 是它的入站伙伴。

下一条命令将尝试使用入站邻居中的更改来同步还原的域控制器上的架构命名上下文：

D:/>repadmin /sync D:/>repadmin /sync "CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microso ft,DC=com" test-machine3 465848f9-5446-4176-a504-59629c7a8fd8 Sync from 465848f9-5446-4176-a504-59629c7a8fd8 to test-machine3 completed successfully.

然后，可以尝试使用同一命令来同步入站邻居和还原的域控制器，以检查出站复制是否工作：

D:/>repadmin /sync "CN=Schema,CN=Configuration,DC=testdom,DC=nttest,DC=microso ft,DC=com" test-machine1 a07b44e6-76ba-4f03-80c9-5a4a256347bb Sync from a07b44e6-76ba-4f03-80c9-5a4a256347bb to test-machine1 completed successfully.

如果同步成功，则该域控制器就可以通过临近域控制器的验证，并接收其中的更改。如果不成功，则可能表示，该还原的域控制器上的计算机帐户密码是旧密码，这样入站伙伴就无法验证还原的域控制器。应该使用 netdom 工具，将入站副本域控制器上的密码和还原的域控制器上的密码设置为相同。有关 netdom 工具的更多信息，请参见 Windows 2000 CD 上的 Windows 2000 支持工具。

权威性还原的其它验证

除了上述的步骤外，还应该验证采用权威性还原操作还原的对象是否出现在目录中。

还可以使用 Repadmin 命令行工具，通过检查目录或子树的版本号是否增加，从而验证权威性还原是否成功完成。执行此任务的方式如下：执行 /showmeta 命令，后面跟随着执行权威性还原的目录和子树的准确可分辨的名称。

全局编录服务器的恢复

要恢复全局编录服务器，可以从备份中进行还原，也可以指派一个新的 GC 以便补偿原位置丢失的信息。

还原全局编录服务器所需的步骤

请参考本文中“从备份中进行还原”部分。如果想要自动将 DC（在备份时作为 GC）还原为 GC 角色，唯一的方法就是从备份中进行还原。使用重新安装的方法来还原 DC 将不能自动还原 GC 角色。在多域环境中，切记，从备份中还原 GC 所需的时间要多于还原正常域控制器所需的时间。

指派新 GC 所需的步骤

由于配置多个 GC 并没有实际的害处，所以，如果遇到 GC 故障而引起的长期停机，您可能会想在您的环境中创建一个新的 GC。在以下情况下，其关系就更加密切：原 GC 服务的用户组不能再访问 GC；或者在您的环境中使用 GC 服务的要求很强烈（例如运行 Exchange 2000）。

要启用新的 GC，请按照 Windows 2000 Server 帮助中启用或禁用全局编录部分中介绍的步骤。

注意一个目录林中有多个 GC 可以提高系统的可用性，其代价是会增加复制的信息流量和数据库的大小。如果要重新安装出故障的 DC 并使其角色仍为 GC，您可能想删除在该 DC 故障时配置的所有其它 GC。

操作主机的恢复

一旦操作主机 (OM) 不可用，还原该角色的唯一方法是执行以下过程之一：

从备份中还原故障的操作主机。
将该角色强制转移到环境中的其它 DC 上。只有在不能从备份中还原原始角色时，才能执行此操作。

注意通过重新安装来还原 OM 服务器并不能还原其原始的角色状态。但是，在重新安装之后，该角色可从其它担当该角色的 DC 正当地转移回来。

OM 也被称为 FSMO（弹性单一主机操作）角色承担者。

强制转移操作主机角色

强制转移（通常的叫法）是无需原始角色承担者的协作就可执行的过程。换句话说，当原始角色承担者出现灾难情况时，可以转移该角色，强制将该角色转移到域/目录林中的另一台 DC 上。

尽管强制转移 OM 角色的过程与所有 5 个角色的过程类似，但是在执行时需要注意的事项却不同。这些问题将在本文稍后进行讨论。

注意 OM 角色的正常转移过程在本文中不作介绍。如果可以执行此过程，则表示原始角色承担者能正常工作，并不参与灾难恢复。

强制转移操作主机所需的步骤

要强制承担角色的 DC 必须与在前一个角色承担者上执行的更新完全同步。这就是为什么强烈建议在环境中指定的备用角色承担者应该和现有的角色承担者处在同一站点中，而且使它们成为直接的复制伙伴的原因。

为了确保在环境中选择最合适的备用 OM，请使用 Repadmin 工具（包括在 Windows 2000 CD 的支持工具中）来检查它的状态。

为了说明这一点，假设服务器 SYD01 是域 Whitepaper.com.au 的操作主机，SYD02 是指定的备用 OM，而 MEL01 是域 Whitepaper.com.au 中唯一的另一台 DC。

键入如下两条命令：

C:/>repadmin /showvector dc=whitepaper,dc=com,dc=au SYD02.whitepaper.com.au
Sydney/SYD01 @ USN 4023
Melbourne/MEL01 @ USN 4087

C:/>repadmin /showvector dc=whitepaper,dc=com,dc=au MEL01.whitepaper.com.au
Sydney/ SYD01 @ USN 4018
Sydney/SYD02 @ USN 5017

由于 SYD01 是源操作主机，所以我们关心的只是更新顺序号 (USN)。SYD02 (4023) 上的 USN 高于 MEL01 (4018) 上的 USN，因此 SYD02 比 MEL01 更新，更适合承担该角色。

确定出承担 OM 角色的最佳备用计算机之后，请按照下面的步骤来强制转移 OM 角色：

打开命令提示符。
键入 NTDSUTIL。
在 ntdsutil 提示符下，键入：roles
在 FSMO 维护提示符下，键入：connections
在服务器连接提示符下，键入：connect to server <服务器的 FQDN>。例如：connect to server syd02.whitepaper.com.au
在服务器连接提示符下，键入：quit
在 FSMO 维护提示符下，键入：seize <操作主机>。例如：seize schema master
在弹出窗口中，单击是以验证强制转移。
在 FSMO 维护提示符下，键入：quit
在 ntdsutil 提示符下，键入：quit

架构主机的恢复

在确定是否强制转移架构主机角色之前，应首先考虑下面的因素：

对环境的影响

首先，必须了解当架构主机出现故障时会对您的环境产生什么样的影响。您会看到如下的主要问题：

不能对架构进行更改

当架构主机不可用时，不能对架构进行更改。如果试图更改架构，则会显示如下面的图 10 所示的消息。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV10.GIF" frameborder="0" width="95%" height="164">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 10

注意显示的确切消息取决于更改的方法。在架构主机不可用的情况下，如果试图安装 Exchange 2000，就会出现上图显示的消息。

在大多数生产环境中，对架构更改的频率应很低，并且应提前进行规划，以便使架构主机的故障不至于产生任何直接的问题。

在架构主机上执行强制转移的注意事项

决定强制转移架构主机角色的主要注意事项，是故障时间的长短。由于重复的架构变更可能会在整个环境中传播，只有在故障的角色承担者无法再返回到联机状态时，才能执行架构主机角色的强制转移。

在大多数环境中，由于对架构主机角色的需要不很频繁，及强制转移的影响，所以在还原承担该角色的 DC 之前的一段时间内，您很可能不能使用该角色。但是，如果由于某些原因，需要立即使用架构主机角色或原角色承担者无法再返回到 Windows 2000 环境，则可以执行强制转移操作。

域命名主机的恢复

在确定是否强制转移域命名主机角色之前，请考虑以下因素：

对环境的影响

首先，必须了解当域命名主机出现故障时会对您的环境产生什么样的影响。您会看到如下的主要问题：

不能向目录林中添加域

在此主机不可用时，不能向 Active Directory 中添加域。如果在域命名主机 (Syd01.Whitepaper.com) 不可用的情况下试图通过运行 DCPROMO 来添加域，则会出现如下面的图 11 中所示的错误消息：

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV11.GIF" frameborder="0" width="95%" height="220">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 11

在稳定的生产环境中，这不是个严重问题。但是在开发、测试或扩展生产环境时，此主机的故障可以阻止扩展，直到该主机被还原或强制转移。

不能从目录林中删除域

如果在域命名主机 (Syd01.Whitepaper.com) 不可用时试图通过运行 DCPROMO 来删除域，那么就会收到一条类似的消息。例如，在该情况下，消息的内容为：用提供的凭据绑定到服务器 syd01.Whitepaper.com 失败。RPC 服务器不可用。 再次提醒，在大多数环境中，应该给予适当的注意。

在域命名主机上执行强制转移的注意事项

决定强制转移域命名主机角色的主要注意事项是故障时间的长短。由于重复的域变更可能会在整个环境中传播，只有在故障的角色承担者无法再返回到联机状态时，才能执行域命名主机角色的强制转移。

在大多数环境中，由于对域命名主机角色的需要不很频繁，及强制转移的影响，所以在还原承担该角色的 DC 之前的一段时间内，您很可能不能使用该角色。但是，如果由于某些原因，需要立即使用域命名主机角色或原角色承担者无法再返回到 Windows 2000 环境，则可以执行强制转移操作。

RID 主机的恢复

在确定是否强制转移 RID 主机角色之前，请考虑以下因素：

对环境的影响

首先，必须了解当 RID 主机出现故障时会对您的环境产生什么样的影响。您会看到如下的主要问题：

不能创建安全对象

在此情况下，所遇到的主要问题是不能向域中添加任何新的安全对象，例如用户、组和计算机；如果试图添加，则会出现如下的错误消息：Windows 不能创建对象，因为：目录服务已经用完了相对标识号池。

另外，在试图创建对象的 DC 的事件日志中会收到一个错误，事件 ID 为 16645。此错误将说明，已经指派的帐户标识号数达到了分配给此域控制器的帐户标识号的最大数。

只有在域中的每一台域控制器上的 RID 池（一个池中有 512 个 RID）都用完时（因为在域中任一 DC 上都可以创建对象），才会出现此错误。

因此，如果域中还剩余有 5 台 DC，那么在 RID 主机故障时，理论上仍然有 2560 (5 x 512) 个 RID 可用。在通常环境中，这可以提供足够的 RID 用来创建安全主体，直到使用上面介绍的方法修复/还原了 RID 主机。但是，如果正在创建大量的安全对象或在域间移动对象，而这些操作所需的 RID 多于现有池的 RID 数，那么就可以执行角色强制转移。

Security Principle无法在域间移动安全主体

如果目标域中的 RID 主机不能运行，则不能将安全主体移到该新域中。与上述问题不同，所有的跨域移动都会因为 RID 主机不可用而立即失败。

在 RID 主机上执行强制转移的注意事项

在 RID 主机上执行强制转移时需要注意一些事项。由于网络上存在重复的 RID 的风险，所以，如果要执行强制转移操作，原来承担 RID 主机角色的服务器应不能返回到联机状态。相反，应该在原角色承担者完全重建之后，再将它投入到生产 Windows 2000 环境中。

如果在了解了 RID 主机强制转移的所有影响之后，实际情况仍然要求立即要有一台正常工作的 RID，请按照强制转移操作主机角色中给定的步骤执行。

PDC 模拟器的恢复

在确定是否强制转移 PDC 模拟器角色之前，请考虑以下因素：

对环境的影响

首先，必须了解当 PDCE 出现故障时会对您的环境产生什么样的影响。您将面对如下的主要问题：

混合模式的环境

如果在一个混合模式的环境（其中 Windows NT Server 4.0 备份域控制器仍在使用）中 PDCE 角色出现故障，您将看到一些问题，而这些问题在本机 PDC 不可用时 Windows NT Server 4.0 中也会出现。例如，如果要使用本地 NT 4.0 域用户管理器工具来管理 NT 4.0 域，则会收到如下的错误消息：找不到此域的域控制器。

如果试图使用本机服务器管理器工具来管理 Windows NT Server 4.0 域，则会收到如下的错误消息：找不到 MYDOMAIN 的主域控制器。您可以管理这个域，但是某些全域的操作会被禁用。

本机模式的环境

在本机模式环境中出现的问题也可能会在混合模式环境中（Windows 2000 的一边）出现。在 Windows 2000 环境中 PDCE 出现故障时，您将遇到下面一些主要问题：

登录失败的可能性增大。如果重新设置用户密码，例如在用户忘记密码，然后管理员在一台 DC（不是验证 DC）上重新设置密码，那么该用户就必须等到密码复制到验证 DC 之后才能登录。

尽管用户的本地验证 DC 会尝试和 PDCE 进行联系，以查看自从上次复制之后密码是否更改，但是由于 PDCE 脱机，所以此操作将失败。因此，验证 DC 只能使用其本地 Active Directory 副本，该副本所反映的密码仍然是原来那个已忘记的密码。

在此情况下，无论从客户端或验证 DC 都看不到明显的错误。

尽管这可以算作问题，但是通过在用户验证 DC 上更改该密码，可以轻松地解决此问题。

试图编辑组策略对象时出错。为了有助于在编辑 GPO 时确保不丢失数据，用于更改 GPO 的默认 DC 应该承担 PDCE 角色。因此，如果 PDCE 不可用，则在试图编辑域中的 GPO 时，就会收到如下面的图 12 中所示的消息。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV12.GIF" frameborder="0" width="95%" height="229">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 12

这是一个小问题，通过在下面提供的任何一种选项，就可以迅速解决该问题。这些选项的简要说明如下所示。

具有 PDC 模拟器操作主机令牌的域控制器。
很明显，在该角色不可用时，此选项也不可用。
由 Active Directory 管理单元使用的域控制器。
这将使用 Active Directory 管理单元正在使用的域控制器。这是在 PDCE 不可用时的推荐选项。
使用任何可用的域控制器。
第三个选项最好不要使用，该选项允许组策略管理单元选择任何可用的域控制器。当选中该选项时，很可能也会选中本地站点中的域控制器。

注意这里所作的更改只能用于单一编辑。换句话说，如果 PDCE 主机不可用，那么在每次编辑 GPO 时都会询问您这个问题。

在 PDC 模拟器主机上执行强制转移的注意事项

PDCE 主机的角色并不像前面所述的那几种角色那样重要。因此，强制转移该角色的操作不会影响其它角色。如果选择强制转移 PDCE 角色，则不必等到将原始角色承担者完全重建之后再将它加入到 Windows 2000 环境中。

因此，强制转移 PDCE 角色这一决定不会对环境产生什么影响，通常可以认为是在 PDCE 故障时，特别是在混合模式的环境中的标准做法。

强制转移 PDCE 角色时只需考虑一个问题：是不是在带有 Windows NT Server 4.0 BDC 的混合模式环境中进行操作。为了能让 BDC 知道它们即将执行的更改，需要将内置组和新的 PDCE 完全同步。

注意由于和强制转移 PDCE 角色相关联的问题对环境的影响很小，所以 Microsoft 允许您通过 Active Directory 用户和计算机管理单元来强制转移该角色。如果要这样做，请执行在角色转移时执行的步骤。如果要这样做，请参考 Windows 2000 Resource Kit 中的 Distributed Systems Guide。如果原 PDCE 不可用，则会看到下面图 13 中显示的对话框。

marginwidth="1" marginheight="0" src="/china/technet/asp/test/windows2000/images/ADRECV13.GIF" frameborder="0" width="95%" height="177">
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

图 13

单击确定，随即开始强制转移角色。

注意强制转移与强制占用意义相同。

另外，可以使用 ntdsutil 来强制转移该角色。如果要这样做，请按照本文“强制转移操作主机所需的步骤”一节中介绍的步骤执行。将步骤 7 替换为：

7. 在 FSMO 维护提示符下，键入：seize pdc

结构主机的恢复

在确定是否强制转移结构主机角色之前，请考虑以下因素：

对环境的影响

首先，必须了解当结构主机出现故障时会对您的环境产生什么样的影响。

结构主机故障对环境的影响是有限的。最终用户并不能感觉到它的影响，只对管理员执行大量组操作产生影响。这些组操作通常是添加用户和/或重新命名用户。在此情况下，结构主机故障只是会延迟通过 Active Directory 管理单元引用这些更改的时间。

在对故障的结构主机进行维修/恢复到原始状态这段时间内，没有结构主机，环境就会无法运行的情况很少发生。但是，如果预计中断时间很长，则建议您强制转移该角色。

在结构主机上执行强制转移的注意事项

强制转移结构主机角色的主要注意事项是确保新的 DC 不是 GC 服务器，但是该 DC 与 GC 的连接必须良好，最好是位于同一个站点内。

小结

本文旨在将关于备份和还原 Active Directory 的信息收集在一起，以帮助管理员更好地了解有关的问题。使用本文，管理员可以为 Windows 2000 环境制定灾难恢复规划。

其它信息

有关 Windows 2000 Server 的最新信息，请访问我们的 Web 站点 http://www.microsoft.com/windows2000以及“Windows 2000/NT 论坛” http://computingcentral.msn.com/topics/windowsnt 。

附录 I

数据库完整性测试

可以在数据库上执行的完整性测试的数量有限，无论在 ESE（可扩展存储引擎）层上，还是在 DB 层上。这些层如下面的图 14 所示。

图 14 Active Directory 功能层

这些测试很费时间。根据情况的紧急程度，您可以执行这些测试或在从备份中进行还原时进行。在执行这些测试之前需要注意一些事项，包括：

如果不能引导到目录服务恢复模式，就不能执行这些测试，因此可以略过本小节。
事件日志中的错误消息或者相应 KB 文章，都可以告诉您有关该问题的性质，并告诉您执行完整性检查是否能够解决该问题。
此过程很费时间。这取决于数据库的大小，而对于大型数据库（1 GB 及以上），则需要花费好几个小时。

这些测试的好处是，在执行这些测试时不会丢失任何数据（而不像修复操作，该操作将在附录 II 中介绍）。执行这些测试时，应该按照如下的顺序：

日志文件的软恢复。
文件完整性。
语法分析。

必须进入目录服务恢复模式中才能继续执行。

执行日志文件的软恢复

在电源意外出现故障的情况下，可以执行日志文件的“软”恢复。由于事务数据在写入数据文件之前先写入到日志文件中，所以您可以重新运行日志文件，以重新产生假如这些事务能够写入到数据文件中时所产生的效果。Ntdsutil 命令行工具中的 Recover 命令用来执行此“软”恢复。所有的日志文件都要经过扫描，以确保所有已提交的事务都应用于数据文件。如果域控制器的前一次关闭不是正常关闭，那么在启动该域控制器之后会自动执行软恢复。

下面是运行 Recover 命令的输出的示例：

C:/>ntdsutil ntdsutil: files File maintenance: Recover Executing Command: C:/WINNT/System32/esentutl.exe /r /8 /o /l"C:/WINNT/NTDS" /s" C:/WINNT/NTDS" /!10240 Initiating RECOVERY mode... Log files: C:/WINNT/NTDS System files: C:/WINNT/NTDS Performing soft recovery... operation completed successfully in 4.717 seconds. Spawned Process Exit code 0x0(0) If recovery was successful, it is recommended you run semantic database analysis to insure semantic database consistency as well.

确保文件完整性

通过使用 integrity 命令，可以检测低级（二进制级别）的数据库损坏情况。integrity 命令会读取数据文件的每一个字节。因此，根据数据库的大小，该过程可能会花费大量的时间。

integrity 命令可以确保数据库本身的信息头的正确性，而且还确保所有的表运行正常和一致。此工具在目录服务恢复模式下使用。如果遇到错误，则会记录到日志文件中。

integrity 命令完成操作的时间取决于所使用的硬件类型以及目录数据库的大小。（在测试环境中，每小时 2 千兆字节 (GB) 属正常情况。）在执行该命令时，会出现一个联机图形，显示完成操作的百分比。

下面是使用 ntdsutil 工具进行完整性检查的示例：

C:/>ntdsutil ntdsutil: files file maintenance:Integrity Opening database . Executing Command: C:/WINNT/System32/esentutl.exe /g "C:/WINNT/NTDS/ntds.dit" /! 10240 /8 /v /x /o Initiating INTEGRITY mode... Database: C:/WINNT/NTDS/ntds.dit Temp.Database: INTEG.EDB failed to get 515126 buffers checking database header checking database integrity Scanning Status ( % complete ) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| checking SystemRoot SystemRoot (OE) SystemRoot (AE) checking system table MSysObjectsShadow MSysObjects . Name RootObjects rebuilding and comparing indexes checking table "datatable" (6) checking data ....................... checking long value tree (24) ... checking index "PhantomIndex" (125) . checking index "INDEX_000901FD" (122) checking index "INDEX_000900DE" (121) checking index "INDEX_00090089" (120) checking index "INDEX_00090573" (119) checking index "INDEX_00090073" (118) checking index "INDEX_00090571" (117) checking index "INDEX_0009056C" (116) checking index "INDEX_00090553" (115) checking index "INDEX_0009013A" (114) checking index "INDEX_00090138" (113) checking index "INDEX_00090330" (112) checking index "INDEX_00090030" (111) checking index "INDEX_00090013" (110) checking index "INDEX_00000013" (109) checking index "INDEX_0000000B" (108) checking index "INDEX_00000007" (107) checking index "INDEX_00000003" (106) . checking index "INDEX_00150003" (105) checking index "LCL_ABVIEW_index00000409" (104) checking index "INDEX_00090363" (103) checking index "INDEX_00090303" (102) checking index "INDEX_00090290" (101) checking index "INDEX_000901FF" (100) checking index "INDEX_000900DD" (99) checking index "INDEX_00090085" (98) checking index "INDEX_00090057" (97) checking index "INDEX_0009001C" (96) . checking index "INDEX_000201CC" (95) checking index "INDEX_0002000D" (93) checking index "INDEX_0000002A" (92) checking index "INDEX_00000004" (91) checking index "NC_Acc_Type_Name" (90) checking index "PDNT_index" (89) .. checking index "INDEX_00090001" (88) . checking index "INDEX_000901F6" (85) checking index "INDEX_000902EE" (84) checking index "INDEX_000904E1" (83) checking index "INDEX_000201D5" (80) checking index "INDEX_000902BB" (77) checking index "INDEX_000903B4" (76) checking index "INDEX_000200A9" (75) checking index "INDEX_0009039D" (74) checking index "INDEX_0009039A" (73) checking index "INDEX_00090098" (72) checking index "INDEX_00090395" (71) checking index "INDEX_0009028F" (69) checking index "INDEX_00090582" (66) checking index "INDEX_00020078" (65) . checking index "INDEX_00020073" (62) checking index "INDEX_00090171" (60) checking index "INDEX_00090167" (58) checking index "INDEX_00090062" (56) checking index "INDEX_00090261" (55) checking index "INDEX_0009014E" (52) checking index "INDEX_0009014D" (51) checking index "INDEX_0009014C" (50) checking index "INDEX_00090147" (49) checking index "INDEX_00090141" (48) checking index "INDEX_00090140" (47) checking index "INDEX_0009012E" (42) checking index "INDEX_00020013" (39) . checking index "INDEX_0009030E" (36) checking index "INDEX_00090008" (32) checking index "INDEX_00090202" (25) checking index "Ancestors_index" (13) . checking index "DRA_USN_CREATED_index" (12) checking index "DRA_USN_index" (11) . checking index "del_index" (10) checking index "INDEX_00090002" (9) .. checking index "NC_Acc_Type_Sid" (8) checking index "INDEX_00090092" (7) rebuilding and comparing indexes checking table "hiddentable" (16) checking data rebuilding and comparing indexes checking table "link_table" (14) checking data checking index "backlink_index" (15) rebuilding and comparing indexes checking table "MSysDefrag1" (123) checking data checking index "TablesToDefrag" (124) rebuilding and comparing indexes checking table "sdproptable" (17) checking data checking index "clientid_index" (19) checking index "trim_index" (18) rebuilding and comparing indexes integrity check completed. operation completed successfully in 13.640 seconds. Spawned Process Exit code 0x0(0) If integrity was successful, it is recommended you run semantic database analysis to insure semantic database consistency as well.

确保数据库的完整性

Ntdsutil 工具包括一个语法检查器，它可以通过选择语法数据库分析选项来调用。语法检查器的作用是检查 Active Directory 数据库内容的完整性。

该工具在目录服务恢复模式下运行。错误将写入 dsdit.dmp .xx 日志文件中。进度指示器将显示检查的状态。

下面是可以执行的操作示例：

引用计数检查。计算出数据表和链接表中所有引用，以确保它们与列出的记录计数相匹配。（有关数据和链接表的更多信息，请参见 Windows 2000 Resource Kit 的 Distributed Systems Guide 中的 Active Directory Data Storage 一节。）这还可以确保每一个对象都有一个 GUID、可分辨的名称和非零引用计数。对于已删除的对象，该检查可确保该对象有删除的时间和日期，但是没有 GUID 或可分辨的名称。
已删除对象的检查。确保对象有删除时间和日期，以及一个特殊的相对可分辨的名称。
祖先检查。检查以确定当前可分辨的名称标记 (DNT) 是否与父级和当前 DNT 的祖先列表相同。
安全描述符检查。检查有效的描述符，确保它有控制字段，并确保自由访问控制列表不为空。如果一个已删除的对象没有自由控制访问列表，那么就会显示一条警告。
复制检查。检查目录分区头中的 UpToDate 矢量，以确保指针的数量正确。它还检查每一个对象是否具有属性元数据矢量。对于对象的实例类型，它会检查元数据、更新矢量、子引用以及部分属性。

执行语法数据库分析

备份 Active Directory。Windows 2000 备份实用程序支持在联机时备份 Active Directory。在“备份向导”中选择备份计算机上的所有内容的选项时，或者在该向导中选择单独备份系统状态时，都会自动执行该任务。
重新启动域控制器，从启动菜单中选择适当的安装，然后按 F8 键，以显示 Windows 2000 高级选项菜单。
选择目录服务恢复模式，然后按 Enter 键。若要再次启动引导过程，请按 Enter 键。
以管理员帐户，使用在脱机 SAM 中为本地管理员帐户定义的密码，登录。
从“开始”菜单中，指向“程序”、“附件”，然后单击“命令提示符”。
在命令提示符下，键入 ntdsutil，然后按 Enter 键。
键入 Semantic database analysis，然后按 Enter 键。
键入 Verbose on，然后按 Enter 键。这将显示语法检查器。
键入 go，然后按 Enter 键。语法检查器随即开始运行，但是不修复遇到的任何错误。若要修复遇到的错误，选择 Go Fixup 选项。
键入 quit，然后按 Enter 键。若要返回到命令提示符，请再次键入 quit。

下面是运行语法数据库分析选项（打开详细模式）的示例：

C:/>ntdsutil ntdsutil: Semantic database analysis semantic checker: Verbose on Verbose mode enabled. semantic checker: Go Opening database . ....Done. Getting record count...2371 records Writing summary into log file dsdit.dmp.0 Records scanned: 2300 Processing records..Done.

附录 II

数据库修复

修复 Active Directory 应该是最后的手段。如果有可用的有效备份，则通常应该还原该备份。不能保证修复 Active Directory 一定奏效。实际上，此过程也有风险，可能导致数据的进一步丢失。另外，这是一个非常费时的过程。

在执行修复之后，必须按照附录 I 中的方法来执行数据库的语法完整性检查。

若要修复 Active Directory，请使用 ntdsutil 工具中的修复选项：

C:/>ntdsutil ntdsutil: files ntdsutil: repair

附录 III

数据库：位置、移动和脱机碎片整理

确定数据库文件和日志文件的位置

要想找到数据文件、日志文件和工作目录的位置，可以使用 info 命令，该命令是 ntdsutil 命令行工具的一部分。该命令可以执行以下任务：

分析并报告计算机中所有磁盘的可用空间。
读取与 Active Directory 文件位置有关的注册表键，并报告它们的值。
报告数据文件、工作目录和日志文件的大小。

下面是运行 info 命令的输出的示例：

C:/>ntdsutil ntdsutil: files file maintenance: Info Drive Information: C:/ NTFS (Fixed Drive ) free(2.9 Gb) total(3.9 Gb) DS Path Information: Database : C:/WINNT/NTDS/ntds.dit - 12.1 Mb Backup dir : C:/WINNT/NTDS/dsadata.bak Working dir: C:/WINNT/NTDS Log dir : C:/WINNT/NTDS - 40.0 Mb total res2.log - 10.0 Mb res1.log - 10.0 Mb REPAIR.TXT - 0.0 Kb edb00001.log - 10.0 Mb edb.log - 10.0 Mb

移动数据库

将数据库从磁盘上的一个位置移到另一个位置时，可以在目录服务恢复模式中使用 Ntdsutil 命令行工具。例如，如果您先前为日志文件或 Ntds.dit 文件指定的驱动器或目录出现损坏，则可能需要将这些文件移动到另一个驱动器中。具体来说，move db to %s 命令可以将 Ntds.dit 数据文件移到 "%s" 指定的新目录中，并更新注册表键，以便使用新的位置重新启动目录服务。强烈建议您在移动操作的前后都进行备份，否则还原操作将不会保留新的文件位置。

还可以将日志文件从一个位置移到另一个位置。具体来说，Move logs to %s 命令可以将目录服务日志文件移到 %s 指定的新目录中，并更新注册表键，以便使用新的目录重新启动目录服务。

脱机碎片整理

Active Directory 以一定的间隔时间（默认情况下，每 12 小时一次）自动执行数据库的联机碎片整理，该操作是垃圾收集过程的一部分。联机碎片整理不会减小数据库文件 (Ntds.dit) 的大小，却可以优化数据库中的数据存储，并回收目录中的空间用来存储新的对象。它可以防止出现数据存储问题。执行脱机碎片整理可以创建新的压缩版本的数据库文件。根据原始数据库文件的破碎程度，新文件可能会小得多。执行脱机碎片整理的方法是：

备份 Active Directory。
重新启动域控制器，从启动菜单中选择适当的安装，然后按 F8 键，以显示 Windows 2000 高级选项菜单。
选择目录服务恢复模式，然后按 Enter 键。若要再次启动引导过程，请按 Enter 键。
使用本地管理员帐户登录。
单击开始，指向程序、附件，然后单击命令提示符。
在命令提示符下，键入 ntdsutil，然后按 Enter 键。
键入 files，然后按 Enter 键。
键入 info，然后按 Enter 键。这将显示有关 Active Directory 数据库及其日志文件的路径和大小的当前信息。记录下该路径。
建立一个具有足够驱动器空间的位置，用于存储压缩的数据库。
键入如下命令，其中 <驱动器> 和 <目录> 是您在上一步中建立的位置的路径。然后按 Enter 键：
compact to <驱动器>:/<目录>

注意必须指定目录路径。如果路径中包含有空格，则整个路径必须用引号引起来（例如，compact to "c:/new folder"）。

将会在指定的路径中创建一个名为 Ntds.dit 的新数据库。
键入 quit，然后按 Enter 键。若要返回到命令提示符，请再次键入 quit。
将新的 Ntds.dit 文件复制到步骤 8 中记录的当前 Active Directory 数据库路径中，覆盖旧的 Ntds.dit 文件。
正常重新启动计算机。

附录 IV