必须先确认原域控永不上线，否则抢占将引发USN冲突和Event ID 1988/2042/8453等严重故障；应优先用PowerShell命令Move-ADDirectoryServerOperationMasterRole配合-Force参数批量抢占五角色，再执行metadata cleanup清理残留对象，并通过真实业务登录、共享访问、组策略应用及DNS记录修正完成验证。
必须先确认原域控是否真的永不上线——否则抢占等于埋雷。只要 dc01 还有哪怕 1% 可能重启并联网，就绝对不能用 seize，而应等它恢复后走 transfer。强行抢占后它再上线，ad 会因 usn 冲突拒绝同步，event id 1988、2042、8453 就是典型报错，修复成本远高于停机时间。
用 PowerShell 一次性抢占全部五个 FSMO 角色最稳
传统 ntdsutil 流程对空格、换行、大小写极其敏感，输错一个词（比如 seize pdc emulator 写成 seize pdc）就会卡住或静默失败；PowerShell 命令则容错强、可复制粘贴、支持批量操作。
- 以管理员身份打开
PowerShell - 执行：
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster -Force - 每角色迁移需 3–5 分钟，期间按一次
Enter即可继续（不是持续敲） - 执行完立刻用
netdom query fsmo验证，输出中所有角色都应指向DC02
抢占后不清理元数据，新主控就是个“纸老虎”
角色抢过来了，但 AD 数据库里还存着宕机 DC 的服务器对象、NTDS Settings、站点链接等残留。这些残留会导致 DNS 解析异常、组策略不下发、甚至新 DC 自身无法升主。
- 在
DC02上运行ntdsutil→metadata cleanup - 进入
connections→connect to domain wjlove.com（填你实际域名） - 执行
select operation target，按提示依次选：站点 → 域 → 原故障 DC（如e-copa.wjlove.com） - 最后输入
remove selected server，确认清除全部痕迹
验证时别只看命令输出，要测真实业务流
netdom query fsmo 显示成功 ≠ 业务已恢复。很多问题出在 DNS 或 GC 配置上，表面角色正常，实际用户登不了录、共享访问不了。
- 从普通客户端（如
Client01）尝试域用户登录 - 访问一个域内共享路径（如
\servershare），确认能凭域账号进 - 运行
gpresult /h report.html，检查组策略是否应用成功 - 打开事件查看器 → Directory Service 日志，重点过滤
1988、2042、8453这三类错误
最容易被忽略的是 DNS 区域状态——抢占后必须手动把原主控的辅助区域提升为主区域，并在 DNS 控制台里删掉所有指向 DC01 的 NS 记录和 A 记录。否则客户端解析 gc._msdcs.wjlove.com 仍会找错机器，全局编录查询就挂了。
