Skip to main content

Windows Server 2025 域控清除所有组策略并重建主策略

好的，我们一步步来解决这个问题。你当前的场景是：

Windows Server 2025 域控（AD 主域控制器）中组策略无法刷新成功（gpupdate /force 报错或无效）。

你想要 清除所有组策略并重建主策略（Default Domain Policy、Default Domain Controllers Policy）。

下面是一个完整、安全的操作步骤（建议谨慎执行，尤其是在生产环境中）。

🧩 一、确认问题范围

首先确认是“组策略损坏”，而不是临时的 SYSVOL / 权限 / 复制问题。

在主域控上运行：

gpupdate /force

如果报类似错误：

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{GUID}\gpt.ini

或：

The system cannot find the path specified.

那说明 SYSVOL 共享下的策略文件缺失或损坏。

🧹 二、备份当前组策略

非常重要！ 即使损坏，也要先备份现有策略对象。

执行：

mkdir C:\GPO_Backup
Backup-GPO -All -Path C:\GPO_Backup

这会把所有 GPO 导出到 C:\GPO_Backup，万一需要恢复可以用 Restore-GPO。

⚙️ 三、删除所有现有 GPO

如果你确定要完全清空并重建：

Get-GPO -All | Remove-GPO

此命令会删除所有组策略对象（包括自定义策略），但不会删除 GPMC 中的链接（如 OU 链接会断开，因为 GPO 已不存在）。

🧱 四、重建默认策略

Windows 提供 dcgpofix 命令用于恢复系统默认组策略。

在主域控上以管理员身份运行：

dcgpofix /target:both

系统会提示确认：

This command will replace the Default Domain Policy and the Default Domain Controller Policy with the original default policy.
Do you want to continue? (Y/N)

选择 Y。

作用：

  • 重新创建：

    • Default Domain Policy (GPO GUID: {31B2F340-016D-11D2-945F-00C04FB984F9})

    • Default Domain Controllers Policy (GPO GUID: {6AC1786C-016F-11D2-945F-00C04fB984F9})

  • 还原到初始默认值。

🧩 五、检查 SYSVOL 与 AD 同步状态

执行：

net share

确认存在：

SYSVOL
NETLOGON

然后再运行：

repadmin /showrepl

确保没有 AD 复制错误。

再执行：

dcdiag /v

查看是否有 GPO / SYSVOL 相关错误。

🔄 六、重新生成 GPO 文件夹

在某些情况下，SYSVOL\sysvol\<domain>\Policies 下可能缺少默认策略文件夹，可以强制重建：

gpupdate /force

如果依然报错，可以手动删除损坏的策略 GUID 文件夹（在确认已备份的前提下）：

C:\Windows\SYSVOL\sysvol\<yourdomain>\Policies\

然后再执行 dcgpofix，它会重新生成对应 GUID 目录。

🧰 七、重建完成后验证

验证新策略是否正常应用：

gpresult /h C:\gp.html
start C:\gp.html

看是否能显示 Default Domain Policy 和 Default Domain Controllers Policy。

🧾 八、可选：手动恢复其他策略

如果之前导出过自定义策略，可逐一恢复：

Restore-GPO -Path C:\GPO_Backup -All

✅ 总结

步骤 操作 说明
1 备份策略 (Backup-GPO -All) 防止误删
2 删除全部 GPO (Remove-GPO) 清空现有
3 重建默认策略 (dcgpofix /target:both) 恢复系统默认
4 检查 SYSVOL / 复制状态 确保无错误
5 测试刷新 (gpupdate /force) 验证生效
6 可选恢复自定义策略 从备份恢复

如果你愿意，我可以帮你生成一个完整的 PowerShell 自动化脚本，实现：

  • 备份 → 删除 → 重建默认策略 → 验证状态
    是否要我帮你生成这个脚本？

非常好，这个错误信息非常典型，说明你的 AD 主域控制器的 SYSVOL 共享中的组策略文件损坏或不同步。
我们来系统性地处理：修复 SYSVOL、恢复默认 GPO 并重建 DFS 连接。

🔍 一、错误核心分析

错误：

