グループ ポリシー

グループ ポリシーのパフォーマンスを最適化する

Darren Mar-Elia

概要:

• モノリシック GPO と機能別 GPO
• グループ ポリシー エントリの処理方法
• GP が変更された場合の動作

よく「パフォーマンスの観点では、サイズの大きい少数の GPO を使用するべきか、サイズの小さい多数の GPO を使用するべきか」という質問を受けます。この記事では、この質問やグループ ポリシーの設計とパフォーマンスに関連するその他のトピックについて取り上げます。ただし、このような包括的な質問にはよくあることですが、

あらかじめ答えをお教えすることができます。それは、「場合によります」というものです。これはいい加減な答えに思われるかもしれませんが、ここでの目的は、グループ ポリシーの処理を支えるメカニズムを説明することです。GPO に取り組み始めたばかりなのか、既存の GPO が数百個適用された環境の最適化を考えているのかにかかわらず、皆さんがグループ ポリシーを設計する際に、適切な情報を基に判断を下すことができるようになることを目的としています。

モノリシック GPO と機能別 GPO

まず、GPO を実装するための 2 つの方法について説明します。"モノリシック" と "機能別" という言葉は、どのように GPO を設計するかを表しています。モノリシック GPO には、さまざまな領域の設定が格納されています。たとえば、モノリシック GPO は、管理用テンプレート、Internet Explorer のメンテナンス、ソフトウェア インストール ポリシーなどからの設定を含みます。つまり、これらすべての設定が 1 つの GPO に格納されています。対照的に、機能別 GPO は通常 1 つのことしか行いません。たとえば、ある機能別 GPO では、ソフトウェアのインストールのみを行ったり、セキュリティ設定を適用したりします。これまで、たった 1 つのポリシー設定のみが格納された機能別 GPO を目にしたこともあります。ただし、おそらくこれはきわめて特殊なケースです。図 1 は、それぞれの方法の長所と短所を示しています。

Figure 1 モノリシック GPO と機能別 GPO の比較

おわかりのように、あらゆる状況でモノリシック GPO と機能別 GPO のどちらが適切な方法であるかを明言することはできません。実際の環境では、おそらく両方が必要になるでしょう。たとえば、ドメイン全体のセキュリティ ポリシーを作成するときは、機能別 GPO の方が適しているかもしれません。セキュリティ設定のみが含まれた 1 つの GPO を用意することで、この GPO の制御をセキュリティ管理者に委任しやすくなり、他のユーザーがこの GPO にアクセスできないようにすることができます。同様に、GP の管理を OU 管理者に委任する場合は、OU ごとにモノリシック GPO を作成することで、各 OU 管理者がそれぞれのポリシー設定をすべて 1 か所から管理できるようになります。これにより、OU 管理者の作業の複雑さを軽減し、特定の OU のユーザーとコンピュータ用に作成する GPO の数を抑えることができます。

このような設計上の方針は、グループ ポリシーの処理のパフォーマンスにどのように影響するのでしょうか。また、パフォーマンスの影響を最小限に抑えることができる GP の設計を賢明に判断するにはどうすればよいでしょうか。グループ ポリシー インフラストラクチャのパフォーマンスを最大限に高めるには、まず、グループ ポリシーの処理の内部動作を理解する必要があります。

グループ ポリシーの処理を理解する

グループ ポリシーの処理は、Windows® および Active Directory® インフラストラクチャのさまざまな機能に関する一連の複雑なやり取りです。大まかには、グループ ポリシーの処理は 2 つに分けることができます。1 つはコアと呼ばれる、グループ ポリシー インフラストラクチャの処理です。このフェーズでは、Windows グループ ポリシー クライアントが最も近いドメイン コントローラに、DC へのリンクの速度、Active Directory 階層内でのこのクライアントの場所 (つまり、このクライアントが属するサイト、ドメイン、および OU)、およびコンピュータまたは現在ログオンしているユーザーに適用される GPO を照会します (この場合、このクライアントは Active Directory ドメインに参加しているサーバーまたはワークステーションであることに注意してください)。GPO の一覧が作成されたら、次のフェーズであるクライアント側拡張機能 (CSE) の処理に移ります。CSE のフェーズでは、登録されている各 CSE が、自身の領域の設定を実装している GPO を処理します。たとえば、レジストリまたは管理用テンプレートの CSE は常に最初に実行され、特定のコンピュータまたはユーザーに適用されるすべての GPO と、レジストリ ポリシーを実装しているすべての GPO を処理します。

