 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Windows の管理

今月は Mark Russinovich が Windows Vista カーネルの中に入って、より正確な CPU 時間の使用状況を知ることができるスレッドとプロセスの新しいパフォーマンス測定アルゴリズムを説明します。ウィルス対策やコンテンツのインデックス作成などのバックグラウンド タスクを効率よく管理することによって、よりシームレスな再生を提供するマルチメディア クラス スケジューラ サービスについても説明してくれます。

さらに今月は、Active Directory 委任機能についてと Windows Vista のグループ ポリシー テンプレートをいっそう活用するための情報についても調べます。もちろん今月は、連載コラムの「The Cable Guy」、「Hey, Scripting Guy!」、「Windows 秘話」などがすべて揃っています。
特集
Windows の管理 Windows Vista カーネルの内部 : 第 1 部

Windows Vista では、OS カーネルの変更によって、メモリ管理から信頼性、さらにセキュリティに至るまでの数多くの分野に進歩がもたらされました。このシリーズの幕開けに、カーネルがプロセス、スレッド、および I/O の分野においてどのように改善をもたらすかについて見ていきます。

Mark Russinovich Active Directory で権限を委任する

Active Directory で委任機能を実装することにより、セキュリティを強化し、管理タスクを簡略化することができます。この手順は、それほど難しいものではありません。ここでは、多少の変更を加えるだけで、ほとんどの IT インフラストラクチャに応用できるシンプルな委任モデルをいくつか紹介します。

Joel Yoker、Rob Campbell Windows Vista の新しいグループ ポリシー テンプレートを掘り下げる

Windows Vista は、グループ ポリシー テンプレートに重要な変化をもたらします。ここでは、ADMX と呼ばれる新しい書式について知っておくべきことのすべてと、これらの変更によってシステム構成の管理がどのように向上するかについて見ていきます。

Darren Mar-Elia グループ ポリシーのトラブルシューティング ガイド

グループ ポリシー問題の解明は難しいプロセスですが、グループ ポリシーがどのように機能し、問題がどこで発生するかを理解すると、作業が容易になります。この概要は、グループ ポリシーに関する問題を、専門家のようにトラブルシューティングするのに役立ちます。

Derek Melber MOM を使った Active Directory の監視

Microsoft Operations Manager 2005 の管理パックでは、IT インフラストラクチャをいっそう効果的に監視できます。この記事では、Active Directory 環境の状態、セキュリティ、信頼性を監視するうえで、5 つの MOM 管理パックがどのように役立つかについて説明します。

John Hann セキュリティ環境でのゲーム プレイ

会社で仕事をしているときでも家でゲームに熱中しているときでも、制限付きユーザーとして実行することには、セキュリティの面で多くのメリットがあります。しかし、一部のゲームは管理者として実行する必要があります。ここでは、一般的な問題とその解決方法について見ていきます。

Matt Clapham
コラム
編集者から

縁の下の機能向上

Joshua Trupin ツールボックス

IT プロのための新製品

Greg Steen SQL に関する Q&A

データベースのサイズ、ミラーリング、マーク付きトランザクション、その他

Nancy Michell 編 ユーティリティ スポットライト

グループ ポリシー インベントリ

Greg Steen The Cable Guy

Windows での QoS のサポート

Joseph Davies 		Windows PowerShell

1 行ずつスクリプトを作成する

Don Jones Hey, Scripting Guy!

車を追いかけるのと、XML を追求するのと

Microsoft Scripting Guys セキュリティ ウォッチ

EFS を展開する : 第 1 部

John Morello デスクトップ ファイル

Windows PE を拡張する

Wes Miller フィールド ノート

機能しない理由

R'ykandar Korra'ti Windows 秘話

功罪混合

Raymond Chen


 Windows の管理: Windows Vista カーネルの内部 : 第 1 部
Windows の管理 Mark Russinovich

Windows Vista カーネルの内部 : 第 1 部
概要:
  • スレッドの優先順位とスケジュール
  • ファイルベースのシンボリック リンク
  • I/O 操作を取り消す

これは Windows Vista カーネルの新機能シリーズの最初の部分です。この記事では、プロセスとスレッド、および I/O の分野での変更について見ていきます。今後の記事では、メモリ管理、起動と停止、信頼性と回復、およびセキュリティについて見ていきます。
この記事は、Windows Vista™ カーネルへの変更のみを対象としており、特に、Ntoskrnl.exe およびそれに密接に関連づけられているコンポーネントに注目しています。Windows Vista では、他にも多くの大幅な変更が行われていますが、正規のカーネルの範疇に収まらないため、ここでの対象から除外されていることを覚えておいてください。このような変更には、シェル (統合されたデスクトップ検索など)、ネットワーク (新しい IPv6 スタックや双方向ファイアウォールなど)、次世代グラフィック モデル (Aero™ Glass、Windows® Presentation Foundation、デスクトップ ウィンドウ マネージャ、新しいグラフィック ドライバ モデルなど) の改善などが含まれます。また、ここで触れられていないものに、新しい Windows ユーザー モードおよびカーネル モードのドライバ フレームワーク (UMDF および KMDF) があります。これらは以前のバージョンの Windows にバックレベル インストールが可能であるために、対象から除外されています。

CPU サイクル カウント
Windows Vista では、プロセスとスレッドの分野に数多くの改善が含まれています。これらの改善には、より公平な CPU の割り当てを実現する CPU サイクル カウンタの使用や、メディア アプリケーションがエラーのない再生を実現するための新しいマルチメディア クラス スケジューラ サービス (MMCSS) などがあります。
Windows NT® から Windows Vista に至るまでのすべてのバージョンでは、間隔タイマ中断ルーチンをプログラミングし、ハードウェア プラットフォームに応じて約 10 ms または 15 ms (ミリ秒) の間隔でこのルーチンを実行します。このルーチンでは、ルーチンによって中断されたスレッドを確認し、そのスレッドがその期間全体にわたって実行されたかのように、スレッドの CPU 使用率統計を更新します。ただし実際には、このスレッドは期間の終了直前に開始された場合もあります。さらに、スレッドは技術的には CPU に割り当てられていても、ハードウェアとソフトウェアの中断ルーチンが代わりに実行されたために、実行されなかった場合もあります。
スレッドやプロセスの CPU 使用率を報告する診断ツールではクロックベースの時間計算でも支障がないかもしれませんが、スレッド スケジューラがこの方法を使用すると、不公平に CPU が割り当てられる場合があります。既定では、クライアント バージョンの Windows では、スレッドは 2 クロック目盛 (フォアグラウンドでは 6) までの実行が許可されています。ただし、システムでのスレッドの動作や他のアクティビティによって、スレッドは実質的に CPU 実行時間をまったく得られない場合も、6 目盛 (フォアグラウンドでは 18) まで得られる場合もあります。
図 1 は、同じ優先順位を持つ 2 つのスレッドの実行準備が同時に完了した場合に発生することのある不公平な割り当てを示しています。スレッド A は、次のタイム スライス期間の終了時まで実行されます。期間が終了すると、スケジューラはスレッド A が期間全体を通して実行されたので、スレッド A の順番が完了したものと見なします。また、不公平ながら、スレッド A にはその順番の中で発生した中断時間も計算に含められます。次の期間が始まると、スケジューラはスレッド B をスレッド A の引き継ぎとして選択し、期間全体にわたって実行します。
図 1 不公平なスレッドのスケジュール
図 1 不公平なスレッドのスケジュール
Windows Vista では、スケジューラは最新のプロセッサのサイクル カウンタ レジスタを使用して、スレッドが実行する CPU サイクル数を正確に追跡します。1 クロック期間中に CPU が実行できるサイクル数を見積もることで、CPU の使用をさらに正確に割り当てることができます。さらに、Windows Vista のスケジューラはスレッドの順番の中で発生した中断時間を計算に含めません。つまり、Windows Vista では、スレッドは常に CPU でのその順番を少なくとも確保し、過剰な実行時間が 1 クロック期間を超えることがないため、割り当てがさらに公平になり、アプリケーションの動作がより決定的なものになります。図 2 は、両方のスレッドに少なくとも 1 タイム スライスの実行期間を与えることで、図 1 に示すシナリオに Windows Vista が対応している方法を示しています。
図 2 Windows Vista のサイクルベースのスケジュール
図 2 Windows Vista のサイクルベースのスケジュール
「プロセスの CPU 使用率を監視する」サイドバーでは、ユーザーが Process Explorer ユーティリティを使用して、プロセスの CPU サイクル使用率を監視できる方法を示しています。

マルチメディア クラス スケジューラ サービス
ユーザーは、音楽プレーヤーやビデオ プレーヤーなどのマルチメディア アプリケーションを使用して、シームレスな再生を体験できることを期待しています。ただし、ウイルス対策プログラム、コンテンツのインデックス作成、メール クライアントなどの、同時に実行される他のアプリケーションによる CPU の需要により、望ましくない一時的な中断が発生する場合があります。より優れた再生を可能にするために、Windows Vista では MMCSS を導入し、マルチメディア スレッドの CPU 優先順位を管理しています。
Windows Media® Player 11 などのマルチメディア アプリケーションでは、マルチメディア特性を示す新しい API を使用して MMCSS に登録しています。この特性は、次のレジストリ キーの下に名前順に一覧表示されているもののいずれかと一致する必要があります。
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

図 A Process Explorer で CPU Time と Cycles Delta を表示する (画像を縮小するには、ここをクリックします)
図 A Process Explorer で CPU Time と Cycles Delta を表示する
図 A Process Explorer で CPU Time と Cycles Delta を表示する (画像を拡大するには、ここをクリックします)

図 3 マルチメディア クラス スケジューラのオーディオ タスク定義
図 3 マルチメディア クラス スケジューラのオーディオ タスク定義 (画像を縮小するには、ここをクリックします)
図 3 マルチメディア クラス スケジューラのオーディオ タスク定義
図 3 マルチメディア クラス スケジューラのオーディオ タスク定義 (画像を拡大するには、ここをクリックします)
%SystemRoot%\System32\Mmcss.dll に実装され、サービス ホスト (Svchost.exe) プロセス内で実行される MMCSS には、優先順位 27 で実行される優先順位管理スレッドがあります (Windows のスレッド優先順位の範囲は 0 ～ 31 です)。このスレッドは、登録されているマルチメディア スレッドの優先順位を、図 4 に示すタスク レジストリ キーの Scheduling Category 値に関連付けられている範囲にまで高めます。Windows では、16 以上のスレッド優先順位はリアルタイムの優先順位範囲にあり、システム上のその他すべてのスレッドの優先順位よりも高くなっています (唯一の例外は、優先順位 28 および 29 で実行されるカーネルのメモリ マネージャ ワーカー スレッドです)。リアルタイム スレッド優先順位の設定に必要な優先順位の繰り上げ特権を持っているのは、MMCSS が実行に使用するローカル システム アカウントなどの管理者アカウントのみです。
Figure 4 MMCSS のスレッド優先順位 (Close Figure 4)

スケジュール カテゴリ | 引き上げられたスレッド優先順位
高 | 23-26
中 | 16-23
オーディオ ファイルが再生されると、Windows Media Player ではオーディオ タスク スレッドを登録し、ビデオが再生されると、再生タスク スレッドを登録します。MMCSS サービスでは、フォアグラウンド ウィンドウを持つプロセス内で実行と同時にストリームを配信しており、タスクの定義キーの BackgroundOnly 値が True に設定されていることを示しているスレッドをすべて引き上げます。
ただし、MMCSS ではマルチメディア スレッドが必要な CPU 時間を取得できるようにする支援をしますが、一方で、他のスレッドも少なくともある程度の CPU 時間を取得して、システムと他のアプリケーションが応答できるようにします。MMCSS では他のアクティビティ用の CPU 使用率を保持するために、次のレジストリ値を指定します。
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
既定では、これは 20 パーセントになります。MMCSS では CPU 使用率を監視し、他のスレッドが CPU を必要としている場合に、10 ms の期間にマルチメディア スレッドが 8 ms を超えて CPU を使用しないようにします。残りの 2 ms はマルチメディア スレッドが CPU を使用しないようにするために、スケジューラではマルチメディア スレッドの優先順位を 1 ～ 7 の範囲に引き下げます。
MMCSS がスレッドの優先順位を引き上げる方法については、「MMCSS による優先度の引き上げを観察する」サイドバーを参照してください。

ファイルベースのシンボリック リンク
Windows Vista の I/O に関する変更には、ファイルベースのシンボリック リンク、さらに効率化された I/O 完了処理、包括的な I/O 取り消しのサポート、および優先順位の付いた I/O があります。
Windows Vista には、NTFS に欠如しているものとして多くのユーザーから望まれていたファイル システム機能であるシンボリック ファイル リンク (UNIX ではソフト リンクと呼ばれる) がついに導入されました。Windows 2000 バージョンの NTFS には、ディレクトリ ジャンクションと呼ばれるシンボリック ディレクトリ リンクが導入されました。このリンクを使用すると、別のディレクトリを指すディレクトリを作成できますが、Windows Vista バージョンが登場するまで、NTFS ではファイルのハード リンクのみがサポートされていました。
Windows がシンボリック リンクおよびディレクトリ ジャンクションを解決する方法の主な違いは、処理が行われる場所にあります。Windows では、シンボリック リンクはローカル システムで処理されます。これは、たとえシンボリック リンクがリモート ファイル サーバー上の場所を参照している場合でも同じです。リモート ファイル サーバーを参照しているディレクトリ ジャンクションは、そのサーバー上で処理されます。したがって、サーバー上のシンボリック リンクは、他のクライアント ボリュームのように、クライアントからのみアクセスできる場所を参照できます。一方、ディレクトリ ジャンクションではこれは不可能です。この問題に対処するために、Windows Vista ではファイルとディレクトリの両方に対し、新しい種類のシンボリック リンクをサポートしています。
多くのファイル システム コマンドは、シンボリック リンクの意味を理解できるように更新されています。たとえば、Delete コマンドではリンクに従ってターゲットが削除されるようにするのではなく、リンク自体を削除する必要があることを理解しています。ただし、すべてのアプリケーションがシンボリック リンクを正しく処理できるわけではないので、シンボリック リンクの作成には既定により管理者のみが持つことのできる、新しいシンボリック リンクの作成特権が必要となっています。
シンボリック リンクを作成するには、コマンド プロンプトで Mklink コマンドを実行します。シンボリック リンクは、コマンド プロンプトの組み込みディレクトリ コマンドによって識別されます。これは、図 5 に示すように、シンボリック リンクに <SYMLINK> のフラグを付け、ターゲットを角かっこで囲んで示すことで行われます。Windows エクスプローラもシンボリック リンクに対応しており、シンボリック リンクをショートカット矢印で示します。エクスプローラでリンク先を表示するには、リンク先の列を参照ウィンドウに追加します。MMCSS による優先順位の引き上げを観察する
MMCSS サービスが Windows Media Player のスレッドに適用しているスレッドの優先順位の引き上げを観察できます。これは、ビデオまたはオーディオ クリップを再生するか、パフォーマンス モニタを実行するか、グラフの目盛を 31 (Windows スレッドの最高優先順位) に設定するか、Windows Media Player (Wmplayer.exe) スレッド オブジェクトの全インスタンス用 Priority Current カウンタを表示に追加することで、観察できます。1 つ以上のスレッドが優先順位 21 で実行されるようになります。
図 B Windows Media Player のスレッドの優先順位引き上げ
図 B Windows Media Player のスレッドの優先順位引き上げ (画像を縮小するには、ここをクリックします)
図 B Windows Media Player のスレッドの優先順位引き上げ
図 B Windows Media Player のスレッドの優先順位引き上げ (画像を拡大するには、ここをクリックします)

図 5 Mklink を使用してシンボリック リンクを作成する
図 5 Mklink を使用してシンボリック リンクを作成する (画像を縮小するには、ここをクリックします)
図 5 Mklink を使用してシンボリック リンクを作成する
図 5 Mklink を使用してシンボリック リンクを作成する (画像を拡大するには、ここをクリックします)

I/O の完了と取り消し
I/O システムには、サーバー アプリケーションのパフォーマンスを向上するための内部の変更が多くなされています。通常これらのアプリケーションでは、完了ポートと呼ばれる同期オブジェクトを使用して、非同期の I/O 要求が完了するのを待機します。Windows Vista より前のバージョンでは、このような I/O が完了すると、I/O を発行したスレッドは I/O 完了作業を実行します。それにより、スレッドが属しているプロセスに切り替わり、その他の作業が中断されます。その後、I/O システムでは完了ポート ステータスを更新し、ステータスが変更されるのを待機していたスレッドを実行します。
Windows Vista では、I/O 完了処理は、I/O を発行したスレッドによって必ずしも実行されるのではなく、完了ポートによって有効化されるのを待機していたスレッドによって行われます。この比較的小さな変更により、不要なスレッドのスケジュール、およびアプリケーションやシステムの総合的なパフォーマンスを低下させるコンテキスト スイッチを回避できるようになりました。さらにパフォーマンスを向上させるために、サーバーでは完了した複数の I/O 操作の結果を 1 回の要求で取得し、カーネル モードへの移行を回避します。
I/O システムにおいて、エンドユーザーの観点から見て最も顕著な変更は、同期 I/O 操作の取り消しを Windows Vista がサポートするようになったことです。Windows XP または Windows Server® 2003 を使用して net view コマンドを実行したか、オフライン リモート システムの共有へのアクセスを試みた経験があるユーザーは、取り消しできない I/O 操作に関する問題に遭遇したことがあるはずです。コマンドまたはファイル ブラウザは、ネットワークのタイムアウトが発生するまで応答しません。アプリケーションでは、I/O を実行しているデバイス ドライバに対し、I/O 操作を取り消すように指示する手段がないため、操作に失敗するまで待機するよりほかはありません。
Windows Vista では、ほとんどの I/O 操作は取り消しが可能です。Net View およびエクスプローラが使用しているオープン ファイル I/O も取り消すことができます。ただし、I/O の取り消しを求めているエンドユーザーの要求に応答できるように、アプリケーションを更新する必要があります。タイムアウトを使用しているデバイスと対話する Windows Vista ユーティリティの多くには、必要なサポートが組み込まれています。たとえば、サードバーティ アプリケーションを含み、実質的にほとんどすべての Windows アプリケーションが使用している、ファイルを開くダイアログと保存のダイアログでは、フォルダ内容の表示中に [キャンセル] ボタンが有効になります。Net コマンドでも、ユーザーが Ctrl + C キーを押すと、その同期 I/O が取り消されます。
I/O 取り消し機能の利点を確認するには、Windows Vista でコマンド プロンプトを開き、次のコマンドを入力してみてください。
net view (\\nonexistentmachine)
存在しないシステムに Windows がアクセスしようとしている間にコマンドはハングしますが、Ctrl + C キーを押すとコマンドを終了できます。Windows XP では、Ctrl + C キーを押しても何の効果もなく、ネットワークの操作がタイムアウトするまでコマンドは返されません。
以前のバージョンの Windows でユーザーに問題を引き起こしていた別の種類の I/O 操作に、デバイス ドライバの処理が適切に取り消されないという問題がありました。これは、取り消しが必要なことをデバイス ドライバが理解するための簡単な方法が存在しなかったためです。プロセスを終了したにもかかわらず、プロセス表示ツールにそのプロセスがまだ表示されているような場合は、デバイス ドライバがプロセスの終了と、まだ完了していないプロセスによって発行された I/O の取り消しに応答しなかったことになります。Windows では、すべてのプロセスの I/O が完了するか、取り消されるまで、最終的なプロセスのクリーンアップを実行できません。Windows Vista では、デバイス ドライバはプロセス終了通知を簡単に登録できるため、終了できないプロセスに関する問題のほとんどは解決されています。

I/O 優先順位
Windows では常に CPU 使用率の優先付けをサポートしてきましたが、I/O 優先順位の概念は含まれていませんでした。I/O 優先順位がないと、検索インデックスの作成、ウイルス スキャン、ディスクの最適化などのバックグラウンド アクティビティは、フォアグラウンド操作の応答性に大きな影響を及ぼすことがあります。別のプロセスがディスク I/O を実行している間にユーザーがたとえばアプリケーションを起動するか、ドキュメントを開こうとすると、フォアグラウンド タスクがディスクのアクセスを待機するために、遅延が発生します。同じ干渉によって、ハード ディスクに保存されている歌のようなマルチメディア コンテンツのストリーム再生も影響を受けます。
Windows Vista では、フォアグラウンドの I/O 操作が優先的に処理されるように、新しい種類の I/O 優先付け機能を導入しています。この機能では、個別の I/O 操作および I/O 帯域幅の予約に優先順位が付けられます。Windows Vista の I/O システムの内部では、図 6 に示すように、5 つの I/O 優先順位がサポートされていますが、実際に使用されるのは 4 つのみです (今後のバージョンの Windows では "高" がサポートされる可能性があります)。
Figure 6 Windows Vista の I/O 優先順位 (Close Figure 6)

I/O 優先順位 | 使用率
重大 | メモリ マネージャ
高 | 未使用
標準 | 既定の優先順位
低 | 既定のタスクの優先順位
最低 | バックグラウンド アクティビティ
I/O の優先順位は既定により "中" に設定されており、メモリ マネージャではメモリが少なくなっている状況でディスクにダーティー メモリ データを書き込む必要があるときに、"重大" の優先順位を使用して、他のデータやコードのために RAM に空き容量を作ります。Windows タスク スケジューラでは、既定のタスク優先順位を持つタスクの I/O 優先順位を "低" に設定します。バックグラウンド処理を実行するために Windows Vista 用に作成されたアプリケーションによって指定されている優先順位は "最低" です。Windows Defender のスキャンやデスクトップ検索インデックスの作成などの、Windows Vista のすべてのバックグラウンド操作では、"最低" の I/O 優先順位を使用します。最低 I/O 優先順位を表示する
Sysinternals が開発したリアルタイム ファイル システムおよびレジストリ監視ユーティリティである Process Monitor は、Windows Vista における読み取りと書き込みのファイル システム操作の詳細情報を I/O 優先順位も含めて収集します。強調表示された行は、SuperFetch (次回の記事で説明) によって発行された非常に低い優先順位を持つ I/O の例を示しています。
図 C Process Monitor で最低 I/O 優先順位を表示する
図 C Process Monitor で最低 I/O 優先順位を表示する (画像を縮小するには、ここをクリックします)
図 C Process Monitor で最低 I/O 優先順位を表示する
図 C Process Monitor で最低 I/O 優先順位を表示する (画像を拡大するには、ここをクリックします)

システム ストレージ クラス デバイス ドライバ (%SystemRoot%\System32\Classpnp.sys) では、I/O 優先順位がほとんどのストレージ デバイスの I/O に自動的に適用されるようにします。クラスおよび他のストレージ ドライバでは、キュー内で "低" または "最低 (Very Low)" の優先順位を持つ I/O の前に "中" の I/O を配置しますが、毎秒少なくとも 1 つの待機中の "低" または "最低" の I/O を発行し、バックグラウンド プロセスの進行を図ります。また、"最低" の I/O を使用しているデータの読み取りにより、キャッシュ マネージャはディスクへの変更を後回しにするのではなく、直ちに書き込むようになるため、本来であればアクセス中のファイルから先に読み取りを行う読み取り操作の先読みロジックがバイパスされます。プロセス マネージャ ユーティリティを使用した "最低" の I/O 優先順位の例については、サイドバー「最低の I/O 優先順位を表示する」を参照してください。
Windows Vista の帯域幅予約のサポートは、メディア プレーヤー アプリケーションに役立ちます。Windows Media Player では MMCSS 優先順位引き上げ機能と共にこのサポートを利用して、ほとんどエラーのないローカル コンテンツの再生を実現します。メディア プレーヤー アプリケーションでは、指定されたレートでデータを読み取る機能を保証することを I/O システムに求めます。デバイスが要求されたレートでデータを配信でき、既存の予約に影響がない場合には、I/O の発行速度とサイズについて、アプリケーションにガイダンスを提供します。I/O システムでは、ターゲット ストレージ デバイスに対して予約を行ったアプリケーションの要件が満たされるまで、他の I/O を処理しません。
ここで触れておく必要のある I/O システムのもう 1 つの変更に、I/O 操作のサイズに関する変更があります。最初のバージョンの Windows NT 以降、メモリ マネージャと I/O システムでは、個別のストレージ I/O 要求によって処理されるデータ量が 64 KB に制限されていました。このため、アプリケーションがそれよりはるかに大きい I/O 要求を発行しても、その要求は 64 KB の最大サイズを持つ複数の要求に分割されていました。各 I/O は、カーネル モードへの移行およびストレージ デバイスでの I/O 転送の開始にオーバーヘッドをもたらすので、Windows Vista ではストレージ I/O 要求のサイズは制限されなくなっています。いくつかの Windows Vista ユーザー モード コンポーネントは、より大きな I/O のサポートを活用するために変更されています。これらのコンポーネントには、エクスプローラのコピー機能やコマンド プロンプトの Copy コマンドがあります。これらは 1 MB の I/O を発行するようになりました。

次回のトピック
これまでで、Windows Vista カーネルが強化されている 2 つの分野を見てきました。私の著書『Windows Internals』(英語) (David Solomon との共著) の次の版には、さらに詳細な情報が記載されています。これは、"Longhorn" というコード名を持つ次のバージョンの Windows Server と同時期に出版される予定です。次回の記事では、新しいカーネルを引き続き紹介し、メモリ管理およびシステムの起動と停止について説明します。

Mark Russinovichは、Microsoft の Platform and Services Division に属するテクニカル フェローです。彼は『Microsoft Windows Internals』(英語) (Microsoft Press、2004) の共同執筆者で、IT および開発者会議で頻繁に講演を行っています。彼は、共同創立した Winternals Software の Microsoft による買収に伴い、Microsoft に入社しました。彼は Sysinternals の創立者でもあり、同社では Process Explorer、Filemon、および Regmon ユーティリティを発表しています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Windows の管理: Active Directory で権限を委任する
Windows の管理 Joel Yoker and Rob Campbell

Active Directory で権限を委任する
概要:
  • 管理者の役割を定義する
  • OU とセキュリティ グループ モデルを開発する
  • 2 次アカウントを使用する
  • 権利の委任用ツール

