Skip to main content

检查+修复 S-DNS1 域控制器健康度

非常关键的状态描述 👍。
你现在的域环境情况可以总结如下，这也是很多 AD 故障转移或清理过程中常见的“半健康状态”：

🧩 一、当前结构判断

项目 状态
域控制器 1 S-DNS1.shuncom.local（192.168.0.5） — 存活、主域控制器（FSMO）
域控制器 2 S-DNS6.shuncom.local（192.168.0.4） — 存活、辅助 DC（但 SYSVOL/Netlogon 复制异常）
客户端表现 域登录、DNS、GPO、认证等功能正常（因为 S-DNS6 仍在运行）
问题 当关闭 S-DNS6 并删除相关 SRV 记录后，客户端找不到 DC，域登录与认证中断

🚨 二、问题的根本原因

这说明：

当前整个域中，S-DNS1 并没有完整地“对外发布”自己是一个可用 DC。
客户端的 DC 定位逻辑（DC Locator）仍依赖 S-DNS6。

换句话说：

  • DNS SRV 记录 _ldap._tcp.dc._msdcs.shuncom.local、_kerberos._tcp.dc._msdcs.shuncom.local 仍把 S-DNS6 作为首选；

  • S-DNS1 的 Netlogon 注册信息未完整写入 DNS；

  • 甚至可能 SYSVOL 没有正确共享（或 DFSR 未完成初始同步），导致客户端通过 DC 定位后仍判定 S-DNS1 “不适合”。

🔍 三、验证思路（不要急着关机 S-DNS6）

在清理前，先验证 S-DNS1 是否具备“完整 DC 功能”。
依次执行以下命令，分析结果：

1️⃣ 验证 SYSVOL / NETLOGON 共享

net share

输出应包含：

NETLOGON      C:\Windows\SYSVOL\sysvol\shuncom.local\SCRIPTS
SYSVOL        C:\Windows\SYSVOL\sysvol

若缺失，则 S-DNS1 无法提供组策略和登录脚本服务，客户端认为该 DC “不健康”。

2️⃣ 验证 DFSR 状态

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,state

正常状态下 state 应为 4 (正常)。

若无输出或状态为 2、3，说明 DFSR 未同步完毕或配置异常。

3️⃣ 验证 Netlogon 动态注册

重新注册并查看 DNS SRV：

net stop netlogon
ipconfig /flushdns
ipconfig /registerdns
net start netlogon
nslookup -type=SRV _ldap._tcp.dc._msdcs.shuncom.local

👉 如果结果中不含 s-dns1.shuncom.local，说明 Netlogon 注册失败（通常由于 SYSVOL/DFSR 问题）。

4️⃣ 验证 DC 广告状态

dcdiag /test:advertising

如果看到：

S-DNS1 没有通过测试 Advertising

那就意味着客户端不会选择它作为 DC。

🧰 四、恢复正确顺序（让 S-DNS1 成为唯一权威 DC）

以下是逐步过渡方案（安全执行，无需马上关机 S-DNS6）：

① 让 S-DNS1 修复 DFSR 状态

在 S-DNS1 上执行：

dfsrdiag pollad
wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig get replicationgroupconfigpresent

如果输出为 FALSE，则注册 DFSR 配置：

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig call PollAD

再执行：

dfsrdiag ReplicationState

若仍无法查询，可能需要重新初始化 SYSVOL（我们后续可生成 safe rebuild 步骤）。

② 验证 S-DNS1 的 SYSVOL 共享恢复

net share

确认 SYSVOL 和 NETLOGON 出现。

③ 在 DNS 中删除 S-DNS6 SRV 前，确保 S-DNS1 注册成功

再次执行：

nltest /dsregdns
nslookup -type=SRV _ldap._tcp.dc._msdcs.shuncom.local

若结果只包含 s-dns1.shuncom.local，说明注册成功。

④ 验证客户端能定位 S-DNS1

在一台域客户端执行：

nltest /dsgetdc:shuncom.local /force
nltest /dcname:shuncom.local

返回：

DC: \\S-DNS1.shuncom.local
地址: \\192.168.0.5

✅ 域控制功能恢复，才能安全下线 S-DNS6。

🧩 五、S-DNS6 下线步骤（在确认上面全部通过后）

  1. 在 S-DNS6 上：

    net stop netlogon
net stop dfsr
dcpromo /demote

    将其降级为普通成员服务器。

  2. 在 S-DNS1 上清理元数据：

    ntdsutil
metadata cleanup
remove selected server S-DNS6
quit
quit

  3. 清除 DNS 中所有与 S-DNS6 相关的 A / SRV 记录。

  4. 最后执行：

    nltest /dsregdns
repadmin /syncall /AdeP

✅ 六、总结

你现在的现象说明：

域功能正常仅因为 S-DNS6 仍在运行，S-DNS1 尚未“完全被广告为域控制器”。

重点在于：

  • 修复 S-DNS1 的 SYSVOL/DFSR；

  • 让 Netlogon 注册生效；

  • 验证 dcdiag /test:advertising 通过；

  • 再清除 DNS 的旧记录并下线 S-DNS6。

是否希望我帮你生成一份 逐步 PowerShell 脚本化自动检查+修复 S-DNS1 域控制器健康度 的方案？
它可以自动检测 DFSR、Netlogon、SYSVOL、SRV 注册、Advertising 状态并输出结果。

Back to top