长时间在大量DC上设置-strict时，如何正确删除挥之不去的对象？

Question

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

使用repadmin /removelingeringobjects需要知道两件事：

1. 哪些 DC 有数据库中的延迟对象

2. 一个 DC，上面没有拖延的物体可用作参考 DC。

显然，在未来，这个环境应该设置为所有新的 DC 都强制执行严格的复制一致性，并且repadmin /options * +strict应该运行以使所有当前的 DC 使用严格的复制一致性，但这会破坏现在的复制而不清理对象。

所以，我的问题是：在如此庞大的环境中，我不知道哪些 DC 有滞留对象，哪些没有，我如何确定一个好的参考 DC 以repadmin /removelingeringobjects供使用，以及我如何确保所有 120+在强制执行严格的复制一致性和中断复制之前，DC 是否清除了延迟对象？或者，是否更容易打开严格模式并repadmin /replsum查看中断并处理它？

Answer 1

这将需要一些时间来修复。

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

repadmin /options +DISABLE_OUTBOUND_REPL

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

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

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

来自伟大的“ Active Directory 复制模型的工作原理”文章：

复制一致性设置

如果延迟对象的属性永远不会改变，则永远不会考虑复制该对象。但是，如果某个属性发生更改，则会考虑将该属性用于出站复制。由于目标域控制器不保存正在复制的属性的对象，因此无法执行更新。如何解决这种情况取决于域控制器上的复制一致性设置。

运行 Windows Server 2003 或 Windows 2000 Server SP3 的域控制器上的注册表设置提供了一个一致性值，用于确定域控制器是否复制并重新激活已从所有其他副本中删除的更新对象，或者此类对象的复制是否阻止。在运行 Windows 2000 Server SP3 和 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 仍然可以正常运行，其中有挥之不去的对象。