群組原則（GPO）實務入門 ── 運作機制、生效確認與 Intune 的分工

「改了 GPO 卻沒有生效」「執行了 gpupdate，設定還是沒變」「在開發機上能動的應用程式，只有在客戶端的電腦上不能動」。這類問題只要拆成哪一個 GPO 是套用對象、哪一項設定優先、以及何時被處理來看，就會比較容易查。

群組原則是在組織中發布並管理 Windows 設定的機制。只說一句「這是用 GPO 發布的」，並無法知道那台電腦或那位使用者實際上受到哪些設定影響。必須把發布端的組態，和接收端的結果對照起來看。

本文是寫給接手 AD 環境的中小企業資訊系統人員，以及要在已加入網域的電腦上導入業務應用程式的開發者的實務入門。內容整理套用順序、生效時機、以 gpresult 與事件記錄檔釐清原因、ADMX 與集中存放區，以及與 Intune 的分工。說明依據截至 2026 年 8 月的官方一手資料。

依你遇到的問題來讀

第一次讀的話，建議先在第 2 章掌握用語，在第 3〜4 章理解運作機制，再進入第 5 章的確認步驟。如果正在調查問題，就以第 5 章為起點，再依結果回頭看優先順序或生效時機的說明。

1. 先講結論

「哪一項設定勝出」與「什麼時候送達」是兩回事

群組原則會依照本機→站台→網域→OU（LSDOU）的順序處理，同一項設定發生衝突時由後處理者勝出。本機 GPO 是最弱的一層。不過，封鎖繼承與強制會改變這個預設的流程。¹

生效分成兩條路線：開機時與登入時的前景處理，以及預設約 90 分鐘加上 0〜30 分鐘隨機偏移量的背景更新。網域控制站的背景更新預設為 5 分鐘。gpupdate /force 是重新套用全部設定，並不是能把只在登入或重新開機時才處理的設定也當場生效的萬用指令。²³

在反覆修改之前，先確認接收端的結果

釐清原因的起點是 gpresult /h 的 RSoP 報告。要確認的是已套用的 GPO、被拒絕的 GPO 與其原因，以及每一項設定的「優先 GPO」。要深入追查處理失敗或延遲時，則使用 GroupPolicy 操作記錄檔。⁴⁵

系統管理範本的設定，原則上會寫入登錄檔的 Software\Policies 等位置，支援原則的應用程式會讓這些值優先於自己的設定。「未設定」則不會寫入任何值。不過也有設定會寫到專用機碼之外，因此值殘留時要連寫入位置一起確認。⁶

統一管理方式，也統一應用程式依賴的前提條件

在網域維運中，ADMX 的定義要集中放到 SYSVOL 的 PolicyDefinitions 集中存放區。這是讓 GPMC 參照共同範本定義的機制。⁷

GPO 與 Intune 要依裝置的身分識別基礎架構與所在位置分工。在混合式環境中要避免同一項設定重複組態，並按領域決定由誰管理。遷移前的分類可以使用 Group Policy analytics。⁸⁹

對開發者而言，GPO 同樣是環境規格的一部分。執行原則、防火牆的本機規則合併、Proxy 或磁碟機組態等會改變應用程式前提條件的設定，都是透過集中管理發布的。遇到「只有客戶端不能動」時，就用報告與實際的值確認這些前提。¹⁰¹¹

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

2. 什麼是群組原則 ── 本機 GPO 與網域 GPO

群組原則是一套機制：由管理員集中定義 Windows 的設定，再套用到目標的電腦與使用者。一整組設定稱為 GPO（群組原則物件）。

首先要區分「在那台電腦內部管理的本機 GPO」與「從 AD 發布的網域 GPO」。

設定放在哪裡：本機還是網域

工作群組（未加入網域）的電腦只會處理本機 GPO。¹ 也就是說，實務上講「受 GPO 管理」時，幾乎都是指網域 GPO。

flowchart TB
    accTitle: 工作群組電腦與已加入網域電腦各自處理的 GPO
    accDescr: 工作群組的電腦只會處理本機 GPO，已加入網域的電腦除了本機 GPO 之外，還會處理從 Active Directory 發布的網域 GPO
    pc{"電腦的加入形態是？"}
    pc -->|工作群組| wg["只處理本機 GPO"]
    pc -->|已加入網域| dom["本機＋網域 GPO"]
    dom -.-> note["實務上的 GPO 幾乎都是網域 GPO"]

圖1：工作群組電腦只處理本機 GPO，已加入網域的電腦還會處理網域 GPO。

設定的對象：電腦還是使用者

任何一個 GPO，其內容都大致分為兩大系統。

• 電腦的組態：對登入該電腦的任何人都生效的設定。在開機時套用。
• 使用者的組態：不論該使用者登入哪一台電腦都生效的設定。在登入時套用。

「這是綁在電腦上的設定，還是綁在人身上的設定」這條軸線，在後面的套用順序與生效確認中都會一再出現。有些項目在兩邊的組態中都有同名設定，因此找設定時請養成兩個系統都看過的習慣。

flowchart TB
    accTitle: GPO 內容的兩大系統
    accDescr: 任何 GPO 都有電腦的組態與使用者的組態兩大系統，電腦的組態在開機時套用並對登入該電腦的任何人生效，使用者的組態在登入時套用並且不論該使用者登入哪一台電腦都生效
    gpo["GPO 的內容"] --> comp["電腦的組態"]
    gpo --> user["使用者的組態"]
    comp --> boot["開機時套用"]
    user --> logon["登入時套用"]
    boot -.-> anyone["對登入的任何人都生效"]
    logon -.-> anypc["在任何電腦上都生效"]

圖2：GPO 分為綁在電腦上的電腦組態，以及綁在人身上的使用者組態兩大系統。

3. 套用機制 ── LSDOU 的「後處理者優先」與繼承控制

3.1. LSDOU：本機→站台→網域→OU

在已加入網域的電腦上，GPO 會依下列順序處理。¹

1. 本機 GPO
2. 連結至站台的 GPO
3. 連結至網域的 GPO
4. 連結至 OU（組織單位）的 GPO ── 從上層 OU 依序處理，最後處理目標電腦／使用者直接所屬的那個 OU 的 GPO

取各層字首的稱呼就是 LSDOU。它表示的不是「優先順序由高到低」，而是處理的先後順序。

當多個 GPO 組態了同一項設定，後處理的 GPO 會勝出。不衝突的設定則單純彙整在一起。¹

在這個預設順序下，離目標最近的 OU 的 GPO 最強，本機 GPO 最弱。「用 gpedit.msc 改好卻又變回原狀」正是規格如此的行為。改變繼承的例外會在 3.2 節確認。

flowchart TB
    accTitle: LSDOU 的處理順序與後處理者優先
    accDescr: GPO 依本機、站台、網域、OU 的順序處理，衝突時由後處理的 GPO 勝出，因此離目標較近的 OU 的 GPO 最強，本機 GPO 最弱
    l["1. 本機 GPO"] --> s["2. 站台"]
    s --> d["3. 網域"]
    d --> ou["4. OU（從上層依序）"]
    ou --> win["衝突時後處理者優先"]
    win -.-> strongest["離目標近的 OU 的 GPO 最強"]
    win -.-> weakest["本機 GPO 最弱"]

圖3：LSDOU 是被處理的順序，同一項設定發生衝突時由後處理的 GPO 勝出。

在同一個位置上，連結順序編號小的勝出

同一個站台、網域或 OU 連結了多個 GPO 時，要確認 GPMC「連結的群組原則物件」索引標籤中的連結順序。

編號最小的 GPO 最後處理，優先順序最高。重點是不要把它讀成「編號小所以先處理」。¹

flowchart TB
    accTitle: 同一位置有多個 GPO 時的連結順序
    accDescr: 同一個站台、網域或 OU 連結多個 GPO 時，處理順序由 GPMC 的連結順序決定，編號最小的 GPO 最後處理，優先順序最高
    multi["同一位置有多個 GPO"] --> tab["由 GPMC 的連結順序決定"]
    tab --> last["編號最小的 GPO 最後處理"]
    last --> win["以後處理者優先而勝出"]

圖4：在同一個連結位置上，連結順序編號最小的 GPO 最後處理而勝出。

3.2. 封鎖繼承與強制（Enforced）

封鎖繼承與強制，是對 3.1 節的預設順序製造例外的機制。閱讀時要把設定在哪裡與擋下什麼分開來看。¹

• 封鎖繼承：設定在網域或 OU 上，就能擋下來自上層的 GPO 繼承。這是用在「只有這個 OU 不想套用全公司標準」的情況。
• 強制（Enforced，舊稱：不可覆寫）：設定在 GPO 的連結上，即使下層封鎖了繼承，該 GPO 仍一定會套用，也不會被下層的 GPO 覆寫。封鎖繼承與強制衝突時，由強制勝出。¹

flowchart TB
    accTitle: 封鎖繼承與強制的關係
    accDescr: 封鎖繼承會擋下來自上層的 GPO 繼承，但已強制的 GPO 即使下層封鎖繼承仍一定會套用，也不會被下層的 GPO 覆寫
    upper["來自上層的 GPO"] --> blocked{"下層封鎖繼承？"}
    blocked -->|否| inherit["直接繼承"]
    blocked -->|是| enforced{"GPO 設定了強制？"}
    enforced -->|否| stop["繼承被擋下"]
    enforced -->|是| apply["一定會套用"]
    apply -.-> noover["不會被下層的 GPO 覆寫"]

圖5：封鎖繼承會擋下來自上層的繼承，但已強制的 GPO 會越過封鎖而一定套用。

強制要限定使用目的

強制會改變預設的「後處理者優先」，用得太多，讀 RSoP 時與直覺不符的結果就會變多。標準做法是限定用在全公司一定要遵守的安全性設定之類的地方。

以上是繼承與優先順序的部分。至於 GPO 能不能套用到目標身上，還要看接下來的安全性篩選。

3.3. 安全性篩選處理

套用需要同時具備「讀取」與「套用」

除了連結位置之外，要套用給誰也能以 GPO 為單位限縮。目標使用者或電腦必須同時擁有該 GPO 的「讀取」與「套用群組原則」兩項存取權限。¹³

預設會把這兩項權限都授予同時包含使用者與電腦的 Authenticated Users，因此連結位置底下的所有對象都會成為套用對象。把範圍縮到特定安全性群組的做法，就是安全性篩選處理。

篩選作用於整個 GPO。它不是能對 GPO 內各項設定分別指定不同對象的機制。¹³

使用者端的 GPO，也要保留電腦的讀取權限

限縮對象時，注意不要連 Authenticated Users 的「讀取」也一併移除。因為自 MS16-072（2016 年）之後，使用者端的原則是以電腦的安全性內容取得的。電腦若讀不到 GPO，就算目標使用者具備兩項權限也不會套用。¹⁴

需要的權限分成下列兩項來想。

• 對目標群組授予讀取＋套用群組原則。
• 對 Authenticated Users 或 Domain Computers 只保留讀取。不需要「套用」權限。¹⁴

flowchart TB
    accTitle: 安全性篩選的套用判定
    accDescr: GPO 要套用，目標使用者或電腦必須同時擁有讀取與套用群組原則兩項權限，使用者端的 GPO 還需要電腦帳戶能夠讀取
    target["GPO 連結位置底下的對象"] --> perm{"同時有讀取與套用權限？"}
    perm -->|否| deny["被篩選拒絕"]
    perm -->|是| usergpo{"是使用者端的 GPO？"}
    usergpo -->|否| apply["會套用"]
    usergpo -->|是| comp{"電腦可以讀取？"}
    comp -->|是| apply
    comp -->|否| deny2["不會套用（MS16-072）"]

圖6：套用需要同時具備「讀取」與「套用群組原則」，使用者端的 GPO 還需要電腦帳戶能讀取。

變更群組之後，要用新的權杖確認

「明明是電腦端的設定，卻只把使用者加進群組」這種弄錯對象的情況，是很常見的絆腳石。請先確認該設定是電腦端還是使用者端。

另一個問題是「已經從群組移除，卻還是持續套用」。成員資格是用登入時建立的安全性權杖評估的，光是等待背景更新並不會改變。

使用者的群組異動要登出再登入、電腦的異動要重新開機，取得新的權杖之後，才會反映到篩選上。

flowchart TB
    accTitle: 群組異動反映到篩選為止的過程
    accDescr: 群組成員資格是以登入時建立的安全性權杖評估，因此使用者的異動要重新登入、電腦的異動要重新開機，取得新的權杖之後才會反映到篩選上
    change["變更群組成員"] --> old["權杖仍是舊的就不會反映"]
    old --> u["使用者要重新登入"]
    old --> c["電腦要重新開機"]
    u --> token["以新的權杖評估"]
    c --> token
    token --> ok["反映到篩選"]
    old -.-> bg["背景更新無法解決"]

圖7：群組異動要等登出或重新開機產生新的權杖，才會反映到篩選上。

共用電腦的應用：回送處理

在共用電腦或遠端桌面伺服器上，有時會希望「對登入該電腦的所有人，替換其使用者的組態」。為此而設的特殊模式就是回送處理（Loopback）。

它依電腦所在位置套用使用者設定，具有取代與合併兩種模式。這是用在 Kiosk 裝置或教室電腦上的進階功能，本文僅介紹它的存在。¹⁵

flowchart TB
    accTitle: 回送處理的概念
    accDescr: 回送處理是依電腦所在位置套用使用者組態的特殊模式，具有取代與合併兩種模式，用在共用電腦或 Kiosk 裝置等希望對所有登入者套用相同使用者設定的場合
    shared["共用電腦、Kiosk 裝置等"] --> lb["回送處理"]
    lb --> base["由電腦所在位置決定"]
    base --> rep["取代模式"]
    base --> mrg["合併模式"]
    lb -.-> aim["對所有登入者都生效"]

圖8：回送處理是依電腦所在位置套用使用者組態的特殊模式，具有取代與合併兩種模式。

4. 什麼時候生效 ── 前景處理與背景更新

就算改了設定，也可能只是套用時機還沒到。這一章要把裝置能不能連到網域控制站，和該設定在哪個時機被處理分開來看。²

區分開機、登入時與運作期間的更新

前提是先能連到網域控制站

只要是能連到網域控制站且正在運作的裝置，支援背景更新的設定在預設情況下大約 2 小時內就會全面送達。離線的裝置，或未連 VPN 的外帶電腦，則要等到下次連上網域控制站才會收到。

只在前景處理才會套用的設定，還要再等開機或登入。

gpupdate 與 /force 的差別

趕時間的話，就在目標電腦上執行 gpupdate。它通常只套用有變更的設定，加上 /force 則不論有沒有變更都會重新套用全部設定。³

rem 只更新有變更的部分（通常這樣就夠了）
gpupdate

rem 重新套用全部設定（懷疑是快取狀態造成時）
gpupdate /force

flowchart TB
    accTitle: 能否連到網域控制站與設定的送達方式
    accDescr: 能連到網域控制站且正在運作的裝置，支援背景更新的設定約 2 小時內就會全面送達，但離線或未連 VPN 的外帶電腦要等到下次連上網域控制站才會收到
    pc{"能連到網域控制站？"}
    pc -->|是| ok["約 2 小時內全面送達"]
    pc -->|否| ng["連上之前不會送達"]
    ng -.-> ex["離線或未連 VPN 的外帶電腦"]

圖9：能連到網域控制站且正在運作的裝置約 2 小時內就會全面送達，離線的裝置則要等到下次連上才會收到。

就算加上 /force，也省不掉前景處理

使用者端的軟體安裝與資料夾重新導向只在登入時處理，電腦端的軟體安裝只在開機時處理。³

gpupdate 的 /logoff 是更新後登出、/boot 是更新後重新開機的選項。加了 /force 仍然沒有改變時，請確認該設定是不是屬於需要登入或重新開機的種類。³

flowchart TB
    accTitle: 設定生效的路徑
    accDescr: GPO 的變更若屬於支援背景更新的設定，會在預設約 90 分鐘加 0〜30 分鐘偏移量內送達，只在前景處理才套用的設定要等開機或登入，趕時間時執行的 gpupdate 對前景處理的設定也需要 /logoff 或 /boot
    change["變更 GPO"] --> kind{"支援背景更新？"}
    kind -->|是| bg["約 90 分鐘＋0〜30 分鐘後更新"]
    kind -->|否| fg["開機、登入時套用"]
    bg --> done["生效"]
    fg --> done
    rush["趕時間時"] -.-> upd["執行 gpupdate"]
    upd -.-> force["用 /force 全部重新套用"]
    upd -.-> reboot["前景要用 /logoff 或 /boot"]

圖10：背景更新只會送達支援的設定，只在前景處理才套用的設定在 gpupdate 之後仍需登出或重新開機。

5. 沒有生效時的原因釐清 ── gpresult、事件記錄檔、登錄檔

這幾樣確認工具的角色各不相同。gpresult 看的是套用的結果，操作記錄檔看的是處理的經過，登錄檔看的是實際寫入的值。不要一開始就動手重改設定，而要從結果縮小原因的範圍。

5.1. 用 gpresult /h 確認 RSoP

多個 GPO 疊加後的最終結果稱為 RSoP（原則結果集）。用內建工具 gpresult，從系統管理員權限的命令提示字元輸出成 HTML 報告會比較好讀。⁴⁵

下面的例子要先備妥輸出目的地 C:\temp 資料夾再執行。讀報告時，也請確認它就是你要查的那台電腦與那位使用者的結果。

rem 把使用者與電腦兩邊的 RSoP 都輸出成 HTML 報告
gpresult /h C:\temp\gp-report.html /f

rem 只在主控台確認概要時
gpresult /r
gpresult /scope computer /r

不要只確認到「已套用」就停下

報告要依序看下列 3 點。就算目標 GPO 出現在清單裡，只要目標設定被別的 GPO 覆寫，值就不會是你期待的。

1. 已套用的 GPO 清單 ── 目標 GPO 有沒有在裡面
2. 被拒絕的 GPO 清單與原因 ── 會顯示安全性篩選、WMI 篩選、空的 GPO 等未被套用的原因⁵
3. 每項設定的「優先 GPO」 ── 目標設定最後是由哪一個 GPO 的值決定的。如果是別的 GPO 勝出，就回頭檢視第 3 章的優先順序

flowchart TB
    accTitle: RSoP 報告最先要看的 3 點
    accDescr: gpresult 的報告先看已套用的 GPO 清單中有沒有目標 GPO，接著確認被拒絕的 GPO 清單與原因，最後用每項設定的優先 GPO 判斷是哪一個 GPO 的值勝出
    rep["開啟 RSoP 報告"] --> one["1. 已套用的 GPO 清單"]
    one --> two["2. 被拒絕的 GPO 與原因"]
    two --> three["3. 每項設定的優先 GPO"]
    three -.-> review["若是別的 GPO 勝出就重新檢視"]

圖11：RSoP 報告要依已套用的 GPO、被拒絕的 GPO 與原因、每項設定的優先 GPO 的順序來看。

5.2. GroupPolicy 操作記錄檔

追查處理的失敗與延遲

只看 gpresult 查不出來的失敗，或處理時間過長的問題，就用事件檢視器的 GroupPolicy 操作記錄檔確認。

位置在「應用程式及服務記錄檔 > Microsoft > Windows > GroupPolicy > Operational」。記錄檔名稱是 Microsoft-Windows-GroupPolicy/Operational，其中會記錄處理從開始到結束的過程、已套用與被拒絕的 GPO 清單，以及拒絕原因。⁵

用 ActivityID 篩出單次處理

每一次原則處理都會分配到一個唯一的 ActivityID。Microsoft 建議的步驟是：從系統記錄檔的警告與錯誤中取得 ActivityID，再用自訂檢視只篩出同一次處理的事件。這樣就不會混入其他次處理的記錄，可以完整追蹤一次處理從開始到結束的過程。⁵

flowchart TB
    accTitle: GroupPolicy 操作記錄檔的篩選步驟
    accDescr: GroupPolicy 操作記錄檔會為每一次原則處理分配唯一的 ActivityID，因此要從系統記錄檔的警告或錯誤取得 ActivityID，再用自訂檢視只篩出那一次處理的事件來讀
    sys["系統記錄檔的警告、錯誤"] --> aid["取得 ActivityID"]
    aid --> cv["用自訂檢視篩選"]
    cv --> one["讀取單次處理的事件"]
    one -.-> rec["已套用與被拒絕的 GPO 清單附有原因"]

圖12：操作記錄檔要先從系統記錄檔取得 ActivityID，再用自訂檢視只篩出一次原則處理來讀。

5.3. 與登錄檔 Policies 機碼的關係

系統管理範本（下一章）的原則，最終會以登錄檔的值寫入。寫入位置原則上是下列原則專用機碼。⁶

• HKEY_LOCAL_MACHINE\Software\Policies（電腦的組態。建議位置）
• HKEY_CURRENT_USER\Software\Policies（使用者的組態。建議位置）
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

原則值會比應用程式自己的設定先被參照

支援原則的應用程式，行為是先讀 Policies 機碼，有值就以它為優先，沒有值才使用自己的設定或預設值。「未設定」的原則不會在登錄檔中寫入任何值。⁶

也就是說，使用原則專用機碼的系統管理範本，並不是去改寫應用程式自己的設定、留下所謂的「刺青（tattooing）」，而是把強制值放在另一個位置。只要取消組態，應用程式就能回到依照自身設定運作的狀態。

flowchart TB
    accTitle: 原則值與應用程式設定的優先關係
    accDescr: 支援原則的應用程式會先讀 Policies 機碼，有值就以它為優先，沒有值才使用自己的設定或預設值，未設定的原則不會在登錄檔中寫入任何內容
    app["支援原則的應用程式讀取設定"] --> haspol{"Policies 機碼有值？"}
    haspol -->|是| pol["以原則值為優先"]
    haspol -->|否| pref["使用自己的設定或預設值"]
    notconf["未設定的原則"] -.-> nowrite["不在登錄檔中寫入任何內容"]

圖13：原則不是改寫應用程式自身的設定，而是讓放在另一個位置的強制值被優先參照的機制。

寫到專用機碼之外的設定，要注意值會殘留

並不是所有原則都寫在專用機碼裡。例如「啟用 Win32 長路徑」就是寫入 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 的 LongPathsEnabled。較舊世代的範本或第三方範本中，也有會寫到任意路徑的。

這類設定即使取消原則的組態，值仍會留下。請透過 ADMX 的定義、設定的說明文字，以及 gpresult 的報告，確認目標設定會寫進哪一個機碼。

以指令碼或群組原則基本設定（Preferences）寫到專用機碼之外的值，也是一般的登錄檔值。它與原則專用機碼不同，要當成取消組態後值仍會留下來看待。

確認實際的寫入位置

先看 Policies 機碼的實際值。不過，不要只因為那裡沒有就斷定「不受 GPO 影響」，也要確認它是不是會寫到專用機碼之外的設定。下面的指令是查看多數原則所使用的 Policies 底下的例子。

# 直接確認由原則發布的值的例子（多數原則會寫在 Policies 底下）
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: 沒有生效時的原因釐清步驟
    accDescr: 先用 gpresult 的 RSoP 報告確認已套用與被拒絕的 GPO，不足時再用 ActivityID 篩選 GroupPolicy 操作記錄檔，發布的實際值則直接到登錄檔的 Policies 機碼確認
    start["設定沒有生效"] --> rsop["用 gpresult /h 確認 RSoP"]
    rsop --> found{"查得出套用與拒絕的原因？"}
    found -->|是| fix["重新檢視優先順序或篩選"]
    found -->|否| oplog["查看 GroupPolicy 操作記錄檔"]
    oplog -.-> aid["用 ActivityID 篩出單次處理"]
    rsop -.-> reg["直接確認 Policies 機碼的實際值"]

圖14：原因釐清以 gpresult /h 為起點，不足時查 GroupPolicy 操作記錄檔，實際值則直接確認 Policies 機碼，有系統地推進。

6. 系統管理範本（ADMX）與集中存放區

ADMX 是設定的定義，ADML 是顯示字串

GPMC「系統管理範本」下排列的項目，是用 ADMX 檔案描述設定的定義，用 ADML 檔案描述各語言的顯示字串。

每台電腦的 C:\Windows\PolicyDefinitions 中都有作業系統隨附的定義，管理工具會讀取它來組出設定畫面。⁷

網域環境要參照共同的集中存放區

在網域維運中，要在網域控制站的 SYSVOL 底下建立 PolicyDefinitions 資料夾。例如 \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions。

其內容會複寫到網域內所有的網域控制站，群組原則工具也會變成預設參照集中存放區。這是為了避免各台管理電腦的範本版本不同、看到的項目互相對不上的問題。ADML 則放在 ja-JP 這類各語言的子資料夾中。⁷

flowchart TB
    accTitle: 集中存放區的運作機制
    accDescr: 在網域控制站的 SYSVOL 底下建立 PolicyDefinitions 資料夾後其內容會複寫到所有網域控制站，群組原則工具也會預設參照集中存放區，因此各台管理電腦之間的定義不再互相對不上
    create["在 SYSVOL 底下建立"] --> cs["PolicyDefinitions"]
    cs --> repl["複寫到所有網域控制站"]
    cs --> ref["GP 工具預設參照"]
    ref -.-> benefit["各台電腦的定義不再對不上"]
    cs -.-> adml["ADML 放到各語言資料夾"]

圖15：SYSVOL 的 PolicyDefinitions 會複寫到所有網域控制站，群組原則工具預設會參照它。

更新要先在工作資料夾備妥再切換

針對新版 Windows 的 ADMX，Microsoft 會依版本分別提供。要更新的是集中存放區這一側。以下載版取代各台電腦的 C:\Windows\PolicyDefinitions 這種做法並不受支援。⁷

更新既有存放區時，不要直接覆寫正式資料夾，而要依下列順序進行。

1. 準備一個以版本命名的工作資料夾，例如 PolicyDefinitions-24H2。
2. 備齊作業系統版，以及 Office、Edge 等應用程式版的完整 ADMX。
3. 把現行的 PolicyDefinitions 改名為 PolicyDefinitions-23H2 之類的名稱，先保留起來。
4. 把工作資料夾改名為 PolicyDefinitions，讓它成為正式參照的對象。⁷

被參照的是名為 PolicyDefinitions 的資料夾。只是放進以版本命名的資料夾並不會生效。先把舊資料夾保留下來，出問題時就能還原。⁷

flowchart TB
    accTitle: 集中存放區更新的步驟
    accDescr: 更新時要在以版本命名的工作資料夾中備齊作業系統版與應用程式版的完整 ADMX，把現行資料夾改名保留後再將工作資料夾改名為正式名稱 PolicyDefinitions，出問題時就還原到保留的舊資料夾
    work["以版本命名的工作資料夾"] --> gather["備齊作業系統版與應用程式版"]
    gather --> evac["把現行資料夾改名保留"]
    evac --> rename["把工作資料夾改成正式名稱"]
    rename --> live["成為正式參照的對象"]
    live -.-> back["出問題時還原到舊資料夾"]

圖16：更新要先在工作資料夾備齊整套檔案，把現行資料夾保留起來後再以改名方式切換為正式版。

7. GPO vs Intune（MDM/CSP）vs 手動、指令碼 ── 判斷表

現在管理 Windows 裝置組態的選項已經不只有 GPO。以 Intune 為代表的 MDM，是透過 CSP（設定服務提供者）這套機制來組態作業系統設定。下表用來判斷該以哪一種為主軸。

判斷的軸線是裝置的基礎架構與所在位置

基本上就是看裝置是以 AD 還是 Microsoft Entra 為基礎架構，以及在哪裡使用。對加入內部部署 AD 網域、固定放在公司裡的電腦，GPO 最可靠；對 Entra 加入的行動電腦，網域 GPO 送不到。

重點是不要把常駐公司內的裝置和外帶的裝置，當成送達條件相同。

混合式環境要逐項決定由誰管理

即使是中小企業，把加入網域與 Intune 註冊組合起來的混合式維運也很常見。這裡要避免的，是同一項設定同時用 GPO 和 MDM 組態。

Policy CSP 中有在衝突時讓 MDM 優先的 MDMWinsOverGP。不過，它的對象只有 Policy CSP 內支援的原則。對不在這個控制範圍內的設定重複組態，哪一方勝出並不受保證。Microsoft 也建議避免重複組態。⁸

原則是把管理主體定下來 ──「這個領域用 GPO，那個領域用 Intune」── 並統一交給其中一方。

flowchart TB
    accTitle: GPO 與 Intune 的分工
    accDescr: 裝置的身分識別基礎架構若是內部部署 AD 且常駐公司內就適合 GPO，若是 Entra 加入或在公司外就適合 Intune，混合式環境則要避免同一項設定重複組態並依設定領域把管理主體統一到其中一方
    q{"裝置的基礎架構與所在位置？"}
    q -->|加入 AD 且常駐公司內| gpo["GPO 可靠且粒度細"]
    q -->|Entra 加入或在公司外| intune["Intune 連公司外也送得到"]
    q -->|混合式| split["依領域統一到其中一方"]
    split -.-> warn["重複組態的結果不受保證"]
    split -.-> ana["用 Group Policy analytics 分類"]

圖17：分工要依裝置的身分識別基礎架構與所在位置決定，混合式環境不要把同一項設定同時用 GPO 與 MDM 組態。

Group Policy analytics 用在遷移前的分類

評估遷移的入口是 Intune 的 Group Policy analytics。把從 GPMC 以 XML 匯出的 GPO 匯入之後，就能逐項分析設定屬於 MDM 已支援、不建議使用，還是無法支援。已支援的設定可以遷移到 Intune 的設定目錄原則。⁹

它不是「把全部搬過去的工具」，而是用來分出哪些能搬、哪些不能搬、哪些該捨棄的工具。

Windows Update 的管理主體也在同樣的脈絡下重整中。請一併參考「WSUS 淘汰後的 Windows Update 管理」。

flowchart TB
    accTitle: 用 Group Policy analytics 進行分類
    accDescr: 把從 GPMC 以 XML 格式匯出的 GPO 匯入 Group Policy analytics 之後就能逐項分出設定是 MDM 已支援還是不建議使用或無法支援，已支援的設定可以遷移到設定目錄原則
    exp["從 GPMC 以 XML 匯出"] --> imp["匯入 analytics"]
    imp --> ana["逐項分析支援狀況"]
    ana --> ok["MDM 已支援"]
    ana --> dep["不建議使用、無法支援"]
    ok --> mig["遷移到設定目錄原則"]

圖18：Group Policy analytics 會匯入匯出的 GPO，分出哪些設定能搬到 MDM、哪些不能。

8. 開發者視角的陷阱 ── 客戶端的 GPO 會改變應用程式的行為

最後是站在承接委外開發的立場該掌握的內容。客戶端的 GPO 會悄悄改寫你的應用程式的前提條件。在「開發機上能動，客戶端卻不能動」的原因裡，GPO 和防火牆、防毒軟體一樣是常客。以下以實際案例列舉。

PowerShell 的執行原則

執行原則可以用 GPO 集中組態，源自 GPO 的 MachinePolicy／UserPolicy 範圍一律優先於在本機或處理程序層級設定的值。¹⁰ 如果安裝程式或維運指令碼是以「加上 -ExecutionPolicy Bypass 就應該能跑」為前提寫成的，在 GPO 管理之下連啟動都辦不到。細節請參考「PowerShell 的執行原則與指令碼簽署」。

停用防火牆的本機規則合併

在以 GPO 或 Intune 集中管理防火牆的環境中，可以按設定檔為單位停用「本機規則合併」（AllowLocalPolicyMerge）。在停用的環境裡，安裝程式在本機登錄的輸入規則即使存在也不會生效。¹¹ 這是導入伺服器型應用程式前一定要確認的重點，在「Windows 防火牆與業務應用程式」中有詳細說明。

磁碟機對應、Proxy 等環境組態

網路磁碟機對應與印表機等，慣例上都是用群組原則基本設定（Preferences）發布的。¹⁶「應該會有 Z 磁碟機」「Proxy 應該是直連」這類對環境的假設，會因為登入的使用者或電腦所屬的 OU 而不成立。以使用者的組態發布的設定，當然不會套用到服務或工作的執行帳戶上，這一點在常駐型應用程式中也很容易漏看。

根本上設定「改不回來」

源自系統管理範本的設定，通常會讓使用者無法從畫面上變更（項目會變成灰色無法點選）。「請客戶自己改一下設定就會好」這句話行不通，這一點會直接影響到處理方針的設計。

flowchart TB
    accTitle: 客戶端 GPO 改變的應用程式前提
    accDescr: 客戶端的 GPO 會以強制執行原則、停用防火牆的本機規則合併、發布磁碟機與 Proxy、使用者無法把設定改回來等形式改變應用程式的前提條件，成為只有客戶端不能動的原因之一
    gpo["客戶端的 GPO"] --> ep["強制執行原則"]
    gpo --> fw["停用本機規則合併"]
    gpo --> env["發布磁碟機、Proxy"]
    gpo --> lock["設定改不回來"]
    ep --> sym["成為只有客戶端不能動的原因之一"]
    fw --> sym
    env --> sym
    lock --> sym

圖19：客戶端的 GPO 會悄悄改寫執行原則、防火牆、環境組態等應用程式的前提條件。

開發端要先決定導入前與故障時的確認事項

該做的準備有下列 3 項。

權限的界線在「Windows 什麼時候需要系統管理員權限」中說明。GPO 不是敵人，而是環境的規格。把它當成規格看待，並備妥要與管理員確認的項目，就能有系統地推進原因釐清。

flowchart TB
    accTitle: 開發端的 3 項準備
    accDescr: 開發端的準備有三項，把應用程式依賴的環境前提寫成導入需求文件並在導入前請客戶端資訊系統人員確認，發生問題時用 gpresult 的報告與 Policies 機碼的實際值確認，以及在設計階段分開需要系統管理員權限的處理
    dev["開發端的準備"] --> doc["1. 把環境前提文件化"]
    dev --> chk["2. 用 gpresult 與實際值確認"]
    dev --> priv["3. 在設計上分離權限需求"]
    doc -.-> ask["導入前請客戶端資訊系統人員確認"]

圖20：開發端的準備是環境前提文件化、用 gpresult 與實際值確認，以及在設計上分離系統管理員權限需求這 3 項。

9. 總結

• 群組原則是把以 GPO 為單位的設定依本機→站台→網域→OU（LSDOU）的順序處理的機制，衝突時由後處理者勝出。離目標近的 OU 的 GPO 最強，本機 GPO 是最弱的一層。
• 可以用封鎖繼承、強制（Enforced）、安全性篩選處理控制預設的流程。強制連封鎖繼承都能勝過，因此切忌濫用。
• 套用分成開機時與登入時的前景處理，以及預設約 90 分鐘＋隨機偏移量的背景更新兩條路線。gpupdate /force 是重新套用全部設定，對只在登入或重新開機時才處理的設定沒有作用。
• 沒有生效時，就依 gpresult /h →GroupPolicy 操作記錄檔→登錄檔的 Policies 機碼的順序有系統地釐清原因。被拒絕的 GPO 會顯示原因。
• 系統管理範本的定義是 ADMX/ADML，在網域維運中要集中放在 SYSVOL 的集中存放區。更新時要替換的是集中存放區這一側，而不是取代本機的 PolicyDefinitions。
• 要用 GPO 還是 Intune，依裝置的身分識別基礎架構與所在位置決定；在混合式環境中要避免同一項設定重複組態，把管理主體統一交給其中一方。遷移前的分類可以使用 Group Policy analytics。
• 對開發者而言，客戶端的 GPO 是環境規格的一部分。只要把執行原則、防火牆、磁碟機或 Proxy 組態等前提條件文件化，並建立可以用 gpresult 確認的體制，「只有客戶端不能動」的多數情況就不足為懼。

相關文章

• Windows 防火牆與業務應用程式 ── 輸入規則要用安裝程式登錄
• WSUS 淘汰後的 Windows Update 管理 ── 該如何選擇 WUfB、Autopatch、Intune
• PowerShell 的執行原則與指令碼簽署 ── 從「用 Bypass 蓋住問題」的做法畢業的實務指南
• 用 winget + PowerShell 自動化 PC 配置 ── 讓操作手冊變成可執行
• 擺脫 IE 模式依賴系統的實務指南
• Windows 什麼時候需要系統管理員權限 - UAC、保護區域、設計上的分辨方式

相關諮詢領域

合同會社小村軟體提供以下技術諮詢服務：調查受 GPO 管理的客戶端環境中業務應用程式無法運作的原因、整理導入需求（執行原則、防火牆、網路前提條件），以及為接手 AD 環境的資訊系統人員進行原則盤點與 Intune 併用方針的技術諮詢。從「想請你一起看 gpresult 的報告」這種階段開始委託也沒問題。

• 技術諮詢、設計審查
• 故障調查、原因分析
• Windows 應用程式開發
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

執行了 gpupdate /force 但設定沒有生效，為什麼？

首先請確認該設定是不是「背景更新不會生效的類型」。使用者端的軟體安裝與資料夾重新導向只在登入時處理，電腦端的軟體安裝只在開機時處理，因此在 gpupdate 執行完成後，還需要登出（/logoff）或重新開機（/boot）。接著用 gpresult /h 輸出 RSoP 報告，確認該 GPO 是否列在「已套用的 GPO」中，或是否以附有原因的方式列在「被拒絕的 GPO」中。如果已經套用卻沒有出現預期的行為，請懷疑是否有另一個優先順序更高的 GPO 覆寫了同一項設定（後處理者優先）。報告中會顯示每項設定的「優先 GPO」，因此可以確定是哪一個 GPO 勝出。

gpresult 顯示「已由篩選拒絕」是什麼意思？

意思是該 GPO 雖然在連結位置上屬於套用對象，卻因篩選處理而被排除在套用範圍之外。最常見的原因是安全性篩選處理：要套用 GPO，使用者或電腦必須同時擁有該 GPO 的「讀取」與「套用群組原則」兩項存取權限。系統預設會將這兩項權限都授予「已驗證的使用者（Authenticated Users）」，但如果採用限縮至特定群組的做法，就可能因為忘記將群組或電腦帳戶加入而被拒絕。另外，對於使用者端的 GPO，光是讓目標使用者擁有這兩項權限還不夠。自 MS16-072 之後，使用者原則會以電腦的安全性內容來取得，因此必須讓「已驗證的使用者」或「網域電腦（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 報告。要檢查的是有沒有套用會改變應用程式行為的設定，例如執行原則導致指令碼被阻擋、防火牆的本機規則合併被停用、Proxy 或磁碟機對應等組態。同時也建議確認登錄檔的 HKLM\Software\Policies 與 HKCU\Software\Policies 底下是否寫入了相關產品的原則值，這樣就能有系統地列出所有源自系統管理範本的強制設定。開發端可以事先準備的做法，是在導入手冊中明確寫出應用程式所依賴的前提條件（執行原則、輸入連接埠、寫入目的資料夾等），並在導入前請客戶端的資訊系統人員確認。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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