Windows Server 2016域控迁移实战：体检、FSMO转移与故障排查

1. 迁移之前的体检与规划：别让一台“带病”的DC硬撑着

如果你正在搜“2016域控服务器迁移”或者“域服务器迁移出错”，我猜你多半已经动手了，而且大概率已经踩了一两个坑。上个月我刚帮一个客户做完从Windows Server 2008 R2到Windows Server 2016的域控迁移，夜里两点的告警邮件和客户端登录超时把我折腾得不轻。回头复盘才发现，真正让迁移变难的往往不是“迁移”这个动作本身，而是迁移前那台老域控身上积攒多年的“历史病”。

Windows Server 2016作为目标域控，本身没有太多要特殊对付的地方，但AD DS环境是一个强耦合的分布式系统，任何一个DC状态不健康，都会在迁移过程中被放大成日志报错、复制失败、客户端无法通过Kerberos验证等问题。所以这篇我打算先讲规划，再讲操作，最后把最容易让你搜到“域服务器迁移出错”的几种典型故障一次性说清楚。

1.1 为什么要重视迁移前的DCDIAG体检

很多运维朋友习惯上来就让新服务器加域，然后装AD角色、一气呵成。这种流程不是不行，但前提是老DC必须干净健康。老DC有没有复制错误、DNS有没有异常、SYSVOL能不能正常共享、时间服务是不是一直默认“不知道该听谁的”，这些全都不会像业务故障那样弹窗提醒你，等到迁移时才一起爆。

我一般会在迁移前后各跑一轮DCDIAG，作为基础体检。命令很简单：

dcdiag /v dcdiag /test:replications /s:DC01 dcdiag /test:dns /v

重点看几个输出标签：Replications、DNS Tests、Services、Systemlog。如果出现Fail或者Warning，先解决再往下走，不要抱着“应该不影响”的心态。尤其是test:replications出现连续性的复制失败时，新DC提升后很可能拉不到完整的AD分区数据，导致后续用户、组策略全部缺胳膊少腿。

复制检查还可以补一条更直观的：

repadmin /replsummary

这条命令会列出所有域控之间最后一次复制成功的时间，一眼能看出哪台DC“掉线”了。如果老DC和备份DC之间复制本来就有问题，那么新DC加入并提升后，问题会被继承下来，到时候排查起来会让你怀疑人生。

1.2 网络、DNS与备机规划

域控迁移最容易被忽略的是网络层。AD对DNS的依赖是“生死级别”的，域控找域控、客户端找域控、GC查询、Kerberos定位KDC，全部依赖DNS里的SRV记录。所以迁移之前，先理一下几件事：

• 新DC的IP地址是静态还是DHCP保留？域控必须用静态IP，这一点我踩过坑：DHCP分配出新的IP后，DNS记录注册混乱，复制直接出问题。
• 新DC的DNS服务器地址应该指向谁？如果环境里只有一台老DC，新DC装了DNS角色之后，自己也要指向自己，否则提升时无法注册SRV记录。
• 老DC是否同时是GC、DNS、DHCP的主持机器？如果是，迁移时角色要逐个交接，不要一股脑退域。

另外建议把新DC放在老DC同一个站点（Site）下，默认Default-First-Site-Name就行。如果跨站点且站点和子网配置不干净，会引出很多“找不到DC”“正在尝试连接下一个域控”的诡异报错，这类问题查起来很耗时。

CLI层面，我习惯用nltest /dsregdns来强制注册DNS记录，用ipconfig /registerdns给所有域内重要服务器重刷一遍解析记录。迁移前后各跑一次，能避免大部分“明明域名能ping通，但客户端就是加不了域”的困扰。

1.3 功能级别与FSMO角色盘点

另一个规划重点是林/域功能级别。如果老DC是2008 R2或2012，那么新DC加入并在2016模式下运行时，功能级别可以先不动。只有在所有DC都升到目标版本之后，才建议把林/域功能级别提升到2016。

功能级别影响的是新特性，例如DFS-R复制SYSVOL、AuthN策略等。提升之前想清楚一件事：一旦把域功能级别从2008 R2提高到2016，意味着以后域里不能再加入2008 R2的DC，如果企业内部还有老服务器想临时变成域控，就会直接被拒。

另外，用下面的命令把FSMO角色归属盘出来：

netdom query fsmo

输出会显示五位“角色主人”，分别是：

• Schema Master（架构主机）
• Domain Naming Master（域命名主机）
• PDC Emulator（PDC仿真器）
• RID Master（RID池主机）
• Infrastructure Master（基础架构主机）

