简介：面向Windows Server域环境初学者与系统管理员的实操型文档，围绕主域控制器、辅助域控制器部署及主域控制器迁移展开，帮助读者梳理域架构搭建、角色转移与常见故障处理思路。资源包共1个docx文件，约566KB，以文字说明和命令示例整理环境准备、活动目录安装、额外域控加入、FSMO五大角色迁移及全局编录设置等内容，并给出ntdsutil命令行转移与角色夺取的参考写法，内容按搭建、加入、迁移与验证顺序组织，便于在实验环境中对照练习、验证主辅域控复制效果和迁移结果。该文档已有2064人浏览学习，适合课程实验、企业域控迁移预演及日常运维知识梳理，也可作为搭建主辅域控、执行角色迁移时的速查笔记，帮助读者减少配置遗漏并建立较完整的排错思路。

1. 从 dcpromo 到 ntdsutil：把主域控、辅助域控和迁移串成一条线

机房角落里那台跑了七八年的机器要下架，域里五个 FSMO 角色全压在它身上，全局编录也只有它一份，这时候才想起来翻文档，最容易出现的问题是步骤对不上号。这份记录把三件事串成一条线：主域控怎么用 dcpromo 从零建起来，辅助域控怎么作为额外域控制器加入并把复制链路跑通，最后把 RID、PDC、基础结构、域命名、架构五个角色连同全局编录一起迁移到新机器上。整套流程基于 Microsoft Windows Server 2003 Enterprise Edition 的双机方案，适合还在维护老活动目录环境的人、想搭实验环境验证迁移路径的人，以及需要理解「域控装完不等于交付」的运维从业者。下面按搭建、加入、迁移、排错的顺序往下走，每一步都给出命令和判断依据。

2. 主域控的搭建：dcpromo 向导 11 个页面分别该填什么

2.1 先定地址和名字，别等装到一半才想

域控搭建里最难调整的是地址规划，一旦 dcpromo 跑完，改 IP 意味着 DNS 记录、SRV 记录、站点信息全部要跟着动。我一般会在装系统之前就把表格填好，两台机器对号入座，装的时候照着抄，不给自己临场发挥的机会。

原始资料里用的是 1.1.1.1 / 255.0.0.0 这套写法，掩码是 A 类的默认掩码。实验环境图省事可以这么干，但我建议换成私网号段，一来 1.1.1.1 现在被公共 DNS 服务占用，客户端做名称解析时容易和外部解析打架；二来掩码写 255.0.0.0 意味着整个 10.0.0.0/8 都算同网段，真实机房里跨网段复制、站点划分这些判断会失真。真要复现实验，用 10.10.10.0/24 更贴近生产，掩码 255.255.255.0，判断逻辑一模一样，出问题时排查范围还小。

还有两个容易忽略的前置动作：把两台机器的防火墙对域控相关端口放行，至少包括 53、88、135、139、389、445、636、3268、3269；把系统时间对齐，域内 Kerberos 认证对时间偏差容忍度只有 5 分钟，时间不同步时会报「安全数据库中存在该计算机账户，但登录失败」这类看起来莫名其妙的错误。

2.2 dcpromo 向导逐项拆解

装完系统、配好静态 IP 和 DNS 指向自身之后，从运行框或者命令行调起安装向导。命令行方式比点开始菜单更稳，尤其是远程桌面里操作的时候：

:: 调起活动目录安装向导 dcpromo

这条命令本身没有参数，走的是交互式向导。dcpromo 也支持应答文件静默安装（dcpromo /answer:文件名），但初次搭建不建议用，向导每一步的选择直接决定后面域的行为，手点一遍能看清每一项的含义。

向导的页面顺序和对应的填法如下，照着填基本不会出错：

几个值得多解释两句的点：

「在新林中的域」这个选项意味着当前这台机器会成为新森林的根域，同时自动持有全部五个 FSMO 角色和全局编录，这是后面迁移章节的起点。如果选错成「现有域的额外域控制器」，向导会要求提供父域凭据，环境里根本没有，只能退出重来。

