# win server 2025 DFSR 在 AD 中存在，但未在本地数据库中正确初始化 非常好 👍，这段 `dumpadcfg` 输出说明了关键状态——你现在的主域控制器 **S-DNS1** 上 DFSR 的 SYSVOL 配置是存在的，但出现了 **异常状态**，我来帮你逐行解释并给出修复建议。 --- ## 🧩 一、当前配置含义解析 从你提供的输出： ``` SUBSCRIBER: DOMAIN SYSTEM VOLUME DN : cn=domain system volume,cn=dfsr-localsettings,cn=s-dns1,ou=domain controllers,dc=shuncom,dc=local Member Ref : cn=s-dns1,cn=topology,cn=domain system volume,cn=dfsr-globalsettings,cn=system,dc=shuncom,dc=local ``` 这是 **S-DNS1 的 DFSR 本地订阅对象**，表示它确实被加入了 SYSVOL 的 DFSR 复制组。 接下来： ``` SUBSCRIPTION: SYSVOL SUBSCRIPTION Root Path : c:\windows\sysvol\domain Staging Path : c:\windows\sysvol\staging areas\shuncom.local ``` 这些路径是 **DFSR 同步目录** 和 **暂存区目录**。理论上这是正确的。 --- ## ⚠️ 二、异常点分析 在输出中有两个不正常的特征：
字段状态正常应有说明
Root Size / Staging Size`(null)`应该显示 MB 数DFSR 未能扫描或加载目录元数据
When Changed最近一次变更 10 月 13 日通常为近期时间说明 DFSR 没有再更新订阅状态
这表明 DFSR 在 **注册了配置但未实际工作**，即 “挂载了 SYSVOL 配置对象，但服务未对目录进行跟踪”。 换句话说 —— **DFSR 在 AD 中存在，但未在本地数据库中正确初始化。** --- ## ✅ 三、确认主域是“权威”来源 (Authoritative) 在 SYSVOL 同步失衡时，必须先选一个 “主域 DC” 作为 **Authoritative (权威)**，其内容将被复制到其他 DC。 你这里显然 S-DNS1 是唯一完整的那个，理应作为权威。 --- ## 🧭 四、修复步骤（推荐方案） 以下为安全、标准的修复方式，不破坏现有 AD： ### 🪟 在主域控制器 S-DNS1 上操作 1️⃣ **停止 DFSR 服务** ```cmd net stop dfsr ``` 2️⃣ **在注册表中声明“权威恢复”** 打开注册表编辑器，定位： ``` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters ``` 在右侧创建（如果不存在）以下键值： ``` 名称： StopReplicationOnAutoRecovery 类型： DWORD (32 位) 值： 0 ``` 然后找到： ``` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols ``` > ⚠️ 如果这个路径不存在，可以手动创建。 在该路径下创建： ``` 名称： BurFlags 类型： DWORD (32 位) 值： D4 ``` `D4` 表示 **Authoritative Restore（权威恢复）** --- 3️⃣ **重新启动 DFSR 服务** ```cmd net start dfsr ``` 等待 2~3 分钟后执行： ```cmd dfsrdiag pollad ``` 4️⃣ **确认状态** ```cmd dfsrdiag dumpmachinecfg | findstr "SYSVOL" ``` 应能看到： ``` ReplicationGroupName : Domain System Volume ReplicationFolderName : SYSVOL Share ``` --- ### 🧩 在辅助域控制器 S-DNS6 / S-DNS8 上 1️⃣ 停止 DFSR 服务： ```cmd net stop dfsr ``` 2️⃣ 在注册表中设置 **非权威恢复（Non-Authoritative）**： ``` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols BurFlags = D2 ``` 3️⃣ 启动服务： ```cmd net start dfsr ``` 等待几分钟后，它们会自动从 S-DNS1 复制完整 SYSVOL。 --- ### ✅ 验证同步 在辅助域执行： ```cmd dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:S-DNS1 /rmem:<本机名> ``` 显示 “无囤积” 即成功。 再检查： ```cmd dir C:\Windows\SYSVOL\sysvol\shuncom.local\Policies ``` 应与 S-DNS1 一致。 --- ## 🧱 五、验证组策略恢复 在任意一台 DC 或客户端运行： ```cmd gpupdate /force ``` 如果不再出现 “读取 gpt.ini 失败” 错误，说明 SYSVOL 复制链路修复成功。 --- 是否希望我帮你生成一个**一键自动执行上述 D4 / D2 修复的 PowerShell 脚本**（含状态检测和日志记录），在三台 DC 上依次运行即可？