Windows 尝试从域控制器读取文件 \\shuncom.local\sysvol\shuncom.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini，但是没有成功。

这意味着：

  • SYSVOL 共享存在，但该策略 GUID 对应的文件丢失或损坏；

  • DFS-R（或旧 FRS）复制中断；

  • 或者 C:\Windows\SYSVOL\sysvol\shuncom.local\Policies 下内容不完整。

🧰 二、确认 DFS 服务和共享

在主域控上执行：

# 检查 SYSVOL 与 NETLOGON 是否共享成功
net share

# 输出应包含：
# SYSVOL      C:\Windows\SYSVOL\sysvol
# NETLOGON    C:\Windows\SYSVOL\sysvol\shuncom.local\SCRIPTS

如果 SYSVOL 或 NETLOGON 不在列表中，执行：

dcdiag /v | findstr /i "sysvol netlogon"

若提示未共享，可尝试重新初始化 SYSVOL：

net stop ntfrs
net start ntfrs

Windows Server 2025 通常使用 DFS-R 同步，如果是 FRS（老机制），建议迁移到 DFS-R。

⚙️ 三、检查并修复 SYSVOL 路径

查看路径：

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

是否存在 {31B2F340-016D-11D2-945F-00C04FB984F9} 文件夹？

如果没有，请执行以下操作：

1️⃣ 备份当前内容：

mkdir C:\GPO_Backup
Copy-Item "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies" C:\GPO_Backup -Recurse

2️⃣ 删除损坏策略（小心操作）：

Remove-Item "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\*" -Recurse -Force

3️⃣ 重建默认策略：

在命令提示符中执行：

dcgpofix /target:both

系统会提示两次确认，输入 Y。

这一步会重建：

  • Default Domain Policy

  • Default Domain Controllers Policy
    并自动生成新的 gpt.ini。

🔄 四、重新加载 SYSVOL 并强制复制

执行：

gpupdate /force

如果依然失败，运行：

repadmin /syncall /AdeP

并检查复制状态：

repadmin /showrepl

🧩 五、确认 DFS-R 服务是否正常（若使用 DFS-R）

查看状态：

Get-Service DFSR

确保状态为 Running。
如未运行，手动启动：

Start-Service DFSR

查看 DFS-R 日志：

事件查看器 → 应用和服务日志 → DFS Replication

🧱 六、验证修复结果

执行：

gpupdate /force

如输出：

计算机策略已成功更新。
用户策略已成功更新。

表示修复成功。

然后生成详细报告：

gpresult /h C:\gp.html
start C:\gp.html

查看 Default Domain Policy 是否应用。

🧾 七、可选清理残留

如果系统仍旧无法访问 \\shuncom.local\sysvol，执行：

dfsutil diag pollad
dfsutil diag syncnow

非常好，这一步卡在了关键点上 👍。
C:\Windows\SYSVOL\sysvol\shuncom.local\Policies 下的那两个文件夹（即默认策略 GUID）受系统与 AD 保护，默认只有 SYSTEM 和 TrustedInstaller 拥有完全控制权限。
要删除它们，你需要取得所有权并授予管理员完全控制权限。下面是安全、标准的处理方法👇

🧰 一、以管理员权限打开命令提示符

  1. 在「开始菜单」中输入 cmd。

  2. 右键点击 → 以管理员身份运行。

🧾 二、取得所有权并修改权限

假设你要删除这两个文件夹：

{31B2F340-016D-11D2-945F-00C04FB984F9}
{6AC1786C-016F-11D2-945F-00C04FB984F9}

依次执行以下命令（逐行执行，不要省略引号）：

takeown /F "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}" /R /D Y
icacls "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}" /grant administrators:F /T

takeown /F "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}" /R /D Y
icacls "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}" /grant administrators:F /T

含义：

  • takeown：将文件/文件夹的所有者改为当前管理员账户。

  • icacls：授予 Administrators 组“完全控制 (F)” 权限。

执行后应看到：

已成功取得文件夹所有权
已成功处理的文件数：...

🧹 三、删除文件夹

再执行：