Active Directory の委任機能は非常に機能性が高く、多くのセキュリティ問題に対応し、管理タスクを簡素化することができます。Active
Directory® で適切に権利を委任することにより、環境内で特定の役割を強制し、管理エラーの影響と可能性を抑え、インフラストラクチャ全体に最小特権の原則を適用することができます。それでも多くの組織は、Active Directory を使用しながらも、この委任機能を活用していないようです。この理由の 1 つとして、企業のための Active Directory 委任モデルの開発が一見、非常に複雑に見えるということが挙げられます。最大の障害は、各組織特有のニーズに応える委任モデルを開発することですが、多少の変更を加えるだけで、ほとんどの IT インフラストラクチャに応用できる非常にシンプルな委任モデルが存在します。
すべての環境は、方法、形状、または形態に何らかの違いがありますが、実際ほとんどの大企業は多くの点で似ており、同じ IT 上の課題を抱えています。たとえば、多くの企業はいくつかの地理的な地域に分けられ、複数の IT エンジニアリング チームまたは業務サポートチームにより展開され、独立した事業単位を持っています。そして、多くの大企業は、特権のエスカレーション、サービス アカウントの悪用、および「信頼」といった事項に対応することを強いられています。
信頼とは興味深い用語で、多くの場合、複数の Active Directory フォレストを持つ理由として使用されます。信頼の問題は、１ 部門、または 1 地域が、別の部門または地域のシステムの可用性に影響を与えることからよく生じます。組織の境界にわたってスキル レベルが異なるのはよくあることで、特定の地域または特定の事業単位をサポートするために必要な特定システムに関する詳細知識が欠如していることも一般的です。このような理由から、部門では中央グループに管理権限を渡したがらないものです。
一方、Active Directory を実装するには、管理者は Active Directory インフラストラクチャを使用するアプリケーションの関与ルールを定義する必要があります。あいにく、このための一般的なアプローチ (アプリケーションのインストール ガイドでよく提唱されているもの）は、サービス アカウントをドメイン管理者クループのメンバにすることです。このアプローチの問題点は、サービス アカウントが本質的には汎用アカウントであることです。これらのアカウントにドメイン管理者の権利を許可すると、IT 環境を深刻な脅威にさらすことになります。サービス アカウントは、悪意のある管理者や不注意な管理者により不適切に使用されたり、アプリケーションの潜在セキュリティ問題を悪用する攻撃者により簡単に乱用されることがあります。
これらの障害は、克服不可能のように思われますが、Active Directory 委任モデルを実装するための優れたシナリオになります。委任モデルの開発は対話型の設計プロセスで、以下の手順に従うことをお勧めします。
  1. 組織内の IT 管理者の役割を定義する。
  2. 組織単位とセキュリティ グループ モデルを開発する。
  3. IT 管理者用に 2 次アカウントを設定する。
  4. 権利を委任する。
では、これらの手順について詳しく見てみましょう。

役割を定義する
役割の定義プロセスでは、最初にサービス管理とデータ管理について完全に理解する必要があります。これらのコンセプトが、あらゆる Active Directory 委任モデルの基礎になります。
サービス管理の中核を成すのは、Exchange サーバーやドメイン コントローラなどのディレクトリ サービス インフラストラクチャの主要コンポーネントの管理です。データ管理とは、サービスの中にあるメールボックスやユーザー アカウントなどのオブジェクトの管理です。Active Directory の範囲内では、サービス管理者は、究極的にディレクトリ サービスの提供と可用性に責任を持つ一方で、データ管理者は、ユーザー アカウントとサーバー アカウント、グループ、およびその他のドメイン リソースを管理します。
Active Directory では、組織単位 (OU) により権限を分割して委任することがサポートされています。既存のディレクトリ サービスまたはドメイン モデルで、管理者が使用できるものと同じ権限レベルを提供するために、OU をカスタム化することができます。しかし、一部の機能を単純に委任することはできず、信頼できる 1 つのグループまたはエンティティが管理を行う必要があります。
さらにタスクの分析も重要になります。管理者によりどの Active Directory タスクが実行され、これらのタスクがどの役割に割り当てられているかを理解する必要があります。たとえば、Active Directory サイトの作成はサービス管理者のタスクであり、セキュリティ グループ メンバシップの変更は通常データ管理者により行われます。各タスクについて、頻度、重要性、および難易度を評価する必要があります。これらにより、権利を委任すべきかどうかが決まるため、タスクの定義において重要な側面になります。日常的に実行されるタスク、リスクが限られたタスク、および実施があまり重要でないタスクは、委任に適しています。一方、まれにしか実行しないタスク、組織全体に対して大きな影響を持つタスク、および高いスキル レベルが要求されるタスクは、委任に向きません。これらのタスクには、代わりにエスカレーション (アカウントを一時的に要求される役割に昇格するか、タスクを再割り当て) が適切な手段になります。
大企業では多くの特徴が似ているため、共通の委任モデルを実装できると考えても差し支えないでしょう。この記事では、組織の境界を考慮し、信頼の問題 (ドメイン コントローラのような企業全体の資産の可用性など) を軽減しながら管理機能を可能にする役割のサンプル セットを提供します。このモデルは単なる例です。組織の役割の検討を始めるためには最適ですが、このガイダンスに逐一沿って計画を立てないようにしてください。
一部の役割は Active Directory により既に定義されており、一部は委任モデルを完成するために最初から設定する必要があります。多くの大規模 Active Directory 環境に適した役割のサンプル セットは、サービス管理用のエンタープライズ管理者、ドメイン管理者、および Tier4 管理者、そしてデータ管理用の Tier3 管理者、地域管理者、Tier2 管理者、および Tier1 管理者で構成することが考えられます。これらの役割とその責任の一覧については、図 1 を参照してください。
Figure 1 役割と責任を定義する (Close Figure 1)

サービス管理者 | 説明
エンタープライズ管理者 | 全社のトップレベルのサービス管理を担当します。恒久的なメンバを含めることを避ける必要があります。
ドメイン管理者 | ドメイン全体のトップレベルのサービス管理を担当します。管理しやすい少人数の信頼できる管理者のみを含める必要があります。
Tier 4 管理者 | ドメイン全体のサービス管理を担当します。必要なサービスの管理に要する権利のみを許可されています。データ管理者のエスカレーション ポイントとなります。
データ管理者 | 説明
Tier 1 管理者 | ディレクトリ オブジェクトの一般的な管理を担当し、パスワードのリセット、ユーザー アカウントのプロパティ変更などのタスクを実行します。
Tier 2 管理者 | ローカルまたは組織のユーザー アカウントとコンピュータ アカウントの一部作成または削除を担当します。
地域管理者 | ローカル OU 構造の管理を担当します。自身の OU 内でほとんどのオブジェクトを作成する権限が与えられています。
Tier 3 管理者 | すべてのデータ管理者の管理を担当します。すべての地域管理者の上位層ヘルプ デスクとエスカレーション ポイントとなります。

サービス管理者
サービス管理者の役割を詳しく見てみましょう。サービス管理者は、重要なインフラストラクチャ コンポーネントを管理します。このカテゴリに属するすべての管理者には高い特権が与えられています。このことから、このケースでは、必要なタスクの実行に要求される最低権限のみを許可する最小特権戦略を強くお勧めします。
エンタープライズ管理者とドメイン管理者。Active Directory では、ディレクトリ内の重要な機能にこれらのセキュリティ コンテキストが必要になる 2 つの特別管理者グループを定義します。これらのグループ (エンタープライズ管理者とドメイン管理者) は、トップレベルのサービス管理を担当します。このように高い特権を備えたグループにつきまとうリスクを軽減するために、これらのグループには、メンバシップを制限することを強くお勧めします。実際には、エンタープライズ管理者グループには恒久的なメンバを含めることなく、ドメイン管理者グループには、管理しやすい少人数の信頼できる常勤社員のみを含めます。
DHCP サーバーの認証や Active Directory サイトの作成など、エンタープライズ管理タスクを実行する必要がある場合、Active Directory フォレストのルート ドメインのドメイン管理者は、エンタープライズ管理者グループのメンバシップを管理することで、特権をエスカレートできます。これらの特権は、エンタープライズ管理者グループに恒久的なメンバを作成することを避けるため、短期間のみ許可する必要があります。もちろん、任意の Active Directory フォレスト内のドメイン管理者グループのすべてのメンバには、信頼を等しく設定する必要があります。
委任モデルの開発においてほとんどの組織が陥る落とし穴として挙げられるのは、これらの組み込まれた役割を無効にしたり、不能にしたりすることです。既定の役割を変更すると、予期せぬ結果を招くことがあり、サービス パックの改訂または製品のアップグレードでこれらの設定が維持される保証がありません。さらに、この種の変更により、組織の外にサポートされてない環境が作られます。実用的なアプローチとして挙げられるのは、組み込まれたグループと役割を使用しながらも、メンバシップを制限することです。これを行うには、おそらく、以前はドメイン管理者のようなグループのメンバシップに依存していた管理者のために新しい役割を作成することが必要になる可能性があります。
Tier4 管理者。Tier4 管理者グループは、すべてのエンタープライズ サービスをサポートする中央のサービス管理者で構成する必要があります。これは作成された役割であるため、組織の特定の要件に合わせてディレクトリ サービスとシステムへのアクセス許可をカスタム化できます。このグループのメンバはサービス管理者でありながら、ときにフォレスト全体のデータ管理タスクを実行することもあります。システムには多くのクラスが存在し、さまざまな責任領域があることから、Tier4 の役割は、ディレクトリのさまざまなサブグループに分けられます。たとえば、Exchange サーバーなど、特定システムを個別に管理するための別の Tier4 グループを作成する必要があります。このグループは、データ管理者のエスカレーション ポイントにもなります。
人々がよくドメイン管理グループのメンバシップを求める 1 つの理由は、任意のドメイン内のすべてのシステムに対する管理権限を得るためです。最小特権モードでこれらのサービス管理者を運用するためのコツは、Tier4 管理者をドメイン管理者にするのではなく、Tier4 管理者にエンタープライズ サーバーの制御を許可することです。特権のエスカレーションを避けるために、Tier4 管理者には、ドメイン コントローラの BUILTIN\Administrators グループのメンバシップを許可しないようにします。このグループは、ディレクトリ サービスに対して分けることができない多くの潜在権利を備えています。たとえば、任意のドメインの BUILTIN\Administrators グループのメンバは、ドメイン管理者グループのメンバシップを管理することができ、メンバが特権をエスカレートできるようになるため、権利の抑制と均衡が維持できなくなります。
既定の権限を不能にしないことの原則を念頭に置いたうえでこのリスクを軽減するには、Tier4 グループをサーバー オペレータと DNS 管理者の組み込みドメイン グループのネストされたメンバにします。これにより、ドメイン コントローラのローカル管理が可能になる一方で Tier4 管理者の特権をエスカレートする能力を制限できます。ほとんどのシステムには (ドメイン コントローラ、証明書サーバーなどを除く)、Tier4 管理者グループをローカル管理者グループのメンバにする必要があります。ネストされたローカル グループ メンバシップを自動化するには、グループ ポリシーの制限されたグループ機能を使用することができます。

データ管理者
それでは、次にデータ管理者の役割を詳しく見てみましょう。これらは、累積的な権利を持つように設計する必要があります。つまり、Tier2 管理者は、Tier1 管理者のすべての権利に加え、何らかの追加特権を与えるというようにします。このような理由から、これらのグループについては下から順に見ていきます。
Tier1 管理者。Tier1 管理者グループには、以前に作成されたディレクトリ オブジェクトの一般的な管理を実行できるようにする必要があります。このグループは、最低のトレーニングを受けた管理者、またはパスワードのリセットなど、分離したタスクを実行する人のためのものです。このグループには、それぞれの組織単位内で、非管理者グループのためのユーザー アカウントのプロパティ変更、ユーザー アカウントのパスワードのリセット、アカウントのロック解除、ユーザー アカウントの有効化/無効化、ワークステーション コンピュータ アカウントの追加とリセット、およびグループ オブジェクト メンバシップの変更を行う権利を与えます。
Tier2 管理者。このグループには、オブジェクトの一部管理と作成を許可し、Tier1 管理者が管理できる場所にのみオブジェクトを作成できるようにします (たとえば、セキュリティ グループは、グループ OU にのみ作成できます)。Tier2 管理者は、Tier1 管理者アカウントの追加と変更、OU のユーザー アカウントの追加、変更、および削除、ワークステーション コンピュータ オブジェクトの削除、およびサーバー、連絡先、共有フォルダの各オブジェクトの追加、変更と削除ができます。
地域管理者。このグループは、地域の OU 構造に対して排他的な権利が与えられています。しかし、ディレクトリ内の他の地域の OU 構造は管理できません。地域管理者アカウントは高い特権を備えているものと見なされるため、これらのアカウントは、別の OU 階層に保存し、Tier4 管理者のサービス管理者が管理を行います。地域管理者は、それぞれの OU 構造内で制限なくほとんどのオブジェクトを作成する権限を備えているため (例外として、その他の組織単位の作成が挙げられることに注意)、下の層により管理できないオブジェクトを作成するリスクが高まります。
Tier3 管理者。多くの組織には、集中管理のヘルプ デスクまたは上位層のヘルプ デスクがあります。この役割はデータ管理者の一覧から構成され、すべての地域管理者よりも上位のデータ管理者グループとなります。ディレクトリ内ではこれらのグループに特に権利を委任するのではなく、各地域管理者グループのネストされたメンバを使用します。これがすべてのデータ管理者のトップレベル エスカレーション ポイントとなるだけでなく、サービス管理者グループにエスカレートされる問題のエントリ ポイントとなります。

OU とセキュリティ グループ モデルを構築する
組織内の役割を定義したら、OU とセキュリティ グループ モデルを定義する必要があります。Active Directory で OU を作成する理由として、権利の委任、およびグループ ポリシー オブジェクトがリンク可能なポイントの作成という主に 2 つの理由があります。OU によりディレクトリ内の管理スコープ (SOM) が定義され、これを使用してさまざまなレベルのオブジェクトに対する権利を制限できます。このため、OU 構造の実装方法を決めるうえで、どのように権限を委任するかが重要な要因となります。
これを念頭に置くと、トップレベル OU (または一連の OU) を、すべてのオブジェクトを格納するドメインのすぐ下に作成する必要があります。この OU が、Tier4 管理者用の最高レベルの SOM を定義する特別な目的となります。トップレベル OU を作成することにより、ディレクトリ サービスに対する権利を、ドメイン レベルからではなく、OU レベルから明確に始めることができます。ドメインからではなく、トップレベル OU から委任を行うことで、既に解説している組み込みドメイン グループを操作して、特権をエスカレートする能力を持つユーザーのリスクを軽減できます。
トップレベル OU の下には、別のデータ管理チームを持つ各地域または各事業単位を表す別の サブ OU 階層を作成する必要があります。各地域のサブ OU は、ディレクトリ オブジェクトを管理する目的で、拡張不能な共通の OU 階層を持たせる必要があります。権利の委任のほとんどは自動化されることになるため、継続的な管理において一貫性が重要になります。各地域で独自の OU を希望する場合があるため、これは難しい注文かもしれません。しかし、IT 管理者は自分の方針を曲げないことが大切です。1 つの地域を拡張する必要があれば、すべての地域のサブ OU 構造を拡張すべきです。これは当初は難しいかもしれませんが、組織でオブジェクトに対する汎用的な格納構造を確立すれば、やがて例外的な状況にも対応できるようになるものです。
最後に、それぞれのサブ OU 階層に対して、管理者の特権のエスカレーション能力を排除するために、Tier1 管理者グループ、Tier2 管理者グループ、および地域管理者グループといった別々のサブ管理者グループとアカウントを作成します。これらのアカウントを別々の OU に配置することにより、それ以下のレベルの管理を制限することができます。このため、すべての Tier1 管理者アカウントと関連セキュリティ グループが、権利のない OU に存在する場合、管理者は他の管理者アカウントをハイジャックしたり、自身のレベルに他の管理者の特権をエスカレートしたりできません。たとえば、ドメイン管理者グループの任意のメンバは、ドメイン内の他の任意のユーザーアカウントをドメイン管理者にすることができます。しかし、この OU モデルでは、そのリスクが軽減されます。図 2 には、OU 構造とその関連セキュリティ グループの例を示します。
図 2 OU 構造と関連するセキュリティ グループ
図 2 OU 構造と関連するセキュリティ グループ

2 次アカウントを設定する
委任モデルを成功させるうえで鍵になるのは、最小特権の原則を強制することです。実際には、これはセキュリティの原則上、与えられた役割に必要なタスクを実行する能力のみを与え、それ以上のものは与えないことを意味します。残念ながら、多くの IT 管理者は、ディレクトリの管理と、Web ブラウズや電子メールを読むなどの毎日のタスクに同じセキュリティの原則を使用しています。別のアカウントを持つことにより、階層化された管理者がディレクトリ サービスに間違ってダメージを与えたり、日常的なアプリケーションを経由してなされる、ディレクトリ管理者を標的にした攻撃を受けたりする可能性が低減します。
ユーザーにログオフしてからログオンしてもらうことなくこれを可能にするには、Secondary Logon サービス (Runas.exe) を使用します。これによりユーザーは、サーバーとワークステーションでスクリプトか実行可能ファイルを実行するときに、別の資格情報を使用して、特権をエスカレートすることができます。
最小特権アカウントの使用というコンセプトは比較的シンプルですが、組織では昔ながらの IT 慣習を破ることが難しいため、ときに徹底が難しいようです。日常的なタスクに特権アカウントを使用するのを防ぐ単純なアプローチとして挙げられるのは、Exchange サーバーのこれらのアカウントに電子メール アクセスを許可せず、組織の管理ポリシーとしてこれを強制することです。これは比較的シンプルなアプローチで、このようなアカウントが管理以外の定常的なタスクに使用される可能性を大幅に低減します。

権利を委任する
委任モデル開発の最後の手順は、Active Directory で実際に権利を委任することです。これには、ディレクトリ内に保存されたデータのアクセス制御エントリ (ACE) とアクセス制御リスト (ACL) の操作が必要になります。Active Directory コンテナの ACL により、どのオブジェクトが作成可能かと、これらのオブジェクトの管理方法が定義されます。権利の委任では、オブジェクトの表示、指定クラスの子オブジェクトの作成、特定クラスのオブジェクトの属性とセキュリティ情報の読み取りの能力など、オブジェクトに対する基本操作を行います。これらの基本操作に加えて、Active Directory では、送信者とレプリケーション管理トポロジなどの操作を可能にする拡張権利が定義されます。
前の手順では、定義された組織の役割に割り当てるセキュリティ グループの作成について検討しました。これは、すべての役割に対して、サブ OU 構造により関連付けられたセキュリティ グループが存在することを意味します。委任モデルを実装するには、これらのグループにディレクトリのオブジェクトに対する権限を割り当てる必要があります。プロセスのこの段階では、以前のように高度にカスタム化された環境の構築を繰り返したくはありません。代わりに、できるだけ組み込みグループと権利を活用するよう心掛けます。たとえば、特定の役割でフォレストの DNS レコードを管理する必要があるとします。この場合、コンテナと Active Directory に統合された DNS に関連する名前付けコンテキストに対する権利を委任しないでください。代わりに、ドメインの BUILTIN\DNS 管理者グループを活用します。さらに、グループ ポリシーによりユーザー権利と他の権限を拡張して、与えられた役割によるシステムの特定クラスの管理に必要な追加権利を付与することができます。
委任により権限を割り当てる場合、ディレクトリ内の拒否 ACE の使用を制限するか、場合によっては完全に排除する必要があります。これらは、トラブルシューティング時に厄介になる可能性があります。より良いアプローチは、明確な許可 ACE を活用して、自身の役割を表すカスタム グループに権利を許可することです。Tier4 管理者などのユーザー定義の役割は、その役割に明確に定義された権利しか備えていないことに気をつけてください。
Active Directory のセキュリティにおいて継承は重要な要因で、これによりどのように特定 ACL が任意のコンテナまたはサブコンテナの子オブジェクトに適用されるかが定義されます。継承可能な ACE をできるだけ目的のオブジェクトの近くに適用するよう確認することで、常に継承の範囲を明確にします。親オブジェクトに適用される継承可能な拒否権限は、祖父母オブジェクトに適用される継承可能な拒否権限よりも優先されます。これが、実際の委任には拒否 ACE を推奨できない主な理由の 1 つです。さらに、継承可能な権限によりオブジェクトに対する明確な ACE を上書きすることはできません。このために、階層化された管理者の能力を制限するか、排除して、ディレクトリ オブジェクトの随意アクセス制御リストを変更すること (書き込み DACL 特権を削除することで) をお勧めします (オブジェクトの作成者は潜在的にこれらの権利を備えています)。経験からいって、管理者にオブジェクトの DACL を変更する能力が与えられていれば、実際にそれを実行するはずです。選択肢を与え、管理エラーの可能性を作ることにより、委任モデルに対する組織の努力が無駄にならないようにしてください。
Active Directory 委任モデルを適切に実装するには、必要なツールがいくつか存在します。非常に大きな組織の場合、組み込みの委任ウィザードを使用してディレクトリに権限を割り当てることは面倒な作業で、管理エラーを引き起こす可能性に満ちています。代わりに必ず自動手順を使用して、委任モデルが正しく文書化されていること、それがサポート可能であること、および何らかの理由で設定が失われたり、間違って変更された場合に復旧オプションが利用できることを確実にする必要があります。
委任の実装に必要な主要ツールは、オブジェクトのディレクトリ サービス ACL の操作に使用する DSACLS.EXE コマンド ライン ツールです。このツールでは、親オブジェクトに DACL の継承フラグを指定することもできます (継承フラグには、このオブジェクトとサブオブジェクト、サブオブジェクトのみ、および継承可能なアクセス許可を 1 レベルのみ伝達するがあります)。DSACLS コマンドは、継承フラグが正しく設定されていないと、最終的にはエラーとなるため、このツールの使用時はテストが重要になります。以降に、ターゲットのデモ OU にコンピュータ オブジェクトを作成する能力を委任するための DSACLS 構文例を示します。
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS では、オブジェクト タイプの大文字と小文字が区別されます。つまり、"cn=computer" に対して "cn=Computer" オブジェクト クラスに対する権限を委任しようとしても機能しません (図 3 を参照してください)。
図 3 大文字と小文字の区別によるエラー
図 3 大文字と小文字の区別によるエラー (画像を縮小するには、ここをクリックします)
図 3 大文字と小文字の区別によるエラー
図 3 大文字と小文字の区別によるエラー (画像を拡大するには、ここをクリックします)
一部のオブジェクトを作成するには、一定の権利セットが必要になります。これは、オブジェクトの "must contain" と "may contain" 属性に関係します。今まで聞いた中で、このコンセプトを説明する最適な比喩は、ハンバーガーのモデルを使用するものです。ハンバーガーがハンバーガーと見なされるには、肉のパティとパンが含まれる必要があります。これらは、ハンバーガー オブジェクト クラスの must-contain 属性です。ピクルス、ケチャップ、レタスなどの品目は may-contain 属性です。このオブジェクト クラスを拡張してチーズバーガーを定義すると、must-contain 属性の一覧にはチーズが追加されます。
ユーザー オブジェクトも同じように機能します。このモデルに従い、次の DSACLS 構文を使用してユーザー オブジェクトを作成してみましょう。
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
管理者がユーザー オブジェクトを作成すると、いくつかのエラーが発生します。パスワードの設定など、ユーザー オブジェクトに必要な属性を設定するための特権を許可する必要があります。これは、次の追加 DSACLS 構文に示されています。
最初の手順として、ユーザー クラスのすべての属性に汎用読み取り/汎用書き込みを許可して、must-contain 属性を書き込む特権を許可します。
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
次の手順では、パスワードを変更する拡張権利を許可します。
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
最後の手順では、[最終パスワード変更日時] 属性の [プロパティの読み取り] と [プロパティの書き込み] を行う特権を許可します。
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
適切な権利を委任したら、定義された役割はコンテナの DACL に定義されたオブジェクト クラスを管理することのみに限定されます。前のコンピュータ オブジェクトの例を使用すると、Active Directory ユーザーとコンピュータのコンテキスト メニューが、このような権利を委任されたユーザーが作成可能な新しいオブジェクトの一覧に制限されます (図 4 の制限された一覧を参照してください)。
図 4 新しいオブジェクトの制限一覧
図 4 新しいオブジェクトの制限一覧
DSACLS を自動化して権利を複雑に展開することもできます。以下には、任意のコンテナのユーザー オブジェクトに対する一般的なアドレス属性を操作するための権利の委任に使用できる DSACLS コマンドをいくつか示します。
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
これらの例は、ほとんどの委任モデルに共通しており、前に定義した役割と共に使用することができます。
委任の実装に使用する別のツールは DSREVOKE.EXE で、これにより管理者は、ディレクトリ内のオブジェクトの特定セキュリティ原則のために委任された権利を検索し、削除できます。このツールは非常に有益ですが、セキュリティ原則のみに対して行うもので、セキュリティ グループ内のネストされたメンバシップが評価されません。
これらのコマンド ライン ツールのほかに、グループ ポリシーのユーザー権利の割り当てと制限されたグループの使用を強くお勧めします。既に解説したように、IT 管理者は、ユーザー権利の割り当てにより特定ターゲット システムのさまざまなユーザー グループに対して低レベルの権利 (システムのリモート アクセスと再起動の権利など) を拡張するか、削除することができます。制限されたグループは、フォレスト内のローカル グループ メンバシップとドメイン グループ メンバシップの指定と強制に使用できます。これらのツールを組み合わせることで、Active Directory 委任モデルの自動化と実装に必要なすべての機能が得られます。

まとめ
Active Directory 委任モデルの開発というタスクは、複雑そうに見えますが、実際には、非常にシンプルな委任モデルをほとんどの IT インフラストラクチャに応用できます。実際の委任モデルの展開で最も重要な手順の 1 つは、明確な役割を定義することです。定義された役割は、管理しやすい少人数のみに限定する必要があります。役割が多すぎると使用されていない役割が出現し、役割が少なすぎると役割の分離ができなくなるため、慎重にバランスを見極める必要があります。
タスクを定義する際に注意する事項は、タスクを頻度、重要性、および難易度で整理することです。役割を定義したら、各役割で可能なことと不可能なことを示し、テスト プロセスを自動化するための一連の使用事例を準備します。使用事例を周到に準備することにより、組織内の関係する人々に対するこれらの役割の説明が容易になり、自動化エラーによる思いがけない事態の発生を軽減することができます。
最後に、委任モデルの開発には実用的なアプローチを踏襲することをお勧めします。簡単であればあるほどサポート性が向上し、維持しやすい委任モデルを開発することで、組織の Active Directory 環境における管理権限の管理が大幅にやりやすくなります。
参考資料
  • Design Considerations for Delegation of Administration in Active Directory (英語)
  • Best Practices for Delegating Active Directory Administration (英語)

Joel Yoker は、マイクロソフト連邦政府チームのシニア コンサルタントです。Joel と Rob は、米国連邦政府関係の顧客向けのセキュリティ ソリューションの開発と展開を専門にしています。
Rob Campbell は、マイクロソフト連邦政府チームのシニア テクニカル スペシャリストです。Joel と Rob は、米国連邦政府関係の顧客向けのセキュリティ ソリューションの開発と展開を専門にしています。


 Windows の管理: Windows Vista の新しいグループ ポリシー テンプレートを掘り下げる
Windows の管理 Darren Mar-Elia

Windows Vista の新しいグループ ポリシー テンプレートを掘り下げる
概要:
  • ADMX の内部
  • ADMX ファイルを編集する
  • ADM ファイルと ADMX ファイルの相違点
  • 中央ストアを作成する

Windows Vista より前のバージョンでは、グループ ポリシー内で設定できるレジストリ値は ADM ファイルによって管理されていました。この ADM ファイルの構文は、不可解で独特なものでした。マイクロソフトにより標準の ADM ファイルと共に出荷されたもの以外に、追加のレジストリ値を制御する必要がある場合は、この
構文を習得し、カスタム ADM ファイルを作成する必要がありました。さらに、これらの ADM ファイルは各グループ ポリシー オブジェクト (GPO) と共に Active Directory® 環境に格納され、これらの各 GPO は、付属の ADM ファイルと共にドメイン内のすべてのドメイン コントローラにレプリケートされていました。
Windows Vista™ のリリースに伴い、マイクロソフトはグループ ポリシー ベースのレジストリ テンプレートの領域に大きな一歩を踏み出します。Windows Vista は、現在では ADMX と呼ばれている ADM ファイルの書式と、これらのファイルの格納方法に大きな変化をもたらします。この記事では、新しい ADMX 書式に注目し、これらのファイルと ADM との相違点について説明します。さらに、これらのファイルのストレージが Windows Vista 環境でどのように取り扱われるかについても見ていきます。

ADMX の相違点
新しい ADMX ファイル書式と、Windows NT® 4.0 以降に使用されてきた古い ADM 書式の最も大きな違いは、ADMX ではレジストリ ポリシー設定の記述に XML 標準を採用していることです。これは、いくつかの理由により望ましいことです。第 1 の理由は、XML の編集には ADM 構文よりも多くのツールを利用できることです。第 2 の理由は、XML はスキーマ化されているので、的確な ADMX ファイルを作成する上で、どこにどのタグを配置すればいいかを判断するためのツールを簡単に構築できるようになることです。スキーマ化は、ADMX 書式などの XML の任意のアプリケーションに対し、使用可能な要素および属性についてと、これらの編成方法について記述したスキーマが存在することを意味します。この記事ではその例を後で紹介します。
ADMX と ADM の別の主な相違点として、メインの ADMX ファイルの文字列セクションが言語固有の ADML ファイルに分割されていることが挙げられます。ADM ファイルについての知識があれば、各ファイルの最後に "[strings]" タグで区切られたセクションがあり、このセクションでは、グループ ポリシー エディタまたは管理用テンプレートを使用したときに表示されるテキストの文字列に値を割り当てることができることをご存じだと思います。たとえば、特定のポリシーの [Explain] タブをクリックしたときに表示されるテキストは、この文字列セクション内に格納されていました。これにまつわる問題は、文字列が ADM ファイル内で格納されていたので、別の言語を使用している Windows® システムでその ADM を使用する場合には、その言語の文字列セクションを含む新しい ADM ファイルを作成する必要があったことです。
また、たとえばフランス語版の Windows を使用しているユーザーが、英語の ADM を使用している既存の GPO を編集する必要があるときには、さらに作業が複雑になっていました。グループ ポリシー エディタではフランス人の管理者は英語しか表示できませんでした。Windows Vista では、[strings] セクションを XML ベースの ADM 言語 (または ADML) ファイルに分割することで、この問題を回避しています。ADML ファイルは、サポートされているすべての言語で提供できます。新しい言語をサポートする場合は、ポリシーを格納するメインの ADMX ファイルには手を加えずに、ADML ファイルを簡単に変更するだけで済みます。さらに重要なこととして、このフランス人管理者が自分の Windows Vista ワークステーションで GPO を編集すると、グループ ポリシー エディタではフランス語版の Windows が使用されていることを検出し、その GPO に対してフランス語の ADML ファイルを自動的に読み込みます。
c:\windows\policydefinitions のフォルダを開くと、Windows Vista のインストールに付属している ADMX および ADML ファイルをすべて表示できます (図 1 参照)。
図 1 Windows Vista の ADMX ファイル
図 1 Windows Vista の ADMX ファイル (画像を縮小するには、ここをクリックします)
図 1 Windows Vista の ADMX ファイル
図 1 Windows Vista の ADMX ファイル (画像を拡大するには、ここをクリックします)
図 1 に示すファイルの上部には、en-us というフォルダがあることに注目してください。これは言語特有のフォルダで、この PolicyDefinitions フォルダ (ここでは英語 (米国)) に表示される ADMX ファイル用の ADML ファイルを含んでいます。各 ADMX には 1 つの ADML ファイルが存在します。このドキュメントの執筆時点では、Windows Vista には既定により 132 の ADMX/ADML ファイルが含まれています。これは、Windows Vista とそれ以前のバージョンのもう 1 つの大きな違いです。Windows XP により作成された GPO には、通常 5 つの ADM ファイルが含まれていました。そのうち一番大きなものは System.adm で、これにはポリシー制御下のほとんどの Windows コンポーネント用のポリシー アイテムが格納されていました。Windows Vista では、ADMX ファイルは機能ごとに分割されているので、はるかに多くの ADMX ファイルが存在します。各 ADMX は通常 1 つの Windows コンポーネント (コントロール パネル、DNS クライアント、Windows エクスプローラなど) に対応しています。

ADMX の内部
この ADMX が XML で作成されているということは、前に説明したように、飛躍的な改善です。ただし、多くの管理者は XML の作成方法に関する知識を持っておらず、ポリシー拡張の作成に ADMX が使用するスキーマについても理解していません。カスタム ADMX を作成するためのチュートリアルはこの記事の対象範囲を超えていますが、ADMX がどのように作成されるかについて見てみましょう。
ADMX または ADML ファイルは任意のテキスト エディタで開くことができます。メモ帳を使用することもできますが、エディタが XML 構文を理解していない限り、メモ帳の使用はあまり便利ではありません。私は Visual Studio® を使用しています。その IntelliSense® 機能が特定の要素の作成に役立つためです。図 2 は、Windows Vista に付属している 1 つの ADMX の最初の数行を示しています。
Figure 2 ADMX ファイル内の一部の XML (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
XML に関する知識がなければこれは不可解に見えるかもしれませんが、これらの XML 要素の多くはどの ADMX ファイルにも含まれているものです。たとえば、policyNamespaces 要素はすべての ADMX ファイルの中でこの ADMX ファイルを一意に識別します。
以前のバージョンの Windows でカスタム ADM ファイルを作成したことがある場合には、Category、Policy、ListBox、ActionList などの一連のタグを使用して、グループ ポリシー エディタに表示されるポリシー設定を定義されたことと思います。これらのタグの多くは変更されていないか、ADMX 書式で若干変更されているだけにすぎませんが、これらは XML として表現されているのでかなり異なっているように見えます。たとえば、私はグループ ポリシーのトラブルシューティング用に Windows 内でさまざまな種類のログを有効にしたカスタム ADM ファイルを作成したことがあります。そのカスタム ADM の一部を図 3 に示します。このファイルを新しい ADMX 書式に移植したものを、図 4 に示します。
Figure 4 ADMX ファイルに変換された ADM ファイル (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 カスタム ADM ファイル (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
多くの点において、この ADMX スニペットはそれに対応する ADM と比較して簡潔なため、簡単に理解できます。ポリシー要素は、このポリシーの機能 (フォルダのリダイレクトのログ記録) を指定します。先頭に $(string. が付いた属性は、対応する ADML 文字列要素の参照です。key および valuename 属性は、その名前から明らかなように、それぞれレジストリ キーおよびこのポリシーが影響を及ぼす値を指定します。parentCategory 要素は、このポリシーがグループ ポリシー エディタの管理テンプレート階層のどこに表示されるかを制御します。supportedOn 要素は、どのオペレーティング システムのバージョンがこのポリシーに従うかを示し、最後に、enabledvalue および disabledvalue 要素は、このポリシーが有効または無効に設定されたときにレジストリに挿入される値を指定します。
これはとても単純なオン/オフ ポリシーです。ADM 構文と同じように、グループ ポリシー エディタではさらに複雑な UI 要素を作成することもできます。ADMX でそれを行うと、構文はもう少し複雑になり、UI 要素のテキスト ラベルを含む ADML ファイルの部分を参照しているプレゼンテーション属性を含むようになります。ただし、ADMX 構文がそれ以上に複雑になることはありません。1 つ念頭に置いておくべきことは、一部のタグ名が ADM と ADMX の間で変更されていることです。たとえば ADM 用語では、"edittext" および "listbox" というタグがありました。ADMX では、これらのタグは ADMX ファイル内でそれぞれ "text" および "list" と呼ばれています。これらの要素には、対応するエントリが ADML ファイル内にあり、そのファイルの中で、これらの要素と共に表示されるテキストが指定されます。
ご存じかもしれませんが、管理者はカスタム (レガシー) ADM ファイルを Windows Vista Group のグループ ポリシー オブジェクト エディタに読み込むことができます。マイクロソフトではカスタム ADM ファイルを ADMX 構文に変換するためのユーティリティを提供する予定があるのかという質問を受けることがよくあります。実のところ、マイクロソフトは FullArmor Corp. と提携し、ADMX Migrator という無料のツールをリリースしました。このツールは 2 つの処理を行います。まず、古いカスタム ADM ファイルを ADMX 書式に変換します (このツールを使用してカスタム gpolog.adm を変換した例については、図 5 を参照してください)。
図 5 ADMX Migrator
図 5 ADMX Migrator (画像を縮小するには、ここをクリックします)
図 5 ADMX Migrator
図 5 ADMX Migrator (画像を拡大するには、ここをクリックします)
第 2 に、このツールは新しい ADMX ファイルを最初から作成するための ADMX エディタとして機能します。このツールは go.microsoft.com/fwlink/?LinkID=77409 (英語) からダウンロードできます。

ADMX のストレージ
ここで触れておくべきもう 1 つの変更に、使用される ADMX および ADML ファイルの格納方法があります。Windows Vista より前のバージョンの Windows では、新しい GPO を編集すると、ADM ファイルが編集タスクを実行したローカルのワークステーションから、Active Directory ドメイン内のドメイン コントローラの GPO の SYSVOL 部分に自動的にコピーされました。これらの ADM はその後、作成された GPO ごとに、ドメイン内の各 DC にレプリケートされました。これにより、特に数十または数百の GPO を扱うような大規模な環境では、多くのネットワーク帯域幅とディスク領域が無駄になっていました。Windows Vista では、このプロセスが大きく方向転換されています。既定では、Windows Vista ワークステーションで Active Directory ベースの GPO を作成すると、グループ ポリシー エディタに表示される管理用テンプレート ポリシーが、GPO を編集しているコンピュータの c:\windows\policydefinitions フォルダから読み込まれます。
ADMX および ADML ファイルは SYSVOL にはコピーされません。これらはローカルでの参照用です。これにより、ADM からグループ ポリシー環境にかかるストレージとネットワークの負担が取り除かれます。ただし、それだけではありません。Windows Vista では、管理用テンプレートのリポジトリとして、中央ストアをサポートしています。これにより、GPO の編集を誰が行うかにかかわらず、編集に使用する ADMX ファイルが効果的に制御されます。制御は、公式の ADMX および ADML ファイル (および作成したカスタム ファイル) すべてをネットワーク上の場所にコピーすることで行います。それにより、その後 Windows Vista ワークステーションで編集するグループ ポリシーはすべて、個別のローカル ファイルではなく、ネットワークベースのバージョンを参照するようになります。中央ストアの設定は、1 つのドメインあたり 1 回だけ行う簡単なタスクです。「中央ストアを作成する」サイトバーの手順に従ってください。

まとめ
Windows Vista の新しい ADMX 書式は、以前の OS バージョンで使用されていた ADM ファイルより飛躍的に改善されています。XML の使用により、これらのファイルの編集や検索のフレームワークが明確になっています。言語固有の文字列を個別のファイルに移動することで、複数言語のグループ ポリシーの編集が容易になり、中央ストアによってすべての GPO を ADM ファイルのコピーを使用して格納し更新する必要性が取り除かれています。これらすべての理由により、ADMX について学ぶことは理にかなっています。
中央ストアを作成する
中央ストアの作成は、比較的簡単です。Active Directory ドメイン内に中央ストアを作成するには、次の手順に従います。
手順 1: エクスプローラを開き、環境内の PDC エミュレータ DC にある SYSVOL 共有にアクセスします (任意の DC を使用できますが、通常、グループ ポリシーの変更に的を絞っているのは PDC ロールの所有者です)。
手順 2: SYSVOL の下の Policies フォルダにアクセスし、PolicyDefinitions という新しいフォルダを作成します。
手順 3: Windows Vista ワークステーションの C:\windows\policydefinitions フォルダの内容を、新しい PolicyDefinitions フォルダにコピーします。このとき、各言語に依存している ADML フォルダ (英語 (米国) のコンピュータの en-us など) も含めます。
ADMX および ADML ファイルを中央ストア フォルダにコピーすると、Windows Vista のグループ ポリシー オブジェクト エディタでは、ローカルに格納されているファイルを無視して、中央ストアにあるファイルを参照し始めます。

Darren Mar-Eliaは、Microsoft グループ ポリシー MVP で、人気の高いグループ ポリシー サイト www.gpoguy.com の作成者であり、『Microsoft Windows Group Policy Guide』(英語) (Microsoft Press、2005) の共同執筆者です。彼は、SDM Software, Inc. の CTO 兼創立者でもあります。彼の連絡先は Darren@gpoguy.com(英語) です。


 Windows の管理: グループ ポリシーのトラブルシューティング ガイド
Windows の管理 Derek Melber

グループ ポリシーのトラブルシューティング ガイド
概要:
  • 一般的な GPO 問題
  • グループ ポリシー ルール
  • GPO 問題のトラブルシューティング
  • トラブルシューティング用ツール

Microsoft Active Directory は、多くの IT インフラストラクチャにとって重要なコンポーネントになっています。Active Directory の最も重要な機能の 1 つにグループ ポリシーがあります。グループ ポリシーを使用すると、管理者はドメイン コントローラ、メンバ サーバー、およびデスクトップを一元管理できるようになります。
明らかに、グループ ポリシーは数多くの利点をもたらしますが、小さな欠点が 1 つあります。大規模な組織では、グループ ポリシーの設計および実装が複雑になり、問題が発生した場合のトラブルシューティングはさらに困難になります。この記事では、グループ ポリシーがどのように構成されているかについて調査し、グループ ポリシーのトラブルシューティング方法を示していきます。この記事を最後までお読みいただければ、あらゆるグループ ポリシー問題の対処に必要な手段がすべて身に付くはずです。

問題のある設定
グループ ポリシー内には、特にグループ ポリシーが総合的な Active Directory® の設計および実装とインターフェイスを取る方法について、数多くの可変部分があります。アクセスおよびネットワークに関する多くの種類の問題をトラブルシューティングする際は、解決策を求めるうえで、Active Directory およびグループ ポリシーの実装の基礎を常に考慮する必要があります。トラブルシューティング プロセスを始めるために、誤って構成されることのあるグループ ポリシー設定について見ていきましょう。その後、グループ ポリシーの誤動作を引き起こすようなさらに複雑な問題について見ていきます。
Active Directory 管理者は、管理用テンプレート ファイル (ADM または ADMX ファイル) とグループ ポリシー オブジェクト エディタを使用するか、GPEdit (gpedit.msc を実行して起動) を使用してグループ ポリシー設定を表示できます。GPEdit を使用した場合、管理者はグループ ポリシー オブジェクト ファイル (GPO) を作成します。GPO は、Active Directory 構造内のコンピュータとユーザーに適用する (または適用しない) ように構成されます。GPO が適切に機能するには、従う必要のあるルールがいくつか存在します。これらのルールについて見てみましょう。
GPO はリンクされる必要がある 新たに作成した GPO は、Active Directory 内のどのノードにもリンクされていない場合があります。GPO は編集や変更が可能ですが、ノードにリンクされるまで、どのオブジェクトにも影響を与えません。GPO が適切にリンクされていることを確認するために、図 1 に示すように、グループ ポリシー管理コンソール (GPMC) に情報ウィンドウを表示できます。
図 1 明確に表示されている GPO リンク
図 1 明確に表示されている GPO リンク (画像を縮小するには、ここをクリックします)
図 1 明確に表示されている GPO リンク
図 1 明確に表示されている GPO リンク (画像を拡大するには、ここをクリックします)
GPO は正しいオブジェクトを対象にする必要がある ご存じのとおり、グループ ポリシーは Active Directory 内の正しいオブジェクトを対象にする必要があります。ただし、トラブルシューティング作業中にこれが見過ごされることがあります。GPO には、2 つの主なカテゴリがあります。これらはコンピュータとユーザーです。GPO を構成するときは、それがコンピュータ オブジェクトまたはユーザー オブジェクトのどちらに対するものであるかを明確にする必要があります。次に、GPO がリンクされている組織単位 (OU) に正しいオブジェクトの種類が配置されていることを確認できます。
GPO はグループには適用されない GPO を Active Directory セキュリティ グループ オブジェクトに適用することは、ユーザーから望まれていることですが、これは不可能です。GPO 設定で構成可能なオブジェクトは、コンピュータとユーザーの 2 つだけです。グループ メンバシップを経由して GPO がオブジェクトを構成することはできません。たとえば、Finance OU にリンクされている GPO が存在する場合、図 2 に示すように、設定によって影響を受ける唯一のオブジェクトは Derek と Frank です。GPO 内の設定は、Marketing グループ内のメンバには、そのグループ内の誰がメンバであっても影響を与えません。
図 2 Finance OU とその中のオブジェクト
図 2 Finance OU とその中のオブジェクト (画像を縮小するには、ここをクリックします)
図 2 Finance OU とその中のオブジェクト
図 2 Finance OU とその中のオブジェクト (画像を拡大するには、ここをクリックします)
ターゲット オブジェクトが GPO のパスに含まれている必要がある GPO 設定が、予期したとおりにオブジェクトに影響を与えていないことに気づいた場合は、もう 1 つの重要な設定を行う必要があります。つまり、オブジェクトを GPO の管理スコープ (SOM) に含める必要があります。これは、GPO がリンクされているノード (子ノードも可) の下にオブジェクトを配置する必要があることを意味します。たとえば、図 3 に示すように、Finance OU にリンクされている GPO は、Marketing OU 内のオブジェクトのいずれにも影響を与えません。GPO の SOM は、リンクされているノードから、Active Directory 構造内の下位に及びます。
図 3 OU が同じレベルにあるとき、GPO はリンクされている OU にのみ適用される
図 3 OU が同じレベルにあるとき、GPO はリンクされている OU にのみ適用される (画像を縮小するには、ここをクリックします)
図 3 OU が同じレベルにあるとき、GPO はリンクされている OU にのみ適用される
図 3 OU が同じレベルにあるとき、GPO はリンクされている OU にのみ適用される (画像を拡大するには、ここをクリックします)
GPO は有効にする必要がある GPO を作成したときには、ターゲット オブジェクトに対して変更を行うように構成されていません。ただし、コンピュータとユーザーの両方の部分に対しては有効になっています。これらの部分のどちらかが無効になっている場合は、それを追跡するのが難しくなります。このため、適用されない GPO をトラブルシューティングしているときは、GPO の一部またはすべてが無効になっていないかどうかを確認することが大切です。確認するには、GPMC の [グループ ポリシー オブジェクト] | [アカウント ポリシー] の下の GPO ステータスを確認します。
一部の設定は再起動を必要とする GPO 設定が正しく機能していないときは、GPO に特有の処理が原因の場合があります。GPO の定期的なバックグラウンド更新がトリガされたときに、GPO 設定のすべてではなく、一部のみしか処理できない場合があります。このため、作成した設定がまだ有効になっていない可能性があります。設定にはフォアグラウンド ポリシーというカテゴリに属するものがあり、これらはコンピュータが再起動されるか、ユーザーがログオフしてから再びログインしたときにのみ適用されます。このような動作をする設定の例には、ソフトウェアのインストール、フォルダのリダイレクト、およびスクリプトの適用があります。

設定の同期および非同期アプリケーション
GPO 内では、起動時およびログイン時のポリシー適用方法を構成できます。可能な変更によって、ポリシーがまだ適用されている最中でもユーザーがデスクトップに直ちにアクセスできるようになる場合と、すべてのポリシーが確実に適用されてからデスクトップにアクセスできるようになる場合があります。図 4 は、各オペレーティング システムの既定の動作方法を示しています。この動作を変更するには、次のポリシー設定を変更します。
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 クライアントでの既定の処理 (Close Figure 4)

オペレーティング システム | 起動 | ログオン | ポリシーの更新
Windows 2000 | 同期 | 同期 | 非同期
Windows XP Professional | 非同期 | 非同期 | 非同期
Windows Server 2003 | 同期 | 同期 | 非同期
ほとんどの管理者は、ポリシーを非同期的に適用し、すべてのポリシーが確実に適用されてからユーザーがデスクトップにアクセスできるようになるのを好みます。これにより、ユーザーが作業を始める前に、すべてのセキュリティおよび構成設定が適用されます。これは、ログオン速度向上のために最適化されている Windows® XP Professional の既定の状態ではないことに注意してください。

既定の継承を変更する
GPO 処理の既定の継承を変更するために使用できる方法は 4 種類あります。これらは強力なオプションであるので、注意して使用する必要があります。グループ ポリシー処理の動作が大幅に変更される場合があるためです。トラブルシューティングも難しくなる場合があります。既定の継承を変更するためのオプションには、次の 4 つの設定と構成があります。
  • ブロック ポリシー継承
  • GPO の適用
  • アクセス制御リスト (ACL) の GPO フィルタ処理
  • Windows Management Instrumentation (WMI) フィルタ
これらの設定は注意して使用する必要があるので、これらがいつ使用されるかは簡単に文書化できるはずです。これらのオプションが使用されているかどうかを判断するには、GPMC を確認します。ブロック継承は、GPMC 内のドメインまたは組織単位 (OU) ノードで実行します。GPO の適用、ACL のフィルタ処理、および WMI のフィルタ処理は、各 GPO で設定します。
または、ターゲット コンピュータから Gpresult コマンドを実行し、これらの設定のいずれかによってポリシーの適用が阻止されているかどうかを確認することもできます。適用されているポリシーの結果セットをさらに詳しく表示するには、/v スイッチを Gpresult コマンドに追加して、詳細出力を行います。

ADM テンプレートに関する問題
GPO の管理用テンプレート セクションの設定の構成では、ADM テンプレートを使用します。オペレーティング システムに付属の ADM テンプレートに加えて、GPO 用の独自のテンプレートをカスタマイズすることもできます。ADM テンプレート内のコードにより、グループ ポリシー エディタの管理用テンプレート ノードの下にフォルダとポリシーが作成されます。ただし、ADM テンプレートが壊れているか、欠如しているか、適切に構成されていない場合は、エディタにこれらの設定の一部またはすべてが表示されない可能性があります。ADM テンプレートの使用中に注意する必要があるその他の点は次のとおりです。
欠如している ADM テンプレート GPO の編集中に、カスタム ADM テンプレートの一部の設定がエディタに表示されていないことに気づいた場合は、ADM テンプレートを GPO にインポートする必要があります。インポートするには、エディタで管理用テンプレート ノードを右クリックし、[テンプレートの追加と削除] を選択します。
欠如している基本設定 カスタム GPO には 2 種類の設定を作成できます。これらは基本設定とポリシーです。ポリシーは、レジストリ内の 4 つのサブキーのいずれかに属している既定のマイクロソフト設定で、各ポリシーの終わりには "Policies" のテキストが付いています。基本設定は、4 つのサブキーのいずれにも属さない "古いスタイル" のレジストリ変更で、いったん構成した後に元に戻すのは困難です。これらの基本設定は、既定ではエディタに表示されません。これらを表示するには、ツールバーの [表示] メニューで有効にする必要があります。このメニューから、[フィルタ] を選択し、[完全に管理されているポリシー設定のみ表示します] チェックボックスをオンにします。これにより、インポートされているカスタム ADM テンプレートで構成されている基本設定が直ちに表示されます。

便利なツール
グループ ポリシーに関する問題を解決するにあたっては、数多くのツールが用意されています。一部のツールはオペレーティング システムに組み込まれており、その他のツールはダウンロードしてインストールします。ここで、作業に適したツールを選択できるようになるために、適切なツールについて説明しましょう。
Dcgpofix 2 つの既定の GPO のどちらかに関して問題が発生することがあります。その 2 つとは、既定のドメイン ポリシーと既定のドメイン コントローラ ポリシーです。これらの GPO のどちらかまたは両方が壊れ、修正不可能なほどに構成がおかしくなっているか、または他の不明な問題が存在する場合は、dcgpofix ツールを使用して GPO を既定の状態に戻すことができます。このツールは Windows Server® 2003 に付属しています。このツールは Windows 2000 ドイメン コントローラでは実行しないでください。代わりに Recreatedefpol を使用してください。また、このツールを使用すると、カスタマイズした設定がすべて失われることを覚えておいてください。
Recreatedefpol このツールは Dcgpofix と似ていますが、Windows 2000 サーバーを対象としています。このツールを使用すると、2 つの既定の GPO を新たにインストールしたときの状態に戻すことができます。このツールは、GPO の定期的な保守作業ではなく、障害回復時にのみ使用してください。このツールはここからダウンロード (英語) できます。
イベント ビューア イベント ビューアには、グループ ポリシーに関する情報が満載されています。ただし、グループ ポリシーのエントリを探すには、すべてのログ ファイルを検索する必要があります。ログ ファイルには、ポリシーの適用、レプリケーション、および更新に関するエントリが含まれています。これらはすべて、問題を突き止める際に役立ちます。イベント ログには特定のグループ ポリシー エラーに関する多くの情報が必ずしも存在するとは限りませんが、識別できないエラーがあるときには、いつでも TechNet を検索できることを覚えておいてください。
Gpresult このツールは、ローカルのターゲット コンピュータでのみ実行できますが、ポリシーの結果セット (RSoP)、ブロックされている GPO、GPO に対するアクセス許可など、多くの情報を提供します。/v スイッチと共にこのコマンドを使用すると、コンピュータに影響を及ぼしている GPO と、現在のログオン セッションに関連付けられているユーザー アカウントに関する詳細な情報が表示されます。
Gpupdate 新しい GPO 設定を実装するか、GPO 処理がすべて実行されていることを確認する場合は、Gpupdate ツールを使用できます。これは、オペレーティング システム (Windows XP 以上) に付属のコマンドライン ツールです。このツールを実行すると、バックグラウンドの更新がトリガされ、この種類の更新に関する GPO 設定がすべて適用されます。/force スイッチを追加すると、前回の更新後に GPO が全く変更されていない場合でも、GPO 設定がすべて再適用されます。Gpresult コマンドを実行する前にこのコマンドを実行すると、GPO 問題の追跡に役立ちます。
Gpotool GPO は、GPO が最初に作成されたドメイン コントローラから他のすべてのドメイン コントローラにレプリケートされるので、レプリケーション エラーや効率の悪い収束が発生する場合があります。その結果、ターゲット コンピュータに変更が一貫して適用されなかったり、まったく適用されない事態が発生します。Gpresult や RSOP などのツールでは、どの GPO が適用されているかを判断できますが、この Gpotool ツールでは、各ドメイン コントローラの GPO が一貫しているかどうかを判断できます。このツールは、go.microsoft.com/fwlink/?LinkId=77613 (英語) から入手可能な Windows Server 2003 Resource Kit に含まれています。
Replmon 1 つのドメイン コントローラから別のドメイン コントローラへの GPO のレプリケーションをトラブルシューティングする場合は、レプリケーションを適切に行うために使用できるツールについて理解しておくことが重要です。GPO にはレプリケーションが必要な部分が 2 つあるので、2 つの部分をそれぞれ調査する必要があります。最初の部分は、各ドメイン コントローラの SYSVOL の内容で、これはファイル複製サービス (FRS) によって制御されています。このレプリケーションを制御するためにできることは、レプリケーション間隔のトリガに役立つサービスの無効化と有効化以外にほとんどありません。GPO のもう 1 つの部分は、Active Directory に格納されており、これは Active Directory レプリケーションによって制御されます。このレプリケーションは、Active Directory サイトとサービスを使用することで、1 つの Active Directory サイト内のドメイン コントローラ間で制御できます。ただし、異なる Active Directory サイトのドメイン コントローラ間のレプリケーションをトリガする必要がある場合は、Replmon などのツールを使用する必要があります。Replmon は、サイトの境界を越えて Active Directory データベースのレプリケーションを強制できますが、Active Directory のサイトとサービスでは強制できません。したがって、Active Directory に格納されているグループ ポリシー情報が一致していない場合は、Replmon を使用してレプリケーション プロセスをトリガし、各ドメイン コントローラに収束された情報を取得できます。Replmon は、Resource Kit および Windows XP Support Tools に含まれています。このツールは go.microsoft.com/fwlink/?LinkId=77614 (英語) からダウンロードできます。
RSOP コマンド ライン ツール Gpresult と似ていますが、RSOP は、すべての GPO によって適用されている設定を表示するためのグラフィック インターフェイスを提供します。RSOP.MSC は Windows XP Professional および Windows Server 2003 に組み込まれているツールです。このツールは、図 5 に示すように、適用されたすべてのポリシー設定の結果をグループ ポリシー オブジェクト エディタと同じような形式で表示します。
図 5 ポリシーの結果セット ツール
図 5 ポリシーの結果セット ツール

まとめ
グループ ポリシーに関する問題のトラブルシューティングは、簡単なタスクではありません。実際、この記事で示しているように、グループ ポリシーは複雑な場合があります。グループ ポリシーをトラブルシューティングする際は、グループ ポリシーの中核となるアーキテクチャとグループ ポリシーに特有の総合的な処理について理解する必要があります。また、GPO が更新、レプリケート、処理、および適用される方法についても理解する必要があります。これらの概念をすべて正しく理解すると、どのようなグループ ポリシー問題でも容易にトラブルシューティングできるようになります。この記事のガイドラインに従い、適切なツールを使用すれば、遭遇したあらゆるグループ ポリシー問題に対処する準備が整います。

Derek Melberは、Microsoft の完全子会社、DesktopStandard の Director of Education, Certification, and Compliance Solutions です。Derek は、『Microsoft Windows Group Policy Guide』(英語) (Microsoft Press、2005) を共同執筆しています。また、Windows セキュリティの監査に関する一連の書籍 (www.theiia.org) も執筆しています。彼の連絡先は derekm@desktopstandard.com (英語) です。


 Windows の管理: MOM での Active Directory の監視
Windows の管理 John Hann

MOM での Active Directory の監視
概要:
  • Active Directory の管理パック
  • MOM をカスタマイズするためのヒント
  • Alert Tuning

管理パックは、Microsoft Operations Manager (MOM) 2005 の活力のもとであり、MOM を他の管理製品から差別化するものでもあります。MOM では管理パックを使用してルール、レポート、タスク、ビューを組み立てます。また、Active Directory などの特定のアプリケーションまたはサービスに範囲を限定できます。
Microsoft 製品チームは、開発するアプリケーションの管理パックを作成し、製品に関するチームの豊富な知識が MOM に反映されるようにしています。さらに、管理パックはそれぞれの IT 環境に合わせてカスタマイズできます。それにより、特定のサーバーおよびアプリケーション環境に基づき、製品を監視および管理するためのルールが成立します。
Active Directory® 固有の管理パックだけではなく、Windows Server® 基本オペレーティング システムから動的ホスト構成プロトコル (DHCP)、DNS、およびファイル レプリケーション サービス (FRS) まで、ディレクトリ サービスの状態を評価するための管理パックは多数あります。MOM で可能な Active Directory のエンド ツー エンドの管理についてよく理解するために、これらの管理パックについて詳しく検討しましょう。

DHCP 管理パック
DHCP サービス管理パックでは、Windows NT®、Windows® 2000、および Windows Server 2003 で実行されている DHCP サービスを監視します。クライアントのネットワーク接続に問題があるかどうかを知るためには、DHCP を監視することをお勧めします。さらに、ご使用の環境で実行されている悪意のある (無許可の) DHCP サーバーについても警告されます。この管理パックのダウンロード パッケージには、ルールやレポート、および監視シナリオや展開について文書化したガイドが含まれています。TechNet MOM 2005 Web サイト (http://www.microsoft.com/japan/technet/prodtechnol/mom/mom2005/default.mspx) には追加の資料やガイドが用意されています。
DHCP を実行している Windows のバージョンが新しいほど、MOM 2005 ではそれを管理するためのインスツルメンテーションと機能が豊富に提供されます。したがって、Windows DHCP サーバーよりも Windows Server 2003 DHCP サーバーに関する情報の方が多く取得できます。たとえば、Windows Server 2003 で実行されている DHCP サーバーでは、スーパースコープが監視されますが、DHCP 管理パックでは、Windows 2000 DHCP サーバーの通常のスコープのみが監視されます。除外するスコープを監視スクリプトのパラメータとして含めることにより、スコープを監視から除外できます。
前に説明したとおり、DHCP 管理パックでは Windows NT、Windows 2000 Server、および Windows Server 2003 で実行されている DHCP サーバーがサポートされています。コンピュータ グループは、オペレーティング システムのバージョン、およびサーバーが DHCP サーバー サービスをホストするかどうかを使用する数式によって作成されます。
DHCP 管理パックでは、特権の低い構成はサポートされません。エージェント アクション アカウントは、ローカル Administrators グループのメンバである必要があります。エージェントなしの監視はサポートされていますが、エージェントなしの構成ではタスクはサポートされません。図 1 は、DHCP 管理パックで使用できるレポートを示しています。
Figure 1 DHCP サービス レポート (Close Figure 1)

すべての DHCP サーバー
すべての認証済み DHCP サーバー
パフォーマンス ヒストリ - Active Queue Length
パフォーマンス ヒストリ - Conflict Check Queue Length
パフォーマンス ヒストリ - Declines per Second
パフォーマンス ヒストリ - Discovers per Second
パフォーマンス ヒストリ - Milliseconds per Packet (Avg)
パフォーマンス ヒストリ - NACKs per Second
パフォーマンス ヒストリ - Scope Free Addresses
パフォーマンス ヒストリ - Scope Addresses in Use
パフォーマンス ヒストリ - Superscope Free Addresses
パフォーマンス ヒストリ - Superscope Addresses in Use
DHCP 管理パックは、go.microsoft.com/fwlink/?LinkId=79527 (英語) からダウンロードできます。

DNS 管理パック
ドメイン ネーム サービス管理パックでは、Windows 2000 Server および Windows Server 2003 で実行されている DNS が監視されます。DNS は Active Directory 全体の状態に不可欠な部分であるため、MOM 2005 で DNS を監視することは非常に重要です。DNS 管理パックでは、名前解決の問題、データベースの問題、レジストリの問題、ランタイム イベントおよびエラーのほか、関連のパフォーマンス カウンタを監視します。
Windows 2000 Server の場合は、Windows Management Instrumentation (WMI) DNS プロバイダをインストールする必要があります。これにより、DNS 管理パックは、WMI DNS 名前空間で情報とテストのクエリを実行できます。
コンピュータ グループはすべて、オペレーティング システムのバージョン、およびサーバーが DNS サーバー サービスをホストするかどうかを使用してグループ メンバシップを決定する数式によって作成されます。DNS 管理パックでは、Windows Server 2003 上のみで低い特権をサポートしています。Windows 2000 では、アクション アカウントは、ローカル Administrators グループのメンバである必要があります。Windows Server 2003 では、アクション アカウントは、ローカル Users グループおよび Performance Monitor Users グループのメンバである必要があります。加えて、アクション アカウントには、"監査およびセキュリティ ログの管理" (SeSecurityPrivilege) 権限および "ローカル ログオンを許可する" (SeInteractiveLogonRight) 権限が必要です。図 2 は、DNS 管理パックで使用できるレポートを示しています。
Figure 2 DNS サービス レポート (Close Figure 2)

すべての Windows DNS サーバー
ゾーン別すべての Windows DNS サーバー
サーバー別すべての Windows DNS ゾーン
Microsoft® Systems Management Server (SMS) の MVP である Marcus Oh は、nslookup を呼び出して DNS サーバーの名前解決機能を確認することにより DNS サーバーをテストするスクリプトを開発しました。marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html (英語) に掲載された Marcus のブログをお読みください。このスクリプトを DNS 管理パックに統合することをお勧めします。
DNS 管理パックは、http://www.microsoft.com/downloads/details.aspx?familyid=2AF941FE-5931-4971-9392-A88BBE577D8C&displaylang=ja からダウンロードできます。

FRS 管理パック
Windows ファイル レプリケーション サービス管理パックでは、Windows 2000 および Windows Server 2003 で実行されている FRS サービスを監視します。FRS は、ドメイン コントローラでログオン スクリプトとグループ ポリシー情報をレプリケートするために使用されます。FRS 管理パックは、各ドメイン コントローラの FRS サービスの状態を詳しく示します。
FRS 管理パックでは、go.microsoft.com/fwlink/?LinkId=79529 (英語) からダウンロードできる Ultrasound ツールを利用しています。Ultrasound は、各ドメイン コントローラに FRS の WMI 名前空間を作成します。Ultrasound は、データベースを必要とし、各ドメイン コントローラに関する WMI 名前空間からの情報を状態の監視のために保存します。Ultrasound からの情報を使用することにより、FRS 管理パックではレプリカ セット、メンバ、接続、FRS サービス自体、および Ultrasound コントローラ サービスの監視が可能です。
実際に、Ultrasound は、管理サーバーとは異なるサーバーにインストールしてください。Ultrasound ルールは、他のコンピュータに代わってイベントやアラートを生成します。Ultrasound ルールでデータを正しく処理するには、Ultrasound を実行している各サーバー上の MOM 管理コンソールでエージェント プロキシを有効にする必要があります。図 3 は、FRS 管理パックで使用できる 4 つのサービス レポートを示しています。
Figure 3 FRS サービス レポート (Close Figure 3)

Ultrasound - よく検出される問題 - 問題の多い接続
Ultrasound - よく検出される問題 - 問題の多いメンバ
Ultrasound - よく検出される問題 - 問題の多いレプリカ セット
Ultrasound - よく検出される問題 - まとめ
この管理パックに関連するコンピュータ グループには、Windows 2000 Server、および Windows Server 2003 で実行されている Microsoft Ultrasound 1.0 サーバーと FRS サーバーが含まれます。コンピュータ グループはすべて、オペレーティング システムのバージョン、およびサーバーが DNS サーバー サービスをホストするかどうかを使用してグループ メンバシップを決定する数式によって作成されます。Ultrasound Servers グループは、サーバーに Ultrasound がインストールされると作成されます。
低い特権用に FRS 管理パックを構成した場合、タスクは機能しませんが、残りの管理パック機能はサポートされます。アクション アカウントには、Ultrasound データベースの読み取りアクセス、および GetControllerStatusForMOM001 ストアド プロシージャの実行権限が必要です。FRS 管理パックには、エージェントなしのコンピュータ、およびエージェント管理のコンピュータの監視が含まれます。
FRS 管理パックは、http://www.microsoft.com/downloads/details.aspx?familyid=FBF5958E-F061-4C53-8623-0248A99A4B16&displaylang=ja からダウンロードできます。

Windows Server 管理パック
Windows 基本オペレーティング システム管理パックでは、Windows NT 4.0 Server、Windows 2000 Server、および Windows Server 2003 を監視します。基本 OS 管理パックは、ドメイン コントローラのオペレーティング システムの状態を報告するほか、システム上のルート サービスも監視します。管理パックは、コア Windows サービス、メモリ、およびプロセッサのパフォーマンスに加えて、ディスクの空き領域やディスクの待ち時間などの情報も提供します。この管理パック、およびこの記事で取り上げた他の管理パックの監視ルール間では、ある程度の重複がありますが、ドメイン コントローラの状態のわかりやすいボトムアップ ビューが提供されます。
図 4 は、基本 OS 管理パックで使用できるレポートを示しています。他の管理パックと同様に、コンピュータ グループはすべて、オペレーティング システムのバージョンを使用する数式によって作成されます。
低い特権での操作用に基本 OS 管理パックを構成する場合、Windows 2000 ではアクション アカウントがローカル Administrators グループのメンバである必要があります。Windows Server 2003 では、アクション アカウントがローカルの Users および Performance Monitor Users グループのメンバである必要があるほか、"監査およびセキュリティ ログの管理" (SeSecurityPrivilege) 権限および "ローカル ログオンを許可する" (SeInteractiveLog-onRight) 権限を持っている必要があります。タスクを除き、基本 OS 管理パックのほとんどは、エージェントなしの監視対象コンピュータでサポートされています。
基本 OS 管理パックは、http://www.microsoft.com/downloads/details.aspx?familyid=E553062F-BD85-4772-8037-8B91F457B710&displaylang=ja からダウンロードできます。

Active Directory 管理パック
Active Directory 管理パックは非常に広範囲に及び、そのルールは Windows 2000 Server と Windows Server 2003 の両方を対象としています。Active Directory 管理パックのルールは、クライアント側の監視、信頼の監視、レプリケーションの監視、およびトポロジの検出に加え、Windows 2000 Server および Windows Server 2003 オペレーティング システムを対象とするルールなど、5 つの分野に及びます。前に説明したとおり、新しいバージョンの Windows では、さらに多くのインスツルメンテーションが有効になるため、追加の監視が可能になります。たとえば、管理パックでは、Windows Server 2003 上での信頼の監視がサポートされますが、Windows 2000 ではサポートされません。
Active Directory 管理パックでは、特定のコンピュータにルールを適用するために使用するグループを多数作成します。クライアント側の監視ルールでは、Active Directory Client Side Monitoring (Active Directory クライアント側の監視) というグループを使用します。MOM がインストールされたコンピュータをこのグループに含め、これらのルールを監視し、管理します。エージェントと共にライセンスされたいくつかのデスクトップ コンピュータ、および Exchange Server の一部をこのグループに含めました。Exchange Server では Active Directory を頻繁に使用するため、問題発生の主要なインジケータとなります。このグループ内のデスクトップ コンピュータにより、エンド ユーザーの操作性を評価できます。クライアント側の監視のルールでは、スクリプトを利用することにより、LDAP を介してクエリの実行、および障害の報告を行って、ドメイン コントローラへの接続をテストします。クライアント側の監視ルールは、プロキシが有効になっているがドメイン コントローラは含まれないエージェント管理のコンピュータにのみ適用できます。
信頼の監視ルールでは、Active Directory Trust Monitoring (Active Directory 信頼の監視) というグループを使用します。Windows Servers 2003 コンピュータは、このグループに含めて信頼をテストします。Windows Server 2003 には、信頼の監視のための WMI 名前空間があります。WMI 名前空間に対してクエリを実行するために、これらのルールによってスクリプトが採用されます。他のドメインで信頼エラーが検出されると、これらのルールによってアラートが発行されます。
Windows 2000 Server または Windows Server 2003 に適用される Active Directory 管理パック ルールは多数あります。これらのルールにより、2 つのオペレーティング システム間の Active Directory の実装方法の違いが明確になります。ただし、Active Directory 管理パックのほとんどは、両方のオペレーティング システムを合わせたルールに含まれます。これらのルールの一部には、メイン コントローラ間の接続をテストするスクリプト、Flexible Single Master Operation (FSMO) 役割所有者の検証、ディレクトリ情報ツリー (DIT) データベース サイズ、グループ ポリシーの処理の検証、知識整合性チェッカー (KCC) 検査、サイト間メッセージング サービス テストなどがあります。
レプリケーションの監視は、Active Directory 管理パックの中心的な機能です。レプリケーションの監視の報告のみに使用するドメイン コントローラを構成するために、Active Directory Replication Latency Data Collection (ソース) と Active Directory Replication Latency Data Collection (ターゲット) の 2 つのグループが用意されています。レプリケーション レイテンシは、データ コレクション グループ内のデータのメンバごとに計算されます。パフォーマンス カウンタは、各グループ メンバに更新がレプリケートされるまでの所要時間によって、値が設定されます。定義されたしきい値を上回る場合は、全社規模のレプリケーション レイテンシが計算および報告されます (そしてアラートが生成されます)。レプリケーションの監視の WMI 名前空間は、Windows 2000 Server にインストールされる必要があります。
Active Directory 管理パックのトポロジの検出は、実装のダイアグラムの作成に使用します。これらの便利なダイアグラムは、Microsoft Office Visio® にエクスポートできます。ダイアグラムは、MOM によってリアルタイムで構築されるため、数秒で最新のバージョンを作成できます。
MOM 2005 オペレータ コンソールの "ダイアグラムの表示" には、3 つの Active Directory 管理パック ダイアグラムがあります。"Broken Connection Objects (接続エラー オブジェクト)" ダイアグラム (図 5 を参照) は、エラー状態のすべての接続を示します。接続エラーがないときは、このダイアグラムが空白の場合があります。
図 5 ダイアグラムの表示 では接続エラーがハイライトされています。
図 5 ダイアグラムの表示 では接続エラーがハイライトされています。
接続オブジェクト ダイアグラムでは DC 間の接続がハイライトされています。.サイト リンク ダイアグラムは、各 Active Directory サイトを示しており、そのサイトの該当するドメイン コントローラと接続サイト リンクがカプセル化されています。
これらのビューのために MOM で作成されたダイアグラムは動的であるため、それらを Visio にエクスポートして、簡単に編集およびカスタマイズを実行できます。たとえば、図 6 は、サイト リンク ダイアグラムを Visio で編集しているところを示しています。
図 6 Visio でのサイト リンク ダイアグラムの編集
図 6 Visio でのサイト リンク ダイアグラムの編集 (画像を縮小するには、ここをクリックします)
図 6 Visio でのサイト リンク ダイアグラムの編集
図 6 Visio でのサイト リンク ダイアグラムの編集 (画像を拡大するには、ここをクリックします)
図 7 は、Active Directory 管理パックで使用できるレポートを示しています。この管理パックに関連するコンピュータ グループは図 8 に示されています。ご覧のとおり Active Directory コンピュータ グループは、明示的なメンバシップによって作成されます。Windows コンピュータ グループは、オペレーティング システムのバージョンと、マシンがドメイン コントロールであるかどうかに従って作成されます。
Figure 8 コンピュータ グループ (Close Figure 8)

Active Directory クライアント側の監視
Active Directory レプリケーション レイテンシ データ
コレクション - ソース
Active Directory レプリケーション レイテンシ データ
コレクション - ターゲット
Active Directory 信頼の監視
Windows 2000 Server ドメイン コントローラ
Windows 2003 Server ドメイン コントローラ
Active Directory 管理パックは、Windows Server 2003 ドメイン コントローラ上で低い権限用に構成できます。管理パックでは、エージェントなしの監視はサポートされません。Windows 2000 Server では、エージェント アクション アカウントは、Domain Admins またはローカル Administrators グループに含まれている必要があります。Windows Server 2003 ドメイン コントローラのアクション アカウントでは、低い権限用に追加のアクセス許可が構成されている必要があります。これには、Users および Performance Monitor Users グループのメンバシップ、イベント ログへのアクセス、および SeSecurityPrivilege、SeAuditPrivilege、および SeInteractiveLogonRight の権限が含まれます。さらに、次のアクセスが必要です。レプリケーションの監視のための Active Directory の CN=MomLatencyMonitors Container へのフル アクセス、NTDS.dit データベースとログ ファイルを格納するディレクトリへの読み取りアクセス、および次のレジストリ キーに対する読み取りアクセス。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Windows Server 2003 で監視する場合は、スクリプト AD Monitor Trusts では、エージェント アクション アカウントに Domain Admin グループまたは Administrators グループのメンバである必要があります。
Active Directory 管理パックは、http://www.microsoft.com/downloads/details.aspx?familyid=B516E614-814A-4277-ABF9-8D5315D2BA06&displaylang=ja からダウンロードできます。

Active Directory 用の MOM のカスタマイズ
Active Directory 管理パックを構成する必要があります。これを行わないとコンソールはアラートでいっぱいの状態が続きます。Active Directory 管理パックでアラートが最多になるのは、ドメイン コントローラが再起動する際で、あらゆるアラートがトリガされるように見えます。不都合なことに、これを停止するのは容易ではありません。最善策は、MOM 内のメンテナンス モードを利用して、予定されているメンテナンスの時間中にアラートを制御することです。メンテナンス モードの目的は、コンソールがいっぱいにならないように、ドメイン コントローラのアラートを自動解決することです。
クライアント コンピュータと該当するサーバーをグループに含めることにより、必ず Active Directory Client Side Monitoring (クライアント側の監視) グループを構成してください。このグループに関連するルールは、FSMO およびそれらへの接続の状態を判断するために役立ちます。
LDAP、PING、および DNS を使用して FSMO にバインドし接続を検証するためのしきい値を使用するパフォーマンス ルールがあります。これらのルールは、Active Directory Availability パフォーマンス ルール内にあります。アラートの重要度を設定することにより、これらのルールで使用するしきい値をカスタマイズしてください。たとえば、FSMO バインドでは、秒単位の属性値を使用します。各 FSMO 役割のパフォーマンス ルールではこのアラート作成方法論を使用しています。
"状態ルールのアラートの重要度の計算" の設定について理解することが重要です。このダイアログ ボックスでは、属性値に If-Else 条件を使用し、アラートの重要度を設定します (図 9 を参照)。AD Op Master Response スクリプトによって作成された Last Bind パフォーマンス カウンタがルールによって収集される際、これらのルールによって設定された条件しきい値に対してそれらがチェックされます。これらの異なるアラート レベルは、環境に合わせて構成する必要があります。
図 9 アラートの重要度ルールの設定
図 9 アラートの重要度ルールの設定 (画像を縮小するには、ここをクリックします)
図 9 アラートの重要度ルールの設定
図 9 アラートの重要度ルールの設定 (画像を拡大するには、ここをクリックします)
各ドメイン コントローラのレプリケーション スケジュールを確認してください。特定のドメイン コントローラのスケジュールが他と異なる場合、レプリケーション レイテンシの結果に誤差が生じ、しきい値を高く設定する原因となります。特定の環境のニーズに適したレプリケーション スクリプトのパラメータを設定する必要があります。いずれかのドメイン コントローラがダウンしている場合や、レプリケーションの問題がある場合、これらのグループの他のすべてのドメイン コントローラにおいても、そのドメイン コントローラが直接のレプリケーション パートナーでなくても、そのレプリケーション エラーが報告される場合があります。したがって、問題のあるドメイン コントローラをメンテナンス モードにしていても、他のドメイン コントローラがレプリケーション エラーを報告する可能性があります。
レプリケーションの監視は、Active Directory 管理パックの調整において最も重視する必要があります。ご使用の環境で管理パックを 2 週間ほど実行して、そのアラートの発生状況を確認する必要があります。一定の傾向が見えてきたら、レポートを使用してレイテンシの概要を述べ、それに応じてしきい値を調整してください。
最後に、Alert Tuning Solution Accelerator (英語) を参照してください。

今後の展望
MOM 2005 および Active Directory 管理パックを使用すると、組織の Active Directory 実装を効果的かつ能率的に監視できます。Active Directory、DHCP、DNS、FRS、および Windows Server 基本 OS 管理パックにより、インフラストラクチャの多くの局面をより効果的に監視でき、Active Directory インフラストラクチャの状態ユーザーを保護できます。レポート データ ウェアハウスに収集された膨大なデータを使用し、パフォーマンスやイベントのデータを分析し、容量計画やパフォーマンスの傾向判定に役立てることができます。
この記事、およびその他多数の記事で取り上げられている管理パックについては、Management Pack Catalog (英語) を参照してください。
Active Directory 管理パックの次の更新には、通常の修正プログラムのコレクションや、いくつかのしきい値の微調整が含まれます。さらに興味深いのは、この製品の次のリリースで計画されている新機能 System Center Operations Manager 2007 です。これには、1 つの構成グループから複数のフォレストを監視する機能、ドメイン コントローラ (それぞれ他のグループとの独自のレプリケーション レイテンシを持つ) のグループを定義する機能、および次のバージョンの Window Server で実行されるドメイン コントローラを監視する機能が含まれます。詳細については、MOM Web サイト (microsoft.com/japan/mom/default.mspx) を参照してください。

John Hann は MOM 2000 からの MOM に従事し、2004 以来 MOM MVP です。彼は MyITForum.com(英語)、MOMCommunity.com(英語)、および LearnMOM.com(英語) の寄稿者です。John に対するお問い合わせについては、彼のブログ (英語) を参照してください。


 Windows の管理: セキュリティ環境でのゲーム プレイ
Windows の管理 Matt Clapham

セキュリティ環境でのゲーム プレイ
概要:
  • 保護されたフォルダおよびレジストリ キーへの書き込みに関する問題
  • コピー防止機能によるエラー
  • ファイアウォールの例外要求による問題
  • エンタープライズ クライアントの問題

私はマイクロソフトの Security Program Manager として勤務しています。また、TechNet Magazine にもセキュリティに関する記事を投稿しています。言うまでもないことですが、私はセキュリティを非常に重視しています。もちろん、趣味もあります。
余暇には、Windows® ベースのゲームを楽しんでいます。特に、シューティング ゲーム、シミュレーション、ロールプレイング、そして RTS (real-time strategy) ゲームを好んでプレイしています。ただし、これには落とし穴があります。友人の Jesper Johansson と Aaron Margosis と同様に、どうしても必要な場合を除き、私は管理者特権でゲームを実行しないようにしています。その理由は、ネットワーク ゲームで 0wn3d が発生するのは私のスキル不足が原因で、他のユーザーがルートキットで私を妨害しているためではないことを確実にするためです (「詳細情報」サイドバーの「Quake 3 Buffer Overflow Advisory」を参照してください)。
そのため、最新のゲームをプレイできないこともあります (図 1 を参照)。私は、管理者アカウントでゲームのインストールおよび更新を行った後、Small Business Server (SBS) ドメインに参加しているクライアント上で制限付きユーザー アカウント (LUA) でゲームを実行できない場合、そのゲームは削除しています。そのようなお粗末なエンジニアリングには付き合っていられませんし、ゲームは他にも沢山あります。過剰反応かもしれませんが、この点は妥協できません。それでも、私はゲームの向上のために小さな欠点を改善することに反対するものではありません。今日は、この点について説明します。まず、私がこれまで経験したゲーム関連の問題とその解決方法を紹介しましょう。ベスト プラクティスの概要については、「制限付きユーザーとしてゲームをプレイするためのヒント」を参照してください。
図 1 手動更新を実行する際のファイル アクセスの問題
図 1 手動更新を実行する際のファイル アクセスの問題 (画像を縮小するには、ここをクリックします)
図 1 手動更新を実行する際のファイル アクセスの問題
図 1 手動更新を実行する際のファイル アクセスの問題 (画像を拡大するには、ここをクリックします)

一般的な問題
この特権の問題は新しいものではありません。多くのゲームおよびその他のプログラムには、適切に実行するために管理者特権が必要なものがあります。詳細については、マイクロソフト サポート技術情報の「制限付きのユーザー アカウントを使用してログオンした場合、一部のプログラムが正しく動作しない」 (support.microsoft.com/kb/307091) を参照してください。この記事には、制限付きユーザーとして実行する際に問題が発生する約 200 のゲームとアプリケーションの一覧が記載されています (少数ながらマイクロソフトのプログラムも含まれています)。
断っておきますが、私は、ゲームをインストールすることや (手動で) 更新する際に管理者特権が必要であることが問題と考えているわけではありません。これは将来、Windows 上で定期的なユーザーごとのインストールを行う機能が利用できるようになるまでは、一般的に必要なことです。このような機能が利用可能になるまでにそれほど時間はかからないと思います。しかし、ゲームをインストールおよび更新した後は、システムのすべてのユーザーがプレイできるはずです。制限付き特権のユーザーも同様です。
保護されたフォルダおよびレジストリ キーへの書き込みに関する問題 私が遭遇した最も一般的な問題は、ゲームが保護されたフォルダまたはレジストリ キーへの書き込みを行おうとするために起動時またはプレイ中にエラーが発生することです (多くの Windows ベースのアプリケーションで一般的な問題です)。既定では、特定のフォルダ (%PROGRAMFILES% など) およびレジストリ ハイブ (HKEY_LOCAL_MACHINE など) に書き込むことができるのは、管理者 (および以前サポートされていた Power Users) だけです。このようなエラーは比較的わかりやすく、「Error 42: Can't write log files to C:\Program Files\CoolGamesInc\NewestFPS\Logs\ (エラー 42: C:\Program Files\CoolGamesInc\NewestFPS\Logs\ にログ ファイルを書き込めません)」 または「Game not installed properly, reinstall and restart. (ゲームが正しくインストールされていません。再インストールしてください。)」というメッセージが表示されます。ゲームをプレイしているとき (現在のステージを保存する際など) にエラー メッセージが表示されることもあります。Age of Mythology® のように、機能させるためには管理者特権が必要であることをユーザーに通知するゲームもあります。頻繁に更新されることに加えて、自己更新プログラムは技術的に解決することが少し難しいため、特権に関する問題は MMOG (Massively Multiplayer Online Game) で多く発生することがあります。私は、EVE Online を試したとき、ログ ファイルが不適切な場所に配置されることに加えて、自己更新ゲーム コンテンツ データがインストール フォルダに配置されることに気付きました。
コピー防止機能によるエラー ゲームの起動に失敗する一般的なもう 1 つの理由は、制限付きユーザーではゲームに組み込まれたコピー防止機能 (またはその他の著作権保護機能) が機能しないからです。この場合、ドライバが適切に起動しなかったり、バックグラウンド サービスが実行していないなどの問題が発生します。この問題で私が遭遇した最も典型的な例は、必要なメディアがドライブに挿入されていてもディスクの挿入が要求されることです。また、管理者だけがコピー防止チェックを適切に実行できるという間違った考えから管理者特権が要求されるゲームもあります。最悪の場合、ゲームのサポート サイトへの参照も含まず、意味もなさないエラー メッセージが表示されることがあります。
ファイアウォールの例外要求による問題 ローカル ネットワークまたはインターネット上でプレイできるマルチプレーヤー ゲームは広く一般に浸透しているので、Windows XP Service Pack 2 (SP2) には、アプリケーションがネットワークをリスンしようとしているときにユーザーに警告メッセージを表示する機能が追加されています。このことが次に一般的な問題の原因となり、ファイアウォール例外が必要なゲームの起動時に、この例外が追加されないという現象が発生します。制限付きユーザーはファイアウォール構成を変更できないので、この警告 (図 2) に対応するには管理者に構成変更を依頼する必要があります。さらに悪いことに、警告がゲームのインターフェイスではなく Windows シェルに表示される場合は、問題を見つけることが困難です。実際、ゲームを終了するまでエラー メッセージが見えないこともあります。
図 2 ファイアウォールの設定による問題
図 2 ファイアウォールの設定による問題 (画像を縮小するには、ここをクリックします)
図 2 ファイアウォールの設定による問題
図 2 ファイアウォールの設定による問題 (画像を拡大するには、ここをクリックします)
エンタープライズ クライアントの問題 制限付きユーザーとして実行することに直接関連するものではありませんが、紹介しておくべきその他の例もあります。私は、スモール エンタープライズと同様のホーム コンピューティング環境を実行しています (詳細については、私が Jesper Johansson と共同で TechNet Magazine 2006 年 10 月号に投稿した「Master Your Domain: Build a Corporate Network at Home」(英語) を参照してください)。私は、SBS 2003 (R2) を使用して、完全な Windows ドメインをセットアップしています。この環境では、マイ ドキュメント フォルダはサーバー共有にリダイレクトされます。ここで最後に説明するエンタープライズ クライアントを処理できないゲームという問題を発見したのは、この環境においてです。
私は、Age of Empires® III (AoE3) に 2 つの問題があることに気付きました。このゲームを開発したチームのために断っておきますが、ゲームは制限付きユーザーとして正常に起動してプレイできます。しかし、大量のログ データがネットワーク経由で書き込まれるので、シナリオの読み込みに時間がかかります。さらに、私の構成、保存済みのゲーム、およびゲーム終了時のステージが AoE3 で維持されません。ファイルはマイ ドキュメント フォルダにありますが、それらのファイルはゲームに読み込まれません。これには非常に失望しました。特に、シリーズの以前のタイトルに比べて AoE3 の LUA への対応が向上したことを考えると、実に残念です。
このようなエンタープライズ クライアントの問題を少なくとも認識しているゲームがありました。Fable®: The Lost Chapters™ を試したとき、リモートのマイ ドキュメントはサポートされていないというメッセージが表示され、ゲームが適切に終了しました。サポートされていないシナリオを認識して除外した開発チームは称賛に値します。しかし、数 MB のデータをマイ ドキュメント フォルダに配置できないという理由だけでプレイできないゲームというのも考えものです。

シンプルな解決策
このような問題は、多くのゲームで何度となく遭遇しました。幸いにして、多くの場合には手軽な対応策があります。一番の対応策は、そのゲームを削除して、別のメーカー製から発売されている LUA 対応のタイトルに乗り換えることです。過剰反応と思われることは承知しています。加えて、開封後のゲームは返品できないので、これは理想的な解決策とは言えません。したがって、その他の対応策を考えてみましょう。制限付きユーザーとしてゲームをプレイするためのヒント
  • Windows Vista にアップグレードする。
  • 購入する前にデモを試す (完全バージョンの LUA の問題はデモで確認できるはずです)。
  • LUA で実行する際に問題が発生することが確認されているプログラムの一覧を確認する。
  • ゲームに "Designed for Windows" ロゴが付いていることを確認する。
  • ゲームをインストールおよび更新した後に制限付きユーザーとして実行する。
  • ゲームが制限付きユーザーとして機能しない場合は、メーカーのテクニカル サポート サービスに連絡する。
  • 必要な場合は、システムのローカル Power User アカウントを使用する。

コピー防止機能によるエラーの修正 最初にコピー防止ドライバの問題を見てみましょう。コピー防止システムが存在することに問題はありませんが、そのために管理者以外がゲームを実行できないということは問題です。ほとんどのゲームでは、Macrovision 社の SafeDisc コピー防止メカニズムが採用されていて、オリジナルのゲーム ディスクをチェックするドライバがインストールされます。既定では、ドライバは要求時に起動するように構成されています。これは制限付きユーザーが実行できない機能です。マイクロソフトと Macrovision は修正プログラムを配布していますが、私は別の解決策を見つけました。
  1. 管理者アカウントを使用して、デバイス マネージャを開きます。
  2. [表示] メニューの [非表示デバイスの表示] を選択します。
  3. [プラグ アンド プレイではないドライバ] ノードを展開します。
  4. Security または SecDrv ドライバのプロパティを開きます (
    図 3 コピー防止機能を適切に実行するための解決策 (画像を縮小するには、ここをクリックします)
図 3 コピー防止機能を適切に実行するための解決策
図 3 コピー防止機能を適切に実行するための解決策 (画像を拡大するには、ここをクリックします)
これでコンピュータの起動時にドライバが起動するようになるので、ディスクを挿入してゲームを実行するときには準備が完了しています。
ファイル システムおよびレジストリへの書き込みに関する問題の修正 ゲームだけでなく、現在および過去の多くのプログラムでは、ファイル システムやレジストリのすべての部分への自由なアクセスが前提となっていることが大きな問題です。管理者特権が必要となるさまざまな問題の解決方法の詳細については、Aaron Margosis による記事「Problems of Privilege: Find and Fix LUA Bugs」(英語) を参照してください。
アクセスの問題は追跡するのが少し面倒ですが、必要なファイル、フォルダ、およびレジストリ キーを識別できれば、制限付きユーザーがゲームをプレイできるようにアクセス制御リスト (ACL) を変更することは難しい作業ではありません。ほとんどの場合、以下の手順を使用できます。
  1. microsoft.com/technet/sysinternals (英語) から最新バージョンの Filemon および Regmon を入手します。
  2. これらのツールを管理者として実行してログの収集を開始します。
  3. 管理者としてゲームを数分間プレイし、最も一般的なタスク (新規キャンペーンの開始、ゲームの保存、ネットワーク ゲームのホストなど) を実行します。
  4. Filemon および Regmon からの結果を検証して、ゲームから行われたアクセスを確認します。
  5. 該当するフォルダおよびレジストリ キーの ACL を変更します。
  6. 管理者以外のユーザーとしてゲームを実行して、正常にプレイできることを確認します。
ACL を変更する際は、制限を低くすぎたり ("Everyone" に "フル コントロール" を与えるなど)、高すぎるレベル (HKEY_CLASSES_ROOT など) で制限を低くしたりしないように注意してください。Windows 全体への不正アクセス防止やシステムのセキュリティ保護を行うために、%SYSTEMROOT% や %PROGRAMFILES% などのシステム フォルダのアクセス許可は変更しないでください。
もう 1 つの解決策は、システムのローカル Power User としてゲームを実行することです。これは理想的な解決策ではありませんが、そのシステムに対してローカルなアカウントを使用することにより、何かの問題が発生した場合でも、影響の範囲は 1 台のワークステーションに限定できます。この解決策は、管理者としてしか適切に機能しないほとんどのゲームに対して有効です。
それとは別に、管理者としてゲームを短時間実行することは、ゲームの自己更新を行う際に便利な方法です。私は、管理者としてゲームを実行し、更新オプションを起動してゲームを終了した後に制限付きユーザー アカウントに戻ってゲームをプレイしています (Windows Vista™ では、修正プログラムがオリジナルのメーカーによって署名されているという前提に基づいて、制限付きユーザーでもアプリケーションを更新できます)。
Windows Vista では、ゲームおよびその他のアプリケーションでのファイルおよびレジストリへのアクセスの問題が解決されています。既定では、制限付きユーザーによって実行されるプログラムでは、ファイルおよびレジストリへの間違ったアクセスをユーザー固有のキャッシュにリダイレクトする仮想化 shim が有効になります。私は、Windows 9x の時代に設計され、(アクセス許可の問題が原因で) Windows XP 上で正常に実行しなかったゲーム (The Neverhood など) が、既定の shim で Windows Vista 上で正常に実行するのを見たことがあります。同様の問題があるその他のゲームを Windows Vista で試すのを楽しみにしていますが、Windows Vista で適切な shim 処理が行われないゲームがあるのは間違いないと思います。
ファイアウォールの問題の修正 ファイアウォールの問題は、ゲームをインストールするときに解決できます。しかし、必要なファイアウォールの設定をゲームのセットアップで構成できない場合は、次の方法を試してみてください。
  1. 管理者としてログオンします。
  2. [コントロール パネル] から [Windows ファイアウォール] を開きます。
  3. [例外] タブで、ファイアウォールの例外に追加するプログラムを選択します。
  4. 一覧から目的のゲームを選択するか、ゲームの実行可能ファイルを参照します。
ゲームの実行可能ファイルをファイアウォールの例外に追加することにより、ゲームは、正常に機能するために必要なポートにアクセスできるようになります。
エンタープライズ クライアントの問題の解決 エンタープライズ クライアントで発生するゲームの問題は、数年後にはなくなるはずです。その理由は、複数台のコンピュータとブロードバンド環境がある家庭が増加していることに加えて、家庭で SBS を実行しているユーザーも増えているからです。しかし、現時点では、何らかの解決策が必要です。
私自身の経験では、リダイレクトされたマイ ドキュメントの問題は、システムのローカル LUA を使用することによって解決されました。マイ ドキュメント フォルダがネットワーク フォルダにリダイレクトされていなければ、Age of Empires III および Fable: The Lost Chapters は両方とも制限付きユーザーとして正常に機能しました。詳細情報
  • Quake 3 Buffer Overflow Advisory (英語)
  • Windows Vista Application Development Requirements for User Account Control Compatibility (英語)
  • Windows XP でユーザー アカウントに最小特権の原則を適用する
  • Aaron Margosis’ LUA Buglight tool (英語)
  • Standard User Analyzer (英語)
  • Master Your Own Domain: Build a Corporate Network at Home (英語)
  • Problems of Privilege: Find and Fix LUA Bugs (英語)
  • 制限付きのユーザー アカウントを使用してログオンした場合、一部のプログラムが正しく動作しない

まとめ
管理者以外のユーザーとして実行する際の利点を活用するために、制限付きユーザーとして実行することを強くお勧めします。エンタープライズ環境で最小の権限でゲームをプレイするのは難しいかもしれませんが、不可能ではありません。私は、さまざまなジャンルで制限付きユーザーとして正常に実行できる多くのゲームを長年にわたって見てきました。そして、制限付きユーザーとして実行できないその他のタイトルを機能させるための解決策も見つけました。その一方で、Windows Vista での仮想化により、Windows XP 上では制限付きユーザーとして実行できなかったゲームも機能するようになりました。

Matt Claphamは、マイクロソフトの Security Program Manager であり、シアトルの IT セキュリティ コミュニティの積極的な参加者として、また IT 起業支援プロジェクトにおいてリスク マネジメント チームのメンバとしても活躍しています。


 編集者から: 縁の下の機能向上
編集者から
縁の下の機能向上

Windows Vista は、 2007 年に企業の IT 部門に大きな変革を引き起こします。InformationWeek に掲載された IDC の最新レポートによると、Windows Vista のリリースの直接的な結果として、今年、米国で 100,000 もの IT 関連の雇用が創出されると予想されています。また、今年、全世界で約 9000 万台のマシンに Windows Vista がインストールされ、来年までに出荷されるマシンの 80% には Windows Vista がプレインストールされてることも予測されています。組織は Windows Vista を展開する時期かどうかを判断する必要があります。私たちにお任せください。
今月号の TechNet Magazine から、Windows Vista の動作の中核であるカーネルの詳細をお伝えするシリーズの連載が始まります。Windows Vista は優れた新しいユーザー エクスペリエンスを提供しますが、それだけが Windows Vista に移行すべき理由ではありません。カーネルは OS の心臓部です。そして、Windows Vista のカーネルは大きく機能が向上しています。
このような変更を解説する適任者は、カーネルを熟知している Mark Russinovich 以外に考えられません。Mark Russinovich の『Windows Internals』(David Solomon との共著) は、バックグラウンドで行われている処理を理解する際の最高のリソースです。
今月号では、Mark Russinovich が、デスクトップ アプリケーションの応答速度を向上させる CPU 割り当ての向上について解説し、Windows Vista のマルチメディア パフォーマンスがカーネル レベルでどのように強化されたかを説明しています。また、この記事では、Windows Vista の I/O の重要な変更についても言及しています。この内容には、ファイル ベースのシンボリック リンク、同期 I/O 処理を取り消すための新しい機能 (個人的には最大の変更と考えています)、および I/O 優先順位の概念が含まれます。エンタープライズで Windows Vista を評価する際は、Mark Russinovich の包括的な記事を参考にしてください。
もちろん、日常的なタスクも考慮する必要があります。今月号には、Active Directory での権限の委任、Windows Vista の新しいグループ ポリシー テンプレート、グループ ポリシーのトラブルシューティング、および MOM を使用した Active Directory の監視など、Windows の監視に関する多くの記事が掲載されています。
最後に、ゲームおよびセキュリティ環境の面にも特筆すべき点があります。仕事ばかりでなく、ときには娯楽も必要です。£JOSHUA TRUPIN

次のマイクロソフト技術支援スタッフに心より感謝します。Matt Ayers、Eugene Bak、Vijay Bharadwaj、Michael Fortin、David Hicks、Khushru Irani、Mehmet Iyigun、Arun Kishan、Mark Lawrence、Pavel Lebedynskiy、Ben Mickle、Michael Murgolo、John Orefice、Ravisankar Pudipeddi、Jeffrey Richter、David Solomon、Jim Truher、Landy Wang、および Andy Zeigler。


 ツールボックス: IT プロのための新製品
ツールボックス
IT プロのための新製品
Greg Steen

データを移動する
SQL Examiner Bundle
www.sqlaccessories.com
DBA、開発者、オペレーション スペシャリスト、あるいはさまざまな職務を兼ね備える人など、組織における役割は何であれ、SQL Server™ を扱うのであれば、おそらく環境間でデータを移動し、データの整合性とデータ構造が損なわれていないことを確認する必要があったことでしょう。もちろん、SQL Server には多くのレプリケーションと同期機能が組み込まれていますが、QA データベースが開発データベースと完全に一致するかどうかを確認するには、時間と手間を省く TulaSoft の SQL Examiner Bundle のようなツールが大きな効果を発揮します。
このアプリケーションでは、マウスを数回クリックするだけで、2 つのデータベース インスタンス間のデータベース構造またはデータ自体の不一致を検出します。ユーザーは、単にアプリケーションでチェックするデータベースを指定するだけです。名前から推測されるとおり、SQL Examiner Bundle には SQL Examiner および SQL Data Examiner という 2 つのアプリケーションがひとまとめになっています。SQL Examiner ではデータベースの構造を確認し、SQL Data Examiner ではすべてのデータを確認してあらゆる違いを表示します。
SQL Examiner では、テーブルや保存されているプロシージャからフルテキスト カタログや XML スキーマ コレクションに至るまで、データベース インスタンスのすべてを確認し、比較します。SQL Server 2005 を使用している場合は、共通言語ランタイム (CLR) アセンブリも比較できます。データベースの比較が終わると、同期するデータベース オブジェクトと同期方向を選択できます。
SQL Examiner でデータベースを確認し、比較する
SQL Examiner でデータベースを確認し、比較する (画像を縮小するには、ここをクリックします)
SQL Examiner でデータベースを確認し、比較する
SQL Examiner でデータベースを確認し、比較する (画像を拡大するには、ここをクリックします)
アプリケーションの非常に優れた機能は、オブジェクトを作成する SQL スクリプトを生成し、その生成されたスクリプトにデータベース間の違いを表示することです。ターゲット データベースの構造の作成時に作成スクリプトまたは移行スクリプトが失敗した後にエラーを表示するには、優れた手段です。(「しまった、ここにクラスタ化インデックスが必要だったんだ。」) 生成されたスクリプトを個別に実行したり、後で実行するようにこれらのスクリプトを保存したりすることもできます。単純に同期ボタンをクリックすれば、アプリケーションがすべての作業を実行してくれます。
別の優れた機能として挙げられるのは、オブジェクトのコメント、トリガ、インデックス、拡張プロパティなど、比較対象に例外を追加するオプションです。構造の比較を確認した後は、SQL Data Examiner でデータを調べ、不一致を確認します。どのテーブルを比較するかだけでなく、指定されたテーブルのどの列を比較するかも選択できます。データ テーブルの比較が完了すると、どの行が一致し、どこに違いがあり、何が 1 つのデータベースに存在し、他にはないかを確認することができます。
SQL Examiner と同様、SQL Data Examiner でも、ボタンをクリックしてテーブルを同期するか、どのデータを転送するかと転送方向を選択することができます。2 つのアプリケーションでは、セットアップをプロジェクトとして保存できるため、毎回タスクを再作成する必要はありません。各アプリケーションは個別購入できますが、自分の経験からいって、両方とも手に入れたいものでしょう。
価格 : 299.95 ドル (1 ユーザー ライセンスごと)

重複ファイルを検索する
zsDuplicateHunter (Professional Edition)
Zizasoft
デスクトップ管理を担当する人であれば、誰しもユーザーのマシンの「空き容量不足」に遭遇したことがあるでしょう。調査をしてみると、ユーザー ベースのファイル保存用のネットワーク接続ストレージ (NAS) システムにバックアップが行われていても、ユーザーは編集を行うたびに文書のコピーを保存していたことがわかります。または、ログ サーバーのバッチ プロセスで大きなログが複製され、割り当てられているすべてのサーバー容量を消費していることもあります。これらの問題は、Windows®、Linux、または Mac OS X で実行できる Java ベースの重複検出アプリケーション、zsDuplicateHunter Professional Edition で解決できる可能性があります。
このアプリケーションでは、ドライブ、ディレクトリ、またはネットワーク共有を簡単に検索して、重複の可能性を検出することができます。名前の比較だけに留まらないこのアプリケーションでは、ファイル サイズ、ファイル チェックサム、さらにはファイルのダイジェスト計算別にファイルをまとめて、クリーンアップするファイルが実際に異なることを確認できます。さらに、重複ファイルを永久的に削除する必要はありません。万が一のために、すべてのマークした重複ファイルを指定したフォルダに移動することができます。
別の優れた機能として挙げられるのは、"Keep Files in this Folder, Delete Duplicates Elsewhere" オプションにより、クリーンなソース ディレクトリを選択して、ディスク上に存在する可能性のある他のすべてのものを削除できることです。検索結果では、ファイルをダブルクリックして関連するファイル ビューアでファイルを開いたり、並べ替えを行ったり、ファイルを選択して望みどおりの結果を得ることもできます。IT プロのための優れた機能により、重複を検索しながら、アプリケーションが占めるメモリの量を調整することができます。追加保護機能として、隠れたファイルまたはシステム ファイルの検索を無効にして、削除すべきではないファイル、またはオペレーティング システムか別のアプリケーションにより管理されるファイルの削除を防ぐこともできます。
Professional Edition には、検索結果セットに対する詳細なフィルタも提供されており、正規表現を適用して削除するファイルを的確に検出できます。
価格 : 39.95 ドル (1 ユーザー ライセンスごと)

アプリケーションを携帯する
MojoPac
www.mojopac.com
別の環境に移動したときに、お気に入りのアプリケーションとデスクトップ設定を利用したくてもできない場合、または誰かのデスクトップを使用するときに自分が使った形跡を残したくない場合には、RingCube Technologies の MojoPac を検討してみてはいかがでしょう。
変わった名前であることはさておき、MojoPac により、USB ハード ドライブ、Zune や iPod などの USB 2.0 でホスト システムに接続可能なパーソナル メディア デバイス、さらには十分な記憶領域を備えた携帯電話に設定とアプリケーションを携帯して、あらゆる Windows XP システム (Home、Professional、Media Center、または Tablet) で使用することができます。この記事の執筆時点では、Windows Vista™ と Windows 2000 ホストはサポートされていないものの、製品 Web サイトのドキュメントによれば、これらの OS に対応するためのアップグレードがまもなく利用できるようになるということです。
MojoPac で設定を携帯する
MojoPac で設定を携帯する (画像を縮小するには、ここをクリックします)
MojoPac で設定を携帯する
MojoPac で設定を携帯する (画像を拡大するには、ここをクリックします)
現在、MojoPac にはホスト システムの管理者権限が必要になるものの、開発中の 2.0 バージョンでは、一部のユーザー モードに対するサポートが追加されます。このツールは基本的に、ホスト OS と記憶装置の間で干渉を実行するもので、アプリケーションを携帯装置にインストールした後に初めて起動すると、初期 Windows アカウントのセットアップをトリガし、MojoPac ユーザーの個人設定を MojoPac 装置に設定します。
起動が完了すると、画面上部のツールバー (最小化可) をクリックするだけで簡単にホスト システムと Mojo システムを切り替えることができます。Mojo 装置へのアプリケーションのインストールは、MojoPac がアクティブな状態で通常通りに行います。既定のディレクトリへのインストールに関する Readme 文書の大きな警告に注意する限り、問題なく使用することができます。
全般的に見て、MojoPac は他の場所で自分の設定を使用することを願う IT プロにとって貴重な資産となる可能性を持っています。たとえば、MojoPac にすべてのシステム ユーティリティ、パケット スニッファ、トラフィック モニタを用意しておけば、組織のあらゆる PC からトラブルシューティングを行うことができ、使った形跡を残すこともありません。
価格 : 49.99 ドル (1 ユーザー ライセンスごと)

ブック レビュー
Administrator’s Guide to SQL Server 2005
www.aw-bc.com
IT 業界では、SQL Sever 2005 により提供される機能の潜在能力と幅を理解する人が益々増えています。広範な XML データ サポートから SQL Server Integration Services (SSIS)、SQL Server 2005 Service Broker にいたるまで、このアプリケーションにより多くの有益な機能強化が得られます。アップグレード パスの計画または SQL Server 2005 インスタンスの管理をサポートするために、Buck Woody は Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional、2006 年) という優れたリファレンス ガイドを執筆しました。
本書では、新しいサーバー プラットフォームに応用できる実用的な管理手順を、(発売されているその他の多くのリファレンスとは異なり) 簡潔に解説しています。本書は、アプリケーションのニーズに合わせてインフラストラクチャを適正なサイズにすることに関するセクションと、異なるシナリオに適した SQL Server のバージョンに関するガイドから始まっています。ここは、回避可能なシステムのパフォーマンス ボトルネックを引き起こさないようにインフラストラクチャを構築する方法に関する知識も得られます。
その後には、強化された SQL Server Profiler と新しい SQL Server Management Studio など、SQL Server により提供される各種ツールについて解説されています。さらに、メンテナンスと自動化タスクを詳しく調べ、サーバーのプロファイリングに基づいて成長計画を立てる方法と実装に適したメンテナンス計画を立てる方法についても確認することができます。
セキュリティに関する章では、OS と SQL Server インスタンスによりネットワークとハードウェアからシステムのセキュリティを保護する方法について検討しています。ここでは、新しいプラットフォームにより提供される追加暗号化、証明書、およびキー管理サービスについて確認することもできます。
別の章では、実装ニーズに応じてシステムの可用性を高めるためのメカニズムについて説明しています。稼働時間に対する要求に応えるための手段として、クラスタ化、データベース ミラーリング、レプリケーション、およびログ配布が検討されています。そして、物理的に性質が異なるインフラストラクチャのオーバーヘッドを起こすことなく、高可用性を提供するために、バーチャル化が優れた手段となっていますが、本書では、Microsoft Virtual Server を使用して 2 ノードのクラスタをセットアップする方法をステップごとに解説しています。
SSIS に関する章では、新しいツール (DTS よ、さようなら) を使用して、抽出、変換、および読み込み (ETL) 機能を開発および展開する方法についてだけでなく、サービスを使用して監視、電子メール通知、およびバックアップの各タスクを作成する方法についても解説しています。
最後のいくつかの章では、新しい SQL Server プラットフォームにより提供される Reporting Service と Analysis Service について詳しく説明しています。ここでは、レポートの設計と作成、レポート システムの管理、および分析サービスの展開の維持に必要な事項について触れています。
全般的に見て、Administrator’s Guide to SQL Server 2005 は、SQL Server 2005 の管理、監視、およびアップグレードについて素早く学ぶための優れた手段です。
価格: 49.99 ドル。


 SQL に関する Q&amp;A: データベースのサイズ、ミラーリング、マーク付きトランザクション、その他
SQL に関する Q&A
データベースのサイズ、ミラーリング、マーク付きトランザクション、その他
Nancy Michell 編

クラスタの移動
Q SQL Server 2000 クラスタを新しい IP アドレスに移行しなければなりません。Windows® クラスタおよび SQL Server™ クラスタの IP アドレスだけでなく、それを支える物理的なサーバーの IP アドレスも移行する必要があります。ソリューション全体を再構築する必要がありますか。
A いいえ、SQL Server のセットアップを実行して IP アドレスを変更するだけで済みます。その方法を説明するサポート技術情報の記事を参照してください。

データベースのサイズ
Q 私は SQL Server 2000 SP4 を業務用に使用しています。これは、ほぼ 10GB のミッション クリティカルなデータベース、単純復旧モデル、9,850MB のプライマリ ファイル、88MB のトランザクション ログ ファイルによって構成されています。データベースのバックアップもほぼ 10GB です。パフォーマンスの向上にはデータベースのサイズを縮小すべきでしょうか。その場合、DBCC SHRINKDATABASE を使用すべきでしょうか DBCC SHRINKFILE を使用すべきでしょうか (残念ながら、このメンテナンスを非ピーク時に行うことはできません)。
A DBCC SHRINKDATABASE も DBCC SHRINKFILE もデータベースで多数の削除や更新が行われ、データのボリュームが小さくなった場合にしか役立ちません。でも、真の問題はなぜそれを問題にするのかということです。10GB のディスク容量は今では 20 ドルぐらいです。100GB のデスク領域を追加して稼動させた方がいいと思いませんか。パフォーマンスは領域が断片化してくると劣化します。メンテナンスができないとすれば、選択肢は限られています。このようなケースではデータベースの第 ２ のコピーを使用する人もいます。リプリケーションを使用してバックアップ コピーを常に最新の状態に更新しておき、メンテナンスをバックアップ コピーに対して行った後、アプリケーションをバックアップに切り替えることができます。この方法では明らかに、いくつかコードを変更して、単純復旧モデルから完全または一括ログ モデルに変更する必要があります。

アップグレードとパフォーマンス
Q SQL Server 2000 から SQL Server 2005 へ 2 つのアプリケーションを移行しなければなりません。このアップグレード中にパフォーマンスへの影響を避ける方法はありますか。
A 通常、次の落とし穴がアップグレードによるパフォーマンス劣化の原因になりますから、避けるようにしてください。
  1. SQL Server 2005 にアップグレードした後、統計を再構築していない。
  2. 2 つの異なったデータ型を比較する JOINS と WHERE 句があり、それが原因でパフォーマンスが悪くなっている。特にサーバーが SQL Server 2000 SP3 以前のバージョンを実行していた場合 (support.microsoft.com/kb/271566/ を参照)。
  3. SQL Server 2005 インスタンスが正しく構成されていない。メモリ、Address Windowing Extensions (AWE)、ドライバなどの構成が間違っている。SQL Server 2000 を実行しているコンピュータを調整した人が、その記録を残さずに去った。そして、その調整は SQL Server 2005 インスタンスに対して行われなかった。
  4. ハードウェアに問題がある。新しいハードウェアがよさそうに見えたので購入したが、実際には期待通りに機能していないということがよくある。
SQL Server インスタンスを実稼動に投入する前に、パフォーマンス ベースラインを確立して期待通りのパフォーマンスが得られることを確認する必要があります。それによってインフラストラクチャが問題である可能性を除外できます。ディスク、I/O、メモリなどの Perfmon カウンタを見て、インスタンス間で比較する必要があります。

データベース ミラーリング
Q データベース ミラーリングを使用していますが、READ_COMMITTED_SNAPSHOT データベース オプションを有効にするにはどうしたら良いですか。ミラーリングをセットアップした後で有効にしようとしたのですが、データベースがミラーリング セッションに入っているという意味のエラーが出て、そのコマンドを実行できませんでした。
A エラーになったのは READ_COMMITTED_SNAPSHOT オプションの設定を有効にするにはデータベースを再起動する必要があるからです。したがって、ミラーリング セッションを停止して、問題のオプションを設定し、データベースを再起動する必要があります。ミラーリングはこの手順を完了した後に再開できます。ミラー データーベースはセッションが再開されるとそのオプションを採用し、フェールオーバー時に使用します。

Q 非同期ミラーリングをセットアップしようとしたのですが 1418 エラーが出ます。Netstat -ano を実行すると SQL Server はすべてのサーバーで正しいポートをリッスンしていることがわかります。エラーはミラーリングを開始しようとすると出ます。どうなっているのでしょうか。
A ファイアウォールによって通信がブロックされている可能性があります。これは比較的よくあることなので調べる必要があります。詳細については、技術白書のデータベース ミラーリングの設定のトラブルシューティング および MSSQLSERVER_1418 を参照してください。
この問題は非同期ミラーリングに特有の問題ではないことに注意してください。実際、同期ミラーリングでも発生する問題です。
ご覧になったエラーは「The server network address "%.*ls" cannot be reached or does not exist. Check the network address name and reissue the command (サーバーのネットワーク アドレス "%.*ls" に到達できないか、存在しないアドレスです。ネットワーク アドレスを確認してコマンドを再実行してください）」だったと思いますが、そのとおりです。多くの場合、リモートのサーバーが存在しないのではなくて、単に到達できなくなっているだけです。
これは、リモート サーバーがダウンしているとき、ポートをリッスンしていないとき、またはエンドポイントがダウンしているときでも発生します。エンドポイントのダウンは、相手のサーバーが同じ暗号化機能をネゴシエートできないときやその他の認証問題がある場合に発生します。相手のサーバーがブロックされている場合もあります。これはコマンドを開始する相手のサーバー上のファイアウォールが原因になっている可能性があります。
その他に確認すべき問題としては、データ ソース名 (DSN) と名前解決の問題があります。通常は、完全修飾ドメイン名の使用を推奨します。多くの場合ファイアウォールが問題の原因になっていますが、他にもいろいろ原因がありうることも知っておいてください。

Q SQL Server 2005 ミラーリングを使用したいのですが、複数のアプリケーションが同じ SQL Server インスタンス上の複数のデータベースに接続している場合にはミラーリングは推奨されていないと聞きました。本当ですか。
A 答えは各アプリケーションが別々のデータベースを持っているか、複数のアプリケーションが複数のデータベースを参照しているか、分散トランザクション コーディネータ (DTC) トランザクションが使用されているかに依存します。複数データベースにまたがるトランザクションが使用されている場合、ミラーリングによって論理的な不整合が発生し、期待通りにトランザクションがコミットされなくなります。このような条件下で何が起こるかのわかりやすい説明は、ここにあります。
複数のデータベースと複数のアプリケーションが使用されていても、個々のアプリケーションが独自のデータベースを持っている場合は、ミラーリングがそのような問題の原因となることはありません。

マーク付きトランザクション
Q マーク付きトランザクションというのはどんなものですか。それは 1 つのデータベースが SQL Server で、もう 1 つが Oracle というような場合に使用できるものですか。
A トランザクションにマークを付ける作業は、すべてのログの中の同じ場所にマークを付けるために DBA が定期的に行う作業です。この作業は、データベースをトランザクション マークまで復元する機能を使用して、すべてのデータベースを同じところまで復旧できるようにするためのものです。これはかなり苦痛を伴う作業です。関連のすべてのデータベースを復元する必要があり、すべてのデータベースでデータが失われます。それを避けるには、ログ ファイルが失われないようにする必要があります。マーク付きトランザクションは SQL Server 独特のものです。分散トランザクションに SQL Server 以外のデータベースも含まれている場合、それらはトランザクションのマーク付けに参加できません。一般に、分散データベース システムでトランザクション マークが使用されることはめったにありません。トランザクション ログの消失は、復旧に多大の手作業を必要とする致命的なイベントとして扱われます。

Access から T-SQL への変換ツール
Q ストアド プロシージャ用の Access™-SQL から T-SQL への自動変換ツールはありますか。
A SQL Server Migration Assistant (SSMA) for Access を試してください。これは (英語) からダウンロードできます。そこには SQL Server Migration Assistant for Oracle、SQL Server Migration Assistant for Sybase、および Migrating Informix Databases to Microsoft® SQL Server 2000 もあります。
Access から SQL Server にアップサイズするには、Office アップサイジング ウィザードを使用できますが、図 1 に示した SSMA for Access の方が変換評価レポートやネットワーク スキャンなどのより充実した機能を備えています。SSMA for Access は Office アップサイジング ウィザードでは現在適切に処理されない多くの問題を処理できます。
図 1 SQL Server Migration Assistant for Access
図 1 SQL Server Migration Assistant for Access (画像を縮小するには、ここをクリックします)
図 1 SQL Server Migration Assistant for Access
図 1 SQL Server Migration Assistant for Access (画像を拡大するには、ここをクリックします)

非クラスタ化インデックス
Q プライマリ キーが 2 つの GUID (GUID1 と GUID2) からなるテーブルがあります。GUID1 と GUID2 上には一意のクラスタ化インデックスが既にありました。今、パフォーマンス上の理由で、第 2 の非クラスタ化インデックスを GUID2 と GUID1 上に作成しようと考えていますが、インデックスを一意にするとパフォーマンスに影響するようなオーバーヘッドが発生しますか。
A 非クラスタ化インデックスを一意と宣言することによってパフォーマンスが低下することはありません。それどころか、そうすることによってインデックス ツリーのレベル数が減少する可能性があります。
非クラスタ化インデックスを一意と宣言すると、ルートと非リーフ ページでその行ロケータがインデックス エントリのキーの末尾に追加されます。これはインデックス エントリの削除や更新を促進するために行われるもので、キーが重複して存在する場合に同義チェーンのスキャンを避けます。変更対象のエントリはシステム シーク処理をキーとロケータの両方に対して行うことで検索できます。その結果、選択したクラスタ キーによってそれらのエントリはかなり長くなります。したがって、ルートと非リーフ ページがいっぱいになるのも速くなります。インデックスが一意の場合、それを宣言すべきです。
要するに、テーブルにクラスタ化インデックスがあるかどうかにかかわらず、そのデーブルの非クラスタ化インデックスが一意と宣言されていない場合、ルートとその他の非リーフ ページにおいてロケータがインデックス エントリに追加されるのです。
さらに、int 識別子列を代理キーとして使用し、次に 2 つの一意のインデックス (GUID1、GUID2) と (GUID2、GUID1) を追加する場合、インデックスは 32 バイトのクラスタリング キーではなく 4 バイトのクラスタリング キーになるためパフォーマンスが向上する可能性があります。

ロックの更新
Q 次のような構造のストアド プロシージャがあります。
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
このストアド プロシージャはロックを 1 つの呼び出しにしか渡さないので、他の呼び出しは待たされます。同じ動作を分離レベルを低くすることによって達成できますか。
READ COMMITTED が適切な分離レベルのように見えます。なぜなら、このトランザクションには 1 つのクエリしかありません。別のトランザクションが同じレコードを更新中の場合、このトランザクションはその別のトランザクションを待つことになります。これは正しいですか。
A 他の呼び出しを待たせているのはシリアル化可能の設定ではありません。それは更新処理自体です。確かに、分離は READ COMMITTED に設定しておくことができます。当然、更新処理は使用するインデックスの更新ロックを取ります。これは、同じステートメントを実行している別のプロセスに問題を引き起こすので、その更新が終わるまでブロックされます (更新が唯一のステートメントなら、ここでは明示的なトランザクションは必要ありません。各ステートメントは、明示的なトランザクションでなければ、暗黙に独立したトランザクションです)。
UPDATE ステートメントの中の WHERE 句に一致する行がない場合、シリアル化可能な分離レベルを使用することによって、そのような行が別のトランザクションによって挿入されたり変更されたりしないようにできます。UPDATE を READ COMMITTED 分離で実行すると、そうはなりません。別のトランザクションがその更新に適合する行を挿入できます。ストアド プロシージャ コードが、見せていただいたコードのようになっている場合、シリアル化やトランザクションなどの操作を行っても意味がありません。単純に更新を実行してください。

次の Microsoft IT 技術支援スタッフに心より感謝します。Gaurav Aggarwal、Anthony Bloesch、Todd Briley、Shaun Cox、Roberto Di Pietro、Michael Epprecht、Kevin Farlee、Umachandar Jayachandran、Chuck Ladd、Kaloian Manassiev、Luciano Moreira、Ward Pond、Mark Prazak、Arunachalam Thirupathi、Roger Wolter、Clement Yip、Frankie Yuen。


 ユーティリティ スポットライト: グループ ポリシー インベントリ
ユーティリティ スポットライト
グループ ポリシー インベントリ
Greg Steen
この記事で使用しているコードのダウンロード: GPInventory.exe (150KB)

持っているもの を整理していない場合に、それをどうやって知りますか。インベントリの詳細を簡単に利用できると、予算割り当て会議や年次監査のときも、さまざまな問題を避けることができます。そして時の権力者ももちろん、常に誰が何をなぜ持っているか、およびメジャー アップグレードには何が必要かなどを知りたがります。
Windows Server® 2003 リソース キットに含まれるグループ ポリシー インベントリ (GPInventory.exe) はこれらに対応するためのツールです。このプログラムを使用すると、図のように複数のリモート ホストからユーザー ポリシーの結果セット (RSOP) クエリ、または Windows® Management Instrumentation (WMI) クエリを使用して、システム情報を照会して取得できます。当然のことながら、プログラムはグループ ポリシー情報を簡単に取得します。さらにインストールされたアプリケーション、プロセッサ名や速度、インストールされた修正プログラムのリストなどの詳細なシステム情報を効果的に取り出すこともできます。それだけではありません。プログラムは Windows Server 2003 リソース キットの一部であるため、完全に無料です。
図 1 GPInventory を使用して情報を収集する
図 1 GPInventory を使用して情報を収集する (画像を縮小するには、ここをクリックします)
図 1 GPInventory を使用して情報を収集する
図 1 GPInventory を使用して情報を収集する (画像を拡大するには、ここをクリックします)
GPInventory.exe にはさまざまな利用方法があります。たとえば、保証の状態を確認する必要がある場合、ネットワーク上の PC のシリアル番号またはサービス番号を収集するだけで済みます。また、ラボ環境にあり、マシンが現在使用中かどうかを確認するには、いすに座ったままで、現在システムにログオンしているユーザーをクエリできます。(たとえば QA 環境をクリーンアウトして復元する場合など) イメージが定期的にブレードに縮小されるブレード サーバーが設定されている場合、PC のインストール日をクエリし、イメージが最後に適用された時刻を確認できます。
GPInventory は、使用も非常に簡単です。在庫調査の対象のコンピュータのリストを含むファイルに GPInventory をポイントし、実行するクエリを選択してから、リストを処理します。ツールは、リスト上の各コンピュータに接続し、それをクエリします。クイック クエリを実行する場合は、ターゲット マシンを Active Directory® から直接、そして実行するクエリ アクションを "クエリ" メニューから選択できます。
マシン上で RSOP クエリを実行するには、"ポリシーの結果セットの生成 (ログ)" 権限が必要です (ドメイン管理者と担当管理者は既定でこの権限を持っています)。WMI クエリでは、WMI Control MMC スナップインを使用して root\cimv2 名前空間で "アカウントの有効化" 権限および "リモートの有効化" 権限を代替ユーザーに付与しない限り、リモート マシンの管理者権限が必要です。
クエリを実行したら、タブ区切りのテキスト ファイルまたは XML として結果を保存できます。どちらの形式も、分析のために Microsoft® Excel® にインポートできます。すべての詳細を確認するには、並べ替えを実行し、自動フィルタを適用します。
さらに、GPInventory ではコマンド ライン実行がサポートされているため、システム情報をクエリするスケジュール済みタスクを簡単に設定し、GUI を介さずに XML ファイルに直接保存できます。これは、業務時間外の実行により適している長時間実行のクエリには非常に役立ちます。
ツールには、RSOP クエリと WMI クエリの既定セットが付属していますが、必要なものがこれらのセットにない場合は、独自にカスタマイズされたリストを使用してクエリ ファイルを追加、編集、および更新できます。クエリ リスト XML ファイルで新しいクエリを定義する方法については、付属のヘルプを参照してください。
GPInventory.exe は、インベントリ、グループ ポリシー、ステータス情報の収集などの目的にはかかわらず、ネットワーク上にある Windows を実行しているマシンについての情報を収集するために効果的な手段です。グループ ポリシー インベントリ ツールへのリンクは、Code Downloads (英語) から入手できます。

Greg Steenは技術者、起業家、熱狂的 IT ファンで、より簡単な操作、開発に役立つ IT プロフェッショナルのためのツールとメソッドを日夜追い求めています。


 The Cable Guy: Windows での QoS のサポート
The Cable Guy
Windows での QoS のサポート
Joseph Davies
この記事は、Windows Server のコードネーム "Longhorn" のプレリリース版を一部基にしています。ここに記載されているすべての情報は変更される可能性があります。

サービスの品質 (QoS) は、家庭環境や企業環境のユーザー エクスペリエンスを向上させるために費用効率の高い方法でネットワーク トラフィックを管理する一連のテクノロジを提供しています。QoS テクノロジを使用すると、帯域幅を測定したり、変化するネットワーク状態 (帯域幅の輻輳や可用性) を検出したり、
トラフィックを優先順位設定、および絞込みすることができます。たとえば、QoS を適用してレイテンシに敏感なトラフィック (ボイス アプリケーションやビデオ アプリケーションなど) に優先順位を付け、一括データ転送などレイテンシに敏感ではないトラフィックの影響を制御することができます。TCP/IP トラフィックに優先順位を付けて配信するには、ホストとネットワーク インフラストラクチャ デバイスからのサポートが必要です。このコラムでは、Microsoft® Windows®-ベースのホストで QoS を使用する方法について説明します。
TCP/IP ネットワークに QoS を設定する際の主な問題は、IP トラフィックの優先順位をどのように指定して配信するかということです。IP の元の RFC 791 では、[Type of Service (TOS)] (サービスの種類) フィールドで優先順位、遅延、スループット、信頼性、コストなどの特性を指定できますが、IP は根本的にベスト エフォートのデータグラム ベースのパケット交換テクノロジであり、先着順にそれぞれのパケットを処理するのが普通です。

優先順位を付けた配信構成
優先順位を付けて配信サービスを提供するには、いくつか方法があります。マークが付けられたトラフィックを特別に処理して、送信ホストに発信トラフィックのマークを付けるようにネットワーク インフラストラクチャを構成することができます。あるいは、送信ホストでネットワーク インフラストラクチャを動的にプログラミングして、発信トラフィックの特性 (アドレスやポート番号など) に基づいて特別な処理を行うようにすることもできます。
TCP/IP トラフィックの場合、さまざまな方法で優先順位を付けて配信することができます。たとえば、イーサネットのネットワーク インターフェイス層では、優先順位を付けて配信するために、イーサネット フレームの仮想ローカル エリア ネットワーク (VLAN) ヘッダーの 3 ビットの [優先度] フィールドを使用して、IEEE 802.1p タグでホストが送信したフレームをマークします。VLAN ヘッダーはイーサネット ヘッダー内の [発信元アドレス] フィールドと [長さ] フィールド (IEEE 802.3 フレーム) あるいは [EtherType] フィールド (イーサネット II フレーム) の間に配置されます。
802.1p タグを送信ホストで実装するには、ネットワーク アダプタとデバイス ドライバで 802.1p がサポートされ、ネットワーク アダプタで 802.1p のサポートが有効になっている必要があります。通常は、ネットワーク アダプタ ドライバのプロパティの [詳細設定] タブで 802.1p サポートを有効にできます。イーサネット スイッチでも 802.1p サポートが有効になっている必要があります。
IEEE 802.11 ワイヤレスのネットワーク インターフェイス層では、WMM (Wi-Fi Multimedia) の Wi-Fi Alliance の認定によって、ネットワーク トラフィックに優先順位を付ける 4 つのアクセス カテゴリが設定されています。これらのアクセス カテゴリは、(優先順位の高い順に) ボイス、ビデオ、ベスト エフォート、および背景です。WMM の優先付けのホスト サポートでは、ワイヤレス ネットワーク アダプタとそのドライバで WMM がサポートされている必要があります。ワイヤレス アクセス ポイント (AP) では WMM が有効になっている必要があります。
インターネット層では、Differentiated Services を使用して IP ヘッダーの Differentiated Services Code Point (DSCP) の値を設定できます。RFC 2472 の定義によると、DSCP 値は IP バージョン 4 (IPv4) TOS フィールドと IP バージョン 6 (IPv6) トラフィック クラス フィールドの上位 6 ビットです。
現代の企業ルーターのほとんどで DSCP トラフィックによる差別化がサポートされていますが、既定では無効になっているのが普通です。DSCP 対応ルーターは、転送中に DSCP 値を読み取り、パケットを特定のキューに配置します。たとえば、定義した DSCP 値に基づいて転送されたパケットを優先度の高いベスト エフォート キューやベスト エフォートよりも優先度の低いキューに配置するようにルーターを構成できます。キューと DSCP 値を構成することで、DSCP をマークしたトラフィックのサービスのレベルを分類することができます。たとえば、ミッション クリティカルなネットワーク トラフィックを優先的に転送することで、優先度の低い一括データ トラフィックによる遅延を防ぐことができます。WMM 仕様は、WMM アクセス カテゴリが DSCP 値にどのようにマップされているかを定義します。WMM 対応のワイヤレス AP は DSCP 値を読み取り、アクセス カテゴリに基づいてトラフィックを処理します。
インターネット層では、RFC 2205 で定義されているシグナリング プロトコル、リソース予約プロトコル (RSVP) を使用することもできます。ホストはこのプロトコルを使用して、エンドポイントまでネットワーク全体の帯域幅の予約を試みることができます。RSVP はネットワーク上で幅広く展開されているわけではありません。現在、Windows XP、Windows Server® 2003、Windows Vista™、 および Windows Server の次期バージョン、コードネーム "Longhorn" (現時点ではベータ) ではサポートされていません。
優先順位を付けて配信するようマークが付けられたパケットを送信するには、アプリケーションやオペレーティング システムのコンポーネントで 802.1p 優先度の値か DSCP 値を指定できる必要があります。次のセクションでは、Windows コンポーネントや Windows ベースのアプリケーションでイーサネット フレームの 802.1p 優先度か TCP/IP トラフィックの DSCP 値を指定する方法について説明します。

Windows XP と Windows Server 2003 における QoS
Windows XP と Windows Server 2003 には、QoS パラメータをトラフィックに割り当てるための API が用意されています。アプリケーション開発者は Windows Sockets (Winsock) と汎用 QoS (GQoS) API を使用して、ソケットごとにアプリケーション レベルに QoS パラメータを適用します。ネットワーク管理者は、トラフィック制御 (TC) API を呼び出すために記述されたトラフィック管理ツールを使用して、ホスト レベルに QoS パラメータを適用します。
Winsock と IP_TOS ソケット オプションを使用して、ソケットの発信パケットの DSCP 値を設定することができます。しかし、既定では TCP/IP スタックでは IP_TOS ソケット オプションは無視されます。IP_TOS ソケット オプションを使用するには、最初に次のレジストリ キーの下に DWORD レジストリ値 DisableUserTOSSetting=0 を作成し、設定する必要があります (図 1 を参照):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
図 1 DisableUserTOSetting のレジストリ値を設定する
図 1 DisableUserTOSetting のレジストリ値を設定する
このレジストリ設定を有効にするには、コンピュータを再起動する必要があります。
IP_TOS ソケット オプションを使用せずにトラフィックの DSCP 値を指定する場合、GQoS API を使用することができます。GQoS は Windows Sockets 2.0 (Winsock2) の一部です。QoS が有効になっているアプリケーションでは、GQoS API を使用して Windows の QoS 機能を呼び出します。Windows XP Service Pack 2 (SP2) の GQoS を使用すると、DSCP 値を設定して発信トラフィックを絞り込むことができます。Windows XP SP2 を実行中のコンピュータに 802.1p 優先度を設定するには、TC API を使用する必要があります。
TC API では、ローカル ホストのネットワーク トラフィックを規制するトラフィック制御機構にアクセスできます。DSCP 値、802.1p タグ、およびスロットル率の直接制御が可能です。ネットワーク管理者は、QoS を認識しないアプリケーションに代わって、トラフィック管理プログラムを使用して TC API を直接呼び出します。TC API は GQoS API よりも API のレベルが低いため、管理者レベルの特権が必要です。
GQoS API と異なり、TC API では送信ホストが同じ複数のアプリケーションのトラフィックを 1 つの QoS フローに集約することができます。この集約の一環として、送信元 IP アドレスと送信先 IP アドレス、送信元ポートと送信先ポート、およびプロトコル (TCP か UDP) の組み合わせからトラフィックを識別することもできます。たとえば、ホストの送信アプリケーションに関係なく、あらゆる送信元ポートと送信先ポートで特定の送信先 IP アドレスへのすべてのトラフィックを 1 つの QoS フローに含めることができます。これに対し、GQoS API では、ソケット経由で送信されたデータに対する QoS の処理を定義できます。
QoS 機能をサポートするには、Windows XP と Windows Server 2003 ベースのコンピュータに QoS Packet Scheduler コンポーネントがインストールされており、ネットワーク接続フォルダのネットワーク接続のプロパティで有効になっている必要があります (図 2を参照)。Windows XP が実行されているコンピュータでは、QoS Packet Scheduler コンポーネント (Psched.sys) が既定でインストールされ、有効になっています。Packet Scheduler コンポーネントは Windows Server 2003 にインストールできます。
図 2 QoS Packet Scheduler を構成する
図 2 QoS Packet Scheduler を構成する

Windows Vista および Windows Server "Longhorn" における QoS
Windows Vista と Windows Server "Longhorn" での QoS サポートは拡張されて簡略化されました。IT スタッフは、API を使用したり既存のアプリケーションを変更したりせずに、ポリシーベースの QoS で DSCP 値を設定し、アプリケーション送信比率を制御できるようになりました。開発者には GQoS と TC API がサポートされています。ただしこれらの API のサポートは、Windows の将来のバージョンではサポートされません。また、IP_TOS Winsock オプションは削除されました。GQoS と TC API を置き換えて、アップグレードされた、または将来のアプリケーションで QoS サポートを簡単にするため、Windows Vista と Windows Server "Longhorn" では新しい QoS2 API (高品質な Windows オーディオ ビデオ エクスペリエンス、qWAVE とも呼ぶ) をサポートしています。
Windows Server "Longhorn" と Windows Vista でポリシーベースの QoS を使用すると、より良いエンドユーザー エクスペリエンスを提供し、帯域幅コストを制御できるほか、帯域幅プロバイダや事業部署と優れたサービス レベルを交渉することができます。アプリケーションに関係なく、Active Directory® インフラストラクチャ全体で Windows Vista や Windows Server "Longhorn" を実行しているコンピュータのネットワーク帯域幅を集中管理できます。トラフィック管理はアプリケーション層で行われるため、ポリシー ベースの QoS トラフィック管理で既存のアプリケーションを変更する必要はありません。
Windows Server "Longhorn" と Windows Vista でポリシー ベースの QoS 設定を使用すると、次の条件に基づいて発信トラフィックの送信比率に優先順位を付けたり、これを管理したりすることができます。
  • 送信アプリケーション (実行可能ファイルのパスと名前)
  • 送信元、あるいは送信先の IPv4/IPv6 アドレス、またはアドレス プレフィックス
  • プロトコル (TCP、UDP、あるいは両方)
  • 送信元、あるいは送信先のポート、またはポート範囲 (TCP または UDP)
QoS ポリシーは、ドメイン、サイト、組織単位 (OU) などの Active Directory コンテナにリンクされているグループ ポリシー オブジェクト (GPO) の一部として、ユーザー ログイン セッションかコンピュータに適用されるか、セキュリティ グループに適用される場合もあります。QoS ポリシーは、グループ ポリシーの一部として、既存の Active Directory 管理インフラストラクチャ上に構築されます。
ポリシー ベースの QoS では、トラフィックの優先順位を定義できます。発信 IPv4 または IPv6 トラフィックを特定の DSCP 値でマークするように QoS ポリシーを構成できます。発信トラフィックの帯域幅の使用も管理できます。QoS ポリシーに発信トラフィックのスロットル率を構成できます。QoS コンポーネントは、帯域幅調整を使用して、集約した発信ネットワーク トラフィックを指定の率に制限します。コンピュータでは、着信トラフィックの帯域幅の使用を管理し、詳細設定を構成して TCP 受信ウィンドウ サイズの最大値を設定し、TCP トラフィックの着信スループットを指定することができます。
Windows Vista と Windows Server "Longhorn" では、QoS Packet Scheduler がインストールされ、既定で有効になっています。Pacer.sys コンポーネントは新しい Network Device Interface Specification (NDIS) 6.0 の軽量フィルタ ドライバで、ポリシー ベースの QoS のパケット スケジューリングと QoS を有効にしたアプリケーションのトラフィックを制御します。Pacer.sys は Windows XP と Windows Server 2003 では Psched.sys に置き換えられます。
イントラネットでポリシー ベースの QoS を展開するには、ユーザーまたはコンピュータ ベースの QoS ポリシーを構成し、適切な Active Directory コンテナに適用します。Windows Vista または Windows Server "Longhorn" ベースのコンピュータは、ユーザー構成かコンピュータ構成グループ ポリシーを更新するときにポリシー ベースの QoS 設定をダウンロードして適用します。
ネットワークはデータとオーディオ/ビデオ (AV) アプリケーションの両方で共有されることが多くなっているため、時間に依存した AV トラフィックをデータ トラフィックより優先できるように、QoS ソリューションが必要となります。さらにネットワークはますますワイヤレス化しているため、レイテンシや帯域幅に敏感なアプリケーションを一層混乱させることになります。
Windows Vista の qWAVE 機能には、AV アプリケーションとワイヤレス ネットワークによって導入されたネットワークの課題に対応できる QoS 関連のソフトウェア モジュールのコレクションが用意されています。qWAVE は QoS サブシステムに統合されており、複数のインターネットおよびネットワーク インターフェイス層パケット優先テクノロジと連動します。qWAVE では、複数の AV ストリーム (QoS を必要とするリアルタイムのフロー) とデータ ストリーム (電子メールやファイル転送などのベスト エフォート フロー) が同時にサポートされています。
qWAVE テクノロジのコレクションは、LAN 帯域幅の検出と監視、ネットワークの QoS 機能の検出、およびネットワーク帯域幅を公平に一貫して使用する分散受付制御を行います。これらのテクノロジでは高度な AV ストリーミング テクノロジを使用できるため、変化するネットワーク状態に動的に適応でき、QoS2 API を使用した場合にのみ開発者に提供されます。
Windows Vista と Windows Server "Longhorn" の QoS2 API は、GQoS API と IP_TOS Winsock オプションに置き換えられるため、GQoS API よりも使いやすくなります。

詳細情報
QoS の詳細については、多数のソースが TechNet から提供されています。詳細については、Microsoft Quality of Service Web サイト (英語) を参照してください。Windows Core Networking ブログ (英語) の QoS のセクションも参照してください。

Joseph Davies は、マイクロソフトのテクニカル ライターとして Windows ネットワークのトピックに関する講義および執筆を 1992 年から行っています。Joseph Davies は、Microsoft Press® 向けに本を 5 冊執筆しており、また月間の TechNet Cable Guy コラムの著者でもあります。


 Windows PowerShell: 1 行ずつスクリプトを作成する
Windows PowerShell
1 行ずつスクリプトを作成する
Don Jones

これまでのコラムで、Windows PowerShell はシェルであることを強調してきました。おそらく既にご存知の cmd.exe (コマンド プロンプト) シェルとは違って、Windows PowerShell は対話型で使用するように設計されています。それでいて、Windows PowerShell は cmd.exe のバッチ言語より強力なスクリプト言語もサポートします。そのため、
VBScript のような言語と同等あるいはそれ以上に強力な言語になっています。しかし、Windows PowerShell™ がシェルであるという事実により、スクリプトの学習が非常に簡単になっています。スクリプトはシェルの中で対話型で 1 行ずつ書いて、その結果を直ちに確認しながら開発できます。
この対話型スクリプト作成技法によってデバッグも容易になっています。スクリプトの結果を直ちに確認できるので、思いどおりの結果にならなければ手早く変更できます。
このコラムでは、例を挙げて Windows PowerShell でスクリプトを対話型で作成する過程を説明します。例として作成するのは、テキスト ファイルからサービスの名前を読み取り、各サービスのスタートアップの種類を無効に設定するスクリプトです。
ここで学んでいただきたいことは、大きなスクリプト全体に取り組むのではなく、小さな単位の積み重ねで Windows PowerShell スクリプトを作成するという考え方です。必要な管理タスクを構成要素に分解して、個々の構成要素を単独で実行できるようにすることが可能です。Windows PowerShell ではそのような個別のスクリプトを統合する優れた方法が提供されています。小さな単位に分解して作業することによって、最終的なスクリプトの開発が容易になるということがわかると思います。

ファイルから名前を読み取る
Windows PowerShell では、テキスト ファイルを読み取る方法を突き止めるのは容易ではありません。「Help *file*」を実行すると、ファイルにテキストを送るための Out-File コマンドレットの説明が表示されるだけで、テキストを読み取る方法の説明がありません。まったく役に立ちません。でも、Windows PowerShell のコマンドレット名は一定のルールに従っているので、それを利用できます。Windows PowerShell では、何かを取り出すのに使用するコマンドレットの名前は通常 Get で始まります。「Help Get*」を実行すると、このグループのコマンドレットの一覧が表示されるので、スクロールして Get-Content を見つけることができます。いけそうですね。次に「Help Get-Content」を実行してその説明を表示します (図 1 を参照)。必要な情報が含まれているようです。
図 1 「Help Get-Content」を実行して詳細ヘルプを表示したところ
図 1 「Help Get-Content」を実行して詳細ヘルプを表示したところ (画像を縮小するには、ここをクリックします)
図 1 「Help Get-Content」を実行して詳細ヘルプを表示したところ
図 1 「Help Get-Content」を実行して詳細ヘルプを表示したところ (画像を拡大するには、ここをクリックします)
Windows PowerShell では、ほとんどすべてのものがオブジェクトとして扱われます。テキスト ファイルも例外ではありません。テキスト ファイルは厳密には行の集合です。ファイルの中の個々の行は一種の独立オブジェクトとして動作します。C:\services.txt という名前のテキスト ファイルを作成して、1 行に 1 サービス名の形式で名前を入れると、Windows PowerShell では Get-Content コマンドレットを使用して名前を 1 つずつ読み取ることができます。このデモンストレーションの目的は、対話型でスクリプトを作成する方法を示すことにあるので、テキスト ファイルに対して Get-Content を実行し、その結果を調べることから始めます。
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
期待どおり、Windows PowerShell はファイルを読んで名前を表示しています。もちろん、単に名前を表示することが本来の目的ではありませんが、これで Get-Content が期待どおりに動作することがわかりました。

サービスを変更する
次にすることは、サービスのスタートアップの種類を変更することです。ここでも、適切なコマンドレットを見つけることから始めます。それには「Help *Service*」を実行します。短いリストが戻り、Set-Service コマンドレットが該当する唯一のコマンドレットのように見えます。このコマンドレットをスクリプトに取り入れる前に、その動作を確認するためのテストをします。「Help Set-Service」を実行するとその使用方法が表示されます。簡単にテストして確認します。
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

構成要素を統合する
サービス名を読み取る機能と Set-Service コマンドレットを統合する必要があります。ここではWindows PowerShell の強力なパイプライン機能を使用します。パイプラインを使用すると 1 つのコマンドレットからの出力を別のコマンドレットへ入力として渡すことができます。パイプラインはオブジェクト全体を渡します。オブジェクトの集合がパイプラインに入力されると、オブジェクトはパイプラインを通して 1 つずつ渡されます。これは、Get-Content の出力はオブジェクトの集合ですが、それを Set-Service にそのままパイプできることを意味します。Get-Content は集合を渡すので、集合の中の個々のオブジェクトつまりテキスト行が 1 つずつ Set-Service にパイプされます。その結果、テキスト ファイルの中の行ごとに Set-Service が実行されます。コマンドは次のようになります。
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
これで何が行われるかを下に説明します。
  1. Get-Content コマンドレットが実行され、ファイル全体が読み取られます。ファイルの中の個々の行は個別のオブジェクトとして扱われ、全体でオブジェクトの集合を形成します。
  2. そのオブジェクトの集合が Set-Service にパイプされます。
  3. パイプラインは Set-Service コマンドレットを各入力オブジェクトに対して実行します。それが実行されるたびに、1 つの入力オブジェクトが Set-Service の最初のパラメータであるサービス名としてそのコマンドレットに渡されます。
  4. Set-Service が実行されます。入力オブジェクトが最初のパラメータとして使用され、その他に指定されているパラメータがあればそれも使用されます。このケースでは -startuptype パラメータが使用されています。
お気付きになりましたでしょうか。この時点で既に目的が達成されています。でもまだスクリプトは書いていません。これと同じ作業を Cmd.exe シェルで実行するのは容易ではありません。VBScript では 12 行のコードを書くことになります。Windows PowerShell ではこれを 1 行で処理します。でも、これで終わりではありません。ステータスの出力やフェードバックがほとんど提供されていません。エラーが出なかったことはわかりますが、実際何が行われたかはよくわかりません。必要なタスクを処理するための機能を理解したので、もう少し見栄えがするスクリプトの作成を開始できます。
Michael Murgolo による Windows PowerShell Prompt Here
Microsoft® PowerToys for Windows® の中で最も人気があるのは Open Command Window Here ツールです。私も気に入っています。Microsoft PowerToys for Windows XP または Windows Server® 2003 Resource Kit Tools の一部として提供されてる Open Command Window Here を使用すると、Windows エクスプローラの中でフォルダやドライブを右クリックすることによってその場所をポイントするコマンド ウィンドウを開くことができます。
Windows PowerShell を勉強したとき、それと同じ機能があれば良いのにと思いました。そこで、Open Command Window Here のセットアップ .inf ファイルの cmdhere.inf を Windows Server 2003 Resource Kit Tools から取り出し、Windows PowerShell Prompt Here コンテキスト メニューとして使用できるように変更しました。このサイドバーの元になっている .inf ファイルは元のブログ記事に含まれています(leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx で提供されています)。インストールするには、.inf ファイルを右クリックして [Install] (インストール) を選択するだけです。
このツールの Windows PowerShell 版を作成するとき、元のツールにバグを見つけました。Open Command Window Here をアンインストールすると、必要なくなったコンテキスト メニュー エントリが後に残るというバグがあることがわかりました。その結果、元の cmdhere.inf の修正版も元のブログ記事で提供することになりました。
これらの PowerToys はどちらも、コンテキスト メニュー エントリがレジストリ キーの中で設定されディレクトリおよびドライブのオブジェクトの種類に関連付けられているという事実を利用しています。これは、コンテキスト メニューのアクションがファイルの種類に関連付けられているのと同じです。たとえば、.txt ファイルを右クリックするといくつかのアクション (開く、印刷、編集など) が一覧の一番上に表示されます。これらの項目がどのように設定されているかを理解するために、HKEY_CLASSES_ROOT レジストリ ハイブを見てみましょう。
レジストリ エディタを開いて、HKEY_CLASSES_ROOT フォルダを展開すると、.doc、.txt、などのファイルの種類に対応したキーの名前を見ることができます。.txt キーをクリックすると、"(既定)" の値が txtfile (図 A を参照) になっていることがわかります。これが .txt ファイルに関連付けられているオブジェクトの種類です。下へスクロールして txtfile キーを展開し、その中の shell キーを展開すると、.txt ファイルのコンテキスト メニュー エントリ用に名付けられたキーが表示されます (コンテキスト メニューの作成方法は他にもあるので、すべてのエントリは表示されません)。そのキーの中には command キーがあります。command キーの "(既定)" の値はそのコンテキスト メニューを選択したときに Windows が実行するコマンド行です。
cmd プロンプトでも Windows PowerShell プロンプトでもこの方法で Open Command Window Here と Windows PowerShell Prompt Here のコンテキスト メニュー エントリを作成するツールを使用します。ドライブやディレクトリに関連付けられているファイルの種類はありませんが、HKEY_CLASSES_ROOT の中にはこれらのオブジェクトに関連付けられている Drive キーと Directory キーがあります。
図 A レジストリの中で設定されているコンテキスト メニュー エントリ
図 A レジストリの中で設定されているコンテキスト メニュー エントリ (画像を縮小するには、ここをクリックします)
図 A レジストリの中で設定されているコンテキスト メニュー エントリ
図 A レジストリの中で設定されているコンテキスト メニュー エントリ (画像を拡大するには、ここをクリックします)

Michael Murgolo は Microsoft Consulting Services のシニア インフラストラクチャー コンサルタントです。専門はオペレーティング システム、展開、ネットワーク サービス、Active Directory、システム管理、自動化、およびパッチ管理です。

対話型でスクリプトを作成する
C:\services.txt のリストに含まれている各サービスに対して実行するコマンドレットを複数用意する必要があります。サービス名やその他の情報を出力してスクリプトの進行状況を追跡できるようにするためです。
以前はパイプラインを使用してオブジェクトをコマンドレットからコマンドレットへと渡しました。今度は、Foreach コンストラクトという (先月のコラムで紹介した) もっとスクリプト的な手法を使用します。Foreach コンストラクトはオブジェクトの集合を受け取ることができ、集合の中の各オブジェクトに対して複数のコマンドレットを実行します。ループが繰り返されるときに現在のオブジェクトを示す変数を指定しておきます。たとえば、コンストラクトは次のようにして始まります。
foreach ($service in get-content c:\services.txt)
Get-Content コマンドレットを使用してテキスト ファイルの内容を取り出している点は以前と同じです。ただし、今度は Foreach コンストラクトで Get-Content が戻すオブジェクトの集合を処理するようになっています。ループは各オブジェクトに対して 1 回実行され、現在のオブジェクトが変数 $service に入れられます。後は、ループの中で実行するコードを指定するだけです。元の 1 行コマンドをここでも繰り返してみます。これは複雑にならないように、また元の機能を失わないようにするためです。
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
ここで注目していただきたいことは、Foreach コンストラクトの最初の行が中かっこの開始 ({)で終わっていることです。中かっこの内部にあるものはすべて Foreach ループの内部にあると見なされ、各オブジェクトに対して 1 回実行されます。「{」を入力して Enter キーを押した後、Windows PowerShell のプロンプトが >> に変わったことに注意してください (図 2 を参照)。これは、コンストラクトが始まったこと、そしてそれが終わるのを待っていることを示しています。次に Set-Service コマンドレットが入力されています。ここでは、$service がテキスト ファイルから読み取られた現在のサービス名を示すので、$service を最初のパラメータとして使用しています。次の行では、中かっこを閉じてコンストラクトを終了しています。Enter キーを 2 回押すと、そのコードが直ちに実行されます。
図 2 コンストラクトが開始されたことを示す Windows Powershell 画面
図 2 コンストラクトが開始されたことを示す Windows Powershell 画面 (画像を縮小するには、ここをクリックします)
図 2 コンストラクトが開始されたことを示す Windows Powershell 画面
図 2 コンストラクトが開始されたことを示す Windows Powershell 画面 (画像を拡大するには、ここをクリックします)
そうです。直ちに実行されるのです。上の例はスクリプトのように見えますが、実際はライブで実行されているのであって、テキスト ファイルとして保存されたものを実行しているわけではありません。次に、全体を再度入力し直して、サービス名を出力するコードの行を追加します。
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
今度は、テキストを表示しようとしていることに注意してください。そのテキストは二重引用符で囲まれています。二重引用符は、それがテキスト文字列であってコマンドではないことを示します。ただし、単一引用符ではなく二重引用符を使用すると、Windows PowerShell は変数のテキスト文字列をスキャンします。それが見つかると、その変数の実際の値を変数の名前の代わりに表示します。その結果、このコードが実行されると、現在のサービス名が表示されます。
でも、これはまだスクリプトではありません。
ここまでは、Windows PowerShell を対話型で使用してきました。これは書いたコードの結果を直ちに見ることのできるのでたいへん便利です。しかし、やがて何度も同じコードの入力を繰り返すのが面倒になってきます。そのため Windows PowerShell ではスクリプトの実行もできるようになっています。Windows PowerShell スクリプトではスクリプトという言葉が最も厳密な文字どおりの意味で使われています。Windows PowerShell は基本的にはスクリプトのテキスト ファイルを読み取って、あたかも手で入力したかのようにその各行を "入力" します。ということは、これまでに書いたものをすべてスクリプト ファイルに貼り付けることができるということです。それでは、メモ帳を使用して disableservices.ps1 というファイルを作成し、下のコードを貼り付けてみます。
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
このファイルは C:\test というフォルダに入れました。これを Windows PowerShell の中から実行してみましょう。
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
エラーになりましたね。何が間違っていたのでしょうか。Windows PowerShell の現在の場所は C:\test フォルダになっていましたが、スクリプトが見つからなかったようです。なぜでしょうか。セキュリティ保護のために、Windows PowerShell では現在のフォルダにあるスクリプトを実行できないようになっています。これはスクリプトによってオペレーティング システム コマンドがハイジャックされないようにするためです。たとえば、dir.ps1 という名前のスクリプトを作成して通常の dir コマンドに優先させることはできません。現在のフォルダからスクリプトを実行するには、相対パスを指定する必要があります。
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
今度は何が問題なのでしょうか。まだ実行してくれませんね。パスが正しいにもかかわらず、Windows PowerShell はスクリプトを実行できないと言っています。これは、既定では、Windows PowerShell ではスクリプトを実行できないようになっているからです。これも、セキュリティ保護のための予防措置で、VBScript で見られたような問題を避けるためです。悪意のあるスクリプトは、既定では Windows PowerShell で実行できません。既定ではどのスクリプトも実行できないようになっています。スクリプトを実行するには実行ポリシーを明示的に変更する必要があります。
PS C:\test> set-executionpolicy remotesigned
RemoteSigned 実行ポリシーでは、署名されていないスクリプトをローカル コンピュータで実行できるようになっています。ただし、ローカルでもダウンロードされたスクリプトの実行には署名が必要です。もっと良いポリシーは AllSigned です。これなら信頼されている発行元からの証明書にデジタル署名があるスクリプトのみが実行されます。ただし、今は証明書が手元になくてスクリプトに署名できないので、ここでは RemoteSigned を使用するしかありません。それでは、再度スクリプトを実行してみましょう。
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
ここで使用している RemoteSigned 実行ポリシーは良いポリシーですが優れたポリシーとは言いがたいことを指摘しておきます。もっと良い解決策があります。コード署名証明書を取得した方がはるかに安全です。Windows PowerShell の Set-AuthenticodeSignature コマンドレットを使用してスクリプトに署名し、実行ポリシーをはるかに安全な AllSigned ポリシーに設定できます。
Unrestricted というポリシーもありますが、これは避けるべきです。このポリシーはすべてのスクリプト、リモートからの悪意のあるスクリプトでも自由にローカル コンピュータで実行できるようにします。これは非常に危険な状態です。ですから、Unrestricted ポリシーの使用はどのような理由があってもお勧めできません。

直ちに結果を見る
Windows PowerShell が提供する対話型スクリプト作成能力によって、スクリプトのプロトタイプでもスクリプトの小さな構成要素でも簡単に作成できます。結果が直ちにわかるので、希望どおりの結果になるようにスクリプトを調整するのも簡単です。それが終わったら、将来簡単にアクセスできるようにコードを .ps1 ファイルに保存できます。.ps1 ファイルにデジタル署名を入れることも忘れないでください。そうすれば、Windows PowerShell を最も安全な AllSigned 実行ポリシーに設定したままスクリプトを実行できます。

Don Jones は、SAPIEN Technologies 社でスクリプト作成チームのリードを務めるスクリプトの権威であり、Windows PowerShell: TFM の共著者です (www.SAPIENPress.com を参照)。連絡先 : don@sapien.com


 Hey, Scripting Guy!: 車を追いかけるのと、XML を追求するのと
Hey, Scripting Guy!
車を追いかけるのと、XML を追求するのと
Microsoft Scripting Guy
この記事で使用しているコードのダウンロード: HeyScriptingGuy2007_02.exe (150KB)

古いジョークに、 「家の犬は車を見ると追いかけるんだけど、車を捕まえてどうするつもりなんだろう」というのがあります。
良い質問ですが、Scripting Guy は正解を知りません。ただし、近所にいる犬のルーシーであれば話は別です。ルーシーは車を捕まえてしまいますから。ルーシーは酒屋を襲って車で逃走するに違いありません。前庭の状態から考えると、ルーシーは途中で一息付くこともないでしょう。
このジョークを今日のハイテク時代に合わせてアレンジすると、「うちの会社のシステム管理者は XML をずっと勉強しているんだけど、もしも実際に XML を習得したらどうするつもりなんだろう」になるでしょう。
誤解のないように言っておきますが、私たちは使い古されたジョークを現代風にアレンジしただけで、システム管理者を馬鹿にするつもりはありません。
正直な感想としては、少なくともシステム管理の点においては、XML は過剰に宣伝されたテクノロジなのかもしれません。多くの管理者は XML ファイルを処理するスクリプトを記述することなく幸せに暮らしています。これが近い将来に変わることはないと思います。
しかし、データ ストレージの標準として XML を使用するアプリケーションが増えているのも事実です。当然ですよね。フォーマットされたテキスト ファイルではありますが、XML データ ファイルは、すばやく簡単に作成できるだけでなく、プラットフォーム間での移植性があり、複雑な (高度な) データベース プログラムを必要としません。オペレーティング システムとテキスト エディタさえあれば、すぐに XML データベースを作成できます。
つまり、システム管理者が XML を使ってできることが少なくとも 1 つあって、それは、本格的なデータベースであるかのように XML ファイルをクエリするスクリプトを記述することです。その点については、Scripting Guy の右に出るものはいません。
ルーシーですか? 我らがルーシーはどこかの花壇を掘り返すことに夢中で、XML についてのコラムを書く暇はないと思います。
まず、「Hey, Scripting Guy!」のコラムで紹介した 4 つのスクリプトを含むデータベース ファイルであるシンプルな XML ファイルを見てみましょう (図 1)。
Figure 1 Hey, Scripting Guy! XML のスクリプト (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
ご覧のとおり、これは非常にシンプルなファイルです。個々のスクリプトは、<Script> タグの下にあります。ここから、これらのスクリプトをレコードして参照します。お察しのとおり、XML の熱狂的信者は、これらの項目をレコードとは呼びません。でもご心配なく。私たちの目的は、皆さんが既にご存じのデータベースへのクエリ技術を異なる新しい種類のデータ ソースに適用する方法について紹介することです。まず、その方法を説明した後で、時間があれば適切な用語を使用しましょう。
レコードに戻りましょう。それぞれのレコードには、<Category>、<Subcategory>、<Keyword>、<Title>、および <URL> というフィールドがあります。
皆さんは私たちが予想していたほど驚かないようですね。では、この XML ファイルを開いてコンテンツをエコー バックできるスクリプトを紹介しましょう。
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
これらのタグ名では大文字と小文字が区別されることに注意してください。これは "/Repository/Script" です。"/repository/script" や "/REPOSITORY/SCRIPT" ではありません。
思ったとおり、これでも皆さんはあまり驚きませんね。しかし、これは、ほんの序の口です。
コードを見てわかるように、私たちは Microsoft.XMLDOM オブジェクトの作成から開始します。これは、XML ファイルを処理するための COM オブジェクトです。その後、Async プロパティを False に設定します。これで、制御がスクリプトに返される前にファイル全体がメモリに読み取られます。次に、Load メソッドを使用して、C:\Scripts\Scripts.xml ファイルを読み取ります。
xmlDoc.Load("C:\Scripts\Scripts.xml")
ファイルがメモリに読み取られると、selectNodes メソッドを使用して、指定したレコードをデータベースから選択できます。
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
selectNodes に渡されたパラメータに注意してください。これは、XML ファイル内のパスを表します。この XML ファイルの構造を次に示します。
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
このことが重要なのでしょうか。答えは、「はい」です。XML ファイルを処理する場合は、構造が非常に重要です。たとえば、レコードの個々のプロパティを取得するにはどうすればよいでしょうか。それは簡単です。<Repository> タグにアクセスします。このタグの後ろには <Script> タグおよび個々のプロパティ タグが続きます。さて、どうでしょう。これは、selectNodes へのパラメータとして指定したパスと同じです。私たちは、"これらのレコードのすべてのプロパティを選択する" を意味する /* を使って、このパスをたどります。言い換えれば、返されたコレクションには、データベース内のすべてのレコードのすべてのプロパティが含まれています。これは、Windows® Management Instrumentation (WMI) の "Select * From" クエリと同じです。
注 : シンプルなスクリプトを試すと、私たちが言っている意味がわかるはずです。
スクリプトの残りの部分は簡単で、For Each ループを設定してコレクションを処理し、各項目とそれぞれのプロパティの Text プロパティの値をエコー バックするだけです。
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
車を追いかけるよりも、ずっと簡単です。
しかし、皆さんがおっしゃるとおりですね。ファイルのコンテンツ全体をエコー バックするだけであれば、その XML のすべてをバイパスして FileSystemObject を使用すれば済むことです (実際は、それよりも少し複雑になるかもしれませんが、ほんの少しだけです)。私たちの目的は皆さんを惑わせて「この XML というのは便利なんだ」と思わせることなので、もう少しお付き合いください。。
さて、どんな方法があるのかを考えてみましょう。最初のスクリプトでは、すべてのレコードのすべてのプロパティ値を取得しました。これで問題はないのですが、必要なのはスクリプト タイトルだけだったとしたらどうでしょうか。それは可能でしょうか。ちょっと待ってくださいね。
ルーシーによると、必要な処理は、selectNodes コマンドを変更してパスの最後に目的のプロパティを追加することだけです。つまり、次のようになります。
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
おわかりのように、最初にすべてのプロパティが取得された理由は、* ワイルドカードを使用したからです。ここでは、Title プロパティだけを取得します。なぜでしょうか。それは、これが取得するように言われた唯一のプロパティ値だからです。
注 : XML では、求めたものが正確に返されました。犬のルーシーに悪気はないのですが、XML は人類の最良の友になりました。
もちろん、1 つのプロパティ以上のものを返すことも可能です。たとえば、この変更されたコマンドは、Title プロパティと URL プロパティの両方を返します。
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
構文は少し変に見えますが、慣れれば問題ありません。始めるには、以前と同様にパスの親の部分を指定します。
    /Repository/Script/
次に、かっこのセットを追加して、返すプロパティをかっこの内側で指定します。個々のプロパティを区切るには、パイプ区切り文字 ( | ) を使用します。つまり、次のようになります。
    (Title | URL)
少し変に見えますが、これで問題なく機能します。
もちろん、2 つ以上のプロパティを返すことも可能です。パイプ区切り文字を使用している限り、必要な情報をすべて返すことができます。たとえば、次のコマンドでは 3 つのプロパティ(Title、URL、および Keyword) が返されます。
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
なかなか便利だと思いませんか。
私たちは、結構良いと思ったんですよ。皆さんは難しい方ばかりですね。でも、良い点にお気付きです。ここまでやったことは、データベース内のすべてのレコードに関する情報を取得することだけです。しかし、それで何も悪いことはありません。多くの場合は、これだけで十分です。しかし、これらのレコードのサブセットの情報だけを取得する場合の方が多いのです。たとえば、databases というキーワード (Keyward) を含むスクリプトに関する情報だけを取得するとします。お察しのとおり、次のような構文を使用します。
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
この構文も少し変に見えます。しかし、この構文は簡単でわかりやすいのが特長です。親パスを指定した後、"Where" 句 (x = y など) を角かっこの内側に配置します。
/Repository/Script [Keyword = ‘databases’]
既にお気付きかもしれませんが、Where 句に相当する部分がスクリプトに対して "Keyword 属性が databases に等しい項目だけを返す" ように指示しています。databases という語が引用符で囲まれていることに注意してください。これは必須です。フィルタする語を二重引用符で囲んだ場合、スクリプトを実行すると構文エラーが発生します。
その理由がわかりますか。クエリ文字列全体 ("/Repository/Script [Keyword = ‘databases’]") が二重引用符で囲まれているからです。
もちろん、データをフィルタするときは、等号以外も使用できます。大なり (>) 小なり (<) 記号に加えて、以上 (<=) および以下 (>=) 記号が使用可能です。また、これらの記号の前に感嘆符を配置して、記号をネゲートすることもできます。たとえば、次のコマンドは、Keyword が databases に等しくないすべてのスクリプトを取得します (!= に注意してください)。
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
ちょっと待ってください。「フィルタは設定できるけど、フィルタを設定すると同時に返すプロパティを指定することはできないでしょう」という質問ですか。もちろん、できます。
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
何の問題もなければ、このコマンドは、Keyword が databases であるすべてのスクリプトの Title プロパティだけを返します。確認してみましょう。
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
最後に、もう 1 つコマンドを含めることができるかどうか見てみましょう。かなりの進歩が見られましたが、まだ必要以上のレコードが返されている可能性があります。結局のところ、前のコマンドは Microsoft® Access® スクリプトと Microsoft SQL Server™ スクリプトの組み合わせを返します (その理由は、これらのすべてのスクリプトが databases という Keyword を使用するからです)。返されるデータを databases という Keyword と、Microsoft SQL Server という Subcategory のあるスクリプトに制限した場合はどうなるでしょうか。複数の条件に基づいてフィルタすることは可能でしょうか。
次の構文を見てください。
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
基本構文は同じです。2 つの条件 (Keyword = ‘databases’ および Subcategory = ‘Microsoft SQL Server’) を使用して、これらの 2 つを AND 演算子で接続しました。
注 : はい。おっしゃるとおりです。このシンプルな XML ファイルでは、Subcategory が Microsoft SQL Server であるすべてのスクリプトをリクエストできました。しかし、これでは何もおもしろくありませんし、学ぶべきこともありません。
OR 句を使用することもできます。たとえば、Subcategories が Microsoft Excel®、Microsoft PowerPoint®、Microsoft Outlook® などに等しい大量の Microsoft Office スクリプトがあるとします。返されるデータを Microsoft Word または Microsoft Access というサブカテゴリ (subcategories) からのスクリプトだけに制限することは可能でしょうか。もちろん可能です。
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
それらしくなりましたね。このコラムで皆さんの人生が変わるとは思えませんが、この方法で XML ファイルをクエリすることはできます。基本的な XML 技法を学習するか、車を追いかけるかは、皆さん方次第です。ご自由にどうぞ (後者を選んでルーシーに出くわした場合、Scripting Guy がよろしく言っていたと伝えてください。また、私たちの庭には近づかないようにとも伝えておいてください)。
Hey, Scripting Guy! - Every Day
今月の「Hey, Scripting Guy!」コラムを読んだ皆さんは、これが今まで読んだ中で最高の技術文書だと思ったはずです。これまで人類が記述したものの中で最高傑作と思っているかもしれません。ひょっとしたら、このような文書をもっと読みたくて郵便受けの前で次の TechNet Magazine を待っている方もいるかもしれません。
一体何を待っているのですか。我らがルーシーのことをもっと知りたいのですか。それとも、Scripting Son の最新の冒険談を読みたいのですか。去年の Turducken Bowl の結果をご存じですか。「Hey, Scripting Guy!」コラムを毎日読んで、重要な問題に遅れを取らないようにしてください。私たちは、毎週月曜日から金曜日まで (主な休日および Scripting Guy の休暇を除く)、高校野球、大学フットボールとバスケットボールに関するニュース、そして時には地域の天気予報をお知らせしています ("地域" というのはレドモンドのことですが、レドモンドの天候なんか興味がないでしょう)。
さらに、スクリプト記述に関する新しい事項を毎日学習できます。事実、この興味深いコラムの目玉はスクリプト記述に関する情報です。各コラムでは、Scripting Guy が実在すると信じている人々から寄せられた実際の質問に Scripting Guy がお答えします。毎日のコラムは、microsoft.com/japan/technet/scriptcenter/resources/qanda で読むことができます。また、これまでに Scripting Guy は多くの質問に答えているので、アーカイブは非常に豊富なスクリプト記述に関するソースとして活用できます (microsoft.com/japan/technet/scriptcenter/resources/qanda/hsgarch.mspx を参照してください)。
Scripting Guy に質問がある場合は、scripter@microsoft.com (英語) に質問を送信してください (送信されない質問にはお答えできません。しかし、送信された質問に Scripting Guy がお答えする確率は宝くじの当選率よりも高いはずです)。

Microsoft Scripting Guyは、マイクロソフトの仕事をしています。正確に言うと、マイクロソフトに雇われています。野球をプレイ、監督、観戦 (または他のさまざまな活動を) しているのでない限り、Scripting Guy は TechNet Script Center を運営しています。詳細については、http://www.microsoft.com/japan/technet/scriptcenter/default.mspx を参照してください。


 セキュリティ ウォッチ: EFS を展開する : 第 1 部
セキュリティ ウォッチ
EFS を展開する : 第 1 部
John Morello

皆さんは、ラップトップの盗難や置忘れが原因で、個人データや機密データが失われた、などのレポートを耳にしたことがあるでしょう。ラップトップの紛失は日常茶飯事に発生します。なりすまし犯罪が増加し、法令遵守がますます重要になっている現在、モバイル コンピューティング システムのデータを完全に保護することが不可欠となっています。
1 つの答えとして、Windows 2000 以降 Windows® に含まれている暗号化ファイル システム (EFS) を使用する方法があります。EFS は、組み込みで高パフォーマンスなディスク ベースの暗号化を提供します。EFS はエクスプローラとシームレスに統合しているため、使用しているファイルがいつ暗号化されているかエンド ユーザーに気づかれることはありません。さらに EFS はネイティブの Windows 認証やアクセス制御テクノロジとも同様にうまく機能するので、ユーザーはデータにアクセスするために別のパスワードを記憶する必要がありません。最終的に、EFS にはユーザーが暗号化キーにアクセスできなくなった場合 (ユーザー プロファイルが削除された、損傷した、あるいはスマート カードを損失した、などの場合) にデータを回復できる管理が容易なオプションがあります。
EFS は、Windows の組み込み暗号化テクノロジを使用して、強力な暗号化キーを生成、保存、展開し、データを保護します。Windows XP Service Pack 1 (SP1) 以降のバージョンでは、EFS は 256 ビット キーと一緒に Advanced Encryption Standard (AES) アルゴリズムを使用してディスク上のデータを暗号化します。これらの対称キーは、非対称 (RSA) キーのペアを使用して保護されます。EFS は AES キーを使用して各ファイルを暗号化し、ユーザーの RSA キーを使用してこのキーを暗号化して、その結果をファイルに保存します。EFS 暗号化の詳細については、見出し一覧の「EFS リソース」を参照してください。ここでは、EFS の技術的基盤ではなく、EFS を展開して使用中の環境で使用可能にする方法を重点的に説明します。このため、この記事では、EFS 暗号化の概念についての知識があることを前提としています。

EFS セキュリティについての注意事項
EFS 暗号化を解読する、あるいは破ると主張するアプリケーションがいくつかあります。これらのアプリケーションに、実際に AES (あるいは Data Encryption Standard － DES、もしくは Expanded Data Encryption Standard － DESX) で暗号化された暗号化テキストを解読するものはありません。ただし、これらのアプリケーションは、ユーザーのパスワードから強引にユーザーの EFS 秘密キーにアクセスします。EFS 暗号化に関して覚えておくべき重要なことは、暗号化データの生成と保護に使用される秘密キーがデータ保護 API (DPAPI) を使用しているということです。DPAPI では、ユーザーのログオン資格情報の派生物を使用してデータが保護されるので、EFS を使用したデータ保護は、ユーザーのパスワードと同程度の効果はあります。Windows Vista™ では、スマート カードに EFS 暗号化証明書を保存できるようになったため、パラダイムが変わり、EFS で保護されたデータの相対的なセキュリティが大幅に向上しました。
これらの攻撃に耐えるには、どれぐらいの長さのパスワードが必要ですか。今日のハードウェア機能や現代のパスワード攻撃アルゴリズムを考えると、11 文字以上のパスワード (正確にはパスフレーズ) をお勧めします。11 文字以上のパスフレーズは、事前計算済みのハッシュ攻撃 (Rainbow Table など。詳細については、[リソース] 見出し一覧の「Why you shouldn't be using passwords of any kind on your Windows networks」のブログ投稿 (英語) を参照してください) など、今日最も高度な方法に対して強い耐性があります。

PKI を使用するか使用しないか
EFS に関して、公開キー インフラストラクチャ (PKI) を使用しなければ機能しないという誤った認識がしばしばあります。組織で既に PKI が使用されている場合、EFS を統合して利用することは簡単ですが、これは要件ではありません。したがって、EFS 展開で PKI を使用するかしないかを決定することで、今後の多数の展開決定にも影響を及ぼすことになるので、最初に検討する必要があります。
EFS と一緒に PKI を使用する主な利点は、キーのアーカイブと回復を実行できる機能です。EFS を単独で使用してもデータ回復は実行できますが、自動キー回復は PKI がなければ使用できません。しかも Windows Server® 2003 Enterprise Edition を証明機関 (CA) として実行する必要があります。データ復旧は、暗号化キーにアクセスできなくなったユーザーが、データ回復エージェント (DRA) と呼ばれる指定の管理者に暗号化データを提供すると、DRA がデータを解読してユーザーに返すか、新しい秘密キーで使用するためにデータを再暗号化するプロセスです。ユーザーがこのキーを使用して暗号化する情報は DRA キーのコピーでも暗号化されるため、DRA はユーザーの暗号化プロセスのシャドウの役割を果たします。したがって、ユーザーがキーを紛失した場合でも、DRA が関係していれば、暗号化テキスト データを取得してこれを DRA キーに適用し、解読 (または再暗号化) したデータをユーザーに返すことができます。DRA のアプローチは効果的ですが、ユーザーの暗号化したデータが大量だったり、DRA の役割を果たすローカル IT スタッフがいなかったりする場合には、管理が難しくなります。
これに対してキー回復では、CA がキー作成プロセス時にユーザーの暗号化キーのコピーを作成し、そのキーのコピーを CA のデータベースに保存する必要があります。ユーザーが暗号化ファイルにアクセスできなくなっても、CA 管理者はこのデータベースを検索してユーザーのキーを取得するだけで済みます。その時点で、ユーザーは DRA に回復を依頼しなくても、データにすぐにアクセスできるようになります。この方法でキーを回復した方が、処理も速く効率的です。ただし、ベスト プラクティスとして、キー回復を使用した場合でも、キーを紛失した場合のバックアップ手段として DRA を準備しておくことをお勧めします。こうすれば、大規模な組織では、ローカル IT 管理者が PKI 管理者グループに依存することなくユーザーのデータを回復できる分散回復システムを持つことができます。
EFS と PKI を併用するもう 1 つの利点は、暗号化ファイルの共有が簡単になることです。EFS はラップトップ システムに限定されません。コンピュータの物理的なセキュリティが保証できないあらゆる状況に等しく有益です。これらの状況では、複数のユーザーが同じ暗号化データにアクセスしなければならない場合もあります。Windows での暗号化ファイルの共有サポートは、ディレクトリではなく個別のファイルの共有しか許可されていないため多少制限がありますが、役に立つツールにもなり得ます。ファイルを共有するユーザーは、EFS ファイルを共有しやすくするため、共有相手のユーザーの公開キーにアクセスする必要があります (有効な EFS 証明書が Active Directory® のアカウントに対して発行されている場合はこの方法が一番簡単です)。証明書を手動で発行することもできますが、Enterprise (Active Directory 統合) モードに Windows CA がインストールされていれば、このプロセスを完全に自動化できます。

EFS キー管理
Windows Server 2003 ベースの PKI を使用できる場合、ユーザーの EFS 証明書を生成するプロセスは簡単です。Windows Server 2003 CA には、基本 EFS などの証明書テンプレートの既定セットが用意されています。ただし、このテンプレートはバージョン 1 のテンプレートなので、キーのアーカイブはサポートされていません。そのため、CA でテンプレートを使用可能にする前に、テンプレートを複製して新しいバージョン 2 テンプレートを作成する必要があります (図 1 のように「キー アーカイブ付き EFS」などの名前を付けることができます)。新しいテンプレートの [要求処理] タブに移動し、ユーザーの暗号化キーをアーカイブするオプションを選択します。このオプションを有効にする前に、CA でキーのアーカイブを正しく構成しなければならないことに注意してください。「詳細情報」にはこのプロセスの優れた手引きが掲載されています。基本 EFS テンプレートに優先して、新しいバージョンを使用するようにこのテンプレートを設定することができます (図 2 を参照)。
図 1 キー アーカイブ付き EFS
図 1 キー アーカイブ付き EFS (画像を縮小するには、ここをクリックします)
図 1 キー アーカイブ付き EFS
図 1 キー アーカイブ付き EFS (画像を拡大するには、ここをクリックします)
図 2 基本 EFS テンプレートに優先します
図 2 基本 EFS テンプレートに優先します (画像を縮小するには、ここをクリックします)
図 2 基本 EFS テンプレートに優先します
図 2 基本 EFS テンプレートに優先します (画像を拡大するには、ここをクリックします)
次に、テンプレートに適切な権限を設定して、該当する一連のユーザーにのみ登録アクセスを許可する必要があります。Windows の EFS コンポーネントでは、EFS を最初に使用したときに証明書が自動的に要求されるため、EFS テンプレートへの自動登録をユーザーに許可する必要はないのが普通です。実際、自動登録されたユーザーが全員 EFS を使用していることが確実でない限り、EFS 証明書の自動登録を有効にしないことをお勧めします。図 3 に、EFS 登録設定を示します。EFS を使用しないユーザーに証明書を発行すると、何のメリットもなく CA データベースのサイズを増やすだけになります。CA データベース自体にサイズ制限はありませんが、証明書の発行部数が増えると、特に Microsoft 管理コンソール －MMC から管理することがますます難しくなります。
図 3 EFS ユーザー権限を設定する
図 3 EFS ユーザー権限を設定する (画像を縮小するには、ここをクリックします)
図 3 EFS ユーザー権限を設定する
図 3 EFS ユーザー権限を設定する (画像を拡大するには、ここをクリックします)
最後に、暗号化ファイルの共有をサポートしなければならない場合は、CA でユーザーの証明書を Active Directory に自動発行することもできます。
テンプレートが CA 上に正しく構成されると、ユーザーが最初に EFS を使用してファイルを暗号化したときに、証明書が CA から取得されます。秘密キーは CA によって自動的にアーカイブされます。

DRA キー管理
PKI を使用する準備が整っている場合に、次に考慮しなければならないことは、CA が生成した DRA 証明書を使用するかどうかです。PKI から DRA 証明書を使用しないのはなぜでしょうか。証明書の有効期限が迫っている (2 年未満) 発行元 CA がある、というシナリオを考えてみましょう。CA は自分の有効期限よりも長い有効期限を持つ証明書を発行することはできません。つまり DRA 証明書の有効期間は最大 2 年ということになります。このため、データ復旧シナリオがますます複雑になる可能性があります。この架空の例を次のシナリオに示します。
  1. ユーザーが 2006 年 1 月 にファイルを暗号化しました。グループ ポリシーからコンピュータにプッシュされる DRA 証明書の有効期間は 2 年間になります (2008 年 1 月に有効期限が切れます)。
  2. ユーザーは続けて EFS を使用して新しいファイルを暗号化します。
  3. 2008 年 1 月に DRA 証明書の有効期限が切れると、管理者はグループ ポリシーを通じて新しい証明書をプッシュ ダウンします。
  4. これ以降の暗号化操作にはすべて新しい DRA 証明書が使用されます (古い DRA を使用して暗号化されたファイルを開いた場合も、ファイルを保存すると新しい DRA が使用されます) が、ユーザーが開くことのないファイルも、古い DRA によって保護されています。
  5. ユーザーが誤ってプロファイルを破損し、データ復旧が必要になりました。
  6. この場合、IT 管理者には 2 つの DRA 証明書のセットが必要になります。手順 3 以降にアクセスしたすべてのファイルには新しい証明書が必要となり、手順 3 以降アクセスしなかったファイルには古い証明書が必要となります。
IT 管理者が手順 3 以降にスクリプト (cipher.exe /u) を実行して、新しい DRA ですべてのファイルを更新することもできますが、このプロセスには時間がかかります。また、当然のことですが、有効期限が切れた DRA 証明書が回復ポリシーに含まれている場合、EFS コンポーネントで新しい暗号化操作を行うことはできませんが、DRA キーのペアが有効期限後に無用になってしまうわけではありません。有効期限が切れた DRA キーのペアで暗号化された古いファイルも、そのキーで回復することが可能です。そのため、有効期限が切れた後も DRA キーのペアを破棄してはいけません。いつ必要になるかわからないからです。
このため、有効期間が短い CA がある環境では、有効期限の長い自己署名入りの DRA 証明書を使用することをお勧めします。暗号ユーティリティには、100 年の有効期間を持つ EFS 回復エージェントのキーのペアを自動的に作成するスイッチ (cipher.exe /r) があります (図 4 を参照)。このキーのペアから作成された証明書は、グループ ポリシー オブジェクト (GPO) に追加して、組織全体で DRA として使用することができます。EFS コンポーネントでは DRA 証明書の信頼チェーンがチェックされないので、システムに存在する信頼するルート証明機関のリストに変更を加えなくても、自己署名入り証明書を使用することができます。組織の CA の有効期間に関係なく、長期の有効期間を持つ DRA 証明書を少なくとも 1 つ作成して、ドメイン全体の GPO に追加することをお勧めします。これは他のオプションがすべて失敗した場合の代替手段です。これは CA キーをアーカイブせずに CA で生成された DRA キーを使用している場合に特に重要です。DRA 証明書が危険にさらされた場合は、新しい証明書で GPO を更新し、前述した cipher.exe /u を使用してファイルを更新することができます。

図 4 Ciquer /R を実行する (画像を縮小するには、ここをクリックします)

図 4 Ciquer /R を実行する (画像を拡大するには、ここをクリックします)
EFS のリソース
EFS の具体的な問題やベスト プラクティスの詳細については、以下のサイトを参照してください。
  • Why you shouldn’t be using passwords of any kind on your Windows networks(英語)
  • Implementing Key Archival Walkthrough(英語)
  • Encrypting File System in Windows XP and Windows Server 2003(英語)

KRA と DRA の展開
CA 管理者はキーのアーカイブを使用することで、ユーザーに代わって預託された暗号化キーを回復することができます。これは、CA 管理者が CA によって署名されたキーを使用して組織内のあらゆるデータを解読できることになるため、かなり細心の注意を要する強力な機能です。そのため、キーのアーカイブと回復は慎重に行う必要があります。また、この権限の付与は、信頼されている少数のセキュリティ担当者に限定する必要があります。キーの回復には細心の注意を要するため、EFS で暗号化されたデータへのアクセスを取り戻す主な方法にキーの回復を使用する場合は、CA 管理チームに回復要求を送信する際のエスカレーション プロセスを明確に設定しておくことが重要です。要求を慎重に検討するまでは、回復プロセスを開始しないでください。キーを実際に回復した場合は、回復したキーを使用することで EFS で保護されたすべてのユーザーのデータにアクセスできるため、セキュリティ保護された方法で (電子メールなどを使用せずに) キーをユーザーに届ける必要があります。
キー回復エージェント (KRA) キーは、生成されると CA 管理者によって保管されます。グループ ポリシーを通じてアドバタイズされることはありません。実際、EFS では使用するキーがアーカイブされているかどうかを判断できません。通常どおりに暗号化操作が行われるだけです。さらに、CA で作成された KRA キーは、EFS に固有ではありません。キーのアーカイブを使用している CA は、CA によってアーカイブされるキーを保護するために、CA レベルに n 個の KRA キーが追加されています。これらのキーには、EFS で使用されているキー、セキュリティ保護された電子メール、または暗号化が含まれるその他の証明書などがあります。KRA キーは個々のキー回復エージェントがセキュリティ保護して保存すべきです。また、キーの 1 つを紛失した場合の代替手段として、最低でも 2 つの KRA を使用する必要があります。
管理者が新しく作成されたドメインのドメイン コントローラに初めてログ オンすると、自己署名入りの証明書を使用してドメイン レベルに既定の回復ポリシーが作成され、DC の管理者のプロファイルにキーのペアが保存されます。この DRA 証明書の有効期間は 3 年間です。この既定の証明書を削除して、有効期間が長い自己署名入り証明書か PKI で発行された証明書と置き換えることをお勧めします。この既定の自己署名入り証明書を削除しないと、作成から 3 年後に EFS はドメイン全体で新しいファイルの暗号化を停止してしまいます。これは証明書の有効期限が切れると、有効期限の切れた DRA 証明書が回復ポリシーに含まれている場合、それ以降データを暗号化できないからです。回復エージェント ポリシーを実施せずに Windows XP 以降のシステムを実行することは可能ですが、できるだけ行わないことをお勧めします。そのようなことをすると、何らかの理由でユーザーが暗号化キーにアクセスできなくなったときにキー回復が不可能になり、データはすべて失われ、取り戻すことができなくなります。
説明したように、DRA キーには自己署名入りのものと CA から発行したものを使用できます。大抵の場合、ハイブリッド アプローチを採用し、回復エージェントの最後の手段として、企業全体で最低 2 つの長期の自己署名入り DRA を使用するのが最善の方法です。DRA 証明書はグループ ポリシー オブジェクトを通じて展開されるため、他の GPO と同じ機能を継承しています。つまり、他の GPO 設定の適用を制御する、標準のローカル、サイト、ドメイン、組織単位 (OU) GPO の累計および適用アルゴリズムが DRA にも適用されます。そのため組織では、中央の IT グループが企業のあらゆる部分に DRA でアクセスできる一方、ローカル IT グループは担当する特定領域にしかアクセスできないという多層アプローチを簡単に DRA に実装できます。これは、大規模で地理的に分散した組織にとって、データ回復を促進するために暗号化された大量のデータを WAN リンクを通じて転送する必要がなくなるため、特に貴重な資産です。図 5 は、DRA を多層展開した場合の標準的な例を示します。
図 5 DRA の多層展開
図 5 DRA の多層展開
この場合、バトン ルージュ OU のユーザーは、暗号化された各ファイルにつき、ローカル管理者から 2 つ、北米 IT グループから 2 つ、ドメイン レベルから 2 つの合計 6 つの DRA を持つことになります。したがって、ユーザーが暗号化されたデータにアクセスできなくなっても、バトン ルージュのローカル DRA か北米 IT グループから回復することができます。これらの 4 つの DRA を使用できなくなったり紛失したりしても、最後の手段としてドメイン レベルの DRA を使用してこのデータを回復することができます。どの DRA で回復を実行しても、プロセスは本質的に同じです。最初にユーザーが DRA でデータを使用できるようにします。DRA が必要な手順を踏んで、要求が合法であり、データの真の所有者から寄せられていることを確認することが重要です。合法であることが確認されると、DRA は DRA 証明書を読み込み、データを解読 (できれば再暗号化) して、データをエンド ユーザーに送り返します。問題のあるユーザーを DRA が実際に訪問し、自分の DRA キーのペアをプロファイルに読み込み、データを解読してからキー ペアを削除する、といったローカル回復を選択する組織もあります。そうすれば、ユーザーはプレーンテキスト形式のデータにアクセスし、新しいキーで再暗号化できます。このアプローチは DRA のキーのペアがローカル コンピュータに (一時的に) コピーされるので、安全性では劣りますが、大量のデータを回復しなければならない場合には時間を節約できます。
キーのアーカイブと回復による回復をユーザーに提供する場合は、このプロセスとはまったく別に回復要求を処理する必要があります。ユーザーの要求は、DRA を一切使用せずに CA 管理者に寄せられ、CA 管理者は要求を検証してからアーカイブを検索し、ユーザーの秘密キーを取得する必要があります。これに続き、CA 管理者はこの秘密キーをセキュリティ保護された Web サイトに置いてダウンロードしてもらうなど、セキュリティ保護された方法でユーザーに秘密キーを提供します (スマート カードを利用して Windows Vista から提供されている EFS キーを保存した場合は、そのキーも再発行する必要があります)。このキーをプロファイルに読み込むと、暗号化されたすべてのデータにすぐにアクセスできるようになります。
DRA と KRA のキーのペアで機密データを解読することができるため、キーのペアは正しく保護することが重要です。DRA と KRA のキーのペアは、通常の管理者のデスクトップ プロファイル (日常業務を行うプロファイル) には保存すべきではありません。フロッピー、光ディスク、フラッシュ メディアなど物理的に安全な場所にオフラインで保存する必要があります。回復が必要になると、回復エージェントがキーのペアをこのメディアから回復ワークステーションに読み込み、回復操作を実行してから、キーのペアを削除します。特にセキュリティに厳しい組織では、これらのキーのペアのセキュリティをさらに高めるために、回復用の専用ワークステーションが指定されている場合もありますが、これはすべての組織の要件ではありません。

次回予告
EFS 計画のキー管理、データ復旧、および Active Directory の側面について検証してきましたが、来月はこのトピックの第 2 部でクライアント側の展開に関する質問を重点的に見ていきます。グループ ポリシーを使用した EFS 使用の制御、暗号化対象情報の選択、ログオン スクリプトによるデータの自動暗号化、EFS で保護されたデータを簡単に使用するためのエクスプローラでのクライアント側の強化機能などについて説明する予定です。

John Morello は、ルイジアナ州立大学を首席で卒業し、マイクロソフトで 6 年間さまざまな任務を果たしてきました。シニア コンサルタントとして、フォーチュン 100 企業や連邦政府および国防省向けのセキュリティ ソリューションの設計に携わってきました。現在は Windows Server グループのプログラム マネージャとして、セキュリティおよびリモート アクセス テクノロジに取り組んでいます。


 デスクトップ ファイル: Windows PE を拡張する
デスクトップ ファイル
Windows PE を拡張する
Wes Miller

5 年以上も前に私たちが Windows PE をリリースしたときよりも前に、熱心なユーザーは、より多くの機能を求めていました。残念ながら、Windows PE は、オペレーティング システムの追加層を追加することによって拡張できる Windows XP Embedded と同じように簡単に拡張できるようには設計されていませんでした。もちろん、Windows PE には、基本的な
Win32® サポート (ほとんどの Windows® アプリケーションが機能することを可能にするため)、およびネットワークと大容量記憶域サポート (ネットワークを介して通信し、Windows をインストールすることを可能にするため) を実装する必要がありました。しかし、私たちは、当初からシェルを抑制することを考えていました。私たちは、従来の Windows エクスプローラ シェルではなく cmd.exe を使用することにより、Windows PE 環境が実行できることを制限しました。さらに重要なことですが、その結果、既定の環境では、すべての自動化タスクのスクリプトを簡単に記述することが可能になりました。
それでも、Windows PE を拡張することは可能です。ただ、制限があるので注意してください。図 1 に示すテクノロジが必要な場合は、アプリケーションが機能しない場合や正常に機能しない場合があります (これは包括的な一覧ではありません)。
Figure 1 不足している Windows API (Close Figure 1)

.NET Framework (任意のバージョン)
Active Directory® サービス インターフェイス (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (.NET 以前のバージョンを含む)
Windows と共にネイティブにインストールされないフレームワークを必要とする実行タイプ
エクスプローラまたは Internet Explorer
Windows Media® Player
SAPI、MAPI、TAPI (それぞれ Windows Speech、メール、テレフォニー API)
アプリケーションが何に依存するかがわからない場合は確認する必要があります。その方法を考えてみましょう。私たちも、ADO、HTML アプリケーション (HTA)、および Windows スクリプト ホスト (WSH) コンポーネントを Windows PE で動作させようとしたときに同じ問題に直面しました。この記事では、これらの依存関係を追跡する方法を説明しますが、MKIMG コマンドが含む以上の Windows バイナリを Windows PE イメージに追加することは、使用許諾契約書の条項に違反することに注意してください。そのような変更を環境に実装するには、マイクロソフトから追加ライセンスを取得する必要があります。

依存関係を理解する
アプリケーションの .inf ファイルをメモ帳で開いて注意深く検証すると、多くのことがわかります。事実、多くの場合、これはアプリケーションの意味を理解して、その依存関係を確認する最も簡単な方法です。Windows PE に関して理解しておくべき重要なことは、信頼できるレベルでアプリケーションを実行するには、依存関係を複数のレベル (アプリケーション自身の直接的な依存関係および直接的な依存関係が呼び込む依存関係の両方) でデバッグする必要があるということです。注意を怠ると依存関係が複雑になることがあります。いくつかの偶発的な (または意図的な) コンポーネント追加があると、イメージは複雑になりサイズも大きくなります。
アプリケーションを説明する .inf ファイルがない場合は、.ini がシステムに追加するレジストリおよびファイルを見つけることによって、依存関係に関するヒントを得ることができます。CopyFiles および AddReg セクションを探します。これらのエントリは、アプリケーションが依存するその他のアプリケーション、DLL、およびその他のファイルを参照します。Windows PE の 3 つのアドイン (ADO、HTA、および WSH) のうち、作成が最も簡単だったのは WSH です。再配布可能なバージョンの WSH は古いバージョンの Windows でも使用可能で、今日の Windows には WSH のファイル関連付けを実行する .inf が組み込まれているので、WSH を Windows PE にインストールすることは比較的簡単でした (%windir%\inf\wsh.inf)。

Orca およびスナップショット
アプリケーションが Microsoft® インストーラ (MSI) ファイルとして配布される場合、依存関係を検索するには 2 つの方法があります。MSI に精通しているユーザーは、Orca (Windows Server® 2003 R2 プラットフォーム SDK の一部として go.microsoft.com/fwlink/?LinkId=77941 (英語) で配布されている Windows インストーラ ファイル編集用ツール) を使用して MSI を表示できます。特定のコンポーネントの MSI をインストールして、ファイルおよびレジストリ キーの変更を行う前後の比較分析を実行することもできます。レジストリのダンプ、アプリケーションのインストール、レジストリ キーの再エクスポートを行った後に WinDiff を実行できます ("WinDiff を使用する" サイドバーを参照してください)。その結果は、レジストリに行う必要のある変更のテンプレートとして使用できます。問題は、変更の数が非常に多くなる可能性があることです。それでも、この方法は .inf を参照できない場合 (またはアプリケーションの作成者に確認できない場合) に最適なオプションです。
もう 1 つのオプションは、アプリケーション スナップショットです。本質的に、これはアプリケーションが実行できるようにすることを目的とした変更前後の比較分析と同じです。以前、マイクロソフトは、この比較分析を目的とした (Windows 2000 用) ツールを配布していましたが、そのツールは新しいバージョンの Windows では機能しません。この処理は、多くの商用アプリケーション (インストール リパッケージャ) だけでなく、一部のフリー ユーティリティでも行うことができます。ソリューションごとにプラットフォーム SDK をインストールします (前の段落内のリンクを参照してください)。プラットフォーム SDK には WinDiff が含まれています。WinDiff の比較分析を実行するには、実際に使用する Windows PE のバージョン (Windows PE 1.6) である Windows Server 2003 Service Pack 1 (SP1) にアプリケーションをインストールすることをお勧めします。Windows PE 1.6 は、Standard Edition または Enterprise Edition (SP1) からビルドされています。このタスクを Windows Server 2003 上で実行することによって、Windows PE での環境に最も近い環境をシミュレーションできます (Windows PE では MSI を実行できません)。詳細な手順については、"WinDiff を使用する" サイドバーを参照してください。
この方法では、十分な量の変更された情報が表示されます。残念ながら、変更された情報をレジストリまたはファイル キャプチャからエクスポートして、アプリケーションをインストールするマニフェストを作成するための簡単な方法はありません。変更は手動で組み込む必要があります。これが最初のバージョンの Windows PE における最も困難な問題でした。マイクロソフト内に HTA コンポーネントの定義がなかったので (Internet Explorer® の外部)、HTA コンポーネントを機能させることは複雑な作業でした。私たちは、差分を使用することによって、機能するために十分な HTA を手動で処理できました。これらのキーを手動で Windows PE レジストリに追加することは可能ですが、キーは Windows PE が起動した後に追加することをお勧めします。Windows PE ビルド ツールに含まれている buildoptionalcomponents.vbs スクリプトを使用して、HTA、WSH、または ADO サポートを Windows PE にインストールするために使用した OC.bat および OC2.bat ファイルを表示できます。

便利なツール
直接的な依存関係を分離した後でも、アプリケーションが依存する個々のバイナリを見つけることができない場合があります。たとえば、同じタスクを実行するために別の DLL または OCX が必要かどうかがわからない場合があります。どうやって判断すればよいでしょうか。Sysinternals の Mark Russinovich (現在はマイクロソフトのテクニカル フェロー) が、この処理を行う listdlls という便利なユーティリティを記述しています。Listdlls は、microsoft.com/technet/sysinternals/utilities/ListDlls.mspx(英語) からダウンロードできます。このユーティリティを使用するには、コマンド listdlls.exe > dlls.txt を実行して出力を確認します。図 2 は、listdlls 自身に対して実行した listdlls の出力を示します。このリストを Windows PE に含まれている DLL および OCX ファイルと比較して、アプリケーションのすべての依存関係が存在するかどうかを確認できます (listdlls の場合、すべての依存関係が存在します)。Windows PE の HTA サポートに関しては、その他の方法で識別できなかった依存関係を識別するために listdlls が不可欠でした。
図 2 自身に対して実行された Lisdlls の出力
図 2 自身に対して実行された Lisdlls の出力 (画像を縮小するには、ここをクリックします)
図 2 自身に対して実行された Lisdlls の出力
図 2 自身に対して実行された Lisdlls の出力 (画像を拡大するには、ここをクリックします)
しかし、DLL がリストに含まれていても、アプリケーションが機能するためにその DLL が必ずしも必要なわけではありません。たとえば、メモ帳を起動すると、uxtheme.dll が読み込まれます。Windows PE では、この DLL は使用できません。実際のところ、Windows テーマは使われないので、この DLL が読み込まれることはありません。listdlls によって出力されるどの DLL が実際に必要で、どの DLL が Windows によってオンデマンドで読み込まれるかを理解するには、多くの試行錯誤を行うか、Windows の非常に低レベルの側面を理解する必要があります (後者については、2004 年に Microsoft Press® から刊行された Mark Russinovich、David Solomon 共著『Microsoft Windows Internals, Fourth Edition』を参照することをお勧めします)。
事実、Mark Russinovich は、Windows タスク マネージャの代替として無償で提供されている Process Explorer に同じ機能を組み込んでいます。listdlls は、(個人的な意見では) 簡単にスクリプト化して不足している依存関係の検出および収集に使用できる出力を作成する点が異なります。
一度でもイメージに DLL を追加すると、何らかの作業を行わなければならない可能性があることに注意してください。DLL には、登録が必要なものと必要でないものの 2 種類があります。残念ながら、この 2 つを簡単に区別する方法はないので、1 つずつ登録してみる必要があります。DLL (または OCX) を登録するには、regsvr32 dllname.dll を実行します。これが正常に機能した場合は、DLL が登録されたことを示すダイアログ ボックスが表示されます。正常に機能しなかった場合は、メッセージが表示されないこともありますが、多くの場合、DLL の登録に失敗したこと、または DLL を登録できなかったことを示すダイアログ ボックスが表示されます。Windows PE の HTA および ADO オプション コンポーネントを開発している間、私たちは、DLL の登録を行うとき、インストール用に .inf ファイルを一時的に書き込むため、またはその他の依存関係 (必要な特定のディレクトリなど) を記録するために、書き込み可能なストレージが DLL に必要なことを発見しました。Windows PE では、これは失敗を意味するものでした。幸いなことに、Windows PE 2.0 では、使用可能なスクラッチ領域が既定で存在するので、このようなタスクが機能するようになりました。
Mark Russinovich が作成した 3 つ目のツールは、最近リリースされた Process Monitor というツールです。Process Monitor は、Regmon および Filemon のスーパーセットとして表示でき、Regmon や Filemon よりも高度な詳細を提供し、プロセス間通信の新しい層を追加します。この非常に強力なツールは、Windows でのアプリケーションのトラブルシューティングだけでなく、DLL の相互依存関係がどのようになっているかを確認するためにも役立ちます。Process Monitor は、ダウンロードして入手できます (英語)。

Windows PE ファイルを削除する
Windows PE にコンポーネントを追加する機能と同様に、頻繁に寄せられるもう 1 つのリクエストは、Windows PE のサイズを小さくする方法でした。Windows PE のサイズを小さくするために実行できるいくつかの手順があります。Windows PE のライセンス コピーには、一連のビルド ツールおよびドキュメントが含まれています。ドキュメントには winpe.chm というヘルプ ファイルが含まれています。このファイルを開きます。「Windows Preinstallation Environment User’s Guide」セクションに「Reducing the Size of Windows PE」というタイトルのトピックがあります。このセクションには、不要な場合に安全に削除できるファイルのリストがあります。削除可能なファイルに関するセクションは 3 つあります。
  • フォント ファイルは常に安全に削除できます。
  • ネットワーク関連の .inf ファイルおよびユーティリティは削除できますが、対象のビルドをネットワークで一切使用しない場合にのみ削除してください。
  • コマンドライン ユーティリティを削除することはお勧めしません。その機能が明白で、削除した場合の結果も明白である場合以外は、コマンドライン ユーティリティは削除しないでください。
どのファイルを安全に除外できるかを判断したら、mkimg.cmd によってビルドが完了した後に、バッチ ファイルまたはその他のスクリプトを記述して Windows PE ビルドからファイルを削除できます。

Windows PE のレジストリを変更する
私たちは、ビルド時にオプション コンポーネントを意図的にインストールしませんでした。実行時に余計な時間がかかりましたが、これらのコンポーネントを Windows PE に組み込むための新しい方法をゼロから作る必要はありませんでした (そのような時間的および労力的な余裕はありませんでした)。しかし、レジストリを変更する場合 (アプリケーションにレジストリ変更のデルタを追加する場合やアプリケーションが機能するために必要な可能性のあるキーを編集する場合) はどうでしょうか。レジストリの変更は図 3 に示すように、regedit を使用して簡単に行うことができます。次の手順に従います。
  1. regedit を実行して、HKEY_LOCAL_MACHINE ハイブを選択します。
  2. [ファイル] メニューの [ハイブの読み込み] を選択して、Windows PE ビルドの位置を参照します。I386\System32\ (ハード ドライブに配置するイメージの場合は MiniNT\System32) にある setupreg.hiv を選択します。
  3. ハイブの一時的な名前 ("WinPE" など) を入力して、HKLM の下にあるそのノードを参照します。
  4. このキーを必要に応じて変更します。効果としては、このノードは Windows の通常のインストールにおけるノード HKLM\System と同じです。
  5. 変更を行った後、手順 3 で HKLM の下に作成したキーを選択します (この手順を正しく実行しないと、システムが壊れることがあります)。
  6. [ファイル] メニューの [ハイブのアンロード] を選択します。確認ダイアログ ボックスで [はい] または [いいえ] を選択します。レジストリをロックしたままにすると Windows PE を正常にビルドできないので、レジストリのマウントは毎回確実に解除してください。
図 3 Windows PE のレジストリを開く
図 3 Windows PE のレジストリを開く (画像を縮小するには、ここをクリックします)
図 3 Windows PE のレジストリを開く
図 3 Windows PE のレジストリを開く (画像を拡大するには、ここをクリックします)
これらの手順に従って HKLM\System を変更できます。I386\System32 には、レジストリのその他の領域を変更できるその他の 2 つのキーがあります。DEFAULT はユーザー (または Windows PE を使用する際に実行する SYSTEM) の既定のハイブで、SOFTWARE は HKLM\Software と同じです。レジストリは必要な場合にのみ変更し、変更する際は十分注意してください。
トラブルシューティングまたはリカバリ ツールを Windows PE に追加するために役立つ手順が理解できたと思います。来月は、Mark Russinovich が記述した非常に便利なシステム管理ツールのコレクションである PSTools スイートについて説明します。
WinDiff を使用する
WinDiff は、アプリケーションの依存関係の検索に便利です。WinDiff をインストールして実行するには、以下の手順に従います。
  1. 時間を節約し、最初と最後のスナップショットの間でのファイルまたはレジストリの変更を最小限に抑えるために、システムでインストールの準備をします。
  2. コマンド プロンプトを開いて、reg export HKLM C:\HKLM1.reg を実行してHKEY_Local_Machine レジストリ ハイブの完全なエクスポートを実行します。
  3. dir C:\*.* /S > C:\C1.txt を実行して、C: ドライブ上のすべてのファイルの完全なダンプを実行します (C: がシステム ドライブであることを前提とします)。
  4. アプリケーションをインストールして、インストール後の設定を構成します。
  5. reg export HKLM C:\HKLM2.reg を実行します。
  6. dir C:\*.* /S > C:\C2.txt を実行します。
  7. WinDiff を開いて、[File] メニューの [Compare Files] を選択し、[Select First File] ダイアログ ボックスで HKLM1 .reg を選択し、[Select Second File] ダイアログ ボックスで HKLM2.reg を選択します。
  8. 新しいファイルを示すメッセージが赤で表示されます。HKLM エクスポートのサイズは非常に大きい場合があるので、この処理には時間がかかることがあります。
  9. 相違点を展開するには、赤いテキストをダブルクリックします。
  10. 比較の表示内容を構成するには、[Options] メニューの [Show Right-Only Lines] を選択します。2 番目の比較対象ファイルに新しく追加された行だけが表示されます (新しいファイルおよび新しいレジストリ キーだけが表示されます)。
アプリケーションに関連するキーを見つけるには、検索機能を使用しなければならない場合があります。図 A および B では、私が作成した機能的アプリケーションのファイルおよびレジストリの変更が確認できます。WinDiff ではコピーおよび貼り付け機能が使用できます。これらの機能を使用するには、!> 行をクリックして、目的の行を選択します。
図 A WinDiff のエントリ
図 A WinDiff のエントリ (画像を縮小するには、ここをクリックします)
図 A WinDiff のエントリ
図 A WinDiff のエントリ (画像を拡大するには、ここをクリックします)
図 B WinDiff の特定のキー
図 B WinDiff の特定のキー (画像を縮小するには、ここをクリックします)
図 B WinDiff の特定のキー
図 B WinDiff の特定のキー (画像を拡大するには、ここをクリックします)

Wes Millerは、テキサス州オースティンにある Pluck 社 (www.pluck.com)(英語) の開発マネージャです。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com(英語) です。


 フィールド ノート: 機能しない理由
フィールド ノート
機能しない理由
R'ykandar Korra'ti

「だから、言ってるじゃないですか。 すぐ落ちるんですよ。」
「特定の時間帯に接続が切断されるということですか。それとも、何か特定の操作をしたときに切断されるのでしょうか。特定の機器から接続しているということはありませんか。」
「いいえ。「正常に接続していたのに突然落ちるんです。いつも突然です。」
「しかし、それでは状況が判断できません。思い当たるようなことや何かヒントになるようなことはありませんか。」
「わかっていることは全部お話しました。突然落ちるんです。何とかなりませんか。」
結局、何の助けにもなりませんでした。ルーターのログには特に注目すべきことは記録されていませんが、私たちのトラフィックは時々ドロップすることがありました。何か問題があるはずなのですが、1 分か 2 分たつと正常に機能するようになります。エラーやパターンはなく、突然トラフィックがドロップするのです。奇妙なことでしたが、幸いにも偶然の力によって解決されました。
DSL に接続されている電話が鳴ります。
IP 接続は「Thunk 終了」を示します。
何かの間違いと思いましたが、使用されておらず、誰も知らないはずの DSL の電話番号を誰かがダイヤルすると、私たちの接続が切断されるのです。電話会社に問い合わせても何の解決にもなりませんでした。
私たちの建物は分岐局から 300 メートルほどしか離れていないので、このような現象は発生するはずがありません。私はケーブルをチェックし、すべての機器をリセットしました。念のためにコネクタも掃除しました。しかし、状況は依然として同じでした。それで私は電話会社に問い合わせたのです。「電話がかかってきても接続が切断されることはないと言われましたが、頻繁に接続が切れるんですよ。電話セールスからの DoS 攻撃かもしれません。」
ケーブルの問題...
ケーブルの問題...
翌日、技術者が来て確認したところ、私たちの建物と分岐局との間には 1 キロもの距離があったことが判明しました。よく調べてみると、この地域に配線工事を行った際、新しいケーブルを配線することなく、区域内のすべての電話線を一緒にして 1 本の回線で個々の建物に配線していたことがわかりました。アナログ配線の場合、これで何の問題もありませんが、DSL の場合は、このような配線による距離は分岐局からの実質的な距離として考える必要があり、その距離が大きいほど信号は弱くなります。
幸い、私たちの問題は簡単に解決できました。回線のすべての副分岐を切断して、「DSL 使用中。再接続しないでください。」というメモを貼ったのです。これで距離は、わずか 300 メートル。信号も十分な強さで、電話が鳴っても切断されることはなくなりました。
この話から得た教訓として、接続障害は難解なものであるとかソフトウェアが原因であると思い込んではいけません。単にケーブルに問題があるのかもしれません。電話会社の技術者が必要ないと考えていたとしても、設置する際には DSL 信号の実際の強さを確認してもらうことが大事です。どのような配線構造になっているかは誰にもわからないのです。また、分岐局からの距離も額面通りに受け取ることは危険です。線がどういう経路で配線されているかは電話会社の技術者でさえ知らないので、確認する必要があります。電話会社の技術者は適切な道具を持っています。それを活用しない道理はないでしょう。電話セールスに DSL 番号が知られた際には、そのような道具が特に必要になります。

R'ykandar Korra'tiは、パートナーの Anna と共に小規模な共同 ISP のポストマスタを努めています。以前にマイクロソフトでメール製品を出荷していた R'ykandar Korra'ti は現在、大学院で非常に難解なため名前もない分野の研究を行っています。R'ykandar Korra'ti の連絡先は、darako@murkworks.net です。


 Windows 秘話: 功罪混合
Windows 秘話
功罪混合
Raymond Chen

CD や DVD を挿入すると、 シェルによってディスクの "スニッフィング" が行われて、そのコンテンツの種類が判断されます。この判断に基づいて、実行すべき自動再生アクションが決定されます。スニッフィングがどのように行われるかの詳細については、将来さらに優れたアルゴリズムが見つかった場合に変更される経験則なので文書化されていません。
アルゴリズムを公式に文書化すると契約の概念が発生するので、今後のリリースでアルゴリズムを変更できなくなります。したがって、アルゴリズムの詳細については正式には指定されていません。
これまで SDK の文書を記述したことがない方は、文書化が契約につながることをご存じないかもしれません。特定の動作に関する記録がある場合、それを変更することはできません。変更した場合、その動作に依存している人々から、「文書に記載されている内容と違うじゃないか。ゲームが始まった後にルールを変更することはできないよ。」と言われてしまいます。
この注意を踏まえて、ここでは、autorun.inf ファイルがないデータ CD およびデータ DVD のコンテンツが Windows® XP Service Pack 2 (SP2) でどのように分類されるかを驚くほど簡略化して説明します (今後の Service Pack および今後のバージョンの Windows では動作が異なる可能性があります)。「驚くほど簡略化して」と言った理由は、実際のアルゴリズムが、フォアグラウンド アプリケーションが "Query cancel autoplay" 通知に応答するかどうか、全画面プログラムが実行中であるかどうか、コンピュータがラップトップかどうかなどというすべての種類の情報が考慮される 61 ものステップに基づいたディシジョン テーブルだからです。しかし、ここでは、コンテンツ スニッフィングのステップだけを説明するつもりはありません。

まず、シェルでは、すべてのコンテンツ タイプに対するアクションとして "何もしない" が指定されているかどうかをチェックします。指定されている場合は、スニッフィングを行う必要はありません。判断は "何もしない" です。
指定されている場合は、シェルで何らかの処理が必要です。ディスク上の各ファイル (最大 4 レベル下の階層まで) がチェックされ、ファイルは識別されたタイプに基づいて、画像、音楽、ムービーのカテゴリに分類されます。
これらのカテゴリに該当しないファイルは無視されます。チェックされたすべてのファイルに該当するのが 1 つのカテゴリだけの場合 (ディスク上のすべてのファイルが音楽ファイルである場合など)、ディスクの種類が決定されます。3 つのカテゴリのうち複数のカテゴリが該当する場合、ディスクは混在したコンテンツと見なされます。
これは、音楽ファイルで構成された CD にアルバム アートが含まれている場合、Windows XP SP2 では、この CD は混在したコンテンツとして扱われることを意味します。この点は変更の必要があるかもしれません。しかし、このアルゴリズムを変更して、MP3 ファイルで構成された CD に画像データが含まれている場合に混在したコンテンツと見なされないようにすると、主にオーディオ ファイルで構成され少量の画像を含む CD をレコード会社が発売した場合、このレコード会社は、その CD が混在したコンテンツとして検出されることを予想しています。しかし、アルゴリズムが変更されているので、CD は音楽 CD として認識されます。そうなれば、レコード会社は抗議するでしょう。この場合、責任はどこにあるのでしょうか。スニッフィング アルゴリズムに依存したレコード会社でしょうか。それとも、アルゴリズムが変更された Windows でしょうか。
驚くなかれ、ほんの少しですが、Windows Vista™ ではアルゴリズムが変更されています。Windows Vista では、よく知られた特定のディスク レイアウトのアルゴリズムを簡略化するために、いくつかのチェックが事前に行われます。たとえば、ディスクのルートに DCIM フォルダが存在する場合、デジタル写真が含まれていると見なされます。気が付く人がいるかどうか、楽しみです。

Raymond Chenの Web サイト「The Old New Thing」(英語) および同じタイトルの著作 (Addison-Wesley、2007 年) では、Windows の歴史と Win32 プログラミングを扱っています。Raymond Chen は、太陽はどのような形をしているのかを考えています。