数据库和日志文件分开存放不是形式主义。活动目录数据库文件 NTDS.dit 的写入模式和日志文件差别很大，日志是顺序追加写，数据库是随机读写，放在同一块盘上，日志刷盘会被数据库的随机 IO 拖慢，域控在用户集中登录的早高峰会明显卡顿。实验环境一块盘无所谓，生产环境至少分两个分区。

DNS 注册诊断这一页给三个选项，第二项的大意是「在这台计算机上安装并配置 DNS 服务器，将使用此 DNS 服务器作为该域的 DNS 服务器」，选它之后向导会自动装 DNS 服务并建好正向区域。第一项是「不在本机安装 DNS，稍后手动配置」，这种方式适合 DNS 已经由别的团队统一管理、要单独提申请的场景，如果本机 DNS 没配好就选它，装完域控会得到一个客户端连不上的域。原始资料里选第二项是对的。

权限页面选 2003 兼容模式，会启用更严格的安全设置，比如对匿名查询的限制。只有当林里还存在 Windows 2000 域控、需要向下兼容时才选另一个选项。选完这一页就没有回头路了。

还原模式密码是另一套独立的口令，只在开机按 F8 进入目录服务还原模式时使用，用于离线恢复 NTDS.dit。它和域管理员密码没有任何关系，很多人装完就忘，真出事要恢复时抓瞎。我一般要求它写在两处：纸质交接单和密码管理工具里各一份，不许只存在脑子里。

2.3 装完先自检，别急着加第二台

向导跑完会提示重启，重启后第一件事不是去加辅助域控，而是把自检做完。主域控如果本身是带病的，后面所有复制问题都会显得像玄学，排查成本翻几倍。我习惯跑这么几条：

:: 1. 看 SYSVOL 和 NETLOGON 两个共享是否自动建立 net share :: 2. 用 Support Tools 里的诊断工具做一轮基础体检 dcdiag /test:netlogons /test:advertising /test:services :: 3. 检查 DNS 里域控的 SRV 记录是否注册完整 nslookup -type=srv _ldap._tcp.dc._msdcs.corp.lab :: 4. 确认本机当前持有的 FSMO 角色 netdom query fsmo

第一条net share的输出里必须能看到 SYSVOL 和 NETLOGON 两个共享。这两个共享是组策略下发和登录脚本的基础，没有它们，域能登录但策略不生效，表现是改了口令策略却没人被强制。共享不存在通常是 SYSVOL 还没复制完或者文件系统权限异常，等几分钟再刷新，一直不出来就得看事件日志里的 FRS 报错。

第二条dcdiag需要预先安装 Windows Server 2003 Support Tools，装完在%programfiles%\support tools目录下。三个测试项分别验证网络登录权限、域控是否在 DNS 中正确对外宣告自己、以及关键服务（KDC、Netlogon、W32Time）的启动状态，输出里出现 failed 的行要逐条看清楚，警告（warning）可以先放一放，失败（failed）必须当场解决。

第三条nslookup查 SRV 记录，正常应该返回_ldap._tcp.dc._msdcs.corp.lab对应的主机名和端口 389。如果返回「找不到」，说明 DNS 自动注册没成功，客户端加入域时会报找不到域控。修复方式是重启 Netlogon 服务触发重新注册，命令是net stop netlogon && net start netlogon，还不行就手工检查 DNS 正向区域里_msdcs、_sites、_tcp、_udp四个子目录是否存在。

第四条netdom query fsmo同样来自 Support Tools，输出会列出五个角色分别落在哪台机器上。刚装完应该是五个角色全部指向 DCA.corp.lab，这个输出是后面迁移的基准线，建议截图存档，迁移完再跑一次做对比。

这四条命令加起来不到两分钟，能把八成的基础问题挡在门外。等第二台机器加入之后再发现，就分不清是主域控的锅还是复制链路的锅了。

3. 辅助域控加入：ping 得通不等于复制得通

3.1 地址和 DNS 指向决定了 dcpromo 能不能找到域

辅助域控的准备工作看着简单，出问题的概率却最高。核心就一句话：B 机的首选 DNS 必须指向 A 机，不能指向任何外部 DNS，也不能指向自己。因为 dcpromo 加入现有域的第一步是查_ldap._tcp.dc._msdcs.corp.lab这条 SRV 记录，只有 A 机上的 DNS 有这个记录，指向别的解析器就等于把导航关了。

