 TechNet Magazine April 2007
TechNet Magazine April 2007
APRIL 2007
Windows の管理

今月号も、Mark Russinovich による Windows Vista カーネルの解説をお届けします。今回は、セキュリティ、信頼性、および回復に関する機能強化の詳細に迫ります。Active Directory の回復も今月の中心トピックです。緊急時になってから対処するのではなく、Active Directory の回復計画を事前に用意しておくことが大切です。最後に、あなたの組織では Windows XP Embedded の出番がないと決めてしまう前に、今月号の記事をお読みください。きっと驚かれることでしょう。

管理

ハードウェアのキャパシティとコスト効率は、どのようにしてバランスを取ったらよいのでしょうか。今月は、System Center Capacity Planner を使用して、インフラストラクチャの要件をモデル化します。また、Systems Management Server、WMI、それにわずかなスクリプティングを組み合わせて、クライアントのインベントリ レポートを向上させる方法、SMS を使用してカスタム更新プログラムを展開する方法もご紹介します。
特集
Windows の管理 Windows Vista カーネルの内部 : 第 3 部

Windows Vista カーネルの新機能について詳しく説明するシリーズを今回で締めくくります。この最終回では、信頼性、回復、およびセキュリティに関する変更点と新機能に注目します。

Mark Russinovich 障害回復: Active Directory ユーザーとグループ

Active Directory のデータ回復作業は非常に複雑ですが、適切な障害回復計画を用意しておくことが肝心です。この記事では、ユーザーまたはグループのメンバシップが誤って削除されてしまった場合に備えて、Active Directory のオブジェクトの保存、削除、復元、およびレプリケーション (複製) のしくみについて説明します。

Gil Kirkpatrick Windows XP Embedded の重要性

ご存知ないかもしれませんが、Windows XP Embedded は組織の IT ツールとして非常に役立つ場合があります。この記事では、Windows XP Embedded を使用して、管理オーバーヘッドの軽減、経費の節約、およびセキュリティの強化をどのように実現できるかについて説明します。

Don Jones 管理 System Center Capacity Planner による事前計画

ハードウェアは、不十分だと応答時間の低下につながり、過剰になりすぎると予算や管理リソースを浪費します。ここでは、System Center Capacity Planner を使用して、ネットワークをモデル化し、インフラストラクチャのニーズを正確に見積もる方法について説明します。

John Savill SMS によるアドバンスト クライアント インベントリ

Microsoft Systems Management Server 2003 は、購入時の設定のままでも多くの情報を収集しますが、ユーザーが必要とする量の情報をすべて収集するわけではありません。この記事では、スクリプティング、WMI、および SMS の知識を正しく組み合わせて、必要な少量の情報だけを収集およびレポートするように SMS インベントリを拡張する方法について説明します。

Wes Dobry SMS 2003 R2 を使用してソフトウェアのカスタム更新プログラムを展開する

Systems Management Server 2003 R2 では、更新プログラム管理機能を使用して、カスタム更新プログラムを展開することができます。この記事では、カスタム更新プログラム用インベントリ ツールと、カスタム更新プログラム用発行ツールという 2 つの新しいツールを紹介します。これらのツールは、社内アプリケーションや、サードパーティ製ソフトウェアの更新プログラムを展開する際に役立ちます。

Steve Rachui
コラム
編集者から

間違えた場合は...

Joshua Trupin ツールボックス

IT プロのための新製品

Greg Steen SQL に関する Q&A

インデックスの再構築、ディスク キューの長さなど

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

Autoruns

Lance Whitney The Cable Guy

Windows Vista 用ワイヤレス グループ ポリシーの設定

Joseph Davies Windows PowerShell

データのフィルタ処理と書式設定を行う

Don Jones 		Hey, Scripting Guy!

世間知らずがローカル ユーザーとグループに挑戦する

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

セキュリティの構成ウィザード

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

x64 という選択

Wes Miller Microsoft.com の内部

Active Directory フェデレーション サービスを使用する

Jim Guthrie フィールド ノート

学びの喜び (と苦しみ)

Mark D. Scott Windows 秘話

バグの力

Raymond Chen


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

Windows Vista カーネルの内部 : 第 3 部
概要:
  • 信頼性
  • 回復
  • セキュリティ

このシリーズでは、これまでプロセス、I/O、メモリ管理、システムの起動とシャットダウン、および電源管理に関係する Windows Vista カーネルの強化点について説明してきました。シリーズの最終回にあたるこの第 3 部
では、信頼性、回復、およびセキュリティの分野における機能と機能強化を見ていきます。
今回のシリーズで説明しなかった機能の 1 つにユーザー アカウント制御 (UAC) があります。UAC は、レガシ アプリケーション向けのファイル システムとレジストリの仮想化、管理者権限にアクセスするための権限昇格の同意、管理者権限で実行されるプロセスと同じアカウントで実行される権限の低いプロセスを分離するための Windows® 整合性レベル メカニズムなど、いくつか異なるテクノロジから成り立っています。UAC の内部情報については、TechNet Magazine の今後の記事で詳しく説明する予定です。
Windows Vista™ では多くの新機能や機能強化により、システムの信頼性と、システムやアプリケーションの問題を診断する機能が向上しています。たとえば、Windows イベント トレース (ETW) のカーネル ロガーが常時アクティブになっていて、ファイル、レジストリ、割り込みなどの各種アクティビティのトレース イベントを循環バッファに生成しています。問題が発生すると、新しい Windows 診断インフラストラクチャ (WDI) によりこのバッファのスナップショットが取得され、これをローカルに分析したり、トラブルシューティングを行うために Microsoft サポートにアップロードすることができます。
ユーザーは、新しい Windows 信頼性とパフォーマンス モニタを使用して、クラッシュやハングなどのエラーと、システム構成に行った変更とを相互に関連付けることができます。ブートできないシステムをオフラインで回復するための回復コンソールに代わって、優れた System Repair Tool (SRT) が用意されています。
システムに対するカーネル レベルの変更に依存する分野は 3 つあります。そのため、この記事を詳しく調べるメリットがあります。この 3 つの分野とは、カーネル トランザクション マネージャ (KTM)、強化されたクラッシュ処理、および以前のバージョンです。

カーネル トランザクション マネージャ
ソフトウェア開発において退屈な作業の 1 つは、エラー状態の処理です。このことは、アプリケーションで一連の高度な操作を行っていく中で、ファイル システムやレジストリを変更する 1 つ以上のサブタスクを既に完了している場合に特に当てはまります。たとえば、アプリケーションのソフトウェア更新サービスでレジストリをいくつか更新し、アプリケーションの実行可能ファイルの 1 つを置き換えた後に、2 つ目の実行可能ファイルを更新しようとしたときに、アクセスが拒否されたとします。このサービスでは、このような結果としてアプリケーションを一貫性のない状態のままにしておくことができない場合、行ったすべての変更を追跡して、それらを元に戻す準備を行う必要があります。エラーを回復するコードのテストは困難で、その結果としてテストがスキップされることもよくあるので、回復コードのエラーによって、それまでの作業が無効になる可能性もあります。
Windows Vista 向けに作成されたアプリケーションでは、カーネル トランザクション マネージャによる NTFS とレジストリの新しいトランザクション サポートを使用して、ほとんど作業をする必要なしに、エラーの回復機能を利用できます。アプリケーションで関連性のある多くの変更を行う必要があるときは、分散トランザクション コーディネータ (DTC) と KTM トランザクション ハンドルを作成するか、直接 KTM ハンドルを作成して、ファイルやレジストリ キーの変更をトランザクションに関連付けることができます。すべての変更が正しく行われると、アプリケーションはトランザクションをコミットして、その変更を適用しますが、トランザクションを任意の時点までロールバックして、変更を破棄することもできます。
また、トランザクションがコミットされるまで、他のアプリケーションからはトランザクション内で行われる変更を確認できないことや、Windows Vista およびまもなくリリースされる Windows Server® "Longhorn" で DTC を使用するアプリケーションはトランザクションを SQL Server™、Microsoft® メッセージ キュー サーバー (MSMQ) などのデータベースと調整できることも大きなメリットです。したがって、KTM トランザクションを使用するアプリケーション更新サービスでは、アプリケーションが一貫性のない状態で残ることがなくなります。Windows Update とシステムの復元がどちらもトランザクションを使用している理由はこの点にあります。
KTM では、トランザクション サポートの中心部として、NTFS やレジストリなどのトランザクション リソース マネージャがあり、アプリケーションで行われる変更の特定のセットに対してその更新を調整できます。Windows Vista では、NTFS はトランザクションのサポートに TxF という拡張機能を使用します。レジストリは、同様のサポートに TxR という拡張機能を使用します。ユーザー モードのリソース マネージャが DTC を使用して、複数のユーザー モード リソース マネージャ間でトランザクションの状態を調整するのとまったく同様に、カーネル モードのリソース マネージャは KTM と連携動作して、トランザクションの状態を調整します。サードパーティも KTM を使用して、独自のリソース マネージャを実装できます。
TxF と TxR はどちらもファイル システム API とレジストリ API の新しいセットを定義します。これらの API は、トランザクション パラメータを含むことを除いて、既存の API と同じです。トランザクション内でファイルを作成するアプリケーションでは、まず、KTM を使用してトランザクションを作成します。その結果得られたトランザクション ハンドルを新しいファイル作成 API に渡します。
TxF と TxR は、どちらも共通ログ ファイル システム、つまり CLFS (%SystemRoot%\System32\Clfs.sys) の高速ファイル システムログ記録機能に依存します。CLFS は Windows Server 2003 R2 で導入されました。TxR と TxF は CLFS を使用して、トランザクションをコミットする前に、トランザクションの状態変化を永続的に保存します。そのため、電源が落ちた場合でも、トランザクションによる回復および保証を行うことができます。TxR では CLFS ログ以外に、図 1 に示すように、トランザクション変更を追跡するため、関連する複数のログ ファイルを %Systemroot%\System32\Config\Txr にあるシステムのレジストリ ファイルに作成します。併せてログ ファイルのセットをユーザーのレジストリ ハイブごとに分割します。TxF では、\$Extend\$RmMetadata というボリュームの隠しディレクトリに、ボリュームごとのトランザクション データを格納します。
図 1 システム レジストリ ハイブ TxR ログ記録ファイル
図 1 システム レジストリ ハイブ TxR ログ記録ファイル (画像を縮小するには、ここをクリックします)
図 1 システム レジストリ ハイブ TxR ログ記録ファイル
図 1 システム レジストリ ハイブ TxR ログ記録ファイル (画像を拡大するには、ここをクリックします)

クラッシュ サポートの強化
Windows では、不適切なデバイス ドライバ、ハードウェアの故障、オペレーティング システムなどが原因となる回復不可能なカーネル モードのエラーを検出すると、"死のブルー スクリーン" として知られる表示を行った後システムを停止し、ディスク上のデータが破損するのを防ごうとします。このとき、構成に応じて、物理メモリの一部またはすべての内容をクラッシュ ダンプ ファイルに書き込みます。クラッシュから再起動するときに、根本原因を探るため Microsoft Online Crash Analysis (OCA) サービスによってダンプ ファイルの分析が行われるので、ダンプ ファイルがあると役に立ちます。必要であれば、Microsoft Debugging Tools for Windows を使用してユーザー自身でもダンプ ファイルを分析できます。
ただし、以前のバージョンの Windows では、セッション マネージャ (%Systemroot%\System32\Smss.exe) が初期化済みのページング ファイルを処理するまではクラッシュ ダンプのサポートが有効になりませんでした。つまり、その時点よりも前にブルー スクリーンの原因となる重大なエラーが発生すると、ダンプ ファイルが存在しません。デバイス ドライバの初期化の大半は Smss.exe が開始する以前に行われるため、早い段階でクラッシュするとクラッシュ ダンプが行われず、原因の診断が極めて困難になります。
Windows Vista では、すべてのブート開始デバイス ドライバの初期化後、システム開始ドライバを読み込む前に、ダンプ ファイル サポートを初期化することによって、ダンプ ファイルが生成されない期間を短縮します。この変更により、起動プロセスの初期段階でクラッシュが発生した場合でも、システムでクラッシュ ダンプを取得でき、OCA が問題を解決するのを支援できます。さらに、Windows Vista ではデータが 64 KB のブロック単位にデータがダンプ ファイルに保存されます。それに対して、以前のバージョンの Windows では 4KB のブロック単位に書き込まれていました。この変更により、大きなダンプ ファイルの書き込みが以前に比べて 10 倍高速になります。
Windows Vista では、アプリケーションのクラッシュ処理も強化されています。以前のバージョンの Windows では、アプリケーションがクラッシュすると、ハンドルされない例外のハンドラが実行されました。このハンドラは Microsoft アプリケーション エラー報告 (AER) プロセス (%Systemroot%\System32\Dwwin.exe) を起動し、プログラムがクラッシュしたことを示して、エラー報告をマイクロソフトに送信するかどうかを問い合わせるダイアログ ボックスを表示します。しかし、プロセスのメイン スレッドのスタックが壊れ、ハンドルされない例外のハンドラが実行時にクラッシュすると、そのプロセスがカーネルによって終了させられ、プログラムのウィンドウが瞬時に消えて、エラー報告ダイアログ ボックスが表示されません。
Windows Vista では、エラー処理をクラッシュ プロセスのコンテキストから取り出し、Windows エラー報告 (WER) という新しいサービスに移行しました。このサービスは、サービス ホスト プロセス内部の DLL (%Systemroot%\System32\Wersvc.dll) によって実装されます。アプリケーションがクラッシュすると、依然としてハンドルされない例外のハンドラが実行されますが、このハンドラはメッセージを WER サービスに送信します。その後、WER サービスから WER フォールト報告プロセス (%Systemroot%\System32\Werfault.exe) が起動され、エラー報告ダイアログ ボックスを表示します。スタックが壊れ、ハンドルされない例外のハンドラがクラッシュすると、ハンドラはスレッドのスタック (スクラッチ メモリ領域) をすべて使い果たすまで実行とクラッシュを繰り返し、使い果たした時点でカーネルが介入して、クラッシュ通知メッセージをサービスに送信します。
図 2 と図 3 で、これら 2 つのアプローチを対比できます。この図では、Windows XP および Windows Vista での、クラッシュするテスト プログラム (Accvio.exe) のプロセス関係とエラー報告プロセスを緑色で強調表示して示しています。Windows Vista の新しいエラー処理アーキテクチャでは、マイクロソフトがエラー報告を取得し、ソフトウェア開発者がアプリケーションを改善する機会を得ることなくプログラムが自動的に終了することはなくなりました。
図 2a Windows XP でのアプリケーション エラー処理
図 2a Windows XP でのアプリケーション エラー処理 (画像を縮小するには、ここをクリックします)
図 2a Windows XP でのアプリケーション エラー処理
図 2a Windows XP でのアプリケーション エラー処理 (画像を拡大するには、ここをクリックします)
図 2b
図 2b (画像を縮小するには、ここをクリックします)
図 2b
図 2b (画像を拡大するには、ここをクリックします)
図 3a Windows Vista でのアプリケーション エラー処理
図 3a Windows Vista でのアプリケーション エラー処理 (画像を縮小するには、ここをクリックします)
図 3a Windows Vista でのアプリケーション エラー処理
図 3a Windows Vista でのアプリケーション エラー処理 (画像を拡大するには、ここをクリックします)
図 3b
図 3b

ボリューム シャドウ コピー
Windows XP では、ディスク ボリュームの特定の時点のスナップショットを作成するボリューム シャドウ コピーというテクノロジが導入されました。バックアップ アプリケーションでは、このようなスナップショットを使用して一貫性のあるバックアップ イメージを作成できますが、それ以外の場合はスナップショットが表示されず、バックアップ プロセスの間のみ保持されます。
実際には、スナップショットはボリュームの完全なコピーではありません。正しくは、ライブ ボリューム データが、前回スナップショットが取得された以降に変更されたボリューム セクタのコピーでオーバーレイされる構成の、以前の時点からのボリュームのビューです。Volume Snapshot Provider ドライバ (%Systemroot\%System32\Drivers\Volsnap.sys) がボリュームを対象とした操作を監視し、セクタを変更する前に、セクタのバックアップ コピーを作成します。このとき、ボリュームのシステム ボリューム情報ディレクトリのスナップショットに関連付けられたファイルに元のデータを格納します。
Windows Server 2003 では、共有フォルダのシャドウ コピーにより、スナップショット管理がサーバーの管理者およびクライアント システムのユーザーに公開されます。この機能により、スナップショットの保存が有効になります。ユーザーは、エクスプローラでサーバーのファイル共有にあるフォルダやファイルの [プロパティ] ダイアログ ボックスを開き、[以前のバージョン] タブからこの保存したスナップショットにアクセスできます。
Windows Vista の以前のバージョン機能では、すべてのクライアント システムでこのサポートを利用でき、通常 1 日に 1 度、ボリュームのスナップショットが自動的に作成されます。このスナップショットには、共有フォルダのシャドウ コピーと同じインターフェイスを使用して、エクスプローラの [プロパティ] ダイアログ ボックスからアクセスできます。これにより、間違って変更または削除したファイルやディレクトリの以前のバージョンを表示、復元、またはコピーできます。技術的には新しいテクノロジではありませんが、ボリューム シャドウ コピーの Windows Vista の以前のバージョンの実装では、クライアント デスクトップ環境で使用するために、Windows Server 2003 の同等の機能が最適化されています。
Windows Vista では、ユーザーとシステムのデータ保護を一体化し、余分なバックアップ データの保存を避けるためにも、ボリューム スナップショットが利用されています。アプリケーションのインストールや構成への変更が不適切な動作や望ましくない動作につながる場合は、システムの復元 (Windows XP で Windows NT® 系列のオペレーティング システムに導入された機能) を使用して、復元ポイントが作成された時点に存在していたのと同じ状態にシステム ファイルやデータを復元できます。
Windows XP では、システムの復元により、ファイル システムのフィルタ ドライバ (ファイル レベルで変更を確認できるドライバの一種) を使用して、変更が行われた時点のシステム ファイルのバックアップ コピーを作成できます。Windows Vista では、システムの復元はボリュームのスナップショットを使用します。Windows Vista のシステムの復元ユーザー インターフェイスを使用して復元ポイントに戻ると、実際には、変更されたシステム ファイルの以前のバージョンが、復元ポイントに関連付けられたスナップショットからライブ ボリュームにコピーされています。

BitLocker
Windows Vista は、これまでにリリースされた Windows のバージョン中で最も安全な製品です。Windows Vista には Windows Defender スパイウェア対策エンジンが含まれているだけでなく、BitLocker™ フルボリューム暗号化、カーネル モード コードのコード署名、保護されているプロセス、Address Space Load Randomization、Windows サービス セキュリティとユーザー アカウント制御に対する強化など、さまざまなセキュリティや多層防御の機能が導入されています。
オペレーティング システムは自身がアクティブな間しかセキュリティ ポリシーを適用することができません。したがって、システムのセキュリティが物理的に侵害されるときや、オペレーティング システム外からデータがアクセスされるときに備えて、データを保護する別の手段が必要です。不正アクセスを防ぐためによく使用されるハードウェアベースのメカニズムには、BIOS パスワードと暗号化の 2 つのテクノロジがあります。こうしたテクノロジは、特に盗難や紛失の危険性が高いラップトップで使用されています。
Windows 2000 で導入された暗号化ファイル システム (EFS) は Windows Vista に引き継がれ、パフォーマンスの向上、ページング ファイルの暗号化サポート、スマート カードへのユーザー EFS キーの保存など、以前の実装を上回る多くの機能強化が行われています。しかし、レジストリ ハイブ ファイルなど、システムの重要な領域へのアクセスを保護するために EFS を使用することはできません。たとえば、グループ ポリシーで、ドメインに接続していない場合でもラップトップにログオンすることを許可している場合、ドメインの資格情報検証がレジストリにキャッシュされます。そのため、攻撃者はツールを使用してドメイン アカウントのパスワード ハッシュを取得でき、そのハッシュを使用して、パスワード クラッカーによりパスワードの取得を試みることができます。パスワードを入手した攻撃者は、アカウントと EFS ファイルにアクセスできることになります (スマート カードに EFS キーを格納していなかったことを前提としています)。
Windows Vista では、すべてのシステム ファイルやデータを含めてブート ボリューム (Windows ディレクトリのあるボリューム) 全体を容易に暗号化できるように、Windows BitLocker ドライブ暗号化というフルボリューム暗号化機能を導入しました。NTFS ファイル システム ドライバによって実装され、ファイル レベルで操作する EFS とは異なり、BitLocker は 図 4 に示すように、フルボリューム暗号化 (FVE) ドライバ (%Systemroot%\System32\Drivers\Fvevol.sys) を使用して、ボリューム レベルで暗号化を行います。
図 4 BitLocker FVE フィルタ ドライバ
図 4 BitLocker FVE フィルタ ドライバ (画像を縮小するには、ここをクリックします)
図 4 BitLocker FVE フィルタ ドライバ
図 4 BitLocker FVE フィルタ ドライバ (画像を拡大するには、ここをクリックします)
FVE はフィルタ ドライバなので、最初に BitLocker を使用するように構成されていれば、NTFS がボリュームに送信する I/O 要求をすべて自動的に監視し、そのボリュームに割り当てられたフルボリューム暗号化キー (FVEK) を使用して、書き込まれるブロックを暗号化し、読み取られるブロックの暗号化を解除します。既定では、128 ビット AES キーと 128 ビット ディフューザ キーを使用して、ボリュームが暗号化されます。I/O システムでは暗号化と復号化が NTFS の配下で行われるため、ボリュームは暗号化されていないかのように NTFS に表示され、NTFS は BitLocker が有効になっていることを認識する必要さえありません。ところが、Windows 外からボリュームのデータを読み取ろうとすると、ランダムなデータのように見えます。
FVEK はボリューム マスタ キー (VMK) で暗号化され、ボリュームの特殊なメタデータ領域に格納されます。BitLocker を構成するときに、システムのハードウェア機能に応じて、VMK を保護する方法に多くのオプションがあります。システムがトラステッド プラットフォーム モジュール (TPM) 仕様の v1.2 に準拠する TPM を備え、TPM が BIOS サポートに関連付けられていれば、TPM を使用して VMK を暗号化する (システムは TPM に格納されたキーと USB フラッシュ デバイスに格納されたキーを使用して VNK を暗号化します) か、TPM に格納されたキーとシステム ブート時に入力する PIN を使用してキーを暗号化できます。システムが TPM を備えていない場合、BitLocker では外部 USB フラッシュ デバイスに格納されたキーを使用して VMK を暗号化するオプションを提供します。どのような場合でも、暗号化されていない 1.5GB の NTFS システム ボリュームが必要になります。このボリュームには、ブート マネージャとブート構成データベース (BCD) が格納されます。
TPM を使用する利点は、BitLocker が TPM 機能を使用して、BitLocker が有効になった以降に BIOS やシステム ブート ファイルが変更される場合に、VMK の暗号化が解除されたり、ブート ボリュームのロックが解除されたりしないことを保証することです。システム ボリュームを初めて暗号化するとき、および上記のコンポーネントのいずれかで更新が行われるたびに、BitLocker はこうしたコンポーネントの SHA-1 ハッシュを計算し、各ハッシュ (計測値といいます) を、TPM デバイス ドライバ (%Systemroot%\System32\Drivers\Tpm.sys) の支援を受けて、TPM の異なるプラットフォーム構成レジスタ (PCR) に格納します。その後、TPM を使用して VMK をシールします。シールとは、TPM に格納された秘密キーを使用して、VMK と PCR に格納された値を、BitLocker から TPM に渡されるその他のデータと共に暗号化する操作のことです。BitLocker はシールした VMK と暗号化した FVEK をボリュームのメタデータ領域に格納します。
システムはブート時に独自のハッシュと PCR 読み込みコードを計算し、そのハッシュを TPM の最初の PCR に書き込みます。次に、BIOS のハッシュを計算し、その計測値を適切な PCR に格納します。続いて、BIOS がブート シーケンスの次のコンポーネント、つまりブート ボリュームのマスタ ブート レコード (MBR) のハッシュを計算します。このプロセスを、オペレーティング システム ローダーが計測されるまで続けます。それぞれ実行する後続のコードで、そのコードで読み込むコードの計測を受け持ち、計測値を TPM の適切なレジスタに格納します。最後に。ユーザーが起動するオペレーティング システムを選択するときに、ブート マネージャ (Bootmgr) がボリュームから暗号化された VMK を読み取り、シール解除を TPM に依頼します。オプションの PIN も含めてすべての計測値が VMK をシールした時点の値と同じである場合のみ、TPM は正しく VMK の暗号化を解除します。
この方式は、ブート シーケンスの各コンポーネントが次のコンポーネントを TPM に説明する、検証のチェーンと考えることができます。すべての説明が、TPM が受け取った元の説明と一致する場合のみ、TPM はその機密を開示します。そのため、ディスクが取り外され、別のシステムに設置された場合、システムが別のオペレーティング システムで起動された場合、またはブート ボリュームの暗号化されていないファイルが侵害された場合でも、BitLocker は暗号化されたデータを保護します。

コードの整合性検証
ルートキットなど、カーネル モードのデバイス ドライバとして実装されるマルウェアは、カーネルと同じ特権で実行されるため、識別や削除が最も困難です。このようなマルウェアは、事実上不可視になるように、カーネルやその他のドライバの動作を変更できます。Windows Vista のカーネル モード コード機能向けコードの整合性は、カーネル モードのコード署名 (KMCS) としても知られ、少数の証明機関 (CA) の 1 つによって検査を受けた開発者が発行およびデジタル署名したデバイス ドライバのみの読み込みを許可します。64 ビット向けの Windows Vista では、KMCS が既定で適用されます。
証明機関は自社のサービスを有償で提供し、ビジネスの整合性検証などの基本的なバックグラウンド チェックを実行するため、64 ビットの Windows Vista で実行される匿名のカーネル モード マルウェアを作成するのは困難です。さらに、検証プロセスを何とか擦り抜けたマルウェアでも、侵害されたシステムでそのマルウェアを発見したときに、作成者にたどりつく糸口を残す可能性があります。ドライバにユーザーのシステムをクラッシュするバグや、高品位のマルチメディア コンテンツのロックを解除する (後で簡単に説明します) バグが含まれている疑いがある場合、KMCS には、Windows Online Crash Analysis チームの連絡先を提供するような、補助的な使い方もあります。
KMCS は、Windows で 10 年間以上採用されてきた公開キー暗号化テクノロジを使用し、カーネル モード コードに信頼される証明機関の 1 つによって生成されたデジタル署名を含むことを要求します。発行者がドライバを Microsoft Windows Hardware Quality Laboratory (WHQL) に送り、そのドライバが信頼性テストに合格すると、マイクロソフトがそのコードに署名する証明機関の役割を果たします。ほとんどの発行者は WHQL を通じて署名を取得しますが、ドライバの WHQL テスト プログラムがない場合、発行者がドライバを WHQL テストに送ることを望まない場合、システム起動時の早期に読み込まれるブート開始ドライバの場合などは、発行者自身がコードに署名する必要があります。自身で署名を行うには、まず、マイクロソフトがカーネル モードのコード署名に対して信頼できると認める証明機関の 1 つからコード署名証明書を入手する必要があります。作成者は、その後、コードのハッシュをデジタルに計算し、秘密キーで暗号化することでそのハッシュに署名して、証明書と暗号化したハッシュをコードに含めます。
ドライバの読み込みを試みると、Windows はコードに含まれるハッシュの暗号化を、証明書に格納された公開キーを使用して解除してから、そのハッシュとコードに含まれるハッシュが一致するかどうかを検証します。同じ方法で証明書の信頼性をチェックしますが、この場合は、Windows に含まれる証明機関の公開キーを使用します。
また、Windows は関連する証明書チェーンを、Windows ブート ローダーとオペレーティング システム カーネルに埋め込まれたルート証明機関までチェックします。運用システムでは未署名の 64 ビット ドライバの読み込みが試みられることは一切ありません。WQHL テストに合格していることを確認する署名が含まれないドライバの読み込みが指示されたときに警告ダイアログ ボックスを表示するプラグ アンド プレイ マネージャとは異なり、64 ビットの Windows Vista は 図 5 に示すように、イベントをコードの整合性アプリケーション イベント ログに自動的に書き込み、未署名のドライバの読み込みを常にブロックします。32 ビット Windows Vista でもドライバの署名はチェックされますが、未署名のドライバであっても読み込むことができます。未署名のドライバの読み込みをブロックしてしまうと、Windows XP に読み込まれていたドライバを必要とするアップグレードされた Windows XP システムが機能しなくなります。未署名のドライバを読み込めば、Windows XP のドライバしか存在しないハードウェアのサポートも可能になります。ただし、32 ビット Windows Vista も未署名のドライバを読み込むときに、イベントをコードの整合性イベント ログに書き込みます。
図 5 未署名のドライバの読み込み試行イベント
図 5 未署名のドライバの読み込み試行イベント (画像を縮小するには、ここをクリックします)
図 5 未署名のドライバの読み込み試行イベント
図 5 未署名のドライバの読み込み試行イベント (画像を拡大するには、ここをクリックします)
一般的に、コード署名はコードが厳密なテストに合格した公式リリースであることを示すために使用されるため、発行者は通常テスト コードに署名することは望みません。そのため、Windows Vista には Bcdedit ツール (TechNet Magazine の 2007 年 3 月号の私の記事を参照) を使用して有効または無効にできるテスト署名モードがあります。このモードでは、社内の証明機関が生成したテスト証明書で署名されたカーネル モード ドライバが読み込まれます。このモードは、プログラマがコードの開発中に使用することを目的に設計されました。Windows がこのモードで実行されているときは、図 6 のようなマーカーがデスクトップに表示されます。
図 6 Windows Vista テスト署名モード
図 6 Windows Vista テスト署名モード

保護されているプロセス
Advanced Access Content System (AACS) でライセンスが許可された HD-DVD、BluRay などのフォーマットの次世代マルチメディア コンテンツは、今後数年でさらに一般的になります。Windows Vista にはこのようなコンテンツを再生するために ACCS 標準によって要求される多くのテクノロジが含まれています。このようなテクノロジをまとめて Protected Media Path (PMP) と呼びます。PMP には Protected User-Mode Audio (PUMA) と Protected Video Path (PVP) があります。この 2 つを組み合わせてオーディオとビデオのドライバやメディア プレーヤー アプリケーション向けのメカニズムを提供し、未承認のソフトウェアやハードウェアが高品位形式のコンテンツをキャプチャするのを防ぎます。
PUMA と PVP はオーディオとビデオのプレーヤー、デバイス ドライバ、およびハードウェアに固有のインターフェイスとサポートを定義しますが、PMP は Windows Vista で導入された、保護されているプロセスという一般的なカーネル メカニズムにも依存します。保護されているプロセスは、標準の Windows プロセス構成に基づきます。この構成は、実行中の実行可能イメージ、DLL、セキュリティ コンテキスト (プロセスを実行するアカウントとそのセキュリティ権限)、およびプロセス内のコードを実行するスレッドをカプセル化します。ただし、特定の種類のアクセスは防ぎます。
標準プロセスは、プロセスの所有者と "プログラムのデバッグ" 特権を持つ管理者アカウントにフルアクセスを許可するアクセス制御モデルを実装します。フルアクセスが許可されたユーザーは、プロセスにマップされたコードやデータを含めて、プロセスのアドレス空間を表示および変更できます。また、プロセスにスレッドを挿入することもできます。PMP では、高品位コンテンツおよびそのコンテンツを再生するプロセスに格納された Digital Rights Management (DRM) キーに未承認のコードからアクセスできないため、この種のアクセスは PMP の要件とは一貫性がありません。
保護されているプロセスでは、情報インターフェイスやプロセス管理インターフェイスの限定されたセットにアクセスが制限されます。このようなインターフェイスには、プロセスのイメージ名を照会するインターフェイスやプロセスを終了または中断するインターフェイスなどがあります。ただし、カーネルは保護されているプロセスの診断情報を作成します。この診断情報は、システム上のすべてのプロセスに関するデータを返す、汎用のプロセス クエリ機能を使用して入手できるため、プロセスに直接アクセスする必要はありません。メディアを危険にさらす可能性があるアクセスは、他の保護されているプロセスからのみ許可されます。
さらに、内部から危険にさらされることを防ぐために、実行可能イメージや DLL を含めて、保護されているプロセスに読み込まれるすべての実行可能コードには、保護された環境 (PE) フラグで Microsoft (WHQL) によって署名されているか、オーディオ コーデックの場合は、マイクロソフトから入手した DRM 署名の証明書で開発者によって署名されている必要があります。カーネル モード コードは、保護されているプロセスを含め、すべてのプロセスにフルアクセス許可を得られ、32 ビット Windows は未署名のカーネル モード コードを読み込むことができるため、カーネルでは保護されているプロセス用の API が用意されています。この API では、カーネル モード環境の "クリーン性" を照会し、その結果を使用して、未署名のコードが読み込まれていない場合のみプレミアム コンテンツのロックを解除します。
保護されているプロセスの識別
保護されているプロセスを具体的に識別できる API はありません。ただし、限定された情報しか入手できないことと、管理アカウントでもデバッグできないことを基に間接的に識別することができます。Content Scramble System (CSS) エンコードされた DVD の再生に使用するオーディオ デバイス グラフ アイソレーション プロセス (%Systemroot%\System32\Audiodg.exe) は、タスク マネージャのウィンドウで保護されているプロセスとして識別できます。これは、このプロセスが管理権限で実行されている場合でも、タスク マネージャがコマンド ライン、仮想化、データ実行防止の状態を取得できていないことからわかります。
audiodg の保護されているプロセスを表示するタスク マネージャ
audiodg の保護されているプロセスを表示するタスク マネージャ (画像を縮小するには、ここをクリックします)
audiodg の保護されているプロセスを表示するタスク マネージャ
audiodg の保護されているプロセスを表示するタスク マネージャ (画像を拡大するには、ここをクリックします)

