尽管目标域控制器上记录了错误 8606，但阻止复制的问题对象驻留在源域控制器上。 此外，源域控制器或源域控制器的可传递复制伙伴可能未对过去已删除的逻辑删除生存期数进行入站复制。

在以下情况下，可能存在挥之不去的对象：

请记住按对象 GUID 与 DN 路径搜索潜在的延迟对象，以便无论其主机分区和父容器如何，都可以找到对象。 按 objectguid 搜索还会查找已删除对象容器中的对象，而无需使用已删除的对象 LDAP 控件。

NTDS 复制 1988 事件仅标识源域控制器上阻止严格模式目标域控制器传入复制的当前对象。 在 1988 事件中引用的对象“后面”可能还有其他对象，这些对象也挥之不去。

源域控制器上存在滞后对象可防止或阻止严格模式目标域控制器对复制队列中滞后对象后面的“良好”更改进行入站复制。

由于域控制器从其已删除的对象容器中单独删除对象的方式 (垃圾回收守护程序自上次启动) 起每隔 12 小时运行一次，因此导致目标域控制器上出现 8606 错误的对象可能会在下一次垃圾回收清理执行中被删除。 此类中的挥发对象是暂时性的，应在问题开始后 12 小时内自行删除。

有问题的挥之不去的对象可能是管理员或应用程序有意删除的对象。 将其纳入解决计划，并注意重新更新对象，尤其是有意删除的安全主体。 解决方案

确定林范围 TombStoneLifeTime 设置的当前值。

repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root domain,DC=TLD" /atts:tombstonelifetime  
请参阅 Microsoft 知识库中以下文章中的“删除的逻辑删除生存期和复制”部分：

910205有关Windows Server Active Directory林中挥之不去对象的信息。
对于记录 8606 错误的每个目标域控制器，筛选 NTDS 复制事件 1988 上的目录服务事件日志。
收集 NTDS 复制事件 1988 中引用的每个 唯一 对象的元数据。
在引用新对象的目标域控制器上记录的每个 1988 事件中，填充下表：
对象 DN 路径
对象 GUID
实时或删除？
LastKnownParent
IsDeleted 值
可以通过直接从 NTDS 复制 1988 事件（记录 1988 事件或 8606 复制状态）的目标域控制器的目录服务事件日志中记录的字段读取值来填充此表的第 1 到 5 列。
LastKnownParent 和 IsDeleted 列的日期戳可以通过运行 repadmin /showobjmeta 并引用在 NTDS 复制 1988 事件中引用的 对象的 objectguid 来确定。 为此，请使用以下语法：
repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988 event>"
LastKnownParent 的日期戳标识删除对象的日期。 IsDeleted 的日期戳指示上次删除或重新更新对象。 版本号指示上次修改是删除还是重新更新对象。 IsDeleteted 值为 1 表示初始删除。 大于 1 的奇数值表示至少删除一次后重新恢复。 例如， isDeleted 值为 2 表示 (版本 1) 中删除的对象，随后 (版本 2) 中删除或重新删除。 IsDeleted 的后续偶数值表示对象的后续重新更新或取消删除。
根据 1988 事件中引用的对象元数据选择适当的操作。
错误 8606/NTDS 复制事件 1988 事件最常见的原因是长期复制失败，这些失败阻止域控制器对林中所有原始删除项的入站复制知识。 这会导致一个或多个源域控制器上的对象挥之不去。
查看在“解决方法”部分的步骤 4 中创建的表中列出的对象的元数据。
如果 1988 事件中的对象) 源域控制器上的 ( (实时运行，但在目标域控制器上删除 (超过逻辑删除生存期到期时间) ) ，请参阅“删除延迟对象”和“”。处于此条件的对象必须由管理员手动删除。
如果目标域控制器上的系统时间向前跳转，则已删除的对象可能已从已删除的对象容器中提前清除。 查看“检查时间跳跃”部分。
如果在 1988 事件中引用的对象存在于源域控制器的已删除对象容器中，并且其删除日期正好在逻辑删除生存期到期的顶点，则对象由一个或多个目标域控制器的垃圾回收回收，并且 将由 垃圾回收在源域控制器上的下一个垃圾回收间隔 (即， 挥之不去的对象是 暂时性的) ，你可以选择。 等待下一个垃圾回收执行删除对象，或在源域控制器上手动触发垃圾回收。 请参阅“手动启动垃圾回收”。引入第一个域控制器或部分属性集中的任何更改都可能导致这种情况。
如果在 repadmin /showobjmeta 1988 事件中引用的 对象的输出的 LastKnownParent 值为 1，则表示该对象已被删除，IsDeleted 值为 2 或某个其他偶数值，并且 IsDeleted 的日期戳位于与 LastKnownParent 的日期戳不同的墓碑生存期天数的顶点， 然后，对象已被删除，然后取消删除/身份验证还原，而该对象仍在源域控制器上处于活动状态，但已由目标域控制器的垃圾回收回收日志记录错误 8606/事件 1988。 请参阅在 TSL 过期的尖刻处重新恢复

如何删除挥之不去的对象
虽然存在许多方法来删除挥之不去的对象，但常用的主要工具有三种： repadmin.exe、Lingering Object Liquidator (LoL) 和 repldiag。
挥之不去的对象清盘器 (LoL) 
清理挥之不去对象的最简单方法是使用 LoL。 开发 LoL 工具有助于自动执行针对 Active Directory 林的清理过程。 该工具基于 GUI，可以扫描当前 Active Directory 林，并检测和清理挥之不去的对象。 该工具可在 Microsoft 下载中心使用。
Repadmin
repadmin.exe 中的以下两个命令可以从目录分区中删除挥之不去的对象：
repadmin /removelingeringobjects

repadmin /rehost
命令 repadmin /removelingeringobjects 可用于从源域控制器上的可写目录分区和只读目录分区中删除挥之不去的对象。 语法如下所示：
repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]
<> Dest_DSA_LIST是域控制器的名称，其中包含 (在 NTDS 复制 1988 事件) 引用的源域控制器等延迟对象。