这几台机器是谁、在哪个站点、网络通不通，在迁移计划里都要写清楚。后面做角色转移时，最怕的就是两台DC网络不通却强行执行转移命令，结果角色“丢”了——其实是被转移到一台根本连不上的机器上。

2. FSMO角色与新DC“夺权”的完整操作路径

FSMO全称是Flexible Single Master Operation，也就是“灵活单主机操作”。你可以把它理解成域里的五个“唯一负责人”：比如PDC Emulator负责域内时间同步和密码变更，RID Master负责给每台DC分配RID池，架构主机负责AD架构扩展。既然是“单主机”，就意味着同一时刻只有一个DC在管这件事，迁移时就要把这些职责从老DC手上移交给新DC。

2.1 五个角色是什么、谁最容易被迁移坑

很多朋友只听说“要转移五大角色”，但不知道哪个角色最关键，出问题了是什么表现。我这里用大白话拆开：

• Schema Master（架构主机）：管AD数据库结构的，比如Exchange、System Center这类软件扩展架构时，必须找它。迁移时如果这个角色没转移，新装软件可能会报“无法联系架构主机”。
• Domain Naming Master（域命名主机）：负责域或应用分区的添加删除，平时闲置，但缺了它就建不了新域或子域。
• PDC Emulator（PDC仿真器）：域里最忙的DC角色之一，时间授权、密码校验、组策略默认处理都在它身上。迁移时如果交接不干净，老客户端会按时钟不同步的报错。
• RID Master（RID池主机）：给各DC发放相对标识符池。如果它彻底下线，新DC无法创建新安全主体，界面上就是“无法生成新的用户SID”。
• Infrastructure Master（基础架构主机）：负责跨域对象引用的更新。多域环境重要，单域环境基本可以忽略，但最好也转义过去。

实际迁移过程中，我最强调PDC Emulator和RID Master。PDC Emulator的时间问题会引发Kerberos大面积报错，RID Master则会让新用户/组创建失败。排障时一眼看到“RID Pool 需要调整”这类事件，基本就是它没转移好。

2.2 新成员服务器加入域后的提升动作

新DC的部署流程，我强烈建议这样走：

1. 把新服务器加域，重启。
2. 登录后装AD DS角色，工具跟着装。
3. 在服务器管理器里点“将此服务器提升为域控制器”。
4. 选择“添加新域控制器”到现有域，输入老域控的凭据。
5. 指定DSRM密码，下一步完成安装。

这里有个2016尤其是新手容易踩的坑：网上很多老教程还在提dcpromo，但Windows Server 2016里图形化已经不支持直接跑dcpromo了。如果你打开命令行敲dcpromo，会发现它提示你去服务器管理器操作。所以别照搬古早教程，老老实实用“添加角色和功能”向导。

提升过程中，注意几个选项：

• “域控制器功能级别”保持默认或按需选择，但不要低于现有域功能级别。
• “全局编录”在新DC上默认勾选。单域单DC环境务必保留，多域环境除非你有特殊设计，否则也建议每个DC都勾上GC。
• DNS服务器选项，一般建议直接勾选。AD环境必须要有DNS，否则SRV定位会断。

装完后重启，第一件事不是庆祝，而是看事件日志和复制状态。用repadmin /replsummary确认新DC已经从老DC同步到最新，再考虑下一步角色转移。

2.3 转移FSMO：图形界面与ntdsutil两条路

角色转移可以通过图形界面做，也可以命令行做。图形界面适合只转移一两个角色时用，命令行适合批量操作和无人值守。

图形界面路径：Active Directory 用户和计算机→ 右键域 →操作主机→ 切换到目标DC → 转移对应角色。

Active Directory 域和信任关系右键→操作主机，可以转移Domain Naming Master。

Active Directory 架构管理单元需要提前注册schmmgmt.dll才能看到。

命令行方式更直接，用ntdsutil：

ntdsutil > roles > connections > connect to server NEW-DC > quit > transfer schema master > transfer naming master > transfer rid master > transfer pdc > transfer infrastructure master > quit > quit

每条transfer命令执行时系统都会弹确认框，问你是否确认传输。确认后，角色归属立刻变化。用netdom query fsmo复查一下，能看到所有角色已经指向新DC。

2.4 “转移”和“夺取”的区别，什么时候用哪个

这一区分听着基础，但真的能救命。字面上，transfer是“老DC还在线上、双方协商移交”，seize是“老DC已经挂了、强制把角色抢过来”。

正常搬迁流程里，老DC开机且网络正常，就用transfer。如果老DC硬件已经损坏、彻底无法开机，而角色还在它身上，那只能用seize。比如RID Master丢了，就要：