配置完先做连通性验证，别凭感觉认为「应该通了」：

:: 基础连通性 ping 10.10.10.10 :: 名称解析是否走通了域名到域控的映射 nslookup corp.lab nslookup -type=srv _ldap._tcp.dc._msdcs.corp.lab :: 直接问主域控要域信息，这条最接近 dcpromo 内部的实际动作 nltest /dsgetdc:corp.lab /force

ping只能证明三层通，证明不了域服务可用。真正有说服力的是nltest /dsgetdc，它模拟的就是客户端定位域控的过程，正常输出会列出主域控的全名、IP、站点名和标志位，其中应该包含 GC（全局编录）标记。这条命令报错「无法找到域控制器」，那 dcpromo 一定失败，先修解析，别去改别的。

权限方面，加入额外域控制器用的账号必须是 Domain Admins 组或者 Enterprise Admins 组成员，普通域用户不行。我一般直接拿域管理员账号操作，实验环境不纠结最小权限，但要注意这个账号的密码里不能有会触发命令行转义的特殊字符，否则在向导里粘贴会出问题。

3.2 走一遍「现有域的额外域控制器」

:: 在辅助域控 B 上执行 dcpromo

向导路径和主域控搭建有明显分叉，从第二页开始就不一样了：

第一步，操作系统兼容性页面直接下一步。第二步，域控制器类型选「现有域的额外域控制器」，和主域控那台选「新域的域控制器」正好相反。这一步选错会把 B 机变成一个新森林的根，两台机器各管各的，表面上都叫域控，实际上毫无关系。

第三步，网络凭据页面填有权限加入域的账号、密码和域名。域名这里填corp.lab或者 NetBIOS 名CORP都行，向导会自动解析。如果前面 DNS 没配对，这一步会卡住并提示「无法联系到域 corp.lab 的域控制器」，回头检查 2.1 和 3.1 的内容。

第四步，额外域控制器域名默认带出corp.lab，接受即可。第五步，数据库和日志文件夹，同样建议分开放，路径可以和主域控不同，但目录结构保持一致，便于后期统一备份。

第六步，目录服务还原模式密码。这里有个细节：辅助域控的还原密码可以和主域控不同，两台机器各自独立。为了降低交接成本，我通常设成一样，但会在交接文档里标注「两台机器的 DSRM 密码相同，任何一台需要恢复都使用此口令」。

第七步，摘要页面核对，点下一步开始安装。安装过程中会从主域控复制完整的目录数据库，数据量大的话这一步耗时较长，中间不要中断。安装完成后必须重启，重启之后 B 机才真正开始以域控身份工作。

重启后回到 A 机，打开「Active Directory 用户和计算机」，展开 Domain Controllers 组织单位，应该能看到 DCB 这个计算机对象。这一步能验证加入动作本身成功，但证明不了复制正常，下一节专门说。

3.3 复制链路怎么验证才算真的通了

原始资料里写「经测试，主域控制器的数据能及时复制到辅助域控上面」，这个结论要靠具体手段落地，不然出事时说不清。我常用三层验证，从粗到细：

:: 第一层：总体摘要，看两台域控之间有没有失败计数 repadmin /replsummary :: 第二层：逐条复制伙伴的详细状态，包括上次成功时间 repadmin /showrepl :: 第三层：手动触发一次复制，然后立刻回看结果 repadmin /replicate DCB.corp.lab DCA.corp.lab "DC=corp,DC=lab"

repadmin /replsummary输出的是每个域控作为源和目标时的最大失败时间、失败次数。正常状态下失败次数应该是 0，最大失败时间显示「never」。只要出现非零失败次数，第二层命令能定位到是哪一对复制伙伴、哪个命名上下文出的问题。

repadmin /showrepl会列出 B 机所有的入站复制伙伴，每条下面有「上次成功」的时间戳和连续失败次数。判断标准很简单：上次成功时间应该在最近 15 分钟内（同站点内默认复制间隔），连续失败必须是 0。

