在本文的上半部分中，我们介绍了延迟对象（lingering object）的定义和危害，下面介绍如何删除这些对象。

　　防止延迟对象

　　当然，最可取的办法，是在一开始就防止延迟对象的创建。有一个注册表项叫做StrictReplicationConsistency,我们称之为严格模式，该模式可以保护域控制器不受延迟对象的侵害。

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters
ValueName = Strict Replication Consistency
Data Type = Reg_DWORD
Value Data = 1 = Strict 0=Loose

　　如果值被设为1，就会防止伙伴将延迟对象复制给该域控制器。因此，如果每一个域控制器都设为严格模式，就可以防止延迟对象向它们传播。然而，如果值被设为0，那么意味着为松散模式，就会允许延迟对象的传播。

　　在Windows 2000 Server中，StrictReplicationConsistency的默认值是松散一致性。这个必须要注意，因为如果您有一个域从Windows 2000升级到Windows Server 2003，并且这个值仍然是默认的松散模式，那么升级后，该域仍然会在处于松散模式。另一方面，如果您不是从Windows 2000 Server中升级，而是安装了一个干净的Windows Server 2003域，那么默认会处于严格模式。

　　我已经遇到过一些由于没有花时间去检查这个注册表项，而受到延迟对象侵害的组织。所以，再一次重申，您应该在正常操作时，总是将StrictReplicationConsistency的值定为1。仅仅是在移除延迟对象的过程中，才可以被设为0。

　　同时，当在域控制器1（DC1）上启动了严格模式，然后域控制器2（DC2）试图去复制已经在DC1上被删除的对象时，DC1和DC2之间的复制是不允许的。而且不仅仅是复制这个对象，而是两个域控制器之间的所有复制都不被允许。

　　确定在域中存在延迟对象

　　不同的事件会要么表明活动目录延迟对象的存在，要么发出它们可能会存在的警告。在目录服务事件中有几个事件可能会被记录。

　　事件ID 1864

　　这个事件会表明它们是否是延迟对象。需要注意，里面包括了一个计数器，记录在一天、一周、一个月、两个月、或者墓碑生命期内，有多少与控制器没有进行复制。最后一个条目很重要。不幸地是，这个事件不会告诉我们在墓碑生命期内没有进行复制的域控制器的名字。

Source NTDS Replication
Event ID 1864
User NT AUTHORITYANONYMOUS LOGON
This is the replication status for the following directory partition on the local domain controller.
Directory partition:
DC=DomainDnsZones,DC=corp,DC=com

　　本地域控制器最近没有从很多域控制器那里获取复制信息。对域控制器的计数将分别在如下的时间间隔内进行显示。

　　超过24小时
　　2
　　超过一周
　　2
　　超过一个月
　　1
　　超过两个月
　　1
　　超过一个墓碑生命期
　　1
　　墓碑生命期（天）
　　60

　　事件 2042(错误)—源：NTDS复制

　　这表明严格复制被启用，“源域控制器（source DC）”在墓碑生命期内，没有进行复制，然后当前试图去进行复制，因此，复制已经在源头被禁用了。事件以CName(别名)格式的DNS记录提供了源的全局统一标识符（Global unique identifier GUID）：982a942e-40e4-4e3c-8609-bae0cfd2affb._msdcs.corp.net。通过查看DNS管理单元中_msdcs区域的别名记录，可以很容易地找到域控制器的友好名称。

　　事件ID 1388(错误)—源：NTDS复制

　　描述：另外一个域控制器试图将一个在本地活动目录数据库中不存在的对象复制到这个域控制器。在这个域控制器上，可能已经删除了该对象，并进行了垃圾收集（从对象被删除开始，已经超过一个墓碑生命期或者更多的时间）

　　事件 1988（错误）—源：NTDS复制

　　描述：活动目录复制面临在如下的分区中存在，但在本地域控制器活动目录数据库中已经被删除的对象。由于源域控制器包含一个在本地域控制器活动目录数据库中不存在的延迟对象，所以对这一事件进行了记录。