この後の箇条書きの部分では、クライアントとドメイン コントローラとの間のネットワーク通信など、グループ ポリシーの処理サイクルで実行される各手順について詳しく説明します。覚えておく必要があることは、グループ ポリシーがコンピュータとユーザーの両方に適用されるということです。したがって、グループ ポリシーをバックグラウンドで更新するときなど、ポリシーが処理されるたびに、以下に示す処理サイクルが、コンピュータと特定のシステムに現在ログオンしているユーザー アカウントの両方に対して繰り返されます。これは、コンピュータとユーザーに適用される一連のポリシーがそれぞれ異なるためです。ポリシーの適用動作が発生すると、実際には Windows はコンピュータとユーザーの処理サイクルを同時に実行します。各サイクルはグループ ポリシー エンジンのプロセス内の別々のスレッドで実行されます (Windows 2000、Windows XP、および Windows Server® 2003 の場合は Winlogon プロセス、Windows Vista® と Windows Server 2008 の場合はグループ ポリシー クライアント サービスです)。

GP の処理は、以下の 6 つの手順から構成されています。

1. クライアントが、インターネット制御メッセージ プロトコル (ICMP) を使用してサイト内のドメイン コントローラへの低速リンクの検出を実行し、リンクの速度を特定します。Windows Vista では、低速リンクの検出に ICMP ではなくネットワーク位置認識 (NLA) サービスが使用されます。
2. クライアントは CSE の状態に関する情報をローカル レジストリから読み取り、最後に処理された GPO を特定します。
3. クライアントが LDAP を使用して、Active Directory 階層内の同じ場所にある各コンテナ オブジェクトの gpLink 属性を検索します。この検索は、OU レベル (入れ子になっているすべての OU を含む)、ドメイン レベル、Active Directory サイト レベルの順に行います。この検索結果から、実行する処理があるかどうかを評価する GPO の一覧を作成します。
4. 次に、Active Directory 内の各 GPO を検索し、その GPO の処理に必要なアクセス許可がクライアント (ユーザーまたはコンピュータ) に与えられているかどうかを確認します。バージョン番号、SYSVOL に格納されている GPO のグループ ポリシー テンプレート (GPT) 部分へのパス、およびどの CSE が GPO に実装されているかについても評価されます。
5. 次に、クライアントはサーバー メッセージ ブロック (SMB) プロトコルを使用して GPT の内容を読み取り、gpt.ini ファイルから GPO のバージョン番号を取得します。グループ ポリシー コンテナ (GPC) と GPT のバージョン番号は、前回の処理サイクルから GPO が変更されていないかどうかを確認するために使用される要素の 1 つです。
6. 各 CSE が、HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions に登録されている順番で実行され、前回の処理サイクルから GPO が変更されている (コア処理中に確認されます) 場合は、その CSE が実装された GPO を処理します。各 CSE は、更新中に可能であれば、ユーザー ポリシーの結果セット (RSOP) のデータも Windows Management Instrumentation (WMI) に記録します。

このプロセスを細かく分析し、パフォーマンスへの影響を確認しましょう。まず気を付ける必要があるのは、フォアグラウンドの処理とバックグラウンドの処理には違いがあるということです。フォアグラウンドの処理は、コンピュータの場合はシステムの再起動中に、ユーザーの場合はログオン中に発生します。バックグラウンドの更新は、ワークステーションとメンバ サーバーの場合は、既定の 90 分に無作為に時間 (最大 30 分) を加算した間隔で発生します。ドメイン コントローラの場合は、既定では 5 分おきにバックグラウンドの更新が発生します。Windows Vista では、NLA ベースの更新が発生する場合もあります。これは、基本的にはバックグラウンド更新イベントであり、ドメイン コントローラにアクセスできなかったこと (バックグラウンド更新が発生したときにクライアントがオフラインであった場合など) が原因でグループ ポリシーの処理が失敗した場合に発生します。なぜこれらの処理を区別することが重要なのでしょうか。主な理由は、特定の CSE (ソフトウェアのインストールやフォルダのリダイレクトを実行する CSE など) がバックグラウンド更新中に実行されないためです。同様に、バックグラウンド更新中は、ログオンとログオフを実行するスクリプトや、起動とシャットダウンを実行するスクリプトも実行されません。

