Active Directoryに参加したWindows XPクライアントには、グループポリシー と呼ばれる“ ドメインベースでのコンピュータやユーザの個別設定” がネットワーク経由で適用され、自動的にコンピュータの設定やユーザのデスクトップ環境を整えますが、これを変更したときに、予想に反して反映されないことがあります。その場合、gpresult というコマンドを実行するだけで、かなりの切り分けが可能になります。
gpresult /zでグループポリシーの状態を確認
まず、実際にログオンしている状態で gpresult /z コマンドを実行し、グループポリシーがクライアントやユーザにどう適用されているのかをチェックします(図1 ) 。なお、このチェックはログオンしているユーザによって結果が変わるので、問題が起こっているユーザで実行する必要があります。結果ログは長いので、通常はテキストファイルにリダイレクトします。
図1 gpresult /z を実行したところ
C:\>gpresult /z > %USERPROFILE%\デスクトップ\gpresult.log
C:\>
結果ログに“ エラー:アクセスが拒否されました” や“ 情報:ポリシーオブジェクトは存在しません” と表示された場合、ログオン時に有効なグループポリシーが取り込めない状態になっている意味になるので、ログオンプロセス自体を疑い、本特集のCommand-2 の例であげたような「ログオンに時間がかかる」に添ったトラブルシューティングを行った方がよいでしょう。
そうでなかった場合、結果ログ(リスト1)を見て、それに見合った対応をすることになります。
gpresult結果ログの見方
まず“ ドメインの種類” と“ サイト名” をチェックすることで、DNSベースでドメインコントローラが見つけられているか、確認することができます。通常は "ドメインの種類" は "Windows 2000" となりサイト名も指定されますが、ここが“ WindowsNT 4” となっていてサイト名が“ N/A” となってる場合、SRVレコードによるDNSベースでのドメインコントローラの検索ができていません。この場合、pingを使って名前解決の様子を確認し、ipconfigやnslookupを使ってDNSサーバからSRVレコードが検索できるようにします。方法については、Command-2 を参考にしてください。
リスト1 図1のコマンド実行でできたログ(grpresult.log:部分)
Microsoft (R) Windows (R) XP Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001
作成日 2007/08/13 時刻 4:34:22
RSOP の結果 EXAMPLE\user01 - CHABCL00 : ログ モード
--------------------------------------------
OS 種類: Microsoft Windows XP Professional
OS 構成: メンバ ワークステーション
OS バージョン: 5.1.2600
ドメイン名: EXAMPLE
ドメインの種類: Windows 2000
サイト名: Site2
移動プロファイル:
ローカル プロファイル C:\Documents and Settings\user01
低速リンクで接続: はい
コンピュータ設定
---------
前回のグループ ポリシーの適用時: 2007/08/13 at 4:32:40
グループ ポリシーの適用元: chabsv01.example.com
グループ ポリシーの低速リンクのしきい値: 500 kbps
適用されたグループ ポリシー オブジェクト
----------------------
Default Domain Policy
低速回線使用の確認
次に見るべき項目は "低速リンクで接続" という項目です。ここが "はい" という表示になっていた場合、クライアントは低速回線 ( デフォルトは500kbps以下) での接続とみなされ、グループポリシーの一部 ( アプリケーションの展開・スタートアップ/ログオンスクリプト、フォルダリダイレクト、ディスククォータ、Internet Explorerのメンテナンス、IPセキュリティ)の項目は適用されません。
検出された低速回線が "はい" の場合、その検出結果が正しいかどうかを判断します。ログオンしているドメインコントローラとクライアント間でICMP(いわゆるping) が通っているか確認します。グループポリシー適用時に、クライアントはpingを使ってログオンしたドメインコントローラとのネットワーク距離を測ります。このとき、複数のパケットサイズでpingを行うのですが、2048bytesのサイズが含まれるため、ルータやファイアウォールでpingのパケットサイズを制限している場合、「 pingコマンドでは疎通するのに実際は疎通していない」状況が発生します。
そこで、ping -l 2048 [ドメインコントローラ名] とコマンドを実行し、このパケットサイズで疎通できるか、確認します(図2 ) 。疎通できない場合、ルータやファイアウォールの設定を疑います。はっきり設定を確認したいときには、パケットサイズを2048bytes から少しずつ減らして、くり返しping -lコマンドを実行すれば、サイズの上限が確認できるでしょう。
図2 ping -l コマンドによる回線疎通の確認
C:\>ping -l 2048 chabsv01
Pinging chabsv01.example.com [192.168.10.29] with 2048 bytes of data:
Reply from 192.168.10.29: bytes=2048 time=116ms TTL=127
Reply from 192.168.10.29: bytes=2048 time=112ms TTL=127
Reply from 192.168.10.29: bytes=2048 time=112ms TTL=127
Reply from 192.168.10.29: bytes=2048 time=113ms TTL=127
Ping statistics for 192.168.10.29:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 112ms, Maximum = 116ms, Average = 113ms
C:\>
できるならルータやファイアウォールの設定を見直す方がいいですが、それが難しい場合、各コンピュータに修正プログラムを適用してから ( OSによってサービスパックで適用されていることがあります) PingBufferSize レジストリ値を修正する方法があります。詳しいところはマイクロソフトのサポートページ をご覧ください。
2048bytesのpingが疎通した場合、pingの応答時間から、グループポリシーが判定するおおざっぱなリンク速度を計算します。計算式は、固定値32000Kbpsをping応答時間の平均値で除算します。たとえば、pingの応答時間が平均で110msであれば32000÷110=290Kbps程度となり、デフォルト設定では低速リンクと見なされるのが妥当です。
このとき、デフォルト設定が変更されていないか(グループポリシー設定で変えられます) 結果ログの "グループポリシーの低速リンクのしきい値" ( コンピュータの設定とユーザーの設定の両方があります) を確認しておきます(リスト2 ) 。
リスト2 gpresult結果ログ(grpresult.log)の「グループポリシーの低速リンクのしきい値」部分
< 前略 >
コンピュータ設定
---------
前回のグループ ポリシーの適用時: 2007/08/13 at 4:32:40
グループ ポリシーの適用元: chabsv01.example.com
グループ ポリシーの低速リンクのしきい値: 500 kbps
適用されたグループ ポリシー オブジェクト
----------------------
Default Domain Policy
< 中略 >
管理テンプレート
--------
N/A
ユーザー設定
-------
CN=user01,OU=Users,OU=Accounts,DC=example,DC=com
前回のグループ ポリシーの適用時: 2007/08/13 at 4:32:40
グループ ポリシーの適用元: chabsv01.example.com
グループ ポリシーの低速リンクのしきい値: 500 kbps
適用されたグループ ポリシー オブジェクト
----------------------
Default Domain Policy
< 後略 >
なお、ping の応答時間はおなじシステムでも測定状況で大きく異なることがあるため、この方法はあくまで目安です。正しく計測するにはユーザ環境デバッグログ ( Userenv.log) をレジストリ設定で取得して、その時の状態を調べる必要があります。
低速リンクの検出に問題がない状況になったら、実際に適用されていないグループポリシーを結果ログから確認します。適用されたポリシーや除外されたポリシー名、適用された項目のレジストリキーなどが結果ログには記載されていますので、低速リンクで適用されないポリシーが該当するかどうか、確認します。この設定を変えたい場合、低速リンクの検出に関するポリシー設定を変更する必要があります。
※なお、ログオンスクリプトについて、Windows 2000やWindows XPでは低速リンクでも適用されてしまう不具合 ( 詳しくはサポートページ をご覧ください) がありますので、混乱しないようにしてください。
グループポリシーの複製の確認
低速リンクでも適用されるはずのポリシーが適用されない場合 ( レジストリベースである多くのポリシーは低速リンクでも適用されます) 、ドメインコントローラ間でグループポリシーの複製ができているかどうかを疑います。
上記を簡単に調べる方法として、クライアントにグループポリシーを適用したドメインコントローラと、PDCエミュレータドメインコントローラの内容を比較します。これは、通常の操作ではグループポリシーの追加や編集はPDCエミュレータのSYSVOL共有に含まれるポリシーファイルに対して行われ、その内容がファイル複製サービスによって、他のドメインコントローラに複製される実装だからです。
まず、gpresult結果ログで適用されていない部分があるポリシー名を確認したら、リモートデスクトップ接続などでドメインコントローラにログオンしたうえ、ドメイン名がexample.comとすると
ldifde -d "cn=policies,cn=system,dc=example,dc=com" -r "(&(objectClass=groupPolicyContainer)(displayName=[ポリシー名]))" -f [出力ファイル名]
というコマンドをドメインコントローラ上で実行し、内容を調べます(図3 ) 。
図3 ldfileコマンドの実行例
C:\>ldifde -d "cn=policies,cn=system,dc=example,dc=com" -r
"(&(objectClass=groupPolicyContainer)(displayName=
Default Domain Policy))" -f %USERPROFILE%\デスクトップ\ldifde.log
"chabsv00.example.com" に接続しています
SSPI を使って現在のユーザーとしてログインしています
ディレクトリをファイル ldifde.log にエクスポートしています
エントリを検索しています...
エントリを書き出しています.
1 個のエントリがエクスポートされました
コマンドが正しく完了しました
C:\>
ログファイルであるldfile.log(リスト3 )の中にある "gpCFileSysPath" 属性の内容をメモしておき、最初の"\\example.com"のところをgpresult結果ログに書かれたドメインコントローラ名に置き換え、それをUNCパスとしてドメインコントローラにアクセスします。
リスト3 図3のコマンドラインでできたログファイル(ldfile.log)
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=example,DC=com
changetype: add
objectClass: top
objectClass: container
objectClass: groupPolicyContainer
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
distinguishedName:
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=example,DC=com
instanceType: 4
whenCreated: 20070812185718.0Z
whenChanged: 20070815231116.0Z
displayName: Default Domain Policy
uSNCreated: 4316
uSNChanged: 16457
showInAdvancedViewOnly: TRUE
name: {31B2F340-016D-11D2-945F-00C04FB984F9}
objectGUID:: D/NRNdPBS06IV6Jr4LPCxg==
flags: 0
versionNumber: 65547
systemFlags: -1946157056
objectCategory:
CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=example,DC=com
isCriticalSystemObject: TRUE
gPCFunctionalityVersion: 2
gPCFileSysPath:
\\example.com\sysvol\example.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
gPCMachineExtensionNames:
[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}]
[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]
[{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}]
gPCUserExtensionNames:
[{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}]
その共有フォルダ(図4 )にあるgpt.iniファイル(リスト4 )を開いて、"Version=[数字]"をメモしておきます。これはグループポリシーの更新番号 にあたります。
図4 リスト3のgpCFileSysPathにある共有フォルダ、gpt.iniの拡張子は表示されていない。
リスト4 gpt.iniの内容
[General]
Version=65539
PDCエミュレータの確認
次に、ドメインコントローラ上でntdsutilコマンドを使って、PDCエミュレータをどのドメインコントローラが行っているか確認します。コマンド操作は図5 のとおりでよいでしょう。
図5 ntdsutilコマンドの実行例
C:\>ntdsutil
ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server localhost
localhost に結合しています...
ローカルでログオンしているユーザーの資格情報を使って localhost に接続しました。
server connections: quit
metadata cleanup: select operation target
select operation target: list roles for connected server
サーバー "localhost" は 5 個の役割を認識しています
スキーマ - CN=NTDS Settings,CN=CHABSV00,CN=Servers,CN=Site1,CN=Sites,CN=Configur
ation,DC=example,DC=com
ドメイン - CN=NTDS Settings,CN=CHABSV00,CN=Servers,CN=Site1,CN=Sites,CN=Configur
ation,DC=example,DC=com
PDC - CN=NTDS Settings,CN=CHABSV00,CN=Servers,CN=Site1,CN=Sites,CN=Configuration
,DC=example,DC=com
RID - CN=NTDS Settings,CN=CHABSV00,CN=Servers,CN=Site1,CN=Sites,CN=Configuration
,DC=example,DC=com
インフラストラクチャ - CN=NTDS Settings,CN=CHABSV00,CN=Servers,CN=Site1,CN=Sites
,CN=Configuration,DC=example,DC=com
select operation target: quit
metadata cleanup: quit
ntdsutil: quit
localhost から切断しています...
C:\>
このあと、先ほどの "gpCFileSysPath" 属性をもう一度確認して、最初の"\\example.com"のところをPDCエミュレータのドメインコントローラ名に置き換え、同じようにgtp.iniファイルにある "Version=[数字]" をメモします。両方の "Version=[数字]" を比べてみて内容が違っていれば、ドメインコントローラ間でのグループポリシーの複製が完了していないことになります。
グループポリシーの複製は Active Directory サイト間複製のスケジュール ( デフォルトは 3 時間ごと) で行われるので、スケジュールの内容を見直すなどの対応を取りますが、これにあてはまらない場合は、ドメインコントローラやクライアントのイベントログをチェックしたり、グループポリシーのデバッグログをレジストリで設定して、そこから細かい調査を行います。