# 检查+修复 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 共享** ```powershell net share ``` 输出应包含： ``` NETLOGON C:\Windows\SYSVOL\sysvol\shuncom.local\SCRIPTS SYSVOL C:\Windows\SYSVOL\sysvol ``` 若缺失，则 S-DNS1 无法提供组策略和登录脚本服务，客户端认为该 DC “不健康”。 --- ### **2️⃣ 验证 DFSR 状态** ```powershell Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo | Select ReplicationGroupName, ReplicatedFolderName, State ``` 正常状态下 `state` 应为 `4 (正常)`。 若无输出或状态为 `2`、`3`，说明 DFSR 未同步完毕或配置异常。 --- ### **3️⃣ 验证 Netlogon 动态注册** 重新注册并查看 DNS SRV： ```powershell 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 广告状态** ```powershell dcdiag /test:advertising ``` 如果看到： ``` S-DNS1 没有通过测试 Advertising ``` 那就意味着客户端不会选择它作为 DC。 --- ## 🧰 四、恢复正确顺序（让 S-DNS1 成为唯一权威 DC） 以下是逐步过渡方案（安全执行，无需马上关机 S-DNS6）： --- ### **① 让 S-DNS1 修复 DFSR 状态** 在 **S-DNS1** 上执行： ```powershell dfsrdiag pollad wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig get replicationgroupconfigpresent ``` 如果输出为 `FALSE`，则注册 DFSR 配置： ```powershell wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig call PollAD ``` 再执行： ```powershell dfsrdiag ReplicationState ``` 若仍无法查询，可能需要重新初始化 SYSVOL（我们后续可生成 safe rebuild 步骤）。 --- ### **② 验证 S-DNS1 的 SYSVOL 共享恢复** ```powershell net share ``` 确认 `SYSVOL` 和 `NETLOGON` 出现。 --- ### **③ 在 DNS 中删除 S-DNS6 SRV 前，确保 S-DNS1 注册成功** 再次执行： ```powershell nltest /dsregdns nslookup -type=SRV _ldap._tcp.dc._msdcs.shuncom.local ``` 若结果只包含 `s-dns1.shuncom.local`，说明注册成功。 --- ### **④ 验证客户端能定位 S-DNS1** 在一台域客户端执行： ```powershell 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 上： ```powershell net stop netlogon net stop dfsr dcpromo /demote ``` 将其降级为普通成员服务器。 2. 在 S-DNS1 上清理元数据： ```powershell ntdsutil metadata cleanup remove selected server S-DNS6 quit quit ``` 3. 清除 DNS 中所有与 `S-DNS6` 相关的 A / SRV 记录。 4. 最后执行： ```powershell nltest /dsregdns repadmin /syncall /AdeP ``` --- ## ✅ 六、总结 你现在的现象说明： > 域功能正常仅因为 S-DNS6 仍在运行，S-DNS1 尚未“完全被广告为域控制器”。 重点在于： - 修复 S-DNS1 的 SYSVOL/DFSR； - 让 Netlogon 注册生效； - 验证 `dcdiag /test:advertising` 通过； - 再清除 DNS 的旧记录并下线 S-DNS6。 --- 这个错误的根本原因是： > **Windows 10 / Windows Server 2022 及之后的版本已移除 `wmic.exe` 工具**，因此系统无法识别 `wmic` 命令。 --- ### ✅ 一、替代方案：用 PowerShell 查询 DFSR 状态（推荐） 可以使用 **PowerShell 的 WMI / CIM 命令** 代替 `wmic`： ```powershell # 获取 DFSR 复制文件夹状态 Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select-Object ReplicationGroupName, ReplicatedFolderName, State ``` 或使用较新的 `Get-CimInstance`（建议在 Windows Server 2019/2022 用）： ```powershell Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo | Select ReplicationGroupName, ReplicatedFolderName, State ``` 输出中： - **State = 4** → 表示 *“已就绪 (Normal)”*。 - 其他值如 2、3 表示正在初始化或同步中。 --- ### ✅ 二、若要查看 DFSR 服务状态 ```powershell Get-Service DFSR ``` 应显示： ``` Status Name DisplayName ------ ---- ----------- Running DFSR DFS Replication ``` --- ### ✅ 三、查看 DFSR 的连接伙伴状态 ```powershell Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrConnectionInfo | Select-Object ConnectionName, PartnerName, Enabled ``` --- ### ✅ 四、进一步验证 SYSVOL 是否由 DFSR 管理 ```powershell dfsrdiag pollad dfsrdiag replicationstate ``` 如报错可确认 DFSR 尚未正确注册或服务未启动。 --- ### ✅ 五、如果 DFSR 仍不正常，可做以下检查 1. **服务检查**：`services.msc` → 确认 “DFS Replication” 已启动。 2. **事件日志**：查看： ``` 事件查看器 → 应用程序和服务日志 → DFS Replication ``` 重点关注事件 ID： - **4112**：开始复制 - **4114**：复制暂停（例如 SYSVOL 停止共享） - **4602**：SYSVOL 已完成迁移（健康） 3. **域控制器同步状态**： ```powershell repadmin /replsummary repadmin /showrepl ``` --- ### ✅ 六、如果你只需要确认 SYSVOL 是否正常共享 ```powershell net share ``` 应能看到： ``` Share name Resource ---------- -------- NETLOGON C:\Windows\SYSVOL\sysvol\shuncom.local\SCRIPTS SYSVOL C:\Windows\SYSVOL\sysvol ``` --- 非常好，这组输出信息非常关键，我们可以完整地判断当前 **S-DNS1 的 DFSR 与 SYSVOL 复制状态**。 下面是你的状态诊断结果 + 后续建议操作表。 --- ## 🧩 一、当前状态诊断汇总
检查项当前结果说明
**DFSR 服务状态**✅ Running服务正常运行
**DFSR 管理的 SYSVOL 状态**⚠️ `State = 2`表示 DFSR 处于 **“初始化中 (Initialization)”**，SYSVOL 尚未完全进入 “正常复制 (State=4)”
**DFSR 伙伴关系**⚠️ Partner = `S-DNS6`当前 DFSR 的复制伙伴仍是旧的辅助域 `S-DNS6`
**出站 / 入站复制连接**⚠️ 均为 0表示目前没有复制活动进行（因为唯一伙伴 S-DNS6 可能不可达或未启用）
**SYSVOL / NETLOGON 共享**✅ 均存在本地共享已可用，说明 SYSVOL 树结构本地健康
--- ## 🧠 结论分析 - 当前 **S-DNS1 的 SYSVOL 共享功能正常，但 DFSR 仍认为它有个复制伙伴 S-DNS6**。 - 因此，如果关闭或移除 S-DNS6，而不先清理 DFSR 元数据，S-DNS1 的 DFSR 服务会认为复制集异常（即仍处于初始化状态），进而影响域控制器广告、组策略分发、脚本同步等。 - 你看到的 `State=2` 就是 DFSR 尚未进入健康的 “正常” 状态的直接信号。 --- ## ✅ 二、彻底清理旧伙伴 S-DNS6 并让 S-DNS1 独立承管 SYSVOL 的操作步骤表 ### **步骤 1：确认当前唯一有效 DC 是 S-DNS1** ```powershell netdom query fsmo ``` 应全部指向 `S-DNS1.shuncom.local`。 --- ### **步骤 2：从 AD 元数据中删除 S-DNS6** 在任意健康 DC（此处即 S-DNS1）上执行： ```powershell ntdsutil metadata cleanup connections connect to server S-DNS1 quit select operation target list domains select domain <你的域编号> list sites select site <你的站点编号> list servers in site select server quit remove selected server quit ``` 确认后在 AD 用户与计算机中不再出现 `S-DNS6`。 --- ### **步骤 3：清理 DNS 中 S-DNS6 的 SRV / A 记录** 在 `DNS 管理器` → `shuncom.local` → `_msdcs`、`_sites`、`_tcp`、`_udp` 下手动删除以下记录： - `_ldap._tcp.dc._msdcs.shuncom.local` - `_kerberos._tcp.dc._msdcs.shuncom.local` - `_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.shuncom.local` - 以及 S-DNS6 对应的 `主机(A)` 记录。 --- ### **步骤 4：清理 DFSR 元数据中的 S-DNS6 链接** 在 S-DNS1 上运行： ```powershell dfsmgmt.msc ``` - 展开 **“Replication” → “Domain System Volume”** - 删除与 S-DNS6 相关的 **连接对象 (Connections)** 若图形界面操作不可行，可强制清理： ```powershell dfsrdiag dumpadcfg > C:\dfsr_before.txt ``` 查找其中的 `` 节点中包含 `S-DNS6` 的条目，然后： - 打开 **ADSIEdit.msc** - 连接到命名上下文：`CN=DFSR-GlobalSettings,CN=System,DC=shuncom,DC=local` - 删除包含 `S-DNS6` 的连接对象。 --- ### **步骤 5：强制刷新 DFSR 配置** ```powershell dfsrdiag pollad ``` 然后重启 DFSR 服务： ```powershell Restart-Service DFSR ``` --- ### **步骤 6：验证 DFSR 状态是否恢复正常** 再次执行： ```powershell Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo | Select ReplicationGroupName, ReplicatedFolderName, State ``` 若显示： ``` Domain System Volume SYSVOL Share 4 ``` ✅ 表示 DFSR 状态“正常（Normal）”，S-DNS1 已独立管理 SYSVOL。 --- ### **步骤 7：验证 Netlogon 和 DNS 注册** 1. 强制重新注册 Netlogon 记录： ```powershell net stop netlogon net start netlogon ``` 2. 检查 DNS 是否自动刷新： ```powershell nslookup -type=SRV _ldap._tcp.dc._msdcs.shuncom.local ``` 应仅返回 `S-DNS1`。 3. 验证客户端域加入 / 登录： ```cmd nltest /dsgetdc:shuncom.local ``` 应能正常返回 `S-DNS1`。 --- ## ✅ 三、可选：DFSR 状态检查脚本（简化） ```powershell Write-Host "=== DFSR Replicated Folder Info ===" Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo | Select ReplicationGroupName, ReplicatedFolderName, State Write-Host "`n=== DFSR Connection Info ===" Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrConnectionInfo | Select ConnectionName, PartnerName, Enabled Write-Host "`n=== SYSVOL/NETLOGON Shares ===" net share | findstr "SYSVOL NETLOGON" ``` --- 是否希望我帮你把上述操作步骤整理成一份 **表格化的执行手册（Word/PDF）**？包括命令行、图形界面路径、预期结果和恢复步骤，方便操作时逐项打勾确认。