询问者
在总部dc上对ji_wh用户解除禁用,20分钟后仍未复制到dc02

问题
全部回复
-
尊敬的客户,您好!
感谢您在我们的TechNet论坛发帖。
根据您的案子描述,我得到的案子情况为:总部DC上所做的更改(即禁用用户账户ji_wh)未能成功复制到另一个域控制(即DC02)。
从我们提供的信息,我们不能完全判断您的AD环境是否存在AD复制问题。那么为了更好地了解我们的AD环境以及是否存在AD复制问题,请确认以下信息:
第一,环境信息:
1. 我们AD环境所在的林里有几个域?
2. 我们这个林里的域控制器分布在几个sites里?每个site分别有几个域控制器?
3. 我们提到的总部DC和dc02分别在哪个site?
4. 如果我们提到的总部DC和dc02在不同的site,这两个site间的默认复制间隔是多少?如果手动在站点间复制 (手动复制的命令见如下排查中提到的第5个命令,我们需要手动复制所有的5个分区),我们提到的总部DC上的更改是否可以立刻复制到dc02?
5. 如果多个sites, 每个site内的域控制器之间复制是否正常?
第二,我们可以尝试以下命令来检查我们AD环境是否存在AD复制问题。
如下为排查复制情况的方法,供您参考;
我们可以运用管理员身份运行Command Prompt,来检查复制情况。如我的环境所示,有DC01和DC02两台域控。
1:我们运行第一个命令:“Repadmin /replsummary”以检查域控制器之间的当前复制运行状况。 “ / replsummary”操作可以快速简洁地总结林的复制状态和相对健康状况。运行该命令后,它将显示分为两部分的信息 - 源DSA和目标DSA。
只需要在任意一台域控制器运行即可。2:运行第二个命令:“Repadmin /Queue”显示要保留在队列中的元素以进行复制。它显示域控制器需要发出的入站复制请求,以使其与其源复制伙伴保持一致。
3:运行第三个命令:“Repadmin /Showrepl”在指定的域控制器最后一次尝试实现Active Directory分区的入站复制时显示复制状态。它有助于找出复制拓扑和复制失败。
4:运行第四个命令:“Repadmin /KCC”此命令强制目标域控制器上的KCC立即重新计算其入站复制拓扑。它检查并创建域控制器之间的连接。默认情况下,KCC每隔15分钟在后台运行一次,以检查DC之间是否建立了新连接。通过运行命令,我们将强制DC检查环境中是否找到了新的域控制器,如果是,则将连接添加到该域控制器中。
5:运行第四个命令:“ Repadmin /replicate”开始将指定的目录分区从源DC立即复制到目标域控制器。
例如:repadmin /replicate <目的DC名字> <源DC DSA GUID> <Naming Context>
repadmin /replicate vchzho720vm a4ee466d-f68e-4ae0-9a7c-b570c4dcd124 "CN=Schema,CN=Configuration,DC=a,DC=local"
<Naming Context>如下所示:
Domain: DC=Domain,DC=com
Configuration: CN=Configuration,DC=domain,DC=com
Schema: CN=Schema,CN=Configuration,DC=domain,DC=com
Application:
DC=DomainDnsZones,DC=Domain,DC=com
DC=ForestDnsZones,DC=Domain,DC=com
通过运行上述的命令,我们可以检查AD环境是否存在AD复制问题,如果有的话,可以看到对应的报错代码和对应的报错信息。
关于AD复制的问题解答,可以参考以下文章:
针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.- 已编辑 Jolin LuMicrosoft contingent staff 2019年12月3日 10:03
-
尊敬的客户,您好!
感谢您在我们的TechNet论坛发帖。
根据您的描述,总部之家内的域控一分钟内复制可以完成,而总部DC到分公司DC02的复制时间需要很长时间;
以我的经验来看,这是属于正常显示。站点内的复制根据更改通知而自动进行;默认的复制等待时间是15秒;
站点间的复制根据KCC使用开销最低的跨越树设计建立站点间的复制拓扑,站点间复制被优化为最佳的带宽效率,并且站点之间的目录更新可根据可配置的日程安排自动进行。跨越每个站点链接的站点间复制每 180 分钟(3 小时)进行一次。
关于站点内和站点之间的复制情况,可以参考以下链接:针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。
Jolin Lu
Best regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.- 已编辑 Jolin LuMicrosoft contingent staff 2019年12月5日 2:49
-
尊敬的客户,您好!
感谢您在我们的TechNet论坛发帖。
以便于更好理解你的问题,根据您提供的信息我进行了整理:Q1: 您所表述的总部DC是指总部所有的DC还是其中的某台DC;分公司DC02和dc02是否是同一台DC?
Q2:关于站点需要确认的是:总部的6台DC是否位于同一个站点,此站点内共有多少台DC; 分公司DC02和dc02 分别位于哪个站点?
如果总部DC和dc02位于同一站点,并且此站点内DC数量较少,那么复制需要需要20分钟以上,复制速度是比较缓慢的。
我们目前能给的建议是:检查内部网络连接稳定性和带宽效率。
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
尊敬的客户,您好!
想请问一下您目前的进展怎么样,如果有任何问题,请及时联系我。
十分感谢!
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
尊敬的客户,您好!
根据您的描述,我认为站点间的复制20分钟是合理的。
站点内的复制根据更改通知而自动进行;默认的复制等待时间是15秒;
站点间的复制区别于站点内复制的地方是:不是产生变化立即发生复制, 而是根据站点间的复制计划进行的;
如图是我环境内的设置所示;Site A和Site B之前的复制,默认为180分钟;
此图为他们的计划表,里面的复制时间复制频率都可以在这里更改。
Jolin LuPlease remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
尊敬的客户,您好!
根据我们目前的情况,我理解我们现在的问题是总部有6台DC,现在在总部DC的一台上解除用户禁用后了,这个更改过了20分钟后还未复制到总部的另一个dc02.
我们可以尝试从以下几方面排查看看:
1. 我们可以使用如下命令检查是否有很多堆积的信息还没被复制过去。
2. 也可能是网络问题导致的复制延迟。
3. 请问最终我们的这个更改多久被复制到dc02的呢?在这以后,如果在总部的任何一台dc上作其他更改,是否可以很快被复制到总部dc的其他dc?
4. 站点内的复制是根据更改通知来复制的,一般是更改后15s通知它的复制伙伴,那么总部的这个dc02的复制伙伴谁哪个dc呢?
它的这个复制伙伴什么时候得到这个更改的呢?
在解除用户禁用的DC上更改后,这个更改什么时候被复制到“解除用户禁用的DC”的复制伙伴的呢?
此致,
Daisy Zhou
针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.- 已编辑 Daisy ZhouMicrosoft contingent staff 2019年12月12日 7:42
-
尊敬的客户,您好!
请问我们的问题是否解决了呢? 或者还需要我为您提供什么其他的帮助?
如果有任何不清楚的地方,欢迎您随时咨询我们。
此致,
Daisy Zhou
针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
尊敬的客户,您好!
请问我们的问题是否解决了呢?如果已经解决的话,我们可以在此更新一下信息。
如果我们使用自己的方法解决的话,我们可以分享一下解决方案。如果使用以上提供的方法解决的,我们可以把有用的回复标记为答案。这对于正在查找类似问题的人将很有帮助。
如果有任何不清楚的地方,欢迎您随时咨询。
感谢您的理解和支持。
此致,
Daisy ZhouPlease remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.