第三条手动复制命令适合在改完配置后立即验证，参数依次是目标域控、源域控、命名上下文。命名上下文写成DC=corp,DC=lab这种形式，对应域的 DN。执行完再用repadmin /showrepl看时间戳是否刷新，刷新了就说明链路完全正常。

图形界面的等价操作在「Active Directory 站点和服务」里：展开 Sites → Default-First-Site-Name → Servers → DCB → NTDS Settings，右侧会列出复制连接，右键选择「立即复制」即可。想看得更细，可以打开事件查看器里的目录服务日志，筛选来源为 NTDS Replication 的事件，成功复制的事件 ID 是 1869，报错通常是 1311（复制配置信息不可用）或者 8524（DNS 名称解析失败），这两个错误码基本能把大部分复制故障归类。

还有一点容易被忽略：同站点内的复制默认是变更通知驱动的，主域控上有对象改动后大约 15 秒就会通知辅助域控拉取，所以「及时」是有前提的，前提是两台机器在同一个站点里。如果后面为了模拟多站点环境把它们分到不同站点，复制就变成按计划间隔执行，默认最短 15 分钟，那时候再测「及时性」会觉得怎么都不对，其实是站点链接的开销在起作用。

4. FSMO 五角色迁移：图形界面走一遍，命令行再兜一次底

4.1 迁移前先做 system state 备份

角色迁移是不可逆的在线操作，虽然正常转移不破坏数据，但万一中途断电、网络断、目标机器宕机，目录数据库可能处于不一致状态。动手之前必须先做系统状态备份，这是唯一能回退的手段，我称之为后悔药。

Windows Server 2003 自带的备份工具是 ntbackup，命令行方式比图形界面更适合留档：

:: 把系统状态备份到 D 盘，带作业名和日志 ntbackup backup systemstate /j "pre-fsmo-move" /f "D:\backup\sysstate-01.bkf" /l "D:\backup\backup.log" /m normal

参数逐个解释：backup systemstate指定备份内容为系统状态，包含注册表、COM+ 类注册数据库、引导文件、系统文件以及活动目录数据库；/j是作业名，方便在备份日志里检索；/f指定备份文件路径，.bkf是 ntbackup 的专有格式；/l指定日志文件，出问题时看这个；/m normal表示普通备份，不做增量标记。

这条命令要在主域控和辅助域控上各跑一次，两台机器都要有可回退的基线。备份文件生成后，建议复制一份到网络位置或者移动硬盘，不要只留在本机，因为最需要恢复的场景往往是本机磁盘挂了。

系统状态备份不能单独还原部分内容，恢复时必须在目录服务还原模式下整份还原，或者用权威还原（authoritative restore）的方式只恢复特定对象。还原模式的开机方式是在启动时按 F8，选择「目录服务还原模式」，登录时用 2.2 节里设置的那个还原模式密码，不是域管理员密码。这一整套流程建议在实验环境里完整跑一遍，真出事的时候才不至于手忙脚乱。

4.2 RID、PDC、基础结构：同一张对话框里的三个角色

这三个角色的转移入口都在「Active Directory 用户和计算机」里，操作路径高度一致，区别只是操作主机对话框里选哪个标签页。先理解它们各自管什么，再动手会稳很多：

具体步骤：在辅助域控 B 上打开「Active Directory 用户和计算机」，右键点击域名 corp.lab，选择「连接到域控制器」，在列表里选中 DCB.corp.lab，确定。这一步是关键，不切换的话，后面点「操作主机」看到的还是当前连接的域控，改来改去改的是自己。

连上之后，再次右键域名，选择「操作主机」，弹出对话框，三个标签页分别是 RID、PDC、基础结构。每个页面里都有一个「更改」按钮，点击后系统会确认「是否将操作主机角色转移到 DCB.corp.lab」，选是，然后确定。三个页面按同样方式操作一遍，每个角色转移成功都会有提示框。

这里有一个经典坑：基础结构主机如果和全局编录部署在同一台机器上，它会停止更新跨域对象引用，因为它认为自己的数据已经是最新的。判断规则是——如果林里所有域控都是全局编录，那基础结构主机不起作用，放哪都无所谓；如果林里存在非全局编录的域控，基础结构主机就必须放在非全局编录的域控上。原始资料的场景里两台都是全局编录，所以不受影响，但换到有三四台域控的环境里，这一条不检查就会埋雷，表现是跨域组的成员变更延迟很久才生效，还查不出原因。

