52CE 我爱测NETWORK OBSERVATORY 网络诊断 · 技术资料 · 运维工具
首页/信息库/域与目录服务
域与目录服务

被遗弃的对象阻碍全局目录命名上下文的复制 - Windows Server

· 52CE 我爱测

总结 在 Active Directory 域服务（AD DS）中，孤立对象是存在于林中某些域控制器（DC）但从未复制到所有 DC 的对象。 放弃的对象通常出现在全局编录服务器（GCs）或只读域控制器（RODC）上的只读命名上下文（也称为 分区）。 由于标准 挥之不去的对象 删除工具无法删除已放弃的对象，因此它们可能会导致持久复制错误和难以诊断的搜索结果混乱。 本文讨论如何识别和删除已放弃的对象。 它涵盖以下主题： - 如何识别被遗弃对象的症状，包括复制错

总结

在 Active Directory 域服务（AD DS）中，孤立对象是存在于林中某些域控制器（DC）但从未复制到所有 DC 的对象。 放弃的对象通常出现在全局编录服务器（GCs）或只读域控制器（RODC）上的只读命名上下文（也称为 分区）。 由于标准 挥之不去的对象 删除工具无法删除已放弃的对象，因此它们可能会导致持久复制错误和难以诊断的搜索结果混乱。

本文讨论如何识别和删除已放弃的对象。 它涵盖以下主题：

  • 如何识别被遗弃对象的症状，包括复制错误和暂时性或虚拟对象。
  • 放弃的对象与挥之不去的对象有何不同。
  • 如何使用脚本和手动步骤删除已放弃的对象。
  • 如何使用复制元数据、最新性向量和 DC 标识符来调查废弃对象的根本原因。

先决条件

症状

您管理的 Windows Active Directory 林具有多个域或只读域控制器（RODC），或同时拥有两者。 遇到类似于以下示例中的任何一个的行为、事件或错误消息。

示例 1：暂时或虚拟对象

应用程序或用户搜索Active Directory对象，但搜索结果不一致。

  • 用户或应用程序在连接到 RODC 或 GC 时查找对象。 但是，如果用户或应用程序连接到可写 DC，该对象似乎不存在。
  • 如果用户或应用程序在林级别搜索，则会找到该对象。 如果在域级别搜索，该对象似乎不存在于任何域中。

同样，用户或应用程序会尝试创建对象，但会收到一条错误消息，指示已使用可分辨名称（DN）、用户主体名称（UPN）或服务主体名称（SPN）。 但是，搜索找不到具有该特定 DN 的对象。

示例 2：GC 复制错误：“无法更新对象”和“服务器上没有此类对象”

注释

与 GCS 不同，RODC 在包含放弃的对象时可能不会生成事件或错误。 GCS 可以相互复制，但 RODC 不会复制到任何其他 DC。

事件日志包含事件 ID 1084。 此条目指示目标 GC 上Active Directory实例缺少预期的对象。

Log Name:      Directory Service
Event Source:  Microsoft-Windows-ActiveDirectory_DomainService
Event ID:      1084
Task Category: Replication
Level:         Error

Description:
The directory replication agent (DRA) couldn't update object <FQDN> (GUID <ObjectGUID>) on this system with changes which have been received from source server <SourceServerGUID>._msdcs.bc.com. An error occurred during the application of the changes to the directory database on this system.

如果在目标 GC 的命令提示符下运行 repadmin /showreps ，输出将包含类似于以下示例的消息。

<Site_Name>\<GC> via RPC  
DSA object GUID: 2521a874-d379-4281-8744-4bd34c792026  
Last attempt @ 2002-01-21 16:10.54 failed, result 8240:  
There is no such object on the server.

注释

在此示例中， <Site_Name>/<GC 是标识目标 GC> 的站点名称和 NetBios 名称。 目录系统代理 （DSA） 对象 GUID 是源 GC 的永久标识符。

示例 2：无法删除的“滞留对象”

除了事件 ID 1084 之外，您可能还会看到事件 ID 1988 被记录。 通常，此事件指示Active Directory包含挥之不去的对象。 但是，在这种情况下，它可能表示遗弃的物品。

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1988
User: NT AUTHORITY\ANONYMOUS LOGON

