长时间在大量DC上设置-strict时，如何正确清除残留的对象？

我最近在一个环境中，在全球100多个站点中有120个域控制器。该域始于Windows 2000时代，并且随着时间的推移进行了升级，因此从未将严格的复制一致性设置为新DC的默认值，也从未在任何DC上启用它。目录中有许多对象，因此您经常会看到很多冲突的对象。

使用repadmin /removelingeringobjects需要了解两件事：

1. 哪些DC在数据库中保留了对象

2. 一个没有缠结对象的DC可用作参考DC。

显然，将来应该设置此环境，以便所有新的DC都具有严格的复制一致性，并repadmin /options * +strict应运行以使所有当前的DC使用严格的复制一致性，但是这将立即破坏复制而无需清理对象。

因此，我的问题是这样的：在如此庞大的环境中，我将不知道哪个DC残留有对象，哪些DC没有残留的对象，如何确定repadmin /removelingeringobjects要使用的良好参考DC ，以及如何确保所有120+ DC在强制执行严格的复制一致性并中断复制之前清除了残留的对象？或者，打开严格模式并观察repadmin /replsum有什么坏处并对其进行处理是否更容易？

这将需要一些时间来解决。

要停止所有复制，请运行：

repadmin /options +DISABLE_OUTBOUND_REPL

在所有DC上。请记住，上述设置不会阻止手动复制操作，例如运行admin（您）repadmin /syncall /APed等。但这是一件好事，因为它允许您在重新启用常规复制之前使所有DC完全恢复同步。

如果对象在ServerA上但在ServerB上不存在，则Repadmin确定它是一个挥之不去的对象，其中ServerB是参考DC。关键在于复制新创建的对象与将更新复制到现有对象之间的区别。复制新创建的对象=良好。将更新复制到已经存在的对象=良好。将更新复制到目标DC上不存在的对象=错误。

您只需要起泡，冲洗，重复，直到所有DC与您的一个良好参考DC匹配。然后在所有地方打开严格一致性，然后重新启用复制。是的，您确实要删除在其他远程DC上创建的合法对象，这些对象尚未复制到参考DC。

摘自出色的“ Active Directory复制模型的工作原理 ”文章：

复制一致性设置

如果挥之不去的对象的属性永不更改，则永远不会考虑该对象进行复制。但是，如果属性更改，则该属性将考虑用于出站复制。因为目标域控制器不保存要复制的属性的对象，所以无法执行更新。如何解决此情况取决于域控制器上的复制一致性设置。

运行Windows Server 2003或Windows 2000 Server SP3的域控制器上的注册表设置提供了一个一致性值，该值确定域控制器是否复制并重新激活已从所有其他副本中删除的更新对象，或者是否对这些对象进行复制。受阻。默认设置在运行带有SP3的Windows 2000 Server和Windows Server 2003的域控制器上有所不同。

严格的复制一致性

为避免使已删除的对象恢复活动的问题，默认情况下，在新创建（未升级）的Windows Server 2003林中运行Windows Server 2003的域控制器在收到对其没有对象的更新时会阻止入站复制。

注意•Active Directory复制使用更新跟踪来区分复制新创建的对象和更新现有对象的属性。挥之不去的对象的复制是尝试更新目标域控制器由于对象不存在而无法更新的一个或多个对象的属性。

在对象的目录分区中，复制将暂停，直到从源域控制器中删除了残留的对象，或者禁用了严格的复制一致性设置。

当ServerB对ServerA说：“嘿，已经对现有的objectA进行了一些更新。” 然后ServerA说：“等等吗？我什至根本没有objectA。将整个对象发送给我！” 如果没有严格的一致性。如果具有严格的一致性，ServerA会说：“等等？您希望我如何更新不存在的对象？弯腰！”

要查找域控制器上是否有挥之不去的对象：

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode 

ServerGUID是已知的良好参考DC。我知道您已经知道这一点...以及如何编写以上代码行以在所有DC上运行它...（foreach ($DC In $(Get-ADDomain).ReplicaDirectoryServers) { }）...

您需要一个良好的源DC与底线进行比较。如果您没有已知的好来源DC或不知道，则只需选择一个即可。当然，它应该是可写的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。通过repadmin针对源DC和目标DC的所有组合为您运行，它可以自动执行该过程。然后跟进/advisory_only检查是否还有其他遗留的对象。