PR


まずは「ポリシーの結果セット」
 グループ・ポリシー関連の問題を追跡する際の最初のステップは,問題の起きているクライアント上で「ポリシーの結果セット」を実行することである。ポリシーの結果セットは,どのポリシー設定がクライアントに割り当てられているかを明示するので,問題の原因を絞り込むことができる。


△ 図をクリックすると拡大されます
図4●「ポリシーの結果セット」の画面
 OSのバージョンによって使えるツールは異なる。Windows 2000の場合は,リソース・キットにある「gpresult.exe」を使う。ただし,Windows 2000のgpresult.exeは,ポリシーの結果セットの中でも限られた機能しかサポートしていない。特にセキュリティ・ポリシーについては完全な結果を出力できない。Windows XPであれば様々なツールがある。最も簡単なツールは,すべてのWindows XP Professionalに同こんされている「rsop.msc」(図4)である。

リモート管理ならGPMC
 「グループ・ポリシー管理コンソール(GPMC)」を使えば,Windows XPクライアントで実行したポリシーの結果セットのレポートをリモートで作成できる。GPMCの「グループポリシーの結果ウィザード」を使えば,ユーザーとコンピュータが処理したポリシーと,そのポリシーを配信したGPOをHTML形式のレポートで表示してくれる。

 Windows Server 2003とXPにはもっと完全なバージョンのgpresult.exeが同こんされていて,ポリシーの結果セットのレポートを生成するためのコマンド・ラインのメカニズムも提供されている。

 ポリシー設定の結果のレポートを生成して,GPOをリストアップできたら,今度は絞り込みに入る。しかしその前に,管理用テンプレートのポリシーが実際にはどのように割り当てられるかについて,いくつか理解しておく必要がある。

管理用テンプレートを理解
 前に紹介したように,Windowsコンポーネントは,コンポーネントの振る舞い制御するために,管理用テンプレートのポリシーが変更するレジストリの値を読み込んでいる。これらのポリシー設定はすべて,4つのレジストリ・サブキーのいずれかに保存されている。サブキーのうち2つはコンピュータごと,2つはユーザーごとのものである。コンピュータごとのサブキーは,HKEY_LOCAL_MACHINE\Software\Policiesと,
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
\CurrentVersion\Policiesである。ユーザーごとのサブキーは,HKEY_CURRENT_USER\Software\Policiesと,HKEY_CURRENT_USER\Software\Micrsoft\Windows
\CurrentVersion\Policiesである。

 コンピュータまたユーザーにおいて,これらのサブキーの下に値が保存されている場合,そのコンピュータまたユーザーには,何らかのポリシーが適用されている。いくつかの例外もあるが,現在のWindowsに同こんされている管理用テンプレートのポリシーの設定は,これら4つのサブキーのいずれかに,値が書き込まれる。

独自の.admもトラブルの宝庫
 グループ・ポリシーのテンプレートの実態は,拡張子が「.adm」のファイルだが,管理者が独自のadmファイルを追加することも可能である。独自のadmファイルを追加すると,紹介した4つのサブキー以外のサブキーにレジストリ値を書き込める。このようなカスタム・テンプレートを作ることを「プリファレンス(preferences)」と呼ぶ。プリファレンスは,標準のテンプレートでは変更できないレジストリ値を,グループ・ポリシーで設定する必要が出たときに便利である。

 標準のテンプレートで設定できないレジストリ値とは,グループ・ポリシーを認識しないアプリケーションの設定や,上記4つのサブキーの対象ではないWindowsのシステム設定などである。

 例えば筆者は,独自のadmファイルを作って,グループ・ポリシーによってWindowsシステムにログオンできるようにしたことがある。ログオンするためのレジストリ値は,すべてプリファレンスで設定した。しかしプリファレンスには,プリファレンスによって配布されるGPOがコンピュータやユーザーにとって不要になったとしても,設定を自動的に削除できないという問題点がある。これは「タトゥーイング(tattooing,刺青)と呼ばれ,Windows NT 4.0やWindows 9xのシステム・ポリシーでは頭痛の種だった。

プリファレンスは要注意
 プリファレンスは,グループ・ポリシーのトラブルシューティングをする上で,際限のない困難をもたらす危険性がある。プリファレンスは,GPOと一緒には削除されない。GPOを削除する前には,プリファレンスの設定を必ず「未構成」にしておく必要がある。プリファレンスを未構成にせずにGPOを削除すると,タトゥーイングが起きてしまう。

 GPEで[管理用テンプレート]を右クリックして[テンプレートの追加と削除]を呼び出したときに表示されるリストは,GPOがどのadmファイルを使っているか示したものである。

 例えば,グループ・ポリシーで設定したいレジストリ値があったとして,そのためにOS標準のテンプレート・ファイルを編集したとする。

 しかし,そのうちに登場する新しいWindowsのサービス・パックによって,標準のテンプレート・ファイルが更新されると,そこにあったプリファレンスの設定はなくなってしまう。この場合でも,既にポリシーは有効だったのだから,設定自体はGPOに残ったままである。しかし,GPEではプリファレンスは一切確認できないので,プリファレンスによる設定を解除することもできない。

 このような場合,再度admファイルを作成して,カスタム・プリファレンスを適用してやる必要がある。最善の方法は,カスタム・ポリシー設定についてはいつも個別の.admファイルを作成するようにし,OS標準のテンプレート・ファイルは編集しないことだ。

