執行了 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 底下是否寫入了相關產品的原則值,這樣就能有系統地列出所有源自系統管理範本的強制設定。開發端可以事先準備的做法,是在導入手冊中明確寫出應用程式所依賴的前提條件(執行原則、接收連接埠、寫入目的資料夾等),並在導入前請客戶端的資訊系統人員確認。

什麼是群組原則生效確認與 Intune 比較

「這項設定已經用 GPO 發布了」「客戶端的電腦被群組原則綁住了」── 只要接觸 Windows 的業務系統,「GPO」這個詞就會在日常對話中頻繁出現。然而,一旦輪到自己接手 AD 環境的資訊系統業務,或是要在客戶端已加入網域的電腦上導入應用程式,群組原則在何時、從哪裡、以什麼優先順序套用,能正確說明清楚的人其實意外地少。

「改了設定卻沒有生效」「被要求執行 gpupdate,但不知道到底發生了什麼事」「在開發機上能動的應用程式,只有客戶端不能動,查了之後發現是 GPO」── 本文以面對這類情境的業務應用程式開發者,以及接手 AD 環境的中小企業資訊系統人員為對象,依據截至 2026 年 8 月的官方一手資料,整理群組原則的運作機制(LSDOU 的套用順序)、生效時機、以 gpresult 與事件記錄檔進行的問題排查、ADMX 與集中存放區,以及與 Intune(MDM)的分工。

1. 先講結論

群組原則是「後處理者優先」。依照本機→站台→網域→OU(LSDOU)的順序處理,發生衝突時以後處理的 GPO 優先。本機 GPO(gpedit.msc)是最弱的一層。¹
生效時機是「前景+背景」。電腦的組態一定在開機時套用,使用者的組態一定在登入時套用,此外預設每隔約 90 分鐘+0〜30 分鐘的隨機偏移量會進行背景更新(網域控制站則是每 5 分鐘)。²
gpupdate /force 是「重新套用全部設定」,並非萬能。像軟體安裝或資料夾重新導向這類設定,只會在登入或重新開機時處理(這正是 /logoff、/boot 選項存在的理由)。³
問題排查的起點是 gpresult /h 的 RSoP 報告。可以看到已套用的 GPO,以及被拒絕的 GPO(附原因)。若要深入追查,則要看 GroupPolicy 操作記錄(Microsoft-Windows-GroupPolicy/Operational)。⁴⁵
系統管理範本的原則,原則上會寫入登錄的原則專用機碼(Software\Policies 等)。原則值的優先順序高於應用程式自身的設定,「未設定」則不會寫入任何內容。不過也有部分原則會寫到專用機碼以外的位置(第 5 章)。⁶
ADMX 的集中存放區是 SYSVOL 底下的 PolicyDefinitions 資料夾。建立之後,GPMC 就會參照網域共通的範本定義。⁷
要用 GPO 還是 Intune,取決於裝置的身分識別基礎架構。同一項設定若同時用兩者組態,結果不受保證。評估遷移時可以使用 Group Policy analytics。⁸⁹
對開發者而言,GPO 是「只有客戶端不能動」的常見原因之一。執行原則、防火牆的本機規則合併停用、Proxy、磁碟機對應等會改變應用程式前提條件的設定,常透過集中管理發布。¹⁰¹¹

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

群組原則是一套機制,讓管理員能夠集中定義 Windows 的設定,並強制套用到目標的電腦與使用者。一組設定的集合稱為GPO(群組原則物件)。GPO 有兩個存放位置。

	本機 GPO	網域 GPO
編輯工具	gpedit.msc(本機群組原則編輯器)	GPMC(群組原則管理主控台)+群組原則管理編輯器
儲存位置	該電腦本身。電腦端只有一份,但使用者端可以建立「系統管理員/非系統管理員/特定使用者」分別對應的多個本機 GPO(MLGPO)¹²	Active Directory(連結至站台、網域、OU 來發布)
套用範圍	僅該電腦	連結目標之下的所有電腦/使用者
優先順序	最弱(會被網域 GPO 覆寫)¹	強於本機。網域 GPO 之間由連結目標與連結順序決定
典型用途	工作群組電腦、驗證機的單機設定	發布、強制執行組織的標準設定

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

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

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

「這是綁在電腦上的設定,還是綁在人身上的設定」這條軸線,在接下來的套用順序與生效確認中都會一貫地出現。有些項目在兩個系統中都存在同名的設定,因此在尋找設定時,務必養成兩個系統都要查看的習慣。

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

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

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

本機 GPO
連結到站台的 GPO
連結到網域的 GPO
連結到OU(組織單位)的 GPO ── 由上層 OU 依序處理,最後才處理目標電腦/使用者直接所屬 OU 的 GPO

取首字母而稱為LSDOU的順序。重點在於,這並非「優先順序由高到低」,而是處理的順序。如果多個 GPO 組態了同一項設定,後處理的 GPO 會勝出(不衝突的設定則會單純相加)。¹ 換句話說,離目標最近的 OU 之 GPO 最強,本機 GPO 最弱。「在 gpedit.msc 裡改好了卻又被還原」並非故障,而是這套規格的正常行為。

如果同一個站台、網域或 OU 連結了多個 GPO,則由 GPMC 的「連結的群組原則物件」索引標籤中的連結順序決定。連結順序編號最小的 GPO 會最後處理,優先順序也最高。¹

3.2. 封鎖繼承與強制(Enforced)

預設的順序可以設定例外。¹

封鎖繼承:在網域或 OU 上設定,可以停止繼承來自上層的 GPO。用於「只有這個 OU 不想套用全公司標準」的情境。
強制(Enforced,舊稱「不覆寫」):設定在 GPO 的連結上,該 GPO 即使在下層被封鎖繼承,也一定會套用,不會被下層的 GPO 覆寫。當封鎖繼承與強制相互衝突時,強制勝出。¹

強制會破壞「後處理者優先」的原則,如果大量使用,依 RSoP 判讀時就容易出現不符直覺的結果。慣例做法是只把強制限定用於全公司都必須遵守的安全性設定。

3.3. 安全性篩選

除了連結位置之外,要套用給誰也可以按 GPO 個別限縮。要套用 GPO,目標的使用者或電腦必須同時擁有該 GPO 的「讀取」與「套用群組原則」兩項存取權限。系統預設會將這兩項權限都授予「已驗證的使用者(Authenticated Users,同時包含使用者與電腦)」,因此連結目標之下的所有對象都會套用。若要限縮到特定安全性群組,就要用到安全性篩選。篩選作用於整個 GPO,無法針對 GPO 內的個別設定分別調整。¹³

有一點很重要:在限縮套用對象時,不可以連「讀取」都從預設的「已驗證的使用者」移除。自安全性更新程式 MS16-072(2016 年)之後,使用者端原則會以電腦的安全性內容取得,因此如果電腦帳戶無法讀取該 GPO,即使目標使用者擁有兩項權限,使用者端 GPO 也不會生效。¹⁴ 正確的限縮方式是:先讓目標群組擁有「讀取+套用群組原則」,同時讓「已驗證的使用者」(或「網域電腦」)只保留「讀取」。¹⁴

實務上常見的困擾是「明明加進群組了卻沒有套用(明明是電腦端設定,卻只把使用者加進群組)」「明明已經從群組移除了,設定卻還一直套用」。後者即使等待背景更新也不會解決。群組成員資格是以登入時建立的安全性權杖來評估,因此使用者的群組變更要等到登出→登入、電腦的群組變更要等到重新開機,產生新的權杖之後,才會反映到篩選結果上。

另外,像共用電腦或遠端桌面伺服器這種「希望對登入該電腦的所有人,替換其使用者組態」的情境,還有一種特殊模式叫迴圈處理(依電腦所在位置套用使用者設定的機制,有取代與合併兩種模式)。¹⁵ 這是用於資訊站、教室電腦等的應用功能,本文僅止於介紹其存在。

4. 何時生效 ── 前景處理與背景更新

「設定了卻沒生效」有一半的情況,其實只是尚未到套用時機而已。套用分為兩種。²

種類	時機	對象
前景處理	電腦的組態:開機時/使用者的組態:登入時	所有設定
背景更新	預設每隔約 90 分鐘+0〜30 分鐘的隨機偏移量(避免所有裝置同時來取,刻意錯開)	僅支援背景處理的設定
背景更新(網域控制站)	預設每隔5 分鐘	同上

也就是說,只要是可以連線到網域控制站的運作中裝置,即使變更 GPO 之後什麼都不做,支援背景更新的設定也會在約兩小時內生效。離線裝置或未連上 VPN 的攜出電腦,則要等到下次連上網域控制站才會生效。只能靠前景處理套用的設定,還要再等開機或登入。如果需要加快,可以在目標電腦上執行 gpupdate。預設只會套用有變更的設定,加上 /force 則不論是否有變更,都會重新套用全部設定。³

rem 只更新有變更的部分(通常這樣就足夠)
gpupdate

rem 重新套用全部設定(懷疑是快取狀態的問題時)
gpupdate /force

要注意的是,有些設定就算用 gpupdate 也不會生效。使用者端的軟體安裝與資料夾重新導向只在登入時處理,電腦端的軟體安裝只在開機時處理。為此 gpupdate 提供了 /logoff(更新後登出)與 /boot(更新後重新開機)兩個選項。³ 在抱怨「執行了 gpupdate /force 卻沒套用」之前,請先確認該設定是不是需要重新開機或登入才能處理的類型。

5. 沒有生效時如何排查 ── gpresult、事件記錄檔、登錄

5.1. 用 gpresult /h 確認 RSoP

要確認多個 GPO 疊加後的最終結果(RSoP:原則結果集),標準工具是 gpresult。以系統管理員權限開啟命令提示字元,輸出 HTML 報告是最容易閱讀的方式。⁴⁵

rem 將使用者+電腦兩者的 RSoP 一起輸出為 HTML 報告
gpresult /h C:\temp\gp-report.html /f

rem 只想在主控台看概要時
gpresult /r
gpresult /scope computer /r

在報告中,最先該看的是以下三點。

已套用的 GPO 清單 ── 目標 GPO 有沒有在其中
被拒絕的 GPO 清單與原因 ── 安全性篩選、WMI 篩選、空白 GPO 等未套用的原因會顯示出來⁵
各設定的「優先 GPO」 ── 目標設定是由哪一個 GPO 的值決定的。如果是另一個 GPO 勝出,就要回頭檢視第 3 章的優先順序

5.2. GroupPolicy 操作記錄

當 gpresult 不夠用時(例如處理本身就失敗、耗時過久等),要看事件檢視器的GroupPolicy 操作記錄。位置在「應用程式與服務記錄 > Microsoft > Windows > GroupPolicy > Operational」(記錄名稱 Microsoft-Windows-GroupPolicy/Operational)。這裡會記錄原則處理從開始到結束的整個過程,連同已套用的 GPO 清單、被拒絕的 GPO 清單(附原因)一起記錄下來。每一次原則處理都會分配到唯一的ActivityID,因此 Microsoft 建議的做法是:先從系統記錄檔的警告、錯誤事件取得 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)」式的痕跡,而是一套在別的位置放置強制值、優先被參照的機制。只要停止組態該原則,應用程式就能回到依照自身設定值運作的狀態。

不過,並非所有原則都會寫入專用機碼。作業系統內建設定的一部分(例如「啟用 Win32 長路徑」會寫入 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 底下的 LongPathsEnabled),以及較舊世代或第三方廠商製作的範本,有些會寫到專用機碼以外的任意路徑。這類設定即使停止組態原則,值也會原封不動地留下來。目標設定實際會寫到哪個機碼,請透過 ADMX 的定義、設定的說明文字,或 gpresult 的報告來確認。

反過來說,前面提到的良好行為,僅限於系統管理範本(原則專用機碼)這個框架之內。透過指令碼或群組原則基本設定(Preferences)寫在 Policies 機碼之外的值,和一般的登錄值沒有兩樣,即使停止發布,這個框架也不會自動將其還原。在排查實務上,直接查看「目標設定是否寫在 Policies 機碼中」是最快也最確實的方法。

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

6. 系統管理範本(ADMX)與集中存放區

GPMC 的「系統管理範本」中所列的設定項目定義,是以ADMX 檔案(設定定義本體)與ADML 檔案(各語言的顯示字串)描述的。每一台電腦的 C:\Windows\PolicyDefinitions 中都有作業系統內建的定義,管理工具會讀取這些定義來組成設定畫面。⁷

若以網域方式運作,基本做法是建立集中存放區。在網域控制站的 SYSVOL 底下建立 PolicyDefinitions 資料夾(例如 \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions),其內容就會複寫到網域內所有網域控制站,而群組原則工具預設就會參照集中存放區。⁷ 這樣就能消除「每台管理端使用的範本版本不一致,看到的設定項目也不一樣」的問題。ADML 要放在依語言分開的子資料夾中(日文則是 ja-JP)。⁷

運作上有兩點要注意。第一,新版 Windows 適用的 ADMX 由 Microsoft 按版本發布,更新時要替換的是集中存放區這一側。不支援用下載版取代各電腦的 C:\Windows\PolicyDefinitions。⁷ 第二,更新既有集中存放區時,不建議直接覆寫正式環境的 PolicyDefinitions,而是建議的做法是:在 PolicyDefinitions-24H2 這類以版本命名的工作資料夾中備齊作業系統版與應用程式版(Office、Edge 等)的完整 ADMX,將現行資料夾改名為 PolicyDefinitions-23H2 等名稱先行保留,再將工作資料夾改名為 PolicyDefinitions 使其成為正式版。⁷ 群組原則工具只會參照名為 PolicyDefinitions 的資料夾,因此光是放到以版本命名的資料夾中並不會生效。這種做法的優點是,一旦發生問題,可以隨時還原到保留下來的舊資料夾。⁷

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

Windows 裝置的組態管理選項,如今已不只有 GPO 一種。以 Intune 為代表的 MDM,是透過CSP(組態服務提供者)這套機制來組態作業系統設定。以下是決定要以何者為主軸的判斷表。

觀點	網域 GPO	Intune(MDM/CSP)	手動、指令碼發布
前提條件	已加入 AD 網域+可連線到網域控制站	具備 Intune 授權+裝置已在 Intune 註冊(除了 Entra 加入/混合式加入之外,BYOD 等 Entra 註冊裝置也依註冊方式而定,可能屬於管理對象)	無(正因如此也沒有統一管控)
對公司外部、居家辦公裝置的觸及範圍	若無法透過 VPN 等方式連上網域控制站,就不會更新	可透過網際網路送達	取決於手動作業
設定的粒度與涵蓋範圍	最廣(系統管理範本+安全性設定+指令碼等)	持續擴大中,但尚未與 GPO 的全部設定對等⁹	僅限撰寫的部分
強制力	以原則方式強制執行(Policies 機碼優先)⁶	以原則方式強制執行(CSP)	使用者一旦變更就不會還原
確認套用結果的方法	gpresult / GroupPolicy 操作記錄⁴⁵	Intune 管理中心的報告	需要自行建立機制
適合的環境	以內部部署 AD 為主、常駐公司內部網路的裝置	以雲端為主、攜出裝置、據點分散的環境	數台規模,或作為其他手段的補充

判斷的軸心很單純,就是裝置的身分識別基礎架構(AD 還是 Microsoft Entra)以及裝置所在的位置。對於完全加入內部部署 AD 的公司內固定電腦群組來說,GPO 最為可靠;而對於 Entra 加入的行動電腦來說,GPO 原本就無法送達。

實際上中小企業多半處於中間狀態,也就是混合式環境(已加入網域+已在 Intune 註冊)居多,而在這種環境中最糟糕的做法就是「對同一項設定同時用 GPO 和 MDM 組態」。Policy CSP 中有一項名為MDMWinsOverGP的原則,可以在 GPO 與 MDM 發生衝突時讓 MDM 勝出,但其套用範圍僅限於 Policy CSP 內支援的原則。Microsoft 官方明確表示,對於不在此控制範圍內的設定,若同時用 GPO 與 MDM 組態,就會造成衝突狀態,無法保證哪一方勝出,因此應避免重複組態。⁸ 依設定領域決定「這項用 GPO、那項用 Intune」的管理主體,並統一交給其中一方,是混合式運作的第一原則。

在考慮從 GPO 遷移到 Intune 的階段,Intune 的Group Policy analytics是入口工具。將從 GPMC 匯出的 GPO(XML)匯入之後,就能分析每項設定是否受 MDM 支援,或是屬於不建議使用、無法對應的類型,已支援的設定則可以遷移到 Intune 的設定目錄原則。⁹ 與其把它當成「全部搬過去」的工具,不如理解為「篩選出可以遷移、無法遷移、可以捨棄的部分」的工具,這樣更貼近實際情況。順帶一提,Windows Update 的管理主體也在同一脈絡下持續重整,請一併參閱「WSUS 淘汰後的 Windows Update 管理」。

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

最後要談的是站在委外開發立場必須掌握的內容。客戶端的 GPO,會在不知不覺間改寫你的應用程式的前提條件。「在開發機上能動,但客戶端不能動」的原因之一,GPO 和防火牆、防毒軟體並列為常客。以下依實例列出。

PowerShell 的執行原則:執行原則可以用 GPO 集中組態,來自 GPO 的 MachinePolicy/UserPolicy 範圍,一律優先於在本機或處理程序中設定的值。¹⁰ 如果安裝程式或運作用指令碼是以「只要加上 -ExecutionPolicy Bypass 應該就能動」為前提寫成的,在受 GPO 管理的環境下甚至連啟動都做不到。詳情請參閱「PowerShell 執行原則與指令碼簽章」。
防火牆的本機規則合併停用:在以 GPO/Intune 集中管理防火牆的環境中,可以按設定檔單位停用「本機規則合併」(AllowLocalPolicyMerge)。在停用的環境中,安裝程式在本機登錄的收到連線規則即使存在也不會生效。¹¹ 這是在導入伺服器型應用程式之前務必確認的重點,「Windows 防火牆與業務應用程式」中有詳細說明。
磁碟機對應、Proxy 等環境組態:網路磁碟機的對應或印表機等,常見的做法是透過群組原則基本設定(Preferences)發布。¹⁶ 「應該會有 Z 磁碟機」「Proxy 應該是直接連線」這類環境假設,會因登入的使用者或電腦所屬的 OU 不同而崩解。以使用者組態發布的設定,理所當然不會套用到服務或工作的執行帳戶,這一點在常駐型應用程式中也很容易被忽略。
設定原本就「無法還原」:源自系統管理範本的設定,通常會讓使用者無法從畫面上變更(項目會變成灰色)。「請客戶端自行變更設定就能解決」這種說法行不通,這一點會直接影響因應方針的設計。

開發端現實可行的準備工作有三項。第一,將應用程式所依賴的環境前提(執行原則、待命連接埠、寫入目的地、Proxy 路徑等)以導入需求的形式文件化,並在導入前請客戶端的資訊系統人員確認。第二,發生問題時不要憑猜測,而是查看 gpresult /h 的報告與 HKLM\Software\Policies 底下的實際值(第 5 章)。第三,在設計階段就把需要系統管理員權限的處理與不需要的處理區分開來(這條界線的畫法整理在「Windows 什麼時候需要系統管理員權限」中)。GPO 不是敵人,而是環境的規格。只要把它當成規格來看待,排查就能有系統地進行。

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 確認的體制,「只有客戶端不能動」的多數情況就不足為懼。

參考連結

Microsoft Learn,Group Policy processing and precedence。關於群組原則依本機 GPO→站台→網域→OU 的順序處理,發生衝突時由後處理的 GPO 覆寫(不衝突的設定則會彙整)、同一容器內的多個 GPO 依連結順序處理、連結順序編號最小的 GPO 最後處理故優先順序最高、強制(Enforced)、停用連結、停用使用者/電腦設定、封鎖繼承等例外、已強制的 GPO 即使下層有封鎖繼承仍會持續套用、工作群組電腦只處理本機 GPO、開機時套用電腦原則、登入時套用使用者原則的流程等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn,ADMX_GroupPolicy Policy CSP。關於電腦的群組原則一定在系統開機時套用,預設每隔 90 分鐘+0〜30 分鐘的隨機偏移量進行背景更新、使用者的群組原則一定在登入時套用,同樣以預設 90 分鐘+0〜30 分鐘偏移量更新、網域控制站的預設更新間隔為 5 分鐘、更新間隔可在 0〜64,800 分鐘的範圍內組態等內容。 ↩ ↩²

Microsoft Learn,gpupdate。關於 gpupdate 在預設情況下只套用有變更的原則設定,加上 /force 則重新套用全部設定、針對使用者端軟體安裝或資料夾重新導向這類不會在背景更新時處理、只在登入時處理的擴充功能所提供的 /logoff、針對電腦端軟體安裝這類在開機時處理的擴充功能所提供的 /boot,以及 /target:{computer

user}、/wait 等各項選項的內容。

↩ ↩² ↩³

Microsoft Learn,gpresult。關於 gpresult 是顯示原則結果集(RSoP)的指令、以 /h 輸出 HTML、以 /x 輸出 XML 報告並可用 /f 覆寫、以 /r 顯示概要、以 /v、/z 顯示詳細資訊、可用 /scope {user

computer} 限縮對象、依站台、網域、OU 的成員資格產生疊加後的原則結果集等內容。

↩ ↩² ↩³

Microsoft Learn,Applying Group Policy troubleshooting guidance。關於在群組原則排查中以系統管理員權限的命令提示字元執行 gpresult /h 確認 GPO 未套用原因的步驟、GroupPolicy 操作記錄(Microsoft-Windows-GroupPolicy/Operational)中會記錄已套用的 GPO 清單與被拒絕的 GPO 清單(附拒絕原因)、每一次原則處理實例都會分配唯一的 ActivityID,並可用自訂檢視篩選出該實例事件的步驟、啟用 GPSvc 偵錯記錄等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn,Implementing Registry-based Policy。關於以登錄為基礎的原則儲存位置僅限於 HKCU\Software\Policies 與 HKLM\Software\Policies(建議位置)以及 HKCU/HKLM 的 Software\Microsoft\Windows\CurrentVersion\Policies、「未設定」狀態不會在登錄中寫入值、應用程式應先讀取原則機碼,沒有的話才讀取偏好設定值,原則機碼一律優先於偏好設定機碼、可儲存的資料類型為 REG_DWORD、REG_SZ、REG_EXPAND_SZ、原則更新時應用程式應重新確認原則機碼等內容。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn,How to create and manage the Central Store for Group Policy Administrative Templates in Windows。關於系統管理範本分為定義本體的 ADMX 與各語言顯示字串的 ADML、集中存放區要建立為網域控制站 SYSVOL 底下的 PolicyDefinitions 資料夾(例如 \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)、其內容會複寫到網域內所有網域控制站,群組原則工具預設會參照集中存放區、ADML 放在如 en-US、ko-KR 這類語言別資料夾中、不支援以下載版 ADMX 取代 C:\Windows\PolicyDefinitions、更新時建議在如 PolicyDefinitions-24H2 這類以版本命名的新資料夾中備齊作業系統版與應用程式擴充版的完整 ADMX/ADML,將現行資料夾改名為 PolicyDefinitions-23H2 等名稱先行保留,再將新資料夾改名為正式名稱 PolicyDefinitions 的步驟、發生重大問題時可還原至舊資料夾是這種做法的優點等內容。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn,ControlPolicyConflict Policy CSP。關於將 MDMWinsOverGP 原則(預設值 0)設為 1,可讓 Policy CSP 內支援的原則之 MDM 設定優先於群組原則、套用對象僅限於 Policy CSP 內的原則,不適用於 Defender CSP 等其他 CSP、對於不在此控制範圍內的設定若同時用 GPO 與 MDM 組態,會造成衝突狀態且無法保證哪一方勝出,因此應避免重複組態等內容。 ↩ ↩²
Microsoft Learn,Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune。關於 Group Policy analytics 可匯入、分析內部部署的 GPO,顯示包含 Intune 在內的 MDM 提供者支援的設定,以及不建議使用、無法使用的設定、匯入從 GPMC 以 XML 格式匯出的 GPO、可將匯入的 GPO 遷移為設定目錄原則並部署到裝置等內容。 ↩ ↩² ↩³
Microsoft Learn,about_Execution_Policies。關於執行原則的範圍依 MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine 的優先順序進行評估、MachinePolicy 與 UserPolicy 是由群組原則設定的範圍,即使在較低順位的範圍設定更寬鬆(或更嚴格)的原則,仍以優先順序較高的原則生效、可用 Get-ExecutionPolicy -List 確認所有範圍的設定等內容。 ↩ ↩²
Microsoft Learn,Windows Firewall rules。關於在以 GPO 或 CSP 集中管理防火牆的環境中,可按設定檔單位停用「本機規則合併」(AllowLocalPolicyMerge),停用時本機建立的規則不會生效,需要接收連線的應用程式其規則必須改為集中發布等內容。 ↩ ↩²
Microsoft Learn,Step-by-Step Guide to Managing Multiple Local Group Policy Objects。關於 Windows Vista 以後的本機 GPO 具有「本機電腦原則」「系統管理員/非系統管理員用」「特定使用者用」等多層(MLGPO)、依本機電腦→系統管理員/非系統管理員→特定使用者的順序處理,最後讀取的特定使用者層優先順序最高、屬於未加入網域電腦管理用途的功能等內容。 ↩
Microsoft Learn,Security filtering using GPMC。關於安全性篩選是用來限縮接收 GPO 設定的使用者與電腦的機制、要套用 GPO,目標的使用者或電腦必須同時擁有「讀取」與「套用群組原則」兩項存取權限、系統預設會對所有 GPO 授予已驗證的使用者(包含使用者與電腦)這兩項權限、篩選作用於整個 GPO,無法針對個別設定使用等內容。 ↩
Microsoft Learn,Deploying Group Policy Security Update MS16-072 (KB3163622)。關於套用 MS16-072 之後,使用者的群組原則會以電腦的安全性內容取得這項設計變更、因此電腦帳戶需要擁有 GPO 的讀取存取權限、若因安全性篩選等原因移除了已驗證的使用者的權限,則需要為已驗證的使用者或網域電腦新增「讀取」(不需要「套用群組原則」)等內容。 ↩ ↩²
Microsoft Learn,Loopback processing of Group Policy。關於迴圈處理是依電腦物件所在位置套用使用者設定 GPO 集合的功能、是針對公共區域、實驗室、教室等特殊用途電腦所設計的機制、僅在 Active Directory 環境中受支援,並具有合併與取代兩種模式等內容。 ↩
Microsoft Learn,Group Policy Preferences Getting Started Guide。關於群組原則基本設定(Preferences)是 GPMC 中用來組態磁碟機對應、印表機、排程工作、服務、資料夾選項等的一組擴充功能、可透過項目層級目標處理進行篩選、能在不限制使用者變更的情況下發布設定,可選擇要強制執行的設定與不強制執行的設定(與原則性質不同)等內容。 ↩

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

與本主題相關的服務

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

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

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