入念な事前検証が欠かせない
 今回のように独自の管理用テンプレートを利用する場合は,標準添付の管理用テンプレートを利用したとき以上に,念入りにテストすべきである。最大の理由は,独自のテンプレートを適用して変更したレジストリは,グループ・ポリシーの適用を解除しても元の状態に戻るとは限らないからである。

 Windowsに関する設定情報を変更する標準のグループ・ポリシーは,適用を解除すると設定情報がレジストリから削除され基本的に元に戻る仕様になっている。しかし,独自テンプレートを適用する場合は元々存在するレジストリを直接修正している。このため,もし不具合が発生して,グループ・ポリシーの適用を解除しても,その設定は解除されず問題が解決できない可能性がある。こうしたことは,絶対に避けたい。

 独自管理テンプレートのテストでは,テンプレートによってどのレジストリ・キーが変更され,様々な状況でアプリケーションにどのような影響があるかを把握しておく必要がある。テストする項目は例えば,テンプレートが変更した設定をユーザーが変更した場合にどうなるか,ユーザーがログオフや再起動した場合にどうなるか,独自テンプレートを変更されたり削除されたりした場合にクライアントの設定がどうなるか,などが挙げられる。


△ 図をクリックすると拡大されます
図4●グループ・ポリシーの検証をするときの注意点

 なお,Active Directoryでグループ・ポリシーの検証をするときは,ポリシーの更新間隔に注意したい(図4)。デフォルト設定では,更新間隔が長いため,なかなかクライアントにポリシーが反映されない。グループ・ポリシーで更新間隔を「0」分に設定しておくと,比較的早く反映されるので,検証作業をスムーズに進めることができる。ただし,更新間隔が短いとコンピュータやネットワークに負荷がかかることも考慮する必要がある。

 グループ・ポリシーは,OU(組織単位)単位で適用できるが,検証ではローカル・コンピュータだけにポリシーを適用したほうがよい。マイクロソフト管理コンソールの[ファイル]−[スナップインの追加と削除]から[グループポリシーオブジェクトエディタ]を追加するときに,[グループポリシーオブジェクト]としてデフォルトとなっている[ローカルコンピュータ]を指定する。続いて,管理用テンプレートを追加するとローカルにポリシーが適用可能になる。

 独自の管理テンプレートが,アプリケーションを問題なく管理できることを検証できたら,ようやく本番環境のActive Directoryドメインに対してテンプレートを適用する。このときは,[Active Directoryユーザーとコンピュータ]画面で対象とするOUを指定する。


△ 図をクリックすると拡大されます
図5●「WinZip」の設定を制御するポリシー

