對于網絡管理員來講，關于組策略的問題可能聽到最多的抱怨就是:“我設置了一個策略，為什么它不生效?”。對于一些比較大的網絡環境，組策略可以減輕網管人員的管理工作，但其出問題的幾率還是比較大的。這一方面是由于我們在日常操作時不慎引起的，另一方面是由于策略相互影響而造成最終的結果與設想不一致。

組策略應用要點

這里，筆者給出幾點微軟不推薦的做法:

1.不要刪除兩條默認的策略(默認域策略和默認域控制器策略)，很多問題的發生都是由刪除這兩條默認策略而引起的。而且要使用組策略管理控制臺(GPMC)工具備份這兩條默認策略，用于將來還原。如果直接通過GPMC刪除默認策略時，我們會發現是行不通的，但是，稍有經驗的讀者知道如何刪除它們。既然是一個不推薦的做法，希望大家不要刪除它們。

2.組策略是不能夠鏈接在用戶組上的。有很多初次接觸活動目錄的管理員，經常設想將組策略生效于某一用戶組，這是行不通的。組策略不是為用戶組設定的策略，而是一組策略的集合，只能鏈接在站點、組織單元和域上面。

3.組策略的生效問題

(1)生效順序

正常生效順序:本地策略→站點策略→域策略→父OU策略→子OU策略。

我們使用時，在出現登錄對話框前，會有“應用安全策略”的提示，這也就是本地策略生效的過程。

發生沖突時，最新的策略設置會覆蓋其他設置。計算機設置高于用戶設置(即使用戶設置是后設置的)。父容器組策略設置與子容器設置發生沖突，子容器中組策略的設置將最終生效。同一容器的多個策略按照優先權順序進行生效。所以，當在一個容器上面鏈了多個GPO時，不妨仔細看看它們的順序，很有可能問題是順序不當引起的。

(2)生效時間

默認情況下，非域控制器的計算機每90分鐘刷新一次策略，其中含有隨機的30分鐘時間偏移量，時間偏移量保證了多個計算機不會同時連接到同一個域控制器上面。域控制器每5分鐘刷新一次，保證了緊急更新的組策略設置(安全性設置)能夠得到及時執行，可以在 “域控制器組策略重新刷新時間間隔”里面更改(如圖1)。

498)this.style.width=498;">

圖1 “域控制器組策略重新刷新時間間隔”進行更改

在Windows 2000里面可以使用secedit/refreshpolicy machine_policy或secedit /refreshpolicy user_policy命令強制刷新，在Windows XP或Windows 2003使用gpresult /force強制刷新。如果新做的設置沒有能夠生效，不妨考慮一下是否為刷新時間間隔問題。

組策略常規排錯法

如果您平時是按照以上建議做的，結果組策略的某些設置還是沒有按照預期生效，我們就需要做排錯處理了。

1.首先，確?？蛻舳四玫搅讼嚓P的策略。比如，希望域內所有的計算機不要顯示上次登錄的用戶名以確保安全，可是在所有的用戶端都沒有生效，說明這條策略很有可能客戶端就沒有拿到。從Gpresult或者是組策略結果集，可以知道客戶端拿到了哪些策略。前者是命令行模式，后者是圖形界面，功能都是相同的。下面介紹組策略結果集的使用。

(1)打開gpmc.msc，單擊組策略結果收集向導，選擇是本機還是遠程計算機，選擇為哪一個　用戶顯示最終結果，我們就可以查看結果了(如圖2)。

498)this.style.width=498;">

圖2 查看結果

在“組策略對象→應用的策略”中，我們能夠看到出問題的客戶端應用了哪些GPO，沒有應用哪些GPO，如果某一條組策略沒有被應用，那么設置必定沒有生效，因為計算機根本就沒有拿到這個策略。

正如案例中所述的那個問題(希望域內所有的計算機不要顯示上次登錄的用戶名以確保安全，可惜在所有的用戶端都沒有生效)，后來在隨機的客戶端運行 gpresult，結果發現，為計算機設置的不顯示上次登錄的用戶名策略(當時命名為Do not Display last logon name)根本就沒有應用到客戶端，自然策略不會生效。