Source DC (Transport-specific network address):
4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.Corp.com

　　因为它们是在各个域控制器中被独立记录的，您可以使用像微软EventComb这样的工具，这个工具是账号锁定工具（the Account Lockout tools）的一部分。事件1864和1862表明了延迟对象的存在。

　　如果由于严格一致性，已经禁止复制时，您运行命令Repadmin /showrepl，会看到如下的格式化输出：

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

DC=Wtec,DC=adapps,DC=hp,DC=com
    BracknellGSE-EXCH3 via RPC
        DC object GUID: 00b71e7b-46e3-4b2e-8eef-c05f08d2ab82

******* 753 CONSECUTIVE FAILURES since 2008-12-15 11:52:10
Last error: 8614 (0x21a6):

　　从这个错误中，可以明显地看到，域控制器被保护以免受到过期的域控制器的危害。作为定期对活动目录进行健康维护的一部分，手动或者以脚本的方式运行下面的命令是一个不错的主意：

Repadmin/replsum /bysrc /bydest /sort:delta
Source DC largest delta fails/total %% error
WTEC-DC2 >60 days 105 /105 100  (1722)The RPC server…
WTEC-DC1 41m:26s  0/20  0 
GSE-EXCH3  08m:59s  0/6  0 
WTEC-DC6  08m:34s  0/6  0 

　　通过输出可以看到，对于当前运行命令的域控制器，上一次所有其它的域控制器完成与该域控制器的复制已经过去了多长时间。当然，对WTEC-DC2的红色标记告诉我们，该域控制器已经有超过60天（墓碑生命期）没有与我们的目标域控制器进行复制了。

　　在这种情况下，需要做的是置之不理。幸运的话，不会进行复制，否则，如果严格一致性没有开启，那么我们会让源域控制器受到延迟对象的威胁。对WTEC-DC1采取的措施是将其从网络中移除，进行手动降级，清理活动目录中的服务器对象，等待复制，然后重新升级。

　　移除活动目录中的延迟对象

　　如果您发现了上面提到的事件和错误，那么就需要对延迟对象进行清理。您可以参考右面方框中的微软文章，以获取详细的信息，但这里会进行一个快速的介绍：

　　第一步是将StrictReplicationConsistency的注册表值设置为=1（严格）。如果还没有设置，请一定检查一下 - 不要假设您已经知道它的值是什么。可以使用Repadmin，对所有域控制器上的值进行设置。

repadmin /regkey DC_LIST +strict

　　简单地对DC_List里面所包含的域控制器进行设置。

　　在Windows Server 2003 SP1（以及之后的版本）支持工具中，Repadmin有一个很友好的开关为RemoveLingeringObjects:

/removelingeringobjects [/ADVISORY_MODE]

　　这表示一个一般性的清除延迟对象操作。参数为：

Dest_DC_List – list of DCs to operate on
Source DC GUID – the DSA GUID of a reliable DC (preferably the PDC)
NC – Naming context of the domain the lingering objects exist in.
/ADVISORY_MODE – identifies what will happen when you execute the command for real.

　　所以一个示例命令为：

C:>Repadmin /removeLingeringObjects wtec-dc1 f5cc63b8-cdc1-4d43-8709-22b0e07b48d1 dc=wtec,dc=adapps,dc=hp,dc=com

RemoveLingeringObjects sucessfull on wtec-dc1.

　　在运行Repadmin命令后，检查之前描述的事件日志，以确保延迟对象已经被移除。

　　很明显，可以容易地，在一个有少许域控制器的单域林中，发现警告标志，并运行Repadmin命令去移除延迟对象。可是，在一个有多个域的大林中，这就没那么容易了。比如，延迟对象可能只在森林的一些域控制器的子集中存在。那么就需要在森林中为每一个命名上下文运行这个命令。

　　在一个即将发表的文章中，我会介绍一些，在大的多域的森林中，找到并移除延迟对象的高级技术，其中包括一些高级命令和脚本方法。