Description:
Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as "lingering objects".

This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database. This replication attempt has been blocked.

The best solution to this problem is to identify and remove all lingering objects in the forest.

Source DC (Transport-specific network address):
a3a724aa-55cf-4a0f-8889-2b3fd37a72bd._msdcs.contoso.com

Object:
DC=175.3\0ACNF:160e575d-9205-493d-89b8-97f152af40a5,CN=LostAndFound,DC=contoso,DC=com

Object GUID:
160e575d-9205-493d-89b8-97f152af40a5

要区分您是有残留对象还是被弃对象，请打开命令提示符窗口，然后运行以下命令：

repadmin /removelingeringobjects

命令停止运行后，再次运行它。 如果对象仍然存在，则它们可能是弃用对象，而不是滞留对象。

按名称或 GUID 检查对象时，在可写 DC 上找不到它们。

原因

基本场景是在拥有 RODC 或 GC 作为复制伙伴的中心 DC 上创建一个对象，除此之外还有其他读写副本。 DC 或基础结构中的条件允许对象复制到只读副本，但不能复制到可写副本。 防火墙配置问题或网络问题可能会导致此行为。

在修复此复制问题之前，中央 DC 会被强制从森林中删除。 由于可写 DC 不使用 DC 或 RODC 作为入站复制伙伴，因此对象无法访问可写 DC。 因此，该对象被视为 RODC 或 GCS 上的已放弃对象。

在对象被删除后，如果在一个以 RODC 或 GC 为复制伙伴的中心 DC 上恢复该对象，并且还有其他读写副本，则会出现类似的情况。 同样，还原操作仅在强行删除中央 DC 之前复制到只读副本。 在可写 DC 上，该对象保持其墓碑状态，直到其墓碑生存期到期。 然后，垃圾回收过程将对象彻底移除。 同样，该对象被视为 RODC 或 GCS 上的已放弃对象。

放弃的对象类似于残留的对象。 但是，徘徊对象是在某个时间点存在于所有Active Directory副本中的对象，并且一个或多个副本未收到“删除”更改。 被弃用的对象存在于一些只读副本上，但其余副本从未接收到“创建”变更。 由于这种差异，遗留对象删除工具可能会识别出已放弃的对象，但无法将其删除。 若要详细了解放弃的对象和挥之不去的对象是如何发生的，以及它们的区别，请参阅放弃的对象和挥之不去的对象。

解决方案

你可能需要帮助才能针对特定问题执行适当的操作过程。 可以请求Microsoft技术支持来帮助你解决此问题。

重要

这些方法侧重于删除已放弃的对象，而不是在未复制到的 DC 上创建或还原这些对象。 有关可帮助你确定最初生成已放弃对象的复制问题的参考信息，请参阅 详细信息。

repadmin /removelingeringobjects 使用的算法检查更新向量的范围。 它不会删除 up-to-dateness 向量之外的对象。 根据定义，放弃的对象不存在于可写域控制器（DC）的最新状态向量中。 因此，您必须使用除 repadmin 以外的工具来移除已放弃的对象。

本文介绍使用手动步骤和脚本删除已放弃对象的过程。 您所遵循步骤的具体细节取决于您的林场配置以及您拥有的遗弃对象类型。

步骤 1：收集遗弃对象的 GUID 和托管这些对象的 DC

若要删除已放弃的对象，必须按其 objectGUID 值标识每个对象。 可以从事件和错误消息以及记录操作（如搜索）的日志文件中获取此信息，这些记录结果不一致。 还可以使用脚本来标识某些Active Directory副本中存在但在其他副本中不存在的对象。

以下示例 PowerShell 脚本检测到放弃的对象。 它会在受影响的 GC 命名上下文中创建对象列表，然后检查每个对象是否存在于引用子域中。 如果对象不存在，脚本会将对象信息导出到 .csv 文件和 .ldf 文件。 该脚本不会更改任何对象或对象属性。

注释

在此脚本中，将 $GCdomain 的值更改为受影响域的 DN，将 $rwdomain 更改为引用 DC 的 DN。