2.如果網絡里面有多臺域控制器，要確保多臺域控制器的策略保持一致，檢查方法是運行 gpotool(需要安裝Windows Resource Kit工具包)。

Validating DCs...

Available DCs:

mic-technet.dc.mic

Searching for policies...

Found 4 policies

Policy {31B2F340-016D-11D2-945F-00C04FB984F9}

Friendly name: Default Domain Policy

Policy OK

==========================================================

Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}

Friendly name: Default Domain Controllers Policy

Policy OK

==========================================================

Policy {90BD780C-D2E8-44CB-97B8-80B343852457}

Friendly name: Do not display logon name

Policy OK

==========================================================

Policy {CC2C8E4F-FA55-4824-AC75-0122494DCC31}

Friendly name: user

Policy OK

==========================================================

Policies OK

這是一次運行gpotool的結果，當然，筆者這里只是一個虛擬環境，只有一臺域控制器，讀者可以拿出問題的日志與正常日志進行比對，便會發現問題所在。設想，如果有兩臺域控制器它們之間的復制又出了問題，那么意味著每個域控制器的組策略不統一了，自然客戶端在應用時會發生問題。

3.檢查組策略對象是否在AD中和Sysvol中，而且GUID是否與正確的GPO相關聯。

(1)查看組策略的GUID。

(2)用Search.vbs檢查LDAP協議正確性，GPO和GUID是否為真正意義的對應。

Search.vbs是Windows 2003安裝光盤SupportTools Support.cab下的一個腳本工具，可以將GPO名稱解析為GUID。

使用方法:

cscript search.vbs "LDAP://dc=mydomain,dc=com"

/C:"&(objectClass= groupPolicyContainer)(displayName=Default Domain

Policy)" /P:name /S:SubTree

將mydomain和com換成您自己的域名。

3.以上兩步結束后，如果仍然沒有查到問題所在，可以激活userenv.log:

打開注冊表編輯器，定位至HKEY_LOCAL_MACHINESoftware MicrosoftWindows NT CurrentVersionWinlogon。

新建dword值:UserEnv DebugLevel，數據為10002 (Windows 2000/XP)，Windows 2003改為30002。重新啟動后在%SystemRoot%Debug UserMode下可找到Userenv.log 文件。該文件對我們解決用戶配置文件和組策略處理方面的問題很有幫助。

例如，有時會在該文件中發現:

USERENV(178.63c) 22:27:23:188 EvalList: Object cannot be accessed

這說明登錄的用戶對要應用給他的GPO是沒有權限的，這時就要注意組策略的權限問題。

4.如果是和安全設定有關的策略沒有生效，可以開啟Winlogon:

打開注冊表編輯器，定位至HKEY_LOCAL_MACHINESoftware MicrosoftWindows NT CurrentVersionWinlogon GPExtensions{827D319E-6EAC-11D2-A4EA-00C04F79F83A}，新建一個DWORD值，名稱為 Extension DebugLevel，數值設為2，刷新策略，這樣在以下位置Windows SecurityLogs生成winlogon.log，所有安全設定會被詳細記錄在里面。

舉例來說，啟動基于Windows 2000的計算機時，事件查看器大約每5分鐘記錄一次事件ID 1202和1000。

然后當查看 Winlogon.log 文件時，會發現下面的錯誤信息:

Error 1332: No mapping between account names and security IDs was done.Cannot find Power Users.

很明顯，這是有人給Power Users組做了安全權利指派，但是當計算機被提升成為域控制器后，Power Users組就會被刪除掉，然而組策略里卻沒有將其權限相應的刪除，計算機就會不停地找(準確的說是對應)Power Users組，因此就會報錯。

當我們在查看Userenv.log和Winlogon.log時，可以關注以下信息:fail，error，cannot等這些失敗、錯誤信息。