从作用域看 Windows 域组策略：OU、筛选与结果核对

GPMC 里能看到设置，客户端却没变化，先别急着再刷一次策略。一个 GPO 链接在什么位置、针对哪个账户，往往比设置本身更值得先查。以下讨论的是 AD DS 域组策略，不包括 Intune 等设备管理策略。

用户和计算机，各走各的作用域

组策略对象（GPO）里有两套彼此独立的配置：Computer Configuration 面向计算机账户，通常在开机处理；User Configuration 面向用户账户，通常在用户登录时处理。把浏览器策略配在用户配置下，再把 GPO 链到一台服务器所在的 OU，不能因此让登录者自动拿到该设置。要先问清楚：要改变的是哪一类对象，它在 AD 的什么位置。

域策略不是从某个 OU 开始直接生效。Windows 会按本地策略、站点、域、OU 的顺序处理；嵌套 OU 中，父 OU 的链接先处理，子 OU 随后处理。后处理的同一项设置通常会覆盖先处理的设置。微软的 Group Policy processing 文档 对这个顺序和继承关系有完整说明。

因此，OU 既是组织目录对象的方式，也是实际的策略边界。把所有电脑放进一个很大的 OU，再依赖名称、脚本或人工记忆去区分，时间久了很难看清策略来源。更稳妥的做法是先按管理边界建立 OU，例如工作站、服务器和需受特殊限制的终端；再把只服务于该边界的 GPO 链接到相应 OU。域根链接仍有用途，例如所有域成员都需要的基础安全项，但不适合承载每一台机器的个性化设置。

链接之后，还有筛选和继承

链接只是第一层。安全筛选决定 GPO 是否对某个用户或计算机主体有读取和应用权限；WMI 筛选则在目标计算机上计算条件，条件为真才应用。它们适合处理少量例外，例如某个已明确维护的安全组，或确有必要按系统条件区分的设置。筛选不是单个策略项的开关：同一 GPO 一旦通过筛选，其中符合类别的设置会一起参与处理。条件越多，排查成本越高，尤其是 WMI 查询还会增加策略处理时间。

用户策略还有一个容易漏掉的权限：计算机账户也需要能读取 GPO。把 Authenticated Users 从安全筛选移除后，不能只检查目标用户有没有应用权限，还要检查计算机的读取权限。微软有对应的故障说明。

还要留意用户对象和计算机对象并不总在同一个 OU。某台文件服务器可能在 Servers OU，而登录它的管理员用户在 People OU。前者会决定计算机配置，后者会决定用户配置。把“在这台服务器上看到的桌面设置”一概归因于服务器 OU，是很常见的误判。只有启用回环处理时，计算机所在 OU 才会改变用户配置的常规取值路径。

Block Inheritance 会阻断一般继承；被标记为 Enforced 的链接能越过这个阻断。回环处理则是另一回事：合并模式会在常规用户策略后再处理计算机作用域中的用户策略，替换模式直接使用后者。它适合机房、终端服务器等需要统一登录环境的场景。启用前把模式记清楚，否则报告里出现的策略来源会很难理解。

到目标机器上看结果

在目标用户的 PowerShell 会话中先查看用户结果：

gpresult /scope user /r
gpresult /scope user /h "$env:TEMP\gpresult-user.html"

第一条列出摘要，第二条把 HTML 报告写入当前用户的临时目录。计算机结果可在管理员 PowerShell 中用 gpresult /scope computer /r 查询。若提权时换了账户，不要把那个管理员的用户结果当成原登录者的结果。报告可能包含域名、账户与策略细节，不宜直接公开上传。gpresult 参数说明也列出了指定用户和报告格式的用法。

确认变更确实应当落到本机后，才考虑刷新。下面分别请求计算机与当前用户策略更新；计算机刷新需要相应权限：

gpupdate /target:computer
gpupdate /target:user

它只请求本机刷新，不保证修复 DNS、域控制器可达性或 AD/SYSVOL 复制问题。远程批量刷新也应在确认作用域和网络条件后再做，避免把“刷新”误当成策略设计正确的证明。

报告里若出现“拒绝访问”或“已筛选”，先区分它属于哪一条 GPO、哪个主体和哪种筛选条件；如果报告显示策略已应用而设置仍不符合预期，再查同一项是否被后续 GPO 覆盖。这个顺序能避免直接去改安全筛选，反而扩大了实际作用域。

有些设置必须重新登录或重启才能落实；gpupdate 返回成功，不代表所有设置已经在当前会话里生效。保留变更前后的报告，比重复刷新更便于核对究竟是哪条策略改变了结果。