<源 DSA GUID> 是托管目录分区的可写副本的域控制器的名称，该副本包含Dest_DSA_LIST>中的<域控制器具有网络连接的延迟对象。 要清理 (命令中指定的第一个 DC) 必须能够直接连接到 DC 上的端口 389，该端口托管目录分区的可写副本 (命令) 中指定的第二个 DC。
<NC> 是目录分区的 DN 路径，怀疑该分区包含挥之不去的对象，例如在 1988 事件中指定的分区。
命令 repadmin /rehost 可用于从域控制器中删除托管域目录分区 只读 副本的 linging-objects 域控制器。 语法如下所示：
repadmin /rehost DSA <Naming Context> <Good Source DSA Address>
DSA 是承载非本地域的只读域目录分区的域控制器的名称。 例如，root.contoso.com 中的 GC 可以重新托管其 child.contoso.com 的只读副本，但不能重新托管 root.contoso.com。

<命名上下文> 是位于全局目录中的只读域目录分区的 DN 路径。
<良好的源 DSA 地址>是托管命名上下文>的可写副本的域控制器的名称<。 域控制器必须可用于 DSA 计算机的网络。
如果 repadmin 未删除在 1988 事件中报告的挥发对象，请评估源域控制器上的对象是否是在 USN 间隙中创建的，或者源域控制器的最新向量中是否不存在发起域控制器的对象。
Repldiag
还可以使用 repldiag.exe删除挥之对象。 此工具可自动执行该过程 repadmin /removelingeringobjects 。 使用重新pldiag 从林中删除挥之不去的对象与运行 repldiag /removelingeringobjects一样简单。  但是，通常最好在较大环境中对过程进行一些控制。  选项 /OverRideReferenceDC 允许你选择用于清理的 DC。  使用 选项 /outputrepadmincommandlinesyntax ，可以使用 repadmin 查看林范围的清理方式。
启动以下 TechNet 按需实验室，针对此和其他 AD 复制错误进行引导式故障排除实践：
在实验室中，使用 repadmin 和 repldiag.exe 删除挥之不去的对象

排查 Active Directory 复制错误