重要

此示例脚本在任何Microsoft标准支持程序或服务下都不受支持。

示例脚本“原样”提供，不提供任何形式的保证。 Microsoft进一步否认所有默示担保，包括无限制地保证适销性或适合特定目的的任何默示担保。

由于示例脚本及文档的使用或性能所引起的全部风险均由您承担。 在任何情况下，Microsoft、其作者或参与创建、制作或交付脚本的任何其他人均不对任何损害负责（包括但不限于商业利润损失、业务中断、业务信息丢失或其他经济损失），即使 Microsoft 已被告知此类损害的可能性也是如此。这些损害是由于使用或无法使用示例脚本或文档而引起的。

$GCdomain = "contoso.com"
$rwdomain = "child.contoso.com"
$rwdomainNC = get-addomain $rwdomain

$GC = "dc2.contoso.com:3268"
$gcdc = "dc2.contoso.com"
$allrwdcs = Get-ADDomainController -filter * -server $rwdomain | select-object hostname
get-adobject -filter '*' -searchbase $rwdomainnc .distinguishedname -server$GC|select-propertyname,distinguishedname,objectguid|export-csv-path.\root.csv-NoTypeInformation
$objects = import-csv .\root.csv

Foreach($objectin$objects)
{
   try
      {
         foreach ($dcin$allrwdcs)
            {get-adobject$object.objectguid -server$dc.hostname >$Null}
      }
   catch {$object|export-csv-path.\abandoned.csv-NoTypeInformation-Append
      $name = $object .name
      ldifde -f .\ $name .ldf -d $object .distinguishedname -s$gcdc-t3268-lname,objectclass,objectguid
      }
}

步骤 2：解决那些在只读副本中已还原但在可写副本中依旧被标记为逻辑删除的遗弃对象。

可以针对此步骤使用以下一种或两种方法，具体取决于已放弃对象的详细信息。

  • 如果使用方法 1，可能不必使用步骤 3。 但是，方法 1 仅在有限的情况下可行，并且可能无法解决所有已放弃的对象。
  • 在大多数情况下，可以使用方法 2。 但是，必须继续执行步骤 3 才能完成删除过程。

步骤 1：使用墓碑对象在复制拓扑中重置对象的复制元数据

重要

此方法不适用于每种类型的对象。 例如，对具有子 Rid Set 对象的域控制器计算机对象使用此方法将导致进一步的问题。

可以在以下条件下使用此方法：

  • 被放弃的对象已从删除状态恢复。
  • 该对象仍以墓碑形式存在于林中其他副本中（tombstoneLifetime 尚未失效）。
  • 具有被遗弃对象的 GC 或 RODC 正在正常复制。

在此情境中，您可以连接至其中一个可写副本，恢复该对象，然后再次删除它。 这些更改会同步到其他 DC 以及原始 RODC 或 GC，从而使整个林中的对象状态保持一致。 最新状态向量也同步。

方法 2：清除复制拓扑中的墓碑标记

在许多情况下，参考 DC 具有已放弃对象的墓碑（或回收站中的对象），因此方法 1 不可行。 在这种情况下，等待墓碑自然过期可能并不可行。 例如，如果已启用回收站，则对象将保留在回收站 msDS-deletedObjectLifetime 中（默认情况下为 180 天）。 此时，它们将成为回收对象。 Active Directory将回收的对象视为墓碑。 因此，对象将保持此状态 tombstoneLifetime （默认情况下为 180 天）。

注释

针对 GC 命名上下文，其中 GC 最初从可写 DC 进行复制，并在稍后切换为从 GC 上的只读副本复制，您可能会在 tombstoneLifetime 过期之前收到复制错误。 因此，若要使这些对象过期，但仍允许进行其他复制，可能需要禁用严格的复制一致性，并允许涉及损坏或分裂的合作伙伴的复制。 有关如何使用这些设置的信息，请参阅 Troubleshoot Active Directory 复制错误 8614。