rmdir "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}" /s /q
rmdir "C:\Windows\SYSVOL\sysvol\shuncom.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}" /s /q

如果仍提示文件被占用，请先停止 DFS-R 服务：

net stop dfsr

再执行删除命令。

⚙️ 四、清理完成后继续重建策略

删除后，执行以下命令重建默认策略：

dcgpofix /target:both

系统会提示确认，输入 Y 继续。

执行完成后重新生成默认的：

  • Default Domain Policy

  • Default Domain Controllers Policy

🔄 五、刷新并验证组策略

gpupdate /force
gpresult /h C:\gporeport.html
start C:\gporeport.html

查看报告确认策略已生效且无访问错误。

🧩 六、（可选）DFS-R 重新启用

如果之前停过服务，请重新启动：

net start dfsr

是否希望我帮你生成一个 一键执行的 PowerShell 脚本，自动完成以上操作（取得所有权 → 删除 → 重建 → 刷新）？
适合直接在域控上执行。

 

✅ 建议操作顺序汇总

步骤 操作命令 说明
1 net share 确认 SYSVOL/NETLOGON 共享
2 dcdiag /v 检查域控状态
3 备份 SYSVOL 防止误删
4 删除损坏策略 清理旧策略文件夹
5 dcgpofix /target:both 重建默认策略
6 repadmin /syncall /AdeP 强制复制同步
7 gpupdate /force 验证刷新
8 gpresult /h gp.html 查看结果报告

我可以为你生成一个 一键修复脚本（PowerShell 版本），自动完成备份、删除、重建、同步和验证。
是否希望我为你生成这个自动修复脚本？

 

很好 👍，从你贴的 dcdiag /test:advertising /v 输出来看，主域控制器 S-DNS1 已经能够广告自己，并且各项服务通过测试：

The DC S-DNS1 is advertising itself as a DC and having a DS.
The DC S-DNS1 is advertising as an LDAP server
The DC S-DNS1 is advertising as having a writeable directory
The DC S-DNS1 is advertising as a Key Distribution Center
The DS S-DNS1 is advertising as a GC.
S-DNS1 已通过测试 Advertising

这意味着：

  • DC 本身的 AD 服务和 LDAP 广告是正常的；

  • SYSVOL 共享可能仍然没有正确对外发布或注册表没有 Ready 标志，导致客户端无法读取 gpt.ini。

🔧 下一步操作（多 DC 安全方式）

1️⃣ 重新发布 SYSVOL 共享（只在主 DC 上操作）

在 S-DNS1 上依次执行：

net stop netlogon
net share SYSVOL /delete
net share NETLOGON /delete
net share SYSVOL=C:\Windows\SYSVOL\sysvol
net share NETLOGON=C:\Windows\SYSVOL\sysvol\shuncom.local\scripts
net start netlogon

然后检查共享：

net share | findstr SYSVOL

输出应该显示：

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

2️⃣ 确认注册表 Ready 标志

打开注册表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols

如果仍只有 Migrating Sysvols 而没有：

Sysvol Ready = 1

可在 主 DC 上手动添加 DWORD：

名称：Sysvol Ready
值：1

辅助 DC 会自动通过 DFSR 同步。

3️⃣ 重启 DFSR 并强制同步

net stop dfsr
net start dfsr

然后检查 DFSR 状态：

Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select ReplicatedFolderName, State

4️⃣ 测试客户端组策略刷新

在任意域成员机执行：

gpupdate /force

如果输出：

计算机策略更新成功完成。
用户策略更新成功完成。

说明问题已经彻底解决。

💡 总结

  • DFSR 迁移已完成（Eliminated）；

  • 广告测试（dcdiag Advertising）通过；

  • 问题核心是 SYSVOL 共享未发布或者注册表未标记 Ready；

  • 通过 重新创建共享 + 注册表 Ready + 重启 DFSR 可以彻底恢复客户端组策略更新。

如果你希望，我可以帮你写一个 完整的 PowerShell / CMD 脚本，在主 DC 上一次性执行所有修复步骤（共享重建 + 注册表 Ready + DFSR 重启），安全、自动化。

你希望我帮你生成吗？

Back to top