PDC 仿真主机还有个隐性职责是域的时间源。转移完成后，新持有者会成为域内时间的权威来源，如果这台机器的 CMOS 电池老化导致时间漂移，整个域的时间都会跟着漂。我一般会在这台机器上配一个可靠的外部时间源，用w32tm /config /manualpeerlist:... /syncfromflags:manual /reliable:yes /update命令搞定，然后net stop w32time && net start w32time重启时间服务。

4.3 域命名主机与架构主机：两个藏起来的控制台

域命名主机管的是林级别的域增删，入口在另一个管理工具里：

在辅助域控上打开「Active Directory 域和信任关系」，先右键根节点选择「连接到域控制器」，选中 DCB，确定。然后再次右键根节点，选择「操作主机」，对话框里只有一个标签页，点「更改」，确认。这个角色是林级别的，整个林只有一台持有者，转移过程中如果提示权限不足，检查当前登录账号是否属于 Enterprise Admins。

架构主机更隐蔽，默认的管理工具里根本没有入口，必须先注册一个动态链接库把管理单元放出来：

:: 注册架构管理单元 regsvr32 schmmgmt.dll :: 打开空白 MMC 控制台 mmc

regsvr32是注册 DLL 组件的标准命令，schmmgmt.dll位于%systemroot%\system32目录下，注册成功会弹出一个提示框。注册完成后，运行mmc打开空白控制台，按 Ctrl+M 或者菜单里的「添加/删除管理单元」，在列表里找到「Active Directory 架构」，添加、关闭、确定。

接下来两步顺序不能颠倒：先右键「Active Directory 架构」节点，选择「更改域控制器」，点「指定名称」，输入DCB.corp.lab，确定。确认当前连接已经切到辅助域控之后，再右键该节点选择「操作主机」，点「更改」，按提示确认。

如果顺序搞反了，直接点操作主机，改的可能是当前默认连接的域控（通常是主域控自己），你会看到一个「更改」按钮点下去毫无反应或者报错，因为架构主机默认就在林里的第一台域控上。原始资料里特别强调先改域控制器再改操作主机，就是踩过这个坑留下的经验。

架构主机的转移需要 Schema Admins 权限，而且这个角色的变更会触发整个林的架构同步，操作时林内所有域控最好都在线。如果某台域控长时间离线，架构更新会在它恢复后集中推送，极端情况下会导致复制冲突。生产环境做这一步一般会安排在变更窗口内。

4.4 全局编录迁移与 ntdsutil 命令行兜底

全局编录不是 FSMO 角色，但它决定了登录验证和跨域查询能不能工作，必须和五个角色一起迁。默认情况下林里的第一台域控就是全局编录，新建的额外域控默认不带这个勾。

图形方式在「Active Directory 站点和服务」里：展开 Sites → Default-First-Site-Name → Servers → DCB → 右键 NTDS Settings → 属性，勾选「全局编录」，确定。然后对 DCA 做反向操作，展开到 DCA 的 NTDS Settings 属性，取消勾选。

顺序很重要：先给 B 机勾上，等目录数据完整复制过来（用 3.3 节的方法确认没有未完成的复制），再取消 A 机的勾。反过来操作会有个窗口期，林里一台全局编录都没有，客户端登录时报「找不到全局编录服务器」，所有依赖 GC 的查询全部失败。这个窗口期哪怕只有几分钟，也够用户打电话了。

五个角色全部转移完之后，用命令行的方式复核一遍，同时准备好 seize 的语法以备不时之需：

:: 进入目录服务维护工具 ntdsutil :: 进入 FSMO 维护上下文 roles :: 建立到目标域控的连接 connections connect to server DCB.corp.lab quit :: 逐个转移角色（正常转移，要求原持有者在线） transfer RID master transfer PDC transfer infrastructure master transfer domain naming master transfer schema master :: 退出 quit quit

这套交互式命令的层级要看清：ntdsutil是顶层，提示符是ntdsutil:；输入roles进入fsmo maintenance:；输入connections进入server connections:；connect to server之后必须quit退回到fsmo maintenance:才能执行 transfer 命令，在server connections:提示符下敲 transfer 会提示命令无效。这是新手最常卡住的地方。