ntdsutil > roles > connections > connect to server NEW-DC > quit > seize rid master

注意，seize之后的那个原始角色服务器，以后绝对不能再重新加回域，否则会产生“角色冲突”，比角色丢失还难收拾。它只能重装系统或者保持离线。

我一次真实踩坑经历：某台老DC硬盘快挂了，我没注意，直接执行transfer，结果中途连接断了，角色既不在老DC也不在新DC。幸好后来用seize从新DC抢回来了，但场面足够吓人。所以凡是涉及到角色转移，提前备好当前FSMO归属清单，别打无准备之仗。

3. 迁移出错的高频元凶：DNS、时间同步、SYSVOL复制

到这个阶段，你可能已经把新DC建起来了，但域内开始飘出各种报错。这里把我在Server 2016迁移实战中遇到过的高频故障罗列一下，代码和排查方法都给出。

3.1 DNS注册畸形造成AD复制失败

AD复制本质上是“通过DNS发现伙伴，然后通过RPC通信复制数据”。如果DNS里没有正确的SRV记录，新DC根本找不到老DC去拉数据。常见的现象：

• 事件日志报NTDS Replication错误，源目DC GUID已经删掉。
• dcdiag /test:dns提示The DNS operation timed out。
• DNS管理台里，_msdcs区域树不完整，找不到_tcp/_kerberos等关键记录。

处理套路是这样：先确认新DC网卡DNS指向自己，然后强制注册DNS：

ipconfig /registerdns nltest /dsregdns net stop netlogon && net start netlogon

再查SRV记录：

nslookup -type=SRV _ldap._tcp.dc._msdcs.你的域.com

如果记录缺失，可以手动在DNS管理台新建，或者把Netlogon服务重启一遍让系统自动注册。注意，_msdcszone名称不要输错，常见的“找不到域控制器”八成就是这里拼写不对。

3.2 时间同步与Kerberos登录失败

这是域迁移里最阴的坑之一。Kerberos协议对时间容差默认只有5分钟，一旦客户端和DC的时钟差太多，就会报KRB_AP_ERR_SKEW或者“无法联系域控制器”。

2016域环境中，默认时间同步链是：客户机→DC→PDC Emulator→外部时间源。你在迁移时如果顺手把老DC给降级了，而新DC的PDC Emulator还没配置外部NTP源，那全域时间就飘了。

遇到这个问题的排查方式：

w32tm /query /status w32tm /query /peers w32tm /monitor

如果发现PDC Emulator的source不是可靠外部源，就在PDC上配置：

w32tm /config /manualpeerlist:"ntp.aliyun.com,0x8 ntp.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update net stop w32time && net start w32time w32tm /resync

在客户机和普通DC上，保持默认“从域同步”即可。别手贱把每台机器都指向外网NTP，否则域内时间链反而乱掉。

3.3 SYSVOL与DFSR复制问题

老DC如果是2008 R2或更早，SYSVOL默认可能还在用FRS复制。2016域控默认用DFSR复制SYSVOL，所以新DC提升后，系统会尝试把SYSVOL迁移到DFSR。这中间常常出现“SYSVOL就绪前，组策略无法应用”的假故障。

判断方法有三个：

• 事件ID 4604或4612：出现时注意文本提示。
• 查看SYSVOL共享是否存在：net share sysvol
• 看C:\Windows\SYSVOL\domain\Policies目录下GUID文件夹是否完整。

如果SYSVOL一直不共享，执行：

dcdiag /test:frssysvol /test:dfsr /v dfsrmig /getglobalstate

确保迁移状态已到达Eliminated才算完成。如果卡在Redirected还出现日志警告，可能需要手动dfsrmig /setglobalstate 3，但这一步要在确认复制正常后做。

另外，旧DC用FRS期间，NETLOGON共享异常会导致客户端无法执行登录脚本，用户体验就是“登录巨慢且没脚本”。这一步在迁移计划里务必排进去检查。

3.4 防火墙和安全软件的隐蔽阻断

AD复制/验证用到的端口不少：TCP 135、389、445、464、636、3268、49152-65535动态RPC，UDP 389、445。如果新DC服务器上有第三方防火墙或者云安全组，这些端口被挡，现象就是“新DC提升成功，但复制就是不动”。

我处理过一台阿里云上的新DC，安全组只放了几个常用端口，结果repadmin一直报“目标服务器不可达”。检查方式用：

Test-NetConnection OLD-DC -Port 445 netstat -an | findstr 135

在两端临时关防火墙验证是最快的确认方法，但生产环境记得关完立刻开回来。还有一招，用PortQry工具从新DC扫老DC的动态RPC端口，能快速定位到底哪一段被拦截。

