小村软件有限公司
联系我们
菜单

组策略(GPO)实务入门 ── 原理、生效确认与和 Intune 的分工

· · Windows, 组策略, Active Directory, Intune, PC 管理, PowerShell, 信息系统

「这个设置是用 GPO 配发的」「客户那边的电脑被组策略锁得死死的」── 只要接触过 Windows 业务系统，「GPO」这个词就会日常性地出现在对话里。然而，一旦轮到自己接手 AD 环境的信息系统工作，或是要在客户的加域电脑上部署应用，能够准确说明组策略在何时、从哪里、按怎样的优先顺序生效的人却出乎意料地少。

「改了设置却没生效」「被要求执行 gpupdate，但不知道到底发生了什么」「在开发机上能跑的应用只在客户那边跑不了，一查才发现是 GPO」── 本文面向遇到这类场景的业务应用开发者，以及接手 AD 环境的中小企业信息系统负责人，基于截至 2026 年 8 月的一手信息，整理组策略的原理(LSDOU 应用顺序)、生效时机、用 gpresult 和事件日志进行排查、ADMX 与中央存储，以及与 Intune(MDM)的分工。

1. 先说结论

  • 组策略是「后处理者胜出」。 按本地→站点→域→OU(LSDOU)的顺序处理，后处理的 GPO 在冲突时优先。本地 GPO(gpedit.msc)是最弱的一层。1
  • 生效时机是「前台+后台」。 计算机的配置在启动时必定应用，用户的配置在登录时必定应用，此外默认还会以约 90 分钟+0～30 分钟的随机偏移进行后台更新(域控制器为 5 分钟)。2
  • gpupdate /force 是「重新应用全部设置」，但并非万能。 软件安装、文件夹重定向这类设置只在登录或重启时才会处理(这正是 /logoff、/boot 选项存在的原因)。3
  • 排查的起点是 gpresult /h 的 RSoP 报告。 可以看到已应用的 GPO 和被拒绝的 GPO(附带原因)。深入排查要用 GroupPolicy 运维日志(Microsoft-Windows-GroupPolicy/Operational)。45
  • 管理模板的策略原则上写入注册表的策略专用键(Software\Policies 等)。 策略值优先于应用自身的设置，「未配置」不会写入任何内容。不过也有少数策略会写到专用键之外(第 5 章)。6
  • ADMX 的中央存储就是 SYSVOL 下的 PolicyDefinitions 文件夹。 创建之后，GPMC 就会引用域内统一的模板定义。7
  • 是用 GPO 还是 Intune，取决于终端的身份基础设施。 如果对同一设置两边都配置，结果无法保证。迁移评估可以用 Group Policy analytics。89
  • 对开发者来说，GPO 是「只在客户那边跑不了」的常见原因之一。 执行策略、防火墙本地规则合并禁用、代理与驱动器配置等改变应用前提的设置，正在通过集中管理方式被配发。1011

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

组策略是一种由管理员集中定义 Windows 设置，并强制应用到目标计算机与用户的机制。这一堆设置被称为 GPO(组策略对象)。GPO 有两个存放位置。

  本地 GPO 域 GPO
编辑工具 gpedit.msc(本地组策略编辑器) GPMC(组策略管理控制台)+组策略管理编辑器
保存位置 该电脑本身。面向计算机的只有一个，但面向用户的可以创建「管理员/非管理员/特定用户」等多个本地 GPO(MLGPO)12 Active Directory(链接到站点、域、OU 后配发)
应用范围 仅该电脑 链接目标下辖的全部计算机/用户
优先级 最弱(会被域 GPO 覆盖)1 强于本地。域 GPO 之间由链接目标和链接顺序决定
典型用途 工作组电脑、验证机的单机设置 组织标准设置的配发与强制

工作组(未加入域)的电脑只会处理本地 GPO。1 也就是说，说「由 GPO 管理」时，实务上几乎都是指域 GPO。

无论哪个 GPO，内容大体分为两大系统。

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

「是绑定在电脑上的设置，还是绑定在人身上的设置」这一分类轴，在后面的应用顺序和生效确认中会一以贯之地出现。也有一些设置项在两个系统中都存在，因此在查找设置时务必养成两个系统都看一遍的习惯。

3. 应用机制 ── LSDOU 的「后处理者胜出」与继承控制

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

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

  1. 本地 GPO
  2. 链接到站点的 GPO
  3. 链接到域的 GPO
  4. 链接到OU(组织单位)的 GPO ── 从上层 OU 依次处理，最后处理目标计算机/用户直接所属 OU 的 GPO