同様に、このプロセスの手順 1. では、低速リンクの検出処理について説明しました。Windows Vista よりも前のバージョンのシステムでは、クライアントが ICMP を使用してドメイン コントローラへの ping を実行することで、そのドメイン コントローラが利用可能であるかどうか、およびリンクの速度を特定します。計算されたリンクの速度が特定のしきい値 (既定では 500 Kb/s) を下回る場合は、リンクが低速であると見なされます。この場合も特定の CSE (ソフトウェアのインストール、フォルダのリダイレクト、Internet Explorer のメンテナンスなど) が実行されません。これらの条件はすべて、パフォーマンスだけでなく、ポリシーが予期されたとおりに適用されるかどうかにも影響する可能性があります。

おそらく、パフォーマンスに最も影響を与えるポリシー処理サイクルの側面は、コンピュータまたはユーザーに適用する GPO が変更されているかどうかを特定するロジックです。グループ ポリシー エンジンには、前回 GP が処理されてからコンピュータまたはユーザーに変更が加えられていない場合は処理を実行しないようにする最適化機能が組み込まれています。言うまでもなく、この機能は、特に変更の少ない GP 環境でクライアントがポリシーを処理する際にかかる時間に大きく影響を与える可能性があります。次は、変更が発生する状況について詳しく説明します。

グループ ポリシーの変更が発生する状況

では、グループ ポリシーの処理が必要になる変更とは、どのような変更なのでしょうか。さまざまな状況がありますが、最もわかりやすいのは、GPO を変更した場合に、その GPO を処理するクライアントが変更を検出し、その GPO を再処理するという状況です。クライアントは、どのようにして GPO が変更されていることを認識するのでしょうか。これは、GPO のバージョン番号を基に、クライアント内で検証されます。

GPO は、Active Directory に格納されている GPC (各ドメイン内の CN=Policies, CN=System コンテナの下) と、Policies フォルダの SYSVOL に格納されている GPT という 2 つの要素から構成されます。この GPO の各要素には、バージョン番号が含まれています。GPC のバージョン番号は GPC オブジェクトの versionNumber 属性に格納されています。また、GPT のバージョン番号は特定の GPT のルートにある gpt.ini ファイル内に格納されています。また、クライアントは、自身が (コンピュータごとおよびユーザーごとに) 処理した GPO のバージョン番号をレジストリ内に記録しています。コンピュータのバージョン情報は各クライアントの HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History に、ユーザーのバージョン情報は各クライアントの HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<ユーザーの SID> に格納されています。

グループ ポリシーの処理が発生すると、この 2 つの要素のうちいずれかが、コンピュータまたはユーザーに適用されるすべての GPO のバージョン番号を確認し、レジストリに格納されている、前回のサイクルで処理されたバージョン番号と比較します。現在の GPO のバージョン番号が (大きいか小さいかにかかわらず) 異なっている場合、その GPO は現在の処理サイクル中に処理されます。異なっていない場合は、以下の変更がない限り GPO は処理されません。GPO の再処理条件となるその他の変更を以下に示します。

• ユーザーまたはコンピュータに適用される GPO の一覧に変更があった (GPO が追加または削除された)
• ユーザーまたはコンピュータのセキュリティ グループのメンバシップに変更があった
• GPO にリンクされている WMI フィルタに変更があった (WMI フィルタが追加または削除された)

