一、先建模型：一个 GPO 从定义到生效，要过几道关
组策略"不生效"是个含糊的描述，因为一个 GPO 从定义到真正作用到客户端，中间隔着好几道关，任何一道断了都会表现为"不生效"。先把链路建立起来：
存储在两处。一个 GPO 由两部分组成：GPC（Group Policy Container，存在 AD 数据库里，保存版本号、GUID、链接关系）和 GPT（Group Policy Template，存在 SYSVOL 里，保存实际的策略文件）。客户端要同时读到这两部分，缺一不可。
客户端处理链路。计算机启动 / 用户登录时，Group Policy Client 服务：先通过 LDAP 从 AD 拿到"该计算机 / 用户应该应用哪些 GPO"的列表 → 再通过 SMB 连到 SYSVOL 读取策略文件 → 交给对应的客户端扩展（CSE，Client-Side Extension）逐项应用。
优先级规则（LSDOU）。应用顺序是 Local → Site → Domain → OU，后应用的覆盖先应用的。OU 嵌套时，越靠近对象的 OU 优先级越高。理解了这条，才能看懂"明明设了，为什么没生效"——很可能是被更高优先级的 GPO 覆盖了。
所以排查的第一原则是：先别改配置，先定位"断在哪一道关"。
二、第一动作：gpresult 定方向
gpresult是排障的起点，它直接告诉你"客户端到底应用了哪些 GPO、哪些被拒绝了"。
gpresult /r—— 文本摘要，分计算机配置和用户配置两段
gpresult /h C:\gpresult.html—— 生成完整 HTML 报告，信息更全
看输出时，重点分辨三种情况，它们指向完全不同的根因：
| gpresult 表现 | 含义 | 排查方向 |
|---|---|---|
| GPO 根本没出现在列表里 | 链接 / 继承问题 | 查 OU 链接、Block Inheritance、Enforced |
| 出现但标注 Denied（Security / WMI Filter） | 被筛选拒绝 | 查安全筛选、WMI 筛选器 |
| 显示 Applied，但客户端就是没效果 | 应用了但没落地 | 查首选项"仅应用一次"、慢链接、CSE 需重启 |
把范围先砍到这三类之一，再往下钻，效率完全不同。
三、六大高频根因
根因一：链接问题
GPO 必须"链接"到对象所在的站点 / 域 / OU 才可能生效。两个最常见的坑：GPO 压根没链接到目标 OU；或者链接存在，但Link Enabled = No（链接被禁用）。用 GPMC 或Get-GPInheritance -Target "OU=目标,DC=corp,DC=example,DC=com"看继承关系和链接状态。
根因二：安全筛选（最经典，MS16-072 的坑）
这是"GPO 突然不生效"的第一大元凶。2016 年 6 月的安全更新（MS16-072，KB3159398）改变了组策略的安全行为：GPO 现在要求计算机账户对它拥有读取权限。在此之前，很多管理员为了"收紧权限"，把安全筛选里的 “Authenticated Users” 移除了，只留了特定的用户 / 组——更新之后，这类 GPO 对计算机配置就不再生效。
排查：在 GPMC 的"委派"标签里看安全筛选，确认保留了 “Authenticated Users”（读取权限），或者明确加入了 “Domain Computers”。这是版本升级后 GPO 大面积失效的最常见根因。
根因三：WMI 筛选器返回 false
如果 GPO 配了 WMI 筛选器（WMI Filter），而筛选器的 WQL 查询在目标机器上返回 false，GPO 就不会应用。gpresult会显示 “Filtering: Denied (WMI Filter)”。排查：把筛选器的 WQL 拿到目标机器上手动跑一遍验证结果，比如Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE '%Server%'"，看是不是真的匹配。
根因四：继承被阻止 / 强制
两个相对立、又常被搞混的机制：Block Inheritance（阻止继承）让上级的 GPO 不下来；Enforced（强制）让上级 GPO 无视下级阻止、强制下来。当"上级设了但下级不生效"或反过来时，先查这两个。GPMC 里 OU 右键"阻止继承"，GPO 右键"强制"。
根因五：SYSVOL 复制未同步
多域控环境里，客户端可能连到一台 SYSVOL 还没同步完的域控。表现是"有的机器生效、有的不生效"，非常迷惑。诊断：对比各域控上 GPT 的版本号是否一致——看\\DC1\SYSVOL\corp.example.com\Policies\{GUID}\GPT.INI里的 version 字段；或直接查 DFSR 积压：
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC1 /receivingmember:DC2
积压非零，说明复制还没追平，等它同步完（或先repadmin /syncall触发）再验证。
根因六：环回处理（Loopback）设错了
环回处理让"用户策略"由计算机所在 OU决定，而不是用户所在 OU，常用于终端服务器 / RDS 这类共享场景。它有两个模式，语义要分清：
- Replace：完全忽略用户所在 OU 的用户 GPO，只用计算机所在 OU 的 GPO 用户配置
- Merge：先应用用户所在 OU 的用户 GPO，再叠加计算机所在 OU 的 GPO 用户配置，后者优先
搞反了 Replace / Merge，或者忘了某台共享机器开了环回，都会导致"用户策略莫名不生效"。
四、三个容易被忽略的深坑
深坑一：首选项（GPP）的"仅应用一次"。组策略首选项里很多项默认勾选 “Apply once and do not reapply”（仅应用一次，不再重新应用）。后果是：策略第一次应用后，就算客户端手动把值改回去了，GPO 也不会再纠正它。这常常被误报成"GPO 不生效"，其实是"它只保证第一次"。排查时确认该项是否勾了"仅应用一次"，去掉勾选后强制gpupdate /force再看。
深坑二：gpupdate 不是万能的。部分 CSE 只在计算机启动或用户登录时处理——典型如软件安装、文件夹重定向、启动 / 登录脚本。对这些策略，gpupdate /force刷新不了，必须重启或重新登录才生效。别以为跑了 gpupdate 没反应就是故障。
深坑三：慢链接检测。组策略有"慢链接"检测（默认阈值 500 kbps），当客户端判定连接是慢速时，脚本、软件安装、文件夹重定向等 CSE 默认跳过。远程站点 / VPN 环境下"策略不生效"，先排除是不是撞上了慢链接。
五、防复发 + 验证习惯
- 改完必验：任何 GPO 变更后，在目标机器上
gpresult /r确认 Applied，而不是"设了就走" - 测试 OU 先行：新策略先在测试 OU 验证，再推广到生产 OU
- 变更留痕：GPO 的每次修改记录在案，出问题能回溯"最近改了什么"
- SYSVOL 健康监控：把 DFSR 复制健康纳入日常巡检，避免"半同步"造成的诡异不生效
