说起爱呢，是因为在中国现况下Windows网络还是组网的首选，简单便捷，易于上手，维护简单，而且稳定。WindowsServer系列操作系统的图形化界面也使得入门门槛极低，无论有没有正经学过计算机都能上手搞两下。
而说到恨，则是恨到骨子里。服务器往往承载了很多服务，一旦出现问题，信息管理ITer们可就有得忙了。光靠看微软文档很多时候是不能解决问题的。中文版文档晦涩难懂，英文文档更是难明其意。没办法上网一通搜，难得有一两个靠点边的，跟实际情况又总有差异，难以套用。即使是MCSE，实际上也是没什么卵用的。狠狠心咬牙重装吧，估计老板的脸色也不会好看，毕竟老板请你来就是要快速解决问题的啊！影响了业务，可担不起这个责任，只能顶着心理压力，硬着头皮排查，收集资料，各种试错，一不小心全盘崩坏。
域控复制失败，这个问题其实困扰了很多人。
先说一下案例背景吧。公司的网络采用的是Windows的活动目录，有一台WindowsServer2008R2服务器作为域控，代号DC1。
因为网络规模不大，所以这台域控承担了GC、DC、DNS、DHCP、文件服务等多种角色。用了很多年也没出问题。
具体原因也就不详说了，把一台NAS做成了域控加到域里作为DC的复制伙伴。
后来因为服务器的性能问题，决定把域控、DNS、DHCP迁移到一台新的WindowsServer2012R2服务器上，代号DC2。
先在DC1上检查了FSMO状态，正常。
在服务器管理器中的“任务”启动“将此服务器提升为域控制器”。按步骤走流程。
到了先决条件检查这一步时出错。红色提示非常刺眼，它是这样说的：
架构主机上一次重新启动后未完成复制周期。架构可以被扩展之前，架构主机必须完成至Adprep无法扩展架构。
[状态/结果]
架构主机上一次重新启动后未完成复制周期。架构可以被扩展之前，架构主机必须完成至少
一次复制周期。
[用户操作]
验证架构主机是否连接到网络并可以与其他域控制器通信。请使用站点和服务管理单元在架构操作主机和至少一个复制伙伴之间复制。复制成功后，请重新运行adprep。
后面自然无法继续。
本地网络的结构不复杂，一想便知是当时NAS充当了一回域控导致的问题。
回到DC1上，用命令检查了目录服务器：
dcdiag
问题果然出跟NAS有关，而且是活动目录复制错误。
赶紧打开NAS配置界面，查看NAS的网络配置，退出网络认证，改成本地模式，问题依旧。
这个情况说明了虽然清除了NAS的网络认证，但活动目录中与DC1的复制伙伴关系依然存在。
那可能就要到DC1上去找找原因了。
重启DC1，NAS，回到DC1，再次dcdiag，问题依旧。
在DC2上尝试了一下提升到域控，先决条件仍不能通过。
问题还是出在DC1上，回到服务器管理器。
ActiveDirectory域服务下主要有两项服务：
ActiveDirectory用户和计算机
ActiveDirectory站点和服务
来到ActiveDirectory站点和服务–Site，下有一项Default-First-Site-Name，点开Servers，里面出现两个服务器——NAS和DC1，下面分别有一项NTDSSettings。
直觉感到离答案很近了。来到DC下的NTDSSettings，属性打开，里面有一个连接页面。点开一看，立刻发现了问题：
在DC1上，有从NAS复制到DC1配置。
再打开NAS的NTDSSettings检查，发现正好有相反的配置。
这就是为什么在域中删除了NAS，域控依然要与它相互复制的原因。
但是却不敢直接贸然删除Servers下的NAS。因为DC1里有与NAS配置的连接，万一删除了NAS，而DC1这边不更新那数据库就更乱了，到时候到哪改去？
我是这样操作的：先删除NAS下的NTDSSettings，再删除NAS。
再回到DC1的NTDSSettings查看属性，连接里面已经空了。
重新dcdiag/a，全部通过。
来到DC2，重试先决条件测试，一次性通过。
虽然不知道问题的解决是不是跟删除了DNS中的NAS信息有关，但肯定是和ActiveDirectory域服务有关。