若要更快地清理引用 DC 中的墓碑对象或逻辑删除对象，请使用以下方法缩短这些对象在垃圾回收进程删除它们之前的保留时间。

  • 从回收站中删除对象。 可以使用 Windows PowerShell 将被删除的对象强制转为可回收对象，以防msDS-deletedObjectLifetime过期。 若要运行此过程，请在引用 DC 上打开管理 PowerShell 命令提示符窗口，然后运行类似于以下示例的命令：

    Get-ADObject -Filter 'isDeleted -eq $True -and -not (isRecycled -eq $true) -and name -ne "Deleted Objects" -and lastKnownParent -eq "<LastKnownParent_DN>"' -IncludeDeletedObjects | Remove-ADObject

    注释

    在此命令中， <LastKnownParent_DN> 表示删除对象之前保存对象的容器的 DN。

    运行此命令后， tombstoneLifetime 控制回收对象保留在副本中的时长。

  • 缩短 tombstoneLifetime。 如果从 180 天减少 tombstoneLifetime 到仅几天，则可以加快垃圾回收过程。

    重要

    如果您的林有持续的复制问题，并且某些 DC 明显不同步，那么设置较低的 tombstoneLifetime 值会增加林中积累残留对象的风险。

步骤 3：删除未标有墓碑标记的废弃对象

如果用作引用 DC 的可写 DC 上没有以任何形式存在的被遗弃对象（例如，墓碑对象或回收站中的对象），则可以使用此方法。 请验证引用 DC 的副本中是否不存在已放弃的对象。

若要删除遗留对象，请按照 在过时的复制伙伴上手动删除遗留对象的过程进行操作。 如果使用脚本创建已放弃对象的列表，则可以使用该列表作为此过程使用的脚本的输入。

链接的文章提供了详细说明。 尽管它显示为删除挥之不去对象的手动过程，但它也适用于已放弃的对象。 本文包含脚本，这些脚本在引用 DC 的副本级别运行ldp.exe工具的removelingeringobject操作属性RootDSE。

完成此过程后，运行以下命令以确保已放弃的对象不存在于林中。

repadmin /showobjmeta \* "\<guid=orphaned objectGUID\>"

此命令检查林中所有 DC 上是否存在已放弃的对象。 如果成功删除对象，该命令将生成类似于以下示例的输出：

DsReplicaGetInfo() failed with status 8439 (0x20f7):  
The distinguished name specified for this replication operation is invalid.

详细信息

本部分提供详细的背景信息，可帮助你诊断你的林是如何生成已放弃的对象的。

已放弃对象和悬挂对象是如何形成的

下表提供了一个简化视图，说明了如何产生滞留对象和遗弃对象。 它突出显示了三种类型的对象的相似性和差异。

重要

下表描述了事件序列。 这些序列不是故障排除说明。

序列 放弃的对象类型 1 放弃的对象类型 2 滞留对象
状态 1 对象不存在。 对象存在于所有 DC 上。 对象存在于所有 DC 上。
状态 2 对象不存在。 对象存在于所有 DC 上。 对象存在于所有 DC 上。一个 DC （DC-1） 断开与网络的连接。
状态 3 对象不存在。 对象被删除。 “删除”更改将复制到所有域控制器。 对象被删除。 “删除”更改将复制到除 DC-1 以外的所有 DC。
状态 4 对象是在 DC-2 上创建的。“创建”更改将复制到 GC 或 RODC。在“创建”更改复制到常规 DC 之前，DC-2 会断开与网络的连接。 在墓碑生命周期到期之前，将在 DC-3 上恢复对象（取消删除）。“还原”更改将复制到 DC 或 RODC。在“还原”更改复制到常规 DC 之前，DC-3 会断开与网络的连接。 除 DC-1 之外的所有 DC 都具有对象的墓碑。 DC-1 拥有原始对象。
状态 5 某些 GCS 或 RODC 具有该对象。 可写域控制器 (DC) 没有该对象。 某些 GC 或 RODC 具有该对象。 可写的域控制器包含对象的墓碑。当墓碑生存期到期时，将删除墓碑。 除 DC-1 之外的所有 DC 都具有对象的墓碑。 DC-1 具有原始对象。当墓碑生存期到期时，将删除墓碑。最后，DC-1 重新连接到网络。
结果 某些 GC 或 RODC 拥有该对象，并进行了“创建”更改。 常规 DC 没有对象或“创建”更改，并且不会从 DC 或 RODC 接收入站复制。 某些 GC 或 RODC 拥有该对象，并已应用“还原”更改。 普通 DC 没有对象或“还原”更改，并且它们不会从 GC 或 RODC 接受自入站复制。 只有 DC-1 具有该对象。 DC-1 没有“删除”更改。 其他域控制器（DC）在更改历史记录之外没有任何对对象的引用。

