從群組原則到 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。