在引入 Windows 2000 Server 和 Active Directory 之前，许多企业环境都依赖 Windows NT 作为其服务器基础结构及进行身份识别与访问

管理。自 Windows NT^® 4.0 推出后，它就成为网络操作系统 (NOS) 领域的中坚支持产品，但由于它有很多缺陷，因而难以在大型企业范围内部署。

对于初学者，Windows NT 使用平面命名空间来存储网络资源，这意味着难以将资源分割为更小的子集或配置各种精细管理。例如，您无法为市场部门中的资源配置部门容器，也无法配置仅有权重新设置该部门内的用户密码的本地管理员。如此看来，Windows NT 安全性几乎完全得不到保障。如果您要向桌面支持工程师委派管理任务，通常不得不对其授予远远超出需要的权限。

此外，Windows NT 将所有信息存储在安全帐户管理器 (SAM) 数据库中，该数据库大小不能超过 40 MB。如果 SAM 数据库超过了此建议的最大大小（大约在达到 25,000-40,000 个对象时就会超过此值，具体取决于您的配置），则需要将环境分为多个单独的域，这样管理网络和为用户提供资源访问就会变得复杂。每个 NT 域都包含一个主域控制器 (PDC)，其中包含 SAM 数据库的只读/只写副本；尽管您可以为默认容错部署一个或多个备份域控制器 (BDC)，但这些 BDC 是只读的，无法执行任何需要写入操作的更新，如更改用户的密码。

最终，Windows NT 依赖于 NetBIOS 命名解决方案，它基于广播并且经常在用户浏览网络资源时（尤其是在需要通过慢速或被大量使用的 WAN 链接浏览时）生成大量通信。

在 2000 年，Microsoft 发布了 Windows^® 2000，其中包含对早期 NOS 产品的重要革新。您可以想像到，新的 NOS 服务 Active Directory^® 与 Windows NT 大不相同。Active Directory 不再依赖于平面命名空间，而是基于 X.500 标准构建，它创建了分层组织结构；现在您可以将资源组织到单个域的多个组织单元中，并基于任务级别对每个 OU 委派管理。

与 Windows NT 相比，另一个重大改进是全新的多主机复制模型。仅可写入的 PDC 及其相关的 BDC 一去不复返了；在 Active Directory 中，每个域控制器都可以写入到 Active Directory 数据库中。

不过，虽然这样可在支持大型和/或分散环境方面提供极大的灵活性，但对维护 Active Directory 的完整性也形成了新的挑战。如果 John Smith 和 Jane Dow 在某个国家/地区两端位置的办公室中对同一个对象进行了更改，而这些更改相互冲突，会发生什么情况呢？Active Directory 复制模型定义了将更新传达到某个环境中所有域控制器的方法，还定义了如何处理由可从任何地方进行更改的多主功能产生的冲突。

为了结合以下示例进行说明，我们将只讨论站点内复制。基本上，站点内复制旨在将更改快速复制到同一站点的 DC 内，然后使用更改通知来执行。在站点内复制的情况下，DC1 将通知 DC2 有需要复制的更改，然后 DC2 从 DC1 中拉出这些更改。同样，当 DC2 有任何更改时，它也会通知 DC1，然后 DC1 从 DC2 中拉出这些更改。您可以看到，所有的 Active Directory 复制都通过“拉”操作而不是“推”操作进行。

因为 Active Directory 可扩展至几十万甚至数百万个对象，所以有必要将 Active Directory 数据库划分为多个部分（称为命名上下文）。每个域控制器可在 Active Directory 数据库的本地副本中存储至少三个 NC。

架构 NC 此 NC 将被复制到林中的其他各个域控制器中。它包含有关 Active Directory 架构的信息，该信息又定义了 Active Directory 内不同的对象类和属性。

配置 NC 此 NC 也会被复制到林中的其他各个 DC 中，它包含林范围内有关 Active Directory 的物理布局的配置信息，以及有关显示标识符和林范围内 Active Directory 配额的信息。