transfer和seize的区别值得单独说清楚，两者语义完全不同：

seize是最后手段。如果你的主域控只是暂时宕机、硬盘还能修，千万别用 seize。一旦强夺，原机上的目录数据库里还认为自己是角色持有者，修好之后直接开机接入网络，就会出现两个 RID 主机同时分配 RID 池的情况，SID 冲突、复制冲突接踵而至，清理起来比重装还麻烦。真要强夺，原机恢复后必须先做元数据清理（metadata cleanup），把它从林中彻底摘掉，再考虑是否重新加入。

命令行方式还有一个好处是可以写成批处理留档。我习惯把整个 transfer 序列写成一个.bat文件存在运维目录里，迁移时直接执行，事后作为变更记录的一部分归档，比截图可靠。

5. 避坑与排查：五个把迁移搞翻车的现场

5.1 搭建阶段的两个高频错误

坑一：辅助域控的 DNS 指向了外部解析器

现象：在 B 机上运行dcpromo，选「现有域的额外域控制器」，填完凭据后卡住，提示「无法联系到域 corp.lab 的域控制器，请确认域名输入正确」。

原因：B 机的首选 DNS 被设成了运营商地址或者网关地址，解析corp.lab时查不到 SRV 记录。dcpromo 定位域控完全依赖 DNS，不依赖广播或者 hosts 文件。

解决：把 B 机首选 DNS 改回主域控 IP，ipconfig /flushdns清缓存，再用nslookup -type=srv _ldap._tcp.dc._msdcs.corp.lab验证能解析出记录，然后重新跑 dcpromo。如果不想每次都手改，可以在 B 机 hosts 里加一条静态记录做兜底，但那是权宜之计，DNS 的正规配置不能省。

坑二：主域控装完不做 DNS 自检，SRV 记录缺失

现象：主域控本身能登录，但任何客户端加入域都报「找不到域」，辅助域控也加不进来。

原因：dcpromo 安装过程中如果 DNS 服务安装失败、或者安装后 Netlogon 服务没有正常启动，SRV 记录就不会自动注册。很多人装完看到「安装成功」的提示就直接往下走，跳过了验证。

解决：在 A 机上重启 Netlogon 服务触发重新注册，命令是net stop netlogon && net start netlogon，然后nslookup复查 SRV 记录。如果还是没有，手工检查 DNS 控制台里corp.lab区域下的_msdcs、_sites、_tcp、_udp四个文件夹是否存在，缺哪个就手工建，或者把 DNS 区域删掉重装。这个坑我在实验环境里踩过一次，重装 DNS 花了半小时，后来就养成了装完必跑 SRV 查询的习惯。

5.2 迁移阶段的三个致命操作

坑三：跳过备份直接 seize，原机修好后又接回网络

现象：主域控硬件故障，情急之下在辅助域控上执行了seize夺取全部角色。几天后原机修好，开机接入网络，域内开始出现用户登录随机失败、新建账号 SID 冲突、复制报错 8606（对象已存在但属性不同）。

原因：seize 只是让新机器接管角色，原机的目录数据库里仍然记录自己是角色持有者。两台机器同时对同一批对象做写入，复制引擎无法判断谁是权威，冲突就此产生。

解决：这个坑基本没有优雅的补救办法，标准流程是立即把原机断网，在正常域控上用ntdsutil的metadata cleanup清除原机的域控元数据，把它的计算机账号、复制连接、DNS 记录全部摘干净，然后重装系统再重新加入。从那以后，我这边有一条硬规定：只要用了 seize，原机在元数据清理完成之前，网线不许插。

坑四：只转移了角色，忘了迁移全局编录

现象：五个 FSMO 角色都显示在新域控上了，netdom query fsmo输出也正确，但客户端登录变慢、Outlook 查全球地址簿失败、跨域组查询超时。

原因：全局编录还留在原主域控上，或者两台机器的 GC 勾选状态搞反了——新机器没勾上，老机器先取消了。整个林里没有可用的 GC，所有依赖全局编录的查询都会退化成慢速查询或者直接失败。

