☰

当大量 DC 长期设置 -strict 时，如何正确删除残留对象？

tag-icon • tag-icon windows active-directory
当大量 DC 长期设置 -strict 时，如何正确删除残留对象？

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

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

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

  2. 不具有任何延迟对象以用作参考 DC 的 DC。

显然，将来应该设置此环境，以便所有新的 DC 都强制执行严格的复制一致性，并且repadmin /options * +strict应运行以使所有当前 DC 使用严格的复制一致性，但如果未清理对象，复制将会中断。

因此，我的问题是：在如此庞大的环境中，我不知道哪些 DC 有延迟对象，哪些 DC 没有，如何识别要使用的良好参考 DC ，以及如何确保所有 120 多个 DC 都没有延迟对象，然后强制执行严格的复制一致性并中断复制？ 或者，打开严格模式并观察中断并处理它repadmin /removelingeringobjects是否更容易？repadmin /replsum

答案1

这需要一些时间来解决。

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

repadmin /options +DISABLE_OUTBOUND_REPL

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

如果该对象存在于 ServerA 上但不存在于 ServerB 上（其中 ServerB 是参考 DC），则 Repadmin 确定它是一个延迟对象。复制新创建的对象和复制已存在对象的更新之间的区别是关键。复制新创建的对象 = 好。复制已存在对象的更新 = 好。复制目标 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 仍然可以在有残留对象的情况下正常运行。

答案2

在无法识别干净的 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

然而，看看复制诊断repadmin。它通过针对源和目标 DC 的所有组合为您运行来自动化该过程。然后，它会跟进/advisory_only检查是否存在任何其他残留对象。

相关内容