問題の起きているポリシーを探す
 問題が起きているクライアントでポリシーの結果セットを実行したら,次は問題を起こしているポリシー設定を探す番だ。ユーザーやコンピュータのGPOをすべて削除してしまうのは簡単だが,これではその場しのぎの解決にしかならない。どのポリシーが問題を起こしているのか,特定できないからだ。

 さらにこの方法は,管理用テンプレートの設定には効くが,これまで説明したようにプリファレンスの解除などには通用しない。また,セキュリティ・ポリシーの場合も,GPOを削除しただけでは消えないタトゥーイングの問題があるので,このやり方は通用しない。よって,他のツールやテクニックを使って,問題の原因を究明しなければならないのだ。

 ポリシーの結果セットを実行しても問題の原因が明らかにならない場合は,原因となり得る他のソースを絞り込む必要がある。問題が管理用テンプレートのポリシーと,セキュリティ・ポリシーのどちらに関係しているのか分からない場合でも,やれることはいくつかある。

 管理用テンプレートのポリシーは,人の目を欺くだけで,セキュリティは提供しないことを踏まえると,問題の原因を特定する最初のヒントはエラー・メッセージにある。例えば「アクセスは拒否されました」や「アクセス許可は拒否されました」というメッセージであれば,デスクトップ・ロックダウンの問題というよりもセキュリティに関連する問題であることは明らかある。逆に図1にあるようなエラー・メッセージであれば,管理用テンプレート関連の問題と考えられる。

意味不明でもツールで絞り込める
 意味不明のメッセージが表示される場合でも,ツールを使って問題を絞り込むことができる。管理用テンプレートに関連すると思われる問題を絞り込むに当たって筆者が一番気に入っているツールはSysinternals(http://www.sysinternals.com)が提供するフリーの「regmon.exe」である。

 Regmonを使えば,レジストリ・キー単位でレジストリの行動をフィルタできる。問題を起こすようなオペレーションを実行している最中にRegmonを使って,既に紹介した4つのレジストリ・サブキーの動きを追跡すれば,問題を起こしているポリシーを特定できる。


△ 図をクリックすると拡大されます
図5●レジストリ・モニタリング・ツール「regmon.exe」
 図5では,PowerPointの実行を妨げていたポリシーを,Regmonで追跡した画面である。この例は簡単すぎるし,Regmonを使わなくても原因は特定できるのだが,ポリシーの結果セットでは対処できない場合にRegmonが使えることは見て取れるだろう。

 問題がセキュリティ・ポリシーに関連していると疑われる場合は,そのポリシーを見つけて解除する必要がある。セキュリティ・ポリシーには,個別の設定を削除せずにGPOを削除するとシステムに設定が残ってしまうタトゥーイングがあるからだ。問題のあるセキュリティ設定は,明示的に無効にする必要がある。

 セキュリティ・ポリシーを全社規模で無効にするのが好ましくない場合,数台のマシンで構成された検証用のネットワークを構築するのがよい。Windowsシステムの「%windir%\security\templates」フォルダにある「setup security.inf」というセキュリティ・テンプレート・ファイルを使うと,Windowsのセキュリティ設定を初期状態に戻せる。このテンプレートを使用するには「secedit.exe」コマンドを使ってもよいし,GPEで[コンピュータの構成]−[Windowsの設定]−[セキュリティの設定]を右クリックして[ポリシーのインポート]を選択して,読み込むことでも設定できる。

 セキュリティを初期設定の状態に戻したら,アプリケーションが機能しているかどうかを再度テストし,セキュリティ・ポリシーを1つずつ割り当てながら,問題を起こしているポリシーを探す。この方法は明らかに時間がかかるので,他の方法で問題を見つけられない場合だけ,実施すべきだ。

 原則として,ポリシー設定をテストする際に,設定変更は1つずつ実施するようにして,設定を変更する度にアプリケーションの動作テストなどを実施すべきだ。この方法は,ポリシーの展開を遅らせるが,ポリシー設定のトラブルシューティングのために複数の変更を一斉に行うよりも簡単である。

テスト! テスト! テスト!
 グループ・ポリシーは多くの強力な機能を提供してくれる。しかし,GPOを実装する前に念入りにテストしないと,ユーザーの業務を妨げかねない。

 グループ・ポリシー設定を実装する前に必ずテストしよう。問題に遭遇したら,マイクロソフトが提供しているポリシーの結果セットや,SysInternalのRegmonユーティリティのようなサード・パーティ製のツールを使って,問題を追跡する負担を軽減しよう。そして何よりも重要なことは,グループ・ポリシーを設定する際に,念入りなテストを実施することである。