组策略（GPO）实务入门——原理、生效确认与 Intune 分工

“改了 GPO 却不生效”“执行了 gpupdate 设置还是没变”“在开发机上能跑的应用，只在客户的电脑上跑不起来”。把哪些 GPO 成为应用对象、哪个设置优先、什么时候被处理分开来看，这类问题就容易查多了。

组策略是在组织内下发和管理 Windows 设置的机制。仅凭“已经用 GPO 下发了”这一句说明，还看不出这台电脑或这个用户实际生效了什么。需要把下发一侧的配置和接收一侧的结果对照起来看。

本文是面向两类读者的实务入门：接手了 AD 环境的中小企业信息系统负责人，以及要把业务应用部署到加域电脑上的开发者。内容涵盖应用顺序、生效时机、用 gpresult 和事件日志排查、ADMX 与中央存储，以及与 Intune 的分工。说明基于 2026 年 8 月时点的一手资料。

按遇到的问题查阅

第一次阅读时，建议先在第 2 章掌握术语，在第 3～4 章理解原理，再进入第 5 章的确认步骤。如果正在排查，可以从第 5 章入手，再根据结果回到优先顺序或生效时机的说明。

1. 先说结论

“哪个设置获胜”和“什么时候送达”是两个不同的问题

组策略按本地→站点→域→OU（LSDOU）的顺序处理，同一设置发生冲突时后处理的获胜。本地 GPO 是最弱的一层。不过，阻止继承和强制会改变这个默认流程。¹

生效分两条路径：启动时和登录时的前台处理，以及默认约 90 分钟加 0～30 分钟随机偏移的后台刷新。域控制器的后台刷新间隔默认是 5 分钟。gpupdate /force 只是重新应用全部设置，并不是能把只在登录或重启时才处理的设置也当场应用的万能命令。²³

在反复改配置之前，先确认接收端的结果

排查的起点是 gpresult /h 输出的 RSoP 报告。要确认已应用的 GPO、被拒绝的 GPO 及其原因，以及每个设置的“优先 GPO”。要深入追查处理失败或延迟时，使用 GroupPolicy 运行日志。⁴⁵

管理模板的设置原则上写入注册表的 Software\Policies 等位置，支持策略的应用会优先采用这些值，而不是自己的设置。“未配置”不写入任何值。不过也存在写到专用键之外的设置，因此发现值残留时要一并确认写入位置。⁶

统一管理方式和应用所依赖的前提

在域环境的运维中，ADMX 定义集中到 SYSVOL 下的 PolicyDefinitions 中央存储。这是让 GPMC 引用统一模板定义的机制。⁷

GPO 与 Intune 按终端的身份基础设施和所在位置分工使用。在混合环境中要避免同一设置的双重配置，按领域确定管理主体。迁移时的分类可以使用 Group Policy analytics。⁸⁹

对开发者来说，GPO 同样是环境规格的一部分。执行策略、防火墙的本地规则合并、代理与驱动器配置等会改变应用前提的设置，都是集中下发的。遇到“只在客户环境跑不起来”时，要用报告和实际值确认这些前提。¹⁰¹¹

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 29 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 什么是组策略——本地 GPO 与域 GPO

组策略是管理员集中定义 Windows 设置、并应用到目标计算机或用户的机制。一组设置的集合称为 GPO（组策略对象）。

首先要区分“在这台电脑内部管理的本地 GPO”和“从 AD 下发的域 GPO”。

设置放在哪里：本地还是域

工作组（未加域）的电脑只处理本地 GPO。¹ 也就是说，实务中讲“由 GPO 管理”时，几乎都是指域 GPO。

flowchart TB
    accTitle: 工作组电脑与加域电脑各自处理的 GPO
    accDescr: 工作组电脑只处理本地 GPO，加域电脑除本地 GPO 之外还会处理从 Active Directory 下发的域 GPO
    pc{"电脑属于哪种加入形态?"}
    pc -->|工作组| wg["只处理本地 GPO"]
    pc -->|加入域| dom["本地 + 域 GPO"]
    dom -.-> note["实务中的 GPO 几乎都是域 GPO"]

图1：工作组电脑只处理本地 GPO，加域电脑还会处理域 GPO。

设置的对象：电脑还是用户

任何 GPO 的内容都分为两大类。

• 计算机配置：对登录这台电脑的任何人都生效的设置。在启动时应用。
• 用户配置：无论该用户登录到哪台电脑都生效的设置。在登录时应用。

“设置是绑定到电脑还是绑定到人”这条主线，在后面的应用顺序和生效确认中会一直出现。有些设置在两种配置下都有同名项，因此查找设置时要养成两边都看的习惯。

flowchart TB
    accTitle: GPO 内容的两大类
    accDescr: 任何 GPO 都包含计算机配置和用户配置两大类，计算机配置在启动时应用并对登录这台电脑的任何人生效，用户配置在登录时应用并且无论该用户登录到哪台电脑都生效
    gpo["GPO 的内容"] --> comp["计算机配置"]
    gpo --> user["用户配置"]
    comp --> boot["启动时应用"]
    user --> logon["登录时应用"]
    boot -.-> anyone["对登录的任何人都生效"]
    logon -.-> anypc["在任何电脑上都生效"]

