主页 / server / 问题 / 529603
Accepted
MDMarra
Asked: 2013-08-09 06:23:25 +0800 CST

长时间在大量DC上设置-strict时如何正确删除延迟对象？

  • 772

我最近在一个环境中，在全球 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什么中断并处理它？

windows

2 个回答

  1. Best Answer

    这需要一些时间来修复。

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

    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 或带有 SP3 的 Windows 2000 Server 的域控制器上的注册表设置提供了一个一致性值，该值确定域控制器是否复制并重新激活已从所有其他副本中删除的更新对象，或者此类对象的复制是否正常。被封锁。在运行带有 SP3 的 Windows 2000 Server 和 Windows Server 2003 的域控制器上，默认设置是不同的。

    严格的复制一致性

    为避免重新激活已删除的对象时出现问题，在新创建的（未升级的）Windows Server 2003 林中运行 Windows Server 2003 的域控制器在收到对其没有的对象的更新时默认阻止入站复制.

    注意 • Active Directory 复制使用更新跟踪来区分复制新创建的对象和更新现有对象的属性。延迟对象的复制是尝试更新目标域控制器无法更新的对象的一个​​或多个属性，因为该对象不存在。

    在对象的目录分区中停止复制，直到从源域控制器中删除延迟对象或禁用严格复制一致性设置。

    当服务器 B 对服务器 A 说：“嘿，对现有对象 A 进行了一些更新。” 然后 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 仍然可以在其中带有挥之不去的对象时正常运行。

    • 11

  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

    但是，看看ReplDiag。repadmin它通过针对源和目标 DC 的所有组合为您运行来自动化该过程。然后它会跟进/advisory_only以检查是否有任何进一步的挥之不去的对象。

    • 4

相关问题