强制执行优先于阻止继承。强制执行是GPO级属性，可穿透OU级的阻止继承设置；阻止继承仅对非强制GPO生效，无法屏蔽已启用强制执行的上级GPO。
组策略“强制执行”和“阻止继承”谁优先？
强制执行（enforced）优先于阻止继承（block inheritance）。不是“谁先谁后”的问题，而是设计上强制执行会穿透阻止继承的层级限制——只要上级策略启用了强制执行，下级即使设置了阻止继承，该策略仍会生效。
常见错误现象：Gpresult /h report.html 显示某 GPO 被“已应用”，但目标 OU 明确勾选了“阻止继承”；或者用 gpupdate /force 后策略仍生效，怀疑设置没生效。
- 强制执行是 GPO 级别的属性（在 GPMC 中右键 GPO → “属性” → “常规”选项卡 → 勾选“此 GPO 的设置为强制执行”）
- 阻止继承是 OU 级别的设置（右键 OU → “阻止继承”）
- 一个 OU 可以阻止来自父容器的 GPO，但无法阻止被标记为强制执行的 GPO
怎么确认某个 GPO 是否被设为强制执行？
不能只看 OU 设置，必须逐个检查上游 GPO 是否启用强制执行。GPMC 默认不直观显示该状态，容易漏查。
实操建议：
- 在 GPMC 中展开“组策略对象”，右键每个可能影响目标 OU 的 GPO → “属性” → 切换到“常规”选项卡，查看是否勾选“此 GPO 的设置为强制执行”
- 用 PowerShell 快速筛查：
Get-GPO -All | Where-Object {$_.GpoStatus -eq "Enabled" -and $_.IsEnforced -eq $true} | Select DisplayName, Path, IsEnforced - 注意：
IsEnforced为$true表示该 GPO 启用了强制执行，它会无视下游的阻止继承
想让某个 OU 完全不应用某强制 GPO，怎么办？
阻止继承无效，唯一可靠方式是使用“安全筛选”或“WMI 筛选”排除该 OU 下的对象，或者直接在 GPO 内部禁用相关策略设置。
常见误区：试图在子 OU 上再建一个“冲突 GPO”来覆盖——如果原 GPO 是强制执行，且链接在更高层级（如域根），新 GPO 很可能因链接顺序或未启用强制而失败。
- 首选方案：编辑那个强制 GPO，在“安全筛选”中移除该 OU 下的用户/计算机组，或添加一个“拒绝应用组策略”权限给对应安全组
- 次选方案：用 WMI 筛选（例如
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.%"）配合 OU 特征做条件过滤 - 避免方案：在子 OU 创建同名策略并设为强制——GPO 不按名称合并，而是按链接顺序+强制标志叠加，极易引发不可控行为
链接顺序和强制执行共同作用时，策略如何叠加？
链接顺序（Link Order）只在无强制执行的 GPO 之间起作用；一旦存在强制执行 GPO，它会在所有非强制 GPO 之前处理，且不受链接顺序影响。
性能与调试提示：
- 用
gpresult /r查看“应用的组策略对象”列表，带[Enforced]标记的就是穿透阻止继承的策略 - 多个强制 GPO 按链接顺序从高到低依次应用，后链接的强制 GPO 会覆盖前链接的同名设置（如相同的注册表策略路径）
- 不要依赖“禁用链接”来临时规避——禁用链接等同于移除策略，但若链接在域根且面向全公司，误操作影响面极大
最易被忽略的一点：强制执行状态不会随 GPO 复制自动同步，跨域控制器间可能短暂不一致；生产环境调整前，务必在所有 DC 上用 repadmin /syncall 或等待默认复制完成后再验证。