域 NC 此 NC 将被复制到单个 Active Directory 域中的其他各个 DC 中。正是此 NC 中包含最常访问的 Active Directory 数据：实际用户、组、计算机以及其他驻留在特定 Active Directory 域中的对象。

为了更好地优化复制通信量，将单独复制每个命名上下文，以使更改不频繁的 NC（如架构 NC）不占用域 NC（更改很可能更加频繁）所需的网络带宽。

由于可从任何 Active Directory DC 进行目录更改，因此 Active Directory 复制需要跟踪两种类型的写入操作。一种类型是原始写入，在直接对特定 DC 执行特定更改时进行的写入。例如，如果您连接到 DC1 并更改用户的密码，此更改便被视为 DC1 上的原始写入。Active Directory 还必须跟踪复制的写入，正如您能想像到的，这表示会将特定更改从其他域控制器中复制过来。被视为 DC1 上的原始写入的更改在被复制到 DC2、DC3 以及域范围内的其他任何 DC 中后，便被视为复制的写入。

Active Directory 域控制器通过使用复制元数据管理目录更改的传输。这表示 Active Directory 除了将已更改的实际数据从一个 DC 传输到另一个 DC（对 John Smith 的描述更改为“人力资源主管”），还会传递关于该更改的其他信息（如更改源自的 DC、进行更改的时间以及其他关键信息）以使域控制器以最高效的方式管理复制。

我们要讨论的第一个复制元数据项目是更新序列号 (USN)。每个域控制器都维护特定于该域控制器的 USN。每当从该 DC 对 Active Directory 进行更改，USN 都会增加 1。因此如果某 DC 的 USN 在上午 11:00 时为 1000，而在上午 11:30 时为 1005，您就会知道已在该 DC 上对 Active Directory 数据库进行了 5 次更改。事实上，进行什么样的更改对 USN 来说并不重要 — 您可以修改 5 个不同的对象、创建 5 个对象、删除 5 个对象或前述操作的任意组合，该 DC 的 USN 都会增加 5。此外，USN 仅是特定域控制器的内部项目，与其他 DC 相比较时没有任何参考价值。域中的某个 DC 可能在上午 11:30 时进行更改，并指定 USN 为 1051；而相同域的另一个 DC 可能在同一时刻进行更改，并指定 USN 为 5084。尽管两个 DC 对于几乎同时进行的更改很明显具有完全不同的 USN，但这与如何复制这些更改并不相关；就不同变更之间的比较来说，某个 DC 的更新序列号对其他任何 DC 而言都毫无意义。

但这并不是增加 DC 的 USN 的唯一方式。请记住，对 Active Directory 数据库的更改可包括原始写入或复制的写入。两种类型的写入操作都可增加域控制器上的更新序列号，这意味着每当从其他 DC 复制了更改时，该序列号都会增加。现在，很明显可以看出，每个 DC 都需要一种方法来跟踪已复制的更改，否则每个 DC 在每次复制时都会通过缆线发送整个 Active Directory 数据库。为避免发生这种情况，每个 Active Directory 域控制器都为其他用于进行复制的域控制器维持一个称为高水准矢量 (HWMV) 的值。每个 DC 都将此高水准矢量与远程 DC 的全局唯一标识符 (GUID) 相关联，以防止在远程域控制器被重命名或从目录中删除后产生混淆。

我们从一个简单的示例开始，假设您在 contoso.com 域中配置了两个域控制器 dc1.contoso.com 和 dc2.contoso.com。因为 contoso.com 域中只有两个 DC，所以 DC1 和 DC2 只能彼此复制。（请注意这只是一个简化的示例，并不能完全说明 Active Directory 复制的所有细节。随着讲述的深入，我们会添加更多详细信息。）

我们再假设 DC1 的当前 USN 为 3000，DC2 的当前 USN 为 4500，在开始我们的示例时两个 DC 对彼此而言都已处于最新状态：

