|
まずは「ポリシーの結果セット」
リモート管理ならGPMC Windows Server 2003とXPにはもっと完全なバージョンのgpresult.exeが同こんされていて，ポリシーの結果セットのレポートを生成するためのコマンド・ラインのメカニズムも提供されている。 ポリシー設定の結果のレポートを生成して，GPOをリストアップできたら，今度は絞り込みに入る。しかしその前に，管理用テンプレートのポリシーが実際にはどのように割り当てられるかについて，いくつか理解しておく必要がある。
管理用テンプレートを理解 コンピュータまたユーザーにおいて，これらのサブキーの下に値が保存されている場合，そのコンピュータまたユーザーには，何らかのポリシーが適用されている。いくつかの例外もあるが，現在のWindowsに同こんされている管理用テンプレートのポリシーの設定は，これら4つのサブキーのいずれかに，値が書き込まれる。
独自の.admもトラブルの宝庫 標準のテンプレートで設定できないレジストリ値とは，グループ・ポリシーを認識しないアプリケーションの設定や，上記4つのサブキーの対象ではないWindowsのシステム設定などである。 例えば筆者は，独自のadmファイルを作って，グループ・ポリシーによってWindowsシステムにログオンできるようにしたことがある。ログオンするためのレジストリ値は，すべてプリファレンスで設定した。しかしプリファレンスには，プリファレンスによって配布されるGPOがコンピュータやユーザーにとって不要になったとしても，設定を自動的に削除できないという問題点がある。これは「タトゥーイング（tattooing，刺青）と呼ばれ，Windows NT 4.0やWindows 9xのシステム・ポリシーでは頭痛の種だった。
プリファレンスは要注意 GPEで［管理用テンプレート］を右クリックして［テンプレートの追加と削除］を呼び出したときに表示されるリストは，GPOがどのadmファイルを使っているか示したものである。 例えば，グループ・ポリシーで設定したいレジストリ値があったとして，そのためにOS標準のテンプレート・ファイルを編集したとする。 しかし，そのうちに登場する新しいWindowsのサービス・パックによって，標準のテンプレート・ファイルが更新されると，そこにあったプリファレンスの設定はなくなってしまう。この場合でも，既にポリシーは有効だったのだから，設定自体はGPOに残ったままである。しかし，GPEではプリファレンスは一切確認できないので，プリファレンスによる設定を解除することもできない。 このような場合，再度admファイルを作成して，カスタム・プリファレンスを適用してやる必要がある。最善の方法は，カスタム・ポリシー設定についてはいつも個別の.admファイルを作成するようにし，OS標準のテンプレート・ファイルは編集しないことだ。
問題の起きているポリシーを探す さらにこの方法は，管理用テンプレートの設定には効くが，これまで説明したようにプリファレンスの解除などには通用しない。また，セキュリティ・ポリシーの場合も，GPOを削除しただけでは消えないタトゥーイングの問題があるので，このやり方は通用しない。よって，他のツールやテクニックを使って，問題の原因を究明しなければならないのだ。 ポリシーの結果セットを実行しても問題の原因が明らかにならない場合は，原因となり得る他のソースを絞り込む必要がある。問題が管理用テンプレートのポリシーと，セキュリティ・ポリシーのどちらに関係しているのか分からない場合でも，やれることはいくつかある。 管理用テンプレートのポリシーは，人の目を欺くだけで，セキュリティは提供しないことを踏まえると，問題の原因を特定する最初のヒントはエラー・メッセージにある。例えば「アクセスは拒否されました」や「アクセス許可は拒否されました」というメッセージであれば，デスクトップ・ロックダウンの問題というよりもセキュリティに関連する問題であることは明らかある。逆に図1にあるようなエラー・メッセージであれば，管理用テンプレート関連の問題と考えられる。
意味不明でもツールで絞り込める Regmonを使えば，レジストリ・キー単位でレジストリの行動をフィルタできる。問題を起こすようなオペレーションを実行している最中にRegmonを使って，既に紹介した4つのレジストリ・サブキーの動きを追跡すれば，問題を起こしているポリシーを特定できる。
問題がセキュリティ・ポリシーに関連していると疑われる場合は，そのポリシーを見つけて解除する必要がある。セキュリティ・ポリシーには，個別の設定を削除せずにGPOを削除するとシステムに設定が残ってしまうタトゥーイングがあるからだ。問題のあるセキュリティ設定は，明示的に無効にする必要がある。 セキュリティ・ポリシーを全社規模で無効にするのが好ましくない場合，数台のマシンで構成された検証用のネットワークを構築するのがよい。Windowsシステムの「%windir%\security\templates」フォルダにある「setup security.inf」というセキュリティ・テンプレート・ファイルを使うと，Windowsのセキュリティ設定を初期状態に戻せる。このテンプレートを使用するには「secedit.exe」コマンドを使ってもよいし，GPEで［コンピュータの構成］−［Windowsの設定］−［セキュリティの設定］を右クリックして［ポリシーのインポート］を選択して，読み込むことでも設定できる。 セキュリティを初期設定の状態に戻したら，アプリケーションが機能しているかどうかを再度テストし，セキュリティ・ポリシーを1つずつ割り当てながら，問題を起こしているポリシーを探す。この方法は明らかに時間がかかるので，他の方法で問題を見つけられない場合だけ，実施すべきだ。 原則として，ポリシー設定をテストする際に，設定変更は1つずつ実施するようにして，設定を変更する度にアプリケーションの動作テストなどを実施すべきだ。この方法は，ポリシーの展開を遅らせるが，ポリシー設定のトラブルシューティングのために複数の変更を一斉に行うよりも簡単である。
テスト！ テスト！ テスト！ グループ・ポリシー設定を実装する前に必ずテストしよう。問題に遭遇したら，マイクロソフトが提供しているポリシーの結果セットや，SysInternalのRegmonユーティリティのようなサード・パーティ製のツールを使って，問題を追跡する負担を軽減しよう。そして何よりも重要なことは，グループ・ポリシーを設定する際に，念入りなテストを実施することである。 |