上記の変更があった場合、クライアントは処理サイクル中にポリシーを再処理します。ただし、この処理では、パフォーマンスに大きな影響を与える可能性がある、いくつかの細かい点に注意する必要があります。特定の CSE に適用される GPO が 10 個のうち 1 つでも変更されれば、その CSE に適用されるすべての GPO を処理する必要があります。処理は CSE 単位で実行されることに注意してください。ただし、CSE は、処理を制御する優先順位に従ってポリシーを処理する必要があります (ローカルの GPO、サイトにリンクされている GPO、ドメインにリンクされている GPO、OU にリンクされている GPO の順)。この要件を踏まえて、たとえば、あるユーザーに適用される GPO が 10 個あり、各 GPO が Active Directory 階層の異なるレベルにリンクされているとします。また、この 10 個の GPO にはそれぞれ、管理用テンプレートのポリシー設定が実装されているとします。ここで、管理者が管理用テンプレートのポリシー設定を新たに追加して、ドメインにリンクされている GPO を変更したとします。その後、コンピュータまたはユーザーがポリシーを処理し、変更された GPO のバージョン番号が前回処理されたときよりも大きくなっていること、つまり GPO を再処理する必要があることを認識します。しかし、GP の処理の優先順位によって決められた順序を維持するために、すべての GPO に適用される管理用テンプレートの設定をすべて処理する必要があります。このように、1 つの GPO を簡単に変更しただけでも、そのクライアントのパフォーマンスに大きく影響する可能性があります。

モノリシック GPO と機能別 GPO のパフォーマンスを比較する

ここまでは処理サイクルについて、およびグループ ポリシー環境への変更が処理に与える影響について説明してきましたが、モノリシック GPO と機能別 GPO について、およびこれらがパフォーマンスに与える影響についての説明に戻りましょう。

モノリシック GPO は、グループ ポリシーのバージョン管理のしくみが原因で、パフォーマンス上の隠れた欠点を抱える可能性があります。この理由は必ずしも明確ではありませんが、グループ ポリシーの処理では、CSE 単位のバージョン管理という概念がないことに対処する必要があります。あるユーザーに適用される GPO が 3 つあるとします。これらはモノリシック GPO で、それぞれ複数のポリシー領域を実装しています。たとえば、各 GPO に、管理用テンプレート ポリシー、ソフトウェアのインストール ポリシー、およびフォルダのリダイレクト ポリシーが実装されているとします。ここで、管理者がこの 3 つの GPO のうちの 1 つで、管理用テンプレート ポリシーに変更を加えたとします。この変更のために、バージョン番号が変更されます。その後、ユーザーがグループ ポリシーを処理すると、管理用テンプレート CSE が起動し、1 つの GPO が変更されていることを検出するため、これら 3 つの GPO が再処理されます。

ソフトウェアのインストール CSE とフォルダのリダイレクト CSE が実行されるときも GPO のバージョン番号が確認され、1 つの GPO でバージョン番号が新しくなっていることが検出されます。ただし、バージョン番号からは GPO のどのポリシー領域が変更されているかわからないため、念のため 3 つの GPO がすべて処理されます。結果として、モノリシック GPO の実装では、あるポリシーの 1 つの領域が変更されると、別の領域でも処理が実行されます。

確かに、ソフトウェアのインストール ポリシーやフォルダのリダイレクト ポリシーの CSE は、たとえば、アプリケーションが既にインストールされていて再インストールされることがない場合、実際には何の処理も実行しない可能性があります。しかし、どの CSE でもこのような状態になる可能性があるため、モノリシック GPO を設計するときは、この点を考慮する必要があります。頻繁に変更されるポリシー領域がある場合は、そのポリシー領域が実装された GPO を他のポリシー領域から分離しておくことを検討してください。

機能別 GPO の場合、パフォーマンスに関する考慮事項はより明確です。ユーザーまたはコンピュータごとに複数の GPO が存在する場合 (通常、機能別 GPO では特定のポリシー設定を実装するためにより多くの GPO が必要になるため)、グループ ポリシーの処理のコア フェーズ中に、これらの GPO を列挙するためにグループ ポリシー エンジンが費やす時間が増加することになります。ただし、次のセクションで説明するように、このことがパフォーマンスに大きく影響するとは限りません。

グループ ポリシーのパフォーマンスを計測する

結局、グループ ポリシー インフラストラクチャのパフォーマンスを適切に判断するには、実際の環境でグループ ポリシーのパフォーマンスを計測する必要があります。グループ ポリシーのパフォーマンスをモデル化または予測することは、特定の処理サイクルに影響する可能性がある要素の多さを考えると、ほぼ不可能です。このため、GP の処理のパフォーマンスに問題があるかどうかを確認する最も良い方法は、実際に計測を行うことです。パフォーマンスが低いと判断できる要因は何でしょうか。システムのユーザー エクスペリエンスにグループ ポリシーの処理が影響する場合、パフォーマンスが低いと言えます。この基準は組織によって異なりますが、重要なのは問題があることを認識することです。