步骤 1：DC1 和 DC2 对彼此而言均处于最新状态。DC1 对于 DC2 的高水准矢量为 4500，DC2 对于 DC1 的高水准矢量为 3000，如图 1 所示。

图 1 两个 DC 的当前状态

步骤 2：管理员在 DC1 上创建了一个新对象，DC1 的 USN 增加到了 3001，如图 2 所示。请注意 DC1 针对 DC2 的 HWMV 没有更改，因为 DC1 尚未通知 DC2 自己有正等待中的更改。

图 2 添加了一个新对象

步骤 3：DC1 通知 DC2 自己有可用更改。随后 DC2 启动对 DC1 的复制来请求任何可用的更新。作为此请求的一部分，DC2 将向 DC1 发送其针对 DC1 存储的高水准矢量，如图 3 所示。

图 3 更改通知 (单击该图像获得较小视图)

图 3 更改通知 (单击该图像获得较大视图)

步骤 4：DC1 向 DC2 发送与 USN 3001 相对应的更改，即在步骤 2 中在 DC1 上创建的对象。DC2 将自己的 USN 更新为 4501 并将针对 DC1 的 HWMV 更新为 3001，如图 4 所示。

图 4 更改和更新 (单击该图像获得较小视图)

图 4 更改和更新 (单击该图像获得较大视图)

到目前为止都没有问题吧？但现在问题就来了。DC2 有一个需要复制的更改。如果原来进行的只是 USN 和高水准矢量的更改，那么现在 DC2 要联系 DC1 以将 DC1 刚才复制到 DC2 的相同更改复制回 DC1，这将形成一个无穷的复制循环，并会不断占据越来越多的带宽。为防止此种情况，我们需要再多用几个矢量来解决难题，第一个是最新矢量（UTD 矢量或 UTDV）。

UTDV 是另一个用于强化抑制的复制元数据，即其目的是防止相同的更改通过网络一再重复被复制而耗费带宽。每个 DC 针对其他每个 DC 维护一个 UTDV 表，其中存储相关命名上下文的副本。对于域 NC，域中的各个 DC 针对该域中的每个 DC 维护一个 UTDV；对于配置和架构 NC，则针对林中的每个 DC 维护一个 UTDV。该 UTDV 表不仅会跟踪每个 DC 从其复制合作伙伴接收的最大 USN，还会跟踪从复制给定 NC 的各个 DC 中接收的最大 USN 值。为此，每个复制的更改还需要包括以下信息：

• 要复制更改的 DC 的 GUID。这个要复制的更改可以是原始写入或复制的写入。
• 要从中复制更改的 DC 的 USN。同样，此更改既可以来自原始写入，也可以来自复制的写入。
• 引起更改的 DC 的 GUID。如果此 GUID 与复制更改 DC 的 GUID 相同，表明它是原始写入。否则，UTDV 表就起作用了。
• 引起更改的 DC 的 USN。同样，如果此 USN 与复制更改的 DC 的 USN 相同，就表明这是原始写入。否则，它就不是 UTDV 表。

为了更好的说明此过程，我们添加第三方域控制器 (DC3) 增加示例的复杂性。在本示例中，DC1、DC2 和 DC3 是相互的复制伙伴；DC1 与 DC2 和 DC3 互相复制，DC2 与 DC1 和 DC3 互相复制，DC3 与 DC1 和 DC2 互相复制：

步骤 1：DC1、DC2 和 DC3 对彼此而言都处于最新状态。

步骤 2：DC3 通过重置 jsmith 用户帐户的密码执行单个原始写入。DC3 通知 DC1 和 DC2 自己有可用更改。DC1 和 DC2 从 DC3 拉出原始写入，然后更新各自针对 DC3 的 HWMV 和 UTDV 表，如图 5 所示。

图 5 更新 HWMV 和 UTDV 表 (单击该图像获得较小视图)

图 5 更新 HWMV 和 UTDV 表 (单击该图像获得较大视图)

