windows-server-2003 – 如果无法在Windows域中的DC之间进行复制,可能的结果/副作用是什么?

前端之家收集整理的这篇文章主要介绍了windows-server-2003 – 如果无法在Windows域中的DC之间进行复制,可能的结果/副作用是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
有很多管理文献可以帮助您正确管理 Windows服务器.但在处理现实生活中,事情并不总是像你想要的那样发生.在Microsoft的Windows Server 2003 Administrator’s Companion中,在1400页中,只有一页我可以在设置其他域控制器时找到.如果“同伴”DC无法复制,它们会使听起来很无聊并且不会透露很多内容.

至于手头的具体问题,由于RAID控制器坏了,我们有一个DC在大约一个月前出现故障.没有什么关键可以引起人们的注意,所以把它重新放回去了.一个月后,我们让DC重新启动并运行,而且一切似乎都没问题.第二天,没有人能够登录抱怨“用户不存在”或“无法建立信任关系”.知道我刚刚把被击落的DC放回网络上,我立即将它从网络上取回并让所有人重新启动工作站.在那之后,交换很好,股票变得可用,并且每个人都能够登录.在做了一些事件日志游泳之后,似乎一切都是由于SYSVOL上的复制问题而开始的.我已经阅读了你可以强制复制的地方,但这意味着要把它放回网络上.我害怕将DC重新放回网络,担心会出现其他问题.那么,在一个月内两个DC没有复制的情况下,还有哪些其他问题可能会遇到?

根据它们未被同步的时间长度,您可能会遇到一个达到其 Tombstone Lifetime的情况,之后您开始遇到已删除对象重生的问题.话虽如此,最低默认值是60天,所以如果时间少于此,你应该没问题.

AD(以及DNS和许多其他服务)处理同步问题的方式是每次更改时递增序列号.因此,如果您一直在使用PRIMARYDC并进行更改,则SECONDARYDC将具有较低的数字并将遵循较高的数字.

如果您真的担心,可以随时擦除SECONDARYDC,手动将其从Active Directory中删除,重新映像,然后将其优雅地推广为另一个DC.我认为你把它带到网上并解决你的SYSVOL问题是安全的.如果你想成为一个额外的偏执狂,请在下班后进行,这样你在解析SYSVOL时就不会出现不一致.

下面的编辑Adaptr提出了一个很好的观点 – 如果你选择去那条路线,请确保在擦除它之前没有为SECONDARYDC分配FSMO角色.

猜你在找的Windows相关文章