では、特定のグループ ポリシーの処理サイクルにかかった時間はどのように計測するのでしょうか。この場合も、答えは単純ではありません。Windows Vista または Windows Server 2008 を実行している場合は、イベント ビューアの操作ログを利用できます。イベント ビューアで参照できるグループ ポリシーの操作ログは、"アプリケーションとサービス ログ\Microsoft\Windows\GroupPolicy\Operational" の下にあり、各処理フェーズに要した時間も含め、グループ ポリシーの処理サイクルで実行される各手順の詳細な計測情報を提供しています (図 2 参照)。

図 2** ポリシーの処理時間を示すグループ ポリシーの操作ログのイベント **(画像を拡大するには、ここをクリックします)

ただし、Windows Vista または Windows Server 2008 環境で作業を行っていない場合、ポリシーの処理にかかる時間を計測するメカニズムは、これほど直接的ではありません。この場合は、詳細な userenv ログを有効にし (support.microsoft.com/kb/221833 で公開されているサポート技術情報の記事を参照)、そのファイルに記録されている特定の処理サイクルのタイムスタンプを確認するか、クライアントのレジストリに格納されている、ポリシーの処理の開始時刻と終了時刻を示す値を使用します。コンピュータの場合、これらの値は次の場所に格納されています。

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

ユーザーの場合、これらの値は次の場所に格納されています。

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