步骤 3：轮到最新矢量登场了。DC2 通知 DC1 自己有可用更改。然后 DC1 通过向 DC2 发送以下信息与 DC2 联系以请求新更改：

• DC1 对 DC2 的高水准矢量值，在此情况下为 4501。
• DC1 的 UTDV 表（如图 6 所示），指示已从所有 DC（包括 DC3）接收的最高原始 USN 。

根据 HWMV 为 4501 的情况判断，DC2 知道尚未将相关更改复制到 DC1（请参见图 7）。

但是，根据在开始复制之前 DC1 传送的 UTDV 表，DC2 断定 DC1 实际上并不需要此更改，因为 DC1 已从 DC3 接到了此更改。此时，DC1 仅更新对 DC2 的 HWMV 项目来反映 USN 的增加，如图 8 所示。但是，为了节省带宽，并不通过缆线发送实际数据。

图 8 传播抑制 (单击该图像获得较小视图)

图 8 传播抑制 (单击该图像获得较大视图)

步骤 4：当 DC2 通知 DC3 自己有可用更改时以及当 DC1 以类似方式通知 DC2 和 DC3 时，便会发生相同的传播抑制情况。这三个 DC 将更新各自针对自已的复制伙伴的 HWMV 条目，如图 8 所示，但因为实际数据已在步骤 2 中传送到各个 DC，所以不会再度通过缆线传输。

到目前为止，我们的示例依然存于一个完美的世界中，每次只有一个管理员对 DC 进行更改，从不会出现冲突情况。我们知道这在现实世界中很罕见。既然对 Active Directory 对象的更新可以来自域中的任何域控制器，那么，如果两个管理员从两个不同域控制器执行的更新相互冲突时会发生什么情况？Active Directory 环境中可能发生三种类型的冲突，它们使用不同的冲突解决方案方法。

冲突的属性变更 . 如果两名管理员用相互冲突的方式更新相同的对象，便会发生此类型的冲突：一名管理员将用户描述设置为“市场”，另外一名管理员在另一 DC 上将用户描述设置为“销售和市场”。

创建冲突的新对象 . 如果两个管理员同时使用相同的名称创建对象，例如，两个名为 jsmith 的用户，便会发生此类型的冲突。

将对象移动到删除的容器 . 这种类型的冲突较为少见，如果管理员在容器内（例如，OU）创建或移动对象，与此同时另一名管理员在另一 DC 上删除了该容器，便会发生此类型的冲突。

为了解决前两种类型的冲突，下面介绍另外两个主要用于冲突解决方案的复制源数据。为对象中每个单独的属性分配 versionID 值，初次创建对象时，该值的起始值为 1。只要一修改任意 DC 中的某个属性，versionID 就会增加 1。因此如果特定用户的描述属性已从默认值（空白或 <未设置>）更新为“市场部”，则描述属性的 versionID 会变成 2。如果稍后该描述修订为“销售和市场部”，则描述属性的 versionID 会变成 3，依此类推。此 VersionID 与我们之前介绍的其他元数据一起包含在每个复制项目中。

此 versionID 也可用于进一步减少复制通信量。例如，如果 DC2 上的管理员已对某个属性进行多次更改（可能该管理员几次键入错误更改），使 DC2 具有与 versionIDs 2、3、 4、和 5 对应的原始写入，在此情况下 DC2 将仅复制与最后一个版本 versionID 5 相对应的写入。由于早期更改难逃被覆盖的命运，因此这样可便捷地减少不必要的带宽占用。

对 Active Directory 所做的每个更改中还包含冲突解决方案使用的第二个附加元数据，这是一个时间戳，属于复制元数据的一部分，指示修改是何时进行的。

也可将时间戳属性用作检测 Active Directory 复制运行情况的主动措施。如果 DC 使用相对较新的时间戳未发现特定 DC 中有任何更改，就会开始生成错误消息指示相关 DC 中可能存在问题。