Address Space Load Randomization
データ実行防止や高度なコンパイラ エラー チェックのような手段があるにもかかわらず、マルウェアの作成者は引き続きバッファ オーバーフローの脆弱性を探し、ネットワークに直接インターフェイスを持つ Internet Explorer® のようなプロセス、Windows サービス、およびサードパーティ アプリケーションに影響を与えて、システムへの足がかりを入手できます。ただし、プロセスへの侵入を成し遂げた後、ユーザー データを読み取ったり、ユーザー構成設定やシステム構成設定を変更して永久に存在したりという最終的な目標を実現するにはマルウェアは Windows API を使用する必要があります。
DLL が公開する API エントリ ポイントとアプリケーションとの接続は、通常、オペレーティング システム ローダーによって処理されます。ただし、この種のマルウェアに感染しても、ローダーのサービスの利点は得られません。これにより、特定の Windows リリースでは、システムの実行可能イメージと DLL が常に同じ場所に読み込まれ、マルウェアは API が固定アドレスに存在すると想定できるため生じていた以前のバージョンの Windows でのマルウェアの問題が引き起こされません。
Windows Vista Address Space Load Randomization (ASLR) 機能では、システムが起動されるたびにシステム DLL と実行可能ファイルを異なる場所に読み込むことによって、マルウェアが API の配置場所を把握できないようにします。メモリ マネージャはブート プロセスの早い段階で、ユーザー モードのアドレス空間の先頭にある 16 MB の領域の 64 KB 単位に整列された 256 個のアドレスの 1 つから DLL イメージの読み込みバイアスをランダムに選択します。イメージ ヘッダーに新しい動的再配置フラグを含む DLL がプロセスに読み込まれるとき、メモリ マネージャはその DLL をメモリに、イメージの読み込みバイアス アドレスから始めて、下位アドレス方向にパックします。
フラグ セットを含む実行可能ファイルも同様に扱われ、イメージ ヘッダーに格納された 16 MB のベース読み込みアドレス内の 64 KB 単位に整列されたランダムな位置に読み込まれます。さらに、特定の DLL または実行可能ファイルがそれを使用するすべてのプロセスによってアンロードされた後、再度読み込まれる場合、メモリ マネージャは読み込む場所をランダムに再選択します。図 7 に、32 ビット Windows Vista システムのアドレス空間レイアウトの例を示します。このレイアウトには、ASLR がイメージの読み込みバイアスと実行可能ファイルの読み込みアドレスを選択する元になる領域を含みます。
図 7 実行可能ファイルの DLL の読み込みアドレスに関する ASLR の影響
図 7 実行可能ファイルの DLL の読み込みアドレスに関する ASLR の影響 (画像を縮小するには、ここをクリックします)
図 7 実行可能ファイルの DLL の読み込みアドレスに関する ASLR の影響
図 7 実行可能ファイルの DLL の読み込みアドレスに関する ASLR の影響 (画像を拡大するには、ここをクリックします)
動的再配置フラグは Windows Vista のすべての DLL と実行可能ファイルに含まれていますが、このフラグを含むイメージのみが再配置されます。これは、レガシ イメージを移動すると、開発者がイメージの読み込み場所に関して行っている内部的な想定に反する可能性があるためです。Visual Studio® 2005 SP1 では、このフラグの設定に関するサポートが追加されるため、サードパーティの開発者は ASLR を完全に利用できます。
DLL の読み込みアドレスとして 256 個の場所の中から 1 つをランダムに選択することで、マルウェアが API の正しい場所の推測が不可能になるわけではありませんが、ネットワーク ワームが伝播する速度を大きく制限し、システムに感染する機会を得ただけのマルウェアが確実に機能するのを防ぎます。また、ASLR の再配置方針は、アドレス空間が以前のバージョンの Windows よりも緊密にパックされるという二次的なメリットもあります。連続的なメモリ割り当ての大量の空きメモリ領域が作成され、アドレス空間レイアウトを監視するためにメモリ マネージャが割り当てるページ テーブル数が削減され、変換ルックアサイド バッファ (TLB) の不足が最小限に抑えられます。

サービスのセキュリティ強化
Windows サービスは、マルウェアの格好の攻撃対象になります。多くの Windows サービスは自身の機能にネットワークからアクセスできるようにしているため、遠隔地からシステムの攻撃に利用できるアクセス手段が公開される可能性があります。さらに、ほとんどのサービスが標準ユーザー アカウントよりも高い特権で実行されるため、マルウェアによって侵害できる場合は、ローカル システムでの特権を昇格する機会が与えられます。このため、Windows の進化が始まり、Windows XP SP2 では、サービスに割り当てられる特権とアクセスはサービスがその役割を果たすのに最低限必要なものに削減するように変更が行われました。たとえば、Windows XP SP2 にはローカル サービス アカウントとネットワーク サービス アカウントが導入され、以前サービスの実行に常に使用されていたローカル システム アカウントで利用できた特権のサブセットしか含まれていません。これにより、攻撃者がサービスを悪用したときに得られるアクセス許可が最小限に抑えられます。
ASLR の動作の確認
ASLR の効果は、Sysinternals の Process Explorer のようなツールを使用して、異なる 2 つのブート セッションのプロセスの DLL 読み込みアドレスを比較することによって、簡単に確認できます。次の 2 つのスクリーンショットは、異なる 2 つのセッションから取得したものであり、Ntdll.dll がエクスプローラに読み込まれる際、最初はアドレス 0x77A30000 に、次はアドレス 0x77750000 に読み込まれています。
ntdll.dll の異なるベース アドレス
ntdll.dll の異なるベース アドレス (画像を縮小するには、ここをクリックします)
ntdll.dll の異なるベース アドレス
ntdll.dll の異なるベース アドレス (画像を拡大するには、ここをクリックします)
ntdll.dll の異なるベース アドレス
ntdll.dll の異なるベース アドレス (画像を縮小するには、ここをクリックします)
ntdll.dll の異なるベース アドレス
ntdll.dll の異なるベース アドレス (画像を拡大するには、ここをクリックします)

前回の記事で、サービスをユーザー アカウントから分離し、独自のセッションで実行する方法を説明しましたが、Windows Vista でもほとんどのサービスに割り当てるファイル、レジストリ キー、およびファイアウォール ポートの特権やアクセス許可をさらに削減することによって、最小特権の原則の使用を拡張しています。Windows Vista では、各サービスに一意なサービス セキュリティ識別子 (SID) という新しいグループ アカウントを定義します。サービスは、そのサービスの SID のみがリソースにアクセスできるように権限を設定できます。その結果、サービスが侵害されても、同じユーザー アカウントで実行されている他のサービスにはアクセスできません。サービスの SID は、図 8 に示すように、sc showsid コマンドにサービス名を付けて使用することで確認できます。
図 8 サービス SID の表示
図 8 サービス SID の表示 (画像を縮小するには、ここをクリックします)
図 8 サービス SID の表示
図 8 サービス SID の表示 (画像を拡大するには、ここをクリックします)
サービス SID では、特定のサービスが所有するリソースへのアクセスは保護されますが、既定では、サービスはそのサービスを実行するユーザー アカウントがアクセスできるすべてのオブジェクトに依然としてアクセス許可を所持します。たとえば、ローカル サービス アカウントで実行されるサービスは、ローカル サービスで実行される他のサービスが別のプロセス (ここでは、サービス SID を参照するオブジェクトが保護されます) に作成したリソースにはアクセスできません。ただし、ローカル サービス (および、サービス グループなど、ローカル サービスが所属する任意のグループ) がアクセス許可を持つすべてのオブジェクトの読み取りと書き込みは可能なままです。
そのため、Windows Vista では書き込みが制限されるサービスという新しい制限付きのサービスの種類が導入され、サービスからの書き込みアクセスを、サービス SID、Everyone グループ、およびログオン セッションに割り当てられた SID にアクセスできるオブジェクトに限定して許可します。これを実現するため、Windows 2000 で導入された制限付き SID を使用します。オブジェクトを開いたプロセスが書き込みの制限されたサービスのときは、アクセス チェックのアルゴリズムが変更され、制限付き形式でも制限なし形式でもプロセスに割り当てられていない SID を使用して、そのプロセスにオブジェクトへの書き込みアクセスを許可することはできません。次のコマンドを使用してサービスが制限されているかどうかを確認できます。
sc qsidtype [service]
他にも、サービスが作成するオブジェクトに、同じアカウントで実行される他のアカウントからのアクセス防止を容易にする変更が行われています。以前のバージョンの Windows では、オブジェクトの作成者はオブジェクトの所有者でもありました。所有者は、所有するオブジェクトへのフルアクセスが許可され、オブジェクトのアクセス許可の読み取りと変更が可能です。Windows Vista では、新しく Owner Rights SID が導入され、オブジェクトのアクセス許可にこの SID が存在すると、所有者のアクセス許可を自身が所有するオブジェクトに制限でき、さらにアクセス許可の設定と照会が削除されます。
Windows Vista では、サービスのセキュリティ モデルがさらに強化され、サービスの開発者は、サービスをシステムに登録するときに、サービスの操作に必要なセキュリティ特権を正確に制限できます。たとえば、サービスが監査イベントの生成を必要とする場合は、監査特権を指定できます。
サービス コントロール マネージャは 1 つ以上の Windows サービスをホストするプロセスを開始するときに、そのプロセス用にプロセス内のサービスが必要な特権のみを含むセキュリティ トークン (プロセス ユーザー アカウント、グループ メンバシップ、およびセキュリティ特権を一覧するカーネル オブジェクト) を作成します。実行するアカウントで利用できない特権をサービスが指定すると、そのサービスは開始されません。たとえば、ローカル サービス アカウント プロセスで実行されるサービスの中にプログラムのデバッグ特権を必要とするサービスが存在しない場合は、サービス コントロール マネージャはそのプロセスのセキュリティ トークンからその特権を取り除きます。したがって、サービス プロセスが侵害されても、悪意のあるコードはそのプロセスで実行されるサービスが明示的に要求しなかった特権を使用することはできません。sc qprivs コマンドは、サービスが要求した特権を報告します。

まとめ
今回は、Windows Vista カーネルの変更点を紹介してきた 3 部構成の記事のまとめです。アプリケーション開発者向けの新しいワーカー スレッド プール、共有のリーダー ロックとライタ ロックのような新しい同期メカニズム、サービス スレッド タグ、NTFS のディスク チェックとボリュームのサイズ変更のオンライン サポート、Advanced Local Procedure Call (ALPC) という新しいカーネル IPC メカニズムなど、今回のシリーズで説明しなかった機能と機能強化があります。こうした機能やその他の機能の詳細については、2007 年末に発行を予定している『Windows Internals』の次回のエディションを参照してください。
書き込みが制限されるサービスの表示
Windows Vista では、1 つのサービス ホスト プロセスのみが制限付きのサービスをホストします。Process Explorer のようなプロセス表示ツールを使用して、このプロセスを次のコマンド ラインを備えたプロセスとして識別できます。
svchost -k LocalServiceNoNetwork
このプロセス内で実行するように構成されたサービスには、ベース フィルタ エンジン、診断ポリシー サービス、Windows ファイアウォール、パフォーマンス ログと警告、および Windows Media® Center Service Starter があります。
この画面にはベース フィルタ エンジンのサービス SID が NT SERVICE\BFE という形式で、Restricted フラグ付きで 1 回、フラグなしで 1 回一覧されています。したがって、このプロセスは、そのアカウントがアクセスできるリソースにアクセスできます。ただし、ローカル サービス アカウントが通常アクセスできる他のオブジェクトにアクセスできるとは限りません。たとえば、NT AUTHORITY\SERVICE アカウントは、プロセス トークンに制限フラグ付きで表示されていないため、このプロセスは、そのアカウントに書き込みアクセスが許可されているオブジェクトを変更できません。これは、そのアカウントがトークン内で制限フラグの付いた他のアカウントでも同じです。
プロパティ ダイアログ ボックスの一番下に一覧されている特権は、ローカル サービス アカウントが使用できる特権のサブセットなので、このプロセスで実行されるサービスも特権が制限されます。
サービスの SID フラグ
サービスの SID フラグ (画像を縮小するには、ここをクリックします)
サービスの SID フラグ
サービスの SID フラグ (画像を拡大するには、ここをクリックします)

Mark Russinovich は、Microsoft の Platform and Services Division に所属するテクニカル フェローです。また、『Microsoft Windows Internals』 (Microsoft Press、2004) の共同執筆者であり、Microsoft Tech•Ed や PDC などの、IT カンファレンスや開発者向けカンファレンスで頻繁に講演を行っています。彼は、共同で設立した Winternals Software 社の Microsoft による買収に伴い、Microsoft に入社しましたが、Sysinternals の設立者でもあり、同社では Process Explorer、Filemon、Regmon など、多くの人気のあるユーティリティを発表しています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Windows の管理: 障害回復: Active Directory ユーザーとグループ
Windows の管理 Gil Kirkpatrick

障害回復: Active Directory ユーザーとグループ
概要:
  • レプリケーションとオブジェクト リンクのしくみ
  • NTDSUTIL を使用してバックアップと復元を行う
  • 権限のある復元と権限のない復元

Active Directory は、Windows ネットワークで最も重要なサービスの 1 つです。ダウンタイムや生産性の低下を防ぐには、Active Directory に関する問題の発生に備えて、あらかじめ有効な障害回復計画を準備しておくことがきわめて重要です。
これは今さら言うまでもありません。しかし、データの誤った削除という最もよくある障害シナリオすら想定していない Active Directory® 管理者が非常に多いのです。
オブジェクトの誤った削除は、サービス障害の最も一般的な原因の 1 つです。私はセミナーやカンファレンスの参加者に、データの誤った削除による Active Directory の障害を経験したことがあるかどうかをよくたずねてみますが、いつもほとんど全員が手を挙げるほどです。
データ回復はなぜこれほどまでに複雑なのでしょうか。それを理解するためには、Active Directory におけるオブジェクトの保存、レプリケーション、および削除の方法を理解し、権限のある復元と権限のない復元のしくみを知る必要があります。

オブジェクトを保存する
Active Directory は、X.500/LDAP データ モデルを実装した特殊なオブジェクト データベースです。データ ストアは "ディレクトリ情報ツリー (DIT)" と呼ばれ、索引順次アクセス方式 (ISAM) のデータベース エンジンである、Extensible Storage Engine (ESE) を利用して動作します。この DIT は、概念的には 2 つのテーブルに格納されます。1 つは実際の Active Directory オブジェクトと属性を含むデータ テーブル、もう 1 つはオブジェクトのリレーションシップ情報を含むリンク テーブルです。
データ テーブルの行には Active Directory オブジェクトが 1 つずつ、列には属性が 1 つずつ格納されます。データ テーブルには、ドメイン コントローラ (DC) に保存されたすべてのレプリカのエントリが含まれます。通常の DC の場合、ドメインの NC (名前付けコンテキスト)、構成 NC、およびスキーマ NC のエントリが含まれます。グローバル カタログの場合、フォレスト内の各オブジェクトのエントリが含まれます。
Active Directory は識別名タグ (DNT) という 32 ビットの整数を使用して、データ テーブルの各行を識別します。DNT はオブジェクトの内部参照に使用されるので、識別名 (DN)、objectGUID (16 バイトのバイナリ構造) などの他の識別子と比べて、かなり小さいサイズになっています。objectGUID と異なる点は、DNT がローカル識別子であり、DC ごとに異なるという点です。

Active Directory のオブジェクトのリンク方法
Active Directory では、DIT 内のオブジェクト間に、親子関係 (コンテナ関係) または参照関係 (リンク関係) の 2 種類のリレーションシップが存在します。親子関係を実装する場合は、データ テーブルに "親識別名タグ (PDNT)" という列が追加されます。この列には、常にオブジェクトの親の DNT が格納されます。
Active Directory の各属性は、Active Directory スキーマ コンテナ内の attributeSchema オブジェクトによって定義されます。Active Directory の属性の一部は、リンク属性として定義されています。attributeSchema オブジェクトの linkID 属性にゼロ以外の偶数値が設定されている場合、その属性はリンク属性です。リンク属性は、ディレクトリ内のオブジェクト間にリレーションシップを作成する属性であり、単一または複数の値を持ちます。たとえば、グループ オブジェクトの member (メンバ) 属性は複数の値を持つリンク属性であり、グループ オブジェクトとそのメンバ オブジェクト間にリンクを作成します。
メンバの DN がグループの member 属性に含まれているように思われますが (たとえば [Active Directory ユーザーとコンピュータ] スナップインで表示した場合)、実際は違います。メンバ オブジェクトの DN をグループの member 属性に追加すると、このオブジェクトの DN ではなく DNT が保存されます。DNT はオブジェクトの名前を変更しても変わりません。このため、ユーザー オブジェクトの名前変更が可能であり、個々の member 属性の DN は、システム内のすべてのグループを調べなくても更新されます。Active Directory では、このようにして DIT 内の参照の整合性が保持されています。図 1 に、データ テーブルとリンク テーブルの関係を簡単に示します。この 2 つのテーブルには、Senior Engineers (シニア エンジニア) グループのメンバである Molly Clark、Alexander Tumanov、および Makoto Yamagishi を表す 3 つのユーザー オブジェクトが含まれています。
Figure 1 データ テーブルとリンク テーブルの関係 (Close Figure 1)

データ テーブル |  |  |
DNT | PDNT | オブジェクト クラス | Cn
14529 | 14401 | organizationalUnit | Engineers
14530 | 14529 | Group | Senior Engineers
14531 | 14529 | User | Molly Clark
14532 | 14529 | User | Alexander Tumanov
14533 | 14529 | User | Makoto Yamagishi
リンク テーブル |  |  |
属性 | DNT | 前方リンク |
Member | 14530 | 14531 |
Member | 14530 | 14532 |
Member | 14530 | 14533 |
これらのリンクは、前方リンクと呼ばれます。同様に、Active Directory には後方リンク属性もあります。後方リンクは、リンク先オブジェクト (参照先オブジェクト) から参照元オブジェクト (前方リンクを持つオブジェクト) への参照を提供します。たとえば、ユーザーやグループの memberOf 属性は後方リンク属性です。後方リンク属性を持つ attributeSchema オブジェクトの linkID 値は、対応する前方リンク属性の偶数の linkID 値に 1 を加えた値になります。たとえば、Windows Server® 2003 R2 のスキーマに含まれる member 属性の linkID 値は 2 です。後方リンクとして働く memberOf 属性の linkID 値は 3 です。詳細については、図 2 を参照してください。図 2 は、Windows Server 2003 R2 のスキーマで定義された既定のリンク属性の一覧です。
Figure 2 Windows Server 2003 R2 スキーマのリンク属性 (Close Figure 2)

前方リンク属性 | linkID | 後方リンク属性 | リンク先
member | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
後方リンク属性は常に複数の値を持ち、Active Directory で自動的に管理されます。ユーザーが後方リンク属性を直接変更することはできません。ユーザーまたはグループの memberOf 属性は、Microsoft 管理コンソール (MMC) の Active Directory ユーザーとコンピュータ スナップインを使用して変更できそうに見えます。しかし、実際にはスナップインでは対応するグループの member 属性が変更されるだけで、memberOf 属性は Active Directory によって更新されます。ユーザーをグループに追加するときユーザー オブジェクトのアクセス許可が必要ないのは、実際にはグループ オブジェクトの member 属性を変更しているだけだからです。各 DC は後方リンク属性をローカルに管理するので、後方リンクの変更内容はレプリケートされません。グループの member 属性など、前方リンク属性の変更内容だけがレプリケートされます。
通常の DC の場合、データ テーブルには、ドメイン オブジェクトのエントリの他に、構成コンテナおよびスキーマ コンテナのオブジェクトが含まれます。一部のグループの種類には、別のドメインにあるオブジェクトへの参照も含めることができます。Active Directory は、データ テーブル内に存在しないオブジェクトの DNT をどのようにして保存するのでしょうか。その答えは、インフラストラクチャ マスタの FSMO (フレキシブル シングル マスタ オペレーション) の所有者と、ファントム オブジェクトにあります。

ファントム オブジェクト
あるドメインのメンバを別のドメインのグループに追加すると、データ テーブル内にファントムと呼ばれる特殊なオブジェクトが自動的に作成されます。ファントム オブジェクトには、新しいメンバの objectGUID、objectSid、および DN が含まれます。これにより、DNT をグループの member 属性として保存できるようになります。ドメイン コントローラがグローバル カタログである場合は、データ テーブルにフォレスト内の各オブジェクトのエントリが作成されているので、ファントムを作成する必要はありません。
インフラストラクチャ マスタの FSMO の役割を持つ DC は、定期的にデータ テーブルのエントリとグローバル カタログを比較します。そして、オブジェクトの移動、名前変更、削除などを検出すると、データ テーブル内のファントムを更新し、変更内容をドメイン内のその他の DC にレプリケートします。インフラストラクチャ マスタは、参照カウントに基づいて、ドメイン内の前方リンク属性によって参照されていないファントムを削除することもできます。
DC は、ファントムを利用して、フォレスト内の他のドメインのオブジェクトへの参照を管理できますが、前方リンク属性も、フォレストの外、たとえば信頼されたドメイン内のオブジェクトを参照できます。この場合、Active Directory により、ドメイン NC の CN=ForeignSecurityPrincipals コンテナ内に、外部セキュリティ プリンシンパル (FSP) というオブジェクトが作成されます。FSP には、外部オブジェクトのセキュリティ識別子 (SID) と、外部ドメイン内のオブジェクトを識別するその他の属性が含まれています。ただし、FSP を最新の状態に保つための処理は行われません。データ回復の目的には、FSP をその他の Active Directory オブジェクトと同様に扱います。

オブジェクトを削除する
ここでは主に、ユーザーとそのグループのメンバシップを復元する方法について説明しますが、同じ方法で、リンクされたその他の属性を回復することもできます。
Active Directory でオブジェクトを削除しても、そのオブジェクトが DIT から物理的に削除されるわけではありません。Active Directory は、isDeleted 属性を true に設定して、"オブジェクトが削除された" というマークを付けるだけです。マークが付けられたオブジェクトは、通常のディレクトリ操作では非表示になります。Active Directory は、スキーマに従って、保存すると指定されていないすべての属性を削除し、オブジェクトの相対識別名 (RDN) を <old RDN>\0aDEL:<objectGUID> に変更します。続いて、このオブジェクトを NC の CN=Deleted Objects (削除済みオブジェクト) コンテナに移動します。ただし、構成 NC 内には、削除済みオブジェクト コンテナに移動されないオブジェクト クラスもあります。オブジェクトを削除すると、このオブジェクトから他のオブジェクトへの前方リンクがすべて削除されるので、リンク テーブル内の参照カウントが減ります。削除済みオブジェクトへの前方リンクを含むオブジェクトがある場合は、そのリンクも削除されます。
こうして得られたオブジェクトは、廃棄 (TOMBSTONE) オブジェクトと呼ばれます。Active Directory は、廃棄オブジェクトを他の DC にレプリケートし、同様の変更が行われます。ただし、削除済みオブジェクトを参照する前方リンクへの変更はレプリケートされません。これは、DC ごとにローカルで同様の変更が行われるからです。詳細は後述しますが、このことはグループ メンバシップの回復に影響します。
Active Directory は、CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> オブジェクトの tombstoneLifetime 属性に従って、廃棄オブジェクトを DIT に保持します。各 DC でガベージ コレクションが実行されると、設定された有効期間を過ぎた廃棄オブジェクトは削除されます。既定では、廃棄オブジェクトの有効期間は 60 日 (Windows® 2000、Windows Server 2003、および Windows Server 2003 R2 の場合) または 180 日 (Windows Server 2003 SP1 の場合) です。
廃棄オブジェクトの有効期間と復元処理には、重要な関連性があります。廃棄オブジェクトの有効期間を過ぎた古いバックアップからデータを復元することはできません。ドメインから削除され、ガベージ コレクションが完了したオブジェクトには、廃棄オブジェクトがありません。このため、削除操作を実行しても、復元された DC へのレプリケーションは行われません。削除済みオブジェクトは、復元された DC 上に残留オブジェクトとして残り、この復元された DC は、ドメイン内の他の DC とは、厳密には同じ状態にならなくなります。

オブジェクトをレプリケートする
オブジェクトの追加、属性の変更など、ドメイン コントローラで何らかの更新を行うと、この更新操作に更新シーケンス番号 (USN) と呼ばれる 64 ビットの一意の数値が割り当てられます。Active Directory は、更新対象のオブジェクトや属性に USN のタグを付け、これらのレプリケーションが必要かどうかの判断材料にします。
Active Directory は属性単位でオブジェクトのレプリケーションを行います。つまり、あるオブジェクトのある属性を変更した場合、そのオブジェクト全体ではなく、変更された属性だけがレプリケートされます。この処理を実現するため、Active Directory は、レプリケーション メタデータを使用して、各属性の変更を追跡しています。属性のレプリケーション メタデータには、次のものがあります。
  • ローカル USN。ローカル DC に対する変更操作を識別します。
  • 変更のソース DC の invocationID。厳密には、この DC の対応する nTDSSettings オブジェクトの invocationID 属性です。DC における DIT の特定の生成処理を識別します。
  • 元の操作の USN。ソース DC 上にあります。
  • タイム スタンプ。ソース DC に変更が加えられた時のシステム時刻です。
  • 32 ビットの連続したバージョン番号。この番号は、値が変更されるたびに大きくなります。
変更のレプリケート先 DC は、ソース DC に変更情報をリクエストするとき、前回正常にレプリケートされた変更の USN と最新ベクタを送信します。最新ベクタは、レプリケートされる NC のレプリカを格納するすべての DC から受信した USN のうち、最大の値を示します。ソース DC は、この情報を基に、レプリケート先 DC にまだ適用されていない更新情報だけを送信します。
レプリケート先 DC は、受信した属性の更新情報を処理する際に、各属性のバージョン番号を確認します。受信した属性のバージョン番号が現在のバージョン番号より大きい場合、DC は受信した値を保存します。受信した属性のバージョン番号が現在のバージョン番号と同じである場合、DC はタイムスタンプを比較し、タイムスタンプが新しい方の属性を使用します。タイムスタンプも一致している場合は、invocationID が大きい方の値を選択します。このようにして、すべての DC のすべての属性の値が、最終的に同じになります。

リンクされた値のレプリケーション
Windows 2000 の Active Directory では、属性に 1 つしか値がない場合も、複数の値がある場合も、レプリケーションの方法は同じでした。しかし、member 属性の複数の値が複数の DC 上で頻繁に変更されるような、大規模で動的なグループ オブジェクトでは、この方法はうまく機能しませんでした。たとえば、管理者 1 が DC 1 を使用して、あるグループにユーザーを追加したとします。その後レプリケーション待ち時間内に、管理者 2 が DC 2 を使用して同じグループに別のユーザーを追加した場合、最初の変更は完全に失われ、後からの変更だけが適用されます。この問題は、Windows Server 2003 でリンクされた値のレプリケーション (LVR) という処理の導入により解決されました。
Windows Server 2003 のフォレストの機能レベル、または Windows Server 2003 中間の機能レベルでは、Active Directory は、複数の値を持つ前方リンク属性の個々の値を個別にレプリケートし、各値に固有のレプリケーション メタデータを使用します。これにより、Windows 2000 での問題が事実上解決され、複数の DC 上でほぼ同時にグループ メンバシップが更新されてもデータが失われる心配はなくなりました。
ただし、1 点注意が必要です。フォレストの機能レベルを上げても、複数の値を持つ既存のリンク属性に、新しいレプリケーション メタデータが自動的に適用されるわけではありません。フォレストの機能レベルを上げた後で追加した値にだけ、新しいメタデータが適用されます。これがグループ メンバシップを回復する際にどれほど重要であるかについては、この後すぐにご説明します。

バックアップを作成する
Windows には、DC のシステム状態のバックアップを実行できる非常に基本的な NTBACKUP ユーティリティが付属しています。DC のシステム状態には、レジストリ、SYSVOL、Active Directory DIT ファイル、および重要なシステム ファイルが含まれます。サードパーティのほとんどのバックアップ ユーティリティには、DC のシステム状態のバックアップおよび復元機能があります。
ディスク ファイルにシステム状態のバックアップを取るには、次のコマンドを使用します。
NTBACKUP backup systemstate /F “<filename>”
<filename> の位置には、作成するバックアップ ファイルの名前を入力します。ファイル拡張子 .bkf を付けてください。

権限のない復元を実行する
削除された Active Directory オブジェクトは、バックアップから 2 段階の処理で復元できます。まず、DC をディレクトリ サービス復元モード (DSRM) で再起動した後、Windows の NTBACKUP ユーティリティか、同等のサードパーティ製品を使用して、システム状態のバックアップから Active Directory DIT 全体を復元します。この処理により、DIT 全体が上書きされます。
DC を DSRM で起動する方法は 2 とおりあります。DC のシステム コンソールを使用できる場合は、いったん DC をシャットダウンし、再起動する際に、Windows のブート メニューのプロンプトが表示されたら F8 キーを押します。メニューから [ディレクトリ サービス復元モード] を選択し、DSRM のパスワードを入力します。
リモート管理サーバーでは、Windows のブート メニューを表示できません。この場合は、[マイ コンピュータ] を右クリックし、メニューの [プロパティ] をクリックします。続いて、[詳細設定] タブをクリックし、[起動と回復] の [設定] ボタンをクリックします。[起動システム] の [編集] ボタンをクリックして boot.ini ファイルを開き、図 3 に示すように、行の最後に「/SAFEBOOT:DSREPAIR」スイッチを追加して保存します。boot.ini のスイッチの詳細については、microsoft.com/technet/ sysinternals/information/bootini.mspx を参照してください。
図 3 DSRM の起動オプションを設定する
図 3 DSRM の起動オプションを設定する (画像を縮小するには、ここをクリックします)
図 3 DSRM の起動オプションを設定する
図 3 DSRM の起動オプションを設定する (画像を拡大するには、ここをクリックします)
サーバーを再起動すると、DSRM で起動します。DC を通常モードで再起動するには、boot.ini ファイルから /SAFEBOOT スイッチを削除する必要があります。
DSRM パスワードを使用してログインしたら、再度 NTBACKUP コマンドを実行して、システム状態を復元します。今回はコマンド パラメータは指定しません (NTBACKUP をコマンド ラインから実行して復元を実行することはできません)。ウィザード画面が表示されたら、[ファイルと設定を復元する] をクリックし、[次へ] をクリックします。続いて、バックアップ ファイルを選択し、[システム状態] チェック ボックスをオンにします。図 4 を参照してください。
図 4 バックアップまたは復元ウィザードを使用してシステム状態を復元する
図 4 バックアップまたは復元ウィザードを使用してシステム状態を復元する (画像を縮小するには、ここをクリックします)
図 4 バックアップまたは復元ウィザードを使用してシステム状態を復元する
図 4 バックアップまたは復元ウィザードを使用してシステム状態を復元する (画像を拡大するには、ここをクリックします)
この時点で DC を通常モードで起動すると、Active Directory のレプリケーション処理により、復元された DC がドメイン内の他の DC と同期され、復元データが最新のデータで上書きされてしまいます。もちろん、これは意図するところではありません。実際には、復元したオブジェクトで、ドメイン内の他のドメイン コントローラのデータを上書きする必要があります。

権限のある復元を実行する
NTDSUTIL は、バックアップから復元までの日数に 10 万を乗じた数だけ、各属性のバージョン番号を大きくします。1 日に 10 万回以上更新される属性がある場合を除き、復元された属性のバージョン番号は、他の DC のバージョン番号よりはるかに大きくなります。したがって、レプリケーションにより、これらの DC のデータは権限のある復元が行われたオブジェクトで上書きされます。バックアップから権限のない復元が行われたその他のオブジェクトは、最終的に、その他のドメイン コントローラの既存のデータで上書きされます。
権限のない復元の実行後、通常モードで再起動する前に、NTDSUTIL プログラムを使用して、回復したいオブジェクトについて権限のある復元を実行します。「権限のある復元」と言っても、オブジェクトを本当に復元するわけではなく、Active Directory を使用して、オブジェクトをその他の DC にレプリケートするだけです。このために、NTDSUTIL は、使用可能な次の USN をオブジェクトの属性のローカル USN に割り当てます。これにより、次に同期が行われる際に、オブジェクトがレプリケーション パートナーに送信されます。単一のオブジェクトを復元するには、DC を DSRM で起動し、次の手順に従います。
  1. コマンド ウィンドウを開き、次のように入力します。
    ntdsutil
  2. ntdsutil のプロンプトで、次のように入力します。
    authoritative restore
  3. 権限のある復元のプロンプトで、次のように入力します。
    restore object “<DN of object to be restored>”
    たとえば、DRNET ドメインで、組織単位 (OU) Eng の Molly Clark のアカウントを復元するには、次のように入力します。
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    ディレクトリ サブツリー全体 (たとえば 1 つの OU) に対して、権限のある復元を実行する場合は、次のように入力します。
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    NTDSUTIL には、構成 NC やスキーマ NC を含めたドメイン全体に対して権限のある復元を実行する restore database コマンドもあります。しかし、ドメイン全体を復元するのは危険なので、お勧めしません。ドメイン全体を復元する必要がある場合は、まず 1 つのドメイン コントローラを復元し、ドメイン内のその他の DC を再び昇格させます。詳細については、「Active Directory フォレストの障害回復計画」を参照してください。
  4. プロンプトが表示されたら、権限のある復元で個々のオブジェクトとその属性のバージョン番号が大きくなることを確認します。
  5. 「quit」と 2 回入力して、ntdsutil を終了します。
  6. DC を通常の Active Directory モードで再起動します。
次回、DC とパートナーのレプリケーションが行われると、復元したユーザーのデータがレプリケートされます。ただし、ユーザー オブジェクトの復元は、問題解決の半分に過ぎません。グループとそのメンバ間のリンクのようなオブジェクト リンクの扱いは、より複雑です。復元の前後には、いくつかの根本的な問題が発生します。ここからは、これらの問題について説明します。
まず、後方リンクを持つオブジェクトを削除した場合、何が起こるか確認しましょう。たとえば、1 つ以上のグループのメンバになっているユーザー オブジェクトを削除するとします。このユーザー オブジェクトのコピーを持っている各ドメイン コントローラは、コピーを廃棄オブジェクトに変換し、リンク テーブルから参照をすべて削除します。このようにして、ユーザーのドメイン内のすべてのグループ メンバシップからこのユーザー オブジェクトを削除します。グループ メンバシップは各 DC がローカルで更新するので、グループ メンバシップからユーザーを削除しても、この変更はレプリケートされません。グループの member 属性のバージョン番号とローカルの USN は変更されません。しばらくすると、他のドメインのリンク テーブルからファントム オブジェクトが削除されます。この場合も、グループの member 属性のレプリケーション メタデータは更新されません。
ユーザー ドメインのドメイン コントローラ上で DIT に対し権限のない復元を実行すると、ユーザー オブジェクトと、そのドメイン内のグループのグループ メンバシップがすべて復元されます。このため、復元された DC には不整合はありません。NTDSUTIL ユーティリティを使用して、ユーザーに対し権限のある復元を実行すると、ドメイン内のその他のすべての DC にユーザー オブジェクトがレプリケートされます。
しかし、ドメイン内の現在のグループのレプリケーション メタデータは変更されないので、復元された DC 上のグループの member 属性と他の DC のグループの member 属性に不整合が生じます。この場合、これらを共通の状態にする方法はありません。したがって、ユーザーのメンバシップは、ドメイン内の他の DC 上では復元されません。

