windows – 如果长时间在大量DC上设置-strict,如何正确删除延迟

我最近在一个环境中,在全球100多个站点中有120个域控制器.这个域开始于 Windows 2000时代并且随着时间的推移而升级,因此 strict replication consistency从未被设置为新DC的默认值,并且从未在任何DC上启用.目录中存在延迟对象,因此您经常会看到相当数量的冲突对象.

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

>哪些DC在数据库中具有延迟对象
>没有延迟物体的DC用作参考DC.

显然,在将来,应该设置此环境,以便所有新DC都具有强制执行的严格复制一致性,并且应运行repadmin / options * strict以使所有当前DC使用严格的复制一致性,但这将在不清除对象的情况下中断复制.

所以,我的问题是：在如此庞大的环境中,我不知道哪些DC有延迟对象,哪些没有,我怎样才能找到一个好的参考DC用于repadmin / removelingeringobjects使用,我怎样才能确保在强制执行严格的复制一致性和破坏复制之前,所有120个DC都没有拖延的对象？或者,是否更容易打开严格模式并观看repadmin / replsum以查看哪些内容并处理它？

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

repadmin /options +DISABLE_OUTBOUND_REPL

在所有DC上.请记住,上面的设置并不能阻止手动复制操作,例如运行repadmin / syncall / APed等的管理员(你).但这是一件好事,因为它允许你在重新启用常规之前完全恢复所有DC的同步复制.

如果对象存在于ServerA上而不是ServerB上,则Repadmin确定它是一个延迟对象,其中ServerB是参考DC.复制新创建的对象和复制现有对象的更新之间的区别是关键.复制新创建的对象=好.复制现有对象的更新=好.将更新复制到目标DC上不存在的对象=坏.

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

从伟大的“How the Active Directory Replication Model Works”文章：

Replication Consistency Setting

If the attributes on a lingering object never change,the object is
never considered for replication. However,if an attribute changes,
the attribute is considered for outbound replication. Because the
destination domain controller does not hold the object for the
attribute that is being replicated,an update cannot be performed. How
this condition is resolved depends on the replication consistency
setting on the domain controller.

A registry setting on domain controllers that are running Windows
Server 2003 or Windows 2000 Server with SP3 provides a consistency
value that determines whether a domain controller replicates and
reanimates an updated object that has been deleted from all other
replicas,or whether replication of such objects is blocked. The
default settings are different on domain controllers that are running
Windows 2000 Server with SP3 and Windows Server 2003.

Strict Replication Consistency

To avoid problems with reanimating objects that have been deleted,a
domain controller that is running Windows Server 2003 in a newly
created (not upgraded) Windows Server 2003 forest blocks inbound
replication by default when it receives an update to an object that it
does not have.

Note ? Active Directory replication uses update tracking to
differentiate between replicating a newly created object and updating
an attribute for an existing object. Replication of a lingering object
is an attempt to update an attribute or attributes of an object that
the destination domain controller cannot update because the object
does not exist.

Replication is halted in the directory partition for the object until
the lingering object is removed from the source domain controller or
the strict replication consistency setting is disabled.

当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.

然后,在您再次获得所有域控制器之后,所有人都同意,并且复制很开心……然后您开始在所有域控制器上严格保持一致性.

编辑：This是微软关于这个问题的党派路线,他们可能会告诉你的是你打电话给他们.

最后,这可能比修复它更麻烦,除非它导致你的问题.我不想这么说,但是AD仍然可以正常运行,其中包含挥之不去的物体.

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!