これらの値は FILETIME 形式で保存されているため、通常の日付と時刻の形式に変換する必要があります。また、私が作成した無償のユーティリティ GPTime.exe (gpoguy.com/tools.htm#GP_Time_Utility からダウンロードできます) を使用して、同じ情報を取得することもできます。

Windows Vista または Windows Server 2008 環境がなくても、userenv ログを利用できる場合は、各ポリシー処理サイクルに費やされた時間についての有用な情報を得ることができます。図 3 は、グループ ポリシーの処理のコア フェーズ部分を示す userenv ログの一部です。

図 3** userenv ログの一部 **(画像を拡大するには、ここをクリックします)

このログ ファイルの各行にタイムスタンプが含まれています。グループ ポリシー処理サイクルのコア部分は、"ProcessGPOs: Starting user Group Policy (Background) processing ..." のようなイベント以降の部分が該当します。処理サイクルの CSE 部分は、"ProcessGPOs: Processing extension Registry" という行以降の部分が該当します。このログと、ログ内のタイムスタンプを使用して、ポリシー サイクルの各部分に要した時間を特定することができます。

大まかなパフォーマンスを把握する

十分に時間をかけて userenv ログ ファイルを確認すると、パターンを見つけられるようになります。ポリシーの処理にかかる時間を予測することはできませんが、特定の処理サイクルのどの部分に時間がかかるかが大まかにわかるようになります。たとえば、ポリシー処理イベント中に、ポリシーの変更が処理され、その変更によって CSE の処理が発生する場合、GP の処理のコア部分にかかる時間は、CSE 部分に比べて、通常かなり短くなります。

これはほとんどのポリシー領域に当てはまります。その理由は、ほとんどの CSE は処理のコア部分よりも時間がかかる作業を実行する必要があるためです。CSE の操作で最も時間がかかるのは Active Directory と SYSVOL の照会です。たとえば、コア処理に必要な時間と、Microsoft® Office のインストールを実行するソフトウェアのインストール CSE の処理に必要な時間は比べ物になりません。ただし、前回のサイクルから変更が発生していない、通常のポリシーのバックグラウンド更新の場合、この処理サイクルのコア部分にかかる時間と CSE 部分にかかる時間はほぼ同じです。例外は、レジストリ ポリシーの処理です。この処理は、特定のユーザーまたはコンピュータに適用するレジストリ ポリシー設定が数十個または数百個ない限り、きわめて短時間で実行されます。

また、使用されていないという理由で、GPO の中でコンピュータまたはユーザーのいずれかを対象としたポリシーを無効にしても、ポリシーの処理のパフォーマンスにはほとんど影響がありません。いずれかを対象としたポリシーが使用されていない場合に発生するオーバーヘッドは、このことを確認するために実行される Active Directory の照会処理のみですが、ポリシーが無効になっていることを確認するには、それらのポリシーを適用するように実装されている CSE があるかどうかを確認するために実行されるものと同じ照会処理を実行する必要があります。一方を対象としたポリシーを無効にしても、影響はほとんどありません。

最適な GP のパフォーマンスを得るための設計に関する推奨事項

これまではグループ ポリシーの処理のパフォーマンスに関するさまざまな要素について説明してきましたが、ここではパフォーマンスに直接影響する可能性がある、設計に関する推奨事項を一部紹介します。まとめると、重要なポイントは次の 4 つです。

1. GPO を頻繁に変更する場合は、前述のとおり、1 つの CSE を変更しただけですべての CSE の処理に影響が出る可能性があることを考慮してください。これを回避するには、たとえば、レジストリ ポリシーを頻繁に変更する場合は、レジストリ ポリシーを機能別 GPO (レジストリ ポリシーのみを処理する GPO) に実装するとよいでしょう。これにより、変更があっても他の CSE が処理されずに済みます。
2. GPO の数について考えるときは、ポリシーの処理は変更があった場合のみ実行され、ソフトウェアのインストール、フォルダのリダイレクト、多数のレジストリ ポリシーの処理、サイズの大きなファイルまたはレジストリ ツリーへのアクセス許可の設定など、"負荷の高い" CSE に最も時間がかかることを考慮してください。多くの場合、コア フェーズで処理する GPO の一覧を Active Directory に照会して取得する作業は、処理サイクルの中で最も時間のかからない部分です。したがって、特定のユーザーに適用されるがレジストリ ポリシーをほとんど変更しない、変更頻度の少ない 30 個の GPO は、定期的に負荷の高い CSE を実行する 5 個の GPO よりも処理時間が短くなる可能性があります。これは、後者の GPO は頻繁に変更されるためです。
3. ポリシーの処理のパフォーマンスが明らかに低下する動作は回避してください。たとえば、GPO が変更されていなくても CSE を強制的に実行するポリシーを設定 ("コンピュータの構成\管理用テンプレート\システム\グループ ポリシー" の下) することができますが、この設定を行うと、どのサイクルでもポリシーの処理かかる時間が長くなります。
4. Windows XP と Windows Vista の高速ログオンの最適化を無効にした場合のトレードオフを考慮してください (これを行うには、"コンピュータの構成\管理用テンプレート\システム\ログオン\コンピュータの起動およびログオンで常にネットワークを待つ" のポリシーを有効にします)。このポリシーを有効にすると、フォアグラウンド処理が非同期処理から同期処理に切り替わります。つまり、ユーザーがコンピュータとデスクトップを制御できるようになる前に、コンピュータとユーザーのポリシーを実行する必要があります。ただし、ソフトウェアのインストールおよびフォルダのリダイレクト ポリシーを有効にする際に複数回の再起動やログオンが必要になるという問題を回避できるため、便利な機能として使用できる場合もあります。

まとめ

グループ ポリシーの処理のパフォーマンスを正確に求めることはできませんが、大まかな情報を設計プロセスで参考にして、パフォーマンスの問題を緩和することができます。

処理サイクルのしくみと、どの部分に時間がかかるかを理解することは、パフォーマンスの問題を突き止めるうえで非常に役立ちます。Windows Vista または Windows Server 2008 の操作ログ (以前のバージョンの Windows では userenv ログ) を使用すると、処理サイクルの計測情報を取得できます。CSE の処理が流動的であることと、CSE がポリシーの変更を検出する基準を考慮してください。また、変更が多い動的な環境では、モノリシック GPO よりも機能別 GPO の方が適していることも考慮してください。しかし肝心なのは、グループ ポリシーが Windows 環境の管理を支援するためのテクノロジであるということです。ビジネス ニーズを基にグループ ポリシーの設計を決めることが非常に重要です。その逆ではありません。この記事で説明した、パフォーマンスに影響するいくつかの動作を覚えておくことは、この目的を達成するうえで役立つでしょう。

Darren Mar-Elia は Microsoft グループ ポリシーの MVP です。グループ ポリシーに関する人気サイト (www.gpoguy.com) の制作者であり、『Microsoft Windows Group Policy Guide』(Microsoft Press、2005) の共著者でもあります。また、SDM Software Inc. の創立者で CTO を務めています。彼の連絡先は Darren@gpoguy.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.