從群組原則到 Intune ── 中小企業的裝置管理移轉指南

「AD 伺服器的維護期限到了。要不要就這樣汰換下去，讓群組原則再跑五年？」「遠端工作的電腦，只有連上 VPN 的時候設定才送得到。」在中小企業，這類諮詢正在增加。

本文的主軸不是要不要重新買一台 AD 伺服器，而是往後五年，公司外的電腦要用什麼來管。移轉並不是「全有或全無」。有一種推進方式是一邊保留 AD，一邊從新電腦開始切換到 Entra join＋Intune。¹

首先，請依照您現在想判斷的事，挑選要閱讀的段落。

本文的前提

對象是中小企業的資訊人員與經營者。本文以 2026 年 8 月當下 Microsoft Learn 等一手資訊為依據，整理 GPO 與 MDM 的差異、需要的組態與授權、盤點、分階段移轉，以及容易踩的坑。方案組成尤其會變動，簽約前請以官方資訊確認最新內容。

地端的 Active Directory（AD）與群組原則（GPO），是以「電腦位在公司區域網路，隨時連得到網域控制站」為前提所設計的機制。隨著攜出電腦與遠端工作成為常態，這個前提已經崩解。長年是更新管理標準做法的 WSUS 也在 2024 年 9 月列為淘汰，Microsoft 裝置管理的重心已經移向 Entra ID＋Intune（MDM）。²

flowchart TB
    accTitle: 前提的崩解與管理重心的移動
    accDescr: AD 與 GPO 是以電腦位在公司區域網路、隨時連得到網域控制站為前提的機制，但攜出電腦與遠端工作成為常態後這個前提崩解，加上 WSUS 列為淘汰，管理的重心已移向 Entra ID 與 Intune
    adgpo["地端的 AD 與 GPO"] -.-> premise["前提是隨時連得到 DC"]
    work["攜出電腦與遠端工作成為常態"] --> broken["崩解的是前提本身"]
    premise --> broken
    wsus["WSUS 列為淘汰"] --> shift["重心移向 Entra ID+Intune"]
    broken --> shift

圖 1: AD+GPO 的「電腦位在公司區域網路」這個前提隨工作方式改變而崩解，管理的重心已移向 Entra ID+Intune。

1. 先講結論

移轉方針從以下三點組起來。

1. 改變把管理送到公司外電腦的方式。GPO 需要連上網域控制站，Intune 則是經網際網路同步。不過穩定狀態下的同步大約每 8 小時一次，並不是保證立即生效的機制。原則變更時也會有通知觸發的同步。³
2. 從新電腦開始切換，與既有環境共存。新購與汰換的機器採 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 伺服器」換成「往後五年，公司外的電腦要用什麼來管」，該比較的東西就會浮現出來。

flowchart LR
    accTitle: 該判斷的問題要換個問法
    accDescr: 要不要再汰換一輪 AD 伺服器這個問題，要換成往後五年公司外的電腦要用什麼來管，再據此判斷
    q1["再汰換一輪 AD 伺服器？"] -->|換個問法| q2["往後五年 公司外電腦用什麼管？"]

圖 2: 伺服器汰換的問題，要換成「往後五年，公司外的電腦要用什麼來管」再判斷。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 20 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. GPO 與 MDM 差在哪裡 ── 比較套用機制

不同的不只是設定內容，還有送達方式

先用同一組觀點比較 GPO 與 Intune。GPO 的 LSDOU 套用順序，以及用 gpupdate / gpresult 確認的方法，已在「群組原則(GPO)實務入門」處理過，這裡只聚焦在影響移轉判斷的差異。

移轉判斷上最重要的，是取得來源與送達公司外電腦的方式。GPO 送不到遠端工作的電腦，是因為「電腦位在連得到網域控制站的地方」這個設計前提，已經和現在的工作方式對不上了。

也有一條路是要求全體員工常時連著 VPN，讓 GPO 延續使用。不過那等於選擇再扛下 VPN 基礎設施這另一套基礎建設的維護工作。

flowchart TB
    accTitle: 要讓 GPO 延續使用還是移轉到 MDM
    accDescr: GPO 送不到遠端工作的電腦是因為設計前提已經和現代的工作方式對不上，而要求常時連線 VPN 讓 GPO 延續使用這條路，等於選擇扛下 VPN 基礎設施這另一套基礎建設的維護工作
    gap["設計前提與工作方式對不上"] --> sel{"要怎麼因應？"}
    sel -->|以常時連線 VPN 延續使用| vpn["繼續用 GPO"]
    sel -->|移轉到 MDM| mdm["經網際網路管理"]
    vpn --> cost["扛下另一套基礎建設的維護"]

圖 3: 用常時連線 VPN 讓 GPO 延續使用這條路，同時也是選擇扛下 VPN 基礎設施這另一套基礎建設的維護工作。

「送得到公司外」和「馬上生效」是兩回事

用 Intune 就能不限地點，把管理送到連得上網際網路的電腦。另一方面，穩定狀態下的同步約每 8 小時一次，比 GPO 約 90 分鐘的定期更新來得粗。重要的是不要帶著「發下去就馬上生效」的感覺去移轉。

指派或變更原則時會發送通知給電腦，同步會比較快完成。也可以從管理中心或電腦手動同步，但像緊急封鎖這類需要即時性的管控，必須以同步間隔為前提來設計。³

flowchart TB
    accTitle: GPO 與 MDM 的原則套用路徑
    accDescr: GPO 只有在能連上公司內的網域控制站時才套用，因此遠端工作的電腦只能靠 VPN，而 Intune 經網際網路約每 8 小時同步一次、原則變更時也會以通知同步，所以不限地點都送得到
    officepc["公司內的電腦"] -->|開機與登入時和定期更新| dc["網域控制站"]
    homepc["遠端工作的電腦"] --> vpn{"能經 VPN 連到 DC？"}
    vpn -->|是| dc
    vpn -->|否| miss["收不到最新原則"]
    anypc["在任何地點的電腦"] -->|約每 8 小時同步| intune["Intune 服務"]
    intune -.-> notify["原則變更時以通知同步"]

圖 4: GPO 只有在連得到網域控制站時才套用，Intune 則經網際網路不限地點同步。

3. 整理前提 ── 加入網域、hybrid join、Entra join 三種形態

電腦的加入形態一變，能用的管理手段也跟著變

Windows 電腦「加入公司的方式」有以下三種形態。¹

hybrid join 是把既有的加入網域電腦同時註冊到 Entra ID 的形態。可以一邊沿用既有資產，一邊開始使用 Intune 或條件式存取。不過 Microsoft 建議不要把 hybrid join 當成最終目標，新購與汰換的電腦應該採用 Entra join。¹

既有電腦需要清除重灌，所以要趁汰換時切換

要把加入網域的電腦（含 hybrid join）轉換成 Entra join，並不存在受 Microsoft 支援的手段。必須重設（清除）Windows。因此建議配合硬體更新或作業系統更換的時機，再移到 Entra join。¹

flowchart TB
    accTitle: 三種加入形態與移轉的路徑
    accDescr: 只加入 AD 網域的電腦可以再註冊到 Entra ID 變成 hybrid join，但沒有直接轉換成 Entra join 的手段、必須清除重灌，因此建議把新購與汰換的電腦做成 Entra join
    adonly["只加入 AD 網域（GPO）"] -->|同時註冊到 Entra ID| hybrid["hybrid join（GPO 與 Intune）"]
    hybrid -.->|沒有直接轉換的手段| wipe["需要清除（重設）"]
    wipe --> entra["Entra join（Intune）"]
    newpc["新購與汰換的電腦"] -->|建議| entra

圖 5: 要把既有的加入網域機器轉換成 Entra join 並沒有正式手段，從新購與汰換的電腦開始切換才是標準做法。

中小企業的移轉方針，把電腦與 AD 分開來看會比較好整理。

Entra join 的機器與加入網域的機器，可以在同一個公司環境中共存。為了開始新的管理方式，並不需要一次停用既有電腦或 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 則為殘留的職責暫時保留。

對地端資產的 SSO，另外還有兩個前提

從 Entra join 的機器存取地端的檔案伺服器等也是可行的。不過，光憑 Entra join 這一點，還湊不齊對地端資產做單一登入（SSO）的前提。請確認以下兩點。¹⁸

在移轉計畫中，要先找出有沒有無法滿足這兩點的使用者或使用情境。也就是說，要把「以 Intune 管理公司外的電腦」和「連到公司內的資產」分開確認。

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 月）

確認用 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 五年份的差額並排。在此之上，再把「管理送不送得到公司外的電腦」這個能力差納入考量。這就是成本比較的主軸。

flowchart TB
    accTitle: 成本比較的正確思考方式
    accDescr: GPO 這一邊也要花 AD 伺服器汰換與授權、五年份的維護等成本，因此要把伺服器汰換的報價與 Business Premium 五年份的差額並排，再把管理能否送到公司外電腦這個能力差納入考量後判斷
    gpocost["繼續用 GPO 的成本"] --> hw["伺服器汰換、授權、CAL"]
    gpocost --> ops["建置、維護、備份"]
    bpcost["移轉到 Intune 的成本"] --> sub["Business Premium 五年份"]
    hw --> diff["並排五年份的差額"]
    ops --> diff
    sub --> diff
    diff --> ability["納入管理能否送到公司外電腦"]

圖 9: 把伺服器汰換的報價與 Business Premium 五年份並排，再把管理送達公司外電腦這個能力差納入考量後判斷。

5. 以前用 GPO 做的事，在 Intune 要怎麼做

主要工作在 Intune 都有對應的做法

在把 GPO 的名稱與設定原樣搬進來之前，先把它實現的工作與搬遷的去處對應起來。

設定目錄是系統管理範本的搬遷去處

設定目錄相當於「GPO 編輯器的雲端版」畫面。Microsoft 也把它定位成：想像地端 GPO 那樣做細部設定時，自然的移轉去處。

其中也包含 ADMX 所定義設定的 MDM 版本，也就是 ADMX-backed 原則，另外還有匯入第三方 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: 從試行到基本原則、應用程式派送、既有電腦跟著汰換週期替換，再到縮小 AD 的職責，分階段推進，最終讓由 GPO 派送的設定歸零
    s1["① 試行"] --> s2["② 基本原則"]
    s2 --> s3["③ 應用程式派送"]
    s3 --> s4["④ 既有電腦自然替換"]
    s4 --> s5["⑤ 縮小 AD 的職責"]
    s5 -.-> goal["由 GPO 派送的設定為零"]

圖 14: 移轉從試行到縮小 AD 的職責共五個階段，各階段的完成條件要先訂好。

① 試行：從反正都要買的電腦開始

從下一批新進員工用的電腦、故障換機等新採購的電腦開始。好處是不必額外買電腦就能試，失敗了也能清除重來。

台數變多之後，再評估 Windows Autopilot：它能把從 OOBE（初次設定）到 Entra join＋Intune 註冊整段自動化。一開始並不是必要的。¹

② 基本原則：一開始只收斂到五項

不要想著重現 GPO 的所有設定，先從更新、加密、Defender、螢幕鎖定、LAPS 這五項開始。請用合規原則把合規狀態視覺化。

要啟用條件式存取的「僅限合規裝置存取」，是在試行階段確認沒有誤判之後。¹¹

③ 應用程式派送：減少配置的人工作業

應用程式派送會接到配置的自動化。如果已經整理好以 winget 為基礎的流程，那份資產幾乎可以原樣沿用，當作 Store 應用程式（新版）或 Win32 應用程式的包裝。¹⁵

從操作手冊推進自動化的方法，請參考「用 winget + PowerShell 自動化 PC 配置」。

④ 既有電腦：配合汰換週期

如第 3 章所述，既有的加入網域電腦沒有不清除就轉成 Entra join 的正式途徑。原則上跟著汰換週期替換，只有要提前處理的電腦才清除後切換。

還留著從 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 贏

移轉期間會出現對 hybrid join 的機器同時從 GPO 與 Intune 派送設定的場面。此時若同一項設定發生衝突，預設由 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 裡留著幾條設定、就這樣並行好幾年的公司並不罕見。即使如此，「新電腦全部以雲端管理，在公司外也管得住」這個狀態仍然很有價值。與其執著於完全移轉的形式，不如優先選擇可以退回去的小步前進。

flowchart TB
    accTitle: 不執著於完全移轉、讓兩者並行的價值
    accDescr: AD 還留著並不代表移轉失敗，就算 GPO 裡留著設定並行好幾年，新電腦全部以雲端管理、在公司外也管得住的狀態仍然很有價值
    miscon["AD 還留著就算移轉失敗？"] -->|並非如此| run["GPO 留著並行好幾年"]
    run --> value["新電腦在公司外也管得住"]
    value -.-> forward["優先選擇小步前進"]

圖 19: 就算 AD 留著並行，新電腦全部改為雲端管理的狀態仍然很有價值。

9. 一人資訊部門的現實解方

在只有一位負責人、或由人兼任的公司，要先決定導入後維持得住的範圍。

收斂管理項目與標準電腦樣貌

最初的管理項目收斂到第 7 章②的五項（更新、加密、Defender、螢幕鎖定、LAPS）。想法是只加上真的有需要的設定。設定目錄裡就算有數千項設定，也沒有義務全部都用。¹⁰

標準電腦樣貌也決定成一套：「這家公司的電腦就是這組原則加這組應用程式」。各部門的例外可以用群組或篩選器表達，但例外越多，一個人就越難維持下去。

設計委外，日常維運要能自己轉

對外部夥伴要求的是初期設計、原則範本的製作，以及移轉判斷的諮詢。至於每天新增電腦、微調原則，請把「自己做得到」設為目標狀態。

重要的是不要把建置整包丟出去，落到「沒有人看得懂管理畫面」的狀態。要選會把日常維運也交接給你的夥伴。

變更一次一件，用報表確認後再做下一件

原則變更一次只做一件，在 Intune 的報表確認套用狀態與指派是否失敗之後，再進行下一件。

MDM 的穩定同步週期約 8 小時。「沒生效」的情況大多不是故障而是時間問題，所以要把同步間隔納入考量再確認結果。³

flowchart TB
    accTitle: 原則變更的維運循環
    accDescr: 原則變更一次只做一件，在 Intune 的報表確認套用狀態之後再進行下一件變更。沒生效的情況大多等約 8 小時一次的同步就會解決
    change["一次只做一件原則變更"] --> report["用報表確認套用狀態"]
    report --> next["沒問題就進行下一件變更"]
    next --> change
    report -.-> wait["未生效的情況大多是在等同步"]

圖 20: 原則變更一次一件，用報表確認結果後再進行下一件。

10. 總結

從 GPO 移轉到 Intune，是改變把管理送到公司外電腦的方式，並逐步減少不需要的設定的一項工程。GPO 以連得到網域控制站為前提，Intune 則是經網際網路同步。不過維運時必須把約 8 小時的穩定同步間隔，以及變更時的通知納入考量。

推進方式的基本盤，是把新電腦切換到 Entra join＋Intune，既有電腦則跟著汰換週期替換的分階段移轉。確認對地端資產做 SSO 的前提，若 AD 還留著驗證等職責就繼續共存。

現行 GPO 用 Group Policy analytics 盤點，分類成「丟掉、搬走、找替代」。日文 GPO 的支援率只當參考值，請以設定為單位判斷。在此之上，依試行→基本原則→應用程式派送→既有電腦替換→縮小 AD 的職責這五個階段，附上完成條件往前推進。

移轉期間的原則是同一項設定不要從 GPO 與 MDM 兩邊派送。MDMWinsOverGP 能讓 MDM 優先的範圍僅限 Policy CSP 底下，因此要做成不依賴優先順序控制的架構。

授權可以把 Business Premium 當成起點，但 Remediations 等功能的適用範圍與最新的合約內容要以官方資訊確認。成本要比較伺服器汰換與五年份的差額，並把管理送達公司外電腦這個能力差也納入判斷。

伺服器汰換的報價出來時，就是評估這次移轉的好時機。請從在「AD 再跑一輪」之前，先想想接下來五年電腦會在哪裡被使用開始。

相關文章

• 群組原則(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 管理的電腦，和以加入 AD 網域＋GPO 管理的電腦，可以在同一個公司網路中共存。為了檔案伺服器的驗證與既有業務系統而保留 AD，只把新電腦改成 Entra join 的分階段移轉，才是務實的做法。反過來說，要把既有的加入網域電腦「轉換」成 Entra join 並沒有正式手段，必須清除（重灌），因此標準做法是讓既有機器跟著汰換週期替換。停用 AD 等到 GPO 清空、殘留的職責也盤點出來之後再評估就夠了。

為什麼群組原則套用不到遠端工作的電腦？

因為 GPO 的機制是在能連到網域控制站時才取得並套用。公司外的電腦只有在能透過 VPN 等方式連到網域控制站時才收得到最新原則，對不使用 VPN 的居家電腦來說實質上送不到。Intune（MDM）是經網際網路同步原則，所以電腦不論在哪裡都管得到，公司外電腦的管理難題就從 MDM 的結構上化解了。除了大約每 8 小時的定期同步，原則變更時也會執行通知觸發的同步。

同一項設定從 GPO 和 Intune 兩邊派送的話，哪一邊優先？

預設情況下，衝突的設定由群組原則優先。把 MDMWinsOverGP 原則設成 1 就會改由 MDM（Intune）優先，但這個機制只對 Policy CSP 底下的設定有效，不適用於 Defender CSP 等其他 CSP 所定義的設定。依賴優先順序控制會讓行為難以預測，因此實務上是以「同一項設定不要從兩個通道派送」為原則，搬到 Intune 的設定就從原本的 GPO 刪除，避免雙重管理，這樣比較安全。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。