那么，如何在冲突解决方案中使用这两个属性？我们来依次检查每种冲突类型。

请看 contoso.com 域中 jsmith 用户对象的例子。DC1 上的管理员将对 jsmith 的描述改成了“市场”。几乎同时，DC3 上的管理员将这同一名用户的描述改成了“销售和市场”。此时，DC1 和 DC3 中关于 jsmith 描述属性的比较如图 9 所示。

如果 DC2 同时接到这两种更改，它无疑就需要确定哪个更改“获胜”。相互冲突的解决方案的加时赛顺序如下所示：

1. 具有较高 versionID 的修改会“获胜”，而“失败”的修改会被覆盖。在本例中，如果两个记录的 versionID 都是 2，我们就需要进入第二场加时赛。
2. 如果两个记录具有相同的 versionID，时间戳较晚的更改将获胜，而失败的更改将被覆盖。本例中 DC3 的原始写入的时间戳较晚，所以 jsmith 的描述将被设置为“销售和市场”。极少数情况下，如果 versionID 和时间戳都相同，就需要进行第三场决定性的加时赛：
3. 如果两个记录的 versionID 和时间戳都相同，则具有较低编号 GUID 的 DC 生成的写入将获胜；而具有较高编号 GUID 的写入会被覆盖。因此在 DC1 的 GUID 是 1234567890，DC3 的 GUID 是 2345678901，而两者的 versionID 和时间戳都相同的情况下，DC1 生成的写入会获胜。

您可能在想，“在第一场加时赛中应用时间戳岂不更有意义？”然而事情并不像您想象的那样毫无波澜。如果时间戳是 Active Directory 冲突解决方案中主要的加时赛，想要传播更改的恶意管理员只需将特定 DC 的时钟往回拨，就可以总能靠时间戳获胜。

在两个对象具有相同创建名的情况下，Active Directory 同样将使用上一节介绍的那三场加时赛来确定哪个对象会“获胜”。但是，与上节所述的不同之处在于“失败”的对象不会被覆盖，而是使用字符 CNF（对于冲突对象来说）重命名失败的对象，后面加上冒号和“失败”对象的 GUID。这样，管理员即可更系统地确定应该保留和删除的对象。

如上所述，解决将对象移动到删除的容器是相对较少发生的冲突，只在两种情况下才会发生。一种情况是，某个 DC 上的管理员在特定容器中（例如 Training OU）创建了一个对象，而与此同时另一个 DC 上的管理员删除了该 Training OU。另外一种情况是，某个 DC 上的管理员将一个对象移动到了某个容器中，而与此同时另一个 DC 上的管理员删除了该容器。

在这种情况下，解决方案非常直接：Active Directory 会将“孤儿”对象移动到 Active Directory 的一个特殊容器中（该容器是专为此用途而设）— LostAndFound 容器，它存在于每个 Active Directory 域的根目录下。对于 contoso.com 域，可在以下 LDAP 路径中找到 LostAndFound 容器：LDAP://cn=LostAndFound,dc=contoso,dc=com。如果打开 Active Directory 用户和计算机管理单元时未看到 LostAndFound 容器，只需单击“查看”|“高级功能”。

在 Active Directory 环境中，您可能会遇到一种最严重的情况，如果您了解了它的成因和解决方法，这种最严重的情况也是最容易避免的情况。USN 回滚是一种错误状态，可使网络上的复制完全关闭。之所以会发生 USN 回滚，是因为允许域控制器保持脱机状态相当长时间后返回服务状态，也可能是因为使用不受支持的方法还原域控制器。

导致 USN 回滚的一个基本原因与在 Active Directory 多主机环境中处理删除对象的方式有关。在 DC 上删除对象时，并不会将该对象彻底删除，而是被逻辑删除，以便逻辑删除的对象可以复制到其他 DC 中，以此通知它们对象的删除。最值得注意的是，逻辑删除对象具有一个设为 TRUE 的 isDeleted 属性。为减小逻辑删除对象的大小，对象中所包含的大部分值（如描述、个人信息和用户对象的组成员身份）已被删除（有关此过程的详细信息，请参阅 technetmagazine.com/issues/2007/09 上 Gil Kirkpatrick 的文章《恢复 Active Directory 逻辑删除对象》。