在本实验室中，你将逐步完成常见 Active Directory 复制错误的故障排除、分析和实现阶段。 你将结合使用 ADREPLSTATUS、 repadmin.exe和其他工具来对五个 DC 三域环境进行故障排除。  实验室中遇到的 AD 复制错误包括 -2146893022、1256、1908、8453 和 8606。
每天监视 Active Directory 复制运行状况
如果错误 8606/事件 1988 是由域控制器在最后一个逻辑删除生存期天数中未能复制 Active Directory 更改引起的，请确保今后每天都会监视 Active Directory 复制运行状况。 可以使用专用监视应用程序或查看一个廉价但有效的选项的输出来监视复制运行状况，以在电子表格应用程序（如 Microsoft Excel）中运行 repadmin /showrepl * /csv 命令。  (请参阅 Microsoft 知识库文章910205) 中的“方法 2：使用命令行监视复制 ”。
在逻辑删除生存期天数的 50% 内未进行入站复制的域控制器应放入一个watch列表中，以便获得管理员的优先关注，以使复制正常运行。 如果无法成功复制的域控制器未在 TSL 的 90% 范围内复制，则应对其进行强制降级。
目标域控制器上出现的复制失败可能是由目标域控制器、源域控制器或基础网络和 DNS 基础结构引起的。
检查时间跳跃
若要确定是否发生时间跳跃，检查事件和诊断日志中的日期戳， (事件查看器、repadmin /showrepsnetlogon 日志、dcdiag 报告目标域控制器上记录错误 8606/NTDS Replication 1988 事件的) ：
操作系统发布之前的日期戳 (例如，2008 年 CY 2008 中发布的 OS 的 2003 年日期戳) 
在林中安装操作系统之前的日期戳
将来的日期戳
没有在给定日期范围内记录的事件
Microsoft 支持部门团队在过去和将来看到生产域控制器上的系统时间错误地跳跃了小时、天、周、年，甚至数十年。 如果发现系统时间不准确，则应更正它，然后尝试确定时间跳跃的原因以及可以做些什么来防止未来不准确的时间与更正错误时间。 可能的问题包括：
林根 PDC 是使用外部时间源配置的吗？
引用联机时间源是否在网络上可用并在 DNS 中可解析？
Microsoft 或第三方时间服务是否正在运行且处于无错误状态？
域控制器角色计算机是否配置为使用 NT5DS 层次结构到源时间？
Microsoft 知识库文章中描述的时间回滚保护是否 884776 到位？
系统时钟在虚拟主机计算机上的域控制器上的 BIOS 中是否具有良好的电池和准确的时间？
虚拟主机和来宾计算机是否根据托管制造商的建议配置为源时间？

Microsoft 知识库文章 884776 介绍了帮助保护域控制器免受“侦听”无效时间示例的步骤。 有关 MaxPosPhaseCorrection 和 MaxNegPhaseCorrection 的详细信息，请参阅 W32Time 博客文章 Windows 时间服务。
使用 repadmin /removelingeringobjects /advisorymode检查是否存在挥之不去的对象，然后根据需要将其删除。
根据需要放宽“允许使用不同的和损坏的伙伴进行复制”。
如何手动启动垃圾回收
有多个选项可用于在特定域控制器上手动触发垃圾回收：
运行“repadmin /setattr ”“ ”“ doGarbageCollection add 1”
运行 LDIFDE /s <server> /i /f dogarbage.ldif，其中 dobarbage.ldif 包含文本：
changetype：modify

replace： DoGarbageCollection

dogarbagecollection： 1

最后一个“-”字符是 .ldif 文件的 必需 元素。
在 TSL 到期的尖头重新恢复
对于此条件的存在， repadmin /showobject "<GUID=object guid for object in 1988 event>" 应报告对象在目标域控制器上“找不到”，但在源域控制器上处于活动状态，并且是已删除或未删除的对象。
对源域控制器上的键字段 repadmin /showobjmeta 的评审应报告以下内容是正确的：LastKnownParent 的值为 1，并且其日期戳处于过去 TSL 天的尖点。 其日期戳指示对象的删除日期。
IsDeleted 的版本号为 2 (或) 的另一个偶数值，其中版本 1 定义了原始删除，版本 2 是还原/重新更新。 “isDeleted=2”的日期戳应晚于 LastKnownParent 的上次更改日期的 TSL 天数。
评估有问题的对象是应保持活动对象还是已删除的对象。 如果 LastKnownParent 的值为 1，则表示某个内容或某人删除了对象。 如果这不是 意外 删除，则很可能从具有对象的实时副本的任何源域控制器中删除对象。
如果对象应存在于所有副本上，则选项如下所示：
在不包含 对象的严格模式目标域控制器上启用松散复制。
强制降级已垃圾回收对象的域控制器。
删除对象，然后重新创建它。
启动以下 TechNet 按需实验室，针对此和其他 AD 复制错误进行引导式故障排除实践：
排查 Active Directory 复制错误