取首字母合称为 LSDOU 的顺序。重点在于，这并非「优先级从高到低的顺序」，而是处理的顺序。当多个 GPO 配置了同一设置时，后处理的 GPO 胜出(不冲突的设置则单纯相加)。1 也就是说，离目标最近的 OU 的 GPO 最强，本地 GPO 最弱。「明明在 gpedit.msc 里改过了却又变回去了」并非故障，而是按这一规格正常运作的结果。

如果同一站点、域、OU 上链接了多个 GPO，则由 GPMC 的「已链接的组策略对象」选项卡中的链接顺序决定。链接顺序编号最小的 GPO 最后处理，因此优先级最高。1

3.2. 继承的阻止与强制(Enforced)

默认顺序可以设置例外。1

  • 阻止继承: 在域或 OU 上设置后，可以停止接受来自上层的 GPO 继承。用于「只有这个 OU 不想接受全公司标准」的场景。
  • 强制(Enforced，旧称「不替代」): 在 GPO 链接上设置后，即使下层阻止了继承，该 GPO 也会必定被应用，且不会被下层 GPO 覆盖。当阻止继承与强制发生冲突时，强制胜出。1

强制是破坏「后处理者胜出」原则的机制，用得过多，读 RSoP 时就会越来越多地出现违反直觉的结果。惯例是只把它用在全公司必须遵守的安全设置上。

3.3. 安全筛选处理

不仅是链接位置，应用给谁也可以按 GPO 单位来限定。要应用某个 GPO，目标用户或计算机必须对该 GPO 同时拥有「读取」和「应用组策略」这两项访问权限。默认情况下 Authenticated Users(同时包含用户和计算机)拥有这两项权限，因此会应用给链接目标下辖的所有对象。把范围限定到特定安全组，就是安全筛选处理。筛选作用于整个 GPO，无法针对 GPO 内的单个设置分别调整。13

有一点需要特别注意：在限定应用对象时，不能把默认的 Authenticated Users 连「读取」权限一起去掉。自安全更新程序 MS16-072(2016 年)以后，面向用户的策略是在计算机的安全上下文中获取的，因此如果计算机账户无法读取该 GPO，即使已经给目标用户授予了两项权限，面向用户的 GPO 也不会生效。14 在缩小范围时，正确的做法是给目标组授予「读取+应用组策略」，同时给 Authenticated Users(或 Domain Computers)只保留「读取」。14

实务中常见的坑是「明明加入了组却没生效(面向计算机的设置却只把用户加入了组)」「明明已经移出了组却仍在生效」。后者即使等待后台更新也不会解决。组成员身份是根据登录时生成的安全令牌来评估的，因此用户的组变更要等注销后重新登录、计算机的组变更要等重启，才能拿到新令牌并反映到筛选结果中。

此外，为了应对共享电脑、远程桌面服务器这类「想把登录到该电脑的所有人都替换为同一套用户配置」的场景，还有一种特殊模式叫环回处理(根据计算机所在位置来应用用户设置的机制，有替换和合并两种模式)。15 这是用于自助终端、教室电脑等场景的进阶功能，本文仅作存在性介绍。

4. 何时生效 ── 前台处理与后台更新

「设置了却没生效」，一半原因只是应用的时机还没到而已。应用分为两种。2

类型 时机 对象
前台处理 计算机配置: 启动时/用户配置: 登录时 全部设置
后台更新 默认约每 90 分钟+0～30 分钟随机偏移(为避免所有终端同时来取而错开) 仅支持后台处理的设置
后台更新(域控制器) 默认每 5 分钟 同上

也就是说，只要是能够连接到域控制器的在线终端，即使在修改 GPO 后什么都不做，支持后台更新的设置也会在大约两小时内送达。离线终端或未连接 VPN 的外带电脑，要等到下次连接 DC 才能收到。只能通过前台处理生效的设置，还要再等待启动或登录。如果想加快速度，可以在目标电脑上执行 gpupdate。默认情况下只应用有变更的设置，加上 /force 则无论是否有变更都重新应用全部设置。3

rem 仅更新有变更的部分(通常这样就够了)
gpupdate

rem 重新应用全部设置(怀疑存在缓存状态时使用)
gpupdate /force