因为这些逻辑删除对象不会无限期保留，所以可能会发生 USN 回滚。默认情况下，60 或 180 天后 Active Directory 数据库会完全清空这些逻辑删除对象（具体时间取决于您首次创建 Active Directory 环境时运行的 Windows Server^® 版本）。这 60 或 180 天的间隔称为 tombstone 生存时间。在这段时间内，所有域控制器都必须能至少复制一次，否则不仅于事无补，而且会让事情更糟；它们为 USN 回滚创造了机会。基本上，如果域控制器完全过时而“遗漏”了一个或多个逻辑删除对象，并因此无法向其他 DC 提供最新的 Active Directory 数据库本地副本，这时就会发生 USN 回滚。为避免发生这种情况，不应将脱机时间已超过逻辑删除生存时间的域控制器返回到服务状态；而是使用 Microsoft 知识库文章 216498 (support.microsoft.com/kb/216498) 中提供的步骤，从 Active Directory 中删除旧 DC 的元数据，然后从头重建域服务器。

导致发生 USN 回滚的第二个原因是使用不受支持的方法（最常使用的是磁盘克隆或映像工具）还原了域控制器。如果发生 USN 回滚，由于还原方法没有 Active Directory 感知功能，所以已还原的 Active Directory 数据库并不会意识到自己已“回到过去”。Windows 2000 和最初发行版本的 Windows Server 2003 很难检测出 USN 回滚，但是 Windows Server 2003 SP1（和即将发布的 Windows Server 2008）具有内置控件，可检测出未正确还原的 DC 情况。在这些比较新的 OS 版本中，DC 会在 Directory Services 事件日志中记录事件 ID 1115、2095、2103 和 2110；这些事件的文本和从 USN 回滚中恢复的必要步骤可在适用于 Windows Server 2003 的知识库文章 875495 (support.microsoft.com/kb/875495) 中找到。（有关在 Windows 2000 中处理 USN 回滚的信息，可从 support.microsoft.com/kb/885875 上的知识库文章 885875 中找到。）

在即将发布的 Windows Server 2008 版本中，Microsoft 通过引入只读域控制器 (RODC)，在多主机模型中进行了细微的改动。RODC 主要用于分支机构部署，或用于在特定位置没有派专业工作 IT 人员到现场，但需要采取额外步骤来确保特定 DC 的完整性的情形。虽然我们满可以用整篇文章来讨论关于 RODC 的所有技术细节，但我们还是重点研究一下您应该熟悉的要点吧。

如名称所示，驻留在 RODC 上的 Active Directory 数据库的副本是只读的。可以连接到 RODC 来读取所需的几乎所有信息，但在 RODC 上无法执行任何写操作。

其次，RODC 不执行任何出站复制操作。这是与我们目前为止一直讨论的多主机复制模型最根本的不同。RODC 会从其他可写 Windows Server 2008 DC 接收入站复制，但它不向其他 DC 复制任何信息。这样可再增加一层安全屏障，即使恶意用户能设法从 RODC 中修改 Active Directory，这些修改也不会传播到环境的其他部分。

也许最令人感兴趣的是，在默认情况下，RODC 不复制用户密码。将 Active Directory 数据库从可写 DC 入站复制到 RODC 时，将复制所有用户对象，但不包括用户的密码信息。这为分支机构环境提供了另一安全屏障，假如 DC“长腿跑了”，DC 的硬盘驱动器上也没有密码信息。整体来看，这些对多主机 Active Directory 复制最初理念的更改创建了一个有很大改进的模型，可用于确保分支机构或其他远程位置中的域控制器的安全。