ad域控制器引导模式维修核心是进入dsrm后，先用esentutl /g校验ntds.dit完整性，再依损坏程度分层修复：逻辑异常优先用ntdsutil语义分析/fixup，物理损坏则执行esentutl /p修复加/d整理，最后必须验证ldap查询、事件日志、fsmo角色及复制状态。
ad域控制器在引导模式下维修，核心目标是安全进入修复环境、精准识别问题、执行最小干预操作。这不是常规重启能解决的场景，必须依赖目录服务还原模式（dsrm）和底层工具链，同时避开常见误操作。
确认是否真需进入DSRM
很多故障其实不需要进DSRM——比如网络不通、DNS配置错、服务临时卡死。先做三步快速判断：
- 用物理控制台或远程桌面直连服务器，看能否响应
ping和dir C:\ - 运行
Get-Service NTDS, KDC, Netlogon | Select Name, Status，确认服务是否“Stopped”而非“Starting” - 查事件日志：重点看ID 1032、1103、1168（数据库损坏）、5719（安全通道失败）、1566（Kerberos票据异常）
只有当lsass.exe报错0xc00002e1、系统反复卡在启动界面、或repadmin /showrepl提示RPC不可用时，才真正需要DSRM。
正确进入并验证DSRM环境
BIOS阶段按F8选“目录服务还原模式”后，必须用DSRM专用密码登录（不是域管理员密码）。登录后第一件事不是急着还原，而是确认环境可信：
- 运行
ntdsutil "file maintenance" "info"，检查ntds.dit路径、大小、最后一致性检查时间是否合理 - 执行
esentutl /g "C:\Windows\NTDS\ntds.dit"做校验——若返回“Checksum error”，说明物理损坏；若卡住或报“Page not readable”，可能是磁盘坏道 - 别跳过
repadmin /showrepl：如果还能执行且显示其他DC复制状态正常，说明问题可能局限在本机，优先尝试语义修复而非整库还原
分层修复：从轻量到强制
修复不是“一刀切”，要按损坏程度选择策略：
-
逻辑异常（推荐首选）：运行
ntdsutil "activate instance ntds" "semantic database analysis /fixup" quit quit，自动修复孤儿对象、断裂索引、引用丢失，不删数据，耗时10–45分钟 -
物理损坏但可读：用
esentutl /p强制修复文件结构，再跟esentutl /d整理碎片，最后ntdsutil "files" "recover"补全日志链 -
严重损毁或备份可用：先用
wbadmin get versions确认备份时间点，再执行wbadmin start systemstaterecovery -version:xxx -backupTarget:X:，还原后务必立即重做系统状态备份
退出前必须完成的收尾动作
修完重启进正常模式前，漏掉这几步等于白干：
- 运行
Get-ADUser -Filter * -ResultSetSize 1测试基础LDAP查询是否响应 - 检查事件日志是否连续出现ID 1000以上（成功启动标记），且不再报1032/1103
- 用
netdom query fsmo确认FSMO角色仍在本机（若已转移，需手动夺回或重新指派） - 执行
dcdiag /test:replications /test:intersite验证复制链是否恢复
不复杂但容易忽略