调查弃置对象：如何解释来自复制伙伴和更新矢量的信息

由于许多原因，查找复制问题可能是一项复杂的工作。 一个原因是复制报告和记录通常使用多个标识符来跟踪单个 DC，并且这些标识符会随时间而变化。 每个 DC 都从以下几个方面跟踪入站复制：

  • 复制伙伴的标识
  • 该复制伙伴上的“Active Directory”副本的状态，包括是否（以及何时）从备份恢复。
  • 复制伙伴是否有尚未复制的更改
  • 复制伙伴以前发送的所有更改，每次还原之前和之后

标识复制合作伙伴

若要跟踪已放弃的对象，需要为每个受影响的 DC 及其入站复制合作伙伴提供两个 GUID。 下表描述了这些 GUID。

GUID 类型 也称为 说明
DSA 对象 GUID DSA GUID 此 GUID 是 DC 的永久标识符。 将基于Windows的服务器提升到 DC 时，Windows创建此 GUID。 此 GUID 不会更改。
DSA 调用 ID invocationID 此 GUID 标识 DC 上Active Directory的当前副本。 Windows将 DC 添加到新域或现有域时配置此 GUID，并在从备份还原 DC 时对其进行更改。 在提升 DC 并创建一个新的森林时，该 DC 使用其 DSA GUID 作为其调用标识符，直到第一次从备份中还原该 DC。

注释

如果停止并解除分配在 Azure 中运行的虚拟 DC，则下次启动 DC 时，Windows的行为就像从备份还原Active Directory一样。 DC 的调用 ID 会自动更改。 由于此行为，虚拟 DC 可能会以与物理 DC 不同的速率更改其调用 ID。

如果必须停止 Azure 虚拟机，可以通过在来宾操作系统内关闭 VM，而不是使用 Azure 门户来避免此行为。 虚拟 DC 关闭自身后，可以解除分配它。 有关详细信息，请参阅“在Azure虚拟网络中部署 AD DS”中的 manageability。

有关还原虚拟化 DC 时要遵循的更常规的最佳做法，请参阅“虚拟化域控制器部署和配置”中的 虚拟化安全措施 。

事件 ID 1084 和事件 ID 1988 都标识 源服务器。 此服务器通常是充当生成事件的 DC 的入站复制伙伴的 GC（ 目标服务器，通常也是 GC）。 放弃的对象存在于源服务器上，但不存在于目标服务器上。

拍摄林的当前复制状态的快照，包括当前 DC 标识符（DSA GUIDS 和调用 ID）。 若要获取快照，请在其中一个 DC 的命令提示符处运行以下命令：

repadmin /showrepl *

注释

对于大型拓扑，可以约束命令在特定 DC 上运行。 有关详细信息，请参阅 Repadmin。 还可以运行 repadmin /? 以查看此命令的联机帮助。

对于具有两个 GCs 的林环境，此命令将生成以下示例的类似输出：

Repadmin: running command /showrepl against full DC GC-1.contosotest.com
Default-First-Site-Name\GC-1
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8e294159-140d-41f8-b041-23896e86cb00
DSA invocationID: 9789f50b-6b9f-4632-ba93-dccf617325a2

==== INBOUND NEIGHBORS ======================================

DC=contosotest,DC=com
    Default-First-Site-Name\GC-2 via RPC
        DSA object GUID: 0dd82239-b6e1-4f03-9899-76a80ad9f88a
        Last attempt @ 2026-02-10 15:52:38 was successful.

. . .

Repadmin: running command /showrepl against full DC GC-2.contosotest.com
Default-First-Site-Name\GC-2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 0dd82239-b6e1-4f03-9899-76a80ad9f88a
DSA invocationID: 3e04086d-da99-465f-b82d-e74f31a1caf1