在本实验室中，你将逐步完成常见 Active Directory 复制错误的故障排除、分析和实现阶段。 你将结合使用 ADREPLSTATUS、 repadmin.exe和其他工具来对五个 DC 三域环境进行故障排除。 实验室中遇到的 AD 复制错误包括 -2146893022、1256、1908、8453 和 8606。
对象挥之的原因
原因 1：源域控制器向目标域控制器上的垃圾回收已回收的对象发送更新，因为源域控制器在 TSL 已用天数内脱机或复制失败
域 CONTOSO.COM 包含同一域中的两个域控制器。 墓碑生存期 = 60 天。 在两个域控制器上都启用了严格复制。 DC2 遇到主板故障。 同时，DC1 在接下来的 90 天内每天对过时的安全组进行原始删除。 脱机 90 天后，DC2 会收到更换的主板并启动，然后在所有用户帐户上发起 DACL 或 SACL 更改 ，然后 入站复制有关从 DC1 发起删除的信息。 DC1 记录 DC2 脱机前 30 天内在 DC1 上清除的更新安全组的 8606 错误。
原因 2：源 DC 在 TSL 过期的尖点处向已通过严格模式目标 DC 的垃圾回收回收的对象发送更新
域 CONTOSO.COM 包含同一域中的两个域控制器。 墓碑生存期 = 60 天。 在两个域控制器上都启用了严格复制。 DC1 和 DC2 每 24 小时复制一次。 DC1 每天发起删除。 DC1 已就地升级。 这会在配置和可写域分区中的所有对象上标记新属性。 这包括当前位于已删除对象容器中的对象。 其中一些在60天前被删除，现在正处于墓碑到期的顶点。 DC2 通过垃圾回收回收一些对象，这些对象在复制计划使用 DC2 打开之前 TSL 几天前删除。 记录错误 8606，直到 DC1 通过垃圾回收来回收阻塞对象。
对部分属性集的任何更新都可能导致临时延迟对象，这些对象会在源域控制器在 TSL 过期 (将第一个 W2K8 R2 域控制器添加到现有林) 之后自行清除。
原因 3：目标域控制器上的时间跳跃过早加快了目标域控制器上已删除对象的垃圾回收速度
域 CONTOSO.COM 包含同一域中的两个域控制器。 墓碑生存期 = 60 天。 在两个域控制器上都启用了严格复制。 DC1 和 DC2 每 24 小时复制一次。 DC1 每天发起删除。 DC1 (但 DC2) 使用的引用时间源将前滚到日历年 2039。 这会导致 DC2 在 CY2039 中使用系统时间。 这会导致 DC1 过早地删除当前从其已删除的对象容器中删除的对象。 同时，DC2 源自对 DC2 上的用户、计算机和组的属性的更改，这些属性在 DC2 上处于活动状态，但已删除，现在过早地垃圾回收在 DC1 上。 DC1 下次对过早删除的对象进行入站复制更改时，将记录错误 8606。
原因 4：对象在 TSL 过期的尖点重新更新
域 CONTOSO.COM 包含同一域中的两个域控制器。 墓碑生存期 = 60 天。 在两个域控制器上都启用了严格复制。 DC1 和 DC2 每 24 小时复制一次。 DC1 每天发起删除。 包含用户、计算机和组的 OU 会意外删除。 过去在 TSL 的尖刻处进行的系统状态备份在 DC2 上进行了身份验证还原。 备份包含已在 DC2 上处于活动状态但已通过 DC1 上的垃圾回收删除和回收的对象。
原因 5：触发 8606 日志记录的 USN 气泡
假设在 USN 气泡中创建对象的方式不会进行出站复制，因为目标域控制器“认为”它具有对象，因为该气泡。 现在，在气泡关闭后，更改开始再次复制后，将在源域控制器上为该对象创建更改，并显示为目标域控制器的挥之不去的对象。 目标控制器记录事件 8606。
有关发起删除的端到端复制知识的要求
Active Directory 域控制器支持多主数据库复制，其中保存可写分区) 的任何域控制器 (都可以创建、更改或删除对象或属性， (值) 。 对象/属性删除的知识由发起域控制器和任何域控制器持久保存，这些域控制器在 TSL 天内传入了源删除的复制知识。  (请参阅 Microsoft 知识库文章 216996 和 910205) 
Active Directory 需要从所有分区持有者进行端到端复制，以传递方式将所有目录分区的所有原始删除复制到所有分区持有者。 在滚动 TSL 天数内入站复制目录分区失败会导致对象挥之不去。 挥之不去的对象是由至少一个域控制器有意删除的，但错误地存在于目标域控制器上，而目标域控制器上没有入站复制所有唯一删除的暂时性知识。
如果需要 Microsoft 支持方面的帮助，建议按照 使用 TSS 收集 Active Directory 复制问题的信息中所述的步骤收集信息。