管理用テンプレートはテキストで記述
 これまでの説明で,レジストリに設定を保存するアプリケーションなら.admファイルを独自に記述することで,設定を変更できることが分かっていただけただろう。.admファイルの内容を初めて見た人は,複雑だと感じるかもしれないが,基本的な8つコンポーネントといくつかのキーワードを習得すれば,内容の解釈やテンプレートの作成ができるようになる。8つのコンポーネントとは,Comments,Strings,CLASS,CATEGORY,POLICY,PART,ITEMLIST,ACTIONLISTである(図5)。

 サンプルの管理用テンプレートを見れば,いくつかのまとまりに分かれていることが分かると思う。まず冒頭の部分では,Commentsコンポーネントで,テンプレートの説明が記述してある。各コメントの先頭にはセミコロン「;」を記述する。コメントは1行ずつにしてもよいし,コンポーネントやキーワードに続けて記述してもよい。続くCLASSコンポーネントは,グループ・ポリシー・オブジェクト(GPO)をグループ・ポリシー・エディタ・スナップインの[ユーザーの構成],[コンピュータの構成]のどちらに表示させるかを定義する。CLASSで使える値は「COMPUTER」と「USER」だけである。CLASSの値とノードは,変更が行われるレジストリ・サブキーとも関係がある。USERクラスは,HKEY_CURRENT_USER サブキー下の設定を変更し,COMPUTERクラスは,HKEY_LOCAL_MACHINE下の設定を変更する。

 「CATEGORY」以下が,グループ・ポリシーを設定する中核部分となる。CATEGORYコンポーネントは,グループ・ポリシー,グループ・ポリシー・エディタ・スナップインにGPOの設定を表示するときのノード名を記述できる。複数のCATEGORY記述をネストして,設定をより構造化することも可能である。サンプル・テンプレートでは,「デフォルト・パスの指定」「関連プログラムの指定」「ユーザー・インターフェースの指定」の3カテゴリに分かれている。

 CATEGORY の後にあるKEYNAMEは,レジストリ・サブキーへのパスを示している。この後に,具体的なポリシーを設定する記述がある。ポリシーは複数設定することができ,各ポリシーの終わりは「END POLICY」で,カテゴリの終わりは「END CATEGORY」で締めくくることになっている。

 またテンプレートの本文全体にわたって,「!!」が多くあることにも気づいただろう。これは,Stringsの参照を意味しており,テンプレートの後半にある[strings]以降の文字列を参照している。

 仮にこれを利用しないと,ポリシーに関する記述が長くなってしまい,テンプレートが読みにくくなってしまう。しかし,Stringsを利用すれば,文字列を整理でき,テンプレートの編集やトラブルシューティングのときに便利である。テンプレートの本文にあるコンポーネントやキーワードの先頭に以下のように感嘆符(!)を2つ付与して,「!!stringname」とすることで,[strings]部分に「stringname=“value”」と記述した文字列を参照させる。

GPOの設定画面を作成する
 ポリシー設定では,ユーザー・インターフェースを作成するためにPART,ITEMLIST,ACTIONLISTなどのコンポーネントを使うことができる。これによってユーザーは,テキスト・ボックス,チェック・ボックス,ドロップダウン・リスト・ボックスなど,グループ・ポリシー・エディタ・スナップイン内のGPOを編集するためのユーザー・インターフェースを利用できるようになる。関連する説明文を表示することも可能だ。

 具体的には,CHECKBOX,COMBOBOX,DROPDOWNLIST,LISTBOX,EDITTEXT,TEXT,NUMERIC,EXPLAINといったキーワードを使う。サンプルの管理用テンプレートはいろいろなパーツを使っている。テンプレートにあるこれらキーワードと,グループ・ポリシー・エデ ィタ・スナップインに表示される結果を比較すると,理解しやすい。

 例えば,ITEMLISTコンポーネントはDROPDOWNLISTと一緒に使うことで,その設定に対する有効な選択肢のリストを表示できる。サンプルの管理用テンプレートでは,PathsカテゴリにあるOpenLocationポリシー用にITEMLISTとDROPDOWNLISTを使って,デフォルト・パスを選択できるようにした例を紹介している(図3右端の画面,図5参照)。

 ほかにも,ACTIONLISTを使うと,レジストリ・サブキーの値を制御状態に応じて1つ以上定義できる。例えば,DROPDOWNLISTを使った場合,ドロップダウン・リストから選択した項目に応じて変更する一連のレジストリ・サブキー値をACTIONLISTで定義できる。

 キーワードの使い方の詳細は,開発者向けのホワイトペーパー「ImplementingRegistry-Based Group Policy」(レジストリ・ベースでのグループ・ポリシーの実装)に掲載されている。

シンプルに始めてトラブルを回避
 限られた誌面でたくさんのコンポーネントやキーワードを紹介したので,困惑している読者も多いだろう。独自の管理用ポリシーの適用は,シンプルなものから始めるのがトラブルを避けるコツだ。

 グループ・ポリシーで変更したい設定を,アプリケーションとユーザー・インターフェースに分割し,テンプレートにはGPOへの変更を1つずつ追加するといいだろう。先に追加したGPOが問題なく動作していることを確認してから,新しいGPOを開始するという流れである。変更したいレジストリ・キーや値を検索するには,Regmon(米Sysinternals社が提供するフリーウエア)などを使うとよい。