从组策略走向 Intune——中小企业的设备管理迁移指南

“AD 服务器的维护期限到了。是就这样更新换代，把组策略再用五年吗？”“居家办公的 PC 只有连上 VPN 时设置才送得到。”在中小企业，这类咨询正在增多。

本文的主轴，不是要不要重新买一台 AD 服务器，而是未来五年用什么来管理在公司外的 PC。迁移并非“全有或全无”。有一种做法是保留 AD，同时从新 PC 开始切换到 Entra join+Intune。¹

先根据现在想判断的事情，选择从哪里开始读。

本文的前提

读者对象是中小企业的信息系统负责人和经营者。本文基于截至 2026 年 8 月的 Microsoft Learn 等一手资料，梳理 GPO 与 MDM 的差异、所需架构与许可、盘点、分阶段迁移以及容易踩坑的地方。尤其是套餐构成会变动，签约前请用官方信息确认最新内容。

本地的 Active Directory（AD）与组策略（GPO），是以“PC 位于公司局域网、随时能连上域控制器”为前提设计的机制。随着带出公司的 PC 和居家办公成为常态，这个前提已经不成立了。长期作为更新管理标配的 WSUS 也在 2024 年 9 月转为弃用，Microsoft 设备管理的重心正在移向 Entra ID+Intune（MDM）。²

flowchart TB
    accTitle: 前提失效与管理重心的转移
    accDescr: AD 与 GPO 是以 PC 位于公司局域网、随时能连上域控制器为前提的机制，但带出公司的 PC 与居家办公常态化让这个前提失效，加上 WSUS 转为弃用，管理重心移向 Entra ID 与 Intune
    adgpo["本地的 AD 与 GPO"] -.-> premise["前提是随时能连上 DC"]
    work["带出公司的 PC 与居家办公常态化"] --> broken["失效的是前提本身"]
    premise --> broken
    wsus["WSUS 转为弃用"] --> shift["重心移向 Entra ID+Intune"]
    broken --> shift

图1：AD+GPO 所依赖的“PC 位于公司局域网”这一前提随工作方式的变化而失效，管理重心移向了 Entra ID+Intune。

1. 先说结论

迁移方针从以下三点搭建。

1. 改变把管理送达公司外 PC 的方式。GPO 需要能连上域控制器，而 Intune 经互联网同步。不过常态下的同步大约每 8 小时一次，这套机制并不保证即时生效。策略变更时也会有通知触发的同步。³
2. 从新 PC 开始切换，与既有环境共存。新购机和替换机用 Entra join+Intune，既有的加入域机器保持 hybrid join，按替换周期更换，这样更现实。立刻停用 AD 并不是迁移的前提条件。¹
3. 不要整套照搬 GPO，而要逐条设置分类。用 Group Policy analytics 盘点，不需要的设置丢掉，需要的设置迁到 Intune 或设计替代方案。原则是同一项设置不从 GPO 和 MDM 两边下发。⁴⁵

管理模板、更新管理、BitLocker、LAPS、应用下发这些主要工作，在 Intune 侧都有对应功能。另一方面，登录脚本、驱动器映射、打印机下发则是无法原样迁走的典型例子。第 5 至 6 章会梳理它们的去处。

对中小企业来说，包含 Intune Plan 1 与 Entra ID P1 的 Microsoft 365 Business Premium 是现实的起点。不过，并非所有 Intune 功能都包含在内。许可与费用在第 4 章确认。⁶⁷

把问题从“要不要再更新一轮 AD 服务器”换成“未来五年用什么管理在公司外的 PC”，该比较的东西就清楚了。

flowchart LR
    accTitle: 需要判断的问题的置换
    accDescr: 要不要再更新一轮 AD 服务器这个问题，应当置换成未来五年用什么管理在公司外的 PC 来判断
    q1["再更新一轮 AD 服务器?"] -->|置换| q2["未来五年 用什么管理公司外的 PC?"]

图2：服务器更新换代的问题，应置换为“未来五年用什么管理在公司外的 PC”来判断。

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

2. GPO 与 MDM 有什么不同——比较下发机制

不同的不只是设置内容，还有送达方式

先用同一套视角比较 GPO 与 Intune。GPO 的 LSDOU 应用顺序，以及用 gpupdate / gpresult 确认的方法，已在“组策略（GPO）实务入门”中讲过，这里只聚焦对迁移判断有影响的差异。

迁移判断中最重要的是获取来源和送达公司外 PC 的方式。GPO 送不到居家 PC，是因为“PC 位于能连上域控制器的地方”这一设计前提，已经与现在的工作方式不符。

也有一条路是要求全体员工常连 VPN，从而给 GPO 延命。不过，那意味着还要背上 VPN 基础设施这另一套东西的维护。

flowchart TB
    accTitle: 延续 GPO 还是迁移到 MDM
    accDescr: GPO 送不到居家 PC 是因为设计前提与现在的工作方式不符，强制全员常连 VPN 给 GPO 延命，等于背上 VPN 基础设施这另一套东西的维护
    gap["设计前提与工作方式不符"] --> sel{"如何应对?"}
    sel -->|用常连 VPN 延命| vpn["继续使用 GPO"]
    sel -->|迁移到 MDM| mdm["经互联网管理"]
    vpn --> cost["背上另一套基础设施的维护"]

图3：靠常连 VPN 给 GPO 延命这条路，同时也意味着背上 VPN 基础设施这另一套东西的维护。

“送得到公司外”和“马上生效”是两回事

用 Intune，就能把管理送到任何能上网的 PC，不限地点。另一方面，常态下的同步约每 8 小时一次，比 GPO 约 90 分钟的定期刷新要粗。不要带着“下发后马上生效”的感觉去迁移，这一点很重要。

策略分配或变更时会向终端发送通知，同步相对及时。也可以从管理中心或终端手动同步，但对紧急阻断这类要求即时性的管控，必须以同步间隔为前提来设计。³

flowchart TB
    accTitle: GPO 与 MDM 的策略下发路径
    accDescr: GPO 只有在能连上公司内的域控制器时才应用，因此居家 PC 只能依赖 VPN，而 Intune 经互联网约每 8 小时同步一次并在策略变更时通过通知同步，因此不限地点都能送达
    officepc["公司内的 PC"] -->|启动与登录时以及定期刷新| dc["域控制器"]
    homepc["居家的 PC"] --> vpn{"能经 VPN 连上 DC 吗?"}
    vpn -->|能| dc
    vpn -->|不能| miss["收不到最新策略"]
    anypc["任何位置的 PC"] -->|约每 8 小时同步一次| intune["Intune 服务"]
    intune -.-> notify["策略变更时通过通知同步"]

图4：GPO 只在能连上域控制器时才应用，Intune 则经互联网不限地点地同步。

3. 梳理前提——加入域、hybrid join、Entra join 三种形态

PC 的加入形态不同，能用的管理手段也不同

Windows PC“加入公司”的方式有以下三种形态。¹

hybrid join 是把既有的加入域 PC 同时注册到 Entra ID 的形态。可以在沿用既有资产的同时开始使用 Intune 和条件访问。不过 Microsoft 建议不要把 hybrid join 当作最终目标，新购与替换的 PC 应采用 Entra join。¹

既有 PC 需要擦除，所以趁更换时切换

把加入域的 PC（含 hybrid join）转换成 Entra join，并不存在 Microsoft 支持的手段。需要执行 Windows 的重置（擦除）。因此官方建议配合硬件更新或系统重装来改成 Entra join。¹

flowchart TB
    accTitle: 三种加入形态与迁移路径
    accDescr: 仅加入 AD 域的 PC 可以再注册到 Entra ID 变成 hybrid join，但没有直接转换成 Entra join 的手段而需要擦除，因此建议把新购与替换的 PC 做成 Entra join
    adonly["仅加入 AD 域（GPO）"] -->|同时注册到 Entra ID| hybrid["hybrid join（GPO 与 Intune）"]
    hybrid -.->|没有直接转换的手段| wipe["需要擦除（重置）"]
    wipe --> entra["Entra join（Intune）"]
    newpc["新购与替换的 PC"] -->|推荐| entra

图5：把既有的加入域机器转换成 Entra join 没有正式手段，从新购与替换的 PC 开始切换才是常规做法。

中小企业的迁移方针，把 PC 和 AD 分开看会更清楚。

Entra join 的机器与加入域的机器可以在同一个公司内网环境中共存。为了开始新的管理方式，并不需要一次性废弃既有 PC 或 AD。¹

flowchart TB
    accTitle: 分阶段迁移期间的共存架构
    accDescr: Entra join 的机器与加入域的机器可以在同一个公司内网环境中共存，前者用 Intune 管理后者用 GPO 管理，同时为残留职责暂时保留 AD 而只逐步清空 GPO 的内容
    env["同一个公司内网环境"] --> ejoin["Entra join 的机器"]
    env --> djoin["加入域的机器"]
    ejoin --> intune["用 Intune 管理"]
    djoin --> gpo["用 GPO 管理"]
    gpo -.-> shrink["逐步清空其中的内容"]
    env -.-> ad["为残留职责保留 AD"]

图6：Entra join 的机器与加入域的机器可以在同一个公司内网环境中共存，AD 为残留职责暂时保留。

对本地资产的单点登录另有两个前提

从 Entra join 的机器访问本地文件服务器等资源也是可以的。不过，仅凭是 Entra join，还凑不齐对本地资产做单点登录（SSO）的前提。需要确认以下两点。¹⁸

在迁移计划中，要先排查有没有不满足这两点的用户或使用场景。也就是说，要把 Intune 对公司外 PC 的管理，和对公司内资产的连接分开确认。

flowchart TB
    accTitle: Entra join 机器对本地资产做单点登录的前提
    accDescr: 从 Entra join 的机器访问本地文件服务器，需要同时满足是由 Entra Connect 等同步而来的混合标识，以及能连到域控制器这两个前提
    pc["Entra join 的机器"] --> cond1{"是混合标识吗?"}
    cond1 -->|是| cond2{"能连到 DC 吗?"}
    cond1 -->|否| ng1["拿不到 AD 凭据"]
    cond2 -->|是| ok["对文件服务器单点登录"]
    cond2 -->|否| ng2["在公司外需要 VPN 等"]

图7：从 Entra join 的机器对本地资产做单点登录，有混合标识与能连到域控制器这两个前提。

4. 许可与费用——Intune 包含在哪些套餐里（截至 2026 年 8 月）

确认用 Business Premium 能起步到什么程度

基础许可是 Microsoft Intune Plan 1。它既作为单独订阅提供，也随各种 Microsoft 365 套餐一起提供。⁶

对中小企业来说，重要的一点是 最多 300 个用户的 Microsoft 365 Business Premium 中包含 Intune Plan 1。Business Premium 还包含 Microsoft Entra ID P1 与 Microsoft Defender for Business，因此可以一直配置到合规性策略＋条件访问。⁷

Business Standard / Basic 不包含 Intune。如果是从只有邮件和 Office 的合约走向设备管理，那么升级到 Business Premium 的差价，实际上就是引入 Intune 的费用。

flowchart TB
    accTitle: 面向中小企业的套餐与 Intune 的关系
    accDescr: 最多 300 个用户的 Business Premium 包含 Intune Plan 1 与 Entra ID P1 与 Defender for Business 并可一直配置到条件访问，而 Business Standard 与 Basic 不包含 Intune
    bp["Business Premium"] -.-> cap["最多 300 个用户"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["可一直配置到条件访问"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["不包含 Intune"]

图8：Business Premium 包含 Intune Plan 1 与 Entra ID P1，而 Business Standard/Basic 不包含 Intune。

界面上有的功能，也可能需要另外的许可

特别要留意以下两点。

套餐构成不是固定的。进入 2026 年以后，也在持续调整搭售内容，例如把 Intune Suite 的功能重新分配到 Microsoft 365 的高阶套餐（E3/E5 等）。本节请当作截至 2026 年 8 月的信息，签约前请确认官方的许可页面与价格页面。⁶

能从 Intune 管理界面用到，和合约上可以用，是两回事。典型例子是 Remediations。它需要 Windows Enterprise E3/E5 系列（随 Microsoft 365 E3/E5 等搭售）的许可，在 Business Premium 的范围内无法使用。替代方法在第 5 章梳理。⁹

要比的不是“订阅对零元”，而是五年的费用

GPO 一侧同样会产生费用：AD 服务器的硬件更新换代、Windows Server 许可与 CAL、搭建、五年的维护、备份、故障处理。

把服务器更新换代的报价单，和 Business Premium 五年的差额摆在一起。在此基础上，再计入能否把管理送达公司外 PC 这一能力差异。这就是费用比较的主轴。

flowchart TB
    accTitle: 费用比较的正确思路
    accDescr: GPO 一侧同样会产生 AD 服务器更新换代与许可以及五年维护等费用，因此要把服务器更新换代的报价与 Business Premium 五年的差额摆在一起，再计入能否把管理送达公司外 PC 这一能力差异来判断
    gpocost["继续用 GPO 的费用"] --> hw["服务器更新换代、许可、CAL"]
    gpocost --> ops["搭建、维护、备份"]
    bpcost["迁移到 Intune 的费用"] --> sub["Business Premium 五年"]
    hw --> diff["把五年的差额摆在一起"]
    ops --> diff
    sub --> diff
    diff --> ability["再计入能否管到公司外 PC"]

图9：把服务器更新换代的报价与 Business Premium 的五年费用摆在一起，再计入管到公司外 PC 这一能力差异来判断。

5. 过去用 GPO 做的事，在 Intune 里怎么做

主要工作在 Intune 侧都有对应功能

在把 GPO 的名称和设置原样搬过去之前，先把它实现的工作与去处对应起来。

设置目录是管理模板的去处

设置目录相当于“云版的 GPO 编辑器”界面。Microsoft 也把它定位成：当你想像本地 GPO 那样做细致配置时，自然的迁移去处。

其中也包含 ADMX 所定义设置的 MDM 版，即 ADMX 支持的策略，还有导入第三方 ADMX 的功能（预览版）。¹⁰

脚本按“希望什么时候执行”来选

Remediations 是由旧称 Proactive remediations 更名而来的功能，会定期执行检测脚本与修复脚本这一对脚本。它可以替代“每次登录都修一下什么”这类运维，但需要第 4 章提到的 Windows Enterprise E3/E5 系列许可。⁹

在 Business Premium 的范围内，把平台脚本与 Win32 应用的检测规则组合起来是现实的做法。平台脚本在分配后执行，脚本或分配发生变更时会重新执行，失败时会重试；它与定期执行的 Remediations 要区分开。¹⁶

把“判定是否合规”和“拦住访问”分开

合规性策略＋条件访问是 GPO 时代没有的思路。可以定义“BitLocker 已启用、系统为最新、Defender 正在运行”等合规条件，并阻止不满足条件的设备访问 Microsoft 365。¹¹

职责分成两部分：合规性策略负责判定合规状态，条件访问负责控制访问。只有当条件访问策略要求设备合规时，阻断才会生效。条件访问是 Entra ID P1 的功能，包含在 Business Premium 中。¹¹

flowchart TB
    accTitle: 合规性策略与条件访问的流程
    accDescr: 合规性策略只是依据合规条件判定设备的合规状态，只有当条件访问策略要求设备合规时，合规设备才被允许而不合规设备才被阻止
    policy["定义合规条件"] -.-> cond["如 BitLocker 已启用或系统为最新"]
    policy --> state["判定设备的合规状态"]
    state --> ca["条件访问要求设备合规"]
    ca -->|合规| allow["可访问 Microsoft 365"]
    ca -->|不合规| block["阻止访问"]

图10：判定合规状态是合规性策略的职责，拦截是条件访问的职责。二者组合起来阻断才生效。

更新管理的选项（WUfB、Autopatch、继续用 WSUS 的判断）在“WSUS 弃用后的 Windows Update 管理”中讲解，BitLocker 与 LAPS 的设计则在“BitLocker 实务指南”“Windows LAPS 实务指南”中详细展开。

6. 现行 GPO 的盘点——用 Group Policy analytics 分类

第一项实际作业，是按设置逐条分析 GPO

迁移计划的第一项实际作业，是盘点现行 GPO。使用 Intune 自带的 Group Policy analytics，不必手工解读 GPO，就能按设置逐条区分能否迁移到 MDM。⁴

按这个流程，就能把已支持的设置迁到 Intune 侧。⁴

flowchart TB
    accTitle: 用 Group Policy analytics 盘点的流程
    accDescr: 在 GPMC 中把 GPO 导出为 XML 并导入到 Intune 后会显示 MDM 支持率与每条设置能否迁移，Ready for migration 的设置可以转换为设置目录的策略
    export["在 GPMC 中把 GPO 导出为 XML"] --> import["导入到 Intune"]
    import --> rate["显示 MDM 支持率"]
    rate --> report["迁移准备情况报告"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["转换为设置目录的策略"]

图11：从导出 XML 到导入、逐条设置分类、再转换为设置目录，这就是 Group Policy analytics 的流程。

日语 GPO 不能只看支持率下结论

非 ADMX 设置的分析只支持英语。导入包含英语以外语言设置的 GPO 时，MDM 支持率可能不准确。在日语环境下尤其要注意。⁴

支持率是粗略的参考值。最终判断要看逐条设置的列表。

flowchart TB
    accTitle: 分析日语 GPO 时的注意事项
    accDescr: Group Policy analytics 对非 ADMX 设置的分析只支持英语，含日语设置的 GPO 其 MDM 支持率可能不准确，因此支持率只作粗略参考而最终判断要看逐条设置的列表
    jgpo["含日语设置的 GPO"] --> limit["非 ADMX 分析只支持英语"]
    limit --> rate["支持率可能不准确"]
    rate --> use1["支持率只作粗略参考"]
    rate --> use2["最终判断看逐条设置的列表"]

图12：日语 GPO 的 MDM 支持率可能不准确，因此最终判断要看逐条设置的列表。

把分析结果分成“丢弃、迁移、替代”

工具给出的能否迁移，和今后是否还需要这项设置，要分开判断。

运行了十年的 GPO 里，会残留相当多的老旧设置。能把不需要的设置丢掉，本身就是盘点的重大成果。并不需要把所有能迁的设置都迁过去。

没有对应设置的典型例子及替代方向如下。

flowchart TB
    accTitle: 盘点结果的三类分法
    accDescr: 盘点结果分成丢弃的设置、迁到 Intune 并验证的设置、没有对应设置而需要设计替代方案的设置这三堆来处理
    result["分类结果"] --> discard["丢弃的设置"]
    result --> move["迁到 Intune 的设置"]
    result --> alt["需要设计替代方案的设置"]
    discard -.-> legacy["清掉堆积下来的遗留物"]
    move --> pilot["转换为设置目录并验证"]
    alt --> design["下发脚本或做成应用"]

图13：盘点结果分成“丢弃”“迁到 Intune”“设计替代方案”三堆。

7. 分阶段迁移方案——五个阶段与完成条件

先把“做什么”和“何时算完成”对齐

部署分成五个阶段，每个阶段都设定完成条件。为了让一个人的信息系统岗也不会让迁移半途而废，在动手之前先确定“到什么程度才能说结束了”。

flowchart TB
    accTitle: 五阶段迁移方案
    accDescr: 从试点到基本策略、应用下发、按替换周期更换既有 PC、缩减 AD 的职责逐阶段推进，最终让 GPO 下发的设置降为零
    s1["① 试点"] --> s2["② 基本策略"]
    s2 --> s3["③ 应用下发"]
    s3 --> s4["④ 既有 PC 的自然替换"]
    s4 --> s5["⑤ 缩减 AD 的职责"]
    s5 -.-> goal["GPO 下发的设置为零"]

图14：迁移从试点到缩减 AD 职责分五个阶段推进，各阶段的完成条件要事先定好。

① 试点：从反正要买的 PC 开始

从下一批新员工用 PC、故障替换机等新采购的 PC 开始。优点是不必额外买 PC 就能试，失败了也可以擦除重来。

台数多起来之后，可以考虑用 Windows Autopilot 把从 OOBE（初始安装）到 Entra join＋注册 Intune 的过程自动化。一开始并非必需。¹

② 基本策略：先收敛到五项

不要试图重现 GPO 的全部设置，先从更新、加密、Defender、锁屏、LAPS 这五项开始。请用合规性策略把合规状态可视化。

把条件访问的“仅允许合规设备访问”打开，应放在确认试点中没有误判之后。¹¹

③ 应用下发：减少装机中的手工操作

应用下发会带来装机自动化。如果已经整理好基于 winget 的流程，那些资产几乎可以原样用作 Store 应用（新）或 Win32 应用的封装。¹⁵

从操作手册出发推进自动化的方法，请参考“用 winget + PowerShell 自动化 PC 装机”。

④ 既有 PC：配合替换周期

如第 3 章所述，既有的加入域 PC 没有不擦除就转成 Entra join 的正式路径。原则上按替换周期更换，只对要提前处理的 PC 擦除后切换。

还留着从 Windows 10 更换计划的组织，与那个计划同步推进就能避免重复劳动。相关选项在“Windows 10 停止支持后的现实解”中做了梳理。

⑤ 缩减 AD 的职责：GPO 空了，身份验证的职责仍可能保留

GPO 清空，和 AD 不再需要，并不是一回事。只要还有文件服务器的身份验证或遗留应用的 LDAP 查询，AD 就会作为身份验证服务器缩减后继续运行。

把残留职责盘点出来并设定期限，才是这个阶段的工作。当职责都消失后，再考虑停用 AD 本身。

flowchart TB
    accTitle: GPO 清空之后如何对待 AD
    accDescr: 即使 GPO 清空了，只要还有文件服务器的身份验证或遗留应用的 LDAP 查询，AD 就会作为身份验证服务器缩减后继续运行，而最后阶段的工作就是盘点残留职责并设定期限
    gpoempty["GPO 已清空"] --> remain{"还剩哪些职责?"}
    remain -->|文件服务器身份验证| keep["作为身份验证服务器缩减后继续"]
    remain -->|遗留应用的 LDAP 查询| keep
    remain -->|没有职责| retire["考虑停用 AD 本身"]
    keep --> task["做到盘点并设定期限"]

图15：即使 GPO 清空了，只要还有残留职责，AD 就会作为身份验证服务器缩减后继续运行。

8. 容易踩坑的地方

8.1. GPO 与 MDM 的双重下发——默认 GPO 获胜

迁移期间，会出现从 GPO 和 Intune 两边同时向 hybrid join 机器下发设置的场面。此时若同一项设置发生冲突，默认由 GPO 一侧优先。

把 Policy CSP 的 MDMWinsOverGP 设为 1，MDM 侧的设置就会优先，对应的 GPO 设置会被阻止。不过，适用范围只限于 Policy CSP 之下的设置，不适用于 Defender CSP 等其他 CSP 定义的设置。对于不在其管辖范围内的设置，如果由 GPO 和 MDM 同时配置，Microsoft 也明确写明不保证哪一侧获胜。⁵

flowchart TB
    accTitle: GPO 与 MDM 冲突时的优先关系
    accDescr: 同一项设置由 GPO 与 MDM 同时下发时默认由 GPO 优先，把 MDMWinsOverGP 设为 1 后只有 Policy CSP 之下的设置才由 MDM 优先，其他 CSP 的设置则不保证胜负
    both["同一项设置由 GPO 与 MDM 同时下发"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|否| gpowin["GPO 优先（默认）"]
    flag -->|是| csp{"是 Policy CSP 之下的设置吗?"}
    csp -->|是| mdmwin["MDM 优先"]
    csp -->|否| unknown["不保证哪一侧获胜"]
    both -.-> avoid["原则上不要两边都下发"]

图16：默认由 GPO 获胜，MDMWinsOverGP 只对 Policy CSP 之下有效。原则是避免双重下发。

实务上的原则是，不依赖优先级控制，不把同一项设置从两边下发。迁到 Intune 的设置，要把对应的 GPO 侧改回“未配置”，或者把整个 GPO 的链接解除。把盘点过的设置记入第 7 章②的已迁移清单，也是为了避免双重管理。

8.2. 对本地资产的依赖——网络驱动器与打印机

卡壳的地方多数不在 Intune 的功能，而在与本地资产的连接。即便 Entra join 的机器能访问文件服务器，只要驱动器映射和打印机下发还依赖 GPO 的登录脚本，先消失的就是那个下发手段。¹

是把共享迁到 OneDrive / SharePoint，还是换成 Universal Print，抑或暂时用下发脚本过渡，要在试点期间定下来。若要替换，请把它纳入第 7 章③的应用下发阶段。¹⁶

flowchart TB
    accTitle: 替换依赖本地资产的下发方式
    accDescr: 驱动器映射与打印机下发若依赖 GPO 的登录脚本，迁移时会先失去下发手段，因此要在试点期间定下是迁到 OneDrive 或 SharePoint、换成 Universal Print，还是暂时用下发脚本过渡
    dep["依赖登录脚本"] --> lost["迁移后先失去下发手段"]
    lost --> share["迁到 OneDrive/SharePoint"]
    lost --> print["换成 Universal Print 等"]
    lost --> script["用下发脚本过渡"]
    share --> decide["在试点期间定下方针"]
    print --> decide
    script --> decide

图17：依赖登录脚本的下发在迁移时会先失去手段，所以要在试点期间定好替换去处。

8.3. 重新设计装机流程——Autopilot 并非“必需”

有人会把 Autopilot 和 Intune 迁移打包推荐，但如果每年只采购几台到十几台，用在 OOBE 中登录工作账户、手动 Entra join 的做法也不会有实际损害。

Autopilot 发挥作用的场景，是采购台数增加、从开箱起的无人安装开始有价值时，或者能使用经销商侧的设备注册时。它可以等第 7 章②③就绪后再加上，并不是迁移的前提条件。

flowchart TB
    accTitle: 是否引入 Autopilot 的判断
    accDescr: 每年采购几台到十几台的规模，用在 OOBE 中手动 Entra join 的做法不会有实际损害，等采购台数增加、无人安装开始有价值时再补上 Autopilot 即可
    scale{"每年的采购规模?"} -->|几台到十几台| manual["在 OOBE 中手动 Entra join"]
    scale -->|台数增加后| ap["用 Autopilot 实现无人化"]
    ap -.-> later["等②③就绪后再加"]

图18：采购规模不大时手动 Entra join 就够了，Autopilot 可以后补。

8.4. “不全部换成 Intune 就不行”这个误解

Entra join 的机器与加入域的机器共存，是官方支持的架构。AD 还留着，并不意味着迁移失败。¹

GPO 里留着几条设置、并行运行好几年的公司也不少见。即便如此，让新 PC 全部由云端管理、在公司外也能管控，这个状态本身就有很大价值。与其执着于完全迁移的形式，不如优先选择可以回退的小步前进。

flowchart TB
    accTitle: 不执着于完全迁移的并行价值
    accDescr: AD 还留着并不等于迁移失败，即使 GPO 里还留着设置并行运行数年，让新 PC 全部由云端管理并在公司外也能管控的状态仍有很大价值
    miscon["AD 还留着就算迁移失败?"] -->|并非如此| run["GPO 保留设置并行数年"]
    run --> value["新 PC 在公司外也能管控"]
    value -.-> forward["优先小步前进"]

图19：即使 AD 还留着并行运行，让新 PC 全部由云端管理的状态也有很大价值。

9. 一个人的信息系统岗的现实解

在只有一名负责人、或由他人兼任的公司里，要先确定引入后能维持住的范围。

收敛管理项与标准 PC 形态

最初的管理项收敛到第 7 章②的五项（更新、加密、Defender、锁屏、LAPS）。思路是只在出现需要时才增加设置。设置目录里有数千项设置，并没有全部都用的义务。¹⁰

标准 PC 形态也定成一套：“本公司的 PC 就是这组策略加这组应用”。按部门的例外可以用组或筛选器表达，但例外越多，一个人就越难维持。

设计交给外部，日常运维要能自己转起来

对外部合作方，要求的是初期设计、策略模板的制作、迁移判断上的咨询。而日常的 PC 添加与策略微调，请把“自己能做”定为目标状态。

不要把搭建整个甩出去，最后落到“没人看得懂管理界面的含义”的状态，这一点很重要。要选择能把日常运维一并交接给你的合作方。

变更一次一项，在报告中确认后再进行下一项

策略变更一次只做一项，在 Intune 的报告中确认应用状态和分配失败情况后，再进行下一项。

MDM 的常态同步周期约为 8 小时。“没生效”的情况多数不是故障而是时间问题，所以要结合同步间隔来确认结果。³

flowchart TB
    accTitle: 策略变更的运维循环
    accDescr: 策略变更一次只做一项，在 Intune 的报告中确认应用状态后再进行下一项变更。没生效的情况多数等约 8 小时周期的同步就能解决
    change["一次只做一项策略变更"] --> report["在报告中确认应用状态"]
    report --> next["没问题就进行下一项变更"]
    next --> change
    report -.-> wait["多数未生效只是在等同步"]

图20：策略变更一次只做一项，在报告中确认结果后再进行下一项。

10. 总结

从 GPO 迁移到 Intune，是一项改变把管理送达公司外 PC 的方式、并逐步减少不必要设置的工作。GPO 的前提是能连到域控制器，而 Intune 经互联网同步。不过需要结合约 8 小时的常态同步间隔和变更时的通知来运维。

推进方式上，基本做法是把新 PC 切换到 Entra join+Intune，既有 PC 按替换周期更换的分阶段迁移。确认对本地资产做单点登录的前提，若 AD 还保留着身份验证等职责，就继续共存。

现行 GPO 用 Group Policy analytics 盘点，分成“丢弃、迁移、替代”。日语 GPO 的支持率只作参考值，请逐条设置判断。在此基础上，按试点→基本策略→应用下发→既有 PC 的更换→缩减 AD 职责这五个阶段，带着完成条件推进。

迁移期间的原则是不把同一项设置从 GPO 和 MDM 两边下发。用 MDMWinsOverGP 让 MDM 优先只限于 Policy CSP 之下，因此要做成不依赖优先级控制的架构。

许可可以从 Business Premium 起步，但 Remediations 等功能的适用范围和最新的合约内容要用官方信息确认。费用要比较服务器更新换代与五年的差额，并把能否管到公司外 PC 这一能力差异也计入判断。

当服务器更新换代的报价出来时，正是考虑这次迁移的好时机。在“AD 再来一轮”之前，请先从思考未来五年的 PC 会在哪里使用开始。

相关文章

• 组策略（GPO）实务入门——机制、生效确认与同 Intune 的分工
• WSUS 弃用后的 Windows Update 管理——WUfB、Autopatch、Intune 该怎么选
• Windows 10 停止支持后的现实解——ESU、LTSC、换机的判断表
• 用 winget + PowerShell 自动化 PC 装机——让操作手册变得可执行
• BitLocker 实务指南——从恢复密钥管理入手的驱动器加密
• Windows LAPS 实务指南——告别全部 PC 通用的本地管理员密码

相关的咨询领域

小村软件有限公司提供以下咨询：从 AD+GPO 环境到 Entra ID+Intune 的分阶段迁移设计（现行 GPO 的盘点、策略重现方针、试点计划），服务器更新换代与上云迁移的比较论证，以及利用既有业务应用与装机资产的迁移。哪怕只是一起探讨“该不该再买一台 AD 服务器”也可以。

• 技术咨询与设计评审
• 现有资产复用与迁移支持
• 联系我们

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

从 GPO 迁移到 Intune 后，现在使用的组策略设置能全部重现吗？

无法全部重现。Intune 的设置目录包含数千项 Windows 设置，其中也有来自 ADMX 的设置，多数安全设置和限制都能迁走；但也有一些设置在 MDM 侧没有对应项，例如用登录脚本映射网络驱动器、批量下发打印机。把现行 GPO 导出的 XML 导入 Intune 的 Group Policy analytics，就能逐条区分每项设置能否迁移（Ready for migration / Not supported / Deprecated）。没有替代手段的设置，可以改用下发 PowerShell 脚本、做成应用，或者干脆“不再使用该设置”来处理。

使用 Intune 需要哪种许可？

基础是 Microsoft Intune Plan 1，可以单独订阅；不过中小企业通常是以包含在 Microsoft 365 Business Premium（最多 300 个用户）里的形式使用。Business Premium 也包含 Entra ID P1，因此可以一直用到合规性策略与条件访问的组合。另一方面，也有像 Remediations 这样另外要求 Windows Enterprise E3/E5 系列许可的功能。套餐构成变动频繁，签约前请在 Microsoft 官方许可页面确认最新内容（本文以 2026 年 8 月为准）。

AD 服务器必须马上停用吗？

不必。用 Entra join+Intune 管理的 PC，与用 AD 加入域+GPO 管理的 PC，可以在同一个公司内网中共存。为了文件服务器的身份验证和既有业务系统而保留 AD，只把新购 PC 改成 Entra join，这种分阶段迁移更现实。反过来说，把既有的加入域 PC“转换”成 Entra join 并没有正式手段，需要擦除（重置），所以既有机器按替换周期更换才是常规做法。等 GPO 清空、残留职责也梳理清楚之后，再考虑停用 AD 完全来得及。

为什么居家办公的 PC 上组策略不生效？

因为 GPO 的机制是能连上域控制器时才获取并应用。公司外的 PC 只有通过 VPN 等连到域控制器时才收得到最新策略，对不使用 VPN 的居家 PC 实际上等于送不到。Intune（MDM）经互联网同步策略，PC 在哪里都能管理，公司外 PC 的管理难题在 MDM 的结构层面就消解了。除了大约每 8 小时一次的定期同步，策略变更时还会通过通知触发同步。

同一项设置由 GPO 和 Intune 同时下发时，哪一侧优先？

默认情况下，冲突的设置由组策略一侧优先。把 MDMWinsOverGP 策略设为 1 就会改成 MDM（Intune）一侧优先，但这套机制只对 Policy CSP 之下的设置有效，不适用于 Defender CSP 等其他 CSP 定义的设置。依赖优先级控制会让行为难以预测，所以实务上应以“同一项设置不从两条通道下发”为原则，迁到 Intune 的设置就从原来的 GPO 中删除，避免双重管理，这样更安全。

作者简介

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

Go Komura

小村软件有限公司 代表

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