Skip to main content

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 服务

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 服务

net start dfsr

等待 2~3 分钟后执行：

dfsrdiag pollad

4️⃣ 确认状态

dfsrdiag dumpmachinecfg | findstr "SYSVOL"

应能看到：

ReplicationGroupName : Domain System Volume
ReplicationFolderName : SYSVOL Share

🧩 在辅助域控制器 S-DNS6 / S-DNS8 上

1️⃣ 停止 DFSR 服务：

net stop dfsr

2️⃣ 在注册表中设置 非权威恢复（Non-Authoritative）：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols
BurFlags = D2

3️⃣ 启动服务：

net start dfsr

等待几分钟后，它们会自动从 S-DNS1 复制完整 SYSVOL。

✅ 验证同步

在辅助域执行：

dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:S-DNS1 /rmem:<本机名>

显示 “无囤积” 即成功。

再检查：

dir C:\Windows\SYSVOL\sysvol\shuncom.local\Policies

应与 S-DNS1 一致。

🧱 五、验证组策略恢复

在任意一台 DC 或客户端运行：

gpupdate /force

如果不再出现 “读取 gpt.ini 失败” 错误，说明 SYSVOL 复制链路修复成功。

是否希望我帮你生成一个一键自动执行上述 D4 / D2 修复的 PowerShell 脚本（含状态检测和日志记录），在三台 DC 上依次运行即可？

No Comments
Back to top