解决：在「Active Directory 站点和服务」里按 4.4 节的顺序重新操作，先给新域控勾上 GC，用repadmin /showrepl确认复制完成，再取消老域控的勾选。判断 GC 是否真的生效，可以用nltest /dsgetdc:corp.lab /gc指定查询全局编录，输出的服务器应该是新域控。

坑五：架构主机转移时没先切换域控制器

现象：在 MMC 里添加了「Active Directory 架构」管理单元，右键点「操作主机」，点「更改」按钮是灰的，或者点下去报「拒绝访问」。

原因：MMC 控制台默认连接到当前登录域或者林根域的第一台域控，而架构主机默认就在那台机器上。你在 B 机上点「更改」，实际是在对 A 机自己操作，等同于「把角色从 A 迁到 A」，系统自然不会让你点。

解决：先右键「Active Directory 架构」节点，选「更改域控制器」→「指定名称」→ 输入DCB.corp.lab，确定之后再操作主机。这个顺序原始资料里写得很明确，但实际操作时因为选项藏得深，很容易漏掉。同样的问题在「Active Directory 域和信任关系」里也有，操作域命名主机之前必须先连接目标域控。

排查这类问题的通用思路是：任何一个「操作主机」对话框，点开之后第一眼先看对话框标题或者描述里显示的当前域控名字是不是你以为的那台。不是的话，先断开重连，别急着点更改。这个习惯能省掉大量「改了没反应」的困惑。

6. 迁移后的验证与善后：三条命令把「以为成功」变成「确认成功」

角色转移的对话框提示「操作成功」，只代表这一次 RPC 调用完成了，不代表整个域的状态健康。我一般用三条命令做最终验收，跑完截图存档，作为变更单的附件。

:: 1. 确认五个角色的实际归属 netdom query fsmo :: 2. 对目标域控做一轮完整诊断，重点看复制和 DNS dcdiag /v /c /e /s:DCB.corp.lab :: 3. 用 CSV 格式导出复制拓扑，便于长期归档对比 repadmin /showrepl /csv > D:\backup\repl-after-move.csv

第一条的输出里，RID、PDC、基础结构、域命名、架构五行都应该指向DCB.corp.lab。如果还有一行指向老机器，说明那个角色没转成功，回到第 4 章对应小节重做。

第二条的/v是详细模式，/c表示对所有测试项执行（包括一些默认跳过的），/e表示检查林内所有域控，/s指定起点服务器。这条跑完输出很长，重点看末尾的「failed」汇总行和 5.1、5.2 里提到的那几个关键测试项。warning 可以接受，failed 必须清零。

第三条导出的 CSV 会记录每一对复制伙伴的名称、上次成功时间、失败次数、错误码。这份文件的价值在于时间维度上的对比——迁移当天导一份，一周后再导一份，两次对比如果失败次数没有增长、上次成功时间都在滚动，说明复制链路稳定。出现新的错误码能第一时间发现，不用等用户报障。

善后工作里最容易漏的是老域控的处置。角色和全局编录都迁走之后，老机器还留在 Domain Controllers 组织单位里，仍然参与复制、仍然占着一个域控的席位。如果它的硬件确实要退役，正确的收尾是用dcpromo执行降级，把它变成普通成员服务器或者直接退域，让域控元数据被自动清理干净。降级之前务必确认新域控已经承担全部角色、GC 复制完成、并且至少有一份可用的系统状态备份——降级本身也会触发复制和数据库变更，出问题同样需要恢复手段。

降级命令也是dcpromo，向导会提示「这个服务器是最后一个域控制器吗」，选否，输入有权限的凭据，确认后开始降级。如果选是，它会把这个域连同里面的所有对象一起删掉，那一瞬间整个域就没了，所以这一页要看得特别仔细。

从那以后我每次做完角色迁移，都会强制走一遍「三条命令 + 一次备份校验 + 老机器降级确认」的收尾流程，哪怕领导催着说赶紧下班，也不省这一步。迁移这活儿最怕的就是「看起来成功了」，等到用户登录不上再回头查，往往已经是几天后的事，日志滚没了，现场也没了。希望帮到你。

本文还有配套的精品资源，点击获取