从组策略到 Intune ── 中小企业的设备管理迁移指南

「服务器支持期限到了，我们在规划更换。但已经没把握该不该再买一台 AD 服务器，再跑一轮（五年）域和组策略。」「在办公室决定的组策略，从来套用不到远程工作用的笔记本。如果只有连上 VPN 才套用，真的算管到了吗？」── 这几年，中小企业客户这类咨询稳定增加。

背景是工作方式变了。内部部署的 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["带回家与远程工作成常态"] --> broken["坏掉的是假设"]
    premise --> broken
    wsus["WSUS 已弃用"] --> shift["重心移到 Entra ID+Intune"]
    broken --> shift

图 1: 「PC 在公司区域网络」这个 AD+GPO 假设，随工作方式改变而坏掉，管理重心移到 Entra ID+Intune。

话虽如此，迁移不是全有或全无。用 Entra join 加 Intune 管理的 PC，与 AD 域加入加 GPO 的 PC，可以在同一家公司共存，² 也可以分阶段迁移：文件服务器先留 AD，新 PC 改由 Intune 管理。本文以中小企业的信息人员与经营者为对象，依 2026 年 8 月当下 Microsoft Learn 等一次信息，整理 GPO 与 MDM 运作方式的差异、前置配置、许可、怎么盘点现行 GPO、分阶段迁移情境，以及容易踩的坑。

1. 先讲结论

• GPO 在 PC 连上域网络时套用；Intune（MDM）经互联网同步。「设置永远到不了家用 PC」这个问题，在 MDM 结构上不会发生。稳态同步大约每 8 小时，策略变更时也会跑通知驱动的同步。³
• 迁移不是全有或全无；假设共存的分阶段迁移才是务实答案。 Microsoft 自己建议新 PC 做 Entra join，既有域加入的 PC 先当 hybrid join，跟着硬件更新周期替换。²
• Intune 可以单独订阅，但中小企业务实的路是用 Microsoft 365 Business Premium 内含的 Intune Plan 1（截至 2026 年 8 月）。 方案组成一直在变，签约前务必确认一次信息。⁴⁵
• 盘点现行 GPO，用 Intune 内建的 Group Policy analytics。 导入 GPO 的 XML 导出后，每条设置会依能否迁移分类；有对应项的设置可转成 Settings catalog 策略。⁶
• GPO 时代的主要工作，几乎都有 Intune 对应。 管理模板对应 Settings catalog，⁷ WSUS 对应 Windows Update for Business，BitLocker 恢复密钥对应存进 Entra ID，⁸ 本地管理员密码对应 Windows LAPS，⁹ 应用部署对应 Win32 应用（.intunewin）¹⁰ 与 Microsoft Store 应用（以 winget 为基础）。¹¹
• 无法原样搬走的经典项目是登录脚本、驱动器对应、打印机部署。 改用 PowerShell 脚本部署、¹² Remediations（旧称 Proactive remediations）、¹³ 把工作做成应用，或「停掉那个做法」。
• 不要从 GPO 和 MDM 两边部署同一条设置。 默认冲突时 GPO 赢。把 MDMWinsOverGP 设成 1 会让 MDM 赢，但只适用 Policy CSP 设置。¹⁴
• 域加入的机器与 Entra join 的机器可以共存，Entra join 的机器也能访问内部文件服务器。 立刻退役 AD 不是迁移的条件。²

用一句话说：「该不该再换一轮 AD 服务器」这个问题，应改写成「未来五年，场外那些 PC 要用什么管」再做决定。

flowchart LR
    accTitle: 该决定的问题要改写
    accDescr: 要不要再换一轮 AD 服务器这个问题，应改写成未来五年要用什么管场外 PC
    q1["再换一轮 AD 服务器？"] -->|改写| q2["未来 5 年，场外 PC 用什么管？"]

图 2: 把换服务器的问题改写成「未来五年，场外那些 PC 要用什么管」再做决定。

2. GPO 与 MDM 哪里不一样 ── 比较套用机制

先把两者放在同一张场上比。GPO 机制本身（LSDOU 套用顺序、用 gpupdate/gpresult 确认）深入见「组策略(GPO)实务入门」，这里只收敛到影响迁移决定的差异。

迁移决定最重要的是第一列与第三列。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 平台这块基础建设。

另一方面，MDM 同步间隔（约 8 小时）比 GPO 的定期刷新（约 90 分钟）粗，「部署了就立刻套用」的手感带不过去。指派或变更策略时会通知设备、相对快地同步，³ 但需要即时性的控制（紧急封锁等）必须把同步间隔算进设计。

flowchart TB
    accTitle: GPO 与 MDM 如何套用策略
    accDescr: GPO 只有 PC 连得上公司内部域控制器才套用，家用 PC 依赖 VPN；Intune 经互联网大约每 8 小时同步，策略变更时也会通知同步，因此 PC 在哪都涵盖得到
    officepc["公司内部 PC"] --> dc["域控制器"]
    officepc -.-> when["启动与登录"]
    when -.-> when2["加上定期刷新"]
    homepc["家用 PC"] --> vpn{"能经 VPN 连到 DC？"}
    vpn -->|能| dc
    vpn -->|不能| miss["策略永远到不了"]
    anypc["无论在哪的 PC"] --> intune["Intune 服务"]
    anypc -.-> every["约每 8 小时同步"]
    intune -.-> notify["变更时通知驱动"]
    dc ~~~ homepc
    miss ~~~ anypc

图 4: GPO 只有 PC 连得上域控制器才套用；Intune 不论位置都经互联网同步。

3. 先整理前置条件 ── 域加入、Hybrid Join、Entra Join 三种形态

「Windows PC 怎么加入公司」有三种形态，选哪一种决定能用哪些管理工具。²

Hybrid join 是「给既有域加入的 PC 一个云端身份」的形态，可以一边留着既有资产、一边开始用 Intune 与条件式访问。不过 Microsoft 建议不要把 hybrid join 当最终目标，新机与更换的 PC 做 Entra join。²

这里有一个要掌握的限制。没有 Microsoft 支持的办法，能把既有域加入的 PC（含 hybrid join）转换成 Entra join；需要 Windows 重设（清除）。 因此 Microsoft 也建议在硬件更新或重装 OS 时再转到 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 切过去。

由此，中小企业务实的目标可以这样写。

1. 新机与更换的 PC 用 Entra join 加 Intune 管理
2. 既有域加入的 PC 先不动，让它们在硬件更新周期自然替换
3. 文件服务器验证等剩余角色暂时留 AD，分阶段把 GPO 内容清空

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 的机器也能访问内部文件服务器这类内部资产。² 不过那种单一登录有两个前提。（1）用户是用 Entra Connect（或 Cloud Sync）从内部 AD 同步过来的混合身份（只存在云端的用户拿不到 AD Kerberos/NTLM 认证数据），以及 （2）PC 对域控制器有网络可达性（场外需要 VPN 等）。¹⁵ 在迁移计划里，先确认没有用户或使用情境踩破这两点。

flowchart TB
    accTitle: Entra join 机器对内部资产做 SSO 的前提
    accDescr: 要从 Entra join 机器访问内部文件服务器，必须满足两个前提：用 Entra Connect 等同步的混合身份，以及连得上域控制器
    pc["Entra join 机器"] --> cond1{"混合身份？"}
    cond1 -->|是| cond2{"连得上 DC？"}
    cond1 -->|否| ng1["拿不到 AD 认证数据"]
    cond2 -->|是| ok["对文件服务器 SSO"]
    cond2 -->|否| ng2["场外需要 VPN 等"]

图 7: Entra join 机器对内部资产的 SSO 有两个前提：混合身份，以及连得上域控制器。

4. 许可与成本 ── 哪些方案内含 Intune（截至 2026 年 8 月）

Intune 的基础许可是 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 月的快照，签约前务必在 Microsoft 的许可与定价页确认最新信息。
• 有些能从 Intune UI 打开的功能需要另外许可。 代表性例子是后文的 Remediations：它需要 Windows Enterprise E3/E5 等级许可（捆在 Microsoft 365 E3/E5 等），Business Premium 范围内不能用。¹³

成本比较不是「Intune 订阅费用」对「零」。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 怎么做

GPO 营运的主要工作，各自的 Intune 对应列在对照表。

几点补充。

• Settings catalog 是对应「云端版 GPO 编辑器」的画面，Microsoft 自己把它定位成「想用与内部 GPO 一样细的方式设置时，自然的迁移目的地」。它包含以 ADMX 为后盾的原则（ADMX 定义设置的 MDM 版），也有导入第三方 ADMX 的（预览）功能。⁷
• 合规策略加条件式访问 是 GPO 没有的想法。你定义「BitLocker 开、OS 够新、Defender 在跑」这类合规条件，就能封锁不符合的设备访问 Microsoft 365。条件式访问是 Entra ID P1 功能，含在 Business Premium。¹⁶
• Remediations 已从 Proactive remediations 更名。 它定期跑检测脚本加修复脚本这一对，可以取代「每次登录都修一点东西」那种 GPO 营运，但如前所述需要 Windows Enterprise E3/E5 等级许可。¹³ 在 Business Premium 范围内，务实替代是把平台脚本（脚本或指派变更时跑，失败会重试）¹² 与 Win32 应用检测规则合在一起。
• 更新管理的细项选择（在 WUfB、Autopatch、继续用 WSUS 之间决定）见「WSUS 弃用后的 Windows Update 管理」，BitLocker 与 LAPS 的设计分别见「BitLocker 实务指南」与「Windows LAPS 实务指南」。

flowchart TB
    accTitle: 合规策略与条件式访问的流程
    accDescr: 合规策略只依合规条件判定设备的合规状态；只有条件式访问原则要求合规设备时，合规设备才被允许、不合规设备才被封锁
    policy["定义合规条件"] -.-> cond["BitLocker 开、OS 够新等"]
    policy --> state["判定设备合规状态"]
    state --> ca["条件式访问要求合规"]
    ca -->|合规| allow["允许 Microsoft 365 访问"]
    ca -->|不合规| block["封锁访问"]

图 10: 判定合规状态是合规策略的工作；封锁是条件式访问的工作。合在一起封锁才生效。

6. 盘点现行 GPO ── 用 Group Policy Analytics 分类

迁移计划真正的第一件事是盘点现行 GPO。Intune 有专用功能 Group Policy analytics，不必亲手读 GPO，就能依设置分类「MDM 能不能取代」。⁶

步骤如下。⁶

1. 在域控制器等开启组策略管理控制台（GPMC.msc），对目标 GPO 按右键 → Save Report，导出成 XML 档（每个文件 4 MB 以下）
2. 在 Intune 管理中心，到 Devices → Group Policy analytics，导入 XML（可复选）
3. 自动分析后，每个 GPO 会显示 MDM 支持百分比（在 Intune 有对等项的设置占比）
4. 在 Group policy migration readiness 报表确认每条设置的分类：Ready for migration / Not supported / Deprecated
5. Ready for migration 的设置可以原样转成 Settings catalog 策略再部署

flowchart TB
    accTitle: 用 Group Policy analytics 盘点的流程
    accDescr: 从 GPMC 把 GPO 导出成 XML 再导入 Intune；会显示 MDM 支持百分比与每条设置的迁移就绪度，Ready for migration 的设置可转成 Settings catalog 策略
    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["转成 Settings catalog 策略"]

图 11: 从 XML 导出、导入、依设置分类、转到 Settings catalog──就是 Group Policy analytics 的流程。

日文环境有一个重要注意点。Group Policy analytics 对非 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 支持百分比可能不准，因此最终判断看每条设置的清单。

实务上，把分类结果拆成三堆。

1. 该丢掉的设置── Internet Explorer 时代的设置、已退役系统的设置、没人说得出理由的设置。盘点最大的收获，其实是能把这堆丢掉。跑了十年的 GPO，堆积的遗留相当可观。
2. 该搬到 Intune 的设置── Ready for migration 里你还需要的那些。转成 Settings catalog，用试点群组验证。
3. 该设计替代的设置── Not supported 里你还需要的那些。代表性例子与替代方向如下。

flowchart TB
    accTitle: 盘点结果的三堆
    accDescr: 盘点结果分成三堆处理：该丢掉的设置、该搬到 Intune 再验证的设置，以及没有对应项、要设计替代的设置
    result["分类结果"] --> discard["该丢掉的设置"]
    result --> more{"搬走还是替代？"}
    more --> move["搬到 Intune"]
    more --> alt["设计替代"]
    discard -.-> legacy["清掉遗留"]
    move --> pilot["Settings catalog"]
    pilot -.-> pilotN["再验证"]
    alt --> design["脚本或做成应用"]

图 13: 把盘点结果拆成「丢掉」、「搬到 Intune」、「设计替代」三堆。

7. 分阶段迁移情境 ── 五个阶段与退出条件

把整体拆成五个阶段，每个阶段放退出条件。事先决定「做到什么叫做完」，是一人信息部门迁移不卡住的诀窍。

flowchart TB
    accTitle: 五阶段迁移情境
    accDescr: 从试点经基准策略、应用部署、既有 PC 在硬件更新周期自然替换，到缩小 AD 的角色，分阶段推进，最后把经 GPO 部署的设置变成零
    s1["（1）试点"] --> s2["（2）基准策略"]
    s2 --> s3["（3）应用部署"]
    s3 --> s4["（4）既有 PC 自然替换"]
    s4 --> s5["（5）缩小 AD 的角色"]
    s5 -.-> goal["经 GPO 部署的设置是零"]

图 14: 从试点到缩小 AD 角色分五阶段推进迁移，每个阶段的退出条件事先决定。

各阶段的重点。

• （1）试点 从反正要买的 PC 开始──下一台新人 PC、故障更换等。从新机器开始的好处是额外投资为零，失败可以清除重来。数量变多后，再考虑用 Windows Autopilot 把从 OOBE（初始设置）到 Entra join 加 Intune 注册自动化。²
• （2）基准策略 不要以重现每一条 GPO 设置为目标。先收敛到更新、加密、Defender、屏幕锁定、LAPS 这五项，用合规策略把合规状态视觉化。在条件式访问开启「只允许合规设备」，要等试点确认没有误判之后。¹⁶
• （3）应用部署 与自动化预配连在一起。若已有以 winget 为基础的步骤（「用 winget + PowerShell 自动化 PC 配置」），那份资产几乎可以原样重用成 Store 应用（新）或 Win32 应用包装。¹¹
• （4）既有 PC 如第 3 章所说，没有转成 Entra join 的路径，因此原则是自然替换。仍有 Windows 10 更换计划的组织（「Windows 10支持结束后的现实解方」）可以把那次更换与（4）同时推进，避免做两次。
• （5）缩小 AD 的角色 清空 GPO 不代表 AD 立刻不需要。若文件服务器验证、旧应用的 LDAP 查询等还在，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 都会对同一台 PC（hybrid join 的机器）部署设置。这里，同一条设置冲突时，默认组策略赢。把 Policy CSP 的 MDMWinsOverGP 设成 1 会让 MDM 侧设置赢，并挡住对应的 GPO 设置，但这套机制只适用 Policy CSP 底下的设置，不适用 Defender CSP 等其他 CSP 定义的设置。Microsoft 自己也说，若对不在 MDMWinsOverGP 底下的设置同时从 GPO 与 MDM 设置，会进入冲突状态，不保证谁赢。¹⁴

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 侧配置改回「Not configured」，或干脆解除 GPO 链接。第 6 章的已迁移清单，也是这件事的帐本。

8.2. 依赖内部资产 ── 网络驱动器与打印机

迁移卡住的地方，很多不是 Intune 功能，而是连到内部资产。从 Entra join 机器访问内部文件服务器本身做得到，² 但若驱动器对应与打印机部署依赖 GPO 登录脚本，那个部署手段会先消失。在试点期间决定：要把共享移到 OneDrive/SharePoint 或改用 Universal Print 收进阶段（3），还是暂时用脚本部署搭桥。¹²

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 不是「必要」

有时会被建议把 Windows Autopilot 与 Intune 迁移当一套导入，但一年只采购几台到十几台的规模，在 OOBE 用公司帐户登录并手动 Entra join，实质上没有坏处。Autopilot 开始划算，是采购数量变多、从拆箱无人值守设置有价值，或能用经销商侧的设备注册的时候。等（2）与（3）就位再加进去就好；它不是迁移的前提。

flowchart TB
    accTitle: 要不要导入 Autopilot 的决定
    accDescr: 一年只采购几台到十几台时，在 OOBE 手动 Entra join 实质上没有坏处；等采购数量变多、无人值守设置有价值时再加 Autopilot
    scale{"一年采购规模？"} -->|几台到十几台| manual["OOBE 手动 Entra join"]
    scale -->|数量变多之后| ap["用 Autopilot 无人值守"]
    ap -.-> later["等（2）与（3）就位再加"]

图 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. 一人信息部门的务实答案

最后，整理负责人只有一位（或当兼职）的公司该怎么设计营运。

• 管理项目从一开始就收敛。 若想把 GPO 时代每一条设置都带进来，光盘点就会把自己耗尽。从第 7 章（2）的五项（更新、加密、Defender、屏幕锁定、LAPS）开始，做成「只有需要时才加设置」的减法设计。Settings catalog 提供数千项设置，⁷ 但没有义务全用。
• 只决定一种标准 PC 映像。 只维护一种标准：「这家公司的 PC 就是这组策略加这组应用」。部门例外可以用群组与筛选表达，但例外愈多，一个人愈跟不上。
• 设计与做范本问外部伙伴；日常营运留在公司内。 容易失败的 Intune 迁移外包，是把建置丢过墙、最后变成「没人看得懂系统管理画面在说什么」。请外面做初始设计、策略模板化、迁移决策的咨询对象，目标是你自己日常能加一台 PC、能微调一条策略。反过来说，该选会交接到那一步的伙伴。
• 一次只改一件事。 策略变更一次一条，在 Intune 报表（策略套用状态与指派失败）确认结果后再往下。MDM 同步大约 8 小时一轮，³ 多数「还没套用」是时间问题，不是故障。

flowchart TB
    accTitle: 策略变更的营运循环
    accDescr: 策略变更一次一条，在 Intune 报表确认套用状态后才做下一条。多数还没套用的情况，等大约 8 小时的同步周期就会解决
    change["只改一条策略"] --> report["在报表确认套用状态"]
    report --> next["没问题就做下一条"]
    next --> change
    report -.-> wait["多数未套用是在等同步"]

图 20: 策略变更一次一条，在报表确认结果后再往下。

10. 总结

• GPO 是假设连得上域控制器的机制，结构上到不了场外 PC。Intune（MDM）经互联网同步，从根解消这个问题。
• 迁移不是全有或全无。Entra join 的机器与域加入的机器可以共存，把新 PC 切到 Entra join 加 Intune 的分阶段迁移，是中小企业的务实答案。既有机器没有转换路径，因此跟着硬件更新周期替换是既定模式。
• 中小企业用 Microsoft 365 Business Premium（Intune Plan 1 加 Entra ID P1）开始 Intune 是务实的。不过方案组成一直在变，Remediations 等部分功能需要更高许可，因此不要把这篇 2026 年 8 月的文章当福音，请确认一次信息。
• 现行 GPO 的盘点可用 Group Policy analytics 自动化。Ready for migration 的设置转到 Settings catalog，没有对应项的登录脚本与打印机部署，改用脚本部署、把工作做成应用，或停掉那个做法。注意日文 GPO 的支持百分比可能不准。
• 迁移依「试点 → 基准策略 → 应用部署 → 既有 PC 自然替换 → 缩小 AD 角色」五阶段推进，每个阶段的退出条件先决定。
• 双重套用冲突时默认 GPO 赢。MDMWinsOverGP 只是 Policy CSP 的机制，因此原则是「不要从两边部署同一条设置」。
• 换服务器的报价落地时，是考虑这次迁移最好的时机。在「再一轮 AD」之前，先想未来五年的 PC 会在哪里用。

相关文章

• 组策略(GPO)实务入门 ── 运作机制、生效确认与 Intune 的分工
• WSUS 弃用后的 Windows Update 管理 ── 该如何选择 WUfB、Autopatch、Intune
• Windows 10支持结束后的现实解方 ── ESU、LTSC、换机的判断表
• 用 winget + PowerShell 自动化 PC 配置 ── 让操作手册变得可执行
• BitLocker 实务指南 ── 从恢复密钥的管理开始建立驱动器加密
• Windows LAPS 实务指南 ── 停止在所有电脑共享同一组本地管理员密码

相关咨询领域

小村软件有限公司承接从 AD+GPO 环境分阶段转到 Entra ID+Intune 的设计（盘点现行 GPO、重现设置的方针、试点计划）、换服务器与转云端的比较审查，以及重用既有业务应用与预配资产的咨询。从一起考虑「该不该再买一台 AD 服务器」开始就可以。

• 技术咨询・设计评审
• 既有资产迁移
• 联系我们

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

从 GPO 转到 Intune，现在用的每一条组策略设置都能重现吗？

不能全部重现。Intune 的 Settings catalog 有数千项 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 连得上域控制器时才获取并套用。办公室外的 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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。