AD域主控器宕机后不会立即瘫痪，但FSMO角色滞留将导致关键管理操作失败；需先强制夺取五角色，再彻底清理故障DC元数据及DNS记录，并配置新全局编录服务器。

主域控制器宕机后，AD域不会立刻瘫痪——只要还有其他正常运行的域控制器，用户登录、组策略应用、资源访问等基础功能仍可继续。但五大FSMO角色若长期滞留在已离线的DC上，关键管理操作（如新建用户、改密码、加域、升域功能级别）将陆续失败。恢复的核心是两件事：把角色抢过来，把故障DC的“影子”彻底擦干净。

确认故障状态并验证当前角色归属

别急着开命令行。先确认主DC确实无法恢复：

• 用ping dc01.contoso.com和Test-Connection dc01.contoso.com -Count 2测试网络连通性
• 尝试RDP连接，检查物理服务器是否断电或蓝屏
• 在辅DC上运行netdom query fsmo，看输出是否仍显示所有角色归属已宕机的DC

如果返回结果里还写着Schema master: dc01.contoso.com这类信息，说明角色未迁移，必须干预。

用ntdsutil强制夺取五大FSMO角色

仅适用于原DC彻底失联、永不回归的场景。在辅DC（如dc02）上以管理员身份打开CMD或PowerShell：

• 输入ntdsutil，回车
• 输入roles，回车
• 输入connections，回车
• 输入connect to server dc02.contoso.com（替换成你当前要操作的辅DC主机名），回车
• 输入q返回角色界面
• 依次执行以下五条命令（每条后回车）：
  seize schema master
seize domain naming master
seize pdc
seize rid master
seize infrastructure master
• 全部执行完后输入q两次退出

再运行netdom query fsmo核对，所有角色应已指向dc02。

清理故障DC残留元数据

角色抢过来只是第一步。原DC的“幽灵记录”还在AD数据库和DNS里，不清理会导致同步错误、DNS解析失败、新DC加入异常：

• 在任意正常DC上打开Active Directory站点和服务 → 展开对应站点 → Servers → 找到故障DC节点 → 右键其下的NTDS Settings → 删除
• 接着右键该服务器本身 → 删除（注意：必须先删NTDS Settings，否则会报错）
• 打开Active Directory用户和计算机 → 进入Domain Controllers容器 → 删除故障DC计算机账户
• 打开DNS管理器 → 在_msdcs.域名和正向查找区域.域名中，手动删除所有与故障DC相关的A记录、SRV记录（尤其是_ldap._tcp.dc._msdcs等）

配置全局编录并验证服务可用性

不是所有DC默认就是全局编录服务器。若故障DC原本是GC，需手动启用新DC的GC功能：

• 打开Active Directory站点和服务 → 展开站点 → Servers → 目标DC → NTDS Settings → 右键 → 属性
• 勾选全局编录复选框 → 确定
• 等待几分钟让复制完成（可用repadmin /replsummary查看同步状态）
• 用普通域账号在Client机器上测试：能否登录？能否访问共享文件夹？能否打开gpupdate /force？能否在ADUC中新建用户？

所有测试通过，说明AD域已实质性恢复。