問題: ドメイン内のグループ メンバシップが復元されない
ユーザー オブジェクトに対し権限のある復元しても、ユーザーのグループ メンバシップは復元されません。なぜでしょうか。ユーザーの memberOf 属性 (後方リンク) ではなく、グループ オブジェクトの member 属性 (前方リンク) を使用してメンバシップのリレーションシップが保存され、レプリケートされるからです。この場合、問題となるのはユーザーの古いグループ メンバシップを見つけ出す方法です。このメンバシップが見つかったら、今度は適切に回復する方法が問題になります。
マイクロソフトでは、ユーザーのグループ メンバシップの回復処理に徐々に改良を加えてきました。このため、実行している Active Directory のバージョンによって使用する方法が異なります。次のセクションでは、主に Windows 2000 Active Directory について説明します。
ユーザーの以前のグループ メンバシップは非常に簡単に特定できます。復元された DC の後方リンク属性、この場合はユーザー オブジェクトの memberOf 属性を調べるだけです。memberOf 属性には、ユーザーのドメインのローカル グループおよびグローバル グループのすべてのメンバシップが含まれています。復元されたユーザーのグループ メンバシップを一覧表示するには、Microsoft 管理コンソール (MMC) の Active Directory ユーザーとコンピュータ スナップイン (ADUC) か、Windows Server 付属の LDIFDE ユーティリティを使用できます。
次の LDIFDE コマンドを実行すると、Molly Clark がメンバになっている DRNET ドメイン内のグループが一覧表示され、結果が output.ldf ファイルに書き込まれます。
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
LDAP ツールを使用するときは必ず通常モードで DC を起動する必要があります。また入力方向のレプリケーションは無効にしてください。そうしないと、復元したデータが上書きされます。REPADMIN コマンドを使用すると、入力方向のレプリケーションを簡単に無効にすることができます。
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
<dcname> の位置には、復元する DC 名を入力します。作業が完了したら、–DISABLE_INBOUND_REPL を使用してレプリケーションを再度有効にしてください。
回復するユーザー数が少数の場合は、ADUC を使用して、該当ユーザーをグループに手動で追加する方法が簡単です。回復するユーザー数がある程度の数に達している場合は、処理の一部を自動化するツールを利用できます。Microsoft 製品サポート サービスから利用可能な Microsoft GROUPADD ユーティリティでは、ユーザーの以前のグループ メンバシップを一覧表示するために作成した LDIF ファイルを受け入れて、これらのメンバシップを再作成する LDIF ファイルを生成します。たとえば、この GROUPADD コマンドでは、前述の Molly Clark の例で作成した LDIF ファイルを処理できます。
C:\> groupadd /after_restore output.ldf
このコマンドは、Molly Clark がグループ メンバシップを持っていたドメインごとに、groupadd_<domain>.ldf という名前の新しい LDIF ファイルを生成します。<domain> の位置には、グループを更新するドメインの完全修飾ドメイン名を入力します。この LDIF ファイルは、次のコマンドでインポートできます。
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Windows Server 2003 では、NTDSUTIL が改良され、member 属性内に存在する追加メタデータを利用して、リンクされた値のレプリケーション (LVR) 機能を使用できるようになっています。復元されたユーザー オブジェクトがドメイン内のグループのメンバであり、そのユーザーのグループ メンバシップが LVR メタデータと共に保存されていた場合、NTDSUTIL は member 属性の対応する値のバージョン番号を大きくします。これにより、復元されたメンバシップがレプリケートされます。
Windows Server 2003 SP1 バージョンの NTDSUTIL には、GROUPADD 機能が組み込まれていて、ユーザー オブジェクトに対し権限のある復元を行うと、自動的に LDIF ファイルが作成されます。図 5 はこの新しいバージョンの NTDSUTIL、図 6 は自動的に作成された LDIF ファイルの内容を示しています。
Figure 6 NTDSUTIL によって作成された LDIF ファイルの内容 (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
図 5 GROUPADD 機能が組み込まれた新しい NTDSUTIL
図 5 GROUPADD 機能が組み込まれた新しい NTDSUTIL (画像を縮小するには、ここをクリックします)
図 5 GROUPADD 機能が組み込まれた新しい NTDSUTIL
図 5 GROUPADD 機能が組み込まれた新しい NTDSUTIL (画像を拡大するには、ここをクリックします)
多数のユーザーおよびグループを含む OU 全体を復元する場合は、手動でユーザーをグループに追加していたのでは手間がかかります。グループ自体に対し権限のある復元を実行することで、復元されたグループ メンバシップを回復することができます。
ただし、グループに対し権限のある復元を実行する処理には、2 つの問題点があります。1 つは明らかな問題です。グループを復元すると、そのグループ内のメンバシップがバックアップ時の状態に戻ります。したがって、復元されたグループには、前回のバックアップ以降に加えられた変更内容をすべて適用し直す必要があります。もう 1 つはややわかりにくいのですが、Active Directory のレプリケーション方法と関係のある問題です。ユーザーとグループの両方に対し権限のある復元を実行した後、これらがレプリケートされる順番は決まっていません。グループ オブジェクトが、復元されたユーザー オブジェクトより先に DC にレプリケートされた場合、ソースのドメイン コントローラは、グループからユーザー参照を自動的に削除します。これは、ユーザー オブジェクトがまだその DC 上に存在していないからです。ユーザー オブジェクトが後でレプリケートされた場合でも、このオブジェクトはグループに追加されません。
この問題を解決する最も簡単な方法は、グループに対する権限のある復元をもう一度行うことです。最初の権限のある復元を実行した後、通常モードで再起動し、レプリケーションが正常に行われていることを確認します。次に DSRM で再起動し、NTDSUTIL を実行して、ユーザーがメンバになっているグループに対し権限のある復元を実行します。こうすることで、通常モードで再起動したとき、ユーザー オブジェクトがレプリケートされた後に、そのオブジェクトを参照するグループ オブジェクトがレプリケートされます。

問題: 他のドメインのグループ メンバシップが復元されない
「このユーザーはどのグループのメンバだったか」という問題は、実際には結構厄介です。復元しようとしているユーザーは、他のドメインのローカル グループやユニバーサル グループのメンバであった可能性があります。この場合、権限のない復元では、グループ メンバシップは復元されません。では、ユーザーが他のドメインのどのグループのメンバになっているかは、どのようにしてわかるのでしょうか。答えはグローバル カタログにあります。グローバル カタログには、固有のドメインのデータの他に、フォレスト内の他のドメインのデータの読み取り専用コピーが含まれています。
グローバル カタログに含まれているフォレスト全体のデータを利用するには、グローバル カタログに対して権限のない復元を実行します。つまり、まず第一にグローバル カタログのバックアップが必要になります。LDIFDE を実行してユーザーのグループ メンバシップを特定できたら、そのユーザーの他のドメインのユニバーサル グループ メンバシップを見つけることができます。
回復中のユーザーのグループ メンバシップ一覧が表示されたら、既定のポート 389 ではなく、グローバル カタログ ポート 3268 に接続し、検索先としてフォレストのルート ドメインを指定します。LDIFDE は、回復されたユーザーのグループ メンバシップを表示します。このメンバシップには、フォレスト内のすべてのドメインのユニバーサル グループのメンバシップも含まれています。具体的な方法は次のとおりです。
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
グローバル カタログ上で GROUPADD または新しい NTDSUTIL を実行すると、LDIF ファイルがユーザーのドメインに対して 1 つ、復元されたユーザーがメンバになっていたユニバーサル グループのある各ドメインに対して 1 つずつ生成されます。これらの LDIF ファイルをインポートすると、そのユーザーのすべてのグループ メンバシップが復元されます。これでだいたい終わりですが、次の問題にぶつかります。

問題: 他のドメインのローカル グループ メンバシップを回復する
Windows Active Directory 環境には、3 種類のグループが存在します。グローバル グループは、同じドメインのメンバだけで構成されるグループですが、自分のドメインと、フォレスト内のその他のドメインのドメイン ローカル グループ内でメンバとして使用できます。グローバル グループの member 属性は、グローバル カタログには表示されません。しかし、グローバル グループには自分のドメインのメンバしか含まれないので、問題はありません。ユニバーサル グループは、任意のドメインのメンバから構成されるグループであり、フォレスト内の他のユニバーサル グループ、フォレスト内の自分のドメインおよびその他のドメインのドメイン ローカル グループ内でメンバとして使用できます。ユニバーサル グループの member 属性は、グローバル カタログにレプリケートされます。ドメイン ローカル グループは、フォレスト内の任意のドメインのメンバから構成されるグループですが、他のドメインのグループ内メンバとしては使用できません。また、ドメイン ローカル グループの member 属性は、グローバル グループの member 属性と同様、グローバル カタログには表示されません。つまり、他のドメインのドメイン ローカル グループ内のユーザーのメンバシップは、簡単には回復できません。
Windows Server 2003 SP1 より前までは、外部ドメインのドメイン ローカル グループ メンバシップを回復するには、各ドメインの DC を復元し、復元されたユーザーが含まれていたドメイン ローカル グループのドメイン データを手動で検索して、このユーザーを特定したグループに追加し直す必要がありました。この方法は、ドメイン数の多い大規模な環境ではたいへん時間がかかります。
Windows Server 2003 SP1 バージョンの NTDSUTIL では、この点が強化されています。ドメイン コントローラ上で NTDSUTIL を実行すると、復元されたユーザー オブジェクトの DN と GUID を含むテキスト ファイルが作成されます。次に、各外部ドメインについて、単一の DC に対し権限のない復元を実行し、このテキスト ファイルを DC にコピーした後、NTDSUTIL を実行して、新しいドメイン固有の LDIF ファイル (回復されたユーザーを元々メンバだったドメイン ローカル グループに追加する) を生成します。
このためには、外部ドメインごとに DC 上で次のステップを実行します。
  1. 外部ドメインの DC を DSRM で起動します。
  2. NTBACKUP を使用して、復元されたユーザーのグループ メンバシップを含む DIT のコピーを復元します。
  3. NTDSUTIL で作成された .txt ファイルを作業対象の DC にコピーします。
  4. コマンド ウィンドウを開き、「ntdsutil」と入力します。
  5. 「authoritative restore」と入力します。
  6. 「create LDIF file(s) from <file name>」と入力します。<file name> にはテキスト ファイルの名前を入力します。
  7. 「quit」と 2 回入力して、ntdsutil を終了します。
  8. DC を通常の Active Directory モードで再起動します。
  9. 「ldifde –i –f <ldif filename>」と入力します。<ldif filename> には作成した LDIF ファイルの名前を入力します。
これで、削除されたユーザーのグループ メンバシップがすべて復元されました。

ステップ バイ ステップ
Active Directory ユーザーとそのグループ メンバシップの回復処理は簡単ではありません。特に複数ドメイン環境の場合、処理は複雑になります。グループ メンバシップを正常に回復するための手順は、実行中の Windows のバージョンによって異なります。
Windows 2003 SP1 を使用している場合は、次の手順を参照してください。
  1. GC を DSRM で起動し、削除されたユーザーを含むバックアップを使用してシステム状態の復元を実行します。
  2. NTDSUTIL を使用して、削除されたユーザーに対し権限のある復元を実行します。NTDSUTIL により、復元されたオブジェクトの DN と GUID を含むテキスト ファイルが 1 つと、ユーザーのグループ メンバシップの復元に使用する 1 つ以上の LDIF ファイルが作成されます。
  3. LDIFDE –i –f <LDIF filename> を実行して、現在のドメインとその他のドメインのグループ メンバシップをインポートします。<LDIF filename> には、手順 2 で作成した LDIF ファイルの名前を入力します。
  4. グローバル カタログを通常モードで再起動します。
  5. 各外部ドメインの DC を DSRM で起動し、復元されたユーザーのグループ メンバシップを含むバックアップを使用して、システム状態の復元を実行します。
  6. create ldif files コマンドを使用して、NTDSUTIL を実行します。
  7. DC を通常モードで再起動します。
  8. LDIFDE –i –f <LDIF filename> を実行して、外部ドメイン内のグループ メンバシップを復元します。<filename> には、手順 6 で作成した LDIF ファイルの名前を入力します。
  9. ここで、REPADMIN /syncall を実行して、強制的にレプリケーションを実行することもできます。
SP1 をまだ適用していない Windows Server 2003 を実行している場合、または Windows 2000 を実行している場合、追加の手順が必要です。旧バージョンの NTDSUTIL では LDIF ファイルは作成されません。GROUPADD ユーティリティを使用して作成する必要があります。次のようにします。
  1. グローバル カタログを DSRM で起動し、削除されたユーザーを含むバックアップを使用してシステム状態の復元を実行します。
  2. NIC を無効にするか、ケーブルを抜いて、入力方向のレプリケーションを無効にします。
  3. グローバル カタログを通常モードで再起動します。
  4. LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf を実行して、ユーザーのメンバシップをダンプします。<dn> の位置には識別名を入力します。
  5. GROUPADD /after_restore membership.ldf を実行して、LDIF ファイルを作成します。
  6. LDIFDE –i –f <filename> を実行して、現在のドメインとその他のドメインのグループ メンバシップをインポートします。<filename> には、手順 5 で GROUPADD を使用して作成した LDIF ファイルの名前を入力します。
  7. REPADMIN /options <dcname> –DISABLE_INBOUND_REPL を使用して、入力方向のレプリケーションを再度有効にします。
  8. 各外部ドメインの DC を DSRM で起動し、復元されたユーザーのグループ メンバシップを含むバックアップを使用して、システム状態の復元を実行します。
  9. DC を通常モードで再起動します。
  10. LDIFDE –i –f <filename> を実行して、外部ドメイン内のグループ メンバシップを復元します。<filename> には、手順 5 で GROUPADD を使用して作成した LDIF ファイルの名前を入力します。
  11. ここで、REPADMIN /syncall を実行して、強制的にレプリケーションを実行することもできます。
Windows Server 2003 SP1 より前の環境の場合、あとは復元されたユーザーの外部ドメイン ローカル グループのメンバシップを回復するだけです。ドメイン ローカル グループのメンバシップを手動で復元するか、バックアップから DC を復元して、ドメイン ローカル グループに対し権限のある復元を実行します。

まとめ
Active Directory 環境でうっかりユーザーや OU を削除してしまうのは、よくあることです。しかし、削除されたユーザーとそのグループ メンバシップを復元するのは驚くほど複雑で手間がかかり、間違いやすい作業です。こうした障害からできるだけ短時間で回復するには、オブジェクトのリンク、レプリケーション、削除、および権限のある復元について理解しておく必要があります。
実稼働環境ですべての手順をいきなり正しく実行できるはずはありません。あなたの会社の CEO のユーザー オブジェクトを回復する必要が生じてもあわてずに済むように、削除したオブジェクトの回復計画を紙に書き記しておくことをお勧めします。また、実際のデータで実行する前に、少なくとも 1 ～ 2 回は、その計画の手順を訓練しておきましょう。上司や CEO から感心、評価されること請け合いです。
参考資料
  • Active Directory から削除されたユーザーおよびユーザーのグループ メンバシップを復元する方法
  • Microsoft 製品サポート サービス
  • ステップバイステップ ガイド : Active Directory の管理

Gil Kirkpatrickは NetPro 社の最高技術責任者であり、1996 年以来 Active Directory 用ソフトウェアの開発に取り組んできました。彼が HP 社の Guido Grillenmeier と共同で行う Active Directory の障害回復ワークショップは好評です。また、彼は Directory Experts Conference (www.dec2007.com) の発起人でもあります。


 Windows の管理: Windows XP Embedded の重要性
Windows の管理 Don Jones

Windows XP Embedded の重要性
概要:
  • Windows XP Embedded の徹底解剖
  • 優れたハードウェア オプション
  • Windows XP Embedded のカスタマイズ

Windows XP Embedded は、コンポーネント化された Windows のバージョンであり、セットトップ ボックスや家電製品など、消費者向けの電子機器とよく結び付けて考えられます。しかし Windows XP Embedded を組織の情報技術ツールの 1 つとして使用できる場合もあります。
すべてのユーザーにとって最適な解決策ではない場合もありますが、シナリオによっては、管理オーバーヘッドを低下させたり、ハードウェアのコストやサイズを縮小したり、セキュリティを強化したりできます。

Windows XP Embedded とは
Windows® XP Embedded は、フットプリントの小さい Windows の 3 つのバージョンのうちの 1 つであり、他の 2 つは Windows Embedded CE と Windows Embedded for Point of Service です。組み込み型の Windows オペレーティング システムのうち、Windows XP Professional クライアント コンピュータの完全な機能を提供できる (少なくともその可能性がある) のは、Windows XP Embedded のみです。Windows XP Embedded は Windows XP Professional Service Pack 2 (SP2) をベースにしていますが、極限までモジュール化されているという点で、通常の Windows XP とは異なります。Windows XP Embedded には、標準インストール イメージと呼ばれるものがありません。代わりに、Windows Embedded Studio と呼ばれるツールキットを使用して、構築しているデバイスに合わせてカスタマイズされた Windows XP Embedded 環境を作成できます。この環境に含まれるのは、対象のデバイスに必要な機能のみです。DirectX® やエクスプローラが必要ない場合は、それらをインストールせずに済みます。このモジュール化により、各 Windows XP Embedded イメージを構築および展開する際に加える変更が少なくなります。つまり、管理作業の軽減、セキュリティの強化、およびイメージを実行するハードウェアのコストの削減が実現されます。使用できるいくつかのオプションは、図 1 のように Target Designer (Windows Embedded Studio の一部) で確認できます。
図 1 Target Designer でのコンポーネントの選択
図 1 Target Designer でのコンポーネントの選択 (画像を縮小するには、ここをクリックします)
図 1 Target Designer でのコンポーネントの選択
図 1 Target Designer でのコンポーネントの選択 (画像を拡大するには、ここをクリックします)

企業内での位置付け
Windows XP Embedded ベースのデバイスに適したユーザー シナリオは増加しています。たとえば、大規模な顧客サービス コール センターを管理する企業があるとします。多くの場合、コール センターの担当者に必要なのは、内部で開発された 1 つまたは 2 つのアプリケーションと Web ブラウザ程度です。担当者はコンピュータのごく一部の機能しか使用しないため、Windows XP Embedded を使用することにより、不要な機能を削除することができます。機能を減らすことにより、誤った操作の影響を受ける部分やセキュリティ攻撃を受ける確率が低下します。
Windows XP Embedded デバイスの機能は制限されているため、パフォーマンスの低い (多くの場合、安価な) ハードウェア上で実行できます。多くの製造業者は、電力消費量の少ない、Intel 互換のプロセッサを使用するマザーボードを生産しています。これらのマザーボードは非常に小さく、消費する電力量もわずかです。また、実行時の発熱量が少ないため、多くの場合ファンを使用しません。このため、使用できるアプリケーションの数が少ない、小さなフットプリントの組み込み型デバイスに最も適しています。

Windows XP Embedded の優れたオプション
Windows XP Embedded では、Windows XP の完全なバージョンでは使用できない非常に役立つオプションがいくつか提供されます。Enhanced Write Filter (EWF) と Hibernate Once, Resume Many (HORM) を使用すると、Windows の管理作業を簡略化できます。EWF は、展開する Windows XP Embedded に追加して、特定のディスク ボリュームを読み取り専用にできるオプション コンポーネントです。ディスクへの書き込み操作は、別のディスク上やメモリ内に配置できるオーバーレイにすべて変換されます。オペレーティング システム自体は、EWF オーバーレイとその親ボリュームを 1 つの単位として認識します。つまり、通常のディスク ボリュームと同じように認識します。しかし、実際は親ボリュームには変更が加えられず、EWF オーバーレイにのみ変更が加えられます。この動作を活用する方法はいくつかあります。たとえば、Windows XP Embedded イメージをコンパクト フラッシュ (CF) カードに展開するとします (Windows XP Embedded イメージは 5 MB ほどしかありませんが、多くの場合約 200 MB でチェックインするため、CF カードには十分な大きさの記憶域が必要です)。この CF カードはアダプタに差し込んでマザーボードの IDE コネクタに接続できるため、通常の固定ディスクと同じように使用できます。現在の CF カードは書き込み可能回数が制限されている (約 100,000 回) ため、EWF を使用して CF ボリュームを読み取り専用にするとよいでしょう。ここでは、EWF オーバーレイを RAM 内に配置したと仮定します。ユーザーが誤った操作を行った場合は、単にコンピュータの電源をオフにします。これにより、EWF オーバーレイと、コンピュータに加えられたすべての変更は即座に失われます。コンピュータを再起動すると、CF カードに格納された最初の状態に戻ります。同じ設定を CD または DVD ベースのイメージに使用することができます。これらのメディアは基本的に読み取り専用であるため、EWF はすべての書き込み操作をオーバーレイにキャプチャします。オーバーレイが小容量の内蔵ハード ディスクに格納された場合でも、元の (CD または DVD 上の) ブート ボリュームは変更されません。コンピュータを最初の構成に戻す必要がある場合は、EWF オーバーレイを消去するだけで済みます。
HORM を使用すると、その名前のとおり、コンピュータを 1 回休止状態にし、その時点の状態から何回でも再開することができます。コンピュータはほぼ瞬時に起動します。必要な作業は、コンピュータを構成し、必要なアプリケーションがすべて実行された状態にした後、そのコンピュータを休止状態にするだけです。それ以降は、コンピュータを起動して数秒待機するだけで、再びすべてのアプリケーションやサービスが実行された状態になります。

Windows XP Embedded イメージの構築
マイクロソフトでは、Windows XP Embedded を専門に扱う企業から構成される、Embedded Partner プログラムを展開しています (参加企業の一覧は、microsoft.com/japan/windows/embedded にある Windows XP Embedded のホーム ページから参照できます)。しかし、多くの企業が通常用の PC の製造業者に構築済みのイメージ (企業のアプリケーションや特定の構成を含みます) を提供しているように、独自の Windows XP Embedded イメージを構築して、フットプリントの小さい完全なシステムを提供している Embedded パートナーと共有することが必要になる場合があります。Windows XP Professional に Windows Embedded Studio をインストールし、Windows XP Embedded イメージの構築と管理に使用することができます。
このツールキットを使用するには、まず Windows XP Embedded システム用に使用するハードウェアに、Windows XP Professional の完全なバージョンをインストールします。これにより、完全な Windows XP のセットアップ ルーチンを使用して、すべてのハードウェアを正常に動作させることができます。次に、Windows Embedded Studio をインストールします。通常、Windows Embedded Studio をインストールすると、組み込み型のイメージの管理に使用されるデータベースがインストールされますが、このデータベースを別の場所にインストールして、中央のリポジトリを提供することができます。次に、Tap.exe というコマンド ライン ユーティリティを実行して、Windows XP Embedded で使用できる新しい特殊なコンポーネントを作成します。通常、コンポーネントにより、メディア プレーヤー、ファイル システム、その他のカスタム アプリケーションなどの機能がカプセル化されます。この場合は、特定のシステムに必要なハードウェア デバイス ドライバを含むコンポーネントを作成します。この手順は、ツールが適切なハードウェア ドライバを検出して追加できるように、ターゲット ハードウェアで実行する必要があります。
次は、Windows XP Embedded Component Designer を実行し、Tap.exe ユーティリティによって作成されたコンポーネントをインポートします。図 2 に示されているように、Component Designer はデバイスの情報を読み取り、完全な Windows XP Embedded コンポーネントを構成します。このコンポーネントが、新しい Windows XP Embedded イメージの基盤になります。このツールにより、使用するプラットフォームに必要なデバイス ドライバを正確に特定する作業が大幅に簡略化されます。コンポーネントの作成後、Component Database Manager を使用して、新しいコンポーネントを Windows XP Embedded コンポーネント データベース (既知の Windows XP Embedded コンポーネントがすべて格納されたリポジトリ) にインポートします。コンポーネントを Windows XP Embedded コンポーネント データベースに格納することにより、Windows XP Embedded イメージでそのコンポーネントを使用できるようになります。
図 2 Component Designer
図 2 Component Designer (画像を縮小するには、ここをクリックします)
図 2 Component Designer
図 2 Component Designer (画像を拡大するには、ここをクリックします)
これで、実際の作業の大部分に使用する Windows XP Embedded Target Designer ツールを使用して、新しいターゲットの構成を作成するための準備ができました。図 1 で確認したように、デバイスに必要な一連の関数の作成に必要なコンポーネントをすべて追加します。また、エクスプローラ (デバイスでグラフィック シェルが必要な場合)、NTFS ファイル システム (または FAT32)、NT Loader、言語サポート、ユーザー インターフェイス コアなど、Windows の主要コンポーネントをいくつか追加することも必要になります。既定では、10,000 種類を超える数のコンポーネントを使用できます。
各コンポーネントの設定をあらかじめ構成することもできます。たとえば、Windows の [スタート] メニュー、デスクトップ、およびその他の場所に特定の項目を表示するように、User Interface Core コンポーネントをカスタマイズすることができます。各コンポーネントの設定をカスタマイズすることにより、各デバイスを要件に合わせてあらかじめ構成することができます (図 3 を参照)。
図 3 設定のカスタマイズ
図 3 設定のカスタマイズ (画像を縮小するには、ここをクリックします)
図 3 設定のカスタマイズ
図 3 設定のカスタマイズ (画像を拡大するには、ここをクリックします)
Windows XP Embedded イメージで最も注意が必要なのは依存関係です。たとえば、イメージに DirectX コンポーネントを追加するには、Windows に主要なグラフィック処理機能を提供するいくつかのコンポーネントも追加する必要があります。すべての依存関係を把握するのは、特に何千もの依存関係を持つ、サイズの大きい複雑なイメージでは非常に困難になる可能性があります。ここでコンポーネント データベースが役立ちます。Target Designer 内で F5 キーを押すだけで、追加したすべてのコンポーネントがスキャンされ、それらのコンポーネントに必要な依存コンポーネントが自動的に追加されます。図 4 は、実行中のスキャンを示しています。これは、Windows XP Embedded を高度にモジュール化するための重要な処理です。この機能が Target Designer に組み込まれていることにより、すべての正しい依存コンポーネントが含まれたイメージを正常かつ容易に作成することができます。
図 4 依存関係チェック
図 4 依存関係チェック (画像を縮小するには、ここをクリックします)
図 4 依存関係チェック
図 4 依存関係チェック (画像を拡大するには、ここをクリックします)
必要なコンポーネントとそれらの依存コンポーネントをすべて追加したら、Windows XP Embedded イメージをビルドできます。イメージは、Windows XP Embedded デバイスのブート ボリュームにコピーするファイルです。これらのファイルは、特殊なツールを使用することなく展開できます (Windows XP Embedded ツールセットにはリモート インストール サービスと似た機能を持つリモート ブート サーバーも含まれており、これを使用して Windows XP Embedded イメージをベアメタル ハードウェアに展開することもできます)。これらの手順を完了した後、構築したイメージの実際のサイズを確認できます。エクスプローラ シェルと、メモ帳やペイントなどの数個のアプリケーションが含まれた非常に基本的なイメージを作成した場合、そのイメージのサイズは 90 MB 未満でした。もちろん、メモ帳とペイントしか実行できないデバイスに関心を持つユーザーはあまりいませんが、ある作業に特化したイメージのサイズはここまで小さくできることがわかります。

Windows XP Embedded と Windows XP
Windows XP Embedded は、必要最低限の機能しか使用できないオペレーティング システムというわけではありません。マイクロソフトでは、Windows XP Embedded を実行しているコンピュータに Windows XP の完全なバージョンとほぼ同じ機能を実装できる、パッケージ化されたコンポーネントを提供しています。これには、DirectX 9.0c、Microsoft® .NET Framework、Windows Media® Player 10 などをインストールするためのオプションが含まれています。また、エクスプローラを置き換えるカスタム シェルなどのカスタム コンポーネントを構築する方法が記載された開発者向けのドキュメントも多く含まれているため、特定の Embedded デバイスに合った環境を作成できます。
しかし Windows XP Embedded では、Windows XP Professional の完全なバージョンに含まれているすべての機能は提供されません。たとえば、Windows ファイル保護 (WFP) は Windows XP Embedded には含まれていません。また、Windows XP ツアー、新しいユーザーがコンピュータを構成するのに役立つ最初のようこそ画面やウィザード、Windows セットアップなど、いくつかのユーザー フレンドリな機能も含まれていません。Windows XP Embedded は、Windows 製品のライセンス認証を使用しません (Windows XP Embedded イメージのライセンス認証は、Windows Embedded Studio ツール内からランタイム プロダクト キーを使用して行います)。特に顕著な違いは、Windows XP Embedded は環境内の Microsoft Software Update Services サーバーを使用できるが、Windows Update をまったく使用しないことです。さらに、Windows XP Embedded では、Windows XP Professional に含まれている MSN® Explorer も提供されません。
充実した Windows XP Embedded の開発サイクルは、先を見越しながら進んでいます。現在は、新機能が追加された Feature Pack 2007 が提供されています。これらの新機能には、USB ブート、オーバーレイ全体をコミットしなくても新しいファイルを親ボリュームにコミットできる EWF の機能拡張、NTFS 圧縮のサポートなどがあります。これらの機能拡張によって、Windows XP Embedded オペレーティング システムにさらなる柔軟性や選択肢が加わるだけでなく、より Windows XP Professional に近い機能がこのオペレーティング システムで提供されます。

組み込み型システムの開発を始めてみよう
組み込み型システムは、従来の Windows XP システムよりも構築に少し時間がかかることがありますが、シナリオによっては大きな利点があります。Windows XP Embedded システムの機能は制限されていますが、管理や修理が容易でコストを大幅に削減できる、消費電力の少ない小さなハードウェアをサポートできます。消費電力の減少により、公共料金や発熱も抑えることができるため、コンパクトな作業環境を設計する際に、優れた柔軟性が提供されます。消費者向けの機器、医療機器、キオスクなどのほか、思いもよらない製品の内部でも Windows XP Embedded が使用されていますが、そのような一般的な使用方法だけでなく、企業でも組み込み型のオペレーティング システムを使用することが最適な場合があります。

Don JonesSAPIEN Technologies のプロジェクトおよびサービスの責任者であり、『Windows PowerShell: TFM』(SAPIEN Press) の共著者でもあります。Don に対するお問い合わせについては、彼の Web サイト (www.ScriptingAnswers.com) を参照してください。


 管理: System Center Capacity Planner による事前計画
管理 John Savill

System Center Capacity Planner による事前計画
概要:
  • SCCP の基礎
  • 新しいモデルの作成
  • モデルの微調整
  • 実際の使用状況のシミュレーション

現在のインフラストラクチャ コンポーネントは、コンポーネントがサポートするビジネスには重要です。しかし、ユーザー数が増加し、企業が多様化するにつれて、
コンポーネントを運用するサーバーの規模や台数を正確に見積もるのは困難になります。ハードウェアは、不十分だとエンド ユーザーへの応答時間の低下につながり、過剰になりすぎると簡単に予算が浪費され、余分な管理が必要になります。このため、マイクロソフトは System Center Capacity Planner (SCCP) 2006 を作成しました。
大まかに言えば、SCCP では、使用するネットワーク トポロジ (場所、リンク速度、待機時間)、ソフトウェア、ハードウェア、および使用プロファイル (送信メッセージ数など) に関する情報を入力できます。その後、ハードウェアやネットワーク コンポーネントの使い方を、さまざまな使用レベルやさまざまな詳細設定に変更してシミュレーションを実行します。提案された構成を実装した場合に、サービスの要件を適切に満たすことになるかどうかを確認するために、こうしたモデル化が役に立ちます。
SCCP は、特定のサーバーで運用することも、ネットワーク テストを行うことも必要ではありません。基本的には、モデル化した環境に対してテスト シナリオを実行できるシミュレーション ツールです。SCCP に実際に必要な最低限のシステム要件は、Windows® XP with Service Pack 2 (SP2)、Windows Server® 2003、または Windows 2000 SP4 と、Microsoft® .NET Framework 2.0 です。Microsoft Operations Manager (MOM) では既にサーバーの使用状況に関する情報を収集しており、Systems Management Server (SMS) ではハードウェア構成に関する情報を管理しているため、次世代の SCCP では MOM と SMS にさらに密接なインターフェイスがとられ、一部の情報を自動的に収集することを期待できます。
SCCP 2006 のインストールは簡単です。標準のインストール ウィザードでは、使用許諾契約への同意と、インストール先フォルダの確認が必要なだけです。製品がインストールされると、[すべてのプログラム] メニューにショートカットが追加されます。SCCP の初回起動時には、Microsoft Capacity Planner の [Welcome] (ようこそ) 画面が表示され、図 1 に示すように、Capacity Planner の 4 つのコンポーネントのうち 3 つにアクセスできます。
図 1 Capacity Planner ツールの開始
図 1 Capacity Planner ツールの開始 (画像を縮小するには、ここをクリックします)
図 1 Capacity Planner ツールの開始
図 1 Capacity Planner ツールの開始 (画像を拡大するには、ここをクリックします)
Model Wizard (モデル ウィザード) では、システム アーキテクチャ モデル (SAM: System Architecture Model) を作成するために、希望する環境に関する質問が行われます。SAM には、場所、ユーザー、ネットワーク、使用パターン、およびハードウェアの詳細情報が含まれます。
Model Editor (モデル エディタ) では、以前にウィザードまたはエディタを使用して作成した SAM の微調整や変更が可能です。エディタでは、モデルの検証、シミュレーションを行った使用状況の表示、およびメール サーバーでの追加の負荷やリモート ユーザーの存在などのその他のシナリオのテストが可能です。
Capacity Planner には、SAM で使用するために、あらかじめ定義されたハードウェアの種類が多数含まれています。ただし、異なる種類のハードウェアが必要な場合は、Hardware Editor (ハードウェア エディタ) によるハードウェア構成のカスタム定義がサポートされます。
モデルを選択したら、Capacity Planner の Simulation (シミュレーション) を使用して、選択したモデルに対してさまざまなテストを行い、そのモデルが実際環境の実装に実現可能かどうかを判断できます。
コンポーネントを調べたり、コンポーネントが相互作用する方法を調べる場合は、実際にツールを使用するのが最善の方法です。この記事では、ウィザードを使用することから始め、シミュレーションを実行し、カスタム ハードウェアを実行することでアーキテクチャ モデルを微調整します。このウォークスルーでは、Exchange 環境を扱いますが、そのプロセスは MOM に似た方法で機能します。

新しいモデルの作成
計画するインフラストラクチャの検証や "what if" シナリオを実行する前に、または現状配置済みインフラストラクチャについてシナリオを実行する場合でも、SCCP に環境を記述する必要があります。残念ながら、現在のバージョンではネットワークを簡単にスキャンすることはできません。そのため、物理的な場所、物理場所間の接続の種類、サーバー、メールボックス、ユーザーの配置に関連してインフラストラクチャを詳しく記述し、ユーザーがその環境を使用する方法についても詳しく記述する必要があります。
詳しくはユーザー ガイドで説明されていますが、このツールにはいくつか制限事項があります。たとえば、Exchange モデルでは、単一フォレストしかサポートされません。つまり、外部フォレスト内のドメインはモデル化されません。そのため、任意のフロントエンド サーバーでは、グローバル カタログとメールボックス ストアの両方を同じサイトに保持していると想定されます。100 サイトのみをモデル化でき、その中で最大 10 サイトをハブ サイトにできます。最大 300 台のサーバー コンピュータがサポートされ、Outlook® 2003 クライアント (Web またはローカル) のみがサポートされます。良い知らせとしては、SCCP では中央またはハブの場所では最大 49,999 のクライアントがサポートされ、支社の場所では最大 10,000 のクライアントがサポートされます。ActiveSync® や Outlook Mobile Access 接続などの Exchange 機能はサポートされず、POP や IMAP などのレガシ接続オプションもサポートされません。バックアップと復元の操作に起因する使用状況は考慮されません。また、クラスタ構成も考慮されません。ただし、Capacity Planner には、日常のメールの典型的な用途を正確にモデル化するのに必要なオプションがあります。
[Welcome] (ようこそ) ページからウォークスルーを開始するには、[Create a model with the Model Wizard] (モデル ウィザードを使用してモデルを作成する) を選択し、モデル化するインフラストラクチャを記述します。ここでは、次のような企業を作成します。ダラスに本社、ヒューストンとオースティンに支社があり、それぞれローカルに多くの電子メール ユーザーがいます。各場所に独自のサーバーを用意する必要はないので、電子メール ユーザーの数と種類に関する情報を指定します。SCCP ではその情報により、Exchange サーバーをローカルに設置すべき場所と、ユーザーが Exchange サーバーにリモートに接続する場所を推定します。
企業インフラストラクチャの基本的なモデルを作成したら、ウィザードにより本社と支社のサイト数、各サイト間の接続、およびメッセージングの目的に使用できる帯域幅の比率の入力を求められます。ウィザードは広範なアプローチを使用して作業を勧めます。この記事の後半では、ウィザードが作成したモデルを微調整して、細部との個別のリンクを構成します。この例では、1 つの本社サイトと 2 つの支社サイトを確認できます (図 2 参照)。本社サイトと支社サイトの間には T1 接続があり、メッセージングには帯域幅の 50% が使用されます。本社は 1 つしかないので、本社サイト間の速度は構成する必要がありません。
図 2 WAN トポロジと接続帯域幅の構成
図 2 WAN トポロジと接続帯域幅の構成 (画像を縮小するには、ここをクリックします)
図 2 WAN トポロジと接続帯域幅の構成
図 2 WAN トポロジと接続帯域幅の構成 (画像を拡大するには、ここをクリックします)
ウィザードの次のウィンドウでは、支社の平均ユーザー数、電子メール クライアント (キャッシュ モードの Outlook 2003 または Outlook Web Access)、および本社サイトのユーザー数の入力を求められます。繰り返しになりますが、これは非常に大まかな情報で、後からモデル エディタを使用して微調整できます。ここでは各支社に 200 人、本社に 500 人のユーザーがおり、すべてのユーザーがキャッシュ モードの Outlook を使用していることにしました。
ウィザードの既定のメール使用レベルには、High (高)、Medium (中)、Low (低) の 3 つがあります。各レベルでは、メールボックス平均サイズ、送受信するメッセージ数、および電子メール メッセージごとの平均サイズに異なる値を想定します。どの組み込みの種類も組織に必要な使用パターンに一致しない場合は、4 つの個別の使用特性それぞれに対して、個別の値を構成できます。
次の手順では、図 3 に示すように、ハードウェア設定を構成します。SCCP では考えられる CPU 構成を 3 つまで指定でき、これらの構成を使用して、サーバーのさまざまな役割に対してハードウェアをモデル化します。CPU 構成には、1 CPU の 1 GHz Pentium III Xeon から、4 CPU の 3.66 GHz Xeon MP まで、あらゆる構成が可能です。Exchange 2003 は、多くの役割 (つまり、メールボックス ストア、ブリッジヘッド、フロントエンド) で構成され、さらに Active Directory® グローバル カタログの役割もあります。使用状況で許容されれば、役割を少数のサーバーに統合するオプションを使用できます。サーバーの統合を指定しないと、使用状況として必要がなくても、役割ごとに個別のサーバーが構成されます。SCCP が統合を行うことを許可することで、最適な結果が得られます。
図 3 サーバーのハードウェア プロファイルの構成
図 3 サーバーのハードウェア プロファイルの構成 (画像を縮小するには、ここをクリックします)
図 3 サーバーのハードウェア プロファイルの構成
図 3 サーバーのハードウェア プロファイルの構成 (画像を拡大するには、ここをクリックします)
最後に、インターフェイス、サイズ、および速度を基に使用できるディスクの種類を選択できます。ディスクの数は Capacity Planner が計算するため、指定する必要はありません。ストレージ エリア ネットワーク (SAN) を指定することもできますが、現状ではクラスタを作成する機能は使用できません。
ウィザードの次の手順は見積もったモデルの要約で、SCCP が最適と見積もったサーバー台数、各サーバーの役割、およびプロセッサ、メモリ、ディスクの詳細構成が示されます。SAN を選択している場合は、それも表示されます。
複数の場所を選択しただけなので、その場所の一部にしかサーバーが表示されない可能性は十分にあることに注意してください。これは、図 4 に示すように、今回の例では、場所によってはローカルに Exchange サーバーを配置することは最適ではなく、リモートの Exchange メールボックス サーバーを利用してメールボックスにサービスを提供する方が適切であると、SCCP が調査によって確認したためです。ここでは、400 人の支社ユーザーにはローカルの Exchange メールボックス ストアがなく、現在 500 人のユーザーがいるダラスの Exchange メールボックス ストア サーバー 1 台に統合されています。
図 4 Capacity Planning の初期評価の要約
図 4 Capacity Planning の初期評価の要約 (画像を縮小するには、ここをクリックします)
図 4 Capacity Planning の初期評価の要約
図 4 Capacity Planning の初期評価の要約 (画像を拡大するには、ここをクリックします)
ウィザードのこのページまでは、[Back] (戻る) と [Next] (次へ) ボタンをクリックして (または、左側のナビゲーション ウィンドウでウィザードのページを直接クリックして)、回答を変更し、モデルの要約を微調整できます。希望どおりの構成になったら、[Model Summary] (モデルの要約) ページで [Finish] (完了) ボタンをクリックします。その結果、このモデルがモデル エディタで開かれ、構成をさらに細かく調整できます。

モデルの微調整
モデル ウィザードは、基本モデルを作成するのに優れたツールです。ただし、さまざまな場所がそのまま使用できる平均的なものでない限り、使用状況の見積もりの基礎として本当に役立つように、そのモデルに対して何らかのカスタマイズが必要になる可能性があります。場所によっては、ユーザー数が異なっていたり、一部がキャッシュ モードの Outlook 2003 で、一部が Outlook Web Access (OWA) であるなど、メッセージング クライアントにさまざまな組み合わせが考えられることも珍しいことではありません。モデル ウィザードでは、このレベルの細かい指定はできませんが、モデル エディタを使えば構成可能です。たとえば、場所やユーザーの種類を追加して、環境のある側面を変更した効果を確認する場合もこのツールが役に立ちます。
モデル エディタでは、図 5 に示すように、ツール専用のフォーマットでモデルを .sam ファイルに保存し、取得します。他のすべての作業と同様に、大きな変更を加える前にモデルをファイルに保存し、作業中のモデルを失わないように、内容を説明するファイル名を使用することをお勧めします。[File] (ファイル) メニューには [Export] (エクスポート) メニュー項目があり、要約の詳細レポートを Excel® 形式で生成し、モデルを Visio® のトポロジ ダイアグラムとして生成します。
図 5 モデル エディタでの SAM 構成の微調整
図 5 モデル エディタでの SAM 構成の微調整 (画像を縮小するには、ここをクリックします)
図 5 モデル エディタでの SAM 構成の微調整
図 5 モデル エディタでの SAM 構成の微調整 (画像を拡大するには、ここをクリックします)
モデル エディタの左側のウィンドウには、Global Topology (グローバル トポロジ)、Site Topology (サイト トポロジ)、または Model Summary (モデルの要約) を表示するオプションを備えた基本ナビゲーション領域があります。グローバル トポロジでは、サイトの観点から見たアーキテクチャ モデルが、インターネットなどの追加ネットワークと共に表示されます。サイト トポロジ ビューでは、選択したサイトまたはネットワークに関する情報が表示されます。モデルの要約では、環境の要約がテキスト形式で表示されます。これは、モデル ウィザードの最後のページに表示される情報と同じ形式です。
どのオプションを選択しても、モデル エディタの中央のウィンドウに詳細が表示されます。右側のウィンドウは、Windows Server 2003 R2 に同梱される新しいバージョンの Microsoft 管理コンソール (MMC) で採用されたウィンドウで、2 つのサブ領域に分割された "操作" 領域です。上部の領域には、現在のビューまたは選択したオブジェクトに応じて変化する状況依存の操作が表示され、下部の領域には、どのような状況にも当てはまる一般的な操作が表示されます。こうした一般的な操作には、新しいサイトの追加、ユーザーの使用プロファイルの編集、(興味深い) シミュレーションの実行などがあります。
モデル エディタの中央のウィンドウで作業しているときに、すべての項目を選択できます。項目を選択すると、選択したオブジェクトを基に現在の項目操作が変化するだけでなく、そのオブジェクトに関する詳細情報にドリルダウンできます。たとえば、サイトをダブルクリックするとサイト トポロジ ビューに切り替わり、そのサイトに対してモデル化されたオブジェクトの詳細が表示されます。そのため、ローカルにサービスが提供されるサイトでは、その場所にサーバー、ネットワーク、およびユーザーが 1 つ以上表示されることになります。さらに、選択したオブジェクトをダブルクリックすると、オブジェクトの詳細プロパティが表示され、必要に応じて変更することができます。
サイト間を結ぶ線は、その場所間のネットワークを表し、これを編集して、ネットワークの正確な構成を設定できます。たとえば、アップリンクとダウンリンクの帯域幅に異なる速度を指定したり、使用可能な帯域幅の比率を指定したりできます。また、接続の待機時間を構成することもできます。接続の待機時間は、安定した通信にとって非常に重要な属性になることがあります。他にもよく行われる変更として、ユーザーの種類の追加があります。ここで、本社でサービスを提供するクライアントには Outlook Web Access と Outlook 2003 が混在しているとしましょう。サイト トポロジ ビューでダラス本社を開き、[Add a client profile] (クライアント プロファイルの追加) をクリックして、OWA ベースのユーザーに関する情報を追加します。図 6 に示すように、この情報には、OWA クライアントが使用するサーバー、ユーザーが接続するネットワーク、使用可能な帯域幅などがあります。
図 6 モデル内の要素の簡単な追加と変更
図 6 モデル内の要素の簡単な追加と変更 (画像を縮小するには、ここをクリックします)
図 6 モデル内の要素の簡単な追加と変更
図 6 モデル内の要素の簡単な追加と変更 (画像を拡大するには、ここをクリックします)
既存のインフラストラクチャまたは計画するインフラストラクチャが、できる限り密接に SAM に反映されたら、わかりやすい名前を付けて保存します。これが、以降の変更の出発点になります。ここで、構成した設定でモデルがどのように実行されるかのベンチマークを取得するためにシミュレーションを実行します。新しいサイトとユーザーの追加、サーバーの追加や削除、場所へのユーザーの追加、接続や電子メール クライアントの種類の変更など、さまざまな "what if" シナリオをテストするために、このベンチマークを基にモデルを変更できます。このような新たな要素によってモデルが更新されたら、新しい構成が要求に耐えられるかを確認するために別のシミュレーションを実行できます。

実際の使用状況のシミュレーション
シミュレーションの実行は簡単で、一般的な操作またはツールバー ボタンの [Run Simulation] (シミュレーションの実行) をクリックするだけです。まず、モデルのサニティ チェックが行われ、シミュレーションを実行する前に、モデルの不備が表示されます。たとえば、以前には OWA クライアントがおらず、フロントエンド サーバーが構成されていなかったモデルに、多くの OWA クライアントが追加されると、フロントエンド サーバーが存在しないことを通知するエラー メッセージが表示されます。こうした不備がなければ、シミュレーションが実行され、それにつれて状態が表示されます。
シミュレーションが完了すると、すべてのコンポーネントの使用状況に関する詳細情報を含むレポートが生成され、[Simulation Results] (シミュレーションの結果) ビューが開きます。最初に情報を要約するビューが表示されます。このビューには、最も使用率の高い CPU、ストレージ、接続リンク (これらは一般的にボトルネックの原因です) と、実行時間の長いトランザクションや待機時間 (エンドユーザーの操作性に影響します) が表示されます。図 7 に示すように、サーバー、SAN、ローカル接続や外部接続の正確な使用状況についての詳細は、シミュレーションの結果ビューの左側のウィンドウにあるリンクをクリックすることで表示できます。
図 7 単純なモデルのシミュレーション結果の要約
図 7 単純なモデルのシミュレーション結果の要約 (画像を縮小するには、ここをクリックします)
図 7 単純なモデルのシミュレーション結果の要約
図 7 単純なモデルのシミュレーション結果の要約 (画像を拡大するには、ここをクリックします)
たとえば、[Bottleneck analysis] (ボトルネック分析) のグラフィック表示上にマウス カーソルを停止すると、ボトルネックの原因になるサーバーとそのサーバーの属性が示されます。左側のウィンドウの [Threshold settings] (しきい値の設定) に注目してください。このカテゴリは、警告を上げるには値しない、正当な使用方法と見なせる範囲を設定できる便利な機能です。
シミュレーションの詳細レポートは、ハードウェアの購入を決定する際に役立つ情報であるだけでなく、メッセージング アプリケーションで使用されるネットワーク リソースの量を示す場合にも優れています。たとえば、レポートは、低速 WAN リンク経由で接続するユーザーについては、そのリンクの速度が十分かどうかを示します。十分でなければ、場所間のリンク速度をアップグレードするか、ローカル メールボックス ストア サーバーを追加するか、一定の条件を満たす結果を得るためにモデルを変更してシミュレーションを再実行するかを検討できます。同様に、サーバーが常時 5% の CPU 使用率で実行されていれば、サーバーの仕様を落とすことができます。モデルの変更やシミュレーションの実行が容易なので、さまざまなソリューション オプションを自由に実験することができます。その結果、テスト済みのすべてのシナリオからの正確な測定結果を携え、自信を持って、予算会議や企画会議に出席できます。

まとめ
この記事では、SCCP を使用して Exchange 展開のシミュレーションと分析を行う方法の概要について説明しました。SCCP でも、MOM と同じレベルのモデル化とシミュレーションを実行できることに留意してください。SCCP は、現在 MSDN® Premium ダウンロードまたは TechNet Plus の一部としてダウンロードできます。 ¦

John Savill は、Geniant の Technical Infrastructure 部門の責任者です。彼は、CISSP および Windows Server 2003 トラックのセキュリティとメッセージングの MCSE で、8 回の MVP の受賞歴があり、Krav Maga のインストラクタでもあります。また、Packt Publishing から出版されている『Windows Server 2003 Active Directory Design and Implementation』の著者です。


 管理: SMS によるアドバンスト クライアント インベントリ
管理 Wes Dobry

SMS によるアドバンスト クライアント インベントリ
概要:
  • SMS 2003 ハードウェア インベントリ エージェントの使用
  • MIF ファイルによるインベントリ機能の拡張
  • 動的 MOF ファイルと静的 MOF ファイルの比較
この記事で使用しているコードのダウンロード: DobrySMSInventory2007_04.exe (152KB)

管理者としてのあらゆる活動の中で、困難な作業を伴わずには収集できない情報を上司から求められることがあります。しかし、積極的な管理者であり、
こうしたデータの収集を既に完了しているところを想像してください。求められた情報を上司にすぐに提供でき、不要なダウンタイムを避け、多くの時間を費やさず、企業の費用を大幅に節約できたとしたら、ヒーローになれるでしょう。
Microsoft® Systems Management Server (SMS) 2003 は、購入時の設定のままでも大量の情報を収集します。しかし、すべての情報を収集するわけではありません。たとえば、SMS 2003 は既定ではローカル グループとそのメンバ、およびローカル ユーザーとその属性は報告しません。技術者が Domain Users グループ、またはさらに悪いことに Everyone グループを、作業している各システムのローカル管理者グループに配置しているとしたら、こうした情報が収集されていないことが問題になる可能性があります。あるいは、社内のウィルス対策ソリューションやスパイウェア対策ソリューションの除外リストにどのようなローカル ファイルやフォルダが含まれているかを把握する方法が会社にないとします。これは大きな問題ではないように思えるかもしれません。ただし、それも、ユーザーが除外リストに c:\*.* を含めていることに IT 部門のだれかが気付くまでです。
スクリプティング、Windows® Management Instrumentation (WMI)、および SMS の知識を組み合わせて SMS のインベントリ機能を拡張し、必要な少量の情報だけを含めることができます。これは、MIF (管理情報フォーマット) ファイルと MOF (管理オブジェクト フォーマット) ファイルを使用して可能になります。

インベントリの取得
組織では SMS を使用して、カスタマイズした展開の実行、ターゲットの監視、および展開済みシステムのメンテナンスを行うことができます。SMS のインベントリ機能を拡張すれば、大幅にカスタマイズしたターゲットの作成と管理が可能です。たとえば、ユーザーが変更してしまったポリシーを含むシステムにセキュリティ ポリシーを展開して、社内のローカル セキュリティ ポリシーを強制的に適用することができます。また、未承認のローカル ユーザー アカウントを無効にし、無関係なローカル管理者を削除することもできます。
もちろん、クライアント システムに関する詳細情報のタイムリーな取得も SMS に依存します。インベントリ機能を拡張すれば、既定のインベントリだけに依存している場合には使用できないカスタム情報を完全に含むレポートを作成できます。また、情報を非常に細かくすることができます。たとえば、特定のサーバー ファームを指す特定のレジストリ キーがあるシステムの数を含むレポートを作成できます。管理者はこのレポートを使用して、ある特定の時点に各ファームを指すクライアントのおおよその数を査定できます。同様に、セキュリティ チームは、ネットワーク上のどのシステムでスパイウェアとして知られている特定のプロセスが実行されているかをチェックできます。
MIF ファイルと MOF ファイルの値は、ほぼすべてのソースからの入力情報に少量の変換を行って設定できます。情報がテキストベースであれば、MOF ファイルを使って操作し、WMI に配置できます。または、情報を MIF ファイルの形式で収集して、次のハードウェア インベントリ サイクルに送ることができます。インベントリの拡張を実装するには、VBScript または JScript® の知識と、収集対象に関する知識が必要です。収集対象に関する知識だけを考えると、WMI から高度な SQL の知識まで幅広い知識が必要になります。もちろん、収集したデータをレポートする段階になれば SQL の知識が必要になるため、この知識はどのような種類の情報を収集する場合でも不可欠です。

インベントリのしくみ
SMS のインベントリ プロセスには、ハードウェアとソフトウェアの 2 種類があります。ソフトウェア インベントリでは、ファイルの場所、バージョン、サイズ、その他のファイル属性など、ファイルに関する情報のみを収集します。ただし、ソフトウェア インベントリ プロセスを使用してファイルを収集し、サイト サーバーに格納することもできます。
ハードウェア インベントリには、システムに関する一覧の情報が最も多く含まれているので、ハードウェア インベントリの拡張を行うのは容易です。ハードウェア インベントリの情報の大部分は、WMI、レジストリ、およびシステム BIOS から導き出されます。
ハードウェア インベントリは、SMS 2003 のハードウェア インベントリ エージェント サイトの設定で指定されたスケジュールに従って収集されます。収集は、毎分 1 回のように頻繁に行うようにも、数か月に 1 回のようにたまにしか行わないようにも設定できます。通常は、管理上必要な最短頻度で情報を収集することと、ネットワーク、サイト サーバー、管理ポイントまたはクライアントに負担をかけないことのバランスをとります。
ハードウェア インベントリ エージェントが最初にインストールされるときに、sms_def.mof ファイルがコンパイルされます。このファイルには、SMS が最初に収集するすべての情報が含まれます。このファイルをコンパイルすると、ハードウェア インベントリ エージェントに必要なすべての SMS 名前空間と関連クラスが WMI に作成されます。これらのほとんどは、\\.\root\CIMv2\SMS 名前空間に配置されます。インストール後、ハードウェア インベントリ エージェントは、管理ポイントと、最終的にはサイト データベースに送られる情報をビルドするために、これらのクラスの大部分を調べます。

MIF ファイル
ハードウェア インベントリ エージェントは、これらの WMI クラスから情報を取り出すだけでなく、NOIDMIF と IDMIF の各コレクション フォルダにある MIF ファイルを探します。エージェントはこれらの場所で MIF ファイルを見つけると、これを処理し、次回のハードウェア インベントリに渡します。
MIF ファイルを使用して、SMS ハードウェア インベントリを容易に拡張できます。MIF ファイルには、NOIDMIF ファイルと IDMIF ファイルの 2 種類があります。これらのファイルは静的な XML に似たファイルで、ユーザーが SMS データベースに格納できるほぼすべての情報を含めることができます。このファイルは、通常のテキスト ファイルの作成に使用する任意の手段で作成できます。したがって、ほとんどのスクリプト言語や手作業でも作成できます。
一般に、レジストリや WMI に情報が含まれていない場合や、情報を手動で入力する必要がある場合に、MIF ファイルを使用します。たとえば、ハードウェア展開チームが新しいシステムを提供するときに、このようなファイルを作成できます。展開担当の技術者は、システムの HTML アプリケーションに移動して、資産管理データベースの更新に使用するすべての資産情報を入力できます。その後、このアプリケーションによって NOIDMIF ファイルが動的に作成されるので、このファイルを NOIDMIF ファイル コレクション フォルダにダウンロードできます。この NOIDMIF ファイルには技術者が入力したすべての情報を保持できます。このファイルは、SMS データベースに組み込まれます。
NOIDMIF ファイルと IDMIF ファイルには、わずかな違いしかありません。IDMIF ファイルには一意のヘッダーがあり、このヘッダーでアーキテクチャ情報と一意 ID が提供されます。IDMIF ファイルを使用して、システム デバイス以外を独自のエンティティとして、SMS に組み込むことができます。たとえば、スクリプトを使用して SMS にシステム (実際にはプリンタ) を作成し、そのシステムに関する情報を SMS データベースに書き込むことができます。
NOIDMIF ファイルと IDMIF ファイルは、レジストリ キーで指示された標準の場所に格納されます。SMS エージェントが既定の場所にインストールされていると仮定すると、ほとんどの場合、この場所は %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF および ...\IDMIF になります。エージェントが独自の場所にインストールされた場合、MIF ディレクトリは %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF および ...\IDMIF です。これらのディレクトリの場所がわからない場合は、次のレジストリ キーで一覧された場所を検索できます。
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
MIF ファイルは、収集するファイルとは無関係に、常に、同じ形式です。図 1 に示す MIF ファイルを見ると、複数のグループと各グループに 1 つの属性を含む 1 つのコンポーネントでファイルが構成されていることがわかります。セクションはすべて必須ですが、必ずしも複数のグループや属性エントリを含める必要はありません。MIF ファイル内の各グループは、ハードウェア インベントリの名前付きセクション内のデータの行、グループ内の各属性はその行の列と見なすことができます。
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
図 2 に示すサンプル LocalAdmin.vbs は、非常に単純な VBScript です。このスクリプトでは、NOIDMIF ディレクトリを検索し、一時 MIF ファイルが存在すればそれを削除します。次に、一時 MIF ファイルを作成し、簡単な WMI クエリを再帰的に呼び出して収集した情報をファイルに書き込みます。その後、NOIDMIF フォルダに存在する MIF ファイルを削除してから、最後に一時 NOIDMIF を NOIDMIF コレクション フォルダに移動します。
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
MIF ファイルを使用して、SMS ハードウェア インベントリを容易に拡張できますが、このファイルを使用する場合に考慮する問題がいくつかあります。MIF ファイルは、ハードウェア インベントリの各サイクルで処理されます。ただし、これらのファイルは作成、収集、分析が行われてから最後にインベントリに格納されるため、MIF に含まれる情報がインベントリに示されるまで、最大ハードウェア インベントリ 1 サイクル分遅延される可能性があります。つまり、ハードウェア インベントリ サイクルを 1 日に 1 回に設定している場合は、サイト データベース内のデータは最大 2 日前のデータの可能性があります。そのため、MIF ファイルを作成するプログラムを提供するタイミングと、ハードウェア インベントリ サイクルを実行するタイミングを注意深く検討する必要があります。
Contoso 社では、1 日に 1 回深夜にインベントリ サイクルが実行されるものとします。月曜日の午前 1 時に VBScript を実行し、ルートキット スキャナの出力を含む NOIDMIF ファイルを作成します。この出力は深夜に収集され、管理ポイントに報告されます。その後、Contoso 社の SMS 管理者が水曜日の夜半、午後 10 時頃この情報を目にし、45 時間前の情報であることがわかります。このような現象は、SMS の管理者が NOIDMIF ファイルの作成に使用するプログラムを提供するタイミングを考慮しなかったため生じます。

MOF ファイル
MOF ファイルは、MIF ファイルよりも複雑です。さらに、MOF ファイルは WMI に直接情報を入力し、ハードウェア インベントリ エージェントの標準データ収集プロセスの一部になるという、MIF を上回る利点があります。そのため、情報を取得するために何回も VBscript を提供する必要がなく、時間や困難な作業が削減されます。代わりに、コンピュータごとに 1 度 MOF を提供し、コンパイルすることができます。
MOF ファイルには、ハードウェア インベントリの残りの情報と同じ時点の最新情報が含まれるという利点もあります。ハートウェア インベントリ エージェントがサイクルを実行するたびに、毎回 MOF ファイルに詳しく記載されたクラスとプロバイダがクエリされ、すばやく情報が返されます。すぐに情報が必要な場合は、MOF ファイルと VBScript を含むパッケージを実行して、ハードウェア インベントリを開始できます。その後、提供したプログラム ポリシー サイクルと同じぐらい短時間に必要な情報が得られます。
MOF ファイルには、既存の WMI クラスと名前空間用の MOF ファイル、既存の WMI プロバイダを備えた追加クラス用の MOF ファイル、および WMI プロバイダのない追加クラス用の MOF ファイルという 3 つの分類があります。
MOF ファイルは 2 つの部分で構成されています。最初の部分は、名前空間定義セクションです。ここで、WMI プロバイダ情報が識別されます。2 番目のセクションには、SMS のレポート属性を含みます。このセクションでは、前述の WML クラスに含まれる情報の検索と処理を行う場所をハードウェア インベントリ エージェントに指示します。MOF ファイルは WMI を直接扱うため、このファイルを操作する予定がある場合は、時間をとって、Microsoft WMI Software Development Kit (SDK) を調べることをお勧めします (詳細については、go.microsoft.com/fwlink/?LinkID=83121 を参照してください)。
MOF ファイルの前述の各分類は、静的ファイルまたは動的ファイルのいずれかにできます。たとえば、システムのビルド担当者、ビルドに使用するサーバー、ビルドの初期バージョン、コンピュータをビルドした日付などに関連する情報を含む MOF ファイルを、企業のビルド プロシージャでコンパイルする場合は、静的な MOF ファイルになります。この情報は更新の必要がないため、情報を直接 MOF ファイルに格納し、mofcomp.exe を使用して WMI にコンパイルします。コンパイルを行ったら、サイト サーバー上の sms_def.mof ファイルにグループとクラス情報を追加して、ハードウェア インベントリ エージェントが調査する領域を拡張する必要があります。
動的な MOF ファイルは、収集した情報を直接 WMI に書き込む代わりに、WMI プロバイダを使用してデータを収集する点を除けば、静的な MOF ファイルと同様です。WMI プロバイダは、アプリケーションやサービスが WMI に情報を直接入力できるプラグインです。このプロバイダは、レジストリ、ファイルの場所、Windows インストーラの情報など、WMI やシステムの他の領域に動的にアクセスできます。
MOF ファイルを使った作業に関して、ハードウェア インベントリを拡張する最も容易な方法は、既に WMI に存在するよりも多くの情報を含むインベントリ カタログを用意することです。これを行うには、sms_def.mof を拡張するか、現在無効になっている追加のレポート クラスをチューニングできます。sms_def.mof ファイルは \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv フォルダにあります。社内のすべてのデバイスが次のコンピュータ ポリシー サイクルで新しい sms_def.mof を取り出し、情報の収集とレポートを開始します。
困難さの点で考えた場合に次に行えるのは、既存の WMI プロバイダを使用しながら新しいクラスを作成する方法です。このアプローチの例を図 3 に示します。この例では、組み込みのレジストリ プロバイダを使用して、ローカル デバイスの HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper にクエリする動的プロパティを備えた CU_Desktop クラスを作成します。クライアントでこの MOF ファイルをコンパイルしてから、SMS_Def_Extension.mof (図 4 参照) に含まれる情報を sms_def.mof に追加する必要があります。このファイルには、SMS がレポートするかどうかに関する情報、グループ名、クラス ID、ハードウェア インベントリ エージェントがレポートする情報を検索するために WMI 内を調べるクラス、および最後に、実際の値を含みます。
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
MOF ファイルには、システムに既定では含まれない WMI プロバイダによって提供される情報にアクセスする機能もあります。このようなプロバイダを使用するには、クライアント システムで MOF ファイルをコンパイルし、sms_def.mof を拡張する前に、まず、WMI プロバイダを配布およびインストールする必要があります。

まとめ
MIF ファイルと MOF ファイルは、情報を迅速かつ大量に収集するのに優れたツールです。これらのファイル形式は、テーブルを直接変更しないで SMS データベースに情報を入力する作業を容易にするフレームワークを提供します。十分な想像力を働かせれば、ほぼすべての情報のインベントリを行い、レポートすることができます。さらに、管理者が重要な情報を積極的に収集するように行動すれば、問題が発生する状況を回避できる可能性もあります。
MIF ファイルと MOF ファイルを理解するには少し時間がかかります。ただし、これらのファイルの使用方法を学習するのに利用できる役立つリソースがあります。初心者であれば、WMI のドキュメントと SDK、および「Systems Management Server 2003 運用ガイド」を参照してください。こうした概念の理解に努めれば、拡張した SMS インベントリ機能への情報の入力に費やす作業を補って余りある情報を収集できることになるでしょう。

Wes Dobry は、フロリダ州オーランドにある大規模ヘルスケア企業にコンサルタントおよびネットワーク管理者として勤務しています。Wes の連絡先は wesdobry@wesdobry.com (英語のみ) です。


 管理: SMS 2003 R2 を使用してソフトウェアのカスタム更新プログラムを展開する
管理 Steve Rachui

SMS 2003 R2 を使用してソフトウェアのカスタム更新プログラムを展開する
概要:
  • SMS 2003 R2 の新しい更新プログラム管理機能
  • カスタム更新プログラム用発行ツール (CUPT)
  • カスタム更新プログラム用インベントリ ツール (ITCU)

自社のシステムの特殊なハードウェアや、基幹業務 (LOB) アプリケーションなどにカスタム更新プログラムを展開する必要がある場合は、Windows Update のような管理された自動処理は利用できません。少なくとも、これまではそうでした。Systems Management Server (SMS) 2003 R2 の登場により
同様の更新プログラム管理機能を使用して、独自のカスタム更新プログラムを展開することができるようになりました。SMS 2003 R2 には、Device Management Feature Pack の更新、Operating System Deployment (OSD) Feature Pack へのリンク、セキュリティ監視の強化をはじめとする数多くの新機能が搭載されています。脆弱性評価用スキャン ツールを利用することで、OS の構成、ユーザー パスワード、IIS および SQL Server™ の構成の弱点などの、潜在的なシステムおよびネットワークの脆弱性を理解することができます。また、SMS 2003 R2 には、カスタム更新プログラム用インベントリ ツール (ITCU)、およびカスタム更新プログラム用発行ツール (CUPT) も含まれています。この記事では、この 2 つのツールに注目して、独自のカスタム更新プログラムの展開を簡単かつ効率的に行う方法をご紹介します。

カスタム更新プログラム用発行ツール (CUPT)
SMS 2003 R2 をインストールして使用するには、クライアントも含め、サイト全体を SMS 2003 Service Pack 2 (SP2) にアップグレードする必要があります。CUPT を使用するには、Microsoft® 管理コンソール (MMC) 3.0 にアップグレードする必要があります。CUPT は SMS サイト サーバーにインストールする必要はありませんが、Windows® XP 以降のバージョンの Windows にインストールし、データベースのホスティング用に SQL Server 2005 を用意する必要があります。SQL Server 2005 が利用可能でない場合は、SQL Server Express Edition をインストールする必要があります。CUPT は、SMS システムにカスタム更新プログラムを登録して管理する際に中心的な役割を果たすツールであり、SMS にカスタム更新プログラムを発行する前に、作成済みのカタログをテストする機能も備えています。
カスタム更新プログラムは、サードパーティ ベンダが自社製ソフトウェア用に提供する更新プログラムと、特定の環境用に独自に作成された社内用更新プログラムの 2 種類に分けられます。CUPT は、この両方の種類の管理に使用することができます。手順が簡単なサードパーティ製カスタム更新プログラムの場合から説明します。この記事の執筆時点では、SMS による適切な修正プログラムのスキャンおよび配布のために使用できる更新プログラム カタログを Adobe、1E、および Citrix の 3 社が提供しています。参加している企業は、図 1 に示すように、カスタム更新プログラムのパートナー カタログを選択することにより表示できます。
図 1 実行中の CUPT
図 1 実行中の CUPT (画像を縮小するには、ここをクリックします)
図 1 実行中の CUPT
図 1 実行中の CUPT (画像を拡大するには、ここをクリックします)
パートナー提供の更新プログラムを使用するには、カタログをダウンロードして SMS に追加するだけです。まず、必要な更新プログラムをダウンロードして、[操作メニュー] から更新プログラムをインポートするオプションを選択します。ウィザードにより、ダウンロードした .cab ファイルの場所を入力するよう求められます。このウィザードを完了すると、新しい更新プログラムが CUPT に表示され、構成や SMS サイト サーバーへの発行を行うことができるようになります。必要な各更新プログラムを発行するには、フラグを設定する必要があることに注意してください。フラグの設定されていない更新プログラムは、発行の要求が行われても対象には含まれません。図 2 に示すように、フラグの設定はまとめて行うことができます。更新プログラムを発行するには、右端の列のフラグが設定されている必要があることに注意してください。
図 2 発行のフラグを設定する
図 2 発行のフラグを設定する (画像を縮小するには、ここをクリックします)
図 2 発行のフラグを設定する
図 2 発行のフラグを設定する (画像を拡大するには、ここをクリックします)
ダウンロードした更新プログラムは、必要に応じてさらにカスタマイズすることができます。カスタマイズを行うには、更新プログラムを選択し、[編集] を選択します。ただし、不適切な構成を行うと予期しない問題の発生につながるので注意が必要です。
更新プログラムにフラグを設定したら、発行の準備は完了です。外部の .cab ファイルに発行して後で使用することも、選択した更新プログラムを SMS サイト データベースと同期してすぐに使用することもできます。SMS サイト データベースと同期するには、サイト サーバー名やパッケージのソース パスなどの構成情報を入力する必要があります (図 3 を参照)。
図 3 同期に必要な情報
図 3 同期に必要な情報 (画像を縮小するには、ここをクリックします)
図 3 同期に必要な情報
図 3 同期に必要な情報 (画像を拡大するには、ここをクリックします)
このダイアログ ボックスは、[カスタム更新プログラム] ノードを選択して、[操作メニュー] から [設定] を選択することにより表示できます。アクセス可能なサイト サーバー名と、カスタム更新プログラム用インベントリ ツールのソース ディレクトリのパスを入力すると、サイトのコードと状態が更新されます。
同期のオプションを設定したら、CUPT を使用して SMS サイト サーバーと同期することができます。同期は、[操作メニュー] から [更新プログラムの公開] オプションを選択して実行します。これにより、公開ウィザードが開始されます。更新プログラムを SMS データベースに公開してすぐに使用するには、必ず Systems Management Server サイト データベースとの同期のオプションをオンにします。幸いにも、この手順は画面の表示内容により確認することができます。同期の設定が構成されていない場合、このオプションは灰色表示されます。
このウィザードを完了すると、カスタム更新プログラムは SMS 管理コンソールから操作できるようになります。ソフトウェアの更新の配布ウィザードを開始すると、利用可能な任意のカスタム更新プログラムを処理することができます。
サードパーティ製品用のベンダ提供更新プログラムを登録して使用する処理をひととおりご紹介しましたが、ベンダ提供のソフトウェアにパッケージ化された更新プログラムが用意されていない場合はどうなのでしょうか。このような場合にこそ CUPT の出番です。CUPT を使用すれば、ほとんどすべての状況に対応する完全なターゲット ルールを備えたカスタム更新プログラムを作成することができます。
カスタム更新プログラムの作成は難しくはありませんが、管理者はソフトウェアの更新方法、更新プログラムが適用可能かどうかを判断するための条件、更新の対象を決定するためのターゲット ルールを理解していることが必要です。ターゲット ルールは、更新プログラムの作成処理とは独立して定義されます。ターゲット ルールは、[操作メニュー] から [規則の管理] オプションを選択することにより表示できます。
カスタム更新プログラムの作成は、[操作メニュー] の [更新プログラムの作成] を選択することにより開始します。これにより、カスタム更新プログラムの詳細を入力するためのウィザードが起動されます。カスタム更新プログラムの作成に関する詳細については、この記事では扱いませんが、インポート済みのサードパーティ製カスタム更新プログラムのプロパティを検討してみると、独自の更新プログラムを作成する際に、各フィールドで何が要求されているのかを理解するのに役立ちます。図 4 に、構成済みサードパーティ製更新プログラムのプロパティを示します。
図 4 サードパーティ製更新プログラムのプロパティ
図 4 サードパーティ製更新プログラムのプロパティ (画像を縮小するには、ここをクリックします)
図 4 サードパーティ製更新プログラムのプロパティ
図 4 サードパーティ製更新プログラムのプロパティ (画像を拡大するには、ここをクリックします)
カスタム更新プログラムの作成処理を使用すると、クライアント システムに配布するソフトウェアの構成などの、更新以外の処理も行うことができます。ただし、可能であるからといって、こうした処理は、推奨される方法でも CUPT の正しい使用法でもないことに注意する必要があります。

カスタム更新プログラム用インベントリ ツール (ITCU)
ITCU は、カスタム更新プログラムのカタログを処理できる新しいインベントリ ツールです。前身のスキャン ツールと同様に、ITCU は、カスタム コレクション、パッケージ、および企業の SMS クライアントにスキャン ツールを展開するために使用される提供情報を作成します。以前のスキャン ツールとまったく同様に、ITCU はアクセス可能な SMS の配布ポイントからカタログ (この場合はカスタム更新プログラムのカタログ) を取得し、カタログ データに基づいてスキャンを実行し、そのスキャン結果を Windows Management Instrumentation (WMI) に挿入し、ハードウェア インベントリを介してその結果を報告します。スキャン処理の主な違いは、使用されるカタログです。
SMS 2003 R2 の導入により、既存の SMS セキュリティ機能に強力なツールが追加されます。管理者は、既存の SMS インフラストラクチャを活用して、サードパーティ製アプリケーションおよびカスタム アプリケーションの更新作業を行うことができるようになりました。SMS R2 は、パッチ管理を担当する管理者にとってまさにうってつけの製品です。
これで、2 つのツールを自由に使用して、マイクロソフト製以外のソフトウェアの更新プログラムを処理できるようになりました。CUPT と ITCU が提供する管理のしやすさと便利さは、カスタム更新プログラムの適用を Windows Update 並みにスムーズにしてくれることでしょう。
更新プログラム管理に関するリソース
  • TechNet: 更新プログラム管理
  • Web キャスト: IT's Showtime - SMS 2003 R2
  • マイクロソフトのパッチ管理の 10 の法則

Steve Rachui は、マイクロソフト Product Support Services グループに所属する Manageability Support Escalation Engineer です。バージョン 1.2 のころから SMS のサポートを担当しています。Steve の連絡先は steverac@microsoft.com (英語のみ) です。


 編集者から: 間違えた場合は...
編集者から
間違えた場合は...

印刷と Web の主要な違いの 1 つ は、印刷したものは永遠に存在するということです。Web の場合、ちょっとした情報を Web 上に掲載し、後で更新する必要が出てきたら、変更が必要な部分を変更すればいいのです。だれも気付きません。
当然ながら、印刷は別の代物です。一度印刷に回すと、もう後戻りはできません。10 万を超える印刷物が出回ると、ページの内容がどんなものであっても、いつまでも (または次に引越しするまで) 書庫に存在することになります。また、印刷物は月の移り変わりを感じさせてくれ、当然ながら最新号に最新のニュースや記事が掲載されます。
今のところ、私たちは雑誌を発行したら、雑誌の内容をそのままオンライン上にも掲載しています。しかし、これにより、新たな問題が発生しています。オンライン検索を行う人から見ると、Web サイト上のすべてのコンテンツは同時に存在します。では、最新のガイダンスを参照しているかどうかを知るにはどうすればよいのでしょうか。
この問題を解決するため、私たちは数年前に訂正ポリシーを策定しました。このポリシーは、印刷物を独自に改良して、読者がその内容をオンラインで参照できるようにするものです。TechNet Magazine の訂正ページを見ると、発行後に記事に加えたすべての変更が公開されていることがわかります。情報を更新する際は、技術上、編集上、新情報、期限切れ、およびセキュリティという 5 つの理由の 1 つを明記しています。
たとえば、2006 年 5 月に公開した記事「デスクトップ イメージの作成を簡略化するための手法」では、CNIC というツールについて説明しましたが、その時点ではまだ入手できませんでした。CNIC を入手できるようになったときに、訂正ページに更新情報を追加し、オンラインで公開されている記事に更新情報に関する記述を追加しました。この更新情報に関する記述へのリンクをクリックすると、新しい情報に移動します。
紙媒体の TechNet Magazine も毎月新しい号が発行されていますが、訂正ポリシーによって、時間が経っても記事を適切な内容に保てるようにしています。-JOSHUA TRUPIN

次のマイクロソフト技術支援スタッフに心より感謝します。Luis Botero、Derek Del Conte、John Doyle、David Feldman、Scott Hinsley、Jesper Johansson、Brian Mohr、Michael Murgolo、John Orefice、Mark Russinovich、Matt Steele、Fergus Stewart、Jason Stolarczyk、Jim Truher、Alan von Weltin


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

ファイルおよびディレクトリの同期
Allway Sync
allwaysync.com

どの IT 関連の仕事でも、ファイルやディレクトリをある場所から別の場所に移動する作業には時間がかかる場合があります。これは、デスクトップから USB キーに移動する場合でも、ネットワークを経由してサーバーからサーバーに移動する場合でも同様です。多くの場合、それらのディレクトリの同期を維持することにより、重複した不要なファイルを削除したり、ファイルを最新版にしたりすることが重要です。複数の Web サーバーに静的な XML ファイルや HTML ファイルを展開するときなど、複数のコンピュータ間でファイルやディレクトリを同期する必要が生じる場合があります。Usov Lab の Allway Sync は、このような作業に役立つツールです。
Allway Sync は、ファイルおよびディレクトリの一方向のレプリケーションから、複数ディレクトリや双方向のオプションまで、真の多方向の同期を提供します。このアプリケーションは、ローカル ドライブとネットワーク リソースの同期を維持するだけでなく、USB キーや書き換え可能な光学式ドライブなど、リムーバブル デバイスとの自動同期もサポートします。これらのデバイスがコンピュータに接続されたら自動的に同期を開始するように、Allway Sync を構成することができます。
他にも、ファイルの変更が検出されたとき、ログインまたはログアウトしたとき、Allway Sync が起動したとき、指定した時間が経過したときなどに、同期を自動的に開始できます。また、アプリケーションの GUI を使用して、スケジュールされたタスクの実行時に同期を取るように設定することもできます。
Allway Sync を使用したファイルおよびフォルダの同期
Allway Sync を使用したファイルおよびフォルダの同期 (画像を縮小するには、ここをクリックします)
Allway Sync を使用したファイルおよびフォルダの同期
Allway Sync を使用したファイルおよびフォルダの同期 (画像を拡大するには、ここをクリックします)
すべてのファイルの変更および削除は、アプリケーションのローカル データベースに記録されます。Allway Sync では、ファイルの完全な削除、ごみ箱や指定したフォルダへのファイルの移動など、変更されたファイルのバージョン管理と競合したファイルの削除を行うための多数のオプションが提供されます。
作業ごとに、複数の包含フィルタまたは除外フィルタを指定することにより、必要なファイルを取得して不要なファイルを無視できます。また、警告やエラーが発生したときの Allway Sync の動作をカスタマイズして、警告やエラーの種類に応じて異なる動作を構成することができます。たとえば、エラーが発生したときに自動的にコピーを再試行したり、自動再試行の回数や再試行間隔を構成することによってネットワークの待ち時間や一時的な接続の問題に対応したりすることができます。
アプリケーションのログ記録の詳細度を構成し、作業に応じた適切な情報を得ることができます。アプリケーションの設定は、XML 形式でインポートおよびエクスポートできるため、継続的なバックアップや別のコンピュータへの転送を容易に実行できます。また、好奇心の強いユーザーにとっては面白い機能だと思いますが、このアプリケーションでは使用状況の統計を表示する簡単なウィンドウ (ヘルプ メニューから使用できます) も提供されます。この便利なツールによって、ファイルの同期が容易になります。さらに、このツールは非常に手頃な価格で利用できます。
価格 : 無料 (個人使用)、29.99 ドル (商用使用)

ネットワークのマップ作成および監視を実行する
LANState Pro
10-strike.com/lanstate

ネットワーク リソースの状態および可用性をすばやく把握することは、事前対応型の IT 運用環境にとってきわめて重要です。問題の発生時には、他のだれよりも先にその問題を把握する必要があります。10-Strike Software の LANState Pro は、便利なネットワーク マップ作成および監視のためのツールであり、Windows® ベースのネットワークに関して、状態をすばやく表示したり、LAN を管理したりするのに役立ちます。
ネットワークを監視するためにこのアプリケーションを起動すると、Network Mapping Wizard (ネットワーク マップ ウィザード) を選択できます。このウィザードを使用すると、特定のネットワークや IP アドレス範囲内をスキャンしてホストを検出できます。必要に応じて、手動でホストを追加できます。一度ネットワーク マップを作成した後は、LANState が、TCP ポートや ICMP ping のチェックなどの構成された状態チェックを自動的に開始します。応答があったホストは色分けされ、応答がなかったホストは灰色で表示されます。その後、マップ内のホストを構成に適した論理グループに分類し、表示要素を変更したり、説明を追加したりすることができます。
LANState Pro を使用した論理ネットワーク グループの作成
LANState Pro を使用した論理ネットワーク グループの作成 (画像を縮小するには、ここをクリックします)
LANState Pro を使用した論理ネットワーク グループの作成
LANState Pro を使用した論理ネットワーク グループの作成 (画像を拡大するには、ここをクリックします)
描画ツールと編集ツールは多少使い勝手が悪いですが、一度マップが完成すれば、それをファイルに保存できるため、マップを再作成する必要はありません。TCP ポートと ICMP ping のチェックに加え、フォルダやファイルが存在するかどうかのチェックや、ファイルのサイズ、リモート ホストのディスクの空き領域などのチェックを、指定した間隔およびタイムアウトに基づいて実行するように LANState Pro を構成できます。ホストを右クリックしたときに表示されるコンテキスト メニューを使用すると、リモート ホストのシステム情報を収集できます。また、経路の追跡を実行したり、ping を送信したり、既定のチェックを実行したり、ネットワーク メッセージを送信したりすることもできます。
表示されるシステム情報には、NIC の MAC アドレスやその MAC アドレスがバインドされた IP アドレスから、ネットワーク共有、サービス、およびローカル アカウントまで、あらゆる情報が含まれています。OS レベルの大部分の情報を取得するには、参照先のリモート システムに対する適切なアクセス許可が与えられていて、そのシステム用のポートが開かれている必要があります。ただし、RPC 呼び出しからでも多くのデータを取得することができます。また、適切なアクセス許可が与えられている場合、リモート ホストの電源をオンにしたりシャットダウンしたりするためのシグナルを送信できます。
価格 : 249.95 ドル (1 ユーザー ライセンスごと)

コマンド ライン スクリプト
ブック レビュー
www.syngress.com

対話型のウィザードと構成用の GUI を使用すると、複雑な作業を大幅に簡略化できます。ただし IT プロフェッショナルは、これらのインターフェイスを使用するとかえって作業時間がかかる場合があり、必ずしも目下の作業に対して十分なきめ細かさや制御が提供されるとは限りません。幸いにも、そのようなきめ細かさが必要なほとんどの制御は、コマンド ライン インターフェイス (CLI) から実行できます。Windows に含まれているツールの使い方に慣れ、コマンド プロンプトをカスタマイズして管理作業を効率化する方法を理解することにより、時間の節約、効率の向上、および制御の正確性の向上を実現できます。Pawan K. Bhardwaj の『How to Cheat at Windows System Administration Using Command Line Scripts』 (Syngress Publishing、2006) は、CLI および OS のユーティリティの習得に役立ちます。
この書籍には、コマンド シェルのカスタマイズ、バッチ ファイルを使用して自動化とバッチ処理を行う方法、およびスケジュールされたタスクを CLI から管理する方法が記載されています。これらのセクションの後、ディスク、ファイル、およびディレクトリを管理するのに役立つ Windows OS のユーティリティに関する説明が続きます。また、DSQuery や DSMod などのディレクトリ サービス コマンドの概要についても記載されています。これらを前の章で学習したバッチ処理のスキルと組み合わせて使用することにより、より大きなディレクトリ構造の管理にかかる時間を大幅に短縮できます。
さらに、Netstat から Pathping まで必要に応じて使用できる Windows ネットワーク コマンドや、TFTP、RSH、RCP などのリモート接続ツールの概要についても説明します。これらのツールも、最初のセクションで学習した、自動化とスケジュールされたタスクに関するスキルと組み合わせて使用すると、生産性を確実に向上させることができます。全体として見ると、この書籍は Windows ユーティリティに関する総合的な参考資料ではありませんが、1 冊持っておくと役立ちます。
価格 : 39.95 ドル (直販)

ハードウェアの信頼性テスト
BurnInTest
passmark.com/products/bit.htm

カスタム PC の運用、クライアント ベースでのハードウェア コンポーネントの更新、高度な管理機能を持つデスクトップの構築などのいずれの作業に関わっている場合でも、新しいコンポーネントをユーザーに提供する前に、それらのコンポーネントの実行時に問題が発生しないかどうかを確認することがきわめて重要です。PassMark Software の BurnInTest を使用すると、指定したコンポーネントに対してさまざまなストレス テストを実行することで、問題が発生しないことを確認してからそれらのコンポーネントを提供できます。
あらゆるソフトウェアのバーンイン テストと同様に、このアプリケーションは、短時間で長時間の動作サイクルのシミュレーションを行うために、選択されたシステム コンポーネントに負荷をかけることでハードウェアを "使い込み" ます。その目的は、システムやデバイスを使い始める前に、隠れたエラーを発見することです。バーンイン テストにより、CPU やグラフィック カード メモリから、ハード ドライブや CD 書き込みソフトウェアまで、あらゆる側面をテストできます。
このアプリケーションは非常に簡単に使用および構成できるため、特定の構成における各コンポーネントの単体テスト用に、負荷サイクルと設定を変更したりすることができます。テスト構成を設定した後、今後の使用のためにその設定を保存できるため、数か月後に同じテストを再度行う必要がある場合、そのテストにかかる時間を短縮できます。
テストごとに負荷サイクルを構成できるため、テストする各コンポーネントに対して 1 ～ 100 の負荷値を設定できます。たとえば、CPU の演算操作を 75% の負荷でテストし、同時にシステム メモリを 90% の負荷でテストできます。また、BurnInTest を分単位または運用サイクル単位で停止するように設定できます。
このアプリケーションでは、ハード ドライブ、フロッピー ドライブ、および光学式ドライブを 20 台まで同時にテストできるため、クライアント環境に展開する前にドライブの一括テストを実行できます。これにより、各システムを個別にテストする必要なく、それぞれの新しいコンポーネントを一度にテストできるため、システム コンポーネントをアップグレードするための時間を大幅に短縮できます。私が気に入っているのは、このプログラムが SMART パラメータを使用したチェックを実行するという点です。
Professional Edition では、USB 2.0、パラレル ポート、およびシリアル ポート用のさまざまなループバック テストがサポートされます (ハードウェア ループバック デバイスは PassMark から購入できます)。このバージョンの BurnInTest は CD または USB キー ドライブから実行できるため、テストするシステムにアプリケーションが与える影響が小さくなり、実行するテストの信頼性が向上します。
価格 : 49 ドル (Professional Edition)、24 ドル (Standard Edition)

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


 SQL に関する Q&amp;A: インデックスの再構築、ディスク キューの長さなど
SQL に関する Q&A
インデックスの再構築、ディスク キューの長さなど
Nancy Michell

質問 - SQL Server のインデックスはどのようにして再構築されますか。DBCC DBREINDEX によってすべてのディスク領域が使用される理由と、そのコマンドが失敗したときにディスク領域が解放されない理由を教えてください。データベースのサイズは 90 GB で、最も大きなテーブルは 70 GB です。
ディスクの空き領域を 10 % 残して DBCC DBREINDEX を実行すると、すべての空き領域が使用され、コマンドが失敗します。最初のデータベース ファイルのサイズは 90 GB ですが、DBCC コマンドが失敗するとそのサイズは 160 GB まで増加し、増加分の 70 GB は解放されません。そのため、領域を解放するために何度か手動でデータベースを圧縮する必要があります。
コマンドが成功した場合でも、データベース ファイルのサイズは 160 GB になりますが、領域は自動圧縮によって数時間後に自動的に解放されます。使用される領域を減らすために、DBREINDEX の代わりにインデックスの最適化を実行することはできるでしょうか。クラスタ化インデックスは使用しておらず、単純復旧モードを使用しています。
回答 - 最も単純なレベルでは、インデックスの再構築は、インデックスのコピーを新しく構築して古いインデックスを削除することによって行われます。つまり実質的には、わずかな間、インデックスのコピーが 2 つ存在することになります。新しいインデックスの構築には、元のインデックスと同じサイズのデータベース ファイルの領域が必要になる場合があります。また、再構築で並べ替え操作が必要な場合、並べ替えのためにさらにインデックス サイズの 20 % の領域が必要になります。
したがって、最悪の場合、インデックスの再構築には古いインデックスの 1.2 倍の空き領域が必要になります。データベース ファイルに十分な空き領域がない場合、操作の進行に伴ってファイルを拡張する必要があります。自動拡張が無効になっていたり、ディスク ボリュームに十分な空き領域がない場合、空き領域の不足によって再構築操作が失敗する場合があります。
操作が失敗したかどうかにかかわらず、再構築操作の完了後、データベース ファイルに新しく割り当てられた領域は解放されません。その領域は、通常のデータベース操作に使用されることが想定されます。
(手動または自動で) 圧縮を実行すると、そのアルゴリズムのしくみが原因で、ほぼ確実にインデックスの断片化が発生します。詳細については、「SQL Server ストレージ エンジン」を参照してください。特に自動圧縮は、データベースが通常の操作に空き領域を必要とする場合、パフォーマンスに悪影響を与える可能性があります。これは、自動拡張と自動圧縮の繰り返しにより、断片化が大量に発生し、パフォーマンスが大幅に低下する可能性があるためです。
DBCC INDEXDEFRAG (または SQL Server™ 2005 の ALTER INDEX REORGANIZE) を使用すると、追加のデータベース ファイルの領域がほとんど使用されないというメリットがあります。ただし、インデックスの再構築よりも時間がかかり、より多くのトランザクション ログが生成される場合があります。DBCC INDEXDEFRAG では、使用する復旧モードの種類にかかわらず、常に完全ログ記録が行われます。一方、単純復旧モードでインデックスを再構築した場合、一括ログ記録が行われます。それぞれの方法にはさまざまな長所と短所があります。詳細については「SQL Server 2000 インデックスの最適化に関するベスト プラクティス」を参照してください。
断片化の解消方法を決定する前に、まず、断片化を解消するかどうかを決定します。インデックスが使用される操作の種類によっては断片化がパフォーマンスに影響を与えないことがあるため、その場合は断片化の解消によってリソースが浪費されます。詳細は、上記のホワイト ペーパーに記載されています。
結論ですが、使用中の環境に最も適した断片化の解消方法を選択し、その断片化の解消がクエリのパフォーマンスの向上に役立つことを確認してください。

質問 - SQL Server 2005 の 2 つのインスタンス間でデータベース ミラーリングを正しく構成しました。アプリケーションは、SQL Server ログインを使用して SQL Server に接続しています。また、このアプリケーションは ADO および SQL Native Client を使用して構築されています。接続文字列と接続設定には、適切なフェールオーバー パートナーなどの正しい情報が指定されています。また、プリンシパル サーバーに存在するものと同じログインをミラー サーバーに作成しました。データベース障害のテストを行うと、ミラー サーバーにプリンシパル ロールが正しく割り当てられ、SQL Server インスタンスが正常に機能しているように見えます (Windows® ログインを使用してミラー サーバーに接続することもできます)。ところが、アプリケーションを再接続すると、接続に失敗し、次のエラー メッセージが表示されます。
Cannot open database "<db name>" requested by the login. The login failed.
ログインが新しいプリンシパル データベース (ミラー データベース) のユーザーに関連付けられていないようです。このデータベースのユーザーとログインの同期を取るために sp_change_users_login を実行すると、複数の不明なユーザーが解決されたことを示すメッセージが表示されます。その後、アプリケーションは新しいプリンシパル サーバーに正常に再接続できます。何回かフェールオーバーを試行しましたが、毎回同じ動作が確認されます。つまり、ログインとユーザーの関連付けが行われません。
この問題が発生しないように、ミラーリングの設定を構成する方法はありますか。
回答 - はい、あります。この問題は、各サーバーの SQL Server ログインの名前が同じでも、セキュリティ識別子 (SID) が一致していないことが原因で発生します。Windows ドメイン ユーザー ログインや Windows ドメイン グループ ログインの場合、この問題は発生しません。これらのログインの SID は、ユーザーまたはグループが属するドメインの SID を基に作成されるため、ユーザーまたはグループがどの SQL Server に追加されるかに関係なく、同じユーザーまたはグループの SID は一致します。
sp_change_users_login による同期操作を不要にするには、プリンシパル サーバーのログインと同じ名前および同じ SID を持つ SQL Server ログインをミラー サーバーに作成する必要があります。これを行うには、次に示すように、ミラー サーバーにログインを作成するときに、CREATE LOGIN ステートメントで SID を指定します。
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
各ログインの SID は、プリンシパル サーバーの sys.sql_logins カタログ ビューに照会することによって取得できます。図 1 は、特定のサーバーに SQL Server ログインまたは Windows ログインを実際に作成するための CREATE LOGIN ステートメントを生成するクエリの例です。
Figure 1 CREATE LOGIN ステートメントの生成 (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

質問 - ディスク キューの長さの平均はどれぐらいにすればよいでしょうか。たとえば、RAID 01 で構成されたストレージ エリア ネットワーク (SAN) に 20 個の物理スピンドルが含まれている場合、ディスク キューの長さの平均はどのようにして計算すればよいでしょうか。Avg. Disk Queue Length の 20 分の 1 ですか、それとも Avg. Disk Queue Length の 2 分の 1 ですか。
回答 - まず、SAN 環境のディスク キューの長さの平均を把握することに時間を浪費する前に、ディスク待ち時間を確認しましょう。ただしそれも、何を検討しようとしているかによって異なります。理由はすぐにわかります。
(パフォーマンス モニタの) このカウンタの説明は、"サンプリング間隔中に選択したディスクのキューに入った読み取りおよび書き込み要求の数の平均値です" となっています。このカウンタは物理ディスク カウンタでも論理ディスク カウンタでもありますが、カウンタの値は、基になるストレージがどのようにしてオペレーティング システムに提示されるかによって異なります。
では、今回の状況について考えてみましょう。RAID 01 構成に 20 個のスピンドルがあるということですが、この構成ではストライプ化が行われた後ミラー化が行われます (01 または 10 の解釈によっては、ミラー化が行われた後ストライプ化が行われます)。このストレージ アレイで重要なのは、ストライプ セットに 10 個のスピンドルが含まれるということです。
ただし、これだけでは、ストライプのサイズ、書き込みのサイズ、発行する I/O の種類 (読み取り、書き込み、順次、またはランダム) などの基本的な情報がわかりません。
ここではこれらの情報を無視することにし、Avg. Disk Queue Length が 10 だとすると、OS はディスク アレイに対する 10 個の I/O をキューに入れたことになります。理論的には、ストライプ内のミラー化された 10 個のセットにそれぞれ 1 個ずつ I/O が行われるか、10 個すべての I/O が 1 個のディスクに対して行われるかのいずれかです。どちらになるかを知る方法はありません。
ここで、不足している情報が必要になります。それではストライプのサイズが 64 KB、書き込みサイズが 8 KB で、一連の順次書き込みを実行するとしましょう。これは、SQL Server のストレージ操作では一般的なシナリオです。この場合最も考えられるのは、8 個の I/O までが 1 番目のディスクに対して行われ、次の 2 個の I/O が 2 番目のディスクに対して行われる可能性です。そのため、このシナリオで各ディスクのディスク キューの長さを考えると、アレイ内の 1 番目のディスクが 8、2 番目のディスクが 2、残りの 8 個のディスクが 0 になります。
ではシナリオを変更し、理論的なストライプのサイズが 8 KB、書き込みブロックのサイズが 64 KB、ディスク キューの長さが 10 とします。この場合、64 KB のブロックは 8 個のディスクに分散されるため、1 個の I/O は 8 個のディスクに書き込まれます。つまり、キューに入った 10 個の I/O は、アレイの 10 個のディスク全体に合計 80 回のディスク書き込みとして行われます。アレイのディスクごとのディスク キューの長さを計算する場合、それぞれ 8 となります。
現実的に考えて、別のレベルの不確定要素をシナリオに追加しましょう。ほとんどの場合、SAN ストレージは、サーバーの 1 つ以上の HBA、HBA を SAN に接続するための多数のファイバ、SAN のフロント エンドの多数のポート、およびサーバーと SAN との間のファブリックのファイバ スイッチを使用してサーバーに接続されます。また、SAN 内のバスの内部アーキテクチャと、ディスクが SAN 前部のポートに接続される方法もかかわってきます。
I/O がキューに入れられたことがパフォーマンス モニタで報告されるということは、長い待ち時間が発生しているか、OS がディスク キューの長さを測定してから I/O がディスクに書き込まれるまでに、I/O がキューに入れられている可能性があります。ディスク キューの長さの平均ではなく、待ち時間を確認してそのカウンタを基に判断を行う必要があるのはこのためです。

質問 - トランザクション レプリケーションを使用しており、サブスクライバでテーブル内の多数の行が手動で変更されたため、パブリッシャがサブスクライバに存在しない行を更新しようとするとエラーが発生します。
レプリケーションで、スナップショット全体を再適用するのではなく、パブリッシャからこのテーブルの再初期化のみを実行する方法はありますか。tablediff ユーティリティについて調べたところ、目的の操作に適しているようですが、このユーティリティとレプリケーションはどのような関係がありますか。
たとえば tablediff は、パブリッシャのテーブルのスナップショットを、それと同じ時点のサブスクリプションのテーブルと比較しますか。tablediff ユーティリティを使用するときは、データの一貫性を保つためにレプリケーションを停止する必要がありますか。また、他に何か気を付けることはありますか。
回答 - まず、tablediff は、パブリッシュまたはサブスクライブするテーブルのスナップショットを使用しません。この特定のシナリオに関しては、考えられるシナリオが 2 つあります。
1 つは、レプリケーションを一時的に停止して tablediff ユーティリティを実行する方法です。ユーザーがデータを変更する可能性がある場合は、-sourcelocked パラメータおよび -destinationlocked パラメータを使用できます。これらのパラメータによって、ユーティリティの実行中、両方のテーブルに排他ロックがかけられます。この方法を使用できない場合は、レプリケーションを実行したまま -rc パラメータおよび -ri パラメータを使用します。この方法では、tablediff を一度実行し、エラーが検出された場合、再度 tablediff を実行して、レプリケーションの反映が遅れたことが原因で発生したエラーを解決します。ただし、レプリケーションの遅延時間によっては、サブスクライバで変更されたすべての行が必ずしも検出されない場合があることに注意してください。

次の Microsoft IT 技術支援スタッフに心より感謝します。Sunil Agarwal、Chad Boyd、David Browne、Gilles Comeau、Emmanuel Dreux、Amanda Foote、Matt Hollingsworth、Paul Mestemaker、Uttam Parui、Paul Randal、Dennis Tighe、Steven Wort。


 ユーティリティ スポットライト: Autoruns
ユーティリティ スポットライト
Autoruns
Lance Whitney
この記事で使用しているコードのダウンロード: Autoruns (490KB)

Windows® が実行されている一般的な PC では、起動時に、ファイル、ドライバ、タスク、サービスなど大量の項目を読み込みます。起動時の競合のトラブルシューティング、自動起動シーケンスでのマルウェアの追跡、Windows の起動時間の短縮、メモリやシステム リソースの解放などを行うため、ある時点で、特定のスタートアップ項目を表示し、おそらくは無効にすることが必要になるでしょう。
システム構成ユーティリティ (msconfig.exe) では、スタートアップ ファイルとスタートアップ サービスの多くを表示して無効にすることはできますが、ツール バー、ブラウザ ヘルパー オブジェクト、Windows エクスプローラのシェル拡張など、見つからない項目が多数あります。さらに、msconfig ではこれらの項目に関する詳細の多くが共有されません。起動時に読み込む項目をすべて表示および管理するための優れた方法については、Sysinternals 社の Autoruns をご覧ください。
Autoruns は、Mark Russinovich 氏と Bryce Cogswell 氏が作成したもので、Windows ベースの PC 上のすべてのスタートアップ項目 (イメージとも呼ばれています) を明らかにする無償のユーティリティです。スタートアップ フォルダ、レジストリ、非表示にしておきたいその他の領域に保存されているすべてのイメージを表示できます (図 1 を参照)。
図 1 Autoruns を使用したスタートアップ項目の表示
図 1 Autoruns を使用したスタートアップ項目の表示 (画像を縮小するには、ここをクリックします)
図 1 Autoruns を使用したスタートアップ項目の表示
図 1 Autoruns を使用したスタートアップ項目の表示 (画像を拡大するには、ここをクリックします)
Autoruns には、各イメージの名前と場所が表示されます。ファイルの場合はディレクトリ パスが表示され、レジストリ エントリの場合は正確なキーが取得されます。また、発行元の名前や、項目のバージョン データに基づく簡単な説明も提供されます。エントリをダブルクリックすると、そのディレクトリまたはレジストリ キーに移動します。右クリックした場合は、複数のオプションが含まれたポップアップ メニューが表示されます。オプションには、完全なバージョン情報が提供される標準のファイルのプロパティ ウィンドウを表示する [Properties] (プロパティ) コマンドなどが含まれています。[Option] (オプション) メニューの [Include Empty Locations] (空の場所を含める) を選択すると、PC のスタートアップ領域がすべて表示されます。その領域にエントリがあるかどうかは関係ありません。また、PC 上の他のユーザー アカウントを選択して、スタートアップ環境を参照することもできます。
[Verify] (検証) コマンドを使用してエントリのデジタル署名を確認できます。このコマンドは、証明書失効リスト (CRL) を使用して Web サイトを照会し、イメージがデジタル署名かどうか、および署名が有効かどうかを判断します。[Option] (オプション) メニューの別のオプション [Hide Signed Microsoft Entries] (マイクロソフトの署名済みエントリを非表示にする) を選択すると、マイクロソフトによって既に署名されているエントリは除外されるので、サードパーティのイメージに着目することができます。
スタートアップ項目全体の一覧をテキスト ファイルにエクスポートできます。このファイルは、何らかの項目を無効にする場合や、スタートアップ環境をカスタマイズする前に環境のスナップショットが必要な場合に役立ちます。その後、エクスポートしたテキスト ファイルと変更後のスタートアップ構成を比較して、変更点を理解できます。
以下に、Autoruns に含まれているスタートアップ カテゴリをいくつか示します。
Logon (ログオン) 現在のユーザーとすべてのユーザーのスタートアップ フォルダや、レジストリに存在する Run キーが含まれます。
Explorer (エクスプローラ) エクスプローラのシェル拡張、ツール バー、アクティブなセットアップの実行の一覧が含まれます。
Internet Explorer (Internet Explorer) ブラウザ ヘルパー オブジェクト、および Internet Explorer® のツール バーと拡張機能が含まれます。
LSA Providers (LSA プロバイダ) ローカル セキュリティ機関の認証パッケージ、通知パッケージ、およびセキュリティ パッケージが含まれます。
Autoruns では、スタートアップ項目を完全に削除することや、スタートアップ項目を単に無効にすることができます。[Search Online] (オンラインの検索) オプションを使用すると、無効にしても安全な項目を検索できます。このオプションでは、項目やそのカテゴリが説明されている Web ページのインターネット検索が実行され、スタートアップから項目を削除するかどうかのアドバイスが提供されます。項目を無効にすると、その項目は Autoruns によってレジストリ内またはハード ドライブ上のバックアップ場所に移動されます。
Autoruns は Windows XP 64-bit Edition や Windows Server® 2003 64-bit Edition など、すべてのバージョンの Windows で動作します。microsoft.com/technet/technetmag/code07.aspx から入手してください。

Lance Whitneyは、IT コンサルタントであり、トレーナーであり、テクニカル ライターでもあります。Windows のワークステーションおよびサーバーをカスタマイズすることに数えきれないほどの時間を費やしてきました。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


 The Cable Guy: Windows Vista 用ワイヤレス グループ ポリシーの設定
The Cable Guy
Windows Vista 用ワイヤレス グループ ポリシーの設定
Joseph Davies
このコラムには、Windows Server のコードネーム "Longhorn" のプレリリース情報が含まれています。この記事のプレリリース情報は変更される可能性があります。

Active Directory ネットワーク内のすべてのコンピュータに対し、ワイヤレス ネットワーク設定を集中的に構成および配布することができれば、管理者の作業は多少軽減されることでしょう。幸いにも、Windows はコンピュータ構成用の特別なグループ ポリシーの拡張機能をサポートしているので、管理作業の軽減を実現できます。これは
ワイヤレス ネットワーク (IEEE 802.11) ポリシー拡張と呼ばれる拡張機能であり、Windows Vista™、Windows® XP、Windows Server® 2003、および次期バージョンの Windows Server (コード名 "Longhorn") を実行するコンピュータでサポートされます。
この機能がどのように動作するのかを説明します。これらのオペレーティング システムでは、ドメインへの参加時、または起動時に、このグループ ポリシー拡張にワイヤレス設定が自動的にダウンロードされ、適用されます。その後は、この動作が継続的に行われます。ドメイン ベースのグループ ポリシー オブジェクトのワイヤレス ポリシーは、グループ ポリシー オブジェクト エディタを使用して、[コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ワイヤレス ネットワーク (IEEE 802.11) ポリシー] と順に展開したノードで構成することができます。
図 1 に、コード名 "Longhorn" の Windows Server ドメイン、または 802.11Schema.ldf および 802.3Schema.ldf スキーマ拡張ファイルによってスキーマが拡張された Windows Server 2003 ドメインのワイヤレス ネットワーク (IEEE 802.11) ポリシー ノードの場所を示します (詳細については microsoft.com/technet/network/wifi/vista_ad_ext.mspx を参照してください)。
図 1 ワイヤレス ネットワーク (IEEE 802.11) ポリシー ノード
図 1 ワイヤレス ネットワーク (IEEE 802.11) ポリシー ノード (画像を縮小するには、ここをクリックします)
図 1 ワイヤレス ネットワーク (IEEE 802.11) ポリシー ノード
図 1 ワイヤレス ネットワーク (IEEE 802.11) ポリシー ノード (画像を拡大するには、ここをクリックします)
既定では、ワイヤレス ネットワーク (IEEE 802.11) ポリシーはありません。新しいポリシーを作成するには、コンソール ツリーで [ワイヤレス ネットワーク (IEEE 802.11) ポリシー] を右クリックし、[新しい Windows XP ポリシーの作成] または [新しい Windows Vista ポリシーの作成] をクリックします。どのタイプのポリシーも 1 つずつしか作成できませんが、各ポリシーには複数のワイヤレス ネットワーク設定を保存することができます。
Windows XP のポリシー設定は、私の 2003 年 7 月号の記事で説明した手順とよく似ています。ただし、非ブロードキャスト ワイヤレス ネットワーク、Wi-Fi Protected Access 2 (WPA2) 認証方法、および WPA2 認証用の高速移動設定に対し、新たなオプションが用意されています。これらの新しい設定をサポートするには、Windows XP Service Pack 2 (SP2) を実行するコンピュータの場合 support.microsoft.com/kb/917021 から Windows XP SP2 用のワイヤレス クライアント更新プログラムをインストールする必要があります。
Windows Vista のワイヤレス ポリシーには、Windows Vista および Windows Server "Longhorn" のワイヤレス クライアント専用のポリシー設定が含まれています。両方のワイヤレス ポリシーが構成されている場合、Windows XP ワイヤレス クライアントは Windows XP 用のポリシー設定のみを使用し、Windows Vista ワイヤレス クライアントは Windows Vista 用のポリシー設定のみを使用します。Windows Vista のポリシー設定がない場合は、Windows Vista のワイヤレス クライアントは Windows XP の設定を使用します。この記事では、Windows Vista ワイヤレス ポリシーで構成可能な設定について説明します。
Windows Vista ワイヤレス ネットワーク ポリシーの [全般] タブでは、ポリシーの名前と説明の入力、WLAN 自動構成サービスを有効にするかどうかの指定、ワイヤレス ネットワーク プロファイルのリストの作成、およびプロファイルの優先順位の指定を行うことができます (図 2 を参照)。また、プロファイルを選択し、[エクスポート] をクリックすると、プロファイルを XML ファイルとしてエクスポートすることもできます。XML ファイルに保存されたワイヤレス プロファイルをインポートするには、[インポート] をクリックして、ファイルの保存場所を指定します。
図 2 ワイヤレス ネットワーク ポリシーのプロパティ
図 2 ワイヤレス ネットワーク ポリシーのプロパティ (画像を縮小するには、ここをクリックします)
図 2 ワイヤレス ネットワーク ポリシーのプロパティ
図 2 ワイヤレス ネットワーク ポリシーのプロパティ (画像を拡大するには、ここをクリックします)
図 3 は、Windows Vista ワイヤレス ネットワーク ポリシーの [ネットワークのアクセス許可] タブにおける既定の設定を示しています。このタブは Windows Vista で新しく追加されたものであり、ワイヤレス ネットワークを名前で指定し、そのネットワークに対するアクセスを許可または拒否することができます。たとえば、Windows Vista ワイヤレス クライアントが接続を許可されているワイヤレス ネットワーク名 (サービス セット識別子 (SSID) とも呼ばれる) を記載した許可リストを作成することができます。これは、ある組織のノート型コンピュータを、その組織のワイヤレス ネットワークや、インターネット サービス プロバイダなどの特定のワイヤレス ネットワークに接続させたいネットワーク管理者にとって便利な機能です。
図 3 [ネットワークのアクセス許可] タブ
図 3 [ネットワークのアクセス許可] タブ (画像を縮小するには、ここをクリックします)
図 3 [ネットワークのアクセス許可] タブ
図 3 [ネットワークのアクセス許可] タブ (画像を拡大するには、ここをクリックします)
拒否リストでは、ワイヤレス クライアントに接続を許可しない一連のワイヤレス ネットワークを名前で指定できます。これは、管理対象のノート型コンピュータが、範囲内にある他のワイヤレス ネットワークに接続しないようにするのに便利な機能です。たとえば、ある組織がビルの 1 フロアを使用しており、隣接するフロアに別の組織のワイヤレス ネットワークがある場合などです。拒否リストを使用すると、管理対象のノート型コンピュータが、セキュリティで保護されていない既知のワイヤレス ネットワークに接続するのを防ぐこともできます。許可リストまたは拒否リストのいずれかを作成したり、個々のワイヤレス ネットワークに対してアクセスを許可または拒否したりするには、[追加] をクリックしてワイヤレス ネットワークの名前を指定して追加し、許可または拒否のどちらかを設定します。
[ネットワークのアクセス許可] タブには、アドホック モードまたはインフラストラクチャ モードのワイヤレス ネットワークへの接続を防ぐための設定もあります。ユーザーがアクセスを拒否されるように構成されたワイヤレス ネットワークを表示できるようにしたり、任意のユーザーに対してすべてのユーザー プロファイルの作成を許可することもできます。すべてのユーザー プロファイルを使用すると、コンピュータ上にアカウントがある任意のユーザーが、特定のワイヤレス ネットワークに接続できます。この設定が無効になっていると、Network Administrators グループまたは Network Operators グループに属するユーザーのみが、コンピュータ上にすべてのユーザーのワイヤレス プロファイルを作成することができます。

ワイヤレス ネットワーク プロファイルのプロパティ
Windows Vista ワイヤレス ポリシーの [全般] タブからワイヤレス ネットワーク プロファイルを管理するには、既存のプロファイルを選択して [編集] をクリックするか、[追加] をクリックして、新規のワイヤレス プロファイルがアドホック ワイヤレス ネットワーク用であるか、インフラストラクチャ モードのワイヤレス ネットワーク用であるかを指定します。
新規のワイヤレス プロファイルを作成するには、まず [接続] タブでプロファイルの名前を指定し、プロファイルを適用するワイヤレス ネットワーク名のリストを作成します (図 4 を参照)。新しい名前を追加するには、[ネットワーク名 (SSID)] に名前を入力し、[追加] をクリックします。このプロファイルを使用するワイヤレス クライアントがワイヤレス範囲内に入ったときに、プロファイル内に指定されているワイヤレス ネットワークに自動的に接続を試行するかどうかも指定できます (Windows Vista ポリシーの [全般] タブに示される、ワイヤレス プロファイルの優先順位が適用されます)。さらに、より優先順位の高いワイヤレス ネットワークが範囲内に検出された場合に、このワイヤレス ネットワークから自動的に切断するかどうかを指定したり、このプロファイルのワイヤレス ネットワークが非ブロードキャスト ネットワーク (非表示のネットワークとも呼ばれる) であることを指定したりすることもできます。
図 4 [接続] タブ
図 4 [接続] タブ (画像を縮小するには、ここをクリックします)
図 4 [接続] タブ
図 4 [接続] タブ (画像を拡大するには、ここをクリックします)
図 5 に示す [セキュリティ] タブでは、プロファイル内のワイヤレス ネットワークに対して適用される認証方法および暗号化の方法を構成できます。選択できる暗号化の方法は、認証方法によって決まります。その選択肢を図 6 に示します。
Figure 6 セキュリティ メソッド (Close Figure 6)

認証方法
オープン
共有
Wi-Fi Protected Access (WPA) - パーソナル
WPA - エンタープライズ
WPA2 - パーソナル
WPA2 - エンタープライズ
802.1X で開く
暗号化の方法
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Advanced Encryption Standard (AES、高度暗号化標準)
図 5 [セキュリティ] タブ
図 5 [セキュリティ] タブ (画像を縮小するには、ここをクリックします)
図 5 [セキュリティ] タブ
図 5 [セキュリティ] タブ (画像を拡大するには、ここをクリックします)
認証方法として [WPA - エンタープライズ]、[WPA2 - エンタープライズ]、または [802.1X で開く] を選択した場合、ネットワークの認証方法 (拡張認証プロトコル (EAP) の種類)、認証モード (ユーザーの再認証、コンピュータの認証、ユーザーの認証、またはゲスト認証)、認証が中止されるまでの試行回数、および次回接続用にユーザー情報をキャッシュするかどうかも指定できます。ユーザー情報をキャッシュするかどうかの設定では、ユーザーがログオフしたときに、ユーザー資格情報のデータをレジストリから削除することを指定できます。この場合、ユーザーが次回ログオンした際に、資格情報 (ユーザー名とパスワードなど) の入力を求められます。
[WPA - エンタープライズ]、[WPA2 - エンタープライズ]、または [802.1X で開く] の各認証方法に対して高度なセキュリティ設定を構成するには、[詳細設定] をクリックします。図 7 に、[セキュリティの詳細設定] ダイアログ ボックスの既定の設定を示します。
図 7 [セキュリティの詳細設定] ダイアログ ボックス
図 7 [セキュリティの詳細設定] ダイアログ ボックス (画像を縮小するには、ここをクリックします)
図 7 [セキュリティの詳細設定] ダイアログ ボックス
図 7 [セキュリティの詳細設定] ダイアログ ボックス (画像を拡大するには、ここをクリックします)
[IEEE 802.1X] セクションでは、初回の EAP over LAN (EAPOL) 開始メッセージに対する応答がない場合に続けて送信される EAPOL 開始メッセージの数と、先に送信された EAPOL 開始メッセージに対する応答がない場合に EAPOL 開始メッセージを再送信する間隔を指定します。また、認証クライアントが認証システムから認証エラーを受信した後に 802.1X 認証アクティビティの実行を禁止する期間や、エンド ツー エンドの 802.1X 認証が開始された後に 802.1X 要求の再送信を待機する間隔も設定できます。
シングル サインオン (SSO) を使用すると、802.1X 認証をユーザーのログオンと関連付けて実行するよう構成したり、ユーザー ログオンと 802.1X 認証の資格情報を Windows ログオン サーバー上で統合したりできます。[シングル サインオン] セクションには、ユーザー ログオン処理の直前または直後にワイヤレス認証を実行するための設定と、処理開始までの接続遅延時間を秒単位で指定する設定があります。また、認証方法により追加の資格情報の入力が要求される場合に、追加の入力フィールドをユーザーに表示するかどうか、およびこのフィールドを表示する時間、そしてこのプロファイルのワイヤレス ネットワークのコンピュータ認証またはユーザー認証に対し、別の仮想 LAN (VLAN) を使用するかどうかも指定できます。
[高速移動] セクションでは、ペアワイズ マスタ キー (PMK) のキャッシュや、事前認証のオプションを構成できます。[高速移動] セクションは、認証方法として [WPA2 - エンタープライズ] を選択した場合にのみ表示されます。PMK のキャッシュを使用すると、ワイヤレス クライアントとワイヤレス アクセス ポイント (AP) が 802.1X 認証の結果をキャッシュします。これにより、ワイヤレス クライアントが認証済みのワイヤレス AP に戻ったときに、すばやくアクセスすることができます。PMK キャッシュにエントリを保持する最大時間と、エントリの最大数を構成できます。事前認証では、ワイヤレス クライアントは、現在のワイヤレス AP との接続状態を保ちつつ、範囲内にある他のワイヤレス AP に対して 802.1X 認証を実行できます。ワイヤレス クライアントが、事前認証済みのワイヤレス AP に移動した場合に、アクセス時間を大幅に短縮することができます。ワイヤレス AP との事前認証を試行する最大回数も構成することができます。
Windows のワイヤレスのサポートに関する詳細については、microsoft.com/wifi を参照してください。Windows グループ ポリシーに関する詳細については、microsoft.com/gp のリソースを参照してください。

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


 Windows PowerShell: データのフィルタ処理と書式設定を行う
Windows PowerShell
データのフィルタ処理と書式設定を行う
Don Jones

Windows PowerShell は、ユーザーがそれほど多くの作業をしなくても、多くの貴重な情報を返すことができます。このことに疑いの余地はありません。たとえば、単純な Get-WMIObject コマンドレットを考えてみましょう。このコマンドレットを使用すると、ローカル コンピュータ上のサービスの一覧を返すことができます。既定のビューには、実行中のサービスの状態、名前、スタートアップ モードの一覧が表示されます。
このビューは、本質的には、サービス コンソールをコマンド ラインで表示したものです。Windows PowerShell™ により、このビューの取得が非常に容易になります。
ただし、サービスに関して入手できる有用な情報は、既定のビューに表示される内容よりも多く存在します。次のコマンドを実行してみてください。
$s = get-wmiobject win32_service
$s[0] | gm
コマンドの 1 行目からは、すべてのサービス (具体的には、Windows® Management Instrumentation (WMI) の Win32_Service クラスのすべてのインスタンス) のコレクションが返され、$s 変数に格納されます。2 行目は、そのコレクション内の最初のサービス (序数 0 が角かっこ内に示されています) を取得し、Get-Member コマンドレットにパイプ処理します。このコマンドレットは、そのエイリアス gm を使用して略してあります。結果の出力には、そのデータ型に使用できるすべてのプロパティとメソッドが示されます。ここでは、Windows PowerShell の組み込みの Get-Service コマンドレットではなく、WMI の Win32_Service クラスを使用することにしました。実際には、Microsoft® .NET ServiceController オブジェクトよりも WMI の方が、StartName プロパティを含む多くの情報を公開するためです。このプロパティは、サービスの実行に使用されているユーザー アカウントの名前を示します。次のコードを実行すると、1 つのインスタンス (最初のインスタンスなど) の名前を確認できます。
PS C:\> $s[0].StartName
LocalSystem
ただし、コレクション内の序数でサービスを参照しても、サービスは特定の順序になっていないため、あまり役立ちません (サービスは通常、アルファベット順に示されていますが、必ずしもそうとは限りません)。管理の観点からいうと、すべてのサービスの一覧や、各サービスのログインに使用されているアカウントに最も関心を持つことが考えられます。たとえば、これは規程遵守の監査に役立ちます。それでは、少し戻って、WMI が既定で提供しているものを見てみましょう。Get-WMIObject の短いエイリアス gwmi を使用します (図 1 を参照)。
Figure 1 gwmi を使用する (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
これは明らかに単なるサンプルですが、出力が管理用レポートにはまったく適していないことはわかります。知りたいのは、サービスの名前と StartName (サービスの実行に使用されているアカウント) です。また、この少し見た目の悪い一覧ではなく、もっと読みやすい形式のレポートが欲しいと考えています。ここで活躍するのが、Windows PowerShell の強力な書式設定コマンドレットとデータのフィルタ処理コマンドレットです。

必要なデータを取得する
まず、目的のプロパティが表示されるように、Get-WMIObject を使用してデータをフィルタ処理します。この処理を行うには、Windows PowerShell の Select-Object コマンドレットまたはその簡単なエイリアス select を使用することをお勧めします。select は、オブジェクトのコレクション (Get-WMIObject によって返されるコレクションなど) を受け取り、これらのオブジェクトの目的のプロパティだけを表示するように設計されています。つまり、gwmi の出力を select にパイプ処理し、目的の 2 つのプロパティを指定できます。図 2 は結果を示しており、表形式で適切に書式設定された Name プロパティと StartName プロパティが含まれています。
図 2 Name プロパティと StartName プロパティだけを表形式で表示する
図 2 Name プロパティと StartName プロパティだけを表形式で表示する (画像を縮小するには、ここをクリックします)
図 2 Name プロパティと StartName プロパティだけを表形式で表示する
図 2 Name プロパティと StartName プロパティだけを表形式で表示する (画像を拡大するには、ここをクリックします)
ただし、規程遵守の監査についてこのレポートを作成すると、実際に含まれる情報が多すぎる結果になります。一部のサービスは無効になっているため、無効になっているサービスによって理論上使用されているアカウントは、出力を参照するどの人にとっても重要ではないでしょう。したがって、スタートアップの種類、つまり、Win32_Service クラスの StartMode プロパティが Disabled のサービスをすべて除外しようと考えています。
Windows PowerShell では、Where-Object コマンドレットまたはその短いエイリアス where を使用してオブジェクトのフィルタ処理を実行します。where コマンドレットは、入力オブジェクトのコレクションを受け取り、各オブジェクトをスクリプト ブロックで実行し、定義済みの一連の条件に基づいて各オブジェクトがコマンドレットの出力に表示されるかどうかを判断します。条件を満たしている各オブジェクトは、True を返すため、出力に含まれます。False 値を返すオブジェクトは含まれません。
ここでは、StartMode プロパティが Disabled のオブジェクトだけが必要であると判断しました。Windows PowerShell では、その評価は次のようになります。
$object.StartMode –eq “Disabled”
もちろん、$object は単なる例です。実際にスクリプトを書いているわけではないので、$object という変数はありません。ただし、where で使用されているスクリプト ブロック内では、$_ という名前の特殊な変数を使用しています。この変数は、現在コマンドレットで評価されているオブジェクトを表します。そのため、where スクリプト ブロックは次のようになります。
$_.StartMode –eq “Disabled”
これは、次のように簡単にテストできます。
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
もちろん、この簡単なテストでは、出力が既定の一覧形式で表示されます。また、スペースを節約するために、ここではサービスを 1 つだけ含めました。しかし、この出力が適切ではないことに気付くでしょう。無効になっているサービスを除外するのではなく、含めてしまいました。これは、私がスクリプト ブロックを逆に理解したためです。この例は次のように変更することで、StartMode が Disabled ではないすべてのサービスを含める必要があります。
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
これでうまくいくでしょう。これで出力には目的のサービスだけが含まれるので、もう一度出力を select にパイプ処理し、必要なプロパティだけを指定できます。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
あるコマンドレットから別のコマンドレット、さらに別のコマンドレットにデータをパイプ処理するこの作業は、実際には、Windows PowerShell の機能を示しています。スクリプトはまだ作成していませんが、大量のデータ セットをフィルタ処理して、求めている出力だけを取得することができました。

適切な見た目
select の出力が依然としてオブジェクトの集まりであることに注意してください。Windows PowerShell を使用して、適切に書式設定された表を取得すると、本当に PowerShell.exe がこれらのオブジェクトを返すことがわかります。つまり、Windows PowerShell は、単なる人間である私にはオブジェクトが見えないことを理解しているので、オブジェクトをテキストとして描画します。この場合、図 2 に示すように、オブジェクトを、各プロパティの列を含む表として描画しました。
監査目的の場合は、これで十分かもしれません。しかし、十分ではない場合もあります。人によってニーズは異なりますが、Windows PowerShell では特定のニーズを認識することを想定していません。代わりに、出力を最適な形式で書式設定するツールが用意されています。4 つの組み込みのコマンドレット (Format-List、Format-Custom、Format-Table、および Format-Wide) は、オブジェクトのコレクション (select によって返されるコレクションなど) を受け取り、さまざまな方法でこれらのオブジェクトの書式設定を行うように設計されています。Format-Table は、基本的には、Windows PowerShell が select コマンドレットの出力の書式設定に既に使用しているものです。別の見た目を参照するために、Format-List を試してみましょう。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
結果は、次のサンプルに少し似ています。
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Format-Wide コマンドレットは、既定では各オブジェクトの最初のプロパティを示す、複数の列から成る一覧を生成するように設計されています。たとえば、次の行を試してみます。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
この結果、サービス名の一覧が生成されますが、これは求めているものではありません。出力には、監査レポートで必要としている重要な情報である、StartName (図 3 を参照) がありません。
図 3 Format-Wide コマンドレットを使用して表示された出力で重要な情報 StartName が除外されている
図 3 Format-Wide コマンドレットを使用して表示された出力で重要な情報 StartName が除外されている (画像を縮小するには、ここをクリックします)
図 3 Format-Wide コマンドレットを使用して表示された出力で重要な情報 StartName が除外されている
図 3 Format-Wide コマンドレットを使用して表示された出力で重要な情報 StartName が除外されている (画像を拡大するには、ここをクリックします)
プロパティを 2 つしか扱っていないため、Format-Table または Format-List で満足できる可能性があります。ただし、監査担当者が画面上のこの情報を見て喜ぶとは考えられません。 おそらく、監査担当者は何らかのファイルが欲しいでしょう。

データをエクスポートする
では、監査担当者はデータをどのように表示したいのでしょうか。サービスとログイン名の一覧を CSV (コンマ区切り) ファイルに出力すれば、後から Microsoft Excel® で簡単に開くことができるため、満足すると考えられます。CSV ファイルを作成するには、出力を Windows PowerShell Export-CSV コマンドレットにパイプ処理するだけです。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
確かに、現在では、CSV は少し時代遅れのように思えます。おそらく、監査担当者は、データがイントラネット サーバー上の Web ページとして表示されることを望むでしょう。Web ページとして表示するには、まず、ConvertTo-HTML コマンドレットを使用して、出力を HTML に変換します。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
未処理の HTML を表示するのは難しいため、出力をファイルに書き込む必要があります。
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
図 4 に示されている結果は、適切に書式設定された HTML ページです。このページは、それ以上変更せずに、Web サーバー上に投稿できます。
図 4 適切に書式設定された HTML ページとして表示された出力
図 4 適切に書式設定された HTML ページとして表示された出力 (画像を縮小するには、ここをクリックします)
図 4 適切に書式設定された HTML ページとして表示された出力
図 4 適切に書式設定された HTML ページとして表示された出力 (画像を拡大するには、ここをクリックします)

関連のある事実に絞る
Windows PowerShell を使用すると、さまざまな管理データにすばやくアクセスできます。ただし、そのデータが未処理の状態の場合、ビジネスの面で必ずしも役に立つとは限りません。
(where を使用して) データをフィルタ処理し、(select を使用して) 必要なオブジェクトのプロパティを選択し、適切な書式設定オプション (Format-Table や Format-List など) を適用することで、ほとんど手間をかけずに、簡単にこの管理データを有用な情報に変換することができます。その後、簡単に共有できるファイル形式にデータをエクスポートすることで、自分のデスクトップ以外でこの情報を取得し、貴重な情報を組織内の他の人々に伝達することができます。

Don Jones は SAPIEN Technologies のプロジェクトおよびサービスの責任者であり、『Windows PowerShell: TFM』(SAPIEN Press) の共著者でもあります。Don に対するお問い合わせについては、彼の Web サイト (www.ScriptingAnswers.com) を参照してください。


 Hey, Scripting Guy!: 世間知らずがローカル ユーザーとグループに挑戦する
Hey, Scripting Guy!
世間知らずがローカル ユーザーとグループに挑戦する
Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2007_04.exe (151KB)

ファイルとフォルダのセキュリティ記述子を管理する方法はありますか

信じられないかもしれませんが、 もちろん昔は Scripting Guys もそれほど賢くはありませんでした。信じられないでしょう。何ですか。信じられる、しかもそれほど昔のことではないでしょう、ですって。何をおっしゃっているんですか。いいですか、教えてあげましょう。そうですね、皆さんは、先日 Scripting Guys の著者の 1 人が新しい TV を接続しようとしたのを確かに見たでしょう。
この Scripting Guy だけは、新しい TV の取り付けはロケット科学ではないから簡単だと自己弁護しそうですが、実際はロケット科学よりも複雑です。TV の取り付け自体は 3 本のビデオ ケーブルと 1 組のオーディオ ケーブルを配線するだけですが、それに加えてビデオ、DVD プレーヤー、Xbox® などをそこに取り付ける必要があります。また、不規則な数字を "汎用" リモコンに入力して、それらのデバイスをすべて認識できるようにする作業も当然必要です。これに比べれば、人口衛星を火星の軌道に乗せることなど簡単です。
驚くべきことに、この Scripting Guy は何とかすべての接続を正確に行いました。しかし、すべての電源を入れても何も起こりませんでした。彼はきちんと各接続を 2 回も 3 回も確認しました。また、すべてのユーザー マニュアルを読んだり、見落としている情報がないかどうかをオンラインで調べたりもしました。しかし何も得ることはできませんでした。彼が MP3 プレーヤーを電子工学の神にいけにえとして捧げようとしていたそのとき、彼はケーブル ボックスから伸びているケーブルを壁のケーブル差込口に差し込むという重要な手順を行っていなかったことに気が付きました。
注 : この Scripting Guy の家にあるものをすべて接続するのがこれほど大変であるということは、この家は物であふれかえっていると思うかもしれません。実際、この Scripting Guy もそのことは認めるでしょう。しかし、新しいものを買うときの家族投票で、この Scripting Guy はいつも 2 対 0 で敗れてしまいます。読み間違えないでください、2 対 1 ではなく 2 対 0 です。どういうわけか、父親の票はこの家族投票の集計対象になる気配がまったくありません。しかも投票記録も残っていません。
あなたの疑問に対する答えはイエスです。彼は努力しました。しかし今のところ、国連はこの議会に投票監視員を派遣することを拒否しています。
もちろん今考えてみると、Scripting Guys (特に新しい TV を接続した Scripting Guy) は世間知らずでしたが、それほど間抜けだったわけではありません。たとえば、『Microsoft® Windows® 2000 スクリプト ガイド』の計画段階で、この書籍の章を考えるとき、Scripting Guys は多くの専門家の助けを借りました。落選した章の中に、ローカル ユーザーとグループの管理に関する章がありました。専門家は "ローカル ユーザーとグループの管理?" "なぜそんなことを考えるの? ローカル ユーザーとグループのことなんてだれも気にしないよ。" と言いました。
とても悔しいのですが、それ以降多くの人たちが (社内の "専門家" のような例外もありますが) ローカル ユーザーとグループに関心があることがわかりました。毎週、ユーザーをローカル グループに追加する方法、ユーザーをローカル グループから削除する方法、コンピュータのローカル管理者のパスワードを変更する方法などに関する質問が書かれた電子メールが山のように寄せられています。
確かに、スクリプト センターのスクリプト リポジトリにもこれらの作業を行う方法が示されたサンプル スクリプトがいくつかありますが、これらのスクリプトのほとんどは一度に 1 台のコンピュータしか操作しません。これでは不十分です。ユーザーが知りたいのは、この操作を複数のコンピュータに対して同時に実行する方法です。1 台のコンピュータでしかローカル管理者のパスワードを変更できないのですか、ユーザーに聞いてみてくださいよ、Scripting Guy。私たちは所有しているすべてのコンピュータ、OU 内のすべてのコンピュータ、またはすべてのメール サーバーでその操作を行う必要があるのです。おわかりでしょう、と。
スクリプト ガイドが 2003 年に発行されたことを考えると、同じような電子メール メッセージが 4 年近くの間殺到していたということになります。最近 Scripting Guy の 1 人が、"Excel® ワークシートからコンピュータ名を読み取って、各コンピュータのローカル管理者のパスワードを変更する方法を教えてほしいという質問があったよ。どうしたらいいだろう。" と言いました。
4 年間かかりましたが、ついにわかりました。図 1 に示したコードが私たちの成果です。
Figure 1 ようやく完成したコード (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
注 : おわかりのとおり、このスクリプトを記述するのに 4 年かかったのは、記述することが大変だったからではなく、Scripting Guys が何をするのにも時間がかかるからです。ですから、Scripting Guys が毎年大みそかに行うパーティには必ず出席しましょう。次の恒例イベントはいつ行われるか (または行われることがあるのかさえも) わかりませんからね。
ここで紹介するのは、ワークシートからコンピュータ名を読み取って、各コンピュータのローカル管理者のパスワードを変更するスクリプトです。このマジックを行うために、まず簡単なことから始めます。図 2 のような、とても単純なワークシートがあるとします (ない場合は作成してください)。
図 2 変更を加えるコンピュータの一覧
図 2 変更を加えるコンピュータの一覧 (画像を縮小するには、ここをクリックします)
図 2 変更を加えるコンピュータの一覧
図 2 変更を加えるコンピュータの一覧 (画像を拡大するには、ここをクリックします)
ご覧のとおり、特別なものはありません。列 1 (列 A) には、パスワードを変更する必要があるすべてのコンピュータの名前が列挙されています。列 2 (列 B) には、各コンピュータのローカル管理者のパスワードが最後に変更された日時を記録します。これにより、ローカル管理者のパスワードがすべて同期されているかどうかを簡単に把握することができます。
スクリプト自体は、まず On Error Resume Next ステートメントを使用します。通常は、わざわざスクリプトにエラー処理を含めたりしません。これは、エラー処理を記述することに反対しているわけではなく、スクリプトをできる限り短くてわかりやすくするためです。しかしここでは、On Error Resume Next ステートメントでなければなりません。これは、このスクリプトが異なる複数のコンピュータに接続するからです。いずれかのコンピュータの電源がオフになったらどうなるでしょうか。エラー処理を行っても、何も起こりません。もちろんエラーは発生しますが、スクリプトはエラーを無視して先に進むことができます。エラー処理を行わなかった場合、Scripting Guy が新しい TV の電源を初めて入れたときとほぼ同じ状況になります。つまり、何も起こりません。
次に、以下のコード ブロックを使用して、Excel.Application オブジェクトのインスタンスを作成し、その Excel インスタンスを画面に表示し、ワークシート C:\Scripts\Test.xls を開きます。
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
大事なことを言い忘れていましたが、カウンタ変数 i に値 2 を代入します。この変数は、ワークシートの現在の行を追跡するために使用します。
注 : i に 2 を代入するのはなぜでしょうか。答えは簡単です。ワークシートをよくご覧ください。実際のデータは 2 行目から始まっています。1 行目は単なる見出しです。
どうですか。私たちは YPbPr1 ケーブルの接続は得意ではないかもしれませんが、スクリプトについては多少知っています。
まあ、いずれにしてもときどきしか役に立ちませんが。
これで準備ができました。まず、列 1 の空のセルを検出するまで実行される Do Until ループを設定します。これは、他に何をしていても、列 1 の行だけは空にしてはならないということです。スクリプトは空の行を検出すると、データの末尾に達したと見なしてループ (スクリプト) を終了します。回避策はいくつかありますが、単にワークシート内に空の行をつくらないようにする方が簡単です。
ループ内では、まず、行 i、列 1 のセルの値を strComputer という名前の変数に代入します (1 回目のループでは、i の値が 2 であるため、行 2、列 1 のセルの値を代入します)。次に、以下のコードを使用して、変数 strComputer によって示されたコンピュータのローカル管理者アカウントへのオブジェクト参照 (objUser) を作成します。
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
エラーが発生した場合、このスクリプトはその時点で失敗します。たとえば、ネットワークの問題が発生したり、コンピュータの電源がオフになったり、Scripting Guy の 1 人が DVD プレーヤーの取り付けを誤って米国西部全体を停電にしてしまったりするかもしれません。このようなことが起こった場合、目的のコンピュータに接続することはできません。このため、上記のコードのすぐ後、以下のように VBScript の Err オブジェクトの値を確認します。
If Err = 0 Then
Err オブジェクトの値が 0 の場合、問題なく目的のコンピュータ (およびその管理者アカウント) に接続できたことを意味します。Err が 0 以外の場合、可能性は 1 つだけです。つまり、接続に失敗したということです。この場合、接続先のコンピュータのパスワードを変更する処理は実行しません。言うまでもなく、接続できなければパスワードを変更することはできないからです。
エラーが発生しなかった場合、以下の 2 行のコードが実行されます。
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
1 行目では、SetPassword メソッドを使用して、新しいパスワード (egTY634!alK2) をローカル管理者アカウントに割り当てます (もちろん、パスワードにはお子さんの名前を使用しないでください)。2 行目では、現在の日時を (VBScript の Now 関数を使用して) 行 i、列 2 のセルに書き込みます。[Password Changed] 列を更新するのは、実際にリモート コンピュータに接続してパスワードを変更できた場合のみであることに注意してください。コンピュータに接続できなかった場合、対応する [Password Changed] 列のセルは更新されません。これによって、成功した操作と失敗した操作を見分けることができます。
結局どういうことなのでしょうか。つまり、ループの処理を 1 回実行すると、ワークシートは図 3 のようになるということです。
図 3 最初のパスワードを再設定した後のコンピュータの一覧
図 3 最初のパスワードを再設定した後のコンピュータの一覧 (画像を縮小するには、ここをクリックします)
図 3 最初のパスワードを再設定した後のコンピュータの一覧
図 3 最初のパスワードを再設定した後のコンピュータの一覧 (画像を拡大するには、ここをクリックします)
コンピュータ 1 に対する処理はここまでですが、次に進む前にちょっとした整理を行う必要があります。
Err.Clear
i = i + 1
上記のコードは短いですが、どちらもとても重要です (Scripting Guys があまり重要でないコードを書いているかのようですが)。最初の行では、Err オブジェクトを 0 に再設定します。エラーが発生しなかった場合、Err は既に 0 なのでこれは余分な処理になりますが、エラーが発生した場合、Err は 0 以外の値になります。この場合、Err オブジェクトを手動で再設定することがとても重要です。なぜでしょうか。それは、これがエラー オブジェクトだからです。このオブジェクトは成功を追跡せず、エラーのみを追跡します。たとえば、コンピュータ 1 で問題が発生し、接続が失敗したとします。話を続けるために、この問題が原因でエラー オブジェクトが 99 に設定されたとしましょう。
さらに、ループ処理を続行し、コンピュータ 2 に正常に接続できたとします。Err の値はどうなるでしょうか。そうです。いやが応でも、Err には 99 が設定されたままになります。これは、Err オブジェクトはエラーが発生した場合のみ変更され、エラーが発生しなかった場合は、現在の値を無期限に保持するためです。
これがそれほど重要なことなのでしょうか。当然重要です。技術的に言えば、コンピュータのパスワードを変更するのは、接続が成功した場合ではなく、Err が 0 の場合のみです。電卓を使うので、少し待ってください。はい、大丈夫でした。99 は 0 ではありません (もちろん、父親が 99 票を投じても 1 票もカウントされない Scripting Guy の家族会議の場合は除きます)。上記のことが重要である理由は、コンピュータ 2 への接続が成功しても Err は 0 にならず、Err が 0 以外の場合、スクリプトはローカル管理者のパスワードを変更するための処理を行わないからです。
つまり、Err の値が変更された場合は、その値を 0 に再設定する必要があるということです。再設定しなかった場合、それ以降スクリプトはエラーが発生したものとして処理を行います。では Err オブジェクトを 0 に再設定するにはどうすればよいでしょうか。そのとおりです。Err.Clear を呼び出せばいいのです。
次に、i の値を 1 つ増やします。なぜでしょうか。1 回目のループ処理では、i の値は 2 でした。これは、一覧の行 2、列 1 のコンピュータに接続する必要があったからです。2 回目のループ処理では、一覧の行 3、列 1 のコンピュータに接続する必要があります。i は操作する行を示す変数なので、i を 3 に設定する必要があります。ご存知のように、2 + 1 = 3 です (幸いなことに電卓をまだ終了していませんでした)。そしてようやく、ループの最初に戻ってワークシート内の次のコンピュータに対して処理を実行します。
これはすばらしい処理ですが、私たちはもう以前ほど世間知らずではないので、このスクリプトだけではユーザーから電子メールで寄せられた質問に対応できないことはよくわかっています。ユーザーは言うでしょう。"この Excel の処理はすばらしいですが、OU 内のすべてのコンピュータやテキスト ファイルに列挙されたすべてのコンピュータのローカル管理者のパスワードも変更する必要があるのです。または、コンピュータの一覧をポップアップ表示して、リスト ボックスからコンピュータを選択できたらいいと思います。それができないのであれば..." と。
まあそうあわてないでください。Scripting Guys は皆さんがお望みなら何でもいたします (その希望が叶えられるまで 4 年間待つ気があるならということになりますが)。おわかりのように、スクリプト センターでは複数のコンピュータ用のテンプレート (つまり、複数のコンピュータに対してとても簡単にスクリプトを実行できるテンプレート) がたくさん提供されています。たとえば、OU 内のすべてのコンピュータのローカル管理者のパスワードを変更する必要があるとします。問題はありません。OU 内のすべてのコンピュータに対してスクリプトを実行するためのテンプレートは、図 4 のようになります。
Figure 4 OU に対するスクリプトの実行 (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
"Insert your code here" と書かれたセクションを見てください。必要な作業は、そのセクション内のサンプル コードを削除し、ローカル管理者のパスワードを変更するためのコード (このコラムからコピーできます) に置き換えるだけです。つまり、サンプル コードを次のコードに置き換えます。
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
このサンプル コードだけでは結果は記録されませんが、そのためのコードは簡単に追加できます。サンプル コードを置き換え、いずれかの OU を指定するように接続文字列 LDAP://OU=Finance,dc=fabrikam,dc=com を変更するだけです。
実は、これらのテンプレートは 1 年以上も前から提供されています。提供したときは、これまでスクリプト センターで提供したものの中でも人気が高いスクリプトになるのではないかと思っていました。しかし私たちが間違っていました。スクリプトを複数のコンピュータに対して実行する方法に関する質問は毎日のようにたくさん寄せられますが、これらのテンプレートはほとんど使用されるようになりません。どのユーザーもこれらのテンプレートの存在を知らなかったのだと思います。しかし、これで覚えましたね。場所もお教えしておきましょう。microsoft.com/technet/scriptcenter/scripts/templates です。今までだれもこれらのテンプレートを使わなかったのは、このせいかもしれませんね。
今や Scripting Guys は以前ほど世間知らずではなくなりましたが、以前ほど間抜けでも不器用でもなくなったでしょうか。その疑問には、次のようにご説明しておきましょう。少し前に Scripting Guys の 1 人は、週末を使って家の周りのものを整理することにしました。月曜日に仕事に来たとき、彼は親指を強打して出血が止まらなくなっており、足にも大怪我を負っていました。
考えてみると、これはそれほど悪いことではありませんでした。少なくとも Scripting Guy にとっては。

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


 セキュリティ ウォッチ: セキュリティの構成ウィザード
セキュリティ ウォッチ
セキュリティの構成ウィザード
John Morello
このコラムには、Windows Server "Longhorn" のプレリリース情報が含まれています。この記事のプレリリース情報は変更される可能性があります。

サーバーを効率的かつ継続的にセキュリティで保護することは、多くの IT 組織の課題です。特に膨大な数のコンピュータが多くの地理的な境界や組織の境界にまたがって分散している組織には、このことが当てはまります。1 台のサーバーのセキュリティを強化することは、経験豊富な管理者にとっては比較的容易な作業ですが、強化するサーバーの数が 10 台、100 台、または 1,000 台にまでなってくると、まったく違った話になります。
長年の間、多くの組織は、サーバーのセキュリティを確保するために独自の内部チェックリストや基準を考案したり、マイクロソフト、米国標準技術局、その他の外部団体などから提供されたガイダンスに記載されている方法を取り入れたりしていました。このドキュメントは非常に重要になる可能性がありますが、単独では組織がネットワークに関するベスト プラクティスを実行に移すのに十分ではありません。このため、多くの組織は既定の設定をそのまま使用するか、システムを強化するためのスクリプトやポリシーを独自に作成するために膨大な時間と労力を費やすことを選びました。
マイクロソフトは、Windows Server® 2003 Service Pack 1 (SP1) にセキュリティの構成ウィザード (SCW) が組み込まれたことにより、役割に基づいてサーバーの強化とサーバーが攻撃を受ける確率の低減を実現するための、容易かつサポートされた方法を提供できるようになりました。SCW の利点と、展開と管理を一元的に行うことができるグループ ポリシーを組み合わせることで、大規模な IT 企業でも SCW を使用することができます。今月のコラムでは、IT 組織で SCW とグループ ポリシーを使用して安全かつ一貫した方法で組織のサーバーを管理し、展開コストと運用コストを削減する方法の概要を説明します。

SCW とは
SCW は、コントロール パネルの [Windows® コンポーネントの追加と削除] からインストールできるオプション コンポーネントであり、Windows Server 2003 R2 を含むすべての Windows Server 2003 SP1 ファミリで使用できます。管理者は、まず対象のサーバーに対して SCW を実行し、そのサーバーの役割を確認します。次に、最小特権の構成を使用して、コンピュータを強化するセキュリティ ポリシーを作成します。つまり、その役割として機能するために必要なサービス、アプリケーションの機能、およびポートのみを使用し、特に必要がないものは無効にすることができます。この方法により、対象のサーバーが攻撃を受ける確率を低減することができます。そのサーバーの役割に必要ないサービスを実行している場合、機能面での利点を得ることなく、サーバーに対するネットワーク リスクのみが増加します。これらのサービスを無効にすることで、このようなリスクが低下すると同時に、サーバーのパフォーマンスが向上する場合もあります。
Windows Server 2003 ではセキュリティが大幅に強化され、Windows Server の以前のバージョンに比べて攻撃を受ける確率が全体的に大きく低下しましたが、Windows Server 2003 は、Windows Vista™ や Windows Server の次期バージョンであるコードネーム "Longhorn" のように、高度にコンポーネント化されたコアをベースに構築されたオペレーティング システムではありません。このため、既定の Windows Server 2003 では、すべてのサーバーの役割の構成には必要ないサービスが有効化および実行されていることがあります。たとえば、印刷スプーラ サービスは既定で有効になっていますが、データベース専用サーバーとして実行されるコンピュータには必要ありません。

役割ベースのセキュリティを実現する
マイクロソフトは過去数年にわたって、セキュリティに重点を置いた大量のドキュメントを公開してきました。たとえば、管理者がサーバーの各役割に必要なサービスを理解するのに役立つドキュメントや、Web サーバーなどのよく知られた役割用の構築済みテンプレートを提供するドキュメントなどがあります。しかし、『Windows Server 2003 セキュリティ ガイド』などに記載されているガイドラインを大規模な環境で実装するのは困難です。特に、基本的な IIS や SQL Server よりも複雑なアプリケーションを環境で使用する場合、より実装は困難になります。さらに問題を複雑にしているのは、企業で無数のサードパーティ製のアプリケーションが使用されており、それらの多くが複数のサーバーの役割に依存し、アプリケーションやサービスの要件も厳密に定義されていない場合があることです。
SCW は、上記のようなガイドに記載されている、依存関係に関する情報やベスト プラクティスを、管理者主導のウィザードにすべてカプセル化することで、これらの問題に対処します。たとえば、SQL Server™ と IIS の両方が必要な基幹業務 (LOB) アプリケーションを展開している場合、管理者がセキュリティ ガイドをくまなく調べて、環境の依存関係の一覧を独自に作成する必要はなくなります。その代わりとして、管理者はサーバーにアプリケーションをインストールし、SCW を起動することができます。SCW は現在実行されているサービスを検出し、そのサーバー用に選択する必要がある役割の一覧を管理者に提供します。SCW は、管理者の選択内容に応じて、選択された役割が依存していないすべてのサービスを無効にするポリシーを生成します。また、レジストリのセキュリティ強化、不要なネットワーク通信のブロック、および効果的な監査ポリシーの適用を行うためのオプションを提供します。SCW の実行後、管理者は SCW ポリシーを XML ファイルとして保存し、同じ LOB アプリケーションを実行している他のすべてのサーバーに適用できます。
つまり SCW を実行することにより、手作業が多い従来の Windows Server のセキュリティ保護の方法に比べて、3 つの大きな利点が得られます。1 つ目は、管理者が頻繁に製品ドキュメントを調べて、特定の作業に必要なサービスや設定を確認する必要性が (なくなるわけではありませんが) 大幅に低下することです。この情報は SCW に組み込まれているため、管理者は質問に基づいたインターフェイスを使用して、容易に必要な情報を提供できます。2 つ目は、サービスの強化、ネットワーク攻撃を受ける確率の低減、LDAP サービスと SMB サービスの強化、IIS のロックダウンなど、多くの分野のガイダンスが SCW に統合されることです。以前は、これらの構成作業を行うために、インターフェイスも方法も異なる別々のユーティリティを使用する必要がありました。3 つ目は、SCW は設定を XML ポリシー ファイルに出力するので、"一度作成して何回も適用する" というシナリオに使用できることです。特定の LOB アプリケーションをサポートするために展開するサーバーの数が 1 台でも 100 台でも、同じ SCW ポリシーを容易にすべてのサーバーに適用できます。これにより、セキュリティ設定の一貫性が高まり、運用コストが削減されます。また、SCW ポリシーのロールバックも容易になります。

SCW コンポーネント
SCW は多くの機能や利点を提供しますが、実際は 3 つの主要な部分から構成される非常に単純なツールです。この主要な部分とは、ウィザード インターフェイス、コマンド ライン インターフェイス、およびセキュリティの構成データベース (SCD) です。小規模または中規模の企業の管理者が使用する必要があるのは、おそらくウィザード インターフェイスのみです。大規模またはさらに複雑な環境の管理者は、コマンド ライン インターフェイスを使用して、SCW ポリシーをグループ ポリシー オブジェクト (GPO) に変換するタスクなどの SCW タスクを自動化できます。通常は、独自の SCW の役割を作成する上級管理者のみが、SCD を変更します。
管理者は、図 1 のようなウィザード インターフェイスを使用して、セキュリティ設定の作成、編集、適用、およびロールバックを対象のサーバーに対して行うことができます。管理者は、選択肢が提供される一貫したワークフローの中で、サービスと設定、ネットワーク接続、セキュリティ監査ポリシー、および IIS の設定を順に検討することができます。
図 1 SCW のインターフェイス
図 1 SCW のインターフェイス (画像を縮小するには、ここをクリックします)
図 1 SCW のインターフェイス
図 1 SCW のインターフェイス (画像を拡大するには、ここをクリックします)
SCW コマンド ライン インターフェイスでは、3 つの基本的な機能が提供されます。1 つ目に、管理者は複数のサーバー (ローカルまたはリモート) の分析と構成、およびポリシーのロールバックを行うことができます。2 つ目に、XML ベースの SCW ポリシーを GPO に変換して、グループ ポリシー管理コンソールなどの標準的な GPO 管理ツールでネイティブに使用できます。そして 3 つ目に、図 2 のような SCW コマンド ライン ツールを使用して、拡張した新しいセキュリティの構成データベースを登録できます。
図 2 SCW コマンド ライン ツール
図 2 SCW コマンド ライン ツール (画像を縮小するには、ここをクリックします)
図 2 SCW コマンド ライン ツール
図 2 SCW コマンド ライン ツール (画像を拡大するには、ここをクリックします)
SCD は、SCW の各役割に必要な特定のサービスや設定が記述された XML ファイルの集合です。これらのファイルは %windir%\security\msscw\kbs にあります。既定の SCW には、多くの主要な Windows Server の役割だけでなく、BizTalk®、Commerce Server、Exchange Server、Host Integration Server、Internet Security and Acceleration Server、Microsoft Identity Integration Server、Microsoft Operations Manager、Small Business Server、SharePoint® Portal Server、SharePoint Team Services、SQL Server、および Systems Management Server という 12 種類の定義済みのアプリケーションの役割が付属しています。役割ごとに別々の XML ファイルが使用されます (図 3 を参照)。新しい役割の定義が作成されるたびに、対応する XML ファイルがこのディレクトリに格納されます。これらのファイルは標準の XML であるため、テキスト ビューアや、XML をサポートするその他のアプリケーションで読み取ることができます (図 4 を参照)。
図 3 定義済みの役割
図 3 定義済みの役割 (画像を縮小するには、ここをクリックします)
図 3 定義済みの役割
図 3 定義済みの役割 (画像を拡大するには、ここをクリックします)
図 4 役割の構成ファイル
図 4 役割の構成ファイル (画像を縮小するには、ここをクリックします)
図 4 役割の構成ファイル
図 4 役割の構成ファイル (画像を拡大するには、ここをクリックします)

SCW とグループ ポリシーを組み合わせる
SCW は、それだけでもすばらしいツールですが、その真の力はグループ ポリシーと組み合わせたときに初めて明らかになります。Windows® 2000 のリリース以来、Windows サーバーをセキュリティで保護する方法としてマイクロソフトが重点的に推奨してきたのは、グループ ポリシーを使用して、一貫性および永続性のある、一元管理されたポリシー アプリケーションを使用することでした。管理者は、役割に基づいてサーバーを組織単位 (OU) に分類することにより、個々のコンピュータ レベルではなく、企業全体に標準のセキュリティ構成を展開できます。組織は、標準のグループ ポリシーの累計および適用ロジックをベースにしてサーバーの役割を構築することによって、少数のマスタ ポリシーを使用して 100 台または 1,000 台のサーバーをセキュリティで保護できる、階層化されたサーバーの役割を設計できます。特徴的な役割を持つサーバーに、マスタ ポリシーに変更を加えたポリシーを適用する必要がある場合、それらのサーバーにより近い OU 階層用に、役割に焦点を合わせた項目の少ない差分ポリシーを作成できます。これにより、マスタ ポリシー全体を複製することなく、少ない変更で役割固有の機能を有効にすることができます。つまり、一元管理されたポリシーの利点が提供されるだけでなく、必要に応じた個別の適用にも対応できる柔軟性が提供されます。
この方法の真の課題は、実装段階にあります。さまざまなアプリケーションやサーバーの役割を保有する大規模な組織の場合、適切なポリシーの作成は困難で時間がかかります。しかしそれは SCW が開発されるまでの話です。SCW を使用してポリシーを生成してから、それらのポリシーを適切な OU に適用することにより、既存の作業と今後導入する作業の両方に対して、ディレクトリによってホストされた、役割ベースのセキュリティを展開する時間を大幅に短縮できます。組織でこの作業を行う方法をわかりやすく説明するために、大規模な企業で SCW と役割ベースの GPO を実装する方法について順を追って説明します。

企業内での SCW
この例では、架空の Contoso ネットワークを使用します。Contoso は、大規模かつ複雑な、地理的に分散した IT 企業です。Contoso は運用コストの削減とサーバーのセキュリティの強化を目指し、マイクロソフトのガイダンスに従って、作業に基づいてサーバーを分類および整理する、役割ベースの OU 階層を作成します。これらの OU に適用するポリシーは、SCW を使用して作成します。
SCW は既定ではインストールされていないため、Contoso で使用している無人インストール イメージの SCW コンポーネントを有効にする必要があります。これを行うには、Unattend.txt の [Components] セクションに SCW=On という新しい行を追加します。その後、このイメージを使用して構築されるすべての新しいシステムには、セットアップ中に SCW コンポーネントがインストールされます。ただし、SCW をインストールするように構成しただけでは、コンピュータの構築中にポリシーが適用されないことに注意してください。
セットアップ処理中に既定のポリシーを適用するには、イメージ内の cmdlines.txt ファイルの [Commands] セクションを編集して、scwcmd に次のオプションを指定して呼び出します。
scwcmd configure /p:ContosoBaselinePolicy.xml
テキスト ファイルと XML ファイルは、どちらもイメージの $OEM$ ディレクトリに格納されている必要があります。サーバーの構築時に、Contoso はなぜディレクトリの最上位の OU に適用されたポリシーに依存せず、ベースライン ポリシーを適用するのでしょうか。これは、サーバーの構築時にポリシーを適用することにより、そのサーバーが Active Directory® に参加するかどうかにかかわらず、一貫したベースラインを保証できるためです。たとえば、サーバーをテスト目的で構築する場合、構築処理中にベースライン ポリシーを適用すると、そのサーバーを運用環境の Active Directory に参加させなくても、組織の標準セキュリティ ポリシーは必ず適用されます。このサーバーが後から Active Directory に参加した場合、グループ ポリシーの適用および優先順位のアルゴリズムに従って、ローカルの設定がドメインまたは OU レベルの設定よりも優先されます (ポリシーは、ローカル、サイト、ドメイン、OU という優先順位に基づいて適用されます)。
SCW をインストールしたら、ベースライン ポリシーの作成を開始することができます。ベースライン ポリシーは、役割ベースのセキュリティ OU 階層の最上位に展開され、通常は階層内で最も制限が厳しいポリシーである必要があります。つまり、既定のポリシーのセキュリティをできるだけ高く設定してから、個々の作業に対して、サーバーの役割に必要なサービスやポートを使用できるようにしていくということです。このため、ベースライン ポリシーを作成するには、何も変更を加えずに新しく構築されたサーバーを用意し、Contoso の標準管理ツールおよびユーティリティを追加した後、そのサーバーに対して SCW を実行します。たとえば、基本的な Windows のインストールが完了した後、標準のウイルス対策ツール、バックアップ ツール、管理ツール、および監視ツールを (手動または cmdlines.txt ファイルを使用して) サーバーにインストールします。各ツールによって独自の Windows サービスが作成される可能性があるため、これらのサービスがサーバーに作成されてからベースライン ポリシーを作成することにより、サービスをロックダウンするフェーズで SCW がそれらを認識できます。
サーバーが構築されたら、そのサーバーに対して SCW を実行します。SCW は、ローカルまたはリモートで実行できますが、SCW を実行するユーザーは、コンピュータのローカル管理者グループのメンバである必要があります。SCW をリモートで実行する場合、リモート ホストのどのユーザー アカウントを使用して実行するかを指定するためのオプションが提供されます。ローカルで実行する場合は、runas.exe を使用して同じ操作を行うことができます。SCW で最初に行う作業は、ローカル コンピュータで実行されているサービスを評価し、現在インストールされている役割を表示することです (図 5 を参照)。
図 5 サーバーの役割の選択と表示
図 5 サーバーの役割の選択と表示 (画像を縮小するには、ここをクリックします)
図 5 サーバーの役割の選択と表示
図 5 サーバーの役割の選択と表示 (画像を拡大するには、ここをクリックします)
Contoso のベースライン サーバーの制限は最も厳しくするという設計になっているため、このサーバーではどの役割も選択しません。サーバーが担う役割を選択したら、次は必要なクライアント機能を確認し、自動更新、Active Directory、FTP クライアントなどの機能を有効にします。ほとんどの組織では、SCW の既定の設定 (図 6 を参照) をそのまま使用することで、重要な機能 (ドメインに参加する機能など) が提供され、重要度の低い機能 (FTP クライアントなど) は提供されません。
図 6 インストールされる機能
図 6 インストールされる機能 (画像を縮小するには、ここをクリックします)
図 6 インストールされる機能
図 6 インストールされる機能 (画像を拡大するには、ここをクリックします)
SCW の次のページでは、有効にする管理ツールと既定以外のサービスを選択できます。Contoso の標準サーバー管理ツールおよびユーティリティをインストールしてから SCW を実行する理由は、このページでそれらを選択できるようにするためです。ウイルス対策、バックアップ、および関連アプリケーションをインストールすると、それらのサービスが SCW によって認識されるため、生成するポリシーの設定にそれらのサービスが含まれます。
サービス強化セクションの最後の質問は、特定できないサービスの処理方法です。これらのサービスは、SCW ポリシーが作成されたコンピュータでは実行されていませんが、このポリシーが適用される他のコンピュータで実行されている可能性があります。たとえば、新しいサードパーティ製のアプリケーションがインストールされた新しいサーバーにベースライン ポリシーを適用する場合、そのアプリケーションによってインストールされたすべてのサービスは、ここで管理者が選択した内容に応じて処理されます。管理者は SCW を使用すると、サービスのスタートアップ モードを変更しないか、サービスを無効にすることができます。[無効] が最も安全なオプションですが、明示的に実行を許可されていないサービスがすべて実行できなくなるため、注意して使用する必要があります。このため、このオプションは、高いセキュリティが確保されている、管理の行き届いた環境に最も適しています。組織の他の環境では、スタートアップ モードを変更しないことを選択するようお勧めします。このため、Contoso の例では、このオプションを選択します。SCW は、サービスのセキュリティ強化関連の作業を完了する前に、変更されるサービスに関するレポートを管理者に提供します。
SCW は、サービスの強化を完了した後、受信ネットワークのアクセスを制限するためのオプションを提供します。特定の役割に必要なサービスの一覧と同様、特定の作業に必要なポートの一覧が SCW の XML データベースに含まれます。
管理者は、図 7 のように、必要に応じて追加のポートを構成したり、サービスごとのポートの規則を作成したりできます。Contoso のベースライン サーバーの場合は、リモート デスクトップなどの最も基本的なサービスのみを許可する必要があります。他のすべての例外は、下位の OU 階層に適用する、役割ベースのポリシーで構成します。
図 7 ポートの表示と許可
図 7 ポートの表示と許可 (画像を縮小するには、ここをクリックします)
図 7 ポートの表示と許可
図 7 ポートの表示と許可 (画像を拡大するには、ここをクリックします)
その後、管理者はファイル トラフィックと印刷トラフィックの署名などのレジストリ オプションを選択できます。ベースラインの構成の場合、ここでも最も安全な既定値を選択することがベスト プラクティスとして推奨されます。
次のページで選択するのは、システム監査ポリシーです。ほとんどのシステムでは、[成功のアクティビティを監査する] を選択することが最も適切です。すべてのアクティビティを監査した場合、プロセッサの使用率が高くなり、監査ログに大量のデータが記録されます。攻撃を受けている可能性があり、より詳細な分析が必要な場合は、特定のコンピュータで失敗の監査を有効にすることができます。
最後に、IIS を強化するためのオプションが管理者に提供されます。これらのオプションは IIS Lockdown ツールで使用できるオプションに似ており、今回 SCW ポリシーに直接統合されました。
すべてのステップが完了したら、XML ファイルを保存するための画面が表示されます。保存されたファイルは、その後グループ ポリシーがネイティブで認識できる形式に変換されます。保存された XML ファイルを GPO に変換するには、scwcmd.exe を使用します。入力するコマンドは次のとおりです。
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
このポリシーは Active Directory に自動的に作成されるため、Contoso が役割ベースの強化に使用する OU 階層の最上位に適用できます。
このポリシーが階層の最上位に適用された後、その OU 階層に追加されたコンピュータはすべてその設定を継承します。Contoso の管理者は、このポリシーの変更を必要とするコンピュータ (W3SVC サービスを実行する必要がある IIS サーバーなど) を追加するとき、その新しいサーバーの役割用に SCW を再実行し、生成された新しいポリシーを GPO に変換して、そのサーバーが含まれた新しいサブ OU に適用します。サーバーに最も近い GPO が優先的に適用されるため、最終的には、その OU のサーバーが担う役割の機能を有効化するために変更する設定を除き、ベースラインの設定が適用されます (図 8 を参照)。
図 8 Contoso でのポリシーの適用
図 8 Contoso でのポリシーの適用 (画像を縮小するには、ここをクリックします)
図 8 Contoso でのポリシーの適用
図 8 Contoso でのポリシーの適用 (画像を拡大するには、ここをクリックします)
この方法の真の力は、大規模な組織や、多くのサーバーの展開時に明らかになります。最初の SCW ポリシーを作成して OU に適用したら、それ以降のサーバーは単にその OU に追加するだけで、適切なセキュリティ ポリシーを自動的に継承します。このため、最初にポリシーを作成して Active Directory に追加した後は、新しいサーバーの展開や既存のサーバーの置換を容易かつ迅速に行うことができます。

今後の見通し
マイクロソフトは、次の Windows Server リリースの "Longhorn" で、オペレーティング システムを大幅にコンポーネント化し、攻撃を受ける確率の低減を既定で実現します。管理者は、最小の既定値を制限することに重点を置くのではなく、サーバー マネージャ ツールを使用して、各サーバーに必要な役割と作業を追加します。サーバー マネージャの動作は SCW に似ており、依存関係の内部データベースを使用して、役割に必要なサービスをインストーラが提供するための機能のみを追加できるようにします。また、GPO によって制御される機能が大幅に拡張されたことにより、この記事で説明した、グループ ポリシーを使用して一元管理される役割ベースのセキュリティも大きく強化されます。つまり Windows Server "Longhorn" は、向上した柔軟性と、さらに強化された既定のセキュリティの状態により、SCW の考え方を次の段階に進めます。
SCW の関連情報
SCW の使用を開始する際に役立つ Web ページを次に示します。
  • セキュリティの構成ウィザードに関するドキュメント
  • セキュリティの構成ウィザード (SCW)
  • Windows Server "Longhorn"

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


 デスクトップ ファイル: x64 という選択
デスクトップ ファイル
x64 という選択
Wes Miller

Windows XP は 5 年以上にわたり、64 ビット アーキテクチャにネイティブで対応しています。しかし、Intel Itanium プロセッサを早期に導入したユーザーでない限り (Itanium 用の Windows XP は、通常の 32 ビット版 Windows XP と同日にリリースされました)、x64 システム対応の Windows XP や Windows Server 2003 の提供が開始された最近になって初めて 64 ビットへの対応を知ったという人が大半でしょう。
x64 (業界では x86-64 と呼ばれることもあります) は、AMD の AMD64 アーキテクチャおよび Intel の EM64T の一般名です。この 1 年以内に新しく購入されたパソコンの場合は、現在は 32 ビットで動作していても (十中八九そうだと思いますが)、64 ビットに対応している可能性が高いと思います。
現在、私はテキサス州オースティンに拠点を置く、小規模なベンチャー企業に携わっています。当社のある製品のアーキテクチャを考慮して、私たちは x64 アーキテクチャによってもたらされる特定の利点を活用することを目指しています。これは、自らの領分をきっちり定めて、x64 アーキテクチャ用のリリースだけを開始した Microsoft® Exchange 2007 チームの状況と似ています。私が管理する開発/テスト チームでも、開発用のワークステーション、ノート型パソコン、サーバー、および運用サーバーでは、x64 バージョンの Windows® XP および Windows Server® 2003 のみを使用しています。また、私自身、当社製品のテストやデバッグを行うために、自分のノート型パソコンで Windows XP Professional x64 Edition を使用しています。
おもしろいことに、私が 64 ビットの Windows を使用している (しかもモバイル システムで) ことをだれかに話すと、ほとんどの人は困惑した表情を浮かべます。64 ビット コンピューティングに詳しい人であれば、不信と嫌悪感と驚きが混ざったような表情を見せます。これは、64 ビット システム向けのデバイス ドライバはきわめて少ないと思われているからです。今月のコラムでは、私が x64 ビット モードのシステムで Windows XP および Windows Server 2003 を使用する方法と理由、そして導入の利点 (および障害) をご紹介します。また、Windows Vista™ x64 のサポート、移行、および展開についても説明します。

x64 小史
始めにも言いましたが、Windows における 64 ビットのサポートは、元はといえば Intel Itanium プロセッサのサポートから始まりました (Windows は 64 ビットの Alpla プロセッサ用に提供されたこともありましたが、Alpla 上で実行されると実質的には 64 ビットの性能を発揮できませんでした)。Windows XP および Windows Vista は Itanium をサポートしていないため、64 ビット Windows クライアント コンピューティングにおける現在の主役は、x64 アーキテクチャです。Windows Server 2003 の多くのエディションは、Itanium ではなく x64 向けに提供されています (Itanium は、基本的に超ハイエンドのデータセンター用途に追いやられています)。この傾向は、次期バージョンの Windows Server (コード名 "Longhorn") のリリースでも続くと思います。
x64 プラットフォーム上の Windows のサポートは、Windows Server 2003 Service Pack 1 (SP1) のリリース時に開始されました。少し紛らわしいのですが、x64 バージョンの Windows XP がリリースされたのもちょうどこの時期です。つまり、Windows の異なるコード ツリーから、32 ビット版と 64 ビット版の Windows XP が生まれたことになります。32 ビット版では現在、2 つ目のサービス パックが提供されていますが、64 ビット版の Windows XP については、厳密に言うとサービス パックがまったくない状態です (Windows Server 2003 では SP1 レベルの機能が既に統合されているとして、SP1 は提供されていると考えてもよいでしょう)。
64 ビットの Windows (Windows XP、Windows Server 2003、Windows Vista、または Windows Server "Longhorn") を実行するための要件は、事実上同じです。当然のことながら、まず 64 ビット対応のプロセッサが必要です。AMD の場合は、AMD64 互換のシングル、デュアル、またはクアドコアのシステムが必要です (詳細については amd.com/jp-ja/Processors/ProductInformation/0,,30_118,00.html を参照してください)。Intel の場合は、EM64T サポートまたは Intel 64 アーキテクチャのシングル、デュアル、またはクアドコアのシステムが必要になります (詳細については intel.com/technology/intel64 (英語) を参照してください)。ただし、細かいところに厄介な点があるので注意が必要です。たとえば、Intel Core Duo システムは 64 ビット対応ではありません。Intel Core 2 Duo システムは 64 ビット対応ですが、これは Centrino Duo と呼ばれることもあります (私が使用するノート型パソコンがそうです)。

x64 を使用する
お使いのシステムが 64 ビット版 Windows をネイティブでサポートしているかどうかがわかったら、次にデバイス サポートについて対処する必要があります。マイクロソフトは、ベンダや OEM に対し、(2 年以上にわたる WinHEC セッションを通じて) デバイスおよびシステム用の 64 ビット ドライバを開発、認証するよう働きかけてはいるものの、Windows x64 の使用における最大の課題は、ハードウェア デバイスまたはソフトウェアに対応したドライバが容易に見つからないことです。私の経験から言うと、x64 の実行が最も有効なのは、必要なデバイス サポートが限られており、x64 のメリットが最も論理的に表れるサーバー上においてです。
一番困難なのは、デスクトップ システムとモバイル システム向けのドライバを見つけることです。一般的に、主要な OEM プロバイダ、またはエンタープライズ クラスのコンポーネントによって構築されたシステムの方が、ドライバが見つかる可能性が高いでしょう (つまり、ビジネスでの需要に後押しされ、ベンダや OEM が x64 対応ドライバの作成や認証を行う場合です)。
幸いなことに、Windows Vista では、この状況は好転します。これまでは x86 アーキテクチャが優先され、x64 アーキテクチャは無視されて、ドライバを備えたハードウェアが非常に少ない結果となっていましたが、立場が逆転するのです。Windows Vista では、デバイス ベンダは x64 ドライバの互換性テストを実行しなければなりません。実のところ、x86 ドライバを含める必要はないのですが、もちろん含めてもよいということになっています。つまり理論的には、ハードウェアの一部 (特に、Windows Vista の新機能を活用するデバイス) は、x64 Windows のみをサポートし、x86 のサポートは提供しない可能性があることを意味します。
実際、64 ビット Windows をネイティブで実行する際の唯一の問題点とは、ドライバに関することだけなのです。これよりも大きな問題点が生じつつ (または移行しつつ) ありますが、これについては後ほど説明します。

64 ビットにする理由
もちろん、AMD も Intel も、そしてマイクロソフトも、刺激を求めて 64 ビット アーキテクチャに向けて動いているわけではありません。64 ビットへの移行により、いくつかの大きな利点がもたらされるからです。図 1 に示すように、x64 アーキテクチャによってもたらされる最も重要な機能強化は、利用可能なメモリが大幅に増加する点です。32 ビットの Windows では、最大 4 GB までしか使用できませんでしたが、64 ビットの Windows では最大 16 テラバイト (TB) も使用できます。ただし、64 ビットのポインタは上限の 16 TB までアドレッシング可能ですが、アプリケーションでは最大約 8 TB までしかアクセスできないので注意が必要です。
Figure 1 メモリ アドレス空間の上限 (Close Figure 1)

アドレス空間 | 64 ビット Windows | 32 ビット Windows
仮想メモリ | 16 TB | 4 GB
ページング ファイル | 512 TB | 16 TB
ページ プール | 128 GB | 470 MB
非ページ プール | 128 GB | 256 MB
システム キャッシュ | 1 TB | 1 GB
さらに、x64 版 Windows では、ハードウェア ベースのデータ実行防止 (DEP) 機能が提供されます。これは、NX (No Execute) をサポートする x86 システムでも利用できます。ハードウェア駆動型のソリューションを Windows で利用することにより、バッファ オーバーフローの防止が可能になります。これは、メモリ内のデータ ページからのコード実行を防止するしくみです。このトピックの詳細については、support.microsoft.com/kb/875352 を参照してください。
x64 版 Windows では、x86 版 Windows と同様、マルチプロセッサまたはマルチコア CPU のネイティブ サポートも可能です。Windows XP システムのイメージ作成において最も複雑な点は、すべての Windows x64 インストールで単一のハードウェア アブストラクション レイヤ (HAL) を使用することにより解消されました。非 ACPI システムや、シングル CPU システムの HAL の特定に苦労することはもうありません。
基本的に、アーキテクチャとしての Windows x64 では、既存の管理インフラストラクチャと既存の 32 ビット ソフトウェアを (エミュレーションにより) 使用できる一方で、64 ビット ソフトウェアにより、大幅に拡張されたメモリをアクセスすることができます。実際、Windows x64 への移行に伴う難点として挙げられるのは、16 ビット アプリケーションのサポートが完全になくなる点 (16 ビット インストーラを使用する 32 ビット アプリケーションのような "隠れ 16 ビット" も含む)、ハードウェア DEP が有効化されていると正常に動作しないアプリケーションに関する問題点 (DEP はプロセスごとに無効にできます。また Windows アプリケーション互換性チームは、DEP が有効な状態で正常に動作しないアプリケーションの一部に対して、互換性の修正 "shim" を提供しています)、そして 64 ビットの Windows Vista では、すべてのドライバをデジタル署名しなければならない点だけです。
最後に挙げた機能は、メモリ内の Windows カーネルが不正に干渉されないように付加されたものであり、しばしばルートキットによって使用される手法です。マイクロソフトでは、x64 アーキテクチャ向けのドライバを先に開発するようベンダに推奨しているため (Windows ハードウェア品質テストにドライバを適合させるため)、この要件はこれまでのように手ごわい要件ではなくなるはずです。
x64 システムの Windows を導入する上で考慮すべき点は、他にもいくつかあります。たとえば、x64 システム向けの Windows XP には、Windows Media® Center Edition または Windows Tablet PC Edition の機能を搭載したバージョンがない点が挙げられます。しかしこの点も、x64 版 Windows に x86 版と同じ機能を実装した Windows Vista では解決されています。

仮想化
これまで、仮想化については言及してきませんでした。Microsoft Virtual PC や VMware などの PC 仮想化製品のことではありません。32 ビット実行可能ファイル用の、オペレーティング システムの仮想化のことです。32 ビット 版 Windows では、すべての 16 ビット アプリケーションは NTVDM (仮想 MS-DOS® マシン) のコンテキストの中で実行されます。前述のように、64 ビット版 Windows は、16 ビット アプリケーションをサポートしていません。代わりに、Windows の統合コンポーネントの大半は 64 ビット バイナリとしてネイティブに実行され、一部コンポーネントと多数のサードパーティ製プログラムは 32 ビット アプリケーションとして実行されます。
Windows では Windows On Windows (WOW) と呼ばれるまったく新しいエミュレーション層を提供してこれらの 32 ビット アプリケーションにオペレーティング システムを異なる形で見せ、事実上 32 ビット版 Windows で実行させることができます。WOW の下では、x86 アプリケーションは Program Files (X86) を単なる Program Files として見なします。同様に、%WINDIR%\SysWOW64 は、x86 アプリケーションには %WINDIR%\System32 として示されます。また、x86 アプリケーションは、レジストリ キー HKLM\SOFTWARE\Wow6432Node を、HKLM\SOFTWARE ノードそのものとして見なします。
Process Explorer ツールを使用すると、仮想化の別の側面を垣間見ることができます。多くの 32 ビット アプリケーションでは、統合された 32 ビットの Windows バイナリと相互作用することを想定しているため、これらのバイナリの多くは 64 ビットおよび 32 ビット両方のバージョンが提供されます。Process Explorer ツールに列を追加すると、これを簡単に表示することができます。図 2 では、cmd.exe の 2 つのインスタンスを示しています。そのうち 1 つは 32 ビット版で、もう 1 つは 64 ビット版です。強調表示した 32 ビット インスタンスでは、複数の wow64* DLL が 32 ビット プロセスに読み込まれていることが分かります。これは仮想化が行われていることを示しています。仮想化により、32 ビット アプリケーションが 64 ビット Windows 上で動作することが可能になっています。また、64 ビット版および 32 ビット版それぞれの cmd.exe によって使用されている作業ディレクトリ (パス) にも注目してください。
図 2 Process Explorer で 32 ビット版および 64 ビット版の cmd.exe を表示する
図 2 Process Explorer で 32 ビット版および 64 ビット版の cmd.exe を表示する (画像を縮小するには、ここをクリックします)
図 2 Process Explorer で 32 ビット版および 64 ビット版の cmd.exe を表示する
図 2 Process Explorer で 32 ビット版および 64 ビット版の cmd.exe を表示する (画像を拡大するには、ここをクリックします)
仮想化に関して最後に述べておきたい点があります。それは、Windows は explorer.exe をネイティブ 64 ビット アプリケーションとして実行しますが、これには長所と短所があることです。短所の中で最たるものは、エクスプローラのシェル拡張機能を動作させるには、x64 用に再コンパイルする必要があることです (ただし、再コンパイルされていないものが大半です)。
Internet Explorer® については、この反対です。つまり IE は、既定では 32 ビット版でネイティブに動作します。これは第一に、今日のインターネット上に多数存在する ActiveX® コントロールが、そのままの状態で正常に動作するようにするためです。64 ビット アプリケーションは 32 ビットの DLL やドライバを読み込むことができないため、現在利用可能なほぼすべての ActiveX コントロールである 32 ビット ActiveX コントロールを 64 ビットのブラウザでは読み込めません。つまり、大量のインターネット コンテンツにアクセスできなくなるのです。これを実際に確認するには、64 ビット Windows システムで C:\Program Files\Internet Explorer\iexplore.exe を実行し、ActiveX コントロール コンテンツを読み込むサイトにアクセスしてみてください (Windows Update でも可)。程度の差はあるでしょうが、いずれにせようまく表示できないはずです。Windows Update (図 3 を参照) は、このような状況において、Internet Explorer の 32 ビット インスタンスを開くように更新されました。将来的には、64 ビットの Internet Explorer を活用できるように ActiveX コントロール コンテンツが更新される場合も出てくるでしょう。しかし、今日の大半の Windows システムは 32 ビットの Windows を実行しているため、ActiveX コントロール コンテンツの更新はあまり必要とされていません。この状況はしばらくの間続くと私は思います。
図 3 32 ビット Active X コントロールは 64 ビット Internet Explorer で動作しない
図 3 32 ビット Active X コントロールは 64 ビット Internet Explorer で動作しない (画像を縮小するには、ここをクリックします)
図 3 32 ビット Active X コントロールは 64 ビット Internet Explorer で動作しない
図 3 32 ビット Active X コントロールは 64 ビット Internet Explorer で動作しない (画像を拡大するには、ここをクリックします)

Pluck 社における x64 Windows
この記事の冒頭で、Pluck 社における x64 Windows への移行について触れました。移行作業は、Windows XP Professional x64 Edition、Windows Server 2003 Enterprise Edition x64、および Windows Vista x64 の 3 つのバージョンで行いました。
当社は規模が小さいので、最新製品の開発を始めた段階で Windows x64 への移行を開始し、その利点を享受することができました。このため、当社で発注するすべての新しいハードウェアは、必ず x64 対応のものにしました。実は当社製品の動作の実現は、x64 の大容量メモリと仮想化の連携があってこそなのです。当社のすべての物理サーバーは、64 ビットのホスト サーバー上で 64 ビット仮想サーバーとして動作しています。各ホスト サーバーには 16 GB の RAM が搭載されており、これはホスティングされる仮想サーバーに分配されます (通常、各ステージング用仮想マシン (VM) には 2 GB、各運用 VM には 3 GB を割り当てています)。
ティア 1 システムと仮想化されたハードウェアも同時に使用することで、ほぼ 100% のデバイス サポートを達成できます。たとえば、私が使用しているノート型パソコンには、x64 ドライバのないデバイスが 3 つあります。これらのデバイスはどれも、さほど重要ではないバックプレーン型のデバイスであるらしく、これらがなくてもシステムは正常に動作します。興味深いことに、Windows Vista RC1 x64 をインストールしても、まったく同じデバイス サポートになります (私のシステムには Windows Vista Capable ロゴが貼付されています)。ただし、不足しているドライバも、ベンダから間もなく提供されるでしょう。
当社でのシステム使用目的は、主に Microsoft Office、Visual Studio®、および開発とビルドのプロセスで利用するその他いくつかのツールに限定されているので、移行において互換性の問題が生じるようなレガシ アプリケーションはそれほど使用していません。同時に 32 ビット版 Windows も多数使用していますが、新しいハードウェアを使用して 64 ビットへの移行を始めてから、移行作業は比較的容易に進んでいます。

x64 の展開と移行
展開については、いくつか考慮すべき点があります。マイクロソフトは、x64 アーキテクチャ専用の Windows プレインストール環境 (Windows PE) のバージョンを提供しています。ただし、x64 システムには x86 との互換性があるため、特にイメージング ソリューションを使用している場合などは、x86 Windows PE の使用が希望されることでしょう。無人インストールによって Windows XP を展開する場合、Windows PE はアーキテクチャ専用のバージョンを使用する必要があります。これは、winnt32.exe は展開先のアーキテクチャと同じアーキテクチャ上で実行されなければならないためです。Winodws PE には 32 ビット互換性レイヤがなく、x64 上の winnt32.exe は 64 ビット アプリケーションであるため、32 ビット Windows の展開には、32 ビットの Windows PE が必要になります。これは、64 ビットの場合でも同様です。
リモート インストール サービス (RIS) はこの点が異なるため、Pluck 社では RIS を使用しています。Windows Server 2003 SP1 から利用可能になった RIS では、x64 に加え、x86 や Itanium アーキテクチャの Windows も展開することができます。x64 システムが RIS サーバーに接続すると、サーバーは (既定の構成では) x86 および x64 の RISetup または RIPrep イメージを提供します。RIS は、x64 クライアントに x86 イメージのみ、または x64 イメージのみを提供するよう構成することもできます。この選択肢は、x64 ハードウェアでの最高のエクスペリエンスを実現するために、既定で提供されます。
ここまで、アップグレードについては言及しませんでした。もちろん、それには理由があります。あいにく、OS 全体を x86 から x64 にアップグレードするには、大変な作業が伴います。この理由から、また、Windows XP Pro x64 Edition の導入数が限られていることもあり、任意の x86 のバージョンから Windows XP x64 にアップグレードしたり、任意の Windows XP (x86 または x64) から Windows Vista x64 にアップグレードしたりすることはできません。x64 システム上の Windows Vista は、前バージョンの Windows XP Pro x64 Edition と同様、クリーン インストールのみに対応している製品なのです。このため、多くの組織では、ハードウェアの入れ替えと同時に x64 への移行を検討しています。また、Windows Vista の導入についても、この方法を採用する組織が多いことでしょう (1 度に 2 つの移行作業を行う方が合理的だと言えます)。
だからと言って、x86 Windows から x64 Windows に移行するユーザーや組織に対し、ツールがまったく用意されていないわけではありません。ツールはちゃんとあります。ユーザー状態移行ツール (USMT) の Windows XP および Windows Vista 対応バージョンは、Windows のあるインストールから別のインストールへの移行をサポートするよう拡張されています。今日多くの組織では、この方法で Windows を展開しています。同一パソコン上の場合でもワイプおよび再読み込みが行われています。したがって、まったく新しいアーキテクチャに Windows を移行するときにも同じ方法を使用すれば、これまで以上の問題は起こらないはずです。

まとめ
小規模な当社では、x64 への移行は段階的に行われており、大企業に見られるような膨大な移行作業に比べるとかなり容易ですが、すべての IT 担当者が x64 アーキテクチャへの最終的な移行を検討し始める必要があります。現実的には、x86 アーキテクチャおよび Windows の x86 ネイティブ版は、今後 10 年ほどは使用されるでしょうが、エンタープライズ コンピューティングの将来を担うのは x64 アーキテクチャなのです。マイクロソフトが Exchange Server やその他の製品を完全に x64 に移行していることから、まず、自分の環境において x64 システムがよく適合する分野を検討し、次に、現在、x64 システムで Windows XP または Windows Server 2003 をネイティブに使用しているかどうかにかかわらず、Windows Vista への移行が意味を持つ分野についても確認する必要があります。

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


 Microsoft.com の内部: Active Directory フェデレーション サービスを使用する
Microsoft.com の内部
Active Directory フェデレーション サービスを使用する
Jim Guthrie

マイクロソフトでは、エクストラネットを介してビジネス パートナーに重要な内部リソースへのアクセスを提供しています。このエクストラネットのアーキテクチャでは、組織の外部からの参加者が、このネットワーク用の一意のドメイン アカウントを保有している必要があります。
このアカウントは、当然パートナーではなくマイクロソフトの社員によって作成および管理されています。この方法は正常に機能していますが、ユーザーの操作性は不十分な場合があります。また、すべてのパートナー ユーザーの管理はマイクロソフトにとっても負担のかかる作業であり、多くのリソースが必要となります。
ここからは、このエクストラネットのしくみについて説明します。顧客やパートナーは、アプリケーションにサインインするときに、資格情報の入力を求められます。同一セッションの間、そのユーザーが異なるリソースにアクセスしようとすると、再び資格情報の入力が求められます。この動作は、ユーザーが異なるリソースにアクセスするたびに発生します。ユーザーは、複数のリソースを使用する 1 つのアプリケーション (財務データベースなど) にサインインした場合、異なるリソースにアクセスするたびに認証を行う必要があります。これはユーザーにとっては厄介で面倒な操作です。
幸いなことに、Active Directory® フェデレーション サービス (ADFS) を使用すると、この複数回にわたる認証の問題を非常に簡単に解決できます。ADFS は、Windows Server® 2003 R2 のコンポーネントです。ADFS を使用すると、複数の組織間の信頼を容易に作成し、各組織がそれぞれのユーザーを管理しつつ、複数のリソースを共有できるようになります。このコラムでは、マイクロソフトが ADFS をどのように使用して、このエクストラネットの複数のリソースへのアクセスに関する問題を解決するかについて説明し、同様のソリューションを実装する場合に必要な情報を提供します。詳細な説明に移る前に、図 1 を参照し、基本的な ADFS 用語を理解してください。
Figure 1 ADFS に関する用語 (Close Figure 1)

用語 | 定義
フェデレーション | Active Directory フェデレーション信頼が確立された一組の領域またはドメイン。
フェデレーション サービス リソース (FS-R) | 受信した認証要求を FS-A および目的のリソースに転送します。
フェデレーション サービス アカウント (FS-A) | FS-R での認証に使用するアクセス トークンを提供します。
フェデレーション サービス プロキシ (FS-P) | FS サーバーを受信インターネット トラフィックから分離するための層を提供します。
要求 | サーバーから発行される、クライアントに関する命令 (名前、ID、キー、グループ、特権、機能など)。
領域の検出 | 各 FS-A には、ログオンの資格情報が保存されるドメインまたは領域があります。領域の検出によって、ADFS セッションに使用される FS-A が決定されます。

ADFS ソリューション
ユーザーが ADFS 対応のアプリケーションにアクセスしようとすると、領域の検出を行うための画面がフェデレーション サービス リソース (FS-R) によってブラウザに表示されます。ここでユーザーは、セッション中に使用する一連の資格情報を選択します。次にユーザーは、クライアントが選択した領域に基づいて、フェデレーション サービス アカウント (FS-A) サーバーにリダイレクトされます。ユーザーはこのサーバーから、Windows Live™ ID (旧称 Passport アカウント)、Windows 統合認証、または SSL 認証の形式で入力した資格情報に基づく有効なアカウント トークンを (Cookie として) 受信します (図 2 を参照)。このモデルでは、個々の組織が独自のアカウント フェデレーション サーバーを管理します。Microsoft パートナー サーバーの場合は、これによって Microsoft.com に環境内のすべてのアカウントを管理するための負担がかからなくなります。もちろん、そのような責任を与える場合には、フェデレーションを構成する組織を慎重に選択する必要があります。また、それらの組織がアカウント情報を能動的に管理していることを確認する必要があります。
図 2 ADFS の流れ
図 2 ADFS の流れ (画像を縮小するには、ここをクリックします)
図 2 ADFS の流れ
図 2 ADFS の流れ (画像を拡大するには、ここをクリックします)
処理は FS-R サーバーに戻り、ここでアカウント トークンがリソース トークンと交換されます。マイクロソフトの構成では、このリソース トークンには、FS-R で実行された要求マッピング プロセスでユーザーに与えられたアクセス許可の完全な一覧が含まれます。ユーザーは、このリソース トークンを受信すれば、セッションが開かれている間または既定の 24 時間 (この時間は変更できます) の間、ADFS 対応のアプリケーションにシングル サインオン (SSO) できます。この結果、これらの ADFS 対応のアプリケーションに対する SSO が可能になり、ユーザー操作の安全性および効率性が向上します。ADFS 認証プロセスのすべての手順については、TechNet Magazine 2006 年 7 月号の Matt Steele の記事「ADFS を使用してシングル サインオンを簡略化する」を参照してください。
マイクロソフトの社内リソースのセキュリティを維持するため、エクストラネットの中で、インターネットに接続されるネットワークを、社内ネットワークに接続されるネットワークから分離しました。つまり、各サーバーをデュアルホーム化することができました。必要な保護を提供するために、社内ユーザーからの一方向の信頼関係を許可し、これらのサーバーにアクセスできるようにしました。また、エクストラネット内では、必要なリソースへのアクセスを外部ユーザーに提供するためのドメインを別個に構成しています。
実装における 2 つの懸念事項は、負荷分散と ADFS ポリシー ファイルの変更でした。負荷分散は、グローバル レベルとローカル レベルの両方で課題となっていました。運用環境では、2 つの地域のフロントエンド Web サーバー クラスタで、コンテンツ配信ネットワーク (CDN) パートナーの Akamai または Savvis によって提供されるグローバル負荷分散を使用する予定です。これにより、万一 2 つの地域のサーバーが両方ともオフラインになった場合でも、エンド ユーザーは引き続きシステムにアクセスすることができます。この動作は、CDN によって提供されるサーバーの状態確認サービスに基づいた、フェールオーバーの自動化によって実現されます。また、後からクラスタを容易に追加することもできます。コスト削減のため、非運用環境への展開時には CDN サービスを使用しませんでした。
地域レベルでは、ローカル フェールオーバーを行うために、ネットワーク負荷分散 (NLB) クラスタを構成しました。特別な負荷分散機能は使用していないため、ハードウェアでも容易にローカル フェールオーバーを実現できますが、コスト削減のために NLB を使用しています。この構成により、サポートされるすべての環境で 99.9% を超える稼働時間を確保できる安定性が提供されます。
もう 1 つの課題は、ADFS の重要な要素である ADFS ポリシー ファイルが環境全体に正しく配布され、そのファイルへの変更も同様にレプリケートされるようにすることです。これを実現するために、Windows Server 2003 R2 に組み込まれたもう 1 つの機能である、分散ファイル システム レプリケーション (DFS-R) を使用します。この機能は、状態ベースの新しいマルチマスタ レプリケーション エンジンです。各バックエンド サーバーは、常にフル メッシュ レプリケーションを実行する DFS-R グループのメンバとして構成しました。これで、どのサーバーでポリシー ファイルが変更されても、すべてのサーバーにファイルを配布することができます。また、ファイルを変更できるユーザーを制御することにより、サービスの安定性と高い可用性を実現できます。
マイクロソフトでは、すべての変更を ADFS スナップインから行うことを試みました。しかし実際には、手動でこのファイルを更新する必要が生じることがあります。手動でポリシー ファイルを更新するときには、このファイルのバージョンが ADFS によって追跡されることを考慮する必要があります。したがって、変更が環境に反映されるように、次のようにファイルのバージョンを表す値を 1 増やす必要があります。
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
また、他のあらゆる XML ファイルと同様に、この XML ポリシー ファイルでも大文字と小文字が区別されることを考慮する必要があります。この XML ポリシー ファイルには、アプリケーションまたは他の ADFS サーバーへの参照が多数含まれており、それらの参照文字列はサーバー間で一字一字正確にコピーされる必要があります。次に一般的な例を示します。1 つ目の RevocationCheckFlags は手動で入力しますが、2 つ目の TrustPolicyEntryUri (信頼するアプリケーションの URL を表します) は UI から変更されます。
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
セキュリティを強化するため、もう 1 つの ADFS コンポーネントであるフェデレーション サービス プロキシ (FS-P) を使用します。このコンポーネントを使用すると、受信インターネット要求から直接アクセスできない層に FS-R を配置することができます。Microsoft.com では、非運用環境で、1 つのプロキシを使用して複数の ADFS 環境をホストするという独自の方法でプロキシを実装しました。興味深いことに、このテクノロジの計画の初期段階で、レジストリ キーの簡単な変更だけでこの動作を実現できることがわかりました。このキーは、HKLM\Software\Microsoft\WebSSO にあります。このキーの初期ディレクトリの値を変更するだけで、プロキシを複数の環境で使用できるようになります。既定値は次のとおりです。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
環境を切り替えるには、キーを次のように変更します。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
バッチ ファイルを作成することで、この処理の管理を簡略化できます。残念ながら、ADFS 用の MMC スナップインの現在のバージョンでは、環境の切り替えはサポートされていません。これは、プロキシとリソース サーバーまたはアカウント サーバーとの間に一対一の関係があるためです。したがって、プロキシ サーバーを最大限に活用するには、バッチ ファイルを作成する必要があります。この結果、ホストする環境の数が増加しても、それに伴って物理サーバーの数を増やす必要がなくなるため、コストが大幅に削減されます。
アーキテクチャの観点から、マイクロソフトでは仮想コンピュータを使用して非運用環境を管理しています。これにより、さらにコストが削減されます。仮想コンピュータを使用することにより、6 台のサーバーを追加で購入し、そのためのスペースを確保したりする必要がなくなります。これまで、パフォーマンスの問題が発生したことはありません。ただし、運用環境ではさらに高速な処理が要求されるため、高性能の物理コンピュータを使用します。

Active Directory 以外の構成について
Microsoft.com では、認証に Active Directory アカウントを使用するだけでなく、Windows Live ID アカウントも使用できるようになりました。Windows Live ID (WLID) 4.5 を使用すると、要求を変換するしくみを独自に作成すれば、個々の Windows Live ID アカウントからマイクロソフトのリソースへのアクセスを委任できることがわかりました。これで特定のドメイン アカウントが不要になるため、SSO 認証を実現するうえで大きな利点が得られます。

今後の課題
現在の最大の課題は、トークン署名証明書を共有するための ADFS の管理です。現在は、通常 1 年後に更新が必要になる標準の証明書を使用しています。更新時には、対応する各サーバーの更新も必要になります。この作業は、FS-R に大きな影響を与えます。15 個または 20 個のフェデレーションであれば何とか管理できますが、マイクロソフトが考えている規模は、数千にまでは及びませんが少なくとも数百にはなります。この場合、各環境に SSL 証明書を管理する常勤のスタッフを配置する必要があります。このソリューションを自動化するための最善策を複数のチームで検討していますが、まだその方法は決まっていません。
残るもう 1 つの課題は、すべてのアプリケーションが既定で ADFS に対応しているわけではないということです。各サイトで ADFS の機能を利用するには、何らかのプログラムを作成する必要があります。現在、次世代の SharePoint で ADFS の実装要件がサポートされるように、Microsoft® Office SharePoint® Services チームと密接に協力しています。

まとめ
ADFS モデルへの移行を決定する際には、多くの要素について考慮する必要があります。1 つは、顧客がアクセスするリソースの数です。フェデレーションを構成している組織間の信頼を設定する処理は簡単ですが、条件に合ったアクセス ポリシーを作成、確認、および適用するには時間と労力がかかります。そのため、顧客がアクセスするリソースが 1 つしかない場合は、そうした労力を注ぐ価値があるかどうかを判断する必要があります。ただし、リソースの数の増加に伴って、メリットも増加します。
詳細については、「Windows Server 2003 R2 の Active Directory フェデレーション サービス (ADFS) の概要」および「Active Directory フェデレーション サービス : 統合された ID およびアクセス管理の実現」を参照してください。

Jim Guthrie は、マイクロソフトの Microsoft.com 運用チームに所属しています。彼は ADFS に関する仕事を担当しているだけでなく、エンタープライズ ポータル プラットフォーム サポート チームのシステム エンジニアでもあります。


 フィールド ノート: 学びの喜び (と苦しみ)
フィールド ノート
学びの喜び (と苦しみ)
Mark D. Scott

新しい ものが発表されたときのワクワクするような感覚は覚えています。ほとんどの人が手にする前に最新のテクノロジを入手したり、製品を徹底的に調査したり、その動作を学習したり、それを機能させるようにしたりする作業はワクワクするものでした。私は、製品の内情に通じた「専門家」として、他の人たちが秘伝の知識を求めてやってくる早期導入者であることを生きがいとしていました。
しかし、いつの頃からか、この喜びに陰りが出始めました。何が起こったのかは定かではありませんが、夜中の 3 時にミッション クリティカルなアプリケーションを動作させるのに失敗したときに、この喜びを失ってしまったのかもしれません。1 台のサーバーで十分事足りていたときに、社内のメール サーバーがダウンしてしまったために、私が読み損なったマニュアルと一緒に、その喜びも床の上に置いてきてしまったのかもしれません。それとも、単に私が年を取って、皮肉っぽくなってしまっただけでしょうか。それはどうでもいいことです。とにかく、10 年ほど前と比べると、夜遅くまで働くことに、あまり魅せられなくなりました。しかし、だからといって、学ぶことをやめてよい理由にはなりません。つい最近、そのことを強く再認識させられました。
最近、私は、Microsoft® Outlook® 2007 にアップグレードして、この製品を非常に気に入っています。しかし、私は MSN® Premium サービスに加入しており、ISP がサービスの一環として MSN Premium サービスを提供しています。以前のバージョンの Outlook では、MSN の電子メール アドレスにアクセスするのに、Connector という名前の特別なソフトウェアが必要でした。このコネクタ ソフトウェアは、Outlook 2007 で動作しなかったので、MSN に問い合わせてみました。MSN に問い合わせると、ISP に問い合わせるように言われました。最終的には、ISP から、Outlook 2007 では MSN Outlook Connector がサポートされないことを知らされましたが、電子メール、文字チャット、音声チャットを行ったり来たり、この情報を得るのに随分と時間がかかりました。
Connector は必要ないのではないか、という考えがひらめきました。Outlook 2007 を起動し、コネクタ ソフトウェアを使わずに MSN への新しい接続を構成しました。Outlook はインターネットに接続してサーバーを検出し、問題なくアカウントを構成しました。私が持っている他のいくつかの POP3 アカウントも構成しましたが、結果は同じでした。このようにして、私は電子メールにアクセスできるようになり、Outlook のすばらしい新機能について学ぶことができました。
このことから教訓を得ました。サポート担当者が新しい製品を試していたら、Connector が必要ないことを私に教えることができ、お互いの時間をかなり節約できたでしょう。
もっと肝心なのは、私が自分で製品を試していれば、おそらく自分で解決策を見つけていたということです。しかし、私はだれかに答えを教えてもらうことを選びました。私たちの日常生活に重要なものの調査にだれも時間を費やさなかったので、お互いに多くの時間を割くことになりました。もし、だれかが腰を据えて自分で問題を解決していたら、お互いの時間を節約できたでしょうし、結局、実際に自分で問題を解決することになりました。
テクノロジの変化は、私たちの予想を裏切ります。IT プロフェッショナルの役割を果たすためには、先入観にとらわれないようにする必要があります。私たちが懸命になって入手している知識は、いずれ新しいテクノロジによって間違いなく置き換えられる知識です。新しいテクノロジをより簡単に使えるようになるには、既存の知識を入れ替える必要があります。苦労して手に入れた知識でも、いつまでも競争上の優位性として利用することはできません。本当の優位性は、テクノロジの動作に関する古びた事実の蓄積ではなく、新しい概念と手法を習得する能力から生まれます。常に学ぶ姿勢を取り続けることによって、学ぶ姿勢を日常業務の一環とし、スキルに磨きをかけることができます。さまざまな新製品が際限なくリリースされるという今日の状況下では、ライフスタイルとして学ぶ姿勢を持ち続ける必要があります。
私に連絡を取りたい場合は、マイクロソフトのアカウントか MSN のアカウントのいずれか宛てにお気軽に英語でメールをください。Outlook 2007 では、どちらのアカウントのメールも受信できるので問題ありません。

Mark D. Scott は Microsoft Consulting Services のシニア コンサルタントです。彼はクライアントと緊密に連携して、大規模なデータ処理を中心としたアプリケーションの設計と構築を支援しています。Mark の連絡先は granddaddy2002@msn.com (英語のみ) または mascott@microsoft.com (英語のみ) です。


 Windows 秘話: バグの力
Windows 秘話
バグの力
Raymond Chen

Windows 95 では、 トラブルシューティングのページにアクセスして、[バッファの同期を取らない] チェック ボックスをオンにすることができました。しかし、このチェック ボックスがどのような処理を行い、なぜ用意されたのかをご存知ですか。
MS-DOS® の Commit 関数の正常な動作は、特定のファイルからディスクに書き込まれていないデータをフラッシュすることで、データが書き込まれたことを確認してから制御を戻します。[バッファの同期を取らない] チェック ボックスがオンになっていると、データが書き込まれるまで待機することなく、すぐに制御が戻ります。もちろん、これは機能仕様に違反します。機能仕様では、データが書き込まれるまで制御を戻さないように規定されています。このオプションにより、フラッシュの要求を発行するプログラムで、実際にはデータがディスクに書き込まれていないのに、データがディスクに書き込まれたと判断されるというリスクが増大します。サポート技術情報の記事 139669 では、これを婉曲的に "ファイルの整合性の問題" と呼んでいます。
データベース プログラムでは、ディスク上のファイルの状態がプログラムで予期している状態と一致する時点を確立する目的に、Commit 関数を使用することがあります。更新中にコンピュータの電源が供給されなくなった場合、データベース プログラムでは、最後にコミットを実行した時点で記録されている情報を使用して、データベースの整合性を回復することができます。コミットが完了する前に Commit 関数から制御が戻ると、この整合性のチェックポイントが失われることになります。その結果、データベースが破損します。
不適切な結果が生じるのに、なぜこのオプションが提供されたのでしょうか。その理由は、Windows® 3.11 にあるバグです。
図 1 Windows Server 2003 でバグの動作を有効にする
図 1 Windows Server 2003 でバグの動作を有効にする (画像を縮小するには、ここをクリックします)
図 1 Windows Server 2003 でバグの動作を有効にする
図 1 Windows Server 2003 でバグの動作を有効にする (画像を拡大するには、ここをクリックします)
Windows 3.11 では "32 ビット ファイル アクセス" が導入されました。これは、下位レベル ファイル I/O インターフェイスの 32 ビット実装です。しかし、Commit 関数の実装には、ファイル バッファをフラッシュする要求を完全に無視するバグがありました。そのため、ファイル バッファをフラッシュするプログラムを Windows 3.11 で実行すると、フラッシュの呼び出しの効果はありません。その結果、不適切なタイミングでコンピュータの電源供給がなくなると、データベースが破損します。
Windows 95 のファイル システムの開発に携わったメンバが、このバグを修正したところ、新しいバグが報告されるようになりました。ある企業の支払勘定プログラムのパフォーマンスが低下したり、他の企業のデータベース プログラムのパフォーマンスが低下したりするなどの報告を受けました。一体何が起こったのでしょうか。
これらのプログラムでは、フラッシュの呼び出しが絶えず行われていたことが判明しました。プログラマは、Windows 3.11 ではフラッシュの要求が非常に高速に行われることを発見したので、プログラムのあらゆる部分にフラッシュの呼び出しを使用しました。バイトを書き込んではフラッシュし、文字列を書き込んではフラッシュし、という具合です。フラッシュは非常に高速な処理だったので、アプリケーションでは、1 つの操作ごとにデータをコミットしても、パフォーマンスが低下することはありませんでした。しかし、このバグが Windows 95 で修正されたことで、Commit 関数が実際の役割を果たすようになり、このバグに依存したプログラムのパフォーマンスが大幅に低下しました。
もちろん、ファイル システム チームが、この報告に対して何の対策も取らなければ、このようなプログラムのパフォーマンスは依然として低いままで、ユーザーは、Windows 95 に問題があるという勘違いをしてしまったことでしょう。そして、「Windows 95 は動作が遅い」と他の人に話したことでしょう。一方、ファイル システムを以前の Windows 3.11 の動作に戻した場合、前述の厄介な "ファイルの整合性の問題" を引き起こすことになります。
そのため、このバグを修正し、バグの修正によって問題が発生するプログラムを実行しているユーザーのために Windows 3.11 の動作に戻すチェック ボックスを追加するという結論に至りました (とはいうものの、このチェック ボックスはトラブルシューティングのページに用意されています)。
歴史は繰り返されるということが判明しました。Windows Server® 2003 では、I/O の開発メンバが、Forced Unit Access (FUA) としてタグ付けされている要求が、FUA タグを失い、通常の I/O として実行されるバグを発見しました。これはフラッシュの要求を無視するという問題の現代版です。開発チームは、このバグを修正しましたが、以前のバグの動作に戻すオプションを用意しました。Windows Server 2003 に用意されたチェック ボックスは "拡張処理能力を有効にする" という名前ですが、この記事を読んだ皆さんは、このチェック ボックスが以前のバグの動作に戻すためのものであることがおわかりですね。

Raymond Chen は自分の Web サイト The Old New Thing および同じタイトルの書籍 (Addison-Wesley、2007) で、Windows の歴史と Win32 プログラミングについて扱っています。彼は枕のネームタグを外す主義です。