需要注意的是，存在 gpupdate 无法使其生效的设置。面向用户的软件安装和文件夹重定向只在登录时处理，面向计算机的软件安装只在启动时处理。为此 gpupdate 提供了 /logoff(更新后注销)和 /boot(更新后重启)选项。3 在「执行了 gpupdate /force 却还是没进去」之前，先确认一下该设置是不是需要重启或登录才能处理的类型。

5. 未生效时的排查 ── gpresult、事件日志、注册表

5.1. 用 gpresult /h 确认 RSoP

用来确认多个 GPO 叠加之后最终结果(RSoP: 策略结果集)的标准工具是 gpresult。从管理员权限的命令提示符中输出 HTML 报告是最容易阅读的方式。45

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

rem 只在控制台确认概要
gpresult /r
gpresult /scope computer /r

报告中最先应该看的是以下三点。

  1. 已应用的 GPO 列表 ── 目标 GPO 是否在其中
  2. 被拒绝的 GPO 列表及原因 ── 会显示因安全筛选器、WMI 筛选器、空 GPO 等原因未被应用的情况5
  3. 各设置的「优先 GPO」 ── 目标设置由哪个 GPO 的值决定。如果是别的 GPO 胜出，就要回到第 3 章重新审视优先顺序

5.2. GroupPolicy 运维日志

当 gpresult 不够用时(例如处理本身失败、耗时过长等)，要查看事件查看器中的 GroupPolicy 运维日志。位置是「应用程序和服务日志 > Microsoft > Windows > GroupPolicy > Operational」(日志名 Microsoft-Windows-GroupPolicy/Operational)。这里会记录从策略处理开始到结束的整个过程，包括已应用的 GPO 列表和被拒绝的 GPO 列表(附带原因)。每一次策略处理都会分配一个唯一的 ActivityID，Microsoft 推荐的做法是从系统日志的警告/错误事件中获取 ActivityID，然后用自定义视图只筛选出这一次处理的相关事件。5

5.3. 与注册表 Policies 键的关系

管理模板(下一章)的策略，最终会以注册表值的形式写入。写入位置原则上是以下策略专用键。6

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

这里有一个重要的设计思路。支持策略的应用会先读取 Policies 键，如果有值就优先使用该值，没有的话才使用自身设置(首选项)或默认值。「未配置」的策略不会向注册表写入任何内容。6 也就是说，管理模板的策略并不是通过改写应用自身的设置来留下「纹身(tattooing)」，而是一种放在别处的强制值被优先引用的机制。停止配置该策略后，应用就能恢复到遵循自身设置值的状态。

不过，并非所有策略都写入专用键。操作系统内置设置中的一部分(例如「启用 Win32 长路径」会写入 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 下的 LongPathsEnabled)，以及一些较老版本或第三方模板，会写入专用键之外的任意路径。这类设置即使停止配置策略，值也会原样保留。目标设置到底写入哪个键，请通过 ADMX 定义、设置说明文字，或 gpresult 报告来确认。

反过来说，前面提到的「行为规范」只在管理模板(策略专用键)的范畴内成立。脚本或组策略首选项(Preferences)写入 Policies 键之外的值，与普通的注册表值没有区别，停止配发也不会自动恢复原状，这个框架并不适用于它们。在排查实务中，直接查看「目标设置是否写入了 Policies 键」是最快也最可靠的方法。

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

6. 管理模板(ADMX)与中央存储

GPMC「管理模板」中列出的设置项的定义，由 ADMX 文件(设置的定义主体)和 ADML 文件(各语言的显示字符串)描述。每台电脑的 C:\Windows\PolicyDefinitions 中都保存着操作系统自带的定义，管理工具会读取它来构建设置界面。7

如果以域为单位运营，基本做法是创建中央存储。在域控制器 SYSVOL 下创建 PolicyDefinitions 文件夹(例如 \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)后，其内容会复制到域内所有域控制器，组策略工具默认就会引用中央存储。7 这样就消除了「不同管理终端上模板版本不一致、看到的设置项也对不上」的问题。ADML 要放在按语言划分的子文件夹中(简体中文为 zh-CN)。7

运维上有两点需要注意。第一，面向新 Windows 版本的 ADMX 由 Microsoft 按版本分发，更新时应替换中央存储一侧。用下载版替换每台电脑本地的 C:\Windows\PolicyDefinitions 是不受支持的做法。7 第二，更新已有的中央存储时，不应直接覆盖正式使用中的 PolicyDefinitions，而是先在 PolicyDefinitions-24H2 这类带版本号的工作文件夹中备齐操作系统和应用(Office、Edge 等)的整套 ADMX，再把当前文件夹重命名为 PolicyDefinitions-23H2 等名称加以保留备份，然后把工作文件夹重命名为 PolicyDefinitions 正式启用，这样的流程是官方指导的做法。7 组策略工具只会引用名为 PolicyDefinitions 的文件夹，因此仅仅放在带版本号的文件夹里并不会生效。这种方式的优点是，一旦出问题可以恢复到之前备份的旧文件夹。7

7. GPO vs Intune(MDM/CSP) vs 手动/脚本配发 ── 判断表

Windows 终端的配置管理选项，如今已不止 GPO 一种。以 Intune 为代表的 MDM，通过 CSP(配置服务提供程序)机制来配置操作系统设置。下面是以哪个为主轴的判断表。

视角 域 GPO Intune(MDM/CSP) 手动/脚本配发
前提 加入 AD 域+能连接域控制器 Intune 许可证+终端已注册 Intune(除 Entra 加入/混合加入外，BYOD 等 Entra 注册设备也可能纳入，取决于注册方式) 无(所以也没有统一管控)
对社外/居家终端的送达能力 若无法通过 VPN 等连到 DC 则无法更新 可经由互联网送达 取决于人工操作
设置的粒度与覆盖面 最广(管理模板+安全设置+脚本等) 正在扩大，但尚未与 GPO 全部设置等同9 只有写了的部分
强制力 作为策略强制(Policies 键优先)6 作为策略强制(CSP) 用户改动后不会自动恢复
应用状态的确认手段 gpresult / GroupPolicy 运维日志45 Intune 管理中心的报告 需自行搭建机制
适合的环境 以本地 AD 为中心、常驻社内局域网的终端 以云端为中心的外带终端、分散据点 数台规模，或作为其他手段的补充

判断的主轴很简单：终端的身份基础设施(是 AD 还是 Microsoft Entra)，以及终端身处何处。对于完全加入本地 AD 的社内固定电脑群体，GPO 最为可靠；而对于加入 Entra 的移动电脑，GPO 根本无法送达。

现实中的中小企业大多处于两者之间，也就是混合环境(加入域+注册 Intune)，这里最糟糕的情况就是「对同一设置同时用 GPO 和 MDM 配置」。Policy CSP 中有一项叫 MDMWinsOverGP 的策略，可以让 MDM 在与 GPO 冲突时胜出，但其适用范围仅限于 Policy CSP 内已支持的策略。Microsoft 官方也明确指出，对不受此控制的设置同时用 GPO 和 MDM 配置，会产生冲突且无法保证哪一方胜出，应避免双重配置。8 按设置领域分别决定「这个用 GPO、这个用 Intune」并统一到一边管理，是混合运维的第一原则。

考虑从 GPO 迁移到 Intune 的阶段，Intune 的 Group Policy analytics 是一个入口。导入从 GPMC 导出的 GPO(XML)后，可以分析各设置是否受 MDM 支持，还是不建议使用或不支持，已支持的设置可以迁移到 Intune 的设置目录策略中。9 与其说是「全部迁移」，不如把它理解为「区分可迁移、不可迁移、可舍弃」的工具，这样更符合实际情况。此外，Windows Update 的管理主体也在同一背景下进行重组，另请参阅《WSUS 弃用后的 Windows 更新管理》。

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

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

  • PowerShell 的执行策略: 执行策略可以通过 GPO 集中配置，源自 GPO 的 MachinePolicy/UserPolicy 作用域，总是优先于本地或进程级别设置的值。10 如果安装程序或运维脚本是基于「加上 -ExecutionPolicy Bypass 应该就能跑」这一前提写的，在 GPO 管控下甚至连启动都做不到。详见《PowerShell 的执行策略与脚本签名》。
  • 防火墙本地规则合并禁用: 在用 GPO/Intune 集中管理防火墙的环境中，可以按配置文件禁用「本地规则合并」(AllowLocalPolicyMerge)。在禁用的环境中，安装程序在本地注册的入站规则即使存在也不会被应用。11 这是部署服务器型应用之前必须确认的要点，《Windows 防火墙与业务应用》中有详细说明。
  • 驱动器映射、代理等环境配置: 网络驱动器映射、打印机等常见做法是通过组策略首选项(Preferences)来配发。16 「应该有 Z 盘」「代理应该是直连」这类环境假设，会因为登录用户或电脑所属 OU 的不同而落空。用户配置中配发的设置理所当然不会应用到服务或任务的执行账户，这一点在常驻型应用中也很容易被忽略。
  • 设置本身「改不回去」: 源自管理模板的设置，通常用户无法从界面上修改(项目会显示为灰色不可用)。「请客户那边改一下设置就好了」这种说法行不通，这一点会影响应对方案的设计。

开发一方现实可行的准备有三点。第一，把应用依赖的环境前提(执行策略、监听端口、写入目标、代理路径等)作为部署要求写入文档，并请客户方信息系统部门在部署前确认。第二，出问题时不要凭猜测，而要查看 gpresult /h 的报告和 HKLM\Software\Policies 下的实际值(第 5 章)。第三，在设计阶段就把需要管理员权限的处理和不需要的处理区分开(这条界线在《Windows 什么时候需要管理员权限》中有说明)。GPO 不是敌人，而是环境的规格。把它当作规格来对待，排查就能机械化地完成。

9. 总结

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

相关文章

相关咨询领域

合同会社小村软件承接 GPO 管控下客户环境中业务应用无法运行的原因调查、部署要求(执行策略、防火墙、网络前提)的梳理，以及面向接手 AD 环境的信息系统负责人的策略盘点与 Intune 并用方针的技术咨询。哪怕只是「想请你一起读一下 gpresult 的报告」这种阶段也没关系。

参考链接

  1. Microsoft Learn, Group Policy processing and precedence。关于组策略按本地 GPO→站点→域→OU 的顺序处理，后处理的 GPO 在冲突时覆盖(不冲突的设置则汇总)，同一容器内的多个 GPO 按链接顺序处理、链接顺序最小的 GPO 最后处理因而优先级最高，强制(Enforced)・链接禁用・用户/计算机设置禁用・阻止继承这些例外，被强制的 GPO 即使下层存在阻止继承也会持续生效，工作组计算机只处理本地 GPO，启动时应用计算机策略・登录时应用用户策略的流程。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, ADMX_GroupPolicy Policy CSP。关于计算机的组策略在系统启动时必定应用，默认每 90 分钟+0～30 分钟随机偏移进行后台更新，用户的组策略在登录时必定应用同样以默认 90 分钟+0～30 分钟偏移更新，域控制器的默认更新间隔为 5 分钟，更新间隔可在 0～64,800 分钟范围内配置。 ↩ ↩2

  3. Microsoft Learn, gpupdate。关于 gpupdate 默认只应用有变更的策略设置、加 /force 则重新应用全部设置，用于处理面向用户的软件安装或文件夹重定向等无法通过后台更新处理、只能在登录时处理的扩展的 /logoff，用于处理面向计算机的软件安装等只能在启动时处理的扩展的 /boot，以及 /target:{computer user} 和 /wait 等选项。

    ↩ ↩2 ↩3

  4. Microsoft Learn, gpresult。关于 gpresult 是显示策略结果集(RSoP)的命令，/h 输出 HTML、/x 输出 XML 报告并可用 /f 覆盖，/r 显示概要、/v 和 /z 显示详情，/scope {user computer} 可以限定对象，基于站点、域、OU 成员身份生成叠加后的策略结果集。

    ↩ ↩2 ↩3

  5. Microsoft Learn, Applying Group Policy troubleshooting guidance。关于在排查组策略问题时从管理员权限命令提示符执行 gpresult /h 来确认 GPO 未生效原因的步骤，GroupPolicy 运维日志(Microsoft-Windows-GroupPolicy/Operational)中会记录已应用的 GPO 列表和被拒绝的 GPO 列表及拒绝原因，每次策略处理实例都会分配唯一 ActivityID、用自定义视图筛选出该实例相关事件的步骤，以及启用 GPSvc 调试日志的方法。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Implementing Registry-based Policy。关于基于注册表的策略的存放位置仅限于 HKCU\Software\Policies 和 HKLM\Software\Policies(推荐位置)以及 HKCU/HKLM 的 Software\Microsoft\Windows\CurrentVersion\Policies，「未配置」状态下不会向注册表写入值，应用应先读取策略键、没有时再读取首选项值，策略键始终优先于首选项键，可存储的数据类型为 REG_DWORD、REG_SZ、REG_EXPAND_SZ，以及应用应在策略更新时重新检查策略键。 ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, How to create and manage the Central Store for Group Policy Administrative Templates in Windows。关于管理模板分为定义主体的 ADMX 和各语言显示字符串的 ADML，中央存储要在域控制器 SYSVOL 下的 PolicyDefinitions 文件夹(例如 \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)创建，内容会复制到域内所有域控制器且组策略工具默认引用中央存储，ADML 放在按语言划分的子文件夹(如 en-US、ko-KR)中，用下载版 ADMX 替换 C:\Windows\PolicyDefinitions 不受支持，更新时应在 PolicyDefinitions-24H2 这类版本名的新文件夹中备齐操作系统和应用扩展部分的 ADMX/ADML，把当前文件夹重命名为 PolicyDefinitions-23H2 等加以保留，再把新文件夹重命名为正式名称 PolicyDefinitions 的步骤，以及出现重大问题时可恢复到旧文件夹是该方式的优点。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Microsoft Learn, ControlPolicyConflict Policy CSP。关于把 MDMWinsOverGP 策略(默认值 0)设为 1 后，对 Policy CSP 内已支持的策略而言 MDM 设置会优先于组策略，适用对象仅限于 Policy CSP 内的策略、不适用于 Defender CSP 等其他 CSP，对不受此控制的设置同时用 GPO 和 MDM 配置会产生冲突且无法保证哪一方胜出因此应避免双重配置。 ↩ ↩2

  9. Microsoft Learn, Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune。关于 Group Policy analytics 会导入并分析本地 GPO，显示包括 Intune 在内的 MDM 提供程序所支持的设置以及不推荐使用/不可用的设置，导入从 GPMC 以 XML 格式导出的 GPO，可将导入的 GPO 迁移到设置目录策略并部署到设备。 ↩ ↩2 ↩3

  10. Microsoft Learn, about_Execution_Policies。关于执行策略的作用域按 MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine 的优先顺序评估，MachinePolicy 和 UserPolicy 是由组策略设置的作用域，即使在下层作用域设置了更宽松(或更严格)的策略，优先级更高的策略仍然生效，可用 Get-ExecutionPolicy -List 确认全部作用域的设置。 ↩ ↩2

  11. Microsoft Learn, Windows Firewall rules。关于在通过 GPO 或 CSP 集中管理防火墙的环境中可以按配置文件禁用「本地规则合并」(AllowLocalPolicyMerge)，禁用时本地创建的规则不会被应用，需要入站连接的应用的规则必须通过集中配发才能生效。 ↩ ↩2

  12. Microsoft Learn, Step-by-Step Guide to Managing Multiple Local Group Policy Objects。关于 Windows Vista 以后的本地 GPO 拥有「本地计算机策略」「管理员/非管理员用」「特定用户用」等多层(MLGPO)，按本地计算机→管理员/非管理员→用户别的顺序处理，最后读取的用户别层优先级最高，这是面向未加入域计算机管理的功能。 ↩

  13. Microsoft Learn, Security filtering using GPMC。关于安全筛选处理是用于限定接收 GPO 设置的用户与计算机的机制，应用某 GPO 需要目标用户或计算机同时拥有「读取」和「应用组策略」两项访问权限，默认所有 GPO 都对 Authenticated Users(包含用户和计算机)授予了这两项权限，筛选作用于整个 GPO 而无法针对单个设置使用。 ↩

  14. Microsoft Learn, Deploying Group Policy Security Update MS16-072 (KB3163622)。关于应用 MS16-072 后用户组策略改为在计算机的安全上下文中获取这一设计变更，因此计算机账户需要具备对 GPO 的读取访问权限，在安全筛选处理等场景中移除了 Authenticated Users 权限时需要为 Authenticated Users 或 Domain Computers 追加「读取」(不需要「应用组策略」)。 ↩ ↩2

  15. Microsoft Learn, Loopback processing of Group Policy。关于环回处理是根据计算机对象所在位置应用一组用户设置 GPO 的功能，是面向公共区域、实验室、教室等特殊用途计算机设想的机制，仅在 Active Directory 环境中受支持，有合并与替换两种模式。 ↩

  16. Microsoft Learn, Group Policy Preferences Getting Started Guide。关于组策略首选项(Preferences)是可配置驱动器映射、打印机、计划任务、服务、文件夹选项等的一组 GPMC 扩展，可通过项目级定位进行筛选，能够在不限制用户修改的情况下配发设置，可以选择要强制的设置和不强制的设置(这一点与策略性质不同)。 ↩

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

执行了 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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表