我最近在一个环境中，在全球100多个地点有120个域控制器。 这个域从Windows 2000时代开始，随着时间的推移而升级， 严格的复制一致性从未被设置为新的DC的默认设置，并且从未在任何DC上启用。 在目录中有一些滞留的对象，因此你会经常看到相当多的冲突对象。
使用repadmin /removelingeringobjects需要知道两件事情：
哪些DC在数据库中有滞留的对象
DC上没有挥之不去的对象用作参考DC。
显然，将来应该设置这个环境，以便所有新的DC都有严格的复制一致性，并且运行repadmin /options * +strict以使得所有当前的DC使用严格的复制一致性， 但是现在会中断复制而不清除对象 。
所以我的问题是这样的：在这样一个大环境下，我不知道哪个区域中心有拖延的对象，哪些区域没有，我怎样才能find一个好的参考区域来使用repadmin /removelingeringobjects ，怎样才能保证在执行严格的复制一致性和中断复制之前，所有120+个DC都干净地留下了对象。 或者，打开严格的模式并观察repadmin /replsum来查看什么是打破和处理它更容易？
这将需要一些时间来解决。
要停止所有复制，请运行：
repadmin /options +DISABLE_OUTBOUND_REPL
在所有区议会。 请记住，上述设置不会阻止手动复制操作，例如运行repadmin /syncall /APed等的pipe理员（您）。但这是一件好事，因为它允许您在重新启用常规之前将所有DC恢复为同步复制。
如果对象存在于ServerA上，Repadmin会确定它是一个滞留对象，而不是ServerB上的ServerB是引用DC。 复制新创build的对象和将更新复制到已经存在的对象之间的区别是关键。 复制新创build的对象=好。 将更新复制到已经存在的对象=好。 将更新复制到目标DC上不存在的对象=错误。
你只需要起泡，冲洗，重复，直到所有的DC匹配你的一个良好的参考DC。 然后在任何地方打开严格的一致性，然后重新启用复制。 是的，您确实会冒着删除在其他远程DC上创build的合法对象的风险，这些DC尚未复制到您的引用DC。
从伟大的“ 活动目录复制模型如何工作 ”文章：
复制一致性设置
如果延迟对象上的属性永不改变，则该对象从不被考虑用于复制。 但是，如果某个属性发生更改，则将该属性视为出站复制。 由于目标域控制器不包含正在复制的属性的对象，因此无法执行更新。 如何解决此问题取决于域控制器上的复制一致性设置。
运行带有SP3的Windows Server 2003或Windows 2000 Server的域控制器上的registry设置提供了一致性值，该值确定域控制器是否复制并重新生成已从其他所有副本中删除的更新对象，或者此类对象的复制是受阻。 在运行带有SP3和Windows Server 2003的Windows 2000 Server的域控制器上，默认设置是不同的。
严格的复制一致性
为避免重新映射已删除对象的问题，在新创build的（未升级的）Windows Server 2003林中运行Windows Server 2003的域控制器在默认情况下阻止入站复制，当它接收到对其没有的对象的更新时。
注意•Active Directory复制使用更新跟踪来区分复制新创build的对象和更新现有对象的属性。 延迟对象的复制是尝试更新目标域控制器无法更新的对象的一个或多个属性，因为该对象不存在。
对象的目录分区中的复制暂停，直到从源域控制器删除延迟的对象，或禁用严格的复制一致性设置。
当ServerB对ServerA说：“嘿，一些更新已经对现有的对象A.” 然后ServerA说：“等一下，我甚至没有对象A，把整个对象发给我！ 如果没有严格的一致性 如果严格一致，ServerA会说：“等一下，你如何期待我更新一个不存在的对象？
要查找域控制器上是否存在延迟对象，请执行以下操作：
repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode
ServerGUID是已知的很好的参考DC。 我知道你已经知道这个…以及如何脚本上面的行来运行它在所有的DC …（ foreach ($DC In $(Get-ADDomain).ReplicaDirectoryServers) { } ）…
你需要一个好的来源DC比较，底线。 如果你没有一个知名的DC源或不知道，你只需要select一个。 它当然应该是一个可写的GC。 这是相对的 – 如果所有的域控制器都同意一个对象的存在，并且该对象的属性…那么它不是一个挥之不去的对象。
foreach($GC In $(Get-ADForest).GlobalCatalogs) { repadmin /removelingeringobjects $_.name 85d158d2-a006-4fff-b1e5-f9b6eaabab2b '$directoryPartition'
这是森林中的每个GC的目录分区与已知的良好的来源，你需要指定为GUID的分区。
然后，当你所有的域控制器再次一致，复制是快乐的…那么你去开始翻转严格的一致性，所有这些。
编辑： 这是微软在这个问题上的派对路线，如果你打电话给他们，他们可能会谈论你。
最后，这可能比修复更麻烦，除非它引起你的问题。 我讨厌这样说，但AD仍然可以正常运作，其中留下了挥之不去的物体。
在无法识别干净DC的情况下，一般原则如下：
for each $sourceDC in $allDCs for each $targetDC in $allDCs if ($targetDC <> $sourceDC) then run repadmin with $sourceDC and $targetDC end if next next
这个过程在这里描述： http : //blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx
但是，看看ReplDiag 。 它通过针对源和目标DC的所有组合运行repadmin来自动执行该过程。 然后跟随/advisory_only来检查是否有任何进一步拖延的对象。