==== INBOUND NEIGHBORS ======================================

DC=contosotest,DC=com
    Default-First-Site-Name\GC-1 via RPC
        DSA object GUID: 8e294159-140d-41f8-b041-23896e86cb00
        Last attempt @ 2026-02-10 16:07:51 was successful.

此示例识别以下 DC：

DC 名称 DSA GUID 当前调用 ID
GC-1 8e294159-140d-41f8-b041-23896e86cb00 3e04086d-da99-465f-b82d-e74f31a1caf1
GC-2 0dd82239-b6e1-4f03-9899-76a80ad9f88a 9789f50b-6b9f-4632-ba93-dccf617325a2

从最新度向量派生复制历史记录

每个 DC 维护一个最新状态向量，用于记录其自身状态和每个复制伙伴的状态。 若要查看域控制器（DC）的最新状态向量，请在 DC 上的命令提示符处运行如下命令：

repadmin /showutdvec GC-1 dc=contosotest,dc=com

对于具有两个 GCS 的林，此命令生成类似于以下示例的输出：

Caching GUIDs.
..
Default-First-Site-Name\GC-2           @ USN     24987 @ Time 2026-02-10 16:56:31
Default-First-Site-Name\GC-1           @ USN     28677 @ Time 2026-02-10 15:07:21
Default-First-Site-Name\GC-1           @ USN     28957 @ Time 2026-02-10 17:03:15
Default-First-Site-Name\GC-2 (retired) @ USN     24580 @ Time 2026-02-10 15:10:48

此输出是 GC-1 的最新状态向量。 此向量记录来自 GC-1 的更改和从 GC-2 复制的更改。 每个 GC 都使用自己的独立 USN 序列。 GC-1 和 GC-2 在 up-to-dateness 向量中各有两个条目。 这项条件表示这两个 GC 都是从备份中还原的。 此输出提供足够的数据来派生以下信息：

  • GC-1 在 15：07：21 和 17：03：15 之间从备份还原。 在 15：07：21 记录的更改是在还原之前记录的最后一项更改。

  • 当 GC-1 在还原之后开始记录更改时，它会在其最新性向量中创建一个新条目。 源自 GC-1 的最新更改发生在 17：03：15。

  • GC-2 在 15：10：48 和 16：56：31 之间从备份还原。 在 15：10：48 记录的更改是在还原 GC-2 之前复制到 GC-1 的最后一项更改。

  • 当 GC-2 在恢复后开始复制更改时，GC-1 在其最新性向量中为其分配了一个新条目。 源自 GC-2 的最新更改发生在 16：56：31，然后被复制到 GC-1。

  • GC-2 的旧条目被标记为“已退役”，以便将其与记录 GC-2 恢复后发生的复制事件的条目区分开来。

    注释

    林中第一个 DC 的第一个条目可能不会标记为“已停用”，即使它不再处于活动状态。

若要对最新状态向量进行略有不同的视图，请运行相同的repadmin命令与/nocache选项一起。 此命令类似于以下示例：

repadmin /showutdvec GC-1 dc=contosotest,dc=com /nocache

这一次，输出中的向量条目使用 GUID，而不是站点和服务器名称。

3e04086d-da99-465f-b82d-e74f31a1caf1 @ USN     24987 @ Time 2026-02-10 16:56:31
8e294159-140d-41f8-b041-23896e86cb00 @ USN     28677 @ Time 2026-02-10 15:07:21
9789f50b-6b9f-4632-ba93-dccf617325a2 @ USN     28958 @ Time 2026-02-10 17:03:59
ae04509e-574a-4487-914c-7c08df548db9 @ USN     24580 @ Time 2026-02-10 15:10:48

