none
在总部dc上对ji_wh用户解除禁用,20分钟后仍未复制到dc02 RRS feed

全部回复

  • 尊敬的客户,您好!

    感谢您在我们的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复制的问题解答,可以参考以下文章:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems

    针对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.

    2019年12月3日 9:50
  • Jolin Lu 你好!

    1.AD环境中只有一个域,总部环境是一台主域控和五台辅助域控,有50家分公司都是辅助域控。

    2.总部DC到分公司DC02的复制是正常的,两个site间的默认复制间隔是60。

    3.部DC上的更改需要很长时间可以立刻复制到dc02。总部之家域控基本上一分钟就可以。

    4.请问总部DC更改复制到dc02时间长的原因?

    下面截图是

    2019年12月4日 2:41
  • 尊敬的客户,您好!

    感谢您在我们的TechNet论坛发帖。

    根据您的描述,总部之家内的域控一分钟内复制可以完成,而总部DC到分公司DC02的复制时间需要很长时间;

    以我的经验来看,这是属于正常显示。

    站点内的复制根据更改通知而自动进行;默认的复制等待时间是15秒;

    站点间的复制根据KCC使用开销最低的跨越树设计建立站点间的复制拓扑,站点间复制被优化为最佳的带宽效率,并且站点之间的目录更新可根据可配置的日程安排自动进行。跨越每个站点链接的站点间复制每 180 分钟(3 小时)进行一次。


    关于站点内和站点之间的复制情况,可以参考以下链接:

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755994(v=ws.10)?redirectedfrom=MSDN


    针对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.


    2019年12月5日 2:49
  • Jolin Lu 你好!

    站点之间复制是正常,但是在总部DC做更改到分DC02时间比较长,超过20分钟才能看见DC02上有更改效果。请你能不能详细说明导致复制缓慢的原因?提供一些如何排查检查复制缓慢的方案。

    2019年12月5日 6:49
  • 尊敬的客户,您好!

    感谢您在我们的TechNet论坛发帖。

    以便于更好理解你的问题,根据您提供的信息我进行了整理:

    Q1:  您所表述的总部DC是指总部所有的DC还是其中的某台DC;分公司DC02dc02是否是同一台DC?

    Q2:关于站点需要确认的是:总部的6台DC是否位于同一个站点,此站点内共有多少台DC; 分公司DC02dc02 分别位于哪个站点?

    如果总部DCdc02位于同一站点,并且此站点内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.

    2019年12月6日 7:13
  • 尊敬的客户,您好!

    想请问一下您目前的进展怎么样,如果有任何问题,请及时联系我。

    十分感谢!


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2019年12月9日 2:29
  • 微软工程师   你好!

    1、总部DC指所有总部的六台DC。分公司DC02和dc02是同一台。

    2、总部的6台DC是位于同一个站点,如下图所示,每个分公司都有自己的站点  ,总共70家,所有分公司站点都和总部站点复制链接。

    3、总部DC和分公司DC02不在同一的站点内。

    请你能不能详细说明导致复制缓慢的原因?

    2019年12月9日 3:43
  • 尊敬的客户,您好!

    根据您的描述,我认为站点间的复制20分钟是合理的。

    站点内的复制根据更改通知而自动进行;默认的复制等待时间是15秒;

    站点间的复制区别于站点内复制的地方是:不是产生变化立即发生复制, 而是根据站点间的复制计划进行的;

    如图是我环境内的设置所示;Site A和Site B之前的复制,默认为180分钟; 



    此图为他们的计划表,里面的复制时间复制频率都可以在这里更改。


    Jolin Lu


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2019年12月9日 9:52
  • 尊敬的客户,您好!

    根据我们目前的情况,我理解我们现在的问题是总部有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.

    2019年12月12日 7:24
  • 尊敬的客户,您好!
    请问我们的问题是否解决了呢? 或者还需要我为您提供什么其他的帮助?

    如果有任何不清楚的地方,欢迎您随时咨询我们。


    此致,
    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.

    2019年12月16日 6:35
  • 尊敬的客户,您好!

    请问我们的问题是否解决了呢?如果已经解决的话,我们可以在此更新一下信息。

    如果我们使用自己的方法解决的话,我们可以分享一下解决方案。如果使用以上提供的方法解决的,我们可以把有用的回复标记为答案。这对于正在查找类似问题的人将很有帮助。

    如果有任何不清楚的地方,欢迎您随时咨询。

    感谢您的理解和支持。


    此致,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2019年12月19日 8:48