4. 迁移之后的去旧迎新与加固

角色转移完、新DC复制正常，只代表“架构上迁移成功”。真正让你项目收尾成功的是老DC清理干净、客户端不再连到老机器、元数据没有残留。

4.1 老DC降级退域的正确顺序

老DC退域绝不是直接“更改设置→离开域”这么简单，尤其当它是GC或DNS服务器时，先要把角色和GC标记挪走。

流程：

1. 打开“Active Directory 站点和服务”，确认老DC所在站点下没有它负责的、唯一GC子网。
2. 把GC标记临时从老DC去掉，等它复制同步完。
3. 在服务器管理器把AD DS角色删除，选择“将此服务器降级为成员服务器”。
4. 降级完成后，重启，再退域。

降级过程如果报错“无法卸载AD DS”或者卡在半路，常见原因是元数据没清理干净，或者DNS里还残存老DC记录。这时候可以先强制降级：如果系统已经处于“DC无法正常降级”的状态，用ntdsutil的metadata cleanup清理残留。

一次不干净的退域会在DNS里留下大量A记录和SRV记录，之后新加域的计算机有可能被“引”到一台不存在的DC上，从而产生间歇性无法解析域控的诡异故障。

4.2 元数据清理

老DC已经彻底不能用，且没有走正常退域流程时，必须做元数据清理。在任意一台正常DC上执行：

ntdsutil > metadata cleanup > connections > connect to server NEW-DC > quit > select operation target > list domains > select domain 0 > list sites > select site 0 > list servers in site > select server OLD-DC-NUMBER > quit > remove selected server > quit > quit

清理完成后，用netdom query fsmo确认角色都在新DC，再用nltest /dclist:你的域名查看DC列表，老DC不应再出现。

4.3 客户端与业务服务器后续处理

域控换人后，客户端不一定那么快“听话”。有的机器DNS里还写着老DC的IP，如果老DC已经下线，这些客户端的域登录就会间歇性失败。所以客户端批量操作的收敛很关键：

• DHCP作用域选项里，把DNS服务器改为新DC IP。
• 静态IP的服务器，逐个改DNS并执行ipconfig /flushdns、ipconfig /registerdns。
• 如果老DC的IP不能立即回收，考虑临时把新旧DC的IP做对调，让老IP继续由新DC使用，减少客户端改动。

在客户端侧，可以跑：

nltest /dsgetdc:你的域 echo %logonserver% whoami /user

确认登录的DC已经切到新机器上。如果客户端还抱着老DC的会话，可以重启或手动klist purge清理Kerberos缓存，强制重新获取票据。

4.4 验证清单和监控手段

我习惯在迁移结束后第二天做一次“复盘检查”，因为很多问题不会立刻暴露，而是等到第二天登录峰值才炸。检查清单可以做成这样：

• [ ]dcdiag /v /q输出无连续Fail
• [ ]repadmin /showrepl所有DC之间复制正常
• [ ]net share sysvol、net share netlogon都已存在
• [ ]netdom query fsmo输出统一指向新DC
• • [ ] DNS中老DC记录已删除，_msdcs区域SRV记录正常
• [ ] 客户端登录echo %logonserver%已指向新DC

监控上，建议给新DC装上AD状态相关的性能计数器，重点盯NTDS\\DRA Replication性能对象和NTDS\\LDAP Client Sessions。一旦复制队列堆积或LDAP会话异常，就要立刻介入。

5. 一条龙常见报错速查与排障记录

最后这部分，我整理了一张速查表，适合摆在手边当小抄。都是我在2016迁移项目里真实碰过的报错和排查方向，不掺水。

5.1 常见报错速查表

这里把现象、可能原因和处理办法对应起来，方便你拿现象直接查。

5.2 排障心得与习惯

最后一个建议：做域控迁移时，每一步操作前、后都把ntdsutil状态、netdom query fsmo结果、复制状态给保存一份。这些输出不仅是你的“后悔药”，也是项目复盘和交接给同事的宝贵材料。我亲眼见过一个团队因为没有做以上记录，老DC一降级，FSMO角色信息直接变成谜，最后只能凭事件日志逐条推断，折腾了大半夜。

另外，迁移窗口最好安排在业务低峰期。域控迁移和普通的软件升级不一样，它牵动的是整个域内所有机器和用户的信任关系，一旦出错影响面是全线式的。如果你是第一次做2016迁移，建议先在测试环境完整走一遍流程，把坑全部踩完再上生产。我就是这么干的，你会发现真正上生产时心态稳得多。