可以将这些 GUID 与 DSA 和输出 repadmin /showrepl 中的调用 ID GUID 进行比较。 还可以匹配这组条目和上一个示例之间的 USN 和时间戳。 在此示例中，复制在第一次运行 repadmin /showutdvec后继续。 因此，第二次运行在 USN 和时间戳中产生一些轻微的更改。 这两个示例一起提供了足够的数据来派生以下信息：

  • 每个条目都有唯一的 GUID。 在此示例中，可以将输出的 GUID 版本与输出的站点或服务器名称版本进行比较，以关联 GUID 和 GCS，并标识每个 GC 的两个条目。

  • 若要进一步识别 GUID，请将 GC 和 GUID 组合与输出 repadmin /showrepl进行比较。 从此数据中，可以派生以下信息：

    • GC-1 的最旧条目包含 GC-1 的 DSA GUID。 此条目指示 GC-1 是林中的第一个 DC。 GC-1 的第二个条目包含其当前调用 ID。
    • GC-2 的条目均不使用其 DSA GUID。 GC-2 是林中的第二个 DC。 将 DC 添加到现有林时，Windows立即向其分配调用 ID。 GC-2 的最旧条目使用此第一个调用 ID。

在此示例中，GC-2 还接受来自 GC-1 的入站复制。 运行 repadmin /showutdvec 针对 GC-2 时，GC-2 会生成一个视图，展示其自身的更改以及从 GC-1 复制过来的更改。

Caching GUIDs.
..
Default-First-Site-Name\GC-2           @ USN     25016 @ Time 2026-02-10 17:03:02
Default-First-Site-Name\GC-1           @ USN     28677 @ Time 2026-02-10 15:07:21
Default-First-Site-Name\GC-1           @ USN     28957 @ Time 2026-02-10 17:02:30
Default-First-Site-Name\GC-2 (retired) @ USN     24580 @ Time 2026-02-10 15:10:48

可以比较 GC-1 和 GC-2 的历史数据，说明更新向量是一致的：

条目 由 GC-1 报告 由 GC-2 报告
GC-1、DSA GUID @ USN 28677 @ Time 2026-02-10 15:07:21 @ USN 28677 @ Time 2026-02-10 15:07:21
GC-2，已停用 @ USN 24580 @ Time 2026-02-10 15:10:48 @ USN 24580 @ Time 2026-02-10 15:10:48
条目 GC-1 报告 由GC-2报告
GC-1 @ USN 28958 @ Time 2026-02-10 17:03:59 @ USN 28957 @ Time 2026-02-10 17:02:30
GC-2 @ USN 24987 @ Time 2026-02-10 16:56:31 @ USN 25016 @ Time 2026-02-10 17:03:02

此表显示每个 GC 对另一个的看法略有过时。 GC-1 尚未将更改 28958 复制到 GC-2，GC-2 尚未将更改 24988-25016 复制到 GC-1。 在这种情况下，即使数字不匹配，最高 USN 与最新的时间戳相对应。 此条件为预期状态，下一个复制周期应同步这两个全球编录上的更改。

在复制伙伴数据和最新更新向量中查找已弃用对象的指示器

如果要调查的命名上下文已放弃对象，你可能会看到以下差异（除了“症状”部分描述的错误消息）：

  • 源 GC 的调用 ID（或 DSA GUID）永远不会出现在最新性向量（up-to-dateness vector）中。 此结果指示源 GC 从未完成到目标 GC 的命名上下文的初始完整复制周期。
  • 源 GC 的调用 ID（或 DSA GUID）存在于 up-to-dateness 向量中，但其最新条目的时间戳不是最新的。 此结果指示源 GC 停止复制或已从复制拓扑中删除。

为了帮助确定问题的原因，可以从其他使用受影响 GC 作为复制源的 DC 或 GC 检索最新状态信息。 例如，你可以确定哪些服务器未从受影响的源 GC 获取信息，以及哪些服务器确实有助于隔离网络基础结构问题。

参考

资料来源与适用范围

资料来源
微软官方中文故障文档
适用范围
适用于每种类型的对象。 例如，对具有子 Rid Set 对象的域控制器计算机对象使用此方法将导致进一步的问题。
内容语言
中文；命令、路径和错误标识保留技术原文
本地收录日期
2026-10-26
授权说明
CC BY 4.0

正文与所需资源由本站本地存储。查看来源及更新记录 ↗

请按适用版本和实际日志确认原因；本站没有对每一种系统或设备逐项执行文中的操作。