图2：GPO 分为绑定到电脑的计算机配置和绑定到人的用户配置两大类。

3. 应用机制——LSDOU 的“后处理者胜出”与继承控制

3.1. LSDOU：本地→站点→域→OU

在加域电脑上，GPO 按以下顺序处理。¹

1. 本地 GPO
2. 链接到站点的 GPO
3. 链接到域的 GPO
4. 链接到 OU（组织单位）的 GPO——从上层 OU 开始依次处理，最后处理目标计算机或用户直接所属的那个 OU 的 GPO

取首字母的叫法就是 LSDOU。它表示的不是“优先级从高到低”，而是处理的顺序。

当多个 GPO 配置了同一设置时，后处理的 GPO 获胜。不冲突的设置则单纯叠加在一起。¹

在这个默认顺序下，离目标最近的 OU 的 GPO 最强，本地 GPO 最弱。“用 gpedit.msc 改了却又变回去”正是符合规格的行为。改变继承的例外在 3.2 节确认。

flowchart TB
    accTitle: LSDOU 的处理顺序与后处理者胜出
    accDescr: GPO 按本地、站点、域、OU 的顺序处理，冲突时后处理的 GPO 获胜，因此离目标最近的 OU 的 GPO 最强而本地 GPO 最弱
    l["1. 本地 GPO"] --> s["2. 站点"]
    s --> d["3. 域"]
    d --> ou["4. OU（从上层依次处理）"]
    ou --> win["冲突时后处理者胜出"]
    win -.-> strongest["离目标近的 OU 的 GPO 最强"]
    win -.-> weakest["本地 GPO 最弱"]

图3：LSDOU 表示的是处理顺序，同一设置发生冲突时后处理的 GPO 获胜。

同一位置上，链接顺序编号小的获胜

当同一站点、域或 OU 上链接了多个 GPO 时，要查看 GPMC“链接的组策略对象”选项卡中的链接顺序。

编号最小的 GPO 最后处理，优先级也最高。关键是不要把它读成“编号小所以先处理”。¹

flowchart TB
    accTitle: 同一位置存在多个 GPO 时的链接顺序
    accDescr: 当同一站点或域或 OU 上链接了多个 GPO 时处理顺序由 GPMC 的链接顺序决定，编号最小的 GPO 最后处理并获得最高优先级
    multi["同一位置有多个 GPO"] --> tab["由 GPMC 的链接顺序决定"]
    tab --> last["编号最小的 GPO 最后处理"]
    last --> win["后处理者胜出，优先级最高"]

图4：在同一链接位置上，链接顺序编号最小的 GPO 最后处理并获胜。

3.2. 阻止继承与强制（Enforced）

阻止继承和强制，是给 3.1 节的默认顺序制造例外的机制。要把在哪里设置和阻止什么分开来读。¹

• 阻止继承：设置在域或 OU 上，可以阻断来自上层的 GPO 继承。它是应对“只有这个 OU 不想接受全公司标准”的工具。
• 强制（Enforced，旧称：禁止覆盖）：设置在 GPO 的链接上，即使下层阻止了继承，该 GPO 也必定被应用，而且不会被下层的 GPO 覆盖。阻止继承与强制发生冲突时，强制获胜。¹

flowchart TB
    accTitle: 阻止继承与强制的关系
    accDescr: 阻止继承会阻断来自上层的 GPO 继承，但被强制的 GPO 即使下层阻止了继承也必定应用，而且不会被下层的 GPO 覆盖
    upper["来自上层的 GPO"] --> blocked{"下层是否阻止继承?"}
    blocked -->|否| inherit["照常继承"]
    blocked -->|是| enforced{"GPO 是否设置了强制?"}
    enforced -->|否| stop["继承被阻断"]
    enforced -->|是| apply["必定被应用"]
    apply -.-> noover["不会被下层的 GPO 覆盖"]

图5：阻止继承会阻断来自上层的继承，但被强制的 GPO 会越过阻止必定应用。

强制要限定使用目的

强制会改变默认的“后处理者胜出”，用得多了，即使读 RSoP 也会出现越来越多与直觉不符的结果。常规做法是只把它用在全公司必须遵守的安全设置等场合。

以上是继承与优先顺序的内容。至于 GPO 能不能应用到目标上，还要看下面的安全筛选。

3.3. 安全筛选

应用需要同时具备“读取”和“应用”权限

除了链接位置以外，还可以按 GPO 限定应用给谁。目标用户或计算机必须对该 GPO 同时拥有“读取”和“应用组策略”两项访问权限。¹³

默认情况下，同时包含用户和计算机的 Authenticated Users 拥有这两项权限，因此链接位置之下的所有对象都是应用对象。把范围收窄到特定安全组，就是安全筛选。

筛选作用于整个 GPO。它不是为 GPO 内的每个设置分别指定不同对象的机制。¹³

面向用户的 GPO 要保留电脑的读取权限

收窄应用对象时，不要把 Authenticated Users 的“读取”也一并去掉。因为自 MS16-072（2016 年）以后，面向用户的策略是在计算机的安全上下文中获取的。如果电脑读不到 GPO，即使目标用户拥有两项权限也不会被应用。¹⁴

需要的权限分成下面两部分来考虑。

• 给目标组授予读取 + 应用组策略。
• 给 Authenticated Users 或 Domain Computers 只保留读取。不需要“应用”权限。¹⁴

flowchart TB
    accTitle: 安全筛选的应用判定
    accDescr: GPO 要被应用，目标用户或计算机必须同时拥有读取和应用组策略两项权限，面向用户的 GPO 还需要计算机账户能够读取
    target["GPO 链接位置之下的对象"] --> perm{"是否同时有读取和应用权限?"}
    perm -->|否| deny["因筛选而被拒绝"]
    perm -->|是| usergpo{"是面向用户的 GPO?"}
    usergpo -->|否| apply["被应用"]
    usergpo -->|是| comp{"计算机能否读取?"}
    comp -->|是| apply
    comp -->|否| deny2["不被应用（MS16-072）"]

图6：应用需要“读取”和“应用组策略”两项权限，面向用户的 GPO 还需要计算机账户具备读取权限。

改动组成员之后，要用新令牌来确认

“明明是面向计算机的设置，却只把用户加进了组”这种搞错对象的情况，是常见的绊脚石。首先要确认设置是面向电脑的还是面向用户的。

另一个问题是“已经从组里移除了却还在继续应用”。成员身份是用登录时生成的安全令牌来判定的，光等后台刷新不会改变。

用户的组变更要注销后重新登录，计算机的变更要重启，拿到新令牌之后才会体现到筛选上。

flowchart TB
    accTitle: 组变更体现到筛选上的过程
    accDescr: 组成员身份是用登录时生成的安全令牌判定的，因此用户侧的变更要重新登录、计算机侧的变更要重启，拿到新令牌之后才会体现到筛选上
    change["修改组的成员"] --> old["令牌不换就不会生效"]
    old --> u["用户重新登录"]
    old --> c["计算机重启"]
    u --> token["用新令牌判定"]
    c --> token
    token --> ok["体现到筛选上"]
    old -.-> bg["后台刷新无法解决"]

图7：组变更要在注销或重启生成新令牌之后，才会体现到筛选上。

共享电脑的进阶用法：环回处理

在共享电脑或远程桌面服务器上，有时需要“对登录这台电脑的所有人，都把用户配置替换掉”。为此提供的特殊模式就是环回处理。

它根据计算机所在的位置来应用用户设置，有替换和合并两种模式。这是用在自助服务终端或教室电脑上的进阶功能，本文只介绍它的存在。¹⁵

flowchart TB
    accTitle: 环回处理的思路
    accDescr: 环回处理是根据计算机所在位置应用用户配置的特殊模式，有替换和合并两种模式，用在共享电脑或自助服务终端等希望让所有登录者都生效同一套用户设置的场景
    shared["共享电脑、自助服务终端等"] --> lb["环回处理"]
    lb --> base["按计算机所在位置决定"]
    base --> rep["替换模式"]
    base --> mrg["合并模式"]
    lb -.-> aim["对所有登录者都生效"]

图8：环回处理是根据计算机所在位置应用用户配置的特殊模式，有替换和合并两种模式。

4. 什么时候生效——前台处理与后台刷新

改了设置之后，也可能只是应用时机还没到。这里把终端能否连上 DC和该设置在什么时机被处理分开来看。²

区分启动登录时的应用和运行中的刷新

前提是能够到达 DC

只要是能够到达域控制器、并且正在运行的终端，支持后台刷新的设置默认在 2 小时左右就会全部送达。对于离线终端或未连 VPN 的外带电脑，在下次连上 DC 之前都送不到。

只在前台处理时才应用的设置，还需要额外等待启动或登录。

gpupdate 与 /force 的区别

着急时可以在目标电脑上执行 gpupdate。它通常只应用发生了变更的设置，加上 /force 则无论有没有变更都重新应用全部设置。³

rem 只更新变更部分（通常这样就够了）
gpupdate

rem 重新应用全部设置（怀疑缓存状态时）
gpupdate /force

flowchart TB
    accTitle: 能否到达 DC 与设置送达的方式
    accDescr: 能够到达域控制器且正在运行的终端在 2 小时左右就会收到支持后台刷新的设置，而离线或未连 VPN 的外带电脑要等到下次连上 DC 才能收到
    pc{"能否到达 DC?"}
    pc -->|能| ok["2 小时左右全部送达"]
    pc -->|不能| ng["连上之前送不到"]
    ng -.-> ex["离线或未连 VPN 的外带电脑"]

图9：能够到达 DC 且正在运行的终端在 2 小时左右就会收到，离线终端要等到下次连上 DC。

即使加 /force，也省不掉前台处理

面向用户的软件安装和文件夹重定向只在登录时处理，面向计算机的软件安装只在启动时处理。³

gpupdate 的 /logoff 用于在更新后注销，/boot 用于在更新后重启。加了 /force 仍然没有变化时，请确认该设置是不是需要登录或重启的类型。³

flowchart TB
    accTitle: 设置生效的路径
    accDescr: GPO 的变更如果属于支持后台刷新的设置就会在默认约 90 分钟加 0～30 分钟偏移后送达，只在前台处理时才应用的设置需要等待启动或登录，着急时执行的 gpupdate 对前台处理的设置还需要配合 /logoff 或 /boot
    change["修改 GPO"] --> kind{"是否支持后台刷新?"}
    kind -->|是| bg["约 90 分钟 + 0～30 分钟后更新"]
    kind -->|否| fg["启动或登录时应用"]
    bg --> done["生效"]
    fg --> done
    rush["着急时"] -.-> upd["执行 gpupdate"]
    upd -.-> force["用 /force 全部重新应用"]
    upd -.-> reboot["前台处理要用 /logoff 或 /boot"]

图10：后台刷新只能送达支持后台处理的设置，只在前台处理时才应用的设置在 gpupdate 之后仍需注销或重启。

5. 不生效时的排查——gpresult、事件日志与注册表

用来确认的工具各有分工。gpresult 看应用的结果，运行日志看处理的经过，注册表看实际写入的值。不要一上来就改配置，而要从结果倒推原因。

5.1. 用 gpresult /h 确认 RSoP

多个 GPO 叠加后的最终结果称为 RSoP（策略结果集）。用系统自带的 gpresult，从管理员权限的命令提示符输出 HTML 报告，会更容易阅读。⁴⁵

下面的示例要先准备好输出目标文件夹 C:\temp 再执行。阅读报告时，还要确认这份结果对应的确实是想调查的电脑和用户。

rem 把用户和计算机两侧的 RSoP 输出为 HTML 报告
gpresult /h C:\temp\gp-report.html /f

rem 只在控制台查看概要时
gpresult /r
gpresult /scope computer /r

不要只看到“已应用”就结束确认

报告要按下面三点依次查看。即使目标 GPO 出现在列表里，只要目标设置被别的 GPO 覆盖了，值就不会是期望的样子。

1. 已应用的 GPO 列表——目标 GPO 是否在其中
2. 被拒绝的 GPO 列表及原因——会显示安全筛选、WMI 筛选器、空 GPO 等未被应用的原因⁵
3. 每个设置的“优先 GPO”——目标设置最终由哪个 GPO 的值决定。如果是别的 GPO 获胜，就回到第 3 章重新审视优先顺序

flowchart TB
    accTitle: RSoP 报告最先要看的三点
    accDescr: 在 gpresult 的报告中先看已应用的 GPO 列表里有没有目标 GPO，接着确认被拒绝的 GPO 列表及原因，最后用每个设置的优先 GPO 定位究竟是哪个 GPO 的值获胜
    rep["打开 RSoP 报告"] --> one["1. 已应用的 GPO 列表"]
    one --> two["2. 被拒绝的 GPO 及原因"]
    two --> three["3. 每个设置的优先 GPO"]
    three -.-> review["别的 GPO 获胜就重新审视"]

图11：RSoP 报告按已应用的 GPO、被拒绝的 GPO 及原因、每个设置的优先 GPO 的顺序查看。

5.2. GroupPolicy 运行日志

追查处理的失败与延迟

仅凭 gpresult 查不出的失败，以及处理耗时过长的问题，要在事件查看器的 GroupPolicy 运行日志中确认。

位置是“应用程序和服务日志 > Microsoft > Windows > GroupPolicy > Operational”。日志名为 Microsoft-Windows-GroupPolicy/Operational，其中记录了处理从开始到结束的过程、已应用和被拒绝的 GPO 列表以及拒绝原因。⁵

用 ActivityID 定位到单次处理

每一次策略处理都会分配一个唯一的 ActivityID。Microsoft 给出的步骤是，从系统日志的警告和错误中取得 ActivityID，再用自定义视图只筛出同一次处理的事件。这样就不会混入别的处理的记录，可以完整跟踪一次处理从开始到结束的过程。⁵

flowchart TB
    accTitle: GroupPolicy 运行日志的筛选步骤
    accDescr: GroupPolicy 运行日志会为每一次策略处理分配唯一的 ActivityID，因此先从系统日志的警告或错误中取得 ActivityID，再用自定义视图只筛出这一次处理的事件来阅读
    sys["系统日志的警告与错误"] --> aid["取得 ActivityID"]
    aid --> cv["用自定义视图筛选"]
    cv --> one["阅读单次处理的事件"]
    one -.-> rec["已应用和被拒绝的 GPO 列表带原因"]

图12：运行日志的读法是从系统日志取得 ActivityID，再用自定义视图只筛出一次策略处理的事件。

5.3. 与注册表 Policies 键的关系

管理模板（见下一章）的策略，最终会作为注册表值写入。写入位置原则上是下面这些策略专用键。⁶

• HKEY_LOCAL_MACHINE\Software\Policies（计算机配置。推荐位置）
• HKEY_CURRENT_USER\Software\Policies（用户配置。推荐位置）
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

策略值比应用自己的设置先被读取

支持策略的应用的行为是：先读 Policies 键，有值就优先采用，没有则使用自己的设置或默认值。处于“未配置”的策略不会向注册表写入值。⁶

也就是说，使用策略专用键的管理模板并不是改写应用自身的设置、留下“刺青（tattooing）”，而是把强制值放到另一个位置。一旦取消配置，应用就能回到遵循自身设置的状态。

flowchart TB
    accTitle: 策略值与应用设置的优先关系
    accDescr: 支持策略的应用会先读 Policies 键，有值就优先采用，没有则使用自己的设置或默认值，而处于未配置的策略不会向注册表写入任何内容
    app["支持策略的应用读取设置"] --> haspol{"Policies 键中有值?"}
    haspol -->|有| pol["优先采用策略值"]
    haspol -->|没有| pref["使用自己的设置或默认值"]
    notconf["未配置的策略"] -.-> nowrite["不向注册表写入任何内容"]

图13：策略不是改写应用自身的设置，而是让放在另一处的强制值被优先读取的机制。

注意写到专用键之外的设置会留下值

并不是所有策略都写到专用键。 例如“启用 Win32 长路径”会写入 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 下的 LongPathsEnabled。较早年代的模板和第三方模板中，也有写到任意路径的。

这类设置即使取消了策略配置，值也会留下。请通过 ADMX 的定义、设置的说明文本和 gpresult 的报告，确认目标设置究竟写到哪个键。

通过脚本或组策略首选项（Preferences）写到专用键之外的值，同样是普通的注册表值。与策略专用键不同，要把它们当作取消配置后仍会残留的值来对待。

确认实际的写入位置

先查看 Policies 键中的实际值。不过，不能因为那里没有就断定“没有受 GPO 影响”，还要确认是不是写到专用键之外的设置。下面的命令是查看多数策略所用的 Policies 下方的例子。

# 直接确认由策略下发的值的示例（多数策略写在 Policies 下方）
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: 不生效时的排查步骤
    accDescr: 先用 gpresult 的 RSoP 报告确认已应用的 GPO 和被拒绝的 GPO，不够时再用 ActivityID 筛选 GroupPolicy 运行日志，下发的实际值则直接在注册表的 Policies 键中确认
    start["设置不生效"] --> rsop["用 gpresult /h 确认 RSoP"]
    rsop --> found{"能看出应用与拒绝的原因?"}
    found -->|能| fix["重新审视优先顺序和筛选"]
    found -->|不能| oplog["查看 GroupPolicy 运行日志"]
    oplog -.-> aid["用 ActivityID 筛出单次处理"]
    rsop -.-> reg["直接确认 Policies 键中的实际值"]

图14：排查以 gpresult /h 为起点，不够时看 GroupPolicy 运行日志，实际值则直接确认 Policies 键，整个过程机械化地推进。

6. 管理模板（ADMX）与中央存储

ADMX 是设置定义，ADML 是显示字符串

GPMC“管理模板”下排列的项目，其设置定义写在 ADMX 文件中，各语言的显示字符串写在 ADML 文件中。

每台电脑的 C:\Windows\PolicyDefinitions 里有操作系统自带的定义，管理工具读取它们来构建设置界面。⁷

在域环境中引用统一的中央存储

在域环境的运维中，要在 DC 的 SYSVOL 下创建 PolicyDefinitions 文件夹。例如 \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions。

其内容会复制到域内的所有 DC，组策略工具也会默认引用中央存储。这是为了避免各管理终端上模板版本不同、看到的项目对不上的问题。ADML 要放到 ja-JP 等按语言划分的子文件夹中。⁷

flowchart TB
    accTitle: 中央存储的机制
    accDescr: 在域控制器的 SYSVOL 下创建 PolicyDefinitions 文件夹后其内容会复制到所有域控制器，并且组策略工具默认引用中央存储，于是各管理终端之间的定义差异就消失了
    create["在 SYSVOL 下创建"] --> cs["PolicyDefinitions"]
    cs --> repl["复制到所有 DC"]
    cs --> ref["组策略工具默认引用"]
    ref -.-> benefit["各终端之间的定义差异消失"]
    cs -.-> adml["ADML 放到按语言划分的文件夹"]

图15：SYSVOL 中的 PolicyDefinitions 会复制到所有域控制器，组策略工具默认引用它。

更新要先在工作文件夹里准备好再切换

面向新版 Windows 的 ADMX 由 Microsoft 按版本发布。要更新的是中央存储一侧。用下载版替换各台电脑的 C:\Windows\PolicyDefinitions 的做法不受支持。⁷

更新已有的存储时，不要直接覆盖生产文件夹，而要按以下顺序进行。

1. 准备一个带版本名的工作文件夹，例如 PolicyDefinitions-24H2。
2. 把操作系统部分，以及 Office、Edge 等应用部分的 ADMX 全套凑齐。
3. 把当前的 PolicyDefinitions 重命名为 PolicyDefinitions-23H2 之类的名字，作为备份保留。
4. 把工作文件夹重命名为 PolicyDefinitions，让它作为生产环境被引用。⁷

被引用的是名为 PolicyDefinitions 的文件夹。只把文件放到带版本名的文件夹里不会生效。把旧文件夹保留下来，出问题时就能回退。⁷

flowchart TB
    accTitle: 中央存储的更新步骤
    accDescr: 更新时先在带版本名的工作文件夹里凑齐操作系统部分和应用部分的全套 ADMX，把当前文件夹重命名备份后再把工作文件夹重命名为生产名 PolicyDefinitions，出问题时回退到备份的旧文件夹
    work["带版本名的工作文件夹"] --> gather["凑齐操作系统和应用部分"]
    gather --> evac["把当前文件夹重命名备份"]
    evac --> rename["把工作文件夹改成生产名"]
    rename --> live["作为生产环境被引用"]
    live -.-> back["出问题时回退到旧文件夹"]

图16：更新时先在工作文件夹里凑齐全套，备份当前文件夹后再用重命名切换到生产。

7. GPO vs Intune（MDM/CSP） vs 手动与脚本——判断表

现在 Windows 终端的配置管理选项已经不只有 GPO。以 Intune 为代表的 MDM，通过 CSP（配置服务提供程序）这套机制来配置操作系统设置。下面是选择以哪一种为主的判断表。

判断依据是终端的基础设施与所在位置

基本依据是终端以 AD 还是 Microsoft Entra 为基础，以及在哪里使用。对加入本地 AD 域、固定放在公司内的电脑，GPO 最可靠；而对 Entra 加入的移动电脑，域 GPO 送不到。

关键是不要把常驻公司的终端和外带终端当成相同的送达条件。

混合环境下，按设置确定管理主体

即使在中小企业，把加域和 Intune 注册结合起来的混合运维也很常见。这里要避免的是同一设置在 GPO 和 MDM 两边都做配置。

Policy CSP 中有在冲突时让 MDM 优先的 MDMWinsOverGP。但它的作用范围仅限 Policy CSP 内已支持的策略。对不在其控制范围内的设置做双重配置，哪一边获胜无从保证。Microsoft 也建议避免双重配置。⁸

原则是按“这个领域用 GPO，那个领域用 Intune”确定管理主体，统一到一边。

flowchart TB
    accTitle: GPO 与 Intune 的分工
    accDescr: 终端的身份基础设施如果是本地 AD 且常驻公司内则适合 GPO，如果是 Entra 加入或在公司外使用则适合 Intune，混合环境要避免同一设置的双重配置并按设置领域把管理主体统一到一边
    q{"终端的基础设施和所在位置是什么?"}
    q -->|加入 AD 且常驻公司内| gpo["GPO 可靠且粒度细"]
    q -->|Entra 加入或在公司外| intune["Intune 在公司外也能送达"]
    q -->|混合| split["按领域统一到一边"]
    split -.-> warn["双重配置的结果无从保证"]
    split -.-> ana["分类用 Group Policy analytics"]

图17：分工按终端的身份基础设施和所在位置决定，混合环境中不要把同一设置同时配置在 GPO 和 MDM 上。

Group Policy analytics 用于迁移前的分类

评估迁移的入口是 Intune 的 Group Policy analytics。把从 GPMC 导出为 XML 的 GPO 导入进去，就能按设置分析出 MDM 已支持、已弃用、无法支持这三类。已支持的设置可以迁移到 Intune 的设置目录策略。⁹

它不是“把全部搬过去的工具”，而是用来区分能搬、不能搬和该丢弃的东西的工具。

Windows Update 的管理主体也正在同样的背景下重新调整。请一并参考“WSUS 弃用后的 Windows Update 管理”。

flowchart TB
    accTitle: 用 Group Policy analytics 做分类
    accDescr: 把从 GPMC 导出为 XML 格式的 GPO 导入 Group Policy analytics 后就能按设置区分出 MDM 是否支持以及是否属于已弃用或无法支持，已支持的设置可以迁移到设置目录策略
    exp["从 GPMC 导出为 XML"] --> imp["导入 analytics"]
    imp --> ana["按设置分析支持情况"]
    ana --> ok["MDM 已支持"]
    ana --> dep["已弃用、无法支持"]
    ok --> mig["迁移到设置目录策略"]

图18：Group Policy analytics 导入导出的 GPO，区分出能迁移到 MDM 和不能迁移的设置。

8. 开发者视角的陷阱——客户方 GPO 会改变应用的行为

最后是站在受托开发立场上需要掌握的内容。客户方的 GPO 会悄悄改写你的应用的前提条件。在“开发机上能跑、客户那边跑不起来”的原因里，GPO 和防火墙、杀毒软件一样是常客。下面按实例来列举。

PowerShell 的执行策略

执行策略可以通过 GPO 集中配置，来自 GPO 的 MachinePolicy／UserPolicy 作用域始终优先于在本地或进程中设置的值。¹⁰ 如果安装程序或运维脚本是按“加上 -ExecutionPolicy Bypass 就应该能跑”的前提写的，在 GPO 管理之下连启动都做不到。详细内容请参考“PowerShell 的执行策略与脚本签名”。

禁用防火墙的本地规则合并

在用 GPO 或 Intune 集中管理防火墙的环境中，可以按配置文件禁用“本地规则合并”（AllowLocalPolicyMerge）。在禁用的环境里，安装程序在本地注册的入站规则即使存在也不会被应用。¹¹ 这是部署服务器型应用之前必须确认的要点，在“Windows 防火墙与业务应用”中有详细讨论。

驱动器映射、代理等环境配置

网络驱动器的映射和打印机等，通常是用组策略首选项（Preferences）下发的。¹⁶ “应该有 Z 盘”“代理应该是直连”这类环境假设，会因登录的用户和电脑所属的 OU 而不成立。通过用户配置下发的设置当然不会应用到服务或任务的执行账户上，这一点在常驻型应用中也容易被忽略。

设置本身就“改不回来”

来自管理模板的设置，通常用户无法从界面上修改（选项会变灰）。“请客户那边把设置改一下就好了”这种说法行不通，这一点会直接影响处理方针的设计。

flowchart TB
    accTitle: 客户方 GPO 改变的应用前提
    accDescr: 客户方的 GPO 会以强制执行策略、禁用防火墙本地规则合并、下发驱动器和代理配置以及让用户无法改回设置这几种形式改变应用的前提条件，成为只在客户环境跑不起来的原因之一
    gpo["客户方的 GPO"] --> ep["强制执行策略"]
    gpo --> fw["禁用本地规则合并"]
    gpo --> env["下发驱动器与代理"]
    gpo --> lock["设置改不回来"]
    ep --> sym["成为只在客户环境跑不起来的原因之一"]
    fw --> sym
    env --> sym
    lock --> sym

图19：客户方的 GPO 会悄悄改写执行策略、防火墙、环境配置等应用的前提条件。

开发方要事先定好部署前和故障时的确认项

要做的准备有以下 3 项。

权限的划分在“Windows 什么时候需要管理员权限”中讨论。GPO 不是敌人，而是环境的规格。 把它当作规格来对待，把要和管理员一起确认的项目统一起来，排查就能机械化地推进。

flowchart TB
    accTitle: 开发方的三项准备
    accDescr: 开发方的准备有三项，一是把应用依赖的环境前提写成部署要求文档并请客户方信息系统部门在部署前确认，二是出问题时查看 gpresult 的报告和 Policies 键中的实际值，三是在设计阶段就把需要管理员权限的处理分离出来
    dev["开发方的准备"] --> doc["1. 把环境前提文档化"]
    dev --> chk["2. 用 gpresult 和实际值确认"]
    dev --> priv["3. 在设计上分离权限需求"]
    doc -.-> ask["部署前请客户方信息系统部门确认"]

图20：开发方的三项准备是把环境前提文档化、用 gpresult 和实际值确认、在设计上分离是否需要管理员权限。

9. 总结

• 组策略是把 GPO 为单位的设置按本地→站点→域→OU（LSDOU）的顺序处理的机制，冲突时后处理者胜出。离目标最近的 OU 的 GPO 最强，本地 GPO 是最弱的一层。
• 可以用阻止继承、强制（Enforced）和安全筛选来控制默认流程。强制连阻止继承都能压过，所以不可滥用。
• 应用分两条路径：启动时和登录时的前台处理，以及默认约 90 分钟加随机偏移的后台刷新。gpupdate /force 只是重新应用全部设置，对只在登录或重启时才处理的设置无效。
• 不生效时，按 gpresult /h → GroupPolicy 运行日志 → 注册表的 Policies 键的顺序机械化地排查。被拒绝的 GPO 会显示原因。
• 管理模板的定义是 ADMX/ADML，在域环境的运维中集中到 SYSVOL 的中央存储。更新时要替换的是中央存储一侧，而不是本地的 PolicyDefinitions。
• 用 GPO 还是 Intune，取决于终端的身份基础设施和所在位置；混合环境要避免同一设置的双重配置，把管理主体统一到一边。迁移时的分类可以使用 Group Policy analytics。
• 对开发者来说，客户方的 GPO 是环境规格的一部分。把执行策略、防火墙、驱动器与代理配置等前提写成文档，并建立起能用 gpresult 确认的机制，“只在客户环境跑不起来”的问题大多就不可怕了。

相关文章

• Windows 防火墙与业务应用——入站规则要通过安装程序注册
• WSUS 弃用后的 Windows Update 管理——WUfB、Autopatch 与 Intune 怎么选
• PowerShell 的执行策略与脚本签名——从“用 Bypass 蒙混过关”的做法毕业的实务指南
• 用 winget + PowerShell 自动化 PC 装机——让操作手册可执行
• 摆脱 IE 模式依赖系统的实践指引
• Windows 什么时候需要管理员权限 - UAC、保护区域与设计上的辨别方式

相关咨询领域

小村软件有限责任公司承接以下工作：GPO 管理之下的客户环境中业务应用无法运行时的原因调查、部署要求（执行策略、防火墙、网络前提）的梳理，以及面向接手 AD 环境的信息系统负责人的策略盘点和 Intune 并用方针的技术咨询。即使只是“希望有人陪我一起读 gpresult 的报告”这种阶段也没有关系。

• 技术咨询与设计评审
• 缺陷调查与原因分析
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

执行了 gpupdate /force，设置却没有生效，为什么？

首先要确认该设置是不是属于“后台刷新无法应用”的类型。面向用户的软件安装和文件夹重定向只在登录时处理，面向计算机的软件安装只在启动时处理，因此 gpupdate 执行完成后还需要注销（/logoff）或重启（/boot）。其次，用 gpresult /h 输出 RSoP 报告，确认该 GPO 是否出现在“已应用的 GPO”中，或者是否带着原因出现在“被拒绝的 GPO”中。如果已经应用却看不到行为变化，就要怀疑是不是有优先级更高的另一个 GPO 覆盖了同一设置（后处理者胜出）。报告中会显示每个设置的“优先 GPO”，因此可以定位到究竟是哪个 GPO 获胜了。

gpresult 中显示“因筛选而被拒绝”是什么意思？

意思是该 GPO 从链接位置来看确实属于应用对象，但被筛选处理排除在了应用范围之外。最常见的原因是安全筛选：要应用一个 GPO，用户或计算机必须对该 GPO 同时拥有“读取”和“应用组策略”两项访问权限。默认情况下 Authenticated Users 同时拥有这两项权限，但如果运维中收窄到特定的组，就可能因为漏加入组或漏加计算机账户而被拒绝。此外，对于面向用户的 GPO，仅给目标用户授予这两项权限还不够。自 MS16-072 以后，用户策略是在计算机的安全上下文中获取的，因此必须给 Authenticated Users 或 Domain Computers 保留“读取”权限（不需要“应用”）。除此之外，还有 WMI 筛选器条件不匹配，或者 GPO 一侧已禁用用户或计算机侧设置的情况。拒绝原因会同时记录在 gpresult 的报告和 GroupPolicy 运行日志中。

应该用 GPO 还是 Intune 来管理？

基本原则是配合终端的身份基础设施。如果以加入本地 AD 域、始终连着公司内网的终端为主，GPO 是最可靠、粒度也最细的选择。如果 Microsoft Entra 加入的终端，或者不连接域控制器的居家办公终端在增多，那么在公司外也能把配置送达的 Intune（MDM/CSP）更合适。在两者混用的混合环境中，同一设置如果在 GPO 和 MDM 两边都做配置就会冲突，结果无从保证，因此原则是按设置领域确定由哪一边管理并统一到一边。在评估迁移的阶段，可以用 Intune 的 Group Policy analytics 导入现有 GPO，把 MDM 已支持的设置和不支持、已弃用的设置区分开。

在本地组策略（gpedit.msc）里设置的内容会被域的设置覆盖，这是规格吗？

是规格。组策略按本地→站点→域→OU 的顺序处理（LSDOU），后处理的设置在冲突时获胜，因此本地 GPO 是最弱的一层。只要域 GPO 配置了同一设置，本地的修改总会被覆盖。反过来，如果域一侧把该设置留在“未配置”状态，本地 GPO 的值就会原样生效。即使出于验证等原因无论如何都想让本地设置优先，在加域电脑上也没有办法颠覆这个优先顺序，现实的做法是新建一个验证用的 OU 并调整域侧的 GPO，或者使用未加域的验证机。

开发的业务应用只在客户环境里跑不起来，有办法确认是不是 GPO 造成的吗？

第一步是请客户方的管理员在出问题的电脑上以管理员权限打开命令提示符，执行 gpresult /h report.html，然后查看 RSoP 报告。要看的是执行策略导致脚本被拦下、防火墙的本地规则合并被禁用、代理或驱动器映射的配置等会改变应用行为的设置是否已被应用。同时确认注册表 HKLM\Software\Policies 和 HKCU\Software\Policies 下是否写入了相关产品的策略值，这样就能机械化地把来自管理模板的强制设置全部找出来。开发一方能做的准备是，把应用所依赖的前提（执行策略、监听端口、写入目标文件夹等）写进部署手册，并请客户方信息系统部门在部署前确认。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。