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