必须先确认原域控永不上线，否则抢占将引发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 仍会找错机器，全局编录查询就挂了。