群組原則

最佳化群組原則效能

Darren Mar-Elia

摘要:

• 整合型與功能型 GPO
• 如何處理群組原則項目
• GP 變更時會發生什麼事

經常有人問我：「從效能的觀點看來，是擁有少數幾個大型 GPO 比較好呢，還是很多小型 GPO 比較好呢？」因此，本文的重點將放在這個問題及其他群組原則相關的設計和效能議題。就大部分的問題來說，

我可以先告訴您答案：「視情況而定」。這雖然聽起來有點含糊其詞，但我的目的是要闡明群組原則處理的基本機制，而無論您是剛開始接觸，還是想要最佳化包含上百個現有 GPO 的環境，都能針對您的群組原則設計做出明智的決策。

整合型與功能型 GPO

先讓我們來說明實作 GPO 的各種方式。「整合型」和「功能型」指的是設計 GPO 的方式。整合型 GPO 包含許多不同區域的設定，例如，整合型 GPO 可能在單一 GPO 裡面包含系統管理範本、Internet Explorer 維護，以及軟體安裝原則的設定。而相反地，功能型 GPO 通常只有一種用途，例如，功能型 GPO 可能只進行軟體安裝，或強制安全性設定。我甚至還看過只包含一個原則設定的功能性 GPO 呢！不過那可能是極為罕見的情況。[圖 1] 說明各種方法的一些優缺點。

Figure 1 Comparing monolithic and functional GPOs

您可以看到，哪種方法 — 整合型或功能型 — 各種情況都通用，並沒有固定的答案。在您的環境中，您可能兩種都需要用到。舉例來說，當您為整個網域建立安全性原則時，可能覺得功能型方法比較好用。而擁有一個只包含安全性設定的 GPO，比較方便將該 GPO 的控制權委派給安全性系統管理員，以免其他人使用。而在有相同權杖的情況下，如果您將 GP 管理委派給 OU 系統管理員，然後為每個 OU 建立一個整合型 GPO，便可提供這些系統管理員一個讓他們管理所有原則設定的地方。這不但為他們降低工作的複雜度，更可讓您節制針對指定 OU 使用者和電腦建立的 GPO 數目。

這些高階設計的決策何以影響群組原則處理的效能，還有您該如何針對 GP 設計做出明智的決策來盡可能降低效能衝擊呢？要充分發揮群組原則基礎結構的效能，第一步就是了解群組原則處理的實際運作方式。

了解群組原則處理

群組原則處理是一連串複雜的互動作業，牽涉到 Windows® 和 Active Directory® 基礎結構的許多層面。從高階角度來看，群組原則處理分成兩個部分。第一個部分稱為核心，或是群組原則基礎結構處理。在這個階段中，Windows 群組原則用戶端會查詢最接近它的網域控制站，來判斷 DC 的連結速度為何，它存在於 Active Directory 階層的何處 (亦即用戶端是哪個站台、網域和 OU 的成員)，以及有哪些 GPO 套用到電腦或目前登入的使用者 (有一點要注意的是，在這個路徑位置中，用戶端有可能是參加 Active Directory 網域的伺服器或工作站)。GPO 清單一旦建立後，就會開始下一個階段 — 用戶端延伸 (CSE) 處理。在 CSE 的階段期間，每個登錄的 CSE 都會處理在它的區域有實作設定的 GPO 清單。例如，登錄或系統管理範本 CSE 無論在哪種情況下都會先執行，並且處理所有套用到指定電腦或使用者且當中有實作登錄原則的 GPO。

隨後的清單會詳載群組原則處理週期所進行的步驟，包括在用戶端和網域控制站之間的網路互動。要特別注意的是，群組原則會同時套用到電腦和使用者上。因此，原則每次處理時 (例如在背景重新整理群組原則期間)，電腦和指定系統上目前登入的使用者帳戶便會重複我在下面列舉的週期，因為它們各自都會套用不同組的原則。發生這種情況時，Windows 實際上會同時執行電腦和使用者的處理週期，並且在群組原則引擎處理序內的不同執行緒上執行每個週期 (Windows 2000、Windows XP 和 Windows Server® 2003 的 Winlogon 處理序，以及 Windows Vista® 和 Windows Server 2008 中的群組原則用戶端服務)。

處理 GP 的程序包含六個步驟：

1. 用戶端在網域控制站的站台內執行網際網路控制訊息通訊協定 (ICMP) 低速連結偵測，以判斷連結速度。在 Windows Vista 中，使用 ICMP 偵測低速連結已由網路定位知悉 (NLA) 服務所取代。
2. 用戶端從它的本機登錄讀取 CSE 狀態資訊，以判斷哪些 GPO 要最後處理。
3. 用戶端使用 LDAP 在 Active Directory 階層裡面 — 首先是在 OU 層級 (包括所有巢狀 OU)，接著是網域，最後是 Active Directory 站台層級 — 它所在位置內的每個容器物件上搜尋 Active Directory 中的 gpLink 屬性。它根據這項搜尋的結果，建置必須經過評估才能處理的 GPO 清單。
4. 接著在 Active Directory 內搜尋每個 GPO，以判斷用戶端 (使用者或電腦) 是否具有必要的權限來處理它。它的版本號碼、SYSVOL 中 GPO 的群組原則範本 (GPT) 這個部分的路徑，以及 GPO 內實作了哪些 CSE 也都會進行評估。
5. 用戶端接著使用伺服器訊息區 (SMB) 通訊協定來讀取 GPT 的內容，並從 gpt.ini 檔案取得 GPO 的版本號碼。群組原則容器 (GPC) 和 GPT 裡面的版本號碼是用來判斷 GPO 自上次處理週期以來是否有所變更的要素之一。
6. 每個 CSE 以在 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions 下登錄的順序執行，如果 GPO 自上次處理週期以來有所變更 (在核心處理期間判定)，則處理實作該 CSE 的 GPO。每個 CSE 也會在每次重新處理期間，將使用者原則結果組 (RSOP) 資料 (如果有的話) 記錄到 Windows Management Instrumentation (WMI)。

讓我們來分析一下這個程序，並探討效能會受到什麼影響。第一，要明白前景和背景處理之間的差異。對於電腦，前景處理是發生在系統重新啟動期間；對於使用者，則是發生在使用者登入期間。根據預設，背景重新處理會在工作站和成員伺服器上每 90 分鐘發生一次，若是隨機指定，則最多是 30 分鐘一次。背景重新整理在網域控制站上的預設頻率是每 5 分鐘發生一次。在 Windows Vista 中，您也可以 NLA 為主進行重新整理，這基本上是背景重新整理事件，由前一次群組原則處理因為缺乏網域控制站的存取權 (例如當用戶端在發生背景間隔時處於離線狀態) 而失敗所觸發。這些區別為何這麼重要？主要是因為特定 CSE (例如軟體安裝及資料夾重新導向 CSE) 在背景重新處理期間並不會執行。同樣地，登入/登出或開機/關機指令碼在背景重新整理期間也不會執行。

在本程序的步驟 1 當中，我有提到低速連結偵測程序。而在 Windows Vista 之前的系統中，這個程序有賴用戶端使用 ICMP 去 Ping 網域控制站，來判斷它的可用性和連結速度。如果計算出的連結速度低於特定的閾值 (預設為 500Kb/s)，就會將它視為低速連結，再次強調，特定 CSE (例如軟體安裝、資料夾重新導向和 Internet Explorer 維護) 並不會執行。所有這些情況除了可能對效能造成衝擊之外，也可能影響到預期的原則交付情形。

原則處理週期對效能影響最廣的層面，可能是用來判斷套用至電腦或使用者的 GPO 是否變更的邏輯。群組原則引擎有一個內建的最佳化機制：假如電腦或使用者自上次處理 GP 以來都沒有變更的話，就不會進行任何處理。這很明顯會對用戶端處理原則所花的時間產生相當的衝擊，尤其是如果您的 GP 環境很靜態的話。讓我們更深入探討何謂變更。

當群組原則變更時

那麼，就群組原則處理而言，到底什麼才算是變更呢？影響的因素有很多，但最明顯的是，如果您對 GPO 進行變更，處理該 GPO 的用戶端將會偵測到此變更，並重新處理該 GPO。那麼用戶端要怎麼知道 GPO 已變更呢？這要靠 GPO 上和用戶端內的版本號碼來判斷。

GPO 包含兩個部分 — 在每個網域當中存放在 Active Directory 裡面位於 CN=Policies, CN=System 容器下的 GPC，以及存放在 SYSVOL 位於 [原則] 資料夾下的 GPT。GPO 的每個部分都包含版本號碼，對於 GPC，這個版本號碼是存放在 GPC 物件的 versionNumber 屬性內。對於 GPT，則是存放在指定 GPT 的根目錄中的 gpt.ini 檔案裡面。用戶端也會在它的登錄當中記錄它處理過的 GPO 版本號碼 (包括每一電腦和每一使用者)。對於電腦，這項版本資訊是放在 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History 下，而對於每個用戶端上的使用者，則是放在 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User> 下。

當發生群組原則處理時，其中一部分工作是檢查依電腦或使用者而定的所有 GPO 的版本號碼，將它們與上個週期處理過的 GPO (如登錄中找到的) 相加比對。目前 GPO 若有任何不同的版本號碼 (請注意，只會注意是否不同，但它們有可能變大變小！)，便會在目前的處理週期期間處理該些 GPO。如果沒有不同，除非滿足其他變更條件，否則不會進行處理。其他的變更條件如下：

• 套用到使用者或電腦的 GPO 清單有所變更 (新增或移除 GPO)
• 使用者或電腦的安全性群組成員資格有所變更
• 連結到 GPO 的 WMI 篩選器有所變更 (新增或移除 WMI 篩選器)

如果滿足其中任何一項變更條件，那麼用戶端便會在該週期期間重新處理原則。但是在這個程序當中有些微妙的地方您要特別注意，因為它們對效能可能會造成明顯的衝擊。對於指定的 CSE，如果 10 個 GPO 當中有一個產生變更，那麼就必須針對該 CSE 處理所有的 GPO。要記住，處理作業是依每個 CSE 進行。然而，CSE 必須以控制處理的優先順序來處理原則 (先是本機 GPO、再來是站台連結的 GPO，然後是網域連結的 GPO，再來是 OU 連結的 GPO)。根據這項條件，假設我們有名使用者套用 10 個 GPO，每個都在 Active Directory 階層的不同層級上連結。讓我們再假設這 10 個 GPO 每個都有實作一些系統管理範本原則設定。現在，有個系統管理員變更了連結到網域的 GPO — 加入新的系統管理範本原則設定。然後電腦或使用者要處理原則時，注意到那個經過變更的 GPO 的版本號碼比上次處理的時候還大，所以 GPO 需要再次進行處理。但是為了保持 GP 處理的優先順序，它必須處理套用到所有 GPO 的所有系統管理範本設定。因此對單一 GPO 的簡單變更，有可能對該用戶端產生明顯的效能衝擊。

整合型和功能型 GPO 效能比較

了解處理週期，還有對群組原則環境的變更會如何影響處理作業後，讓我們把話題轉回整合型與功能型 GPO，以及它們各自對效能造成的衝擊。

因為群組原則版本控制運作方式的關係，整合型 GPO 對效能可能會有不明顯的負面影響。發生這種情況的原因不是全然一清二楚，但是與群組原則處理當中沒有依 CSE 進行版本控制的概念有很大的關聯。讓我們假設有名使用者身上套用了三個 GPO。每個 GPO 都是整合型的，因為各個都實作了數個原則區域。比方說，假設每個 GPO 都實作了系統管理範本原則、軟體安裝原則和資料夾重新導向原則。現在再假設系統管理員對其中一個 GPO 中的系統管理範本進行了變更。它的版本號碼因為該項變更而增加。接著使用者進來處理群組原則，系統管理範本 CSE 於是啟動，並看到了其中一個 GPO 已變更，所以它又再次處理了這三個 GPO。

當軟體安裝和資料夾重新導向 CSE 執行時，它們也查看了 GPO 版本號碼，並發現到其中一個 GPO 有了新的版本號碼。但是因為新的版本號碼並沒有告訴它們在那個 GPO 中是變更了哪個原則區域，於是為了以防萬一，它們乾脆全部三個 GPO 都再處理一次。結論就是，在整合型 GPO 實作中，對原則的其中一個區域進行變更可能會導致在其他區域進行處理作業。

沒錯，在軟體安裝或資料夾重新導向原則的情況下，該些 CSE 實際上可能不會進行任何動作，舉個例說，要是應用程式已經安裝了，怎麼樣也不會再安裝一次。但重點是，任何 CSE 都可能產生這種行為，而且在設計整合型 GPO 時應將此列入考量。如果您有個原則區域會經常變更，應該考慮將實作該原則區域的 GPO 與其他原則區域分開。

從功能型 GPO 的觀點看來，效能方面的考量因素就比較明顯。如果您的每個使用者或電腦都有多個 GPO (因為功能型方法對於特定原則設定組一般都會牽涉多個 GPO)，就表示群組原則引擎在群組原則處理的核心階段期間，必須花更多的時間來列舉這些 GPO。不過，這對效能不一定會造成顯著的影響，我們在下一節就會談到。

測量群組原則效能

為了對群組原則基礎結構的效能做出明智的決策，您終究得測量群組原則在實際環境內的表現。影響指定處理週期的因素之多，使得製作模型或預測群組原則效能幾乎是不可能。有鑑於此，觀察 GP 處理效能是否有問題的最佳辦法是根據經驗來評量。那到底什麼情況才算效能不彰呢？只要群組原則處理影響到使用者在系統上的使用經驗，都算是效能不彰。這對各個組織來說可能不盡相同，但是關鍵在於在碰到問題時要察覺得出來。

那麼要如何測量指定群組原則處理週期的期間呢？答案可沒那麼簡單。如果您執行的是 Windows Vista 或 Windows Server 2008，可以利用全新的事件檢視器作業記錄。事件檢視器裡面的群組原則作業記錄 (可在 Applications and Services Logs\Microsoft\Windows\Group Policy\Operational 中找到)，為群組原則處理週期各步驟提供了詳實的檢測，包括處理的各個階段所花的時間等 (見 [圖 2])。

[圖 2]** 顯示原則處理時間的群組原則作業記錄事件 **(按影像可放大)

然而，如果您不是在 Windows Vista 或 Windows Server 2008 環境下工作，測量原則處理時間的機制可能就比較不那麼直接了當。在這種情況下，您可以選擇啟用詳細的 userenv 記錄 (請參閱 support.microsoft.com/kb/221833 上的 Microsoft 支援文件)，並查看該檔案當中指定處理週期的時間戳記，或是使用用戶端上存放在登錄內代表原則處理開始和停止時間的值。這些值是存放在電腦的下列位置：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

使用者的位置如下：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

這些值是以 FILETIME 的格式儲存，而且必須轉換成標準的日期和時間。您也可以使用我寫的免費 GPTime.exe 公用程式 (可自 gpoguy.com/tools.htm#GP_Time_Utility 取得) 來取得相同的資訊。

如果您沒有 Windows Vista 或 Windows Server 2008 環境，但可存取 userenv 記錄，還是可以取得每個原則處理週期花了多少時間這類的寶貴資訊。例如，[圖 3] 便顯示了 userenv 記錄的片段，指出群組原則處理核心階段的那部分。

[圖 3]** userenv 記錄的一部分 **(按影像可放大)

請注意，記錄檔的每一行都包含時間戳記。當您看到有個事件顯示類似「ProcessGPOs:Starting user Group Policy (Background) processing ... (ProcessGPOs: 開始使用者群組原則 (背景) 處理...)」的內容時，就表示群組原則處理週期的核心部分已經開始。而當您看到「ProcessGPOs:Processing extension Registry. (ProcessGPOs: 處理延伸登錄)」一行時，表示處理週期的 CSE 部分已經開始。您可以利用這個記錄檔及當中的時間戳記來判斷原則週期的各個部分所花的時間。

概略的效能觀察

您要是花足夠的時間分析 userenv 記錄檔，就會開始看出一些成形的模式，雖然您無法預測出原則處理會花多久的時間，但是您可以粗略觀察到指定處理週期的時間都花在什麼地方。舉例來說，在原則處理事件期間，當要處理原則變更而 CSE 因為變更而有事要做時，花在 GP 處理的核心部分的時間，與 CSE 部分相較起來通常要短很多。

大部分的原則區域都是如此，因為大多數 CSE 需要執行的工作所執行的時間比它們處理核心部分還要久，它們最耗時的作業是查詢 Active Directory 和 SYSVOL。例如，花在核心處理與花在執行 Microsoft® Office 安裝的軟體安裝 CSE 之間的時間根本沒得比。但是，就原則正常的背景重新處理作業而言，如果自上個週期以來沒有什麼變更，處理週期的核心部分所花的時間大約與 CSE 部分相同。這種情況的例外是登錄原則處理 — 除非您對指定的使用者或電腦設有數十個或上百個登錄原則設定，否則速度其實相當快。

此外，因為用不到而停用 GPO 的電腦或使用者端，對原則處理效能的影響並不大。如果原則端用不到，那麼唯一的負荷將是發生在查詢 Active Directory 來確定這一點，而且當進行查詢以確定是否已針對該 GPO 端實作任何 CSE 時，也必須執行相同的查詢來檢視停用選項。停用一端的影響可說是微不足道。

最佳 GP 效能的設計建議

探討了群組原則處理效能這麼多層面之後，此處提供一些會直接影響效能的設計建議。總共可歸納為四個重點。

1. 如果您會經常變更 GPO，請謹記前文提到對一個 CSE 進行變更可能會影響所有 CSE 處理作業。就此而言，假設您打算經常變更登錄原則，把登錄原則放入功能型 GPO (只處理登錄原則的 GPO) 可能比較妥當，因為在發生變更時，可將其他 CSE 隔離而不用處理。
2. 當不確定適當的 GPO 數量時，記住原則處理只會在發生變更時進行，而且「耗資源」的 CSE (像是軟體安裝、資料夾重新導向等)，或是處理大量登錄原則，或是設定大型檔案或登錄樹狀目錄的權限時，都很耗時間。在核心處理期間用來查詢 Active Directory 以取得 GPO 清單所花的時間，往往是處理週期最不耗時間的部份。因此，處理 30 個套用到指定使用者不做什麼登錄原則變更，也不常變更的 GPO 所花的時間，可能比處理 5 個經常執行耗資源的 CSE 的 GPO 來得短，因為這些 GPO 經常變更。
3. 避免會明顯折損原則處理效能的行為。例如，您可以設定原則強制 CSE 即使 GPO 未經過變更也進行處理 (在 [電腦設定]\[系統管理範本]\[系統]\[群組原則] 下)。不過，要是這麼做，每個週期期間的原則處理肯定會花更長的時間。
4. 記住停用 Windows XP 和 Windows Vista 中的快速登入最佳化 (透過在 [電腦設定]\[系統管理範本]\[系統]\[登入]\[永遠在電腦啟動及登入時等待網路啟動] 中啟用原則來完成) 所需付出的代價。當啟用此原則時，前景處理會從非同步切換為同步處理。這表示，電腦和使用者原則必須完成執行後，使用者才能獲得電腦和桌面的控制權。不過，它也可能提供一些好處，因為它可以解決需要兩次或多次重新開機或登入才能使軟體安裝和資料夾重新導向原則生效的問題。

總結

雖說群組原則處理的效能不算是一門真正的科學，還是有些實用的觀點可以帶入設計過程，藉此緩和效能方面的問題。

了解處理週期的運作方式，以及時間都花在什麼地方，對追蹤效能問題將大有幫助。使用 Windows Vista 或 Windows Server 2008 作業記錄 (或是舊版 Windows 中的 userenv 記錄) 來取得處理週期相關的指示資訊。記得從 CSE 的觀點來探勘 CSE 處理難以捉摸的行徑，以及原則當中所謂的變更是什麼。也別忘了，在經常變更的動態環境中，功能型 GPO 可能比整合型 GPO 受用。但重要的是，群組原則是一種為了幫助您更妥善管理 Windows 環境而設計的技術。因此當以商務需要為依歸，來推動群組原則的設計，而不要本末倒置。將此處討論的效能行為謹記在心，將可助您達成此一目標。

Darren Mar-Elia是一位 Microsoft 群組原則 MVP，也是知名群組原則網站 — www.gpoguy.com 的打造者和《Microsoft Windows Group Policy Guide》(Microsoft Press，2005 年) 的作者之一。他還是 SDM Software Inc. 的 CTO 和創辦人，您可以透過電子郵件與他連絡：Darren@gpoguy.com。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.