 TechNet Magazine September 2007

TechNet Magazine September 2007

Windows Vista: BDD 2007 を使用して Windows Vista を展開する

あなたの組織は Windows 2000 または Windows XP から Windows Vista に移行する準備ができていて、あなたがプロジェクトの責任者だとします。心配しないでください。このステップ バイ ステップ ガイドでは Business Desktop Deployment 2007 Solution Accelerator を使用して、Windows Vista の展開を簡略化する方法について説明します。

Michael Niehaus Windows Vista: Windows Vista バックアップ テクノロジ ガイド

バックアップは、多くの人が手遅れになるまで無視してしまう作業です。しかし、手遅れになってしまっても弁解の余地はありません。特に現在では、新しい Windows Vista バックアップと復元センターが登場し、ほとんどの種類のデータ損失からデータを簡単に保護するためのさまざまな機能が提供されていますから。この記事では、どのように Windows Vista を使用して完全な回復戦略を計画できるかについて説明します。

Christine Fok Windows Server: Active Directory の管理に不可欠な 11 個のツール

大規模な組織では、オブジェクトの追加や変更など、ごく一般的な Active Directory の作業でさえ、面倒で時間がかかる場合があります。この記事で紹介する 11 個のツールを使用すると、Active Directory の管理を大幅に簡略化できます。

Laura E. Hunter Windows Server: Active Directory の廃棄済みオブジェクトを復元する

Active Directory の障害回復計画に組み込む必要がある手法やツールはいくつかありますが、これらの 1 つに廃棄済みオブジェクトの復元があります。廃棄済みオブジェクトの復元は、ドメイン コントローラをオフラインにすることなく、削除されたオブジェクトを回復させることができる唯一の方法です。この記事では、Active Directory の廃棄済みオブジェクトを検索して回復させる方法について説明します。

Gil Kirkpatrick コミュニケーション: Office Communications Server 2007 を使用してユーザーどうしを接続する

ユニファイド コミュニケーションの時代がやってきました。この記事では、Microsoft Office Communications Server 2007 について概説し、統合されたメッセージング、ボイス、ビデオ、および会議機能が、どのように組織の生産性と遠距離のコラボレーションの強化に役立つかについて説明します。

Alan Maddison 編集長から: 学びへの道

Joshua Trupin レター: 質問への回答

ツールボックス: IT プロフェッショナル向けの新製品

Greg Steen SQL に関する Q&A: CPU ボトルネック、データベースの復元と移動など

Edited by Nancy Michell ユーティリティ スポットライト: PageDefrag

Windows 標準のデフラグ ツールでは、ハード ディスク上のほとんどのファイルを最適化できます。ただし、Windows ページ ファイルやレジストリ ハイブなどの特定のアイテムは、ほとんどのデフラグ ツールでは処理できません。ここでご紹介する Mark Russinovich が Sysinternals のために開発した PageDefrag ユーティリティは、他のツールでは処理できないファイルをデフラグしてくれます。

Lance Whitney The Cable Guy: 強力なホスト モデルと弱いホスト モデル

マルチホーム ホストは、複数のネットワークに同時に接続することで、強化された接続を提供します。ただし、マルチホーム ホストで実行されているサービスは、より攻撃を受けやすくなります。この記事では、それらの攻撃からコンピュータを保護するために、マルチホーム ホストのさまざまなホスト モデルと、Windows でそれらのモデルがどのようにサポートされているかについて説明します。

Joseph Davies Windows PowerShell: シェルのセキュリティ保護

マイクロソフトは、Windows PowerShell をデザインするときに、セキュリティに主眼を置きました。そして、その目的を実現しました。この記事では、VBScript では発生する可能性があった問題を Windows PowerShell では発生しないようにする、資格情報の処理や実行ポリシーなどの重要なセキュリティ機能と設定の一部を紹介します。

Don Jones Hey, Scripting Guy!: このリレーションシップを救うことはできますか

リレーショナル データベースは一対多のリレーションシップを扱うために設計されました。このため、このようなデータベースを照会するスクリプトを記述する作業は、少し厄介になることがあります。しかし、Scripting Guys が必要な情報すべてを説明するので、心配ご無用です。

The Microsoft Scripting Guys Exchange に関する Queue & A: セットアップ、メッセージ ジャーナリング、ストレージのオプションなど

メッセージ ジャーナリングをどのように使用して社内の電子メールを監視できるか、Office 2003 ユーザーがユニファイド メッセージングを使用できるか、Exchange 2007 の実装に使用するストレージの検討、Exchange 2007 に古いバージョンの Outlook を使用して接続したときに発生する問題などについて説明します。

KC Lemson and Nino Billic セキュリティ ウォッチ: ユーザー アカウント制御の長期的な影響

どれだけ頻繁に取り上げても、ユーザー アカウント制御については、いまだに多くの疑問と誤解があります。ここでは、UAC が何であって何ではないのか、またシステム管理の方法にどんな影響を与えるのかを、率直に説明します。

Jesper M. Johansson デスクトップ ファイル: Windows PE を使用した PC の復旧

Windows Vista には、システムの復旧を簡単にする有用なツールがいくつか用意されています。しかし、大規模かつ多様な組織では、既存のソリューションではうまくいかないのが普通です。もしあなたが、カスタマイズした自己復旧ソリューションの構築を必要とする大企業で働いているならば、Windows PE を使用した独自の復旧ソリューションの構築について説明するこのコラムをぜひお読みください。

Wes Miller フィールド ノート: フリー フードとトレーニングのヒント

問題を最小限に抑えるには、適切なユーザー教育が不可欠です。不定期にトレーニング セッションを開催し、ユーザーが質問をしやすいように社内を歩き回ることはとても重要です。

Michael Dragone Windows 秘話: 既知の DLL のバランスを取る

既知の DLL という機能は、パフォーマンスを向上する手段として Windows に含まれていました。この機能の動作を理解し、時間の経過と共にどのように変わってきたのかを見てみましょう。

Raymond Chen


 Windows Vista: BDD 2007 を使用して Windows Vista を展開する
Windows Vista Michael Niehaus

BDD 2007 を使用して Windows Vista を展開する
概要:
  • BDD 2007 Solution Accelerator
  • イメージを準備する
  • ドライバとアプリケーション パッケージ

あなたは、この作業を先延ばしにしてきましたが、とうとう、やらなければならない時が来てしまいました。組織には、Windows 2000 または Windows XP から Windows Vista に移行する必要があるコンピュータが何百台も、もしかしたら何千台もあります。そして、この移行作業を実行するのはあなたのチームの仕事です。
はじめに
Windows® オペレーティング システムを何年もインストールしている方は、Windows NT® 3.5 から Windows XP までのオペレーティング システムでは、変更点が比較的少なかったことにお気付きでしょう。インストールと構成のプロセスには一貫性があり、ツールは同じで、全体的なプロセスにも変更がありませんでした。しかし Windows Vista® では、プロセス全体が再設計され、新しいツールも数多く追加されています。変更点と変更点による影響のわかりやすい概要については、TechNet Magazine の 2006 年 11 月号の記事「Windows Vista の展開について知っておきたい 10 のポイント」を参照してください。この記事は technetmagazine.com/issues/2006/11/Deployment からオンラインでも参照できます。

新しいプロセスやツールの学習方法
次の 2 つの方法があります。
  1. 新しいツールを 1 つずつ学習します。入手できるすべてのドキュメントを調査します。既存のプロセスに各ツールを導入する方法を特定します。必要な調整を行います。そして、結果を検証します。
  2. 上記の処理が既に行われている何かを利用します。
もちろん、1 つ目の方法を選んでもよいのですが、雑誌の記事ではなく本 1 冊分の説明が必要になってしまいます。ここでは、2 つ目の方法をお勧めします。ここで使用する "何か" とは、Business Desktop Deployment (BDD) 2007 Solution Accelerator です。これは、Microsoft® デスクトップ展開センター (microsoft.com/desktopdeployment) からダウンロードできます。
BDD 2007 Solution Accelerator は、Windows Vista で導入されたすべての新しい展開プロセスとツールをまとめ、Windows オペレーティング システムの展開手続きを簡略化する一連のツール、ガイダンス、およびステップ バイ ステップの手順を提供する製品です。
BDD 2007 を使用するには、BDD 2007 をインストールする Windows XP コンピュータまたは Windows Server® 2003 コンピュータを特定します。BDD 2007 をインストールする前に、まず Microsoft .NET Framework 2.0 と Microsoft 管理コンソール (MMC) 3.0 をインストールする必要があります。その後、BDD 2007 をインストールすることができます。BDD 2007 をインストールしたら、リリース ノートを確認します。これは [スタート] メニューの [BDD 2007] フォルダからアクセスできます。その後、Deployment Workbench のショートカットを使用して MMC スナップインを起動します (図 1 参照)。
図 1 BDD 2007 Deployment Workbench の起動
図 1 BDD 2007 Deployment Workbench の起動
この時点で、[Information Center] (情報センター) で入手できる情報、特に [Getting Started] (はじめに) のチェックリストとドキュメントを確認することをお勧めします。[Components] (コンポーネント) ノードを右クリックし、[Check for Updates] (更新の確認) を選択して、最新の情報とコンポーネントをダウンロードします。
もう 1 つの前提条件に Windows 自動インストール キット (AIK) があります。BDD 2007 で実行される機能の多くでは Windows AIK に収録されているツールが必要です。Windows AIK は、次の 2 つの方法で入手できます。Microsoft ダウンロード センター (http://go.microsoft.com/fwlink/?LinkId=85377) からダウンロードする方法、または Deployment Workbench の [Components] (コンポーネント) ノードを使用して自動的にダウンロードする方法です。どちらの方法でも、ファイルのサイズが非常に大きいので、ダウンロードに時間がかかることを考慮してください。
Windows AIK をインストールしたら、次の段階に進むことができます。次は、Windows Vista の展開に必要なすべてのファイルの収集です。

必要なファイル
この段階では、Windows Vista のインストール ファイル、インストールするアプリケーション、ハードウェアに必要なドライバ、および必要な Windows Vista の更新プログラムまたは言語パックを収集します。これらのファイルはすべて、BDD 2007 をインストールしたときに作成された配布共有のディレクトリ構造にコピーします。
独自のカスタム イメージを作成する
この記事で説明している手順は、標準的な Windows Vista のイメージをマイクロソフト製品 DVD から直接展開する方法です。しかし、2007 Microsoft Office system など、すべてのコンピュータに必要な追加のアプリケーションを含む、カスタマイズされたイメージを展開したい場合もあるでしょう。これは、有名な問題です。最小限のものがインストールされたシン イメージを使用し、展開時にそれ以外のものをインストールするべきでしょうか。それとも、すべてのものがプレインストールされた大きなシック イメージを作成するべきでしょうか。展開にかけられる時間、イメージの作成や保守に必要な管理作業、ネットワーク容量などの要因によって、結論は異なることがあります。ほとんどの状況ではシン イメージの方が適していますが、どちらを使用するのかを決定するのはあなたです。
イメージに含めるものに関係なく、カスタム イメージを作成するプロセスは完全に自動化するようにしてください。このプロセスが自動化されていると、プロセスにもう 1 つ手順を追加して、プロセス全体を再実行し、最後に新しいイメージをキャプチャするだけで、イメージを更新できます。
では、BDD 2007 でこの作業を行うにはどうすればよいでしょうか。この作業は実に簡単です。
  1. カスタム イメージを作成するためのビルドを作成する。
  2. このビルド用のタスク シーケンスを変更して、すべてのカスタム手順を含める。
  3. Windows PE の ISO から起動して、ラボ展開ポイントからベアメタル展開を実行し、ビルドを選択する。
  4. ワークグループへの参加を指定する。
上記の手順を実行すると、展開ウィザードでは別のウィンドウが表示されます。
参照コンピュータのイメージのキャプチャを選択することによって、BDD 2007 では自動的に Sysprep を実行して、オペレーティング システムでキャプチャの準備を整えます。その後 Windows PE で再起動し、ImageX.exe を実行して新しい WIM イメージをキャプチャします。キャプチャしたイメージは Deployment Workbench にインポートして、次回の展開に使用できます。
BDD 2007 を使用した参照イメージのキャプチャ
BDD 2007 を使用した参照イメージのキャプチャ

まず、OS のインストール ファイルをコピーします。Windows Vista DVD (できればインストールごとに個別のプロダクト キーが必要ないボリューム ライセンス メディア) を挿入し、Deployment Workbench の [Operating Systems] (オペレーティング システム) ノードを右クリックし、[New command] (新しいコマンド) を選択して [New OS Wizard] (新しい OS のウィザード) を起動します。[Full Set of Source Files] (ソース ファイル一式) を選択し、DVD ドライブのパス (既に他の場所にインストール ファイルをコピーしている場合は、そのパス) を指定します。残りのページでは既定値を使用して、ウィザードを完了します。ここで [Operating Systems] (オペレーティング システム) ノードをクリックすると、一覧に 1 つ以上の OS イメージが表示されます。
次はアプリケーションです。この時点でアプリケーションを追加する必要はありませんが、追加する場合は、Windows Vista を展開するときに一覧から選択することができます。アプリケーションのインストールが開始されるのをユーザーが待機しなければならないのは好ましいことではないので、コマンド ラインを指定してユーザーの操作なしでアプリケーションをインストールするのが理想的な処理でしょう。この操作がどのようなものかご覧に入れるために、ここではアプリケーションを 1 つ追加してみましょう。Deployment Workbench の [Applications] (アプリケーション) ノードで [New] (新規) を選択し、[New Application Wizard] (新しいアプリケーション ウィザード) を完了します (図 2 参照)。
図 2 Workbench へのアプリケーションの追加
図 2 Workbench へのアプリケーションの追加
その次は OS パッケージです。皆さんが関心を持つのは、言語パック、セキュリティ更新プログラム、および Windows Vista コンポーネントの 3 種類のパッケージでしょう。
言語パックを使用すると Windows Vista をさまざまな言語で実行することができます。サポートされている言語の詳細については、microsoft.com/globaldev/vista/Vista_Language_Support.mspx を参照してください。言語パックは CAB ファイル形式でパッケージ化されていて、すべてのソフトウェア アシュアランスをご契約いただいているお客様は licensing.microsoft.com からダウンロードできます。Windows Vista Ultimate を実行している場合は、Windows Update から入手できます (コンピュータにインストールされた多言語パックは、Windows Vista Enterprise と Windows Vista Ultimate でのみサポートされることに注意してください)。
通常、Windows Vista のセキュリティ更新プログラムは毎月公開され、microsoft.com/technet/security/bulletinsandadvisories から個別に MSU ファイル形式でダウンロードできます。
また、Windows PowerShell™ などの新しい Windows Vista コンポーネントを含めることができます。このようなコンポーネントは、Microsoft ダウンロード センター (microsoft.com/downloads) からダウンロードできます。これらのコンポーネントも MSU ファイル形式でパッケージ化されています。
実際には、OS パッケージはすべてコンポーネントです。このようなコンポーネントは、パッケージとも呼ばれることから、[OS Packages] (OS パッケージ) ノードという名前になりました。これらのコンポーネントはすべて、オンライン (OS が起動しているとき) またはオフライン (OS が起動していないとき) で、Windows Vista に追加できます。BDD 2007 の場合、これらのコンポーネントは、Windows Vista のイメージを展開しディスクに配置してから、最初に OS を起動するまでの間に、必ずオフラインで追加します。
もう 1 つ問題があります。MSU ファイルは、Windows Vista の実行中に WUSA.EXE (Windows Update スタンドアロン インストーラ) を使用して、オンラインでインストールするようデザインされています。しかし、この記事で紹介する手順では更新プログラムをオフラインでインストールします。このため、実際のコンポーネントを含む CAB ファイルが必要です。MSU ファイルには、実際のコンポーネント CAB ファイルが含まれているので、MSU ファイル自体が CAB ファイルになっています。したがって、次のようなコマンドを使用して、CAB ファイルを MSU ファイルから展開できます。
EXTRACT.EXE file.msu -F:*.CAB C:\
このコマンドを実行すると、インポートする必要がある CAB ファイルを入手できます。マイクロソフトでは、この展開を自動実行する BDD 2007 の修正プログラムをリリースしました。この修正プログラムをインストールすれば、この手作業は不要になり、MSU ファイルで BDD 2007 を指定すると、後は BDD 2007 が処理します。この修正プログラムの詳細については、support.microsoft.com/kb/937191 を参照してください。
これらのコンポーネントを Deployment Workbench に追加するには、[OS Packages] (OS パッケージ) ノードを右クリックし、[New] (新規) を選択して、[New Package Wizard] (新しいパッケージ ウィザード) を開始します。このウィザードで、追加するパッケージが格納されているフォルダのパスを指定します。
最後に、Windows Vista を実行するコンピュータ ハードウェアのドライバが必要な場合があります。必要なドライバをベンダの Web サイトまたは Microsoft Update から検索してダウンロードし、パッケージ化されたドライバを展開します。この最後の段階は少し複雑になることがありますが、最終的には、未加工のドライバ ファイル (ドライバ自体に必要な .inf、.sys、.dll、および関連ファイル) を入手する必要があります。
ドライバ ファイルを展開したら、[Drivers] (ドライバ) ノードを右クリックし、[New Deployment] (新しい展開) を選択して、[New Driver Wizard] (新しいドライバ ウィザード) を実行します。Deployment Workbench ではディレクトリ構造をスキャンしてすべての .inf ファイルを検索するため、展開したディレクトリを整理する必要はありません。
ドライバがインポートされると、Deployment Workbench では、サポートされるプラットフォーム、製造元とバージョン、およびドライバでサポートされるプラグ アンド プレイ (PnP) ID の一覧を含む、ドライバの全詳細のカタログが作成されます。

ドライバをインポート済みのオペレーション システム イメージに追加する
BDD 2007 ではインポートした OS イメージを変更しません。代わりに、ドライバは展開プロセスで追加されます。基本的な手順は、次のとおりです。
  1. 展開中のコンピュータでユーティリティ (Microsoft.BDD.PnpEnum.exe) を実行し、そのコンピュータに存在するすべての PnP ID を特定します。
  2. ドライバ カタログで各 PnP ID を検索します。一致する PnP ID が見つかったものについては、必要なドライバ ファイルをコンピュータにコピーします。
  3. Windows Vista セットアップに指示をして、イメージがディスクに適用されてから、最初に Windows Vista を起動するまでの間に、ドライバが OS に追加されるようにします。大容量記憶装置ドライバなど、オペレーション システムの起動に必要なドライバがあるので、必ずこのように指示してください。

その他の準備
展開するには、あとほんの少しだけ作業が必要です。まず、ビルドを定義して、配布共有のオペレーティング システムと、OS のインストールと構成に使用する設定やそのために実行が必要な一連のタスク関連付ける必要があります。
このビルドを作成するには、[Builds] (ビルド) ノードを右クリックし、[New] (新規作成) を選択して、[New Build Wizard] (新しいビルド ウィザード) を起動します。ビルド ID (空白文字や特殊文字を含まない任意の単純な値)、ビルド名、およびビルドの説明を指定します。ビルド名とビルドの説明は、どちらもオペレーティング システムを展開するときに表示されます (図 3 参照)。次に、インストールするオペレーティング システムを選択し、使用する基本設定をいくつか指定します。
図 3 基本的なビルド情報の指定
図 3 基本的なビルド情報の指定

最後の準備
あと 1 つ必要な準備作業は展開ポイントの作成です。簡単に言うと、展開ポイントとは、これまでに収集したすべてのファイル、ビルドの全詳細、および展開プロセスで使用する Windows PE イメージを含む、ネットワーク共有です。展開ポイントの作成は、これまでの他の手順と同様に行えます。[Deployment Points] (展開ポイント) ノードを右クリックし、[New] (新規作成) を選択します。[Lab or single-server deployment] (ラボまたは単一サーバーでの展開) を選択し (図 4 参照)、残りのページについては既定値を使用します。
図 4 展開ポイントの種類の選択
図 4 展開ポイントの種類の選択
ウィザードが完了したら、一覧ウィンドウで新しい展開ポイントを右クリックし、[Update] (更新) を選択して、ネットワーク共有と Windows PE イメージを生成します。
この前の段階で追加したドライバを覚えているでしょうか。Windows PE でも、追加したドライバと同じもの、少なくともネットワーク ドライバと大容量記憶装置ドライバが必要です。この更新プロセスではドライバを自動的に Windows PE イメージに追加します。

準備完了
これで展開する準備が整いました。まず、新しいコンピュータに展開してみましょう。\distribution\boot フォルダから LiteTouchPE_x86.iso ファイルをコピーし、お好みの CD-ROM ライタまたは cdburn.exe を使って、CD-R に書き込みます。cdburn.exe は Microsoft ダウンロード センター (go.microsoft.com/fwlink/?LinkID=77796) からダウンロードできます。コンピュータを CD から起動すると、Windows PE が起動され、図 5 のような初回実行時の開始ウィザードが表示されます。
図 5 展開開始の準備完了
図 5 展開開始の準備完了
[Run the Deployment Wizard] (展開ウィザードを実行する) を選択し、[Next] (次へ) をクリックしてウィザードを開始します。このウィザードでは、定義したビルド、追加したアプリケーション、およびインポートした言語パックを選択できます。また、ドメインに参加したり、コンピュータ名を指定したり、他のさまざまな設定を構成したりすることができます。(Sysprep、Windows PE、および ImageX を使用して新しいイメージ ファイルを作成して) 新しいカスタム イメージを自動的にキャプチャするように指定することもできます。
(コンピュータの速度と種類によっては) 展開にしばらく時間がかかることがありますが、ユーザーによる操作は必要ありません。展開ウィザードが完了すると、概要ページが表示され、展開プロセス中にログに記録された警告やエラーが通知されます。このページにより、展開が正常に行われたかどうかを簡単に確認できます。黄色または赤の概要ページは詳細を調査する必要があることを表し、白いページはすべての処理が正常に行われたことを表します。
今度は、Windows XP を既に実行しているコンピュータに展開してみましょう。コマンド プロンプトで次のコマンドを実行し、BDD 2007 サーバーに作成した Distribution$ 共有にドライブを割り当て、LiteTouch.vbs を実行して展開を開始します。
NET USE M: \\MyServer\Distribution$
cscript.exe M:\Scripts\LiteTouch.vbs
このコマンドを実行すると、先ほどと同じ展開ウィザードが開始されます。ただし、今回はいくつかの新しいオプションが表示されます (図 6 参照)。
図 6 Windows XP を実行するコンピュータに展開する場合のオプション
図 6 Windows XP を実行するコンピュータに展開する場合のオプション
[Refresh this computer] (このコンピュータを更新する) を選択すると、既存の OS は削除され、Windows Vista の新規インストールが実行されます。この際、必要に応じて、既存の OS を削除する前に、ユーザー状態移行ツールを使用して、ユーザー データとユーザー設定をキャプチャすることができます。このツールは、Windows AIK と同様に [Components] (コンポーネント) ノードからダウンロードする必要があります。[Upgrade this computer] (このコンピュータをアップグレードする) オプションを選択することもできます。このオプションを選択すると、Windows Vista セットアップでは、コンピュータにインストールされている既存のアプリケーション、データ、および設定を維持したまま、既存の OS のアップグレード処理が行われます。選択するオプションはさまざまな要因で変化しますが、ほとんどのユーザーには、更新を実行し、クリーンで状態が管理されている OS を使用することをお勧めします。

まとめ
Windows XP を展開する場合について
Windows XP を展開する場合はどうでしょうか。心配しないでください。Windows XP の展開にも、BDD 2007 を使用できます。手順は同じです。Windows XP インストール ファイルを使用して最初のビルドを作成し、Windows XP の新しい Windows Imaging (WIM) イメージをキャプチャし、今後の展開には、この新しい WIM ファイルを使用します。Windows XP イメージの展開は無人インストールよりもずっと高速です。
Windows Vista の展開と比べ、Windows XP を展開するときは次のような厄介な作業が生じることに注意してください。
Windows XP の大容量記憶装置ドライバには、TEXTMODE フォルダ、unattend.txt 設定、sysprep.inf 設定などの、追加の構成作業が必要です。もちろん、既存の Windows XP イメージには大容量記憶装置ドライバを追加することはできないので、大容量記憶装置ドライバを追加する必要があるたびに、新しいイメージをキャプチャする必要があります。また、Windows XP イメージは HAL に依存しているので、2 ～ 3 個のイメージが必要になることがあります。また、言語パックとセキュリティ更新プログラムは Windows XP にオフラインで追加できないので、Windows XP を起動し実行してからインストールする必要があります。
Windows XP の展開に BDD 2007 を使用すると、Windows Vista を展開する準備はできたも同然です。あとは展開する時期を決めるだけです。

この記事では、ほんの概要を説明しただけです。しかし、プロセスの開始から終了までを紹介したので、個々のツールについて学ばなくても、すべての新しいツールが連携して機能するようすを理解していただけたでしょう。これで、BDD 2007 のスクリプトやログを詳しく調べて、実行されたことを確認できます。独自のカスタム イメージを作成し、BDD 2007 に追加して、標準的な Windows Vista のイメージの代わりに展開できます。作成したイメージを格納した DVD メディアや USB フラッシュ ドライブを作成できます。また、SMS 2003 と SMS 2003 の OS Deployment Feature Pack をプロセスに統合することもできます。

詳細情報
この記事で、紹介していないすべてのドキュメントを確認してください。1,000 ページを優に超えるドキュメントが利用でき、これらのドキュメントは、通常、展開プロジェクトにかかわっているさまざまなチームが分担しています。既に紹介済みですが、microsoft.com/desktopdeployment サイトも参照してください。microsoft.public.deployment.desktop ニュースグループをご利用ください。皆さんのような IT プロフェッショナルが Windows 展開に関するあらゆる種類の質問をしています。BDD 2007 と Windows Vista の展開について豊富な情報が掲載されている deployvista.com や myitforum.com などの、サードパーティの Web サイトを参照してください。Microsoft Press から入手できる、新刊『Windows Vista Resource Kit』(microsoft.com/mspress/books/9536.aspx) を参照してください。BDD 2007 のさまざまなパーツについて説明している私のブログ (blogs.technet.com/mniehaus) をご覧ください。お住まいの地域で利用できる BDD 2007 と Windows Vista のトレーニング セミナーについて、最寄りのマイクロソフトの担当者にお問い合わせください。また、詳細情報については、補足記事の「展開に関する詳細情報」を参照してください。
Microsoft Office System のソフトウェア アシュアランスをご契約されている場合は、デスクトップ展開計画サービス (microsoft.com/licensing/sa/benefits/deployment.mspx) をご利用ください。このサービスでは、マイクロソフトまたはマイクロソフトのパートナー企業が、数日間かけてお客様と共に計画を練り、お客様のサイトで概念実証ラボにも取り組みます。
展開に関する詳細情報
  • Microsoft デスクトップ展開センター (microsoft.com/desktopdeployment)
  • Windows Vista の展開について知っておきたい 10 のポイント (technetmagazine.com/issues/2006/11/Deployment)
  • Microsoft .NET Framework 2.0 (go.microsoft.com/fwlink/?LinkId=94601)
  • Windows Server 2003 x86 用 Microsoft 管理コンソール (MMC) 3.0 (go.microsoft.com/fwlink/?LinkId=94602)
  • セキュリティ情報およびアドバイザリ (microsoft.com/technet/security/bulletinsandadvisories)

Michael Niehaus は、マイクロソフトの Solution Accelerators チームに所属するシステム デザイン エンジニアで、ビジネス デスクトップ展開のベスト プラクティス、ツール、およびスクリプトの開発を担当しています。連絡先は michael.niehaus@microsoft.com (英語のみ) です。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Windows Vista: Windows Vista バックアップ テクノロジ ガイド
Windows Vista Christine Fok

Windows Vista バックアップ テクノロジ ガイド
概要:
  • ファイルのバックアップと復元
  • Windows Complete PC バックアップと復元
  • システムの復元
  • シャドウ コピー

手遅れになり、データが失われてしまうまで、バックアップを考慮しない人が多すぎます。あってはならないことですが、残念ながらこれは現実です。Windows Vista では、バックアップを容易に実行できるよう、データをシームレスに保護するためのさまざまな機能を提供しています。
従来のシステムの復元は、より堅牢で、さらに多くのシステム修復シナリオに対応する機能となるよう、再設計されています。また、ファイルのバックアップがより簡単で包括的なデータ保護を目指して機能強化されているほか、Windows® Complete PC バックアップと復元およびシャドウ コピーという 2 つの新機能が追加されています。
これらの機能はすべて、なんらかの形でボリューム シャドウ コピー サービスに依存しています。これは、ボリュームのある時点のコピー ("シャドウ コピー" と呼びます) を作成し、シャドウ コピー間の変更を追跡するサービスです。
これら 4 つの機能はすべて、バックアップと復元センター (図 1 を参照) から利用でき、データのバックアップと復元機能を提供しますが、それぞれは大きく異なっています。しかし、これらを総合的に利用することで、コンピュータの使用期間を通じてさまざまな形のデータ損失に対し幅広い保護が提供されます。
図 1 Windows Vista のバックアップと復元センター
図 1 Windows Vista のバックアップと復元センター

ファイルのバックアップ
Complete PC バックアップのスケジュールを設定する
定期的な Complete PC バックアップのスケジュールを設定することは、コンピュータ全体の最近のイメージを確保するための 1 つの方法です。Complete PC バックアップのスケジュールは、コントロール パネルからは設定できませんが、タスク スケジューラで新しいタスクを作成することで設定できます。Complete PC バックアップのスケジュールを設定する場合は、定期的に監視を行い、バックアップが正常に完了していることを確認することをお勧めします。この作業が必要な理由は、ディスク容量の問題や他の一時的な問題のためにバックアップが失敗した場合に、ポップアップによる通知が行われないためです。これは、ファイルのバックアップを定期的に使用する方法の代わりにはならないと考えてください。それでは、次に、タスク スケジューラを使用して Complete PC バックアップのスケジュールを設定する方法を説明します。
  1. タスク スケジューラを開きます。これを行うには、[スタート] ボタンをクリックし、[すべてのプログラム] をクリックします。次に、[アクセサリ] をクリックし、[システム ツール] をクリックします。
  2. [タスクの作成] をクリックします。
  3. [全般] タブを開きます。
  4. 「定期的な Complete PC バックアップ」など、わかりやすい名前を入力します。
  5. ログオンしているかどうかにかかわらずこのタスクを実行する場合は、[ユーザーがログオンしているかどうかにかかわらず実行する] をクリックします。
  6. [最上位の特権で実行する] をクリックします。
  7. [トリガ] ページを開きます。
  8. [新規] をクリックし、定期的なバックアップを実行するタイミングと方法を指定します。
  9. [操作] ページを開きます。
  10. [新規] をクリックします。
  11. [プログラム/スクリプト] に「wbadmin」と入力します。
  12. [引数の追加 (オプション)] に次のコマンドを入力します。必要に応じて、バックアップ対象のドライブ文字は変更してください。
    Start backup –allcritical –backupTarget:D: -quiet
    システム ボリューム、ブート ボリューム、および Windows 回復環境ボリューム以外のボリュームを追加する場合は、次のステートメントを代わりに使用します。ドライブ文字 E: および F: (文字間はカンマで区切ります) は必要に応じて変更してください。
    Start backup –allcritical –backupTarget:D: -include:E:,F: -quiet
    コマンドには、常に allcritical フラグを指定するようにします。このフラグを指定しないと、バックアップに重要なシステム ボリュームが含まれない可能性があり、これは復元中のエラーにつながります。
  13. その他のタスク関連の設定を構成します。
  14. [OK] をクリックします。

新しいラップトップ コンピュータを購入したとします。写真や Microsoft® Word 文書などさまざまなファイルを新しいシステムにコピーし、アプリケーションをインストールし、最新の Windows 更新プログラムをダウンロードしたところで、ファイルのバックアップを実行することにします。そこで、外付けのハード ドライブをラップトップに接続し、バックアップと復元センターを開きます。[ファイルのバックアップ] ボタンをクリックすると、手順に従ってセットアップを完了するためのウィザードが表示されます。このウィザードでは、バックアップ先 (この例では、外付けのハード ドライブ)、バックアップするファイルのカテゴリ (写真など)、およびバックアップを実行するタイミングを指定するよう求められます。
ファイルのバックアップでは、カテゴリに基づいた方法で、バックアップするファイルの種類を指定します。バックアップ元のドライブ フォーマットは NTFS である必要がありますが、バックアップ先のハード ドライブは NTFS でも FAT でもかまいません。ファイルが特定のカテゴリに関連付けられているかどうかは、MIME の種類、アプリケーションの関連付け、およびファイルの拡張子という 3 つの要素により決まります。
どのカテゴリにも当てはまらないファイルをバックアップする場合は、[他のファイル] を選択します。これには、Windows によって認識されない拡張子のファイルが含まれます。ただし、実行可能ファイルとシステム ファイルはサポートされていません。このようなファイルは、ユーザー データであることはほとんどないため、この機能ではバックアップされません。このメカニズムを使用してシステム ファイルおよび実行可能ファイルをバックアップする必要がある場合は、これらを .zip ファイルに格納して、ウィザードで [圧縮ファイル] を選択します。
新しいラップトップでバックアップ機能を使用するのは今回が初めてなので、完全バックアップ (選択したカテゴリのすべてのファイルの完全なバックアップ) を直ちに実行します。これ以降は、増分バックアップのみを実行します。ファイルのバックアップでは、"増分" は新しいまたは更新されたファイルのみを追跡することを意味します。たとえば、古い Word 文書があり、これを変更した場合、ファイルのバックアップ ツールでは、古い文書と更新された文書の両方の完全なコピーが保持されます (完全バックアップとその後作成された一連の増分バックアップを合わせたものを、バックアップ セットと呼びます)。
無期限に増分バックアップを実行するのではなく、時折完全バックアップを実行してください。これをいつ実行するかは、最後に完全バックアップを実行してからの期間、バックアップしているファイル数、バックアップに使用している CD または DVD の枚数などにより判断します。これは、ベースラインとなる完全バックアップを確保しておくためです。
バックアップされるデータは、.zip ファイル形式 (1 ファイルあたり最大 200 MB) で保存されます。これにより、ほとんどの環境でこのデータにアクセスできるようになります。たとえば、バックアップ メディアを直接参照することで、Windows Vista を実行していないコンピュータにデータを復元できます。バックアップ データは、個別のファイルに保存されるため、複数のディスクに分散して格納することができます。あるディスクで障害が発生しても、他のメディアのバックアップ データにはアクセスできます。
ファイルのバックアップでは、ボリューム シャドウ コピー サービスを使用して、開かれているファイルまたはアプリケーションが使用しているファイルの一貫性のあるコピーが作成されます。バックアップ処理中に、バックアップ アプリケーションはこれらの一貫性のあるコピーを読み取ります。これは、たとえば Microsoft Outlook® により常時開かれている .pst ファイルをバックアップする場合などに便利です。ボリューム シャドウ コピー サービスにより、バックアップされる .pst ファイルの状態の一貫性が保証されるため、復元時にもこのファイルにアクセスできます。
ファイルのバックアップは、自動的には削除されません。ただし、空き領域が少ない場合には、手動でファイルのバックアップを削除できます。その際、注意することは、個々の増分バックアップを削除するのではなく、必ずバックアップ セット全体を削除するようにしてください。
また、ファイルのバックアップを別の場所にコピーしないようにしてください。別の場所にコピーする必要がある場合は、元の単一のバックアップ メディアから別の単一のバックアップ メディアに移動する場合のみ有効であることに注意してください。たとえば、1 枚の CD から 1 枚の DVD にバックアップ データをコピーすることはできますが、複数の CD から 1 枚の DVD にバックアップ データをコピーすることはできません。バックアップを移動するときは、バックアップ メディアのルートに格納されている、コンピュータの名前が付いたバックアップ フォルダと mediaid.bin ファイルをコピーする必要があります。移動されたファイルを復元する場合、コンピュータ上のバックアップ カタログに新しいバックアップの場所が登録されていないため、このようなファイルにアクセスするには、バックアップ コントロール パネルから [詳細な復元 別のコンピュータで作成したバックアップからファイルを復元したり、このコンピュータのすべてのユーザーのファイルを復元したりします] を選択する必要があります。

Complete PC バックアップ
新しいラップトップでの設定と構成がすべて完了したので、完全バックアップを実行し、OS、インストールしたアプリケーション、構成設定、更新プログラムを含む、コンピュータ全体を保護することにします。この場合は、Complete PC バックアップ機能を使用します。この機能は、ハード ドライブの障害や他の問題が発生した場合に、コンピュータを回復させるために使用できます。すべてのアプリケーションを個別に再インストールしたり、構成設定をすべてやり直す必要はありません。この機能の初回実行時には、情報が格納されていないブロックを除き、選択したボリュームのすべてのブロックの完全バックアップが実行されます。その後は、ブロック レベルで差分バックアップが実行されます (詳細は後述)。
バックアップを実行すると、バックアップと復元センターのコントロール パネルが更新されます (図 2 を参照)。バックアップ後は、バックアップが実行された日時やバックアップの保存先などの情報が表示されます。
図 2 以前のバックアップについての詳細が表示されたバックアップと復元センター
図 2 以前のバックアップについての詳細が表示されたバックアップと復元センター
どちらもバックアップを実行しますが、Complete PC バックアップの動作はファイルのバックアップとはまったく異なります。Complete PC バックアップでは、仮想ハード ドライブ (.vhd) 形式で、コンピュータ全体のブロック レベルのイメージのバックアップが作成されます。初回の完全バックアップの実行中に、Complete PC バックアップ エンジンはバックアップ元のディスクをスキャンし、データが含まれているブロックをバックアップ先のディスクに保存されている .vhd ファイルにコピーします。バックアップされたデータは圧縮されませんが、このファイルのサイズは大きくありません。
次の Complete PC バックアップの実行時には、新しいデータと変更されたデータのみが .vhd ファイルに書き込まれ、同じブロック内の古いデータはシャドウ コピー記憶域に移動されます。スナップショット間の差分を計算する処理と、バックアップ先ディスクのシャドウ コピー領域に古いデータを移動する処理には、ボリューム シャドウ コピー サービスが使用されます (図 3 を参照)。この方法により、(変更されたブロックのみをバックアップすることで) 高速に、(データのサイズを抑えて保存することで) 効率よくバックアップを実行できるようになります。バックアップ先のディスクで利用できるシャドウ コピー記憶域の最大サイズは、バックアップ アプリケーションにより定義されています。Complete PC バックアップ システムを使用した定期的なバックアップや自動バックアップを実行するための詳細な手順については、補足記事「Complete PC バックアップのスケジュールを設定する」を参照してください。
図 3 Complete PC バックアップと復元におけるデータの流れ
図 3 Complete PC バックアップと復元におけるデータの流れ
データを復元するときは、ブロックがそれぞれの元の場所に復元されます。古いバックアップから復元を行う場合、エンジンはシャドウ コピー領域からデータを読み取り、適切なブロックを復元します。
Complete PC バックアップでは、NTFS 形式でフォーマットされたディスクのみをバックアップできます。バックアップ先がハード ドライブである場合は、これも NTFS 形式でフォーマットされている必要があります。

システムの復元
システムの復元は、既定で有効になっています。システムの復元ウィザードには、バックアップと復元センターの左上の部分にある [システムの復元を使って Windows を修復] を選択してアクセスします ([スタート] メニューの [すべてのプログラム] をクリックし、[アクセサリ] をクリックして [システム ツール] をクリックしてもアクセスできます)。[別の復元ポイントを選択する] を選択して [次へ] をクリックすると、ラップトップのセットアップ、アプリケーションのインストール、およびバックアップの実行中など、さまざまな時点でこれまでに作成されている復元ポイントが表示されます。
ハード ディスクに複数のボリュームがあるシステムでも、復元ポイントは既定ではブート ボリュームでのみ有効になっています。復元ポイントは選択されているボリュームに対して、アプリケーションやドライバのインストール中と 1 日に 1 回 (復元ポイントがその日に 1 回も作成されていない場合)、自動的に作成されます。また、復元ポイントは、コントロール パネルの [システム] の [システムの保護] を選択することで、手動で作成することもできます。ファイルのバックアップおよび Complete PC バックアップ中に作成されたシャドウ コピーも復元ポイントとして使用できます。
Windows XP では、システムの復元はファイル システム フィルタを使用して、システム ファイルの変更を追跡しています。Windows Vista では、ボリューム シャドウ コピー サービスを使用して、選択されているボリュームに対してブロック レベルで変更を追跡します。これにより、システムの復元はより堅牢で、さらに多くの修復シナリオに対応する機能となっています。
他に新しくなった点として、通常の Windows がオフラインの間もシステムの復元を実行できるようになりました。これは、Windows 回復環境を使用して実現されており、Windows が起動できない場合でも、システムを修復することができます。

シャドウ コピー
シャドウ コピーがユーザーによって認識されることは、ほぼありません。これは、この機能が既定で有効になっており、ユーザーによる入力を必要としないためです。おそらくユーザーがこの機能に気がつくのは、ファイルの復元が必要になったときです。これは実質的には、ボリューム シャドウ コピー サービスが作成した、ファイルのある時点のコピーを提供するための機能です。

シャドウ コピー領域を管理する
シャドウ コピー用の記憶域は、ライブ ボリュームと Complete PC バックアップ用のバックアップ ディスクの両方で確保されています。昇格したコマンド プロンプトから次のコマンドを実行すると、シャドウ コピー用の記憶域の使用領域、割り当て領域、および最大領域の値を確認できます。
VSSAdmin list ShadowStorage
"使用領域" は現在シャドウ コピーによって使用されている領域のサイズ、"割り当て領域" はシャドウ コピー用に予約されている (したがって別の目的では使用できない) 領域のサイズ、"最大領域" は保持できるシャドウ コピーの最大サイズを示しています。
シャドウ コピーの領域の割り当ては自動的に行われ、ユーザーによって設定することはできません。それまでに割り当てられている領域がすべて使用されると、一定のサイズで新しい領域が割り当てられます。このため、"使用領域" の値は、常に "割り当て領域" に示される値よりも少なくなります。
ライブ ボリュームでは、シャドウ コピーの最大記憶域サイズは、最初のシャドウ コピーが作成されたとき (通常は、システムの復元が初めて有効にされ、復元ポイントがセットアップ中に作成されたとき) に決まります。この値は、空き領域の 30% かボリューム全体のサイズの 15% のどちらか少ない方に設定されます。この最大サイズは静的です。空き領域が増減した場合や、ボリュームのサイズが調整された後でも変更されません。
ただし、実は、昇格したコマンド プロンプトから VSSAdmin ツールを使用すると、この記憶域のサイズは手動で調整できます。たとえば、次のコマンドを実行すると、C:\ の最大記憶域サイズを 15 GB に増やすことができます。
VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB
このツールはもともと、特定のボリュームのシャドウ コピーが別のボリュームに保存される可能性がある、Windows Server® で提供されていました。Windows Vista では、あるボリュームのシャドウ コピーは、同じボリューム上に保存されます。したがって、"For" および "On" に指定するボリュームは同じである必要があります。
一方、Complete PC バックアップのバックアップ先ディスクでは、シャドウ コピーの記憶域のサイズは、ディスク容量の 30% と決められています。この値は Complete PC バックアップによって制御され、手動で変更することはできません。このシャドウ コピーの記憶域は、Complete PC バックアップの増分バックアップの保存に使用されます。
シャドウ コピーの記憶域に十分な空き容量があると仮定して、1 つのボリュームに保存しておくことができるシャドウ コピーの数は最大 64 個です。記憶域の最大サイズに達すると、新しいシャドウ コピーの記憶域を確保するために、古いシャドウ コピーが削除されます。したがって、システムの復元の古い復元ポイントは、ライブ ボリューム上のシャドウ コピーの記憶域が制限に達し、さらにバックアップ ディスク上のシャドウ コピーの記憶域が制限に達して古い Complete PC バックアップが削除された時点で、削除されます。また、バックアップ ディスク上で他のデータを保存および編集すると、通常の古いバックアップの処理に影響し、古いバックアップがより短期間で削除される可能性があります。

シャドウ コピーを使用してファイルを復元する
さて、新しいラップトップを購入してからしばらく経ち、これを使用していくつかプレゼンテーションを作成しているとします。プレゼンテーションが完成したので、これらをクライアントに提出しました。それから 1 か月が経過し、新しいプロジェクトに着手することになったので、これらのファイルを削除しました。そのときに、上司からこれらの古いプレゼンテーションが欲しいと言われました。シャドウ コピーの本領が発揮されるのは、このような状況です。
削除されたファイルのコピーを検索する方法は、2 とおりあります。1 つはファイルが保存されていた場所がわかっている場合で、削除したファイルが保存されていたフォルダを右クリックし、[以前のバージョンの復元] をクリックします。表示されたダイアログ ボックスから、削除されたファイルの目的のバージョンがある日付を選択し (図 4 を参照)、[開く] をクリックして、そのファイルをライブ ボリューム上の別の場所にコピーします。このコピー操作は、通常のファイルのコピーと同程度の速度で実行されます。
図 4 削除されたファイルを復元する
図 4 削除されたファイルを復元する
ファイルが保存されていた場所を忘れてしまっている場合は、ファイル ツリー内で最も近い親フォルダの以前のバージョンを開き、そこで検索を行います。たとえば、どのフォルダであったか覚えていなくても、ドキュメント フォルダのいずれかのサブフォルダにあったことがわかっている場合は、エクスプローラのウィンドウの右上隅にある検索ボックスにファイル名 (の全体または一部) を入力してドキュメント フォルダの以前のバージョンを検索できます (図 5 を参照)。ただし、シャドウ コピーの検索機能は、ルート フォルダでは利用できないことに注意してください。また、シャドウ コピーのインデックスは作成されないため、ライブ ボリュームに対する検索と比べて時間がかかる可能性があります。
図 5 ファイル名の一部を入力して、ドキュメントの以前のバージョンを検索する
図 5 ファイル名の一部を入力して、ドキュメントの以前のバージョンを検索する

ファイルのバックアップからファイルを復元する
シャドウ コピーは、利用可能な領域を確保するために時折削除されるため、永遠に利用できるわけではありません。この方法では取得できなくなったファイルが必要な場合は、定期的なファイルのバックアップを利用できます。バックアップと復元センターで [ファイルの復元] をクリックし、削除したプレゼンテーションがあるバックアップの日付を選択します。[ファイルの追加] ボタンをクリックすると、[ファイルを開く] ダイアログ ボックスが表示され、バックアップ内を移動できます。探しているファイルを選択すると、ファイルを同じ場所に復元するか、異なる場所に復元するかを選択するオプションが表示されます。
[ファイルの復元] オプションでは、最新のバックアップ セットに含まれるバックアップしか表示されないことに注意してください。古いバックアップ セットのバックアップを参照するには、[詳細な復元] を選択し、[このコンピュータで作成された古いバックアップにあるファイル] オプションを選択します。まれに、このオプションを使用しても古いバックアップ セットが見つからない場合があります。そのときは、[詳細な復元] を選択し、[別のコンピュータで作成されたバックアップにあるファイル] オプションを選択します。この状況は、コンピュータのバックアップ カタログのサイズが大きくなり過ぎて調整された場合に発生することがあります。

Complete PC バックアップからファイルを復元する
万全を期すために、Complete PC バックアップを使用して個々のファイルを復元できることもお知らせしておきます。Complete PC バックアップはボリューム レベルでの復元を目的としていますが、データが .vhd 形式で保存されるため、オフライン VHD マウント ツールを使用して、個々のファイルへのアクセスと復元を行うことができます (本稿執筆時点では、VHD マウント ツールは Microsoft Virtual Server 2005 R2 SP1 のみで提供されています。Virtual Server 2005 R2 SP1 は、microsoft.com/technet/prodtechnol/eval/virtualserver からダウンロードできます)。バックアップをマウントするには、昇格したコマンド プロンプトを開き、Microsoft Virtual Server\Vhdmount に移動します。その後、次のコマンドを実行します。
vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]
このコマンドを初めて実行すると、必要なドライバが署名されていないことが原因で、システムがそれらのドライバを読み込めない可能性があります。この場合、デバイス ドライバが読み込まれなかったことを示すエラー メッセージが表示されます。この問題を解決するには、上記のコマンドを使用して .vhd ファイルにアクセスしたうえで、デバイス マネージャを開き、表示されている新しいデバイスを右クリックし、[プロパティ] をクリックします。表示されたダイアログ ボックスの [ドライバ] タブを開き、[ドライバの更新] をクリックします。[コンピュータを参照してドライバ ソフトウェアを検索します] をクリックして、[コンピュータ上のデバイス ドライバの一覧から選択します] を選択します。適切なドライバ ファイルは、Microsoft Virtual Server\Vhdmount\vhdstor.inf に格納されています。インストールが完了すると、新しいドライバが表示され、最新の Complete PC バックアップを参照して、必要なファイルを別の場所にコピーできるようになります。

Complete PC 復元
さて、ある晴れた日の午後、プールのそばに座ってラップトップを使用することにしたとします。濡れたタイルに足をとられて、ラップトップがプールに落ちてしまいました。修理は不可能で、新しいコンピュータを購入するしかありません。幸い、Complete PC バックアップ ツールを使用していたので、システムを新しいラップトップに復元することができます。手動で各アプリケーションをインストールし、個人設定を使用してそれらを再構成することに時間を割く必要はありません。Complete PC 復元は、簡単に実行できます。起動時に Windows Vista インストール ディスクを使用して、Windows 回復環境を起動します。そこで、システム イメージが格納されたデバイスを接続するように求められます。適切なイメージを選択すると、復元処理が開始されます。
復元が完了したら、最新のファイルのバックアップからのファイルの復元を実行します。これは、ファイルのバックアップを実行する頻度のほうが高く、より新しいデータが格納されているためです。コンピュータの状態は、選択したファイルのバックアップよりも前の時点に戻されているため、カタログにはこのバックアップのレコードが含まれていません。したがって、[詳細な復元] をクリックし、[別のコンピュータで作成されたバックアップにあるファイル] をクリックして、[このバックアップに含まれるものすべてを復元する] を選択します。また、新たに完全バックアップを実行して、新しく復元されたデータを保護します。
Windows 回復環境は、多くの場合、OEM によってハード ドライブに隠しパーティションとしてインストールされています。これを使用して、同じハードウェアに Complete PC バックアップ イメージを復元できます。ただし、あるコンピュータで作成されたイメージを別のコンピュータに復元する必要がある場合は、Windows のインストール ディスクなど、外部メディアから Windows 回復環境を実行する必要があります。
いくつか注意が必要な点があります。Complete PC 復元は、バックアップを作成したハードウェアと同じハードウェアに復元するときは、問題なく機能します (もちろんハードウェア障害が発生していない場合です)。
Complete PC バックアップにはコンピュータ全体のイメージが含まれているため、別のハードウェアに復元する場合は、いくつかの制約があります。まず、このバックアップ イメージには、復元の完了後にコンピュータの起動に使用されたドライバが含まれています。まれに、新しいコンピュータの起動に必要なドライバが含まれていない場合があります。この問題は、イメージ バックアップが作成されたディスク コントローラの種類 (IDE、SATA、または SCSI) と復元先のディスク コントローラの種類が異なる場合に、発生する可能性があります。ただし、この場合でも、イメージ バックアップに含まれている一般的な Windows ドライバは互換性がある可能性が高いため、復元を正常に完了できる可能性は十分にあります。
また、新しいコンピュータに同じ数またはそれ以上のハード ドライブがあり、各ハード ドライブのサイズが、復元元のハード ドライブと同じかそれ以上でなければ、復元は実行できません。Complete PC バックアップを使用して新しいハードウェアへの移行を行う際は、これらの制約に留意してください。
ブロック レベルでボリューム全体のバックアップと復元が実行されるため、Complete PC 復元では、あるボリュームを完全に復元するか、復元をまったく行わないかのいずれかの処理しか実行できません。したがって、複数のボリュームのバックアップを作成した場合 (たとえば、システム ファイルとデータ ファイルのパーティションを分けている場合など)、それらの復元を実行するときは、システム ボリューム (重要なボリュームであることが示されます) のみを復元するか、すべてのボリュームを復元するかを選択できます。

この記事で紹介した機能を実際に使用する
Windows Vista では、新しいバックアップ テクノロジが導入され、既存の機能が強化されたことで、データおよびシステムの保護機能が Windows XP から大幅に向上しています。4 種類の主要なバックアップ機能 (ファイルのバックアップと復元、Windows Complete PC バックアップと復元、システムの復元、およびシャドウ コピー) は、異なるが相互に補完し合う機能をそれぞれ提供し、より幅広いデータ保護を実現しています。これらの機能がどのように連携するかを理解し、システムが 4 種類の方法をすべて使用するように構成して、状況に合わせて適切な保護と対処を行うことが重要です。
目安としては、データが失われた場合、シャドウ コピーに最新のデータのコピーが含まれている可能性が高いため、まずシャドウ コピーによる復元を試してください。システムが不安定になった場合やシステムを修復する場合は、システムの復元を使用します。Complete PC 復元は、基本的に完全なシステムの修復を行うための最後の選択肢として、十分に注意して使用してください。とはいえ、Complete PC 復元が救世主となる状況もあります。もっとも重要なことは、手遅れになる前に手を打つことです。すぐにバックアップを実行しましょう。
本稿執筆にご協力いただいた Eduardo Laureano 氏、Ivan Pashov 氏、Jill Zoeller 氏と、Windows バックアップと復元製品チームのすべてのメンバに感謝します。

Christine Fok は、マイクロソフトのストレージ ソリューション部門のプログラム マネージャです。Windows クライアント プラットフォームのバックアップおよび復元エクスペリエンスを担当しています。


 Windows Server: Active Directory の管理に不可欠な 11 個のツール
Windows Server Laura E. Hunter

Active Directory の管理に不可欠な 11 個のツール
概要:
  • コマンド ラインでオブジェクトを作成する
  • Active Directory 内で一括操作を実行する
  • Active Directory の更新と保守を行う

来週から働き始める 200 人の新しい従業員が一覧された Excel ワークシートを渡されたり、ヘルプ デスクのスタッフがクリックする必要のない場所をクリックしたためにユーザー アカウントが正しく構成されなかったり、
単に Active Directory ユーザーとコンピュータを毎回開くことなく Active Directory® を管理する簡単な方法を知りたいと思ったりしたことがある場合は、役立つ無償の管理ツールが多数あります。このようなツールには、Windows® OS に組み込まれているもの、リソース キットや Windows サポート ツールに収録されているもの、および無償のサードパーティ製ツールがあります。この便利なツールはどのようなもので、どこで入手できるのでしょうか。この記事では、その答えを紹介します。
まず、Active Directory のオブジェクトを作成、削除、変更、および検索できる、Windows Server® 2003 の組み込みのコマンド ライン ツールについて説明します。

CSVDE
CSVDE と呼ばれるコンマ区切り値データ交換ツールを使用すると、CSV ソース ファイルを使用して新しいオブジェクトを Active Directory にインポートできます。また、既存のオブジェクトを CSV ファイルにエクスポートすることもできます。ただし、CSVDE を使用して、既存のオブジェクトを変更することはできません。このツールをインポート モードで使用している場合に実行できる操作は、新しいオブジェクトの作成のみです。
CSVDE を使用すると、既存のオブジェクトの一覧を簡単にエクスポートできます。次に、Active Directory オブジェクトを ad.csv というファイルにエクスポートするコマンドを示します。
csvde –f ad.csv
-f スイッチは、その後に出力ファイルの名前が指定されることを示します。ただし、環境によっては、この基本的な構文を使用すると、大きくて扱いにくい出力ファイルが作成される可能性があることを考慮する必要があります。特定の組織単位 (OU) に含まれるオブジェクトのみをエクスポートするようにツールを制限するには、上記のコマンドを次のように変更します。
csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com
ユーザー オブジェクトを CSV ファイルにエクスポートすることだけに関心がある場合についても説明しましょう。この場合は、検索にライトウェイト ディレクトリ アクセス プロトコル (LDAP) フィルタを指定できる -r スイッチと、エクスポートする属性の数を制限する -l スイッチを追加します (次のコマンドは、1 行で記述する必要があります)。
csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
    "(&(objectcategory=person)(objectclass=user))" –l
    DN,objectClass,description
-i スイッチを指定すると、オブジェクトをソース CSV ファイルから Active Directory にインポートできます。ただし、CSVDE を使用してユーザー オブジェクトを作成する場合には、重要な制限が 1 つあります。このツールでは、ユーザー パスワードを設定できません。このため、私はユーザー オブジェクトの作成には CSVDE は使用しません。

LDIFDE
Active Directory には、CSVDE よりも強力で柔軟性の高い、LDIFDE と呼ばれる一括ユーザー操作のための別の組み込みツールが用意されています。LDIFDE では、新しいオブジェクトの作成だけでなく、既存のオブジェクトを変更および削除したり、Active Directory スキーマを拡張したりすることができます。LDIFDE の柔軟性のトレードオフは、必要な入力ファイルの形式が、単純な CSV ファイルと比べて複雑であるという点です。LDIFDE の入力ファイルは、拡張子が .ldf で LDIF ファイルと呼ばれます (簡単な作業でユーザー パスワードを構成することもできますが、それについては後で説明します)。
まず、ある 1 つの OU 内のユーザーを LDF ファイルにエクスポートする単純な例について説明しましょう (次のコマンドは、1 行で記述する必要があります)。
ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
       –r "(&(objectcategory=person)(objectclass=user))"
多くのコマンド ライン ツールと同様に、LDIFDE /? コマンドを実行すると、LDIFDE スイッチについての詳細な説明を参照できます。図 1 で、ここで使用したスイッチについて説明します (CSVDE コマンドと LDIFDE コマンドで使用するスイッチは同じです)。
Figure 1 LDIFDE スイッチ (Close Figure 1)

スイッチ | 説明
-d | LDIFDE が操作のために接続する必要がある LDAP パスを指定します。
-f | 使用するファイルの名前を指定します。この記事では、エクスポートの結果の出力先となるファイルの名前を指定します。
-r | エクスポートに使用する LDAP フィルタを指定します。
-s | 操作を実行する接続先のドメイン コントローラ (DC) を指定します。指定しないと、LDIFDE はローカル DC (またはワークステーションからツールを実行している場合は、認証に使用された DC) に接続します。
LDIFDE の真の力は、オブジェクトを作成および操作するときに発揮されます。ただし、まず入力ファイルを作成する必要があります。次のコマンドでは、afuller と rking という 2 つの新しいユーザー アカウントが作成されます。入力ファイルを作成するには、メモ帳 (またはお好みのテキスト エディタ) に次のテキストを入力し、NewUsers.ldf という名前を付けて保存します。
dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking
入力ファイルを作成したら、次のコマンドを実行します。
ldifde –i –f NewUsers.ldf –s DC1.contoso.com
ここで唯一の新しいスイッチは –i です。おわかりと思いますが、これはエクスポートではなくインポートの操作であることを示しています。
既存のオブジェクトを変更または削除する場合も、同じ LDIFDE コマンドの構文を使用し、LDF ファイルの内容を変更します。ユーザー アカウントの説明フィールドを変更するには、図 2 に示すような ModifyUsers.ldf というテキスト ファイルを作成します。
図 2 ModifyUsers LDF ファイル
図 2 ModifyUsers LDF ファイル
-f スイッチの後に新しい LDF ファイル名を指定し、前と同じ LDIFDE コマンド構文を実行して、変更をインポートします。オブジェクトを削除するための LDF の形式は、さらに単純です。ここで操作していた 2 つのユーザー アカウントを削除するには、DeleteUsers.ldf というファイルを作成し、次のテキストを入力します。
dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete
CSVDE とは異なり、LDIFDE ではユーザー パスワードを構成できます。ただし、ユーザー アカウントに unicodePWD 属性を構成するには、ドメイン コントローラで Secure Sockets Layer/Transport Layer Security (SSL/TLS) 暗号化を構成する必要があります。
また、LDIFDE では、ユーザー アカウントだけでなくすべての種類の Active Directory オブジェクトを作成および変更できます。たとえば、次の LDF ファイルを使用すると、contoso.com フォレストのスキーマに EmployeeID-example というカスタム スキーマ拡張が作成されます。
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example
LDIFDE ファイルでは業界標準の LDAP ファイル形式が使用されるため、Active Directory スキーマの変更が必要な多くのサードパーティ製のアプリケーションでは、運用環境に適用する前に変更の確認と承認に使用できる LDF ファイルが提供されます。
一括インポート操作とエクスポート操作を行うツール以外にも、Windows Server 2003 には、さまざまな Active Directory オブジェクトを作成、削除、および変更したり、特定の条件を満たすオブジェクトのクエリを実行したりする組み込みのツールセットも同梱されています (これらのツール、dsadd、dsrm、dsget、および dsquery は、Windows 2000 Active Directory ではサポートされていないことに注意してください)。

Dsadd
dsadd は、特定のディレクトリ パーティションで Active Directory オブジェクト クラスのインスタンスを作成する際に使用します。このクラスには、ユーザー、コンピュータ、連絡先、グループ、組織単位、およびクォータが含まれます。dsadd では、次の要素で構成される一般的な構文が使用できます。
dsadd <ObjectType> <ObjectDistinguishedName> attributes
作成する各オブジェクトの種類には、その種類で使用できる属性に対応する、特定のスイッチのセットを指定することに注意してください。このコマンドによって、さまざまな属性が設定された 1 つのユーザー オブジェクトが作成されます (次のコマンドは、1 行で記述する必要があります)。
dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
-memberOf スイッチでは、ユーザーの追加先となる各グループの完全な識別名 (DN) を指定する必要があります。ユーザーを複数のグループに追加する場合は、複数の DN をスペース区切りで追加できます。
Help Desk グループの DN など、要素にスペースが含まれている場合は、要素を二重引用符で囲む必要があります。IT\EMEA という OU のように要素に円記号が含まれている場合は、「IT\\EMEA」と円記号を 2 つ入力する必要があります (これらの要件は、すべての ds* ツールに適用されます)。
-pwd * スイッチを使用すると、コマンド ラインでユーザーのパスワードを入力するよう求められます。-pwd P@ssword1 のようにコマンドの入力時にパスワードを指定できますが、コマンドでパスワードを指定すると、パスワードが画面にテキストで表示されたり、コマンドを埋め込んだテキスト ファイルやスクリプト ファイルに表示されたりします。
同様に、次の 2 つのコマンドを使用して、グループ オブジェクトと OU を作成できます。
dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod
dsmod は既存のオブジェクトを変更する際に使用し、変更するオブジェクトの種類に応じて異なるサブメニューや構文を使用して、dsadd と同じように操作できます。次の dsmod ステートメントを実行すると、ユーザーのパスワードが変更され、次回のログオン時に新しいパスワードに変更するよう求められるように、アカウントが変更されます。
dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
これらのスイッチが類似していることをご覧に入れるため、次に、同じ属性を構成してこのユーザーを作成する際に使用する dsadd 構文を示します。
dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
ご覧のように、dsadd でオブジェクトを作成するスイッチを知っていれば、dsmod を使用してユーザーを変更する際にも同じスイッチを使用できます。

Dsrm
dsadd の逆の処理を行うのが dsrm です。ご想像どおり、このツールを使用すると、コマンド ラインからオブジェクトを削除できます。基本的な dsrm の構文は、きわめて簡単です。次に示すように、dsrm の後に削除するオブジェクトの識別名を入力するだけです。
dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com
既定では、dsrm によって "このオブジェクトを削除しますか?" というメッセージが表示されます。Y キーを押して、Enter キーを押します。-noprompt スイッチを使用してこのメッセージを非表示にすることができますが、その場合は当然、オブジェクトを削除する前に、正しいオブジェクトを選択したことを確認する機会がなくなります。コンテナ オブジェクト、つまり他のオブジェクトを含む可能性がある組織単位を削除する場合は、役立つ 2 つのスイッチがあります。次のコマンドでは、TrainingOU 組織単位と、それに含まれるすべてのオブジェクトが削除されます。
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
また、次のコマンドでは、TrainingOU 内のすべての子オブジェクトは削除されますが、この組織単位オブジェクト自体は削除されません。
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
    –exclude

Dsmove
Active Directory でオブジェクトの移動または名前の変更を行う際には、dsmove ツールを使用しますが、このツールは、オブジェクトを同じドメイン内で移動する場合にのみ使用してください。ドメイン間またはフォレスト間でオブジェクトを移行する際には、マイクロソフト Web サイトから無償でダウンロードできる Active Directory 移行ツール (ADMT) を使用します。dsmove には、個別または組み合わせて使用したりできる、2 つのスイッチがあります。次のコマンドでは、Steve Conn のアカウントに新しい姓を設定します。
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
    –newname "Steve Conn"
次のコマンドを実行すると、Steve のアカウントが IT OU から Training OU に移動します。
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
    ou=Training,dc=contoso,dc=com
また、次のように一度に両方のスイッチを指定することで、名前の変更と移動を 1 つの操作でまとめて行うことができます。
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
    "Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget と Dsquery
ds* コマンド ライン ツールセットには、オブジェクトの作成や変更用のツールではなく、Active Directory に情報を問い合わせる際に使用される 2 つのツールも含まれます。
dsget では、オブジェクトの DN を入力として指定すると、指定した 1 つまたは複数の属性の値が返されます。dsget では、dsadd や dsmod と同じサブメニュー (user、computer、contact、grou、OU、quota) を使用します。
ユーザー アカウントの SAM アカウント名とセキュリティ識別子 (SID) を取得するには、次のコマンドを入力します (次のコマンドは、1 行で記述する必要があります)。
dsget user cn=afuller,ou=IT,dc=contoso,dc=com
    –samAccountName –sid
このコマンドを実行すると、図 3 のような出力が表示されます。
図 3 dsget の実行結果
図 3 dsget の実行結果
dsquery では、指定した条件を満たす Active Directory オブジェクトの一覧が返されます。使用しているサブメニューに関係なく、次のパラメータを指定できます。
dsquery <ObjectType> <StartNode> -s <Search Scope> -o <OutputFormat>
dsquery では、ObjectType として、computer、contact、subnet、group、OU、site、server 、user、quota、および partition というサブメニューを使用できます (server サブメニューでは、使用している環境のメンバ サーバーではなく、ドメイン コントローラに関する情報を取得することに注意してください)。また、各サブメニューには、それぞれ固有の構文があります。これらのいずれかのクエリの種類が適切でない場合は、自由形式の LDAP クエリを入力できる * サブメニューを使用できます。
StartNode では、検索を開始する Active Directory ツリーの場所を指定します。ou=IT,dc=contoso,dc=com などの特定の DN、または domainroot (特定のドメインのルートから開始) や forestroot (検索の実行にグローバル カタログ サーバーを使用して、フォレスト ルート ドメインのルートから開始) のいずれかのショートカットの指定子を使用できます。
Search Scope オプションでは、dsquery で Active Directory ツリーを検索する方法を指定します。subtree (既定値) では指定された StartNode とそのすべての子オブジェクトをクエリし、onelevel では StartNode の直下の子オブジェクトのみをクエリし、base では StartNode オブジェクトのみをクエリします。
検索スコープをわかりやすくするには、OU に、ユーザー オブジェクトと、追加のオブジェクトを含む子 OU の両方を含めることを検討してください。subtree スコープを指定すると、OU とその OU 内に含まれるすべてのユーザー オブジェクト、および子 OU とその子 OU に含まれるオブジェクトをクエリします。onelevel スコープを指定すると、OU 内に含まれるユーザー オブジェクトのみをクエリし、子 OU や子 OU に含まれるオブジェクトはクエリしません。base スコープを指定すると、OU に含まれるオブジェクトはクエリせず、OU 自体だけをクエリします。
最後に、OutputFormat を使用して、dsquery の出力結果の形式を制御できます。既定では、dsquery コマンドを実行すると、クエリの条件に一致するすべてのオブジェクトの識別名が次のような形式で返されます。
"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com"
IT OU とその子 OU に含まれるすべてのユーザー オブジェクトをクエリするには、次のコマンドを使用します。
dsquery user ou=IT,dc=contoso,dc=com
無効なユーザー アカウントのみを返す -disabled、過去 x 週間以内にログオンしていないユーザーのみを返す -inactive x、過去 x 日以内にパスワードを変更していないユーザーのみを返す -stalepwd x などの他のスイッチを指定すると、このクエリの精度をさらに高めることができます。
ディレクトリ内のオブジェクトの数に応じて、クエリを実行するときに、-limit x スイッチを指定することが必要になる場合があります。既定では、dsquery では、クエリの条件に一致するオブジェクトを最大 100 個返します。-limit 500 のように大きな値を指定したり、-limit 0 を使用して一致するオブジェクトをすべて返すように、dsquery に指示したりできます。
他のサブメニューを使用して、他のオブジェクトの種類に対しても便利なクエリを実行できます。次のクエリは、10.1.x.x アドレス空間にある、Active Directory サイトとサービスで定義されたすべてのサブネットを返します。
dsquery subnet –name 10.1.*
また、次のクエリは、Corp サイトに配置されているすべてのサブネットを返します。
dsquery subnet –site Corp
別のサブメニューを使用して、フォレスト内でグローバル カタログ サーバーとして構成されているドメイン コントローラの数をすばやく特定することもできます。
dsquery server –forest –isgc
また、次の構文を使用して、ドメイン内でプライマリ ドメイン コントローラ (PDC) の Emulator Flexible Single Master Operations (FSMO) の役割をホストしているドメイン コントローラを特定することもできます。
dsquery server –hasfsmo pdc
サブメニューが用意されている他の ds* コマンドと同様に、コマンド プロンプトで、「dsquery user /?」、「dsquery computer /?」、「dsquery subnet /?」などのコマンドを入力すると、特定の dsquery のサブメニューで使用できるすべてのスイッチを表示できます。
その他の巧妙な技としては、| 文字 (日本語キーボードでは Shift キー + \ キー) を使用して、dsquery の出力を dsmod などの別のツールにパイプすることもできます。たとえば、企業で部署名を Training から Internal Development に変更したので、関連のある各ユーザーの説明フィールドの情報を、古い部署名から新しい部署名に更新する必要があるとします。次のように、1 行のコマンド ラインで、説明フィールドに Training が設定されているユーザー オブジェクトをクエリし、その説明フィールドを一括で変更できます。
dsquery user –description "Training" | dsmod
    -description "Internal Development"

サードパーティ製の優れたツール
Active Directory は LDAP 標準ベースなので、LDAP に対応する任意のツールを使用して、Active Directory のクエリおよび変更を行うことができます。多くのサードパーティ ベンダが Active Directory の管理に役立つツールを有償で提供していますが、コミュニティでは無償で入手できる貴重なツールもあります。Directory Services MVP の Joe Richards が作成したコレクションは、その一例で、joeware.net/freetools からダウンロードできます。このサイトでは、多くの異なる機能を提供するさまざまなツールを入手できます。私が頻繁に利用している 3 つのツールは、adfind、admod、および oldcmp です。

Adfind と Admod
adfind と admod は、dsquery と dsmod に似ています。adfind は Active Directory 用のコマンド ライン クエリ ツールで、admod では 1 つまたは複数の Active Directory オブジェクトを作成、削除、または変更できます。
オブジェクトの種類に応じて複数のサブメニューや異なるスイッチを使用する ds* ツールとは異なり、adfind と admod では、実行するクエリや変更の種類に関係なく、いつも同じ構文を使用します。adfind の基本的な構文を次に示します。
adfind –b <Search Base> -s <Search Scope> -f <Search Filter>
    attributesDesired
つまり、ドメイン内のすべてのコンピュータ オブジェクトの DN と説明フィールドをクエリするコマンドは、次のようになります。
adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
    description
また、すべてのユーザー オブジェクトをクエリするコマンドは、次のようになります。
adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
    (objectclass=user))" dn description
LDAP クエリの内容が違うという点を除き、構文は変わっていません。
adfind を使用していると、多くのショートカット演算子があることがわかります。たとえば、前の例では、-b dc=contoso,dc=com の代わりに -default スイッチを使用し、ドメイン全体を検索することができます。-gc を指定すると、ガーベジ コレクション (GC) に対して検索を実行し、Active Directory フォレスト内のすべてのユーザーを返します。また、-rb スイッチを使用して、検索の相対ベースを設定することもできます。phl.east.us.contoso.com ドメインの Training OU を検索する場合、「-b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com」と指定する代わりに「-default -rb ou=Training」と指定するだけで済むので、労力を大幅に減らすことができます。
adfind では、図 4 に示す機能など、他のコマンド ライン ツールでは簡単に管理できない多くの高度な検索機能も実行できます。
Figure 4 adfind スイッチ (Close Figure 4)

スイッチ | 説明
-showdel | Deleted Objects コンテナに対して、廃棄済みオブジェクトをクエリします。
-bit | userAccountControl 属性などのビット単位の演算子に対してクエリを実行します。
-asq | 属性スコープ クエリを実行します。この機能 (dsquery では再現できません) は、特定のオブジェクトの属性を取得し、その属性に対してクエリを実行できます。
-dsq | adfind クエリの出力を、dsmod またはその他のいずれかの ds* ツールにパイプします。
次の -asq スイッチを使用した例は、"HelpDesk のメンバのグループ メンバシップを表示せよ" という意味のコマンドです。
adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf
admod は、その名のとおり、Active Directory 内のオブジェクトを変更する際に使用します。adfind と同様に、特定の構文に付随する特殊なサブメニューを覚える必要はありません。admod では、操作するオブジェクトの種類に関係なく、同じ構文を使用します。また、admod では、-add、-rm、-move、-undel などの適切なスイッチを追加して、オブジェクトの追加、移動、名前の変更、削除、および削除の取り消しも実行できます。dsquery や dsmod と同様に、| 文字を使用して、adfind クエリの結果を admod にパイプすることもできます。
admod で削除の取り消しを実行しても、廃棄済みオブジェクトの復元操作が実行されるだけで、ほとんどのオブジェクトの属性は削除されていることに注意してください。オブジェクトとそのすべての属性を完全に復元するには、Authoritative Restore を実行する必要があります。

Oldcmp
私が自分の自動化ツールキットになくてはならないツールだと考えている joeware ツールが、もう 1 つあります。それは oldcmp というツールです。このツールでは、Active Directory データベースをスキャンして、指定した期間 (週) に使用されていないコンピュータ アカウントを検出し、次の操作を実行できます。
  • アカウントに対して操作を行わずにアカウントのレポートを作成する
  • 使用されていないコンピュータ アカウントを無効にする
  • コンピュータ アカウントを指定した別の OU に移動する
  • コンピュータ アカウントを完全に削除する
oldcmp は、ディレクトリに深刻な悪影響を与える可能性があるため、多くの安全機能が組み込まれています。oldcmp では、まだ無効になっていないアカウント (および "本当に削除して構わない" という意味のコマンド ライン スイッチを手動で指定していないアカウント) は削除されません。"本当に変更しても構わない" という意味のスイッチを使用しない限り、一度に 10 個を超えるオブジェクトが変更されることはありません。また、ドメイン コントローラのコンピュータ アカウントに対して操作が行われることはありません。
ツールの名前が誤解を招くようになるにもかかわらず、Joe は、一定の期間使用されていないユーザー アカウントに対しても同様の機能を実行するように、oldcmp を更新しました。
小規模な Active Directory 環境や、一度に 1 つか 2 つしか追加や変更を行わない Active Directory 環境では、Active Directory ユーザーとコンピュータなどの GUI ツールは、日常的な管理作業を行うのには十分です。ただし、毎日、多数のオブジェクトを追加または変更する場合や、より効率的な管理作業のソリューションを求めている場合は、コマンド ライン ツールに移行することで、Active Directory 内のオブジェクトを作成、変更、および削除する作業を大幅に高速化できます。既に説明したように、無償で入手できる柔軟性の高い強力なツールは多数あります。このようなツールには、Windows に組み込まれているもの、Active Directory コミュニティのメンバが運営しているサイトからダウンロードできるものがあります。このようなツールを使用すると、Active Directory 管理者として生産性を大幅に向上することができます。そして、これらのツールはさらに日常的な仕事に欠かせないものとなるでしょう。

Laura E. Hunter は、Windows Server のネットワークの分野で、Microsoft MVP を 4 回受賞しています。彼女は、『詳説 Active Directory 第 2 版』(O'Reilly、2006 年) の著者です。IT 業界に携わって 10 年のベテランであり、現在は Active Directory アーキテクトとして国際的なエンジニアリング企業で勤務しています。また、この業界の資格を複数持っており、ユーザー グループの会議や業界のカンファレンスで頻繁に講演を行っています。


 Windows Server: Active Directory の廃棄済みオブジェクトを復元する
Windows Server Gil Kirkpatrick

Active Directory の廃棄済みオブジェクトを復元する
概要:
  • 削除されたオブジェクトが Active Directory に格納されるしくみ
  • LDP と ADRESTORE を使用して廃棄済みオブジェクトを検索および復元する
  • オブジェクトの属性と systemFlags

あまり考えたくない話題かもしれませんが、誤ってデータを失うことは日常よくあります。また、IT プロフェッショナルは、あらゆる復旧シナリオに備えておく必要があります。TechNet Magazine の 2007 年 4 月号で、Active Directory® ユーザーおよびグループ
の回復計画を立てておくことの重要性について説明しました。この記事 (technetmagazine.com/issues/2007/04/ADRecovery) では、オブジェクトのリンク、レプリケーション、削除、および Authoritative Restore のしくみについても説明しました。残念ながら、Authoritative Restore 機能を使用するには、ドメイン コントローラ (DC) をディレクトリ サービス復元モード (DSRM) で起動する必要があります。DSRM で起動すると、復元操作の実行中はその DC を使用できなくなります。
この他に、もう 1 つ知っておくべき手法があります。廃棄済みオブジェクトの復元 (ゾンビとは関係ありません) は、DC をオフラインにすることなく、削除されたオブジェクトを回復させることができる唯一の方法です。また、objectGUID 属性や objectSid 属性など、削除されたオブジェクトの ID 情報も、これ以外の手法では回復させることができません。この手法を使用すると、削除されたユーザーやグループの再作成や、削除されたオブジェクトの objectSid が含まれた、古いアクセス制御リスト (ACL) のすべての参照の修正が必要になるという問題もうまく解決されます。ただし、後で説明するように、廃棄済みオブジェクトの復元には独自の制限があるため、Authoritative Restore も対策の 1 つに入れておく必要があります。
廃棄済みオブジェクトの復元は、特定のデータ回復シナリオを簡略化するために、Windows Server® 2003 Active Directory で導入されました。この機能は、削除されたオブジェクトを物理的に削除する前に、それらを一定期間データベース内で保持するという Active Directory の動作を活用しています。この記事では、Active Directory がオブジェクトを削除および復元するしくみと、標準の Microsoft ツールを使用して、削除されたオブジェクトを回復させる方法について説明します。

廃棄済みオブジェクトについて
Active Directory がオブジェクトをディレクトリから削除しても、そのオブジェクトがデータベースから物理的に削除されるわけではありません。Active Directory で実行される処理は、オブジェクトの isDeleted 属性を TRUE に設定することによって "削除された" というマークを付け、オブジェクトのほとんどの属性を削除し、オブジェクト名を変更した後、オブジェクトの名前付けコンテキスト (NC) の特殊なコンテナである CN=Deleted Objects にそのオブジェクトを移動するという処理だけです。この処理が施されたオブジェクトを廃棄済みオブジェクトといい、通常のディレクトリ操作では非表示になります。このオブジェクトはどの Microsoft® 管理コンソール (MMC) スナップインにも表示されず、ほとんどのライトウェイト ディレクトリ アクセス プロトコル (LDAP) ユーティリティで認識されません。つまり、廃棄済みオブジェクトはほぼその姿を消しています。しかし、非表示になっているだけでデータ自体は存在します。なぜ Active Directory は、削除されたオブジェクトである廃棄済みオブジェクトをデータベース内で保持するのでしょうか。
廃棄済みオブジェクトは他の処理では認識されませんが、Active Directory のレプリケーション処理では認識されます。Active Directory は、削除するオブジェクトをホストしているすべての DC で削除操作が実行されるようにするために、廃棄済みオブジェクトを他の DC にレプリケートします。つまり、廃棄済みオブジェクトは Active Directory 環境全体に削除操作をレプリケートするために使用されます。

廃棄済みオブジェクトの有効期限
通常、Active Directory は、LDAP プロトコルの削除操作や、セキュリティ アカウント マネージャ (SAM) の削除操作に応答して、ディレクトリからオブジェクトを削除します。この操作は "要求元の削除" と呼ばれ、Active Directory のレプリケーション処理によって実行される削除操作とは区別されます。この説明は、動的オブジェクトは考慮していません。動的オブジェクトには異なる削除メカニズムが使用され、有効期限 (TTL) が切れた時点で Active Directory によって直接削除されます。
Active Directory は、削除操作を受け取ると、チェックリストを使用して、そのオブジェクトを削除できるかどうかを確認します。この処理では、次の基準がすべて満たされているかどうかが確認されるため、驚くほど複雑な処理が実行されます。
  • オブジェクトの isDeleted が TRUE に設定されていない (既に削除されたオブジェクトを削除することはできません)
  • オブジェクトのセキュリティ記述子に、リソース固有の "プライベート オブジェクト" 制御フラグが設定されている (これは公開されていない "機能" のようです。このプライベート オブジェクト フラグは、セキュリティ記述子構造体の Sbz1 バイトのビット 1 です。)
  • オブジェクトの systemFlags 属性に "削除拒否" ビット (0x80000000) が設定されていない
  • オブジェクトの isCriticalSystemObject 属性が TRUE に設定されていない
  • オブジェクトのセキュリティ記述子によって、そのオブジェクトを削除するための適切なアクセス権がユーザーに与えられている (より具体的に言うと、ユーザーがそのオブジェクト自体を削除することと、親オブジェクトから子オブジェクトを削除することを許可されている)
  • オブジェクトが既存の名前付けコンテキストの相互参照オブジェクト (objectClass = crossRef) ではない
  • オブジェクトが下位オブジェクトを保有していない (LDAP 削除操作に LDAP "ツリー削除" コントロールのオブジェクト ID が含まれている場合、Active Directory は、下位オブジェクトの isCriticalSystemObject 属性が TRUE に設定されていない限り、それらのオブジェクトを自動的に削除します。isCriticalSystemObject 属性により、ツリー削除操作で重要なシステム オブジェクトが誤って削除されるのを防ぐことができます。もちろん、下位オブジェクトを個別に削除することもできます。)
  • オブジェクトが重要な内部オブジェクトではない (DC の nTDSDSA オブジェクトや、NC ヘッドの先祖のプレースホルダ オブジェクトではない)
Active Directory が削除操作を処理するには、これらの基準が満たされているかどうかに加えて、Active Directory が適切な状態であることが必要です。たとえば、Active Directory でドメインの名前変更が実行されている場合、ドメイン信頼アカウントや crossRef オブジェクトは削除されません。
オブジェクトを実際に削除できることが確定したら、Active Directory はオブジェクトを廃棄済みオブジェクトに変換します。まず、オブジェクトから不要な属性を削除します。図 1 で指定されている属性と、スキーマで定義されている属性は、廃棄済みオブジェクト内でも保持されます (詳細については、「オブジェクトの属性を回復させる」を参照してください)。次に、オブジェクトの相対識別名 (RDN) を CN=<old RDN>\0ADEL:<objectGUID> に変更します。\0A は ASCII の改行文字、<objectGUID> は文字列として表される objectGUID をそれぞれ示しています。その後、lastKnownParent 属性をオブジェクトの親コンテナの識別名 (DN) に設定し、isDeleted 属性を TRUE に設定します。そして、すべての前方リンク属性と後方リンク属性をオブジェクトから削除します。最後に、オブジェクトの systemFlag 属性に "削除時の移動を許可しない" ビットが設定されていない場合、オブジェクトを NC の CN=Deleted Objects コンテナに移動します (詳細については、補足記事の「systemFlags 属性とオブジェクトの動作」を参照してください)。
Figure 1 廃棄済みオブジェクトに保存される属性 (Close Figure 1)

保存されるようにハードコードされている属性
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
searchFlags の設定に応じて保存される属性
msDS-AdditionalSam-AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid
CN=Deleted Objects フォルダの構造はフラットであり、オブジェクトの階層が存在しないことに注意してください。階層が存在しないため、同じ CN を持つ 2 つの異なるオブジェクトを削除したときに、名前の競合が発生するのではないかと思うかもしれませんが、競合は発生しません。各廃棄済みオブジェクトの RDN には objectGUID が組み込まれるため、CN=Deleted Objects コンテナに格納される各廃棄済みオブジェクトの RDN は一意になります。
当然のことながら、オブジェクトは永遠に CN=Deleted Objects コンテナ内で保持されるわけではありません。廃棄済みオブジェクトの既定の有効期間は、最初に Windows® 2000 と Windows Server 2003 を使用して構築されたフォレストの場合は 60 日、Windows Server 2003 SP1 を使用して構築されたフォレストの場合は 180 日です。廃棄済みオブジェクトの有効期間を変更するには、CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain> オブジェクトの tombstoneLifetime 属性を設定します。
各ドメイン コントローラは、12 時間ごとにガベージ コレクション処理を開始します (この間隔を変更するには、CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<root domain> オブジェクトの garbageCollPeriod 属性に新しい値を設定します)。このガベージ コレクションでは、DC 上のすべての廃棄済みオブジェクトがスキャンされ、有効期限が切れているすべての廃棄済みオブジェクトが物理的に削除されます。

LDP を使用して廃棄済みオブジェクトを検索する
LDP は、Active Directory の操作に使用できる、エクスプローラに似たユーティリティです。もともとは、Active Directory の開発中に、開発チームが Active Directory の LDAP コードをテストするために設計しました。現在は Windows Server 2003 サポート ツールの一部として、Active Directory を操作するための堅牢なツールへと進化しました。
廃棄済みオブジェクトは通常のディレクトリ操作では表示されませんが、LDAP 検索操作と、コントロールと呼ばれる特殊な LDAP 拡張を使用することによって、Active Directory の廃棄済みオブジェクトを検索できます。コントロールは LDAP 標準で定義されているメカニズムです。コントロールを使用すると、LDAP プロトコルを拡張して LDAP 標準で定義されていない追加機能を提供できるだけでなく、他の LDAP 準拠のソフトウェアとの互換性も維持できます。Active Directory では、Return Deleted Objects (削除されたオブジェクトを返す) コントロールなど、22 個のコントロールがサポートされています。Return Deleted Objects (削除されたオブジェクトを返す) コントロールを使用して LDAP 検索操作を拡張すると、通常は表示されない削除されたオブジェクトを取得できます。
この動作のデモンストレーションを行うために、エンタープライズ管理者の資格情報を使用して foo.local ドメインにログインし、Active Directory ユーザーとコンピュータ (ADUC) MMC スナップインを使用してユーザー オブジェクト (CN=John Smith,CN=Users,DC=foo, DC=local) を作成します (図 2 を参照)。次に、再度 ADUC を使用してこのユーザー オブジェクトを削除します。
図 2 ADUC を使用したユーザーの作成
図 2 ADUC を使用したユーザーの作成
これで、LDP プログラムを実行し、このプログラムを使用して、削除されたユーザーの廃棄済みオブジェクトを表示できるようになりました。まず、LDP を特定の DC に接続し、適切な資格情報を使用して認証を行います。DC に接続するには、[Connection] (接続) メニューの [Connect] (接続) オプションを選択します。今回は DC で LDP を実行しているため、単に [OK] をクリックしてローカル DC に接続します。LDP をリモートで実行している場合は、接続先の DC の名前を指定する必要があります。DC に正しく接続されると、rootDSE の属性 (DC 自体の状態と構成を示す属性など) が表示されます (図 3 を参照)。
図 3 DC に接続された LDP
図 3 DC に接続された LDP
ここで、ドメイン管理者またはエンタープライズ管理者の資格情報を使用して DC に対する認証を行うために、[Connection] (接続) メニューの [Bind] (バインド) を選択します。既にフォレストのエンタープライズ管理者としてログインしている (既定では、ドメイン管理者とエンタープライズ管理者に、CN=Deleted Objects コンテナのオブジェクトを一覧表示および復元する権限が与えられています) ため、[Bind] (バインド) ダイアログの [Username] (ユーザー名) と [Password] (パスワード) を空のままにして、[OK] をクリックします。または、適切な資格情報を [Bind] (バインド) ダイアログに入力してもかまいません。
次に、CN=Deleted Objects,DC=foo,DC=local コンテナの内容を一覧表示します。通常、CN=Deleted Objects コンテナが表示されることはありません。これは、このコンテナ自体が "削除された" というマークを付けられるためです。CN=Deleted Objects コンテナを検索できる唯一の方法は、Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを使用することです。
このコントロールを LDP で使用するには、[Browse] (参照) メニューの [Search] (検索) を選択します。これにより、図 4 のような検索ダイアログが表示されます。[Base Dn] (ベース Dn) フィールドには、検索を開始するディレクトリ ツリー内の場所を指定できます。このフィールドに、ドメインの Deleted Objects (削除されたオブジェクト) コンテナの DN (この例では CN=Deleted Objects,DC=foo,DC=local) を入力します。
図 4 LDP の検索ダイアログ
図 4 LDP の検索ダイアログ
[Filter] (フィルタ) フィールドには、LDP によって使用される検索条件を指定します。既定値の (objectClass=*) は、objectClass 属性に値が格納されているすべてのオブジェクトを検索結果として返します。Active Directory の削除されたオブジェクトの objectClass にも値が格納されているため、既定のフィルタでは、検索範囲内のすべてのオブジェクトが返されることになります。この例では、フィルタを (objectClass=user) に変更して、検索対象をユーザー オブジェクトに制限します。これにより、たとえば削除されたユーザー John Smith を CN=Deleted Objects コンテナ内の (場合によっては) 何千個という廃棄済みオブジェクトから容易に検索できるようになります。
CN=Deleted Objects コンテナには、1 回の検索操作で Active Directory によって返されるオブジェクトの数を上回る数のオブジェクトが格納されている場合もあります。通常、この問題に対処するには、ページ単位の LDAP 検索を使用します。この検索方法では、結果が一度に 1 グループずつ返されます。ただし、LDP ではページ単位の検索と拡張検索を両方指定することはできないため、LDAP フィルタの範囲を絞り込んで目的のオブジェクトを検索する必要があります。
[Scope] (検索範囲) のオプション ボタンでは、検索するディレクトリ ツリーの深さを指定できます。ベース検索では、[Base Dn] (ベース Dn) フィールドに指定されたオブジェクトのみが返されます。1 レベル検索では、ベース Dn オブジェクトの直下にあるオブジェクトが返されます。また、サブツリー検索では、ベース Dn オブジェクトよりも下の階層にあるオブジェクトがすべて返されます。CN=Deleted Objects フォルダの構造はフラットであるため、ここでは 1 レベル検索を使用してすべての廃棄済みオブジェクトを取得します。
ここまでは、従来の LDAP 検索について説明しました。上記の LDAP 検索を実行した場合、CN=Deleted Objects,DC=foo,DC=com が存在しないことを示すエラーが表示されます。これは、このコンテナに "削除された" というマークが付けられているためです。このため、さらに Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールをこの検索操作に含める必要があります。これを行うには、[Search] (検索) ダイアログの [Options] (オプション) をクリックし、[Search Call Type] (呼び出しの種類の選択) の [Extended] (拡張) を選択します (図 5 を参照)。このオプションを選択することによって、検索操作用のコントロールを指定できるようになります。また、[Attributes] (属性) リストの値を * に変更します。これにより、LDP の既定の属性ではなく、LDP によって取得された各オブジェクトの通常の属性がすべて表示されます。
図 5 LDP の [Search Options] (検索オプション) ダイアログ
図 5 LDP の [Search Options] (検索オプション) ダイアログ
次に、[Controls] (コントロール) をクリックして [Controls] (コントロール) ダイアログを表示します。LDP の [Controls] (コントロール) ダイアログは若干扱いにくいため、この操作を行う際は、次の手順に注意深く従って Return Deleted Objects (削除されたオブジェクトを返す) コントロールを追加してください。
[Load Predefined] (定義済みオブジェクトの読み込み) ボックスの一覧を開き、[Return deleted objects] (削除されたオブジェクトを返す) を選択して、[Check in] (チェックイン) をクリックします。これにより、Return Deleted Objects (削除されたオブジェクトを返す) コントロールのオブジェクト ID (OID) (1.2.840.113556.1.4.417) が [Active Controls] (アクティブなコントロール) の一覧に追加されます (図 6 を参照)。これで、以降の LDP によって実行されるすべての拡張検索操作に、このコントロールが追加されます。[OK] をクリックしてコントロールの設定を保存し、もう一度 [OK] をクリックして [Search Options] (検索オプション) ダイアログを閉じます。
図 6 Return Deleted Objects (削除されたオブジェクトを返す) コントロールの追加
図 6 Return Deleted Objects (削除されたオブジェクトを返す) コントロールの追加
[Controls] (コントロール) ダイアログには特有の動作があります。具体的には、[Active Controls] (アクティブなコントロール) の一覧に OID が表示されても、そのコントロールが実際に有効になっているわけではないということです。このため、あるコントロールを次の LDAP 操作で使用するために、そのコントロールを一度チェックアウトしてから再度チェックインする必要が生じる場合もあります。
これで検索を実行する準備ができました。LDP の [Search] (検索) ダイアログで [OK] をクリックすると、LDP によってドメインの CN=Deleted Objects コンテナのすべてのユーザー オブジェクトが取得されます。結果は図 7 のようになります。
図 7 CN=Deleted Objects コンテナの検索結果
図 7 CN=Deleted Objects コンテナの検索結果

LDP の検索結果を調べる
上記で実行した検索では、2 つの廃棄済みオブジェクトが返されました。まず、1 つ目の廃棄オブジェクトの DN は、CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local です。削除されたオブジェクトの objectGUID は、文字列 (41800281-6bc4-42c3-a99b-b283022b3af8) として表されます。その下の DN は、objectClass、cn、distinguishedName などの値を示す属性の一覧です。isDeleted 属性の値は TRUE で、このオブジェクトが実際に削除されたことを示しています。また、objectSid が廃棄済みオブジェクトに保存されていることも確認できます。この属性は、後で説明するユーザーとグループの廃棄済みオブジェクトの回復を行う際に重要になります。廃棄済みオブジェクトを回復させる際に非常に重要になるもう 1 つの属性は、lastKnownParent 属性です。この属性は、削除されたオブジェクトが廃棄済みオブジェクトになる前に格納されていたオブジェクトの DN を表しています。
この記事の LDP のサンプルでは、もともとは CN=Users,dc=foo,dc=local コンテナの CN=John Smith という名前のユーザー オブジェクトであった、2 つの廃棄済みオブジェクトが表示されました。同じコンテナに格納されていた、同じ RDN を持つ 2 つのオブジェクトが、なぜ CN=Deleted Objects コンテナで共存できるのでしょうか。これは簡単に説明がつきます。LDP を実行して廃棄済みオブジェクトを検索する前に、CN=Users,DC=foo,DC=local コンテナに CN=John Smith ユーザー オブジェクトを作成した後、そのオブジェクトを削除しました。その後、まったく同じ属性を持つ別のユーザー オブジェクトを作成し、そのオブジェクトも削除しました。1 つ目の CN=John Smith ユーザー オブジェクトは既に削除されていたため、何の問題もなく同じ名前を持つ 2 つ目のオブジェクトを作成することができました。しかし、これらは異なる一意のオブジェクトとして、objectGUID によって区別されます。objectGUID は廃棄済みオブジェクトの DN に組み込まれるため、これら 2 つは異なるオブジェクトとして CN=Deleted Objects コンテナに格納されます。

廃棄済みオブジェクトが復元されるしくみ
Active Directory では、廃棄済みオブジェクトを通常のオブジェクトに復元するためのメカニズムが提供されます。実質的には、これは削除されたオブジェクトの削除取り消し機能です。この機能は、特殊な構成の LDAP 変更操作であり、2 つの特定の属性を変更する操作が含まれている必要があります。特定の属性を変更する操作とは、isDeleted 属性を削除する (FALSE に設定するだけではありません) 操作、およびオブジェクトの distinguishedName を変更することによって、そのオブジェクトを別のコンテナに移動する操作です。新しい distinguishedName は、通常 (必ずではありません) lastKnownParent 属性をコンテナとして使用し、廃棄済みオブジェクトの作成時に Active Directory によって追加された \0ADEL:<objectGUID> という文字列を RDN から削除した名前を値として保持します。
Active Directory は、廃棄済みオブジェクトを復元する前に、特定の要件がすべて満たされているかどうかを確認します。ユーザーは、廃棄済みオブジェクトを復元するための拡張アクセス権を与えられている必要があります。このアクセス権は、廃棄済みオブジェクトが格納されている NC の NC ヘッドで定義されています。ユーザーは、自分自身のオブジェクトを復元することはできません。廃棄済みオブジェクトの isDeleted 属性は、TRUE に設定されている必要があります。また、セキュリティ記述子で定義されている、オブジェクトの所有者のセキュリティ識別子 (SID) は、フォレスト内のいずれかのドメインか信頼されているドメインの SID である必要があります。
復元するオブジェクトが構成 NC またはスキーマ NC 内のオブジェクトである場合、廃棄オブジェクトの systemFlags 属性に FLAG_CONFIG_ALLOW_RENAME ビットと FLAG_ CONFIG_ALLOW_MOVE ビットが設定されている必要があります。復元するオブジェクトが構成 NC またはスキーマ NC 内のオブジェクトであり、さらに FLAG_CONFIG_ALLOW_LIMITED_MOVE フラグが設定されている場合、そのオブジェクトは、同じ祖父母を持つコンテナにのみ移動することができます。つまり、曽祖父母は変更できないということです。また、オブジェクトがドメイン NC またはアプリケーション パーティション内のオブジェクトである場合、廃棄済みオブジェクトの systemFlags 属性に FLAG_DOMAIN_DISALLOW_RENAME ビットと FLAG_DOMAIN_DISALLOW_MOVE ビットが設定されていない必要があります。
ユーザーが RDN (通常は CN ですが異なる場合もあります) を変更する権限と、オブジェクトを新しい親コンテナに追加する権限を与えられていることが、セキュリティ記述子で定義されている必要があります。また、新しい親コンテナが廃棄済みオブジェクトの objectClass の利用可能な上位クラスであることが、スキーマで定義されている必要があります。System コンテナからの移動や System コンテナへの移動は通常 (レジストリの System サブツリーの Unlock キーの値が 0 以外でない限り) 許可されませんが、System コンテナへの廃棄済みオブジェクトの復元は許可されます。
スキーマ オブジェクトの復元は許可されません。ただし、論理的にはスキーマ NC からオブジェクトを削除することはできないため、このことはそれほど問題ではありません。
すべての確認が正常に終了し、要件を満たしていることが確認されたら、Active Directory は廃棄済みオブジェクトに対して次の手順を実行し、オブジェクトを復元します。
  • isDeleted 属性を削除します。
  • 変更操作によって objectCategory の値が設定されていない場合、廃棄済みオブジェクトに指定されている最も限定的な objectClass を objectCategory の値に設定します。
  • RDN を変更し、オブジェクトを新しい親コンテナに書き込みます。
復元後、オブジェクトの objectGUID 属性と objectSid 属性には、削除される前と同じ値が格納されます。つまり、削除されたオブジェクトを再作成したときのように、(ACL などの) オブジェクトへの外部参照を再設定する必要はありません。復元されたオブジェクトの外観と動作は、削除される前と同じ状態に戻ります。ただし、1 つだけ重要な違いがあります。それは、復元されたオブジェクトでは、廃棄済みオブジェクトに保存されなかった属性がすべて失われるということです。

LDP を使用して廃棄済みオブジェクトを復元する
systemFlags 属性とオブジェクトの動作
systemFlags 属性は、クラス Top 用に定義された (つまり、すべての Active Directory クラス用の) 省略可能な属性です。この属性は、オブジェクトの移動と削除の動作を制御する 32 ビットの整数ビットマスクです。この属性の重要なフラグの概要を次に示します。

FLAG_DISALLOW_DELETE (0x80000000)

このフラグが設定されている場合、システムでは、オブジェクトの削除や別のドメインへの移動が許可されません。

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ NC のオブジェクトの名前を変更することはできません。

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ NC のオブジェクトを移動することはできません。

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ NC のオブジェクトを移動することはできません。このフラグを設定すると、移動先のコンテナの祖父母が現在のコンテナと同じでなければならないという制限が追加されます。

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

既定では、ドメイン NC とアプリケーション NC のオブジェクトの名前は変更することができます。しかし、オブジェクトの systemFlags 属性にこのフラグが設定されている場合、システムではこのオブジェクトの名前の変更が許可されません。

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

既定では、ドメイン NC とアプリケーション NC のオブジェクトは別のコンテナに移動することができます。しかし、オブジェクトの systemFlags 属性にこのフラグが設定されている場合、システムではこのオブジェクトの移動が許可されません。

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

このフラグが設定されている場合、システムでは名前付けコンテキストの CN=Deleted Objects コンテナにオブジェクトが移動されず、isDeleted 属性の設定、オブジェクトの名前の変更、および保存するようにスキーマに指定されていない属性の削除のみが実行されます。つまり、一部の削除されたオブジェクトは名前付けコンテキストの CN=Deleted Objects コンテナに格納されず、元の親コンテナに残ります。

廃棄済みオブジェクトの復元のしくみについて具体的に説明したところで、次は削除したユーザー CN=John Smith を LDP によって復元する方法のデモンストレーションを行います。まず、DC に接続して認証を行います。これで、LDP を使用して変更操作を実行できます。変更操作のパラメータを指定する際は、isDeleted 属性を削除して、さらに新しい DN を指定します。
操作するのは廃棄済みオブジェクトであるため、Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを指定する必要があります。LDP の変更操作にこのコントロールを設定するには、[Options] (オプション) メニューの [Controls] (コントロール) を選択し、[Load Predefined] (定義済みオブジェクトの読み込み) ボックスの一覧から [Return deleted objects] (削除されたオブジェクトを返す) を選択して、[Check in] (チェックイン) をクリックした後、[OK] をクリックしてコントロールの設定を保存します。
次に、[Browse] (参照) メニューの [Modify] (変更) を選択して [Modify] (変更) ダイアログを開き、復元する廃棄済みオブジェクトの DN を入力します。このとき、先ほど実行した検索操作の結果から DN をコピーして貼り付けると、容易に DN を入力できます。
次に、実行する属性操作の一覧を入力する必要があります。廃棄済みオブジェクトを復元するには、isDeleted 属性を削除し、distinguishedName 属性の値を、復元する廃棄済みオブジェクトの任意の DN に置き換えるという 2 つの属性操作が必要です。まず、[Attribute] (属性) フィールドに「isDeleted」と入力し、[Delete] (削除) オプション ボタンを選択します。[Enter] (入力) をクリックすると、この属性操作が [Entry List] (エントリの一覧) に追加されます (図 8 を参照)。
図 8 実行する属性操作の指定
図 8 実行する属性操作の指定
その後、[Attribute] (属性) フィールドに「distinguishedName」と入力し、[Replace] (置換) オプション ボタンを選択して、[Values] (値) フィールドにオブジェクトの新しい DN を入力します。この場合、ユーザーの元の distuiguishedName である CN=John Smith,CN=Users,DC=foo,DC=local を使用します。[Enter] (入力) をクリックすると、この変更操作が [Entry List] (エントリの一覧) に追加されます。
Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを検索操作に含める必要があるため、拡張 LDAP 変更操作を使用する必要があります。これを行うには、[Extended] (拡張) チェック ボックスをオンにします。設定が完了して図 9 のような状態になったら、[Run] (実行) をクリックして変更操作を実行します。結果は大きなテキスト ウィンドウに表示されます。
図 9 distinguishedName の変更
図 9 distinguishedName の変更
Active Directory ユーザーとコンピュータ (ADUC) MMC スナップインに戻って CN=Users コンテナを確認すると、一度は削除されたユーザー オブジェクトが元の場所に戻っています。しかし、復元されたオブジェクトの状態と元のオブジェクトの状態との間には、この後説明するいくつかの重要な違いがあります。

ADRESTORE を使用して廃棄済みオブジェクトを復元する
LDP の使用方法を理解すれば、廃棄済みオブジェクトの復元はそれほど難しいものではなくなります。しかし、LDP は非常に便利な方法とは言えません。幸運なことに、Sysinternals (現在はマイクロソフトに統合されています) のすばらしい開発者によって、この復元処理を簡略化できるコマンド ライン ツールが開発されました。この ADRESTORE と呼ばれるツールは、マイクロソフト Web サイト (microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx) からダウンロードできます。このツールのインストールは単純で、実行可能ファイルをコンピュータの適切なディレクトリ (C:\WINDOWS\SYSTEM32 など) にコピーするだけです。
ADRESTORE は 2 つのモードで実行できます。パラメータを指定せずに実行すると、既定のドメインの CN=Deleted Objects コンテナにあるすべての廃棄済みオブジェクトが一覧表示されます。次のように、コマンド ラインに検索文字列を追加すると、表示するオブジェクトを選択できます。
C:\> adrestore John
上記のコマンドを実行すると、CN=Deleted Objects コンテナにある廃棄済みオブジェクトの中で、CN または OU 属性に "John" という文字列が含まれたオブジェクトがすべて表示されます。つまり、cn=*John* と ou=*John* という LDAP 検索フィルタが使用されます。これはあまり柔軟な廃棄済みオブジェクトの検索方法ではありませんが、多くの状況で使用できます。図 10 は、上記のコマンドを実行したときに ADRESTORE から返される出力を示しています。
図 10 廃棄済みオブジェクトに保存される属性
図 10 廃棄済みオブジェクトに保存される属性
廃棄済みオブジェクトを検索するだけではなく復元する場合は、次のように –r スイッチを文字列 (省略可能) と共に指定する必要があります。
C:\> adrestore –r John
上記のコマンドを実行すると、条件に一致した廃棄済みオブジェクトを復元するかどうかを確認するメッセージが、オブジェクトごとに表示されます。ADRESTORE は、常に廃棄済みオブジェクトの lastKnownParent 属性に指定されているコンテナにオブジェクトを復元します。他のコンテナを指定する方法はありません。
ADRESTORE によって、Active Directory の復元機能の使用に役立つコマンド ライン インターフェイスが提供されます。ADRESTORE はそれほど柔軟性はありませんが、LDP よりもはるかに使いやすいツールです。しかし、ADRESTORE を使用しても、まだ廃棄済みオブジェクトの復元に関する 2 つの重要な問題は解決されません。この問題とは、オブジェクトが最初に削除されたときに一緒に削除される属性をどのようにして回復させるかということ、および構成 NC から削除されたオブジェクトをどのようにして回復させるかということです。

オブジェクトの属性を回復させる
データ回復という点では、廃棄済みオブジェクトの復元のほうが、Authoritative Restore よりもはるかに優れています。これは、廃棄済みオブジェクトの復元では DC をオフラインにする必要がないためです。また、廃棄済みオブジェクトの復元は、削除されたオブジェクトの新しいバージョンを単純に再作成するよりもはるかに便利です。オブジェクトを再作成すると、(そのオブジェクトがユーザーなどのセキュリティ プリンシパルである場合) そのオブジェクトの objectGUID 属性と objectSid 属性には新しい値が割り当てられるため、オブジェクトへの外部参照 (ACL など) を更新して新しいオブジェクトの ID を反映する必要があります。これは大きな悩みの種になる可能性があります。
一部の属性は、オブジェクトが削除されたときに一緒に削除され、廃棄済みオブジェクトの復元を実行しても回復させることはできません。しかし、Active Directory はいくつかの重要な属性を廃棄済みオブジェクトに保存します。その中で最も重要な属性は、objectGUID や objectSid などの ID に関連した属性です。この他にも、既定で多くの属性が保存されます (図 1 を参照)。保存されるようにハードコーディングされている属性のほとんどは、特に削除されたユーザー オブジェクトの回復という点では、あまり興味を引きません。しかし、Active Directory スキーマ内にある、該当する attributeSchema オブジェクトの searchFlags 属性にビット 3 (0x00000008) を設定すると、廃棄済みオブジェクトに保存する属性を追加指定できます。Windows Server 2003 R2 のスキーマでは、既にいくつかの属性 (図 1 にも記載されています) にこのビットが設定されています。
特定のアプリケーションをインストールすると、既存の属性の searchFlags のビット 3 が変更されたり、ビット 3 が設定された新しい属性が追加されたりすることがあります。たとえば、Exchange Server は、いくつかの属性の構成を変更し、それらを廃棄済みオブジェクトに保存される属性として追加します。
Active Directory では、前方リンク属性と後方リンク属性を廃棄済みオブジェクトに保存するように、スキーマ オブジェクトの searchFlags 属性で指定した場合でも、これらのリンク属性が保存されません。具体的には、グループの member 属性やユーザーの memberOf 属性は保存されません。このため、廃棄済みオブジェクトの復元を使用しても、Active Directory のグループ メンバシップを回復させることはできません。これについては、以前に公開した「障害回復: Active Directory ユーザーとグループ」(technetmagazine.com/issues/2007/04/ADRecovery) を参照してください。つまり、廃棄済みオブジェクトの復元を行う際にこの情報も回復させるには、さらに別のメカニズムを提供する必要があります。
廃棄済みオブジェクトの復元をデータ回復戦略の一部として使用する場合は、重要な属性が廃棄済みオブジェクトに保存されることを確認するか、重要な属性を保存および回復させる別の方法 (LDIFDE や他のバックアップおよび復元方法) を提供する必要があります。他の選択肢としては、廃棄済みオブジェクトへの保存や廃棄済みオブジェクトからの回復が行われない属性をバックアップおよび復元するための自動化されたメカニズムを提供する、サードパーティ製のデータ回復製品などがあります。

構成名前付けコンテキストからオブジェクトを復元する
廃棄済みオブジェクトの復元に関する他の大きな制限の 1 つは、一般的に言うと、構成 NC から削除されたオブジェクトを復元できないということです。これらのオブジェクトの移動と名前変更に関しては、オブジェクトの systemFlags 属性の定義に従って、特殊な規則が適用されます。構成 NC のオブジェクトは、systemFlags 属性で指定しない限り、移動することも名前を変更することも (つまり、廃棄済みオブジェクトを復元することも) できません。Active Directory は、特定のクラスのオブジェクトを作成するときに、systemFlags 属性に特定の値を強制的に設定します (図 11 を参照)。また、Active Directory は、これらの値と追加操作で指定された systemFlags の値を組み合わせた値に、ビットごとの論理 OR 演算を適用します。このため、アプリケーションが systemFlags 属性に異なる値を指定した場合でも、必要なビットが正しく設定されます。
Figure 11 既定の systemFlags の設定 (Close Figure 11)

クラス | 既定の設定
server | FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site | FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer | FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA | FLAG_DISALLOW_MOVE_ON_DELETE
siteLink | FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge | FLAG_CONFIG_ALLOW_RENAME
nTDSConnection | FLAG_CONFIG_ALLOW_RENAME
通常の状態で復元できる構成 NC のオブジェクトは、サーバー オブジェクトのみです。興味深いことに、Active Directory がサーバー オブジェクトを削除したとき、廃棄済みオブジェクトは構成 NC の CN=Deleted Objects コンテナに移動されず、元のオブジェクトと同じ場所に残ります。このため、削除されたサーバー オブジェクトが原因で正しいレプリケーションを実行できない場合、Active Directory のレプリケーション トポロジの計算を実行する知識整合性チェッカー (KCC) によって、自動的に再度レプリケーションを実行できる状態に回復させることができます。したがって、サーバー オブジェクトの復元が必要になった場合は、そのオブジェクトが CN=Deleted Objects コンテナに格納されないことを思い出してください。

回復計画における復元
廃棄済みオブジェクトの復元は、重要なデータ回復ツールキットの 1 つになるはずです。このメカニズムは、DC をオフラインにせずに、削除されたオブジェクトを回復させることができる唯一の方法です。また、同じくらい重要なことですが、このメカニズムは、削除されたオブジェクトの ID 情報を回復させることができる唯一の方法でもあります。廃棄済みオブジェクトの復元を使用すると、削除されたユーザーやグループの再作成や、古い ACL のすべての参照の修正が必要になるという問題がうまく解決されます。
しかし、廃棄済みオブジェクトの復元は完全な解決策ではなく、Active Directory によって廃棄済みオブジェクト内で保持されない属性を回復させるための独自のメカニズムを提供する必要があり、構成 NC から削除されたオブジェクトの回復も制限されます。このため、削除されたユーザーやグループの復元を実行する場合は、グループのメンバシップと、必要になる可能性がある、他のリンクされた属性も回復させることを忘れないでください。

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


 コミュニケーション: Office Communications Server 2007 を使用してユーザーどうしを接続する
コミュニケーション Alan Maddison

Office Communications Server 2007 を使用してユーザーどうしを接続する
概要:
  • Office Communications Server のアーキテクチャ
  • 会議機能
  • エンタープライズ ボイス
  • 強化されたプレゼンス

ユニファイド コミュニケーションの時代がやってきました。リリース間近の Office Communications Server 2007 では、Live Communications Server 2005 で提供された機能が刷新されます。アーキテクチャや管理機能の強化に加えて、
Office Communications Server 2007 では、新しいクライアントである Office Communicator が提供されます。また、エンタープライズ ボイスや、オンプレミス Web 会議、強化されたプレゼンスとインスタント メッセージング、フェデレーションなどの新機能や機能強化が実装されています。これらの機能を組み合わせることにより、Microsoft® ユニファイド コミュニケーション戦略を実現するためのプラットフォームが提供され、組織の生産性と遠距離のコラボレーションが強化されます。
また、この新しいバージョンでは、Microsoft 管理コンソール (MMC) スナップインのインターフェイスが整備されています。図 1 は、管理に関する新しい機能強化の 1 つであるパフォーマンス カウンタを示しています。
図 1 新しい MMC スナップインに含まれたパフォーマンス カウンタ
図 1 新しい MMC スナップインに含まれたパフォーマンス カウンタ
新しい Office Communications Server 2007 は、Standard と Enterprise の 2 つのエディションで提供されます。Office Communications Server 2007 Standard は、10,000 人未満のユーザーへの展開に適しています。Standard エディションの展開では、1 台のフロントエンド サーバーにより、すべてのサービスがホストされます。
より規模の大きい展開では、Enterprise エディションを利用できます。このエディションは、統合構成または分散構成で展開できます。統合構成では、すべてのハードウェアがフロントエンド サーバーの単一のプール内に配置されます。最大限のスケーラビリティを確保するには、分散構成を使用します。分散構成では、フロントエンド サーバーのエンタープライズ プール外に、インターネット インフォメーション サービス (IIS) を実行する専用 Web サーバー、Web 会議サーバー、およびオーディオ/ビデオ (A/V) 会議サーバーを配置できます。図 2 は、分散構成のトポロジを示しています。
図 2 分散構成のトポロジ
図 2 分散構成のトポロジ

アーキテクチャ
Office Communications Server 2007 のアーキテクチャは、フロントエンド サーバー、エッジ サーバー、およびアプリケーション サーバーという中核となるサーバーを基盤として構築されています。フロントエンド サーバーは、ユーザーの認証、アドレス帳の管理、プレゼンスの管理、会議の管理、およびアプリケーションのホスティングのほか、サーバーとクライアントとの間のシグナリング、メディアの管理 (ファイルの共有を含む)、およびインスタント メッセージング (IM) と会議のトラフィックのルーティングを行います。
Office Communications Server 2007 の中核となる会議機能は、MCU (Multipoint Control Unit) と呼ばれる一連の統合サーバーによって提供されます。図 3 は、これらのサーバーとその役割の概要を示しています。
Figure 3 会議サーバーとその機能 (Close Figure 3)

会議サーバー (MCU) | サポートされる機能
インスタント メッセージング | 参加者間の IM トラフィックをルーティングし、グループ IM を可能にします。フロントエンド サーバーに統合されているため、別のサーバーにインストールすることはできません。
テレフォニー | 送受信ダイヤル トーンのサポートを可能にします。フロントエンド サーバーに統合されているため、別のサーバーにインストールすることはできません。
Web | ホワイトボード、アプリケーションの共有、質疑応答などのコラボレーション機能、および Office ドキュメントの共有と PowerPoint プレゼンテーションのサポートを提供します。フロントエンド サーバーにインストールするか、分散プール構成で別のサーバーにインストールすることができます。
A/V | マルチパーティ IP オーディオ/ビデオの併用と中継に使用されます。フロントエンド サーバーにインストールするか、分散プール構成で別のサーバーにインストールすることができます。
フロントエンド サーバーのもう 1 つの重要な機能は、アドレス帳サーバーをホストする機能です。Live Communications Server 2005 SP1 を利用したことがある場合は、このサービスをご存知だと思います。Office Communications Server 2007 では、このサービスはオプション コンポーネントではなくなり、中心的な役割を果たします。アドレス帳サーバーは、アドレス帳サービスとアドレス帳ファイル ストアという 2 つのコンポーネントで構成されます。また、このサーバーは、内部ソースと外部ソースから連絡先情報を取得して提供します。内部ソースは通常、Active Directory® と Exchange Server のグローバル アドレス一覧や配布リストなどです。外部ソースには、フェデレーション パートナーやパブリック IM 連絡先のユーザーなどがあります。
Office Communications Server 2007 では、Live Communications Server 2005 で導入された外部ユーザーの接続機能が強化され、外部ユーザーがオンプレミス会議に参加できるようになりました。この追加機能では、Web 会議エッジ サーバーと A/V エッジ サーバーという 2 つの新しいエッジ サーバーが必要です。また別の変更点としては、これまでのアクセス プロキシ サーバーが、アクセス エッジ サーバーと呼ばれるようになりました。Office Communications Server のエッジ サーバーは、ネットワーク境界 (スクリーン サブネット) に配置され、重要な外部ユーザーの接続機能を提供するように設計されています。図 4 は、エッジ サーバーの役割とその用途の概要を示しています。
Figure 4 エッジ サーバーの役割 (Close Figure 4)

サーバー | サポートされる機能_
アクセス エッジ サーバー | フェデレーション、リモート ユーザーの接続、パブリック IM 接続 (PIC)。
Web 会議エッジ サーバー | 外部 Web 会議。
A/V エッジ サーバー | 外部ユーザーとの A/V 会議とポイント ツー ポイント A/V 通話。
リバース プロキシ サーバー | グループの拡張、アドレス帳ファイルのダウンロード、Web 会議のコンテンツへのアクセス。厳密には Office Communications Server の役割ではありませんが、重要な機能を提供します。リバース プロキシ機能は、ISA Server 2006 でも提供されています。
前述の統合サーバーに加えて、Office Communications Server はさまざまなアプリケーション サーバーを利用して、認証、会議メタデータの格納、配布リスト機能の提供など、重要な機能を実行します。Office Communications Server が一般的に使用するアプリケーション サーバーは、IIS、証明書サーバー、Active Directory 環境のグローバル カタログ サーバー、SQL Server® 2005、Exchange Server 2007、およびファイル サーバーです。
IIS は、会議コンテンツへのアクセス、アドレス帳の更新、IM 用の Active Directory 配布グループの拡張、外部ユーザー用の Outlook® 配布リストの拡張を実現するほか、基盤となる Office Communications Server コンポーネント間の通信を支援するために使用されます。
証明書サーバーは、Office Communications Server 内において、クライアントとサーバーとの間の通信、およびサーバー間の通信をセキュリティで保護するという点で、非常に重要な役割を果たします。内部のエンタープライズ証明書サーバーを使用する場合は、すべての内部クライアントと内部サーバーが発行元の証明機関 (CA) を信頼している必要があります。このため、各コンピュータの信頼されたルート ストアに各 CA 証明書チェーンをインストールする必要があります。Office Communications Server のフェデレーション サービスを使用する場合は、パートナー組織でも同様の作業が必要です。
会議への参加者の認証は、Active Directory 環境のグローバル カタログ サーバーによりサポートされます。内部ユーザーとフェデレーション ユーザーの場合、グローバル カタログ サーバーは Kerberos を使用して認証を行います。また、リモート ユーザーとして参加する社員の場合は、各ユーザーの Active Directory 資格情報を使用した NTLM 認証を行い、匿名ユーザーの場合は、ダイジェスト認証を使用して認証を行います。
SQL Server 2005 は、会議の状態データ、およびユーザーの登録情報とプレゼンス情報を保持するために使用されます。障害が発生した場合、SQL Server に格納されているデータを使用してすばやく会議を復元できます。つまり、コンテンツを失うことなく、すばやく確実に回復を完了するための方法が提供されます。
Exchange Server 2007 とそのユニファイド メッセージング機能は、ボイス メッセージングと自動応答機能を提供し、Office Communication Server 2007 を補完する重要なコンポーネントです。
ファイル サーバーは、クライアントがアクセスする必要があるデータを格納するために使用されます。たとえば、クライアントがアドレス帳をダウンロードするときに必要な物理ファイルは、ファイル サーバーに格納されます。同様に、追加の会議コンテンツもファイル サーバーに格納されます。
Office Communications Server 2007 の基盤となるプロトコル アーキテクチャは、標準的なインターネット プロトコルと Microsoft プロトコルを組み合わせて構成されています。たとえば、セッション開始プロトコル (SIP) は、IM、会議、プレゼンスのサブスクリプションなどの機能に幅広く使用されています。Office Communications Server の各種コンポーネントが使用するプロトコルにより、最大限の処理能力と柔軟性が提供されます。図 5 は、中核となるプロトコルとその用途の概要を示しています。
Figure 5 プロトコルとその用途 (Close Figure 5)

プロトコル | サポートされる機能
ハイパーテキスト転送プロトコル (HTTP) | クライアントのアクセス、会議コンテンツのダウンロード、およびアドレス帳データのダウンロード。会議サーバーとフォーカス (Office Communications Server のコンポーネント) との間の通信にも使用されます。
セッション開始プロトコル (SIP) | Office Communications Server の各種コンポーネント (エンタープライズ ボイス、IM、会議サーバー、強化されたプレゼンスなど) によるセッションの作成と管理。
Centralize Conference Control Protocol (CCCP) | 会議と会議クライアントの確立と制御に使用されるカスタム プロトコル。
Persistent Shared Object Model (PSOM) | Web 会議のコンテンツ (セキュリティ キーやユーザーの役割と権利など) の転送に使用されるカスタム プロトコル。
リアルタイム転送プロトコル (RTP) | リアルタイム データの配信。Office Communications Server 2007 内では、エンタープライズ ボイスと A/V 会議用の転送メカニズムを提供します。
Secure Real-Time Transport Protocol (SRTP) | RTP データ用の、暗号化、メッセージの認証、整合性などのセキュリティ サービス。Office Communications Server 2007 内では、マイクやスピーカーなどのメディア デバイスにオーディオ コンテンツとビデオ コンテンツを安全に転送するために使用されます。
Real-Time Transport Control Protocol (RTCP) | メディア デバイス間での A/V 会議セッションの信号の品質に関する情報の伝達。SRTP と共に使用されます。

エンタープライズ ボイス
エンタープライズ ボイスは、ボイスオーバー IP (VoIP) テレフォニーのマイクロソフトによる実装であり、Office Communications Server に追加された最も重要な新機能です。エンタープライズ ボイスは、シグナリングにセッション開始プロトコル (SIP) を使用し、ボイス トラフィックにリアルタイム転送プロトコル (RTP) を使用する実装を基盤として、PC 間だけでなく PC と他の電話との間で通話を送受信することを可能にします。また、エンタープライズ ボイスは、通話の制御、通話のルーティング、電話番号の正規化などの機能も提供します。さらに、公衆交換電話網 (PSTN) のサポートと、SIP または Computer-Supported Telecommunications Applications (CSTA) がサポートされているか、Office Communications Server 2007 API を使用して直接通信を行う構内交換機 (PBX) との相互運用性も提供します。
Office Communications Server 2007 は、既存のボイス インフラストラクチャに大きな変更を加えずに展開できますが、提供されるメリットは大きくなります。エンタープライズ ボイスは、このメリットを実現するために、SIP-PBX、SIP-IP-PBX、および IP-PSTN という 3 種類の展開構成をサポートしています。
SIP-PBX の構成では、すべてのリモート通話が PBX によって制御され、既存の電話が維持されます。この統合は、リモート通話コントロール (RCC) ゲートウェイと CSTA によって実現されます。
SIP-IP-PBX の構成では、IP-PSTN ゲートウェイが利用されます。これにより、CSTA を使用する必要がなくなるため、Office Communicator クライアントで電話番号をダイヤルし、IP-PBX 電話を制御できるようになります。既存の電話機がない場合は、Office Communicator を "ソフト電話" として構成できます。
Office Communications Server 2007 を IP-PSTN コンポーネントと共に展開すると、フロントエンド サーバーに通話コントロールをルーティングできます。この構成では、Office Communicator が、VoIP エンドポイントまたはマイクロソフト認定のサード パーティ製 SIP エンドポイント (通常、多くの組織ではこのエンドポイントは電話機です) と通信して、インターネット経由で通話を送受信できます。
メディア ゲートウェイは、VoIP と PSTN との間で、シグナリングとメディアの変換を行うサードパーティ製のゲートウェイです。Office Communications Server 2007 では、ベーシック、アドバンスト、およびベーシック ハイブリッドという 3 種類のメディア ゲートウェイがサポートされています。Office Communications Server 2007 では、アドバンスト以外のゲートウェイをサポートするために、Mediation Server (仲介サーバー) という役割によって、重要なプロトコルとメディアの変換機能を提供しています。また、Office Communications Server のコンポーネントを使用すると、リモート オフィスとの統合を行うこともできます。
Office Communications Server 2007 のその他のコンポーネントと同様に、エンタープライズ ボイスでも、外部ユーザーとの接続にエッジ サーバーを利用します。具体的には、アクセス エッジ サーバーは、企業の境界の外側にいるユーザーに SIP シグナリングを提供するために使用されます。また、A/V エッジ サーバーは、外部ユーザーが、ファイアウォールやネットワーク アドレス変換 (NAT) などの境界ネットワーク サービスを通過して、ボイス サービスやビデオ サービスにアクセスできるようにするために使用されます。
最終的には、多数のクライアントがエンタープライズ ボイスでサポートされる予定ですが、現在は、Office Communicator の最新バージョンがエンタープライズ ボイスのクライアントとして推奨されています。また、マイクロソフトとそのパートナーは、Office Communications Server と統合される新しい VoIP 電話機の計画を発表しています。
エンタープライズ ボイスは Exchange Server 2007 のユニファイド メッセージングの役割とも統合されているため、Outlook Voice Access と電話機を併用するか、コンピュータを使用して、ボイス メール、電子メール、予定表、連絡先、および受信した FAX に、単一のインターフェイスからアクセスできるようになります。また、ユニファイド メッセージングでは自動応答サービスも提供されるため、自動電話メニュー システムを実装することもできるようになります。

強化されたプレゼンス
Live Communications Server 2005 を利用したことがある場合は、プレゼンスの概念についてよくご存知かもしれませんが、Office Communications Server 2007 では、この概念が拡張および強化されています。一般に、プレゼンスはユーザーの状態と連絡可能性を表します。Office Communications Server では、プレゼンスに関連した情報をより詳細に構成できるよう基盤のインフラストラクチャが強化され、機能性が高まりました。
ユーザーは、6 種類の状態モードを選択できるようになりました。設定できる状態は、Online (オンライン)、Busy (取り込み中)、Do Not Disturb (応答不可)、Right Back (一時退席中)、Away (退席中)、Appear Offline (オフライン) のいずれかです。また、追加の情報を設定することにより、この状態をカスタマイズすることもできます。たとえば、ユーザーの状態が Do Not Disturb (応答不可) に設定されている場合、そのユーザーは応答できない理由を示す追加情報を提供できます。
プレゼンスが強化されたことにより、ユーザーは、5 種類のプレゼンス レベルを任意で使用して、他のユーザーに表示する情報をフィルタすることもできるようになりました。このプレゼンス レベルは、Personal (個人用)、Team (チーム用)、Workplace (仕事用)、Public (公開用)、および Block (禁止) です。これらのレベルにより、プレゼンスを階層的に管理できます。たとえば、Personal (個人用) プレゼンス レベルは、ユーザーの状態が Busy (取り込み中) である場合でも IM での連絡を許可するなど、連絡先にとって最も柔軟性が高いプレゼンス レベルです。また、連絡先に表示される情報の量も、プレゼンス レベルによって制御されます。
また、Office Communicator を使用すると、ユーザーは場所の状態を設定できます。これには、カスタムの場所を設定することも、既定の選択肢である home (自宅) か office (会社) のいずれかを設定することもできます。場所情報は、Personal (個人用) か Team (チーム用) に分類されている連絡先にのみ表示されます。
プレゼンスの機能強化も優れた強化点であり、コミュニケーションの合理化に役立ちますが、組織に与える影響が最も大きいのは、Office Communications Server の基盤となるインフラストラクチャとプレゼンス エンジンです。たとえば、Office Communications Server 2007 には、メンバ Web パーツという Office SharePoint Server 2007 Web パーツが含まれています。この Web パーツにより、ユーザーは、SharePoint Web サイトまたはポータルに関連付けられている他のユーザーのプレゼンスを表示できるようになります。この Web パーツを簡単に SharePoint サイトに追加して、重要なコラボレーション インフラストラクチャ全体でプレゼンス情報の共有を促進することができます。
プレゼンス情報は Microsoft® Office 2007 アプリケーション スイート全体に統合され、ドキュメント ワークスペースとスマート タグ動作設定ボタンから使用できます。たとえば、スマート タグ動作設定ボタンを使用して、ユーザーの状態、連絡先、および予定表情報を表示できます。ユーザーは、スマート タグ動作を使用して、作業を共有したり、会議のスケジュールを設定したり、IM による会話を開始したりできます。

オンプレミス会議
Office Communications Server 2007 におけるもう 1 つの重要な強化点は、オンプレミス会議機能です。内部ユーザーまたは外部ユーザー (匿名ユーザーまたはフェデレーション ユーザー) とのリアルタイム会議をホストできる機能は、多くの組織にとって役立ちます。オンプレミス会議は、スケジュールを設定することも臨時で開催することもでき、IM 会議、A/V 会議、および Web 会議のほか、ファイルの共有、ホワイトボード、スライドのコメント、参加者による投票、質疑応答セッションなどのコラボレーション ツールを含めることができます。Office Communications Server では、会議の種類の切り替えもサポートされています。たとえば、コラボレーションを既存の IM セッションに追加して、臨時の会議を作成できます。
推奨される会議クライアントは Office Communicator ですが、Office Communications Server 2007 では、Office Live Meeting 2007 と Outlook 2007 用の Office Live Meeting アドインもサポートされています。Office Communicator 2007 では、IM、A/V セッションへの参加、アプリケーションの共有、ホワイトボード、およびファイルの転送がサポートされています。また、Office Live Meeting 2007 では、会議への参加のほか、セッションのスケジュール設定、セッションの記録、参加者による投票、および質疑応答がサポートされています。
Outlook 2007 用の Office Live Meeting 2007 アドインには、Outlook 2007 を使用した会議タスクのサポートのほか、各参加者を出席者または発表者として指定する機能や、役割に応じて異なる招待を送信する機能が含まれています。ユーザーは、Organizer (開催者)、Presenter (発表者)、Attendee (出席者) のいずれかの役割を割り当てられるだけでなく、場所と資格情報に応じて内部ユーザー グループまたは外部ユーザー グループに分類されます。内部ユーザーは、Active Directory にログオンできる、企業 LAN に接続されたユーザーです。外部ユーザーはさらに、Remote (リモート)、Federated (フェデレーション)、および Anonymous (匿名) という 3 つのカテゴリのいずれかに分類されます。
リモート ユーザーは、組織内の Active Directory アカウントが与えられたユーザーです。これには、リモート ワーカーや委託業者が含まれます。すべてのリモート ユーザーは、会議の開催者、発表者、または出席者になることができます。
フェデレーション ユーザーは、Office Communications Server 内でフェデレーションを確立することによって定義された資格情報を持つユーザーです。フェデレーション ユーザーは会議に出席し、発表を行うことはできますが、会議を開催することはできません。
匿名ユーザーは、最も制限の厳しいグループであり、招待された会議に出席することしかできません。
特定の会議のセキュリティを強化するために、出席者を制御するための設定を指定できます。Office Communications Server 2007 では、open authenticated (オープン認証)、closed authenticated (クローズド認証)、anonymous (匿名) のいずれかを指定できます。
open authenticated (オープン認証) の会議には、Active Directory ログインを持つリモート ユーザーまたは内部ユーザーが参加できます。また、フェデレーション ユーザーもこの会議に参加できます。closed authenticated (クローズド認証) の会議には、会議の開催者が招待したユーザーしか出席できません。フェデレーション ユーザーは、この会議には参加できません。
anonymous (匿名) の会議には、招待を受け取ったすべてのユーザーが出席できます。ユーザーがこの会議に参加するには、会議キーを提供して、ダイジェスト認証による資格情報の検証に合格する必要があります。匿名ユーザーは、参加後に発表者に昇格しない限り、出席者として参加することしかできません。図 6 は、利用できる設定の一部を示しています。
図 6 会議の設定
図 6 会議の設定

今すぐダイヤルイン
Office Communications Server 2007 により、コミュニケーションの合理化、異なる通信手段の統合、およびユーザーによる制御が可能になるため、企業の作業方法が大幅に変わる可能性があります。アプリケーション内にプレゼンス情報と通信手段の両方を組み込むというコンテキスト通信の概念が、この大幅な変化の基盤となります。Office Communications Server 2007 がラボに展開されていない場合は、展開することをお勧めします。
Office Communications Server 2007 の詳細とベータ版については、TechNet の Office System TechCenter (technet.microsoft.com/en-us/office/bb267356.aspx) を参照してください。また、ユニファイド コミュニケーション グループのチーム ブログ (blogs.technet.com/uc) も参照してください。

Alan Maddison は、MTI Technology Corporation のシニア コンサルタントです。主な担当分野は、Active Directory、Exchange Server、および仮想化です。


 編集長から: 学びへの道
編集長から
学びへの道
Joshua Trupin

私たちは、 本誌を作り始めてからずっと、9 月号を執筆する際には "新学期" をテーマにしてきました。もちろん、9 月号の発行時期が常に新学期と同じではないことはわかっています。たとえば、米国の多くの学校では 8 月下旬に新学期が始まります。一部には、休みをまったく取らない人もいるようです。
しかし、ほとんどの人には、9 月が新学期ということが受け入れられるでしょう。TechNet Magazine は、IT プロフェッショナルの学位を授与する高等教育機関です。というのは、冗談です。しかし、本誌から得られる知識は偽物ではありません。今月は、学びのための詳細なシラバスを用意しました。
すべての優れた高等教育機関と同じように、私たちは、スクリプト好きなユーザーのための SQL 入門課程 (「Hey, Scripting Guy!」) から、Active Directory 管理ツールに関する調査まで、幅広い学習の機会を提供します。
中級課程では、Windows Vista に関する学位を授与します。まず、Business Desktop Deployment (BDD 2007) を使用して Windows を展開する方法について学習します。Windows Vista を企業で展開したら、次に、システムに定期的なバックアップを実装する方法についてのガイドを提供します。この際、現在使用できるいくつかの主要なテクノロジに関する概要も紹介します。
これで、IT プロフェッショナルの学位を取得するまで、あと一歩です。上級課程である Active Directory 研究に進むことができます。トゥームストーンの復活 (廃棄済みオブジェクトの復元) に興味があり、ハロウィンの特集記事まで待てない場合は、今月すぐに調べることもできます。
もちろん、TechNet Magazine は、学びへの道のほんの一例です。Microsoft TechNet サイトには、より多くの通信教育課程が用意されています。TechNet では、主要なテクノロジに関する IT プロフェッショナル向けの何百もの Webcast をご用意しています。中には、マイクロソフト社内で Microsoft IT がテクノロジを使用している方法のデモンストレーションなども含まれます。Webcast の提供内容は、対象者別 (IT プロフェッショナル、企業の役員など) およびテクノロジ別に分類されます。また、実際の大学要覧と同じように、難易度が付けられています。
一例を挙げると、たとえば今月の TechNet Magazine は、Active Directory についてより掘り下げた内容となっています。もしかすると、今月号の内容を実際に活用するには、少し知識が不足しているかもしれません。その場合には、TechNet Webcast にアクセスし、レベル 200 のプレゼンテーション「Active Directory の基礎知識」(msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295120) をご覧ください。
現在、教育を受ける機会は、さまざまな形で提供されています。私たちは、雑誌からインターネットまで、IT プロフェッショナルに必要な情報を随時提供しています。私たちが執筆した記事をいくつかご覧になった後には、ぜひ TechNet Magazine のブログ (blogs.technet.com/tnmag) にアクセスしてください。コーヒーを飲みながら、授業後の会話を楽しみましょう。
—Joshua Trupin

次のマイクロソフト技術支援スタッフに心より感謝します。Paul Bowden、Justin Hall、Anand Lakshminarayanan、Eduardo Laureano、Mike Lewis、Tim Mintner、Michael Murgolo、Mark Russinovich、Jim Truher


 レター: 質問への回答
レター
質問への回答

PsTools
2007 年 3 月号の「デスクトップ ファイル」(「PsTools 入門」、technetmagazine.com/issues/2007/03/DesktopFiles) というコラムで、Wes Miller が PsTools ユーティリティについて説明しています。そのコラムに記載されているすばらしいユーティリティを実行しようとしているのですが、少し苦労しています。特に興味があるのは PsLoggedOn です。それらのすばらしいユーティリティを Path システム変数上のフォルダに配置する方法を具体的に説明していただけますか。例を示していただけると非常に助かります。
—Tim

最善の開始方法は、PsTools パッケージ全体 (download.sysinternals.com/Files/PsTools.zip) を作業ディレクトリ (たとえば c:\toolbox) にダウンロードすることです。ZIP ファイルをそのディレクトリに展開すると、ツールを使用できるようになります。ツールをどこからでも実行できるように、そのディレクトリを PATH システム変数に追加するには、コマンド プロンプトから以下のコマンドを実行するだけです。"c:\toolbox" の部分は実際の作業ディレクトリに置き換えてください。
SET PATH=%PATH%;c:\toolbox

Robocopy に対する賞賛
2006 年 11 月号の Robocopy GUI に関する記事 (technetmagazine.com/issues/2006/11/UtilitySpotlight) を読むまで、我がヘルプ デスクでは、ネットワーク フォルダから SharePoint® ストアに移動されるファイルのタイムスタンプを保存する方法がわからず、困っていました。Robocopy はすばらしいツールです。
—Cristino

レジストリ サブキーをチェックする
ここ数週間、EnableLUA レジストリ サブキーの値がオンかオフかをテストする方法を突き止めようとしてきました。オフの場合は、ユーザー アカウント制御が無効になります。確認のために管理者アカウントでログインしなくても、テスト ラボでプログラムを自動的にインストールできるように、ユーザー アカウント制御を無効にする必要があるのです。すべてのインストール スクリプトの先頭にこのテストを配置してから、スクリプトの実行前に EnableLUA の値を 1 (オン) から 0 (オフ) に変更するスクリプトを実行しようと思っています。でも、このテストを正常に機能させる方法がわからないのです。力を貸していただけると非常にありがたいのですが。
—Derek

レジストリ キーを読み取り、値をチェックし、必要に応じて値を変更する、基本的なスクリプトを以下に示します。この例では、HKLM\Software\Microsoft\Test\TestKey キーを読み取り、値が 1 かどうかをチェックします。値が 1 の場合は 0 に変更し、1 でない場合はスクリプトを終了します。
On Error Resume Next
Set WSHShell =  Wscript.CreateObject _
    ("Wscript.Shell")
RegLoc = _
    "HKLM\Software\Microsoft\Test\TestKey"
KeyValue = WSHShell.RegRead(RegLoc)
If (KeyValue = "1") then
  WSHShell.RegWrite RegLoc,"0"
end If
Wscript.Quit
レジストリを変更するスクリプトは、常に細心の注意を払って使用するようにしてください (今回のような場合は特に)。

ReadyBoost
ReadyBoost についてもう少し明確に説明していただけませんか。私の理解では、ReadyBoost はコンピュータの RAM とハード ドライブとの間のバッファのような役割を果たしますが、データは同時に書き込まれます。これではシステムによってデータが二重コピーされるので、パフォーマンスが低下するのではないでしょうか。ReadyBoost を使用する場合と使用しない場合に、システムのパフォーマンスをどのようにテストすればよいのか教えてください。
—Alex

ReadyBoost の概念は、フラッシュ メモリ (USB スティックなど) が一時的なキャッシュとしての役割を果たせるようにして、(通常高価な) 従来の RAM の量を増強するというものです。ReadyBoost は、必ずしも、同じデータをフラッシュ メモリとハード ディスクに同時に書き込むとは限りません。ReadyBoost は RAM とディスクとの間の中間キャッシュ層として機能します。Mark Russinovich が 2007 年 3 月号の記事「Windows Vista カーネルの内部 : 第 2 部」でこれについてもう少し説明しています。この記事の中で Mark は次のように述べています。
「ReadyBoost サービスがキャッシュを初期化したら、Ecache.sys デバイス ドライバがローカル ハード ディスク ボリューム (C:\ など) に対するすべての読み取りと書き込みをインターセプトし、作成されたキャッシュ ファイルに書き込まれるすべてのデータをコピーします...
...ReadyBoost はキャッシュからランダムに読み取ることができるとわかると、キャッシュから読み取りますが、順次読み取りアクセスはハード ディスクの方がフラッシュ メモリより優れているため、順次アクセスの読み取りパターンの場合は、データがキャッシュにあっても直接ディスクにアクセスするようにします。」
Mark の記事の残りの部分は、オンライン (technetmagazine.com/issues/2007/03/VistaKernel) で読むことができます。

Windows PE のダウンロード
2007 年 5 月号の「レター」コラムの内容に矛盾があるようです。最初の質問「イメージを作成する」では、「Windows® PE 2.0 イメージは、WAIK に含まれているツールを使用して構築およびカスタマイズできます...」とあります。これは、Windows PE がツールに含まれていてダウンロード可能であることを意味します。
しかし、最後の質問「Windows PE を入手する」の回答では、「Windows PE はソフトウェア アシュアランスの特典サービスとして (のみ) 入手できます...」とあります。正しいのは最初の回答であって、2 つ目の回答は古い情報ではないでしょうか。
—Xihui

Windows PE 2.0 は Windows 自動インストール キット (WAIK) に含まれており、ダウンロードとして入手可能です。Windows PE 2.0 のライセンス規則は、Windows PE 1.6 (1 つ前のバージョン) とは異なります (Windows PE 1.6 については昨年の「Windows PE の概要」で扱っていて、この記事は technetmagazine.com/issues/2006/09/WindowsPE で読むことができます)。Windows PE 1.6 は、ソフトウェア アシュアランスの一部としてのみ入手できました。

Windows PowerShell のセキュリティ
Windows PowerShell™ はずいぶん話題になっています。UNIX ライクな構文、コマンド出力の書式設定の容易さなどをほめちぎる記事はたくさん見たことがありますが、Windows PowerShell をデータセンターに展開する場合のセキュリティ上の問題については聞いたことがありません。
Windows PowerShell のような強力なシェルを運用サーバーで展開または実行する場合に発生するセキュリティ上の問題にはどのようなものがありますか。
—Carlos

Windows PowerShell を取り巻くセキュリティが重要なトピックであることに関しては、まったく同感です。実は、Windows PowerShell コラムニストの Don Jones が今月号の TechNet Magazine でこのトピックについて詳しく説明しています。その記事に加えて、最近発売された『Windows PowerShell in Action』(Bruce Payette 著、Manning Publications、2007 年)、『Windows PowerShell: TFM』(Don Jones および Jeffrey Hicks 著、SAPIEN Press、2007 年) という重要な 2 冊の書籍にも必要に応じて目を通してください。どちらの書籍でも Windows PowerShell について非常に深いところまで説明してあり、セキュリティ専用の章が設けられています。

SQL のベスト プラクティス
Best Practices Analyzer (BPA) およびスキーマ修飾オブジェクトに関する回答に記載されている推奨事項 (technetmagazine.com/issues/2007/05/SQLQA を参照) に強い異論があります。(SQL Server 2000 の場合の所有者だけでなく) SQL Server™ 2005 でも、スキーマを解決する必要があります (なお、そのコラムの執筆者は "所有者" のことを間違って "スキーマ" と呼んでいます)。SQL Server 2005 での解決手順は Books Online (BOL) にきちんと解説されています。
したがって、あいまいさのエラーを避け、オブジェクト名の解決に費やされるオプティマイザの CPU サイクルを節約するためには、SQL Server 2005 でもオブジェクトを修飾することがベスト プラクティスとなります。そのコラムに記載されている推奨事項は、マイクロソフトのホワイトペーパー「SQL Server 2005 のバッチのコンパイル、再コンパイル、およびプランのキャッシュに関する問題」に反するように思えます。
—Mike

情報源の人物に直接回答を求めました。その人物とは「SQL に関する Q&A」コラムに貢献していて、テキサス州ダラスにある Microsoft Technology Center のテクノロジ アーキテクトである David Browne です。彼は次のように言っていました。
「ベスト プラクティスというものは、人によって意見が分かれる可能性があり、また、往々にして意見が分かれるものです。特にパフォーマンスに関しては、何がパフォーマンス上の大きな違いをもたらすのかや、価値のある最適化とは何かについて、人によって見解が異なります。
たとえば、コンパイルでのオプティマイザの CPU サイクルを節約するような方法でクエリを記述するということに関しては、私は実行を検討したこともありませんし、それによって現実的なワークロードに測定可能なほどの違いが生じるかどうか疑問に思っています。
一方、クエリ プランの再利用を促進してコンパイルの頻度を減らすことは、一般に認められたパフォーマンス最適化です。」

WinPE
OS のイントールに Systems Management Server (SMS) Operating System Deployment Feature Pack (OSDFP) を使用しています。Windows Vista® がリリースされたので、OSDFP を使用してイントールしようと考え、最新バージョンにアップグレードしました。最新の OSDFP で提供されている Windows PE のバージョンを教えてください。
以前は、イメージ インストール用の .iso ファイルを作成し、それをリモート インストール サービス (RIS) にコピーしてから、ネットワーク ブート オプションを使用して新しいコンピュータを起動していました。でも、今回は、RIS を Windows 展開サービス (WDS) にアップグレードしました。WDS でブート イメージとしてサポートされているのは、Windows Imaging (WIM) ファイルだけです。OSD のインストール オプションを使用して WIM イメージを作成するにはどうすればよいですか。
—Vasishta

OSDFP の最新リリースでは、Windows PE のバージョンは更新されませんでした。リリースに含まれているバージョンは Version 1.5 (Windows PE 2004 とも呼ばれます) のままです。Windows PE は更新されませんでしたが、OSDFP の最新リリースでは、Windows Vista の展開が完全にサポートされるようになりました。
展開可能なデスクトップ イメージの作成に使用する最善のプロセスは、BDD (Business Desktop Deployment) Solution Accelerator で概説されているプロセスです。必要なコンポーネントやドキュメントはすべてオンライン (microsoft.com/technet/desktopdeployment/bdd/2007) で見つかります。今月号の TechNet Magazine に含まれている Michael Niehaus の記事「BDD 2007 を使用して Windows Vista を展開する」も参照してください。

Windows Server 2003 のポスター
2007 年 7 月号の TechNet Magazine が手元に届き、Windows Server® 2008 のポスターが 2 枚付いているのに気付いて大喜びしています。同僚は、先月号で Windows Server 2003 のポスターを手に入れました。Windows Server 2003 版のポスターがほしいのですが、どうすれば入手できますか。印刷されたものでも PDF 形式でもかまいません。
—Jason

Windows Server 2008 のポスターを気に入っていただけて非常にうれしく思います。Windows Server 2003 のポスターの PDF バージョンは、オンライン (go.microsoft.com/fwlink/?LinkID=80428) で入手可能です。Windows Server 2003 のポスターは、1 つのバージョンしか作成しませんでした。


 ツールボックス: IT プロフェッショナル向けの新製品
ツールボックス
IT プロフェッショナル向けの新製品
Greg Steen

SQL Server データベースを移動する
xSQL Bundle Professional Edition
www.xsqlsoftware.com
運用サポート、アプリケーション開発、品質保証テスト、または構成管理を担当しているかどうかにかかわらず、あなたが IT プロフェッショナルならば (TechNet Magazine を読んでいるということは、そうだと思いますが)、SQL Server™ データベースの移動は生活の一部になっていることでしょう。データとデータ スキーマを移動する場合は、不整合が生じないように十分注意する必要があります。そのためには、スキーマやデータを比較して同期するための優れたツール セットが必要です。
最近私が使用したツールは、xSQL Software が提供している xSQL Bundle です。このバンドルは、xSQL Object、xSQL Data Compare、およびそれらに関連するコマンドライン ユーティリティで構成されています。
xSQL Object では、データベース スキーマを比較して同期できます。データベース間で比較するオブジェクトの型やインスタンスについて、多数の比較オプションが用意されています。また、バージョン履歴を保持するのに便利なスキーマ スナップショットを作成することもできます。この機能を使用すると、前のスキーマの状態に簡単にロールバックできます。さらに、xSQL Object でスキーマ スクリプトを生成して、
データベース スキーマを転送したりパッケージ化したりできます。
xSQL Data Compare では、2 つの SQL Server データベースに格納されているデータを比較して同期できます。また、2 つのデータベースの内容全体を比較するか、または比較するテーブル セットを選択することもできます。テーブルが完全に一致しない場合は、カスタム テーブル マッピングを定義して、テーブル内のデータを確実に同一にすることができます。大量のデータを同期する場合は、アプリケーションが一括挿入モードに切り替わり、同期プロセスにかかる時間が短縮されます。
xSQL Data Compare でも xSQL Object でも、ワークスペースを保存できるため、比較環境をいつも作成し直す必要がありません。両方のアプリケーションの同期は、トランザクション処理であるため、確実にすべての操作が正しくコミットされるか、または全体がロールバックされます。また、バンドル内のすべてのアプリケーションで SQL Server 2000 と SQL Server 2005 のデータベース インスタンスがサポートされているため、これらのバージョン間で関連するデータやオブジェクトを比較して同期できます。
おそらく、xSQL Bundle のさらに強力な機能は、2 つのコマンドライン ユーティリティでしょう。実際、これらのユーティリティでは、任意のビルド、プロセス、監視、または自動タスク スケジューラから比較と同期を実行できます。私の考えでは、冗長なタスクを自動化すると、必ず仕事が楽になり、生産性が向上します。コマンドライン ユーティリティは、メイン アプリケーション UI から構成ウィザードを使用して作成できる XML 構成ファイルを読み込みます。また、各ユーティリティには、多数のテキストファイルのログ記録オプションが用意されているため、自動実行中に何が行われているかを追跡できます。

価格 : xSQL Bundle Professional Edition、1 ユーザー ライセンス 499 ドル～
xSQL Data Compare では、2 つの SQL Server データベースのデータを同期できる
xSQL Data Compare では、2 つの SQL Server データベースのデータを同期できる

セキュリティが強化された通信を有効にする
WinSSHD
www.bitvise.com
組織のセキュリティを強化する方法をお探しの方は、Secure Shell Handling 2 (SSH2) や Secure FTP (SFTP) をご検討中かもしれません。簡単に言えば、SSH2 トンネリングを使用すると、リモート コンピュータ上のサービスに安全に接続できます。また、ファイアウォール上で開く、アプリケーションに直接関連付けられた使用可能なリスニング ポートの数を減らすことで、ハッカーに攻撃されるリスクを抑えることができます。SFTP は標準の FTP サーバーに代わるもので、SSH2 を使用してデータとコマンドを保護します。
これらのプロトコルに関心をお持ちの場合は、Bitvise が提供している WinSSHD を検討することをお勧めします。WinSSHD は、Windows 専用に設計された SSH2 サーバーです。
インストールは簡単です。わかりやすいコントロール パネルで WinSSHD サービスを管理できます。このコントロール パネルには、基本的な起動と終了の機能から、Windows® イベント ログのカスタマイズされたビュー (WinSSHD イベントのフィルタ処理が可能) に至るまで、あらゆる機能が用意されています。コンとロール パネルから設定パネルを開いて、セットアップの詳細を構成することもできます。設定パネルでは、インターフェイスとポートのバインドの設定、ログ構成の調整、有効にする SSH セッションの暗号化方法の指定、セッション タイムアウトの構成、認証方法の選択、プロキシ構成の指定、インスタンスへのアクセス権の制御などを行えます。構成のインポートとエクスポートも可能です。
アクセス制御の設定では、IP ルール (サブネット制御のマスキング サポートあり) や DNS 名ルール (IP ルールの後で処理される) でアクセスを制限できます。
WinSSHD では、仮想化がサポートされていますが、これは SFTP 実装としては画期的です。つまり、1 つの Windows アカウントに何千もの仮想ユーザーを割り当てて、アカウントとセキュリティの詳細を簡略化することができます。認証およびアクセス制御に Windows グループを使用することもできます。したがって、ユーザーごとにポリシーを定義する必要がありません。
Kerberos 5 および NTLM 認証がサポートされているため、WinSSHD を 1 つのサインオン環境に統合することができます。統合するには、Tunnelier などの GSSAPI 対応の SSH クライアントが必要です。Tunnelier は、Bitvise が提供する、優れた関連製品です。お察しのとおり、Tunnelier は WinSSHD サーバーと完全な互換性があります。WinSSHD サーバーをリモートで構成するために使用することもできます。
ミッション クリティカルな SFTP または SSH2 サーバー環境では、WinSSHD をクラスタ化して、高可用性を実現できます。クラスタ化は非常に簡単ですが、サポートが必要な場合は、この会社の Web サイトを参照してください。クラスタ化、ポート転送、リモート デスクトップのトンネリングなどに関する情報や構成ガイドがあります。

価格 : 99.95 ドル
WinSSHD では、SSH セッションの暗号化方法を指定できる
WinSSHD では、SSH セッションの暗号化方法を指定できる

USB アクティビティを監視する
USB Monitor Professional
www.hhdsoftware.com
これは、あらゆるユーザーに適した製品です。あなたは USB デバイスのドライバを作成したり変更したりするのが好きな DIY ソフトウェアの愛好家でしょうか。それとも、USB デバイスを実際に開発するハードウェア エンジニアでしょうか。あるいは、アクティビティがどうしてこんなに発生しているのか不思議に思って USB デバイスのアクティビティ ライトをただ見つめてしまったことがあるでしょうか。いずれの場合でも、HHD Software が提供する USB Monitor Professional が役に立ちます。このユーティリティでは、USB デバイスと Windows ベースのシステムの間で USB ホスト コントローラ経由で転送されるデータを記録、表示、および分析できます。
UI は多少複雑ですが、慣れれば管理対象の USB デバイスの入出力データに関する大量の情報を収集できます。既定では、USB デバイスに渡されるほとんどのコマンドとコマンド セットが記録されます。デバイスによっては (特に大容量記憶装置では)、この処理が非常に冗長になることがあります。さいわいなことに、大容量記憶装置について記録するデータをカスタマイズできます。
セッションを記録すると、データをさまざまな方法で分析できます。大容量記憶装置の場合は、[Mass Storage View] (大容量記憶装置ビュー) が表示されます。統計やデバイス スループットに関する線形グラフ、生パケットと制御リクエストのビュー、データ パケット デコーダ ビュー、HID 専用のビュー、および静止画像ビュー (適用されるデバイスの USB Still Image プロトコルをデコード) のオプションもあります。
アプリケーションによって記録されるデータ量の点から、USB 記録セッションの実行を長時間続けるのは好ましくありません。ただし、アクティブな記録セッションで使用できるディスク領域の最大容量を制限したり、記録されたデータを圧縮して必要なディスク領域を少なくすることもできます。

価格 : 標準ライセンス 175.99 ドル～
USB Monitor Professional は USB デバイスに渡されるコマンドを記録する
USB Monitor Professional は USB デバイスに渡されるコマンドを記録する

仮想メディアを管理する
Virtual CloneDrive
www.elby.ch/fun/software
物理メディアの取り扱いは非常に面倒になる場合があります。私は Windows Vista に切り替えて Microsoft 仮想 CD-ROM コントロール パネルとの直接的な互換性がなくなったので、CD-ROM と DVD-ROM のイメージをマウントできる他の方法を探していました (ところで、Windows XP の Microsoft® 仮想 CD-ROM コントロール パネルに関心のある方は、go.microsoft.com/fwlink/?LinkId=94801 からダウンロードできます)。
もちろん、仮想 CD-ROM コントロール パネルは Windows Vista でも実行できます。問題は、常に管理者として実行する必要があるため、管理者コンテキスト、つまり [管理者として実行] を使用して開いたコマンド プロンプトでしかマウントされたドライブを表示できないということです。ユーザーの Windows エクスプローラでは表示できません。その結果、ツールが必要なときに動作しないだけでなく、アプリケーションを安全性の低い環境で実行する必要があるのです。
私が見つけたツールは、Windows Vista のユーザー コンテキストで動作します。
それは、Elaborate Bytes が提供する Virtual CloneDrive
です。このアプリケーションは、GUI 管理アプリケーションとして、またデバイス マネージャで確認できる
ストレージ コントローラとしてインストールされます。インストール後には、3 つの基本設定を行います。1 つ目の設定では、
使用する仮想ドライブの数を指定できます。同時に 8 ドライブまで使用できます。2 つ目は私のお気に入りのオプションで、[Virtual Sheep] (仮想羊) 設定を指定するかどうかを選択できます。この設定を指定すると、標準の CD/DVD ドライブ アイコンが怒った顔の羊に置き換わります。そのため、ISO ドライブとシステム上の実際の物理ドライブを区別できます。3 つ目の設定では、その仮想ドライブに前回割り当てたイメージを起動時に自動マウントするかどうかを選択できます。
Virtual CloneDrive では、ISO ファイル以外に、.ccd、.dvd、.img、.udf、および .bin ファイルもマウントしたり読み取ったりできます。また、Virtual CloneDrive は Windows エクスプローラに統合されるため、イメージのマウントやマウント解除をすばやく実行できます。Virtual CloneDrive の最も優れた点の 1 つは、無料であるということです。Windows Vista® に移行して、ISO ファイル管理の新しいソリューションをお探しの場合は、このツールを試してみてください。

価格 : 無償
Virtual CloneDrive の怒った顔の羊
Virtual CloneDrive の怒った顔の羊

ブック レビュー
『SharePoint Products and Technologies Administrator's Pocket Consultant』
microsoft.com/MSPress/books/10623.aspx
今日のオフィスはペーパーレス化されているとは言えませんが、電子化されたドキュメントを扱う機会は確実に増えています。これらのドキュメントの管理と共有は、ますます大きな問題になっていますが、その解決策として、多くの企業は Microsoft SharePoint®Services および SharePoint Server を検討しています。その際には、Ben Curry 著『Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant』が役立ちます。SharePoint を単に検討しているだけか、計画段階に深くかかわっているか、または既に SharePoint インフラストラクチャを導入していても、管理機能と日常タスクに関するこのリファレンスは必携の書です。
管理者用ポケット コンサルタント シリーズをご存知の方は、このガイドが身近に感じられると思います。内容のレベルと構成の点では、他の管理者用ポケット コンサルタントと同等です。『Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant』では、Windows SharePoint Services 3.0、SharePoint Server 2007 Standard、および SharePoint Server 2007 Enterprise Edition が扱われています。この書籍は次の 4 つのセクションから構成されています。
最初のセクション「SharePoint Products and Technologies Fundamentals」(SharePoint 製品とテクノロジの基本) では、SharePoint Server 製品のコンポーネント、バージョン、要件、およびインストールの概要を示しています。Windows SharePoint Services 3.0 と SharePoint Server の Standard バージョンおよび Enterprise バージョンの違いについても説明しています。このセクションの説明に従って 3 つの各製品をインストールできます。インストール中に作成される SQL Server データベースと IIS Web サイトに関する詳しい説明もあります。
次のセクション「SharePoint Core Administration」(SharePoint コア管理) では、サーバーの全体管理の UI について説明し、新しいサイト コレクションとサイトの作成方法、Web パーツのインポート、使用、および編集方法、インストールのグループと電子メール設定の構成方法に関する参考情報を示しています。さまざまなワークフロー機能の管理方法や、ワークフローの監視方法に関する説明もあります。
3 番目のセクション「Working with SharePoint Server 2007」(SharePoint Server 2007 の操作) では、SharePoint Server の Standard バージョンおよび Enterprise バージョン固有の機能について詳しく説明しています。エンタープライズ コンテンツ管理の構成方法、SharePoint ポータルの作成および構成方法、検索とインデック作成の設定方法、Excel®Calculation Services の構成方法などに関するトピックがあります。Excel Calculation Services のセクションでは、マルチサーバー環境でサービスを構成して、パフォーマンスと可用性を向上させる方法についても説明されています。
4 番目のセクションでは、SharePoint Server 2007 をサーバー ファームに拡張する方法や、実装で使用できるさまざまな構成を示して、SharePoint Server 実装の運用面について詳しく説明しています。最後に、バックアップと復元操作の基本、パフォーマンスの分析方法、およびサイトの管理や改善に役立つ SharePoint Server のログ機能を使用する方法を示しています。
この書籍は、タイトルからは管理者が毎日使うリファレンスという印象を受けますが、計画段階にいる人や SharePoint にただ興味を持っている人も、この書籍を読めば SharePoint をすばやく理解できると思います。この書籍の構成は次のとおりです。まず、さまざまな SharePoint テクノロジと実行可能な操作に関する基本情報を示し、Excel Calculation Services の構成やサーバー ファームへの拡張など、徐々に複雑なトピックに進みます。このような構成になっているため、SharePoint 初心者にとって役立つリファレンスであり、知識を深めた人にとっても引き続き役立つリファレンスになるでしょう。

価格 : 29.99 ドル

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、開発に役立つ IT プロフェッショナルのためのツールと方法を日夜追い求めています。


 SQL に関する Q&amp;A: CPU ボトルネック、データベースの復元と移動など
SQL に関する Q&A
CPU ボトルネック、データベースの復元と移動など
Nancy Michell

質問 - 変更は一切加えていないのですが、SQL Server™ の CPU 使用率が突然急激に上昇し始めました。新しいユーザーを追加したり、ハードウェアが故障したり、新しいテーブルを作成したりしたわけではありません。一体何が起きているのでしょうか。

ヒント : インデックス作成中のアクセス
大規模なテーブルでは、インデックスの作成に非常に時間がかかる場合があります。そのようなテーブルのインデックスを作成しているときに、そのテーブルのデータを利用できるようにすることが必要な場合があります。どのようにすれば、この両方の目的を達成できるでしょうか。
SQL Server では、クラスタ化インデックスの作成、削除、または再構築を行うときに、必ず、テーブルにスキーマ修正 (SCH-M) ロックがかけられます。このロックにより、インデックスの操作中はどのユーザーも、基になるデータにアクセスすることができなくなります。これはテーブルにインデックスを作成しているときに発生する問題です。クラスタ化インデックスとは異なり、列の非クラスタ化インデックスの作成時には、テーブルには共有 (S) ロックがかけられます。このロックでは基になるテーブルのデータを更新することはできませんが、SELECT ステートメントを実行することはできるので、データを読み取ることができます。
クラスタ化インデックスの作成中にテーブルに対して読み取り操作を実行できるようにする必要がある場合、オンライン操作としてテーブルのインデックスを作成する方法があります。このコマンドは次のとおりです。
CREATE UNIQUE CLUSTERED INDEX CLUST_IDX_SQLTIPS
ON SQLTips (tip) with (ONLINE=ON) Go;
テーブルに対してオンライン インデックス操作を行う場合も、クラスタ化インデックスの場合には SCH-M ロックが、非クラスタ化インデックスの場合には S ロックが基になるテーブルにかけられますが、その期間は非常に短く、インデックス操作の開始フェーズと終了フェーズのみです。したがって、オンライン インデックス操作を使用すると、インデックスの作成処理中も基になるテーブルにアクセスしてクエリや更新を行えるようになります。ただし、インデックスの作成などの操作をオンラインで行えるのは、SQL Server 2005 Enterprise Edition のみであることに注意してください。

回答 - 変更を行ったわけでもなくサーバーの負荷が増えたわけでもないのに突然前触れもなく CPU ボトルネックが発生する場合には、サーバーの中核になんらかの原因がある可能性があります。一般的な原因としては、最適ではないクエリ プラン、SQL Server の構成が不十分であること、アプリケーションやデータベースのデザインが不適切であること、ハードウェア リソースの不足などが考えられます。
このような場合には、まず、サーバーが CPU を占有しているかどうかを確認し、占有している場合は、ローカルの SQL Server システムで CPU を最も多く使用しているステートメントを特定する必要があります。パフォーマンス モニタの PROCESSOR:% PROCESSOR TIME カウンタを確認すると、サーバーが CPU を占有しているかどうかを判断できます。1 つの CPU の時間あたりの値が 75％ 以上の場合は、CPU ボトルネックが発生しています。
また、SYS.DM_OS_SCHEDULERS と呼ばれるシステム動的管理ビュー (DMV) をクエリして SQL Server スケジューラを監視し、実行可能なタスクの値を確認する必要もあります。ゼロ以外の値は、そのタスクが、割り当てられているタイム スライスを実行するまで待機しなければならないことを意味します。また、このカウンタの値が大きい場合も CPU ボトルネックの兆候になります。
次のクエリを使用してすべてのスケジューラを一覧表示し、実行可能なタスクの数を確認することができます。
SELECT
 Scheduler_ID,
 Current_Tasks_Count,
 Runnable_Tasks_Count
FROM
 SYS.DM_OS_SCHEDULERS
WHERE
 Scheduler_ID < 255
CPU 使用量の多い SQL ステートメントの上位 50 件を取得するには、図 1 のクエリを使用します。
Figure 1 CPU の使用量が多い上位 50 件のステートメント (Close Figure 1)
SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
 Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
 Total_Physical_Reads,
 SUBSTRING(b.text,a.statement_start_offset/2,
 (case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
 else
 a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
 dbname=Upper(db_name(b.dbid)),
 b.objectid AS 'Object_ID'
 FROM sys.dm_exec_query_stats a
 CROSS APPLY
 sys.dm_exec_sql_text(a.sql_handle) AS b
 ORDER BY
 [Avg_CPU_Time] DESC

質問 - SQL Server 2005 データベースをテープから復旧する必要がありました。データベースの復元後、ユーザーがデータベースに対して持っていたほとんどの権限が失われました。データベースの復元中に、私が行った間違った操作は何だったのでしょうか。データに問題はありませんでしたが、権限の方は散々です。

回答 - おそらく master データベースを同じ場所に復元していなかったのでしょう。その場合、ユーザー データベースのログイン ID と現在の master データベースのログイン ID は一致しません。ログイン ID を同期する必要があります。「データベースの移動に関する詳細情報」に、データベースの復元時または移動時に発生した問題の原因を特定するための適切なリソースを紹介します。

質問 - SQL Server 2005 SP1 の OpenXML を使用して XML データをリレーショナル テーブルに細分化するストアド プロシージャを使用したアプリケーションを開発しました。XML ドキュメントのサイズは最大 5 KB (平均 2.5 KB) です。ストアド プロシージャは、最大 50 回まで並列処理で呼び出されます。
現在、深刻なロックの競合問題が発生しています。私は OpenXML に原因があると考えていますが、どう思われますか。

回答 - OpenXML は、単一のスレッドでデータの細分化や変換を行う場合には nodes メソッドよりも高速ですが、特に並列処理の場合は nodes メソッドによる処理の方が拡張性があります。ただし、それでも OpenXML を使用する場合は、以下のガイドラインに従って OpenXML 全体のパフォーマンスを上げる必要があります。
開発したアプリケーションについては、既に認識されているようですが、同じ行パターンについて OpenXML を 5 回呼び出すのではなく、同じ行パターンを持つすべてのデータを一時的なテーブルに抽出し、そのテーブルを使用して SELECT 文を実行します。また、sp_xml_removedocument を使用してできるだけ早い段階でメモリを解放します。可能であれば、* や // などのワイルドカードを使用しないようにしてください。パスを明示的に指定すると、クエリのパフォーマンスが向上します。

質問 - サーバーで実行している DBCC SHRINKFILE が非常に低速です。マルチプロセッサ コンピュータで実行すればパフォーマンスは向上しますか。この状況を改善するために何ができるでしょうか。

回答 - DBCC SHRINKFILE は、シングル スレッドの操作です。つまり、複数の CPU を活用することはできません。DBCC SHRINKFILE では、ページがファイルの末尾から先頭に 1 ページずつ移動されます。そして、圧縮と呼ばれることの多いこの操作では、最適化は実行されません。実際のところ、多くの場合、圧縮操作によって論理的な断片化は増加します。
圧縮操作のパフォーマンスを向上する方法はいくつかありますが、その １ つにクラスタ化インデックスでページを移動する方法があります。ヒープを使用しており、そのヒープに多数の非クラスタ化インデックスが作成されている場合、処理速度は、クラスタ化インデックスが作成されている場合に比べて著しく遅くなります。
また、ラージ オブジェクト (LOB) データのページの移動も、LOB データのルートを見つけるために行データを読み取る必要があるので、処理速度は遅くなります。
インデックスとテーブルのほとんどの内容がファイルの末尾に格納されている場合、インデックスを再構築して、その内容をファイルの先頭に移動できます。インデックスの再構築では、複数の CPU が活用され、bulk_logged モードで使用するログの領域を削減することができます。その後、圧縮を実行すると、実行速度が速くなります。
圧縮操作の詳細については、まず、blogs.msdn.com/sqlserverstorageengine/archive/2007/03/29/how-does-your-schema-affect-your-shrink-run-time.aspx と blogs.msdn.com/sql-serverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx の記事を参照してください。
データベースの移動に関する詳細情報
  • SQL Server を実行しているコンピュータ間でデータベースを移動する方法
  • SQL Server のデタッチとアタッチ機能を使用して SQL Server データベースを新しい場所に移動する方法
  • [INF] RESTORE ステートメントでの WITH MOVE オプションの使用
  • [HOWTO] SQL Server を実行しているサーバー間でデータベースを移動するときに、権限の問題を解決する方法
  • SQL Server のインスタンス間でログインおよびパスワードを転送する方法
  • [INF] SQL Server 2000 のデータベース コピー ウィザードの説明とトラブルシューティング
  • データベースの復元後にデータベース上のユーザー ログインと権限が無効になる
  • システム データベースのバックアップを別のビルドの SQL Server に復元できない
  • [HOWTO] データベース バックアップまたはトランザクション ログ バックアップからテーブルまたは行を取得する方法

ヒント : ポートの変更
SQL Server に詳しいユーザーであれば、SQL Server がリッスンする既定のポート番号が、ポート 1433 であることはご存知でしょう。SQL Server の名前付きインスタンスは動的ポートを使用するように構成されますが (SQL Server インスタンスは、起動時に、使用可能な任意のポートを選択できます)、SQL Server の既定のインスタンスは常にポート 1433 でリッスンします。そのため、サーバーが既定のポートでリッスンしている場合、そのポートのセキュリティが厳重に確保されていなければ、サーバーは危険にさらされることになります。ただし、既定のポートを変更することで攻撃を阻止できます。その方法を以下で説明します。
SQL Server 構成マネージャを開き、[SQL Server 2005 ネットワークの構成]、[<InstanceName> のプロトコル] を順に展開します。次に、[TCP/IP] をダブルクリックします。下記の TCP/IP のプロパティと各プロパティの説明の一覧に従って設定します。
SQL Server データベース エンジンは、複数のポートで同じ IP アドレスをリッスンできるので、使用するポートを 1433,1500,1501 のようにコンマ区切りの形式で指定します。1 つの IP アドレスを複数のポートでリッスンするように構成する場合は、[TCP/IP のプロパティ] ダイアログ ボックスの [プロトコル] タブで、[すべて受信待ち] パラメータを [いいえ] に設定する必要があります。
次に、各アドレスを右クリックし、[プロパティ] をクリックして構成する IP アドレスを特定します。[TCP 動的ポート] ダイアログ ボックスに 0 が設定されている場合はデータベース エンジンが動的ポートでリッスンしていることを表すので、0 を削除します。IP のプロパティの [TCP ポート] ボックスに、この IP アドレスをリッスンするポート番号を入力し、[OK] をクリックします。コンソール ウィンドウで [SQL Server 2005 のサービス] をクリックし、詳細ウィンドウで [SQL Server (<instance name>)] を右クリックして [再起動] をクリックし、SQL Server を停止して再起動します。
特定のポートでリッスンするように SQL Server を構成すると、サーバーで SQL Server Browser サービスを実行してデータベース エンジンのインスタンスに名前を使用して接続する方法、クライアント上に別名を作成してポート番号を指定する方法、およびカスタム接続文字列を使用して接続するようにクライアントをプログラムする方法という 3 つの方法でクライアントとポートを接続できます。

プロパティ | 説明
アクティブ | 指定されたポートで SQL Server がリッスンしていることを示します。IPAll では使用できません。
有効 | この接続を有効または無効にします。IPAll では使用できません。
IP アドレス | この接続で使用する IP アドレスを確認または変更します。コンピュータで使用している IP アドレスとループバック IP アドレス 127.0.0.1 が表示されます。IPAll では使用できません。
TCP 動的ポート | 動的ポートが無効の場合は空白です。動的ポートを使用する場合は、0 に設定します。
TCP ポート | SQL Server がリッスンするポートを確認または変更します。既定により、既定のインスタンスはポート 1433 でリッスンします。このフィールドには 2,047 文字まで入力できます。

今月の質問に回答してくれた Microsoft IT 技術支援スタッフに心より感謝します。Chad Boyd、Cindy Gross、John Hadden、Saleem Hakani、Stephen Jiang、Mahesh Nayak、Paul Randal、Wayne Yu


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

標準の Windows® デフラグ ツールを使えば、ハード ディスク上のほとんどのファイルを最適化できますが、ほとんどのデフラグ ツールでは処理できないアイテムもあります。たとえば、開かれているファイルや、Windows ページ ファイルやレジストリ ハイブなどの排他的に使用する目的でロックされているファイルは、組み込みの Windows デフラグ ツールまたはサードパーティ製ユーティリティでは通常、処理されません。標準の Windows API では、これらの使用中のファイルのデフラグはサポートされていません。さいわい、Sysinternals のために Mark Russinovich が開発した PageDefrag ユーティリティは、他のツールで処理できないアイテムをデフラグしてくれます。
PageDefrag では、Windows ページ ファイル、レジストリ ハイブ、イベント ログ、および休止状態ファイル (ノート パソコンが休止状態になったときにメモリ内容が保存されるディスク上の領域) をデフラグできます。これらのファイルが最適化されるのは、PC の起動シーケンス中であり、ファイルの使用前です。
PageDefrag を実行するには、pagedfrg.exe ファイルをダブルクリックするだけです。実行すると、デフラグ可能な各ファイルの名前が表示されます (図 1 を参照)。ページ ファイルは pagefile.sys です。レジストリ ハイブは、ハイブ (DEFAULT、SAM、SECURITY、SOFTWARE、および SYSTEM) ごとに個別のファイルとして表示されます。イベント ログも、ハイブごとに個別のファイルとして表示されます。たとえば、AppEvent.evt はアプリケーション ログ、SecEvent.evt はセキュリティ ログ、SysEvent.evt はシステム ログです。最後に、休止状態ファイルは Hiberfil.sys です。
図 1 PageDefrag により、処理可能な各ファイルの名前が表示される
図 1 PageDefrag により、処理可能な各ファイルの名前が表示される
各ファイル名の横に [Clusters] (クラスタ) 列と [Fragments] (フラグメント) 列があります。[Clusters] (クラスタ) 列には、そのファイルに割り当てられているディスク上のクラスタの数が表示されます。[Fragments] (フラグメント) 列には、ディスク上に散在するフラグメント (ファイルの非連続部分) の数が表示されます。このデータに基づいて、ファイルをデフラグするかどうかを判断できます。
2 つのオプションがあり、ファイルを次回の起動時にデフラグするか、または起動のたびにデフラグするかを選択できます。ファイルの使用頻度が高い場合や、PC がほとんど再起動されることがないサーバーなどのコンピュータである場合を除いて、次回の起動時にデフラグを実行することをお勧めします。カウントダウンを有効にすることもできます。有効にすると、PC の起動開始直後に、デフラグの実行を取り消すことができます。
次回コンピュータを再起動すると、標準の chkdsk コマンドが実行され、その後に PageDefrag が実行されます。既に連続クラスタで構成されているファイルについては、デフラグは実行されません。断片化されているファイルは、1 つずつ最適化されます。デフラグ中の各アイテムの名前が表示され、デフラグが成功したかどうかがわかります。また、デフラグの前後でそのファイルに割り当てられているクラスタの数も表示されます。
PC の空きディスク領域が少なすぎる場合、または空き領域自体が断片化されすぎている場合は、PageDefrag でファイルを最適化できないことがあります。このような場合は、より多くの領域を確保し、Windows 標準のデフラグ ツールを実行して空き領域を最適化してから、PageDefrag をもう一度実行します。
PageDefrag は、処理するファイル数が少ないので、通常はすぐに実行が完了します。ただし、ファイルの断片化の程度が高い場合は、少なくとも初回は完了までに時間がかかることがあります。PageDefrag の処理が完了すると、Windows が通常どおり読み込まれます。その後、PageDefrag プログラムをもう一度開いて、各ファイルが 1 つのフラグメントになっていることを確認できます。
PageDefrag を非対話的に実行するには、コマンド ラインまたはスクリプトで、pagedfrg.exe に -e (起動のたびにデフラグを実行する)、-o (デフラグを一度だけ実行する)、-n (デフラグを実行しない)、-t (カウントダウンを指定した秒数に設定する) などのオプションを使用します。
PageDefrag の詳細情報およびダウンロードについては、microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx を参照してください。

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


 The Cable Guy: 強力なホスト モデルと弱いホスト モデル
The Cable Guy
強力なホスト モデルと弱いホスト モデル
Joseph Davies

ますます一般的になっているネットワーク ホストの構成は、複数のネットワーク インターフェイスによってマルチホーム化された構成です。マルチホーム ホストでは、イントラネットやインターネットなどの複数のネットワークに同時に接続できるため、強化された接続が提供されます。ただし、イントラネットと
インターネットの両方に接続できるため、マルチホーム ホストで実行されているサービスは、攻撃を受けやすくなる可能性があります。この記事では、それらの攻撃からコンピュータを保護し、マルチホーム ホストで IP トラフィックがどのように処理されるかについて理解するために、マルチホーム ホストの弱いホスト モデルと強力なホスト モデルについて説明し、その後、これらのモデルが Windows® でどのようにサポートされているかについて説明します。
RFC 1122 は、ルーターとして機能せずにユニキャスト IP トラフィックの送受信のみを行うマルチホーム ホストの 2 つのモデルについて記述した仕様です。これらのモデルは、強力なホストと弱いホストといい、送受信されるユニキャスト トラフィックが、経由するネットワーク インターフェイスに関連付けられている必要があるかどうかを指定しています。これらのモデルによって、ホストがパケットを送受信する方法と、そのホストで実行されているサービスの脆弱性にもたらされる影響が決まります。
RFC 1122 では IPv4 用のモデルが定義されていますが、これらのモデルは IPv6 にも適用されます。IPv6 のマルチホーム ホストの例としては、イントラネットに接続されるネットワーク アダプタと IPv6 トンネリング インターフェイスを持ち、IPv4 と IPv6 の両方を使用するコンピュータがあります。

弱いホスト モデル
弱いホスト モデルでは、IP ホスト (IPv4 または IPv6) は、送信パケットに指定された送信元 IP アドレスが割り当てられていないインターフェイスで、それらのパケットを送信できます。これを、弱いホストの送信動作といいます。また、IP ホストは、受信パケットに指定された送信先 IP アドレスが割り当てられていないインターフェイスで、それらのパケットを受信できます。これを、弱いホストの受信動作といいます。
複数のインターフェイスを持つマルチホーム IP ホストを使用している場合、インターフェイスで弱いホストの受信動作を有効にすると、そのホストはマルチホーム攻撃を受けやすくなることがあります。たとえば、図 1 は、インターネットとイントラネットの両方に接続されるホスト A を示しています。ホスト A のインターネット インターフェイスにはパブリック IPv4 アドレス 131.107.89.211 が割り当てられ、イントラネット インターフェイスにはプライベート IPv4 アドレス 192.168.17.48 が割り当てられています。
図 1 マルチホーム コンピュータの例
図 1 マルチホーム コンピュータの例
インターネット インターフェイスとイントラネット インターフェイスの両方で、弱いホストの送信動作が有効になっている場合、ホスト A は、131.107.89.211 と 192.168.17.48 からのパケットを、インターネット インターフェイスとイントラネット インターフェイスのどちらで送信することもできます。
また、弱いホストの受信動作が有効になっている場合、ホスト A は、131.107.89.211 と 192.168.17.48 へのパケットを、インターネット インターフェイスとイントラネット インターフェイスのどちらで受信することもできます (ホストのファイアウォール規則で受信トラフィックが許可されていることを前提とします)。
弱いホストの受信動作を有効にすると、インターネット上の悪意のあるユーザーは、ホスト A のインターネット インターフェイスにパケットを送信することによって、ホスト A からイントラネット上のホストのみに提供されているサービスを攻撃することができます。このような攻撃は、インターネット インフラストラクチャで、192.168.17.48 に送信されたパケットをホスト A のインターネット インターフェイスに転送する動作がサポートされている場合に発生する可能性があります。このような攻撃からコンピュータを保護するには、ホスト A のインターネット インターフェイスに適切なファイアウォール規則を設定します。ただし、適切なファイアウォール規則を設定しても、ホスト A からイントラネット クライアントに提供されているサービスが攻撃を受ける可能性はあります。

強力なホスト モデル
強力なホスト モデルでは、異なる送受信の動作が使用されます。強力なホストの送信動作では、ホストは、送信パケットに指定された送信元 IP アドレスが割り当てられているインターフェイスでのみ、そのパケットを送信できます。また、強力なホストの受信動作では、ホストは、受信パケットに指定された送信先 IP アドレスが割り当てられているインターフェイスでのみ、そのパケットを受信できます。
インターネット インターフェイスとイントラネット インターフェイスの両方で、強力なホストの送信動作が有効になっている場合、図 1 のホスト A は、131.107.89.211 からのパケットをインターネット インターフェイスで送信し、192.168.17.48 からのパケットをイントラネット インターフェイスで送信することのみが可能です。
また、強力なホストの受信動作が有効になっている場合、ホスト A は、131.107.89.211 へのパケットをインターネット インターフェイスで受信し、192.168.17.48 へのパケットをイントラネット インターフェイスで受信することのみが可能です。
強力なホスト モデルを使用した場合、図 1 のホスト A では、192.168.17.48 へのパケットがインターネット インターフェイスですべて破棄されるため、ファイアウォール規則を構成する必要はありません。これは、ホスト A のイントラネット インターフェイスがインターネットから実質的に分離されるためです。
強力なホスト モデルを選択する場合は、それによって、弱いホストの動作用に設計されたいくつかの種類の接続が影響を受ける可能性があることに注意してください。たとえば、一部の負荷分散の実装は、弱いホストの受信動作を使用して、任意のインターフェイスでパケットを受信してから、内部で適切なインターフェイスにそのパケットをルーティングします。また、弱いホストの送信動作を使用して、高速接続に対応したインターフェイスで任意の送信元アドレスからのトラフィックを送信するホストも、影響を受ける可能性があります。

強力なホストの送受信
次に、強力なホストの送受信動作をインターフェイスごとに有効または無効にした場合、一般的なホストで IPv4 または IPv6 の送受信処理がどのように実行されるかについて説明します。
まず IP は、送信パケットに送信元アドレスが指定されているどうかを確認します。送信元アドレスが指定されていない場合、IP は、ルーティング テーブルに対して、パケットの送信先アドレスの制約のない参照を実行します。制約のない参照では、ルーティング テーブルのすべてのルートが対象になります。IP は、選択された送信先のルートに基づいて、次ホップ インターフェイス (リンク層へのパケットの配置に使用されるインターフェイス) と次ホップ アドレスを決定します。また、次ホップ インターフェイスを基に、必要に応じて RFC 3484 で定義されているアドレスの選択処理を使用して、最適な送信元アドレスを決定します。これで、IP がパケットを送信するために必要な、送信元アドレス、送信先アドレス、次ホップ インターフェイス、および次ホップ アドレスが確定します。
送信元アドレスが指定されている場合は、送信元インターフェイスを特定できます。これは、送信元インターフェイスに、この送信元アドレスが割り当てられているためです。その後、IP は、強力なホストの送信動作が送信元インターフェイスで有効になっているかどうかを確認します。
強力なホストの送信動作が無効になっている場合、IP は、ルーティング テーブルに対して、パケットの送信先アドレスの制約のない参照を実行します。IP は、送信先に最も適したルートに基づいて、次ホップ インターフェイスと次ホップ アドレスを決定します。これで、送信元アドレス、送信先アドレス、次ホップ インターフェイス、および次ホップ アドレスが確定します。強力なホストの送信動作が送信元インターフェイスで無効になっていると、その送信元インターフェイスが次ホップ インターフェイスとして指定されない場合があることに注意してください。
送信元インターフェイスで強力なホストの送信動作が有効になっている場合、IP は、ルーティング テーブルに対して、パケットの送信先アドレスの制約付きの参照を実行します。制約付きの参照では、送信元インターフェイスの次ホップ インターフェイスが指定されているルートのみが対象となります。IP は、送信先用に選択されたルートに基づいて、次ホップ アドレスを決定します。これで、送信元アドレス、送信先アドレス、次ホップ インターフェイス、および次ホップ アドレスが確定します。強力なホストの送信動作が送信元インターフェイスで有効になっている場合、常にその送信元インターフェイスが次ホップ インターフェイスとして指定されます。図 2 は、一般的な IP 送信ホストの処理を示しています。
図 2 一般的な IP 送信ホストの処理
図 2 一般的な IP 送信ホストの処理
送信元アドレスが指定されている場合、制約付きのルートの参照は、ルーティング テーブルに記録されている、送信先に適した複数のルートから、よりメトリックの高いルートを選択できます。たとえば、図 1 のホスト A には 2 つの既定のルートがあります。1 つはメトリックが 10 のインターネット用のルート、もう 1 つはメトリックが 20 のイントラネット用のルートです。どちらの LAN インターフェイスでも、強力なホストの動作が有効になっています。
ホスト A の送信側アプリケーションによって送信元アドレスが指定されなかった場合、ルートの参照の結果、メトリックが最も低い既定のルートが選択されます。この場合、ホスト A は、常にインターネット インターフェイスから、送信元アドレス 131.107.89.211 でトラフィックを送信します。しかし、ホスト A の送信側アプリケーションによって送信元アドレス 131.107.89.211 が指定された場合、ルート参照の結果、インターネット インターフェイスの既定のルートが選択されます。この場合、ホスト A は、インターネット インターフェイスからトラフィックを送信します。ホスト A の送信側アプリケーションによって送信元アドレス 192.168.17.48 が指定された場合、ルートの参照の結果、イントラネット インターフェイスの既定のルートが選択されます。この場合、ホスト A は、イントラネット インターフェイスからトラフィックを送信します。制約付きのルートの参照を使用した場合、IP は、メトリックが高いほうの既定のルートを使用し、送信元アドレス 192.168.17.48 でトラフィックを送信します。
受信トラフィックの場合、まず IP は、そのトラフィックの送信先がホストであるかどうかを確認します。ホストはルーターとして機能していないため、送信先がホストではない場合、IP はそのパケットを確認なしで破棄します。次に IP は、受信インターフェイス (パケットを受信するインターフェイス) で強力なホストの受信動作が有効になっているかどうかを確認します。無効になっている場合、IP はそのパケットを処理します。有効になっている場合は、パケットの送信先アドレスが受信インターフェイスに割り当てられているかどうかを確認します。割り当てられている場合、IP はそのパケットを処理します。割り当てられていない場合、IP はそのパケットを確認なしで破棄します。図 3 は、一般的な受信ホストの処理を示しています。
図 3 受信ホストの処理
図 3 受信ホストの処理

Windows における弱いホストと強力なホストの動作
Windows XP と Windows Server® 2003 では、すべての IPv4 インターフェイスでの送受信に弱いホスト モデルが使用され、すべての IPv6 インターフェイスでの送受信に強力なホスト モデルが使用されます。この動作を構成することはできません。Windows Vista と Windows Server 2008 の次世代の TCP/IP スタックでは、Teredo ホスト固有のリレーに使用される Teredo トンネリング インターフェイスを除くすべてのインターフェイスで、IPv4 と IPv6 の両方に対して、強力なホストの送受信動作がサポートされます。図 4 は、インターフェイスごとに IPv4 と IPv6 の送受信動作を構成するために使用できるコマンドの一覧です。InterfaceNameOrIndex には、ネットワーク接続フォルダに表示されるインターフェイスの名前か、そのインターフェイス インデックスを指定してください。インターフェイスのインターフェイス インデックスは、次のコマンドを実行して表示されたインターフェイスの一覧で確認できます。
Figure 4 強力なホストと弱いホストの送受信動作を構成するためのコマンド (Close Figure 4)

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
netsh interface ipv6 show interface
弱いホストの動作と強力なホストの動作と RFC 3484
RFC 3484 では、接続に使用する送信元と送信先の IPv6 アドレスと IPv4 アドレスを選択するための標準化された方法を提供するために、2 つのアルゴリズムを定義しています。1 つは、特定の送信先アドレスと共に使用するのに最も適した送信元アドレスを選択する、送信元アドレス選択アルゴリズムです。もう 1 つは、利用可能な送信先アドレスの一覧を優先順に並べ替える、送信先アドレス選択アルゴリズムです。
強力なホストと弱いホストの動作は、特定の送信先アドレスと共に使用する送信元アドレスの候補の一覧を決定するとき、および最終的に送信先アドレスの一覧を並べ替えるときに影響を与えます。強力なホストの送信動作の場合、送信元アドレスの候補の一覧には、その送信先に使用される送信インターフェイスに割り当てられたユニキャスト アドレスが列挙されます。弱いホストの送信動作の場合、候補の一覧には、弱いホストの送信動作が有効になっているインターフェイスに割り当てられたアドレスが列挙されます。送信元アドレスと送信先アドレスの選択については、microsoft.com/technet/community/columns/cableguy/cg0206.mspx を参照してください。

既定では、Teredo ホスト固有のリレーに使用される Teredo トンネリング インターフェイスを除くすべてのインターフェイスで、IPv4 と IPv6 の両方に対して、弱いホストの送受信動作が無効になっています。
RFC 3484 の詳細については、補足記事「弱いホストの動作と強力なホストの動作と RFC 3484」を参照してください。

リモート アクセス VPN 接続の既定のルートを無効にする
マルチホーム ホストのもう 1 つの例として、リモート アクセス仮想プライベート ネットワーク (VPN) クライアントがあります。ホストが単一の LAN インターフェイスでインターネットに接続されている場合でも、リモート アクセス VPN クライアントで VPN 接続が完了すると、マルチホーム ホストになります。このマルチホーム ホストでは、2 つのインターフェイスが使用されます。1 つは LAN インターフェイス、もう 1 つは VPN 接続用の Point-to-Point プロトコル (PPP) に基づいたインターフェイスです。また、IPv4 アドレスも 2 つ割り当てられます。1 つはインターネット サービス プロバイダによって LAN インターフェイスに割り当てられ、もう 1 つは VPN サーバーによって PPP ベースのインターフェイスに割り当てられます。
Windows XP と Windows Server 2003 では、VPN クライアントが既定のルートのトラフィックを VPN 接続経由でイントラネットに送信できるように、IPv4 ルーティング テーブルが変更されています。このルーティング テーブルでは、既存の既定のルートのメトリックが引き上げられ、PPP インターフェイスを使用する、メトリックが低い新しい既定のルートが追加されています。この既定の動作により、VPN 接続が確立されている間は、イントラネット上の場所にアクセスでき、インターネット上のほぼすべての場所にアクセスできなくなります。インターネット上の場所とイントラネット上の場所に同時にアクセスできるように、VPN クライアントでスプリット トンネリングを構成することもできます。これを行うには、VPN 接続の既定のルートを追加せず、イントラネットの送信先用の特定のルートを追加します。ただし、スプリット トンネリングを実行する VPN クライアントは、インターネットとイントラネットとの間でパケットをルーティングできるため、この構成は危険を伴います。詳細については、microsoft.com/technet/community/columns/cableguy/cg1003.mspx を参照してください。
Windows XP と Windows Server 2003 における既定の VPN クライアントの動作は、弱いホストの送信動作用に設計されました。このルートの参照では、メトリックが最も低い、VPN 接続の既定のルートが常に使用されます。ただし、強力なホストの送信動作を使用した場合、送信トラフィックに使用される既定のルートは、パケットの送信元 IP アドレスによって異なります。ISP によって割り当てられた IPv4 アドレスから送信されるトラフィックのルートの参照では、LAN インターフェイスを使用する既定のルートが使用されるため、インターネット上のすべての場所にアクセスできます。また、VPN サーバーによって割り当てられた IPv4 アドレスから送信されるトラフィックのルートの参照では、PPP インターフェイスを使用する既定のルートが使用されるため、イントラネット上のすべての場所にアクセスできます。したがって、強力なホストの送信動作を使用すると、IPv4 ルーティング テーブルを直接変更できる管理者レベルの特権が与えられていないアプリケーションを操作する場合でも、スプリット トンネリングが構成されるため、VPN クライアントはインターネットとイントラネットの両方に同時にアクセスできます。
Windows Vista® と Windows Server 2008 の VPN クライアントでは、強力なホストの送信動作によって、スプリット トンネリング構成が既定で作成されないように、VPN 接続の完了時に LAN インターフェイスの既定のルートが自動的に無効になります。この動作により、PPP インターフェイスを使用するアクティブな既定のルートが、ルーティング テーブル内に複数存在しなくなります。また、管理者レベルの特権を与えられていないアプリケーションがスプリット トンネリングを実行できなくなります。
VPN クライアント コンピュータからのトラフィックは、VPN サーバーによって割り当てられた IPv4 アドレスから送信される必要があるため、インターネットとイントラネットの分離が強化されます。VPN 接続が終了すると、無効になっていた既定のルートが有効になります。
この動作は、次のコマンドを使用して制御できます。
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

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


 Windows PowerShell: シェルのセキュリティ保護
Windows PowerShell
シェルのセキュリティ保護
Don Jones

Windows PowerShell チームが新しいシェルの作成に取りかかり、"スクリプト" という用語が議題に上ったとき、おそらくレドモンド中にうなり声が聞こえたことでしょう。結局のところ、管理用スクリプト (ここでは、VBScript のことを言います) に対するマイクロソフトのこれまでの取り組みに、まったく問題がなかったわけではありませんでした。多くの
ユーザーの希望を取り込み、実行モデルに与えた権限が過剰になってしまったため、深刻な問題が発生する可能性が生じました。
チームの仲間たちは Windows PowerShell™ の最初のミーティングで、「同じ道はたどらない」と決意し、これを実現しました。マイクロソフトは、自らのセキュリティについての評判を大きく向上しました。セキュリティについて、製品の開発サイクルの後半ではなく最初の段階で考え始めたことがその最大要因です。この考え方は、Windows PowerShell に非常にはっきりと表れています。

作成したスクリプトが実行されない理由
Windows PowerShell を新しいコンピュータにインストールして .ps1 ファイルをダブルクリックすると、Windows PowerShell ではなくメモ帳が起動します。これは、Windows PowerShell スクリプトに使用される .ps1 というファイル名拡張子が、シェル自体に関連付けられていないためです。つまり、単純に .ps1 ファイルをダブルクリックしただけではスクリプトを実行できません。スクリプトを実行するには、Windows PowerShell を開き、スクリプト名を入力して Enter キーを押すという方法しかありません。
ただし、実際には、スクリプト名を入力するだけでは不十分です。図 1 を見ると、Demo1.ps1 というファイルが現在のフォルダにありますが、「demo1」と入力して Enter キーを押すと、"用語 'demo1' は、コマンドレット、関数、操作可能なプログラム、またはスクリプト ファイルとして認識されません。" というエラーが返されることがわかります。なぜこのような問題が発生するのでしょうか。結局のところ、ファイルはまったく実行されません。
図 1 Windows PowerShell では、コマンドの乗っ取りを防ぐために、スクリプトのパスを指定する必要があります。
図 1 Windows PowerShell では、コマンドの乗っ取りを防ぐために、スクリプトのパスを指定する必要があります。
これは、Windows PowerShell セキュリティ モデルのもう 1 つの側面です。Windows PowerShell 以外のシェルで悪意のあるユーザーがよく使用する方法の 1 つに、組み込みコマンドと同じファイル名を持つスクリプトを作成する方法があります。たとえば、作成したスクリプトをあるユーザーに実行させたい場合、そのスクリプトに Dir.ps1 という名前を付けてフォルダに格納します。ユーザーに「Dir」と入力して Enter キーを押せばよいと思わせれば、ユーザーが想定していた Dir コマンドではなく、作成したスクリプトを実行させることができます。この方法は、コマンドの乗っ取りと呼ばれます。Windows PowerShell ではスクリプトのパスを必ず指定する必要があるので、コマンドの乗っ取りに対しては非常に堅牢です。
demo1 はパスを指定していないので実行されませんが、「./demo1」と入力すると実行されます。これは、パス (現在のフォルダ) を指定したためです。組み込みコマンドを参照するつもりなら、どのようなパスも入力することはないでしょうから、このコマンド ラインが組み込みコマンドと間違われることはほとんどありません。このように Windows PowerShell では、必ずパスを指定することで、コマンドの乗っ取りと Enter キーを押したときに発生する可能性がある動作をめぐる混乱を回避しています。

スクリプトの実行におけるポリシー
Windows PowerShell を新しくインストールした後は、適切な構文を使用してスクリプトを実行します。驚いたことに、またしても、Windows PowerShell によるスクリプトの実行が許可されてないことを知らせるエラー メッセージで迎えられます。どういうことでしょう。実は、ここからはシェルの実行ポリシーの領域です。
現在の実行ポリシーは、シェルで Get-ExecutionPolicy を実行することによって確認できます。既定では、現在の実行ポリシーとして Restricted が設定されています。これは、簡単に言うと、スクリプトが実行されないことを意味します。常に、だれが実行しようとしても、です。既定では、Windows PowerShell はスクリプトを実行するためではなく、対話的に実行するためだけに使用できます。Set-ExecutionPolicy コマンドレットを使用すると、以下の 4 つの実行ポリシー設定のいずれかを選択できます。
  • Restricted - 既定の設定です。どのスクリプトも実行できません。
  • AllSigned - 信頼されたスクリプトのみ実行できます (これについては、後で詳しく説明します)。
  • RemoteSigned - ローカル スクリプトであれば、信頼されていなくても実行できます。ただし、インターネットからダウンロードしたスクリプトを実行するには、そのスクリプトを信頼する必要があります。
  • Unrestricted - 信頼されていないスクリプトも含め、すべてのスクリプトを実行できます。
実のところ、運用環境のすべてのコンピュータに設定すべき最も低い設定は、AllSigned です。開発環境やテスト環境では RemoteSigned が役立ちますが、この設定は通常のユーザーには必要ありません。また、どのような場合であれ、Unrestricted が不要であることもわかっているので、Windows PowerShell の今後のバージョンでこのような権限を過剰に与える設定が削除されたとしても気になりません。

信頼に関する質問
コンピュータは、ルート証明機関 (CA) (デジタル証明書を発行するサーバー) を信頼するようにあらかじめ構成されています。図 2 に、信頼されたルート CA が一覧表示された、コントロール パネルにある [インターネット オプション] アプリケーションを示します。Windows Vista® では、この一覧は非常に簡潔で、いくつかの主要な商用のルート CA のみが表示されます。これに対し、Windows® XP の既定の一覧はサイズが大きく、聞いたこともないようなルート CA が多数表示されます。この一覧にルート CA が含まれていれば、原則的に、そのルート CA を運営する会社がデジタル証明書の発行前に行う ID 確認プロセスには問題がなく、その会社を信頼していることを表します。
一般にコード署名証明書と呼ばれるクラス 3 のデジタル証明書を取得する場合、CA (商用の CA または組織内に存在するプライベート CA) によって ID の確認が行われる必要があります。デジタル証明書は、電子パスポートや電子 ID カードのようなものです。CA は、私が Don Jones であることを示す ID を私に与える前に、いくつかの段階を踏んで、本当に私が Don Jones であることを確認する必要があります。自分の証明書を使用して Windows PowerShell スクリプトにデジタル署名する場合は、Set-AuthenticodeSignature コマンドレットを使用して、スクリプトに自分の名前を署名します。もちろん、だれか他人の名前を含む偽の証明書を取得できたとしたら、その人の名前でスクリプトに署名できます。そのため、信頼できる CA のみが 図 2 の一覧に表示されることが非常に重要になります。
図 2 Windows Vista の信頼された既定のルート CA
図 2 Windows Vista の信頼された既定のルート CA
実行ポリシーの設定が AllSigned および RemoteSigned の場合、スクリプトを信頼できるかどうかが Windows PowerShell によってチェックされるときに、以下の 3 項目についての質問が行われます。
  • そのスクリプトには署名されていますか。署名されていなければ、そのスクリプトは信頼されません。
  • 署名が損なわれていますか。つまり、そのスクリプトは、署名後に変更されていますか。署名が損なわれていれば、そのスクリプトは信頼されません。
  • 署名は信頼されているルート CA によって発行されたデジタル証明書を使用して作成されていますか。そうでなければ、そのスクリプトは信頼されません。
今月のコマンドレット : Set-AuthenticodeSignature
Set-AuthenticodeSignature は、Windows PowerShell スクリプトにデジタル署名するための重要なコマンドレットです。このコマンドレットを使用すると、シェルにおいて最も安全性の高い実行ポリシーである AllSigned を使用できます。このコマンドレットを使用するには、インストールされたコード署名証明書をフェッチする Get-ChildItem という別のコマンドレットを最初に使用します。
$cert = Get-ChildItem –Path cert:\CurrentUser\my –codeSigningCert
ファイルのパスは、インストール済みの証明書を指すパスに置き換える必要があります。インストール済みの証明書には、すべて cert: ドライブを使用してアクセスできます。証明書が読み込まれたら、次のコマンドレットを実行してスクリプトに署名します。
Set-AuthenticodeSignature MyScript.ps1
–cert $cert
もちろん、コマンドレットのパスには、.ps1 スクリプト ファイルへの完全なパスを指定します。シェルによって、ファイルに署名ブロックが追加されます。

信頼によってどのようにセキュリティが強化されるのでしょうか。確かに、ハッカーは、悪意のあるスクリプトを作成してそのスクリプトに署名をし、環境内のだれかに、そのスクリプトを実行することが正しいと思わせることができる可能性があります。そのスクリプトは署名されているので、実行されます。ですが、署名されているので、その署名から作成者の ID を見つけ、警察当局に電話するなどの適切な措置を講じることができます。けれども、悪意のあるスクリプトを作成した後、自分の本当の名前を署名するなんて、ずいぶん間抜けな話ですよね。
もちろん、悪意のあるユーザーがだれか他人の ID の証明書 (適切な ID 確認プロセスを経ずに CA が発行する証明書など) を入手できたとしたら、その署名を使用して実際の犯人を特定することはできないでしょう。これが、信頼するルート CA に、満足できる ID 確認プロセスが必要とされる理由です。
AllSigned 実行ポリシー設定を使用する場合、自分が作成したすべてのスクリプトについても、実行する前にデジタル署名をしておく必要があります。Set-AuthenticodeSignature コマンドレットは非常に簡単に使用できますが、それでも、多くの煩わしさが伴います。その点においては、サードパーティのソフトウェアが役に立つ場合があります。指定した証明書を使用してスクリプトに自動的に署名を行うスクリプト エディタかビジュアルな開発環境を使用することをお勧めします。それらを使用すると、余計な作業を必要とせず、あまり意識しないで署名を使用できます。このような作業をサポートするエディタや開発環境を希望する場合は、私が運営する SscriptingAnswers.com のようなスクリプトのオンライン フォーラムをいくつか参照し、他の Windows PowerShell ファンがどのようなものを使用しているかを問い合わせるメッセージを投稿してください。
証明書が入手できたら、次のコードを実行して、特定の場所にあるすべてのスクリプトに署名することもできます。
Get-Childitem *.ps1 | %{Set-AuthenticodeSignature $_.fullname $cert}

一元管理されるセキュリティ保護
当然のことですが、Windows PowerShell の実行ポリシーは、コンピュータごとに構成できます。しかし、企業環境にとって、これは適切な解決策とは言えません。代わりに、グループ ポリシーを使用できます (go.microsoft.com/fwlink/?LinkId=93675 から Windows PowerShell の管理用テンプレートをダウンロードできます)。ドメイン全体に適用されるグループ ポリシー オブジェクト (GPO) に、単純にファイルを配置し、Restricted に設定します。これにより、Windows PowerShell をインストールした場所にかかわりなく、スクリプトが実行されないようにすることができます。その後、より制限の少ない設定 (AllSigned) を、スクリプトを実行する必要があるコンピュータ (独自のワークステーションなど) にのみ適用することができます。

代替の資格情報
以前の Windows 用の管理用スクリプト言語とは異なり、Windows PowerShell ではセキュリティで保護された方法で代替の資格情報を処理することもできます。たとえば、Get-WMIObject コマンドレットには –credential パラメータがあり、このパラメータを使用すると、リモート WMI 接続に代替の資格情報を指定できます。このパラメータは、ユーザー名は受け取りますがパスワードは受け取りません。そのため、慎重に扱う必要があるパスワードを、クリア テキスト スクリプトにハードコードする必要がありません。代わりに、ユーザー名を指定したときに、Windows PowerShell のダイアログ ボックスが表示され、パスワードの入力を求められます。代替の資格情報を再利用する場合は、次の Get-Credential コマンドレットを使用して、認証情報を格納できます。
$cred = Get-Credential DOMAIN\USER
すぐにパスワードの入力が求められ、最後の資格情報が変数 $cred に格納されます。その後、変数 $cred を必要なだけ何度でも –credential パラメータに渡すことができます。ConvertTo-SecureString コマンドレットと ConvertFrom-SecureString コマンドレットを使用して、資格情報を暗号化された文字列に変換することや、既に暗号化されている文字列を資格情報に変換することもできます。
これには、暗号化キーが最終的にプレーン テキストのスクリプトに保存されるため、セキュリティをまったく無意味にしてしまうという問題が伴います。そこで代わりの方法として、Get-Credential に対する呼び出しを Windows PowerShell プロファイルに追加することができます。これにより、Windows PowerShell を実行したときに即座にユーザー名とパスワードの入力が求められ、入力したユーザー名とパスワードは $cred という変数に格納されます。このようにして、ドメインの管理者アカウントを表す変数 $cred を、いつでもシェルで使用することができます。また、その資格情報の格納先に悩む必要は一切ありません。資格情報はシェルを起動するたびに再作成されるので、格納する必要がないのです。

既定で安全
既定では、Windows PowerShell は、スクリプトをサポートする管理用シェルとして考えられる限り、最もセキュリティの高い状態でインストールおよび構成されます。このような設定を変更しない限り、Windows PowerShell では最大限のセキュリティ レベルが保たれます。つまり、Windows PowerShell のセキュリティ レベルが下がるのは、ユーザーの決定と操作に起因します。そのため、ファイル拡張子の関連付けの再構成や実行ポリシーの変更といった、既定設定の変更を行う前に、必ず操作の結果を完全に把握し、変更によって問題が発生した場合の対策を検討しておく必要があります。

Don Jones は SAPIEN Technologies のリード スクリプト グルで、ScriptingTraining.com のインストラクタです。Don に対するお問い合わせについては、彼の Web サイト (ScriptingAnswers.com) を参照してください。


 Hey, Scripting Guy!: このリレーションシップを救うことはできますか
Hey, Scripting Guy!
このリレーションシップを救うことはできますか
Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2007_09.exe (150KB)

リレーションシップ (関係) はとても重要です。でも、どうして他のだれでもなく Scripting Guys が、関係の重要性を知っているのでしょうか。まず、1 つには、Scripting Guys はテレビをたくさん見るからです。テレビではいつも関係が重要だと言っています。
関係が重要なのは、連続ドラマやテレビ映画の中だけのことではありません。たとえば、ある給料日ローン会社のコマーシャルでは、視聴者にその会社のビジネスを支援してほしいと働きかけています。もともとローンを組むつもりがない人にお金を貸したいからでしょうか。いいえ、違います。では、ローンで 900% の年利を徴収するつもりだからでしょうか。もちろんそうではありません。この給料日ローン会社は、皆さんと個人的な関係を形成したいのです。この会社のコマーシャルが示すように、"関係は重要" なのです。
注 : 確かに、Scripting Guys は泣いています。でもそのことを恥ずかしいとは思いません。結局のところ、皆さんが冷たく無神経にならざるを得ないのは、ある人と給料日ローン会社を結び付ける深く揺るぎない関係について、ちょっと考えただけで涙してしまわないようにするためなのです。
もちろん、皆さんが言いたいことはわかっています。「おいおい、給料日ローン会社にとって関係が重要だと言うなら、データベースを操作するスクリプトを記述する人にとって関係は本当に重要であるに違いない。」と言いたいのですよね。実際、データベースを操作するスクリプトを記述する人々にとってリレーションシップ (関係) は重要です。しかし、残念ながら、このようなスクリプト作成者たちは関係が重要であるということを理解しているとは限りません。でも、心配はいりません。今月のコラムで Scripting Guys が皆さんに正しい情報をお伝えします。
多くのシステム管理者は、よくハードウェア インベントリの追跡方法としてデータベースを使用します。問題は、このようなデータベースの多くが、決して最適とは言えない方法でセットアップされているということです。たとえば、すべてのコンピュータに搭載されているディスク ドライブを追跡するデータベースが必要だとします。データベース設計の経験がない場合は、図 1 のような 1 つのテーブルで構成されたデータベースを作成する可能性が高いでしょう。
図 1 1 つのテーブルで構成されたデータベース
図 1 1 つのテーブルで構成されたデータベース
ご覧のとおり、このデータベースの設計はとても単純です。コンピュータ名用のフィールドが 1 つあり、コンピュータに C ドライブと D ドライブがあるかどうかを Yes/No で示すフィールドが 2 つあります。それだけです。簡潔で、すっきりしていて、要領を得ています。
では、このデータベースのどこに問題があるのでしょうか。実を言うと、ほとんどすべてに問題があります。どのコンピュータにもディスク ドライブが 2 個以上搭載されていないことが確実な場合には、この設計は (ある程度) 機能します。しかし、ディスク ドライブが 3 個搭載されたコンピュータがある場合はどうなるでしょうか。その場合は、ドライブ E の追跡をするためのフィールドをもう 1 つ追加する必要があります。これは、それほど大きな問題ではありません。しかし、ディスク ドライブが 11 個あるコンピュータの場合はどうなるでしょうか。そして、各ドライブのプロパティを追跡する必要がある場合はどうなるでしょうか。たとえば、各ドライブの合計サイズを把握する必要があるとします。その場合は、Drive_C_Size というフィールドが必要になります。それから、Drive_D_Size というフィールドも必要です。また、Drive_E_Size というフィールドも必要です。ここで説明しようとしていることが、だんだん、わかってきていただけたと思います (使用可能なディスク領域、ディスクのコネクタの種類、ドライブでディスク クォータが有効になってるかどうかなどについても追跡するなんて、とんでもありません)。
この経験に基づいて得られた法則を覚えておいてください。あるエンティティが、あるものを 1 つ以上持つことができる場合 (たとえば、コンピュータは 1 個以上のディスク ドライブを搭載できます)、この "フラット ファイル" (1 つのテーブルで構成されたデータベース) の設計は、適切ではありません。確かに、コンピュータに接続されるディスク ドライブの数には制限があるので、ディスク ドライブについては、フラット ファイルを使用して管理することは可能だと思うかもしれません。しかし、データベースを照会して、100 GB 以上の容量のすべてのディスク ドライブの一覧を取得する必要がある場合はどうでしょうか。このような操作を行うには、どうすればよいでしょうか。まず、Drive_C_Size フィールドで 100 GB のドライブを探し、それから、Drive_D_Size フィールド、Drive_E_Size フィールドでも同様に探す必要があります。全体的に見れば、とても効率的または有効的なアプローチとは言えません。では、他にどんな方法があるのでしょうか。フラット ファイルのデータベースを使用できない場合は、何を使用できるのでしょうか。
答えは簡単です。リレーショナル データベースを使用します。リレーショナル データベースは、特に一対多のリレーションシップ (たとえば、多数のディスク ドライブを搭載できる 1 台のコンピュータ) を扱うために設計されました。それから、聞かれる前に言っておきますが、リレーショナル データベースを使用するために、出かけていって何か新しいものを購入する必要はありません。どんな種類のデータベースでも (Microsoft® Access™、SQL Server™、Oracle など)、データベースには既にリレーショナル データベースが用意されている可能性が高いからです。何も購入する必要はありませんが、次の 2 つの方法だけを知っておく必要があります。1) データベースで、2 つのテーブル間のリレーションシップをセットアップする方法と、2) そのリレーションシップを利用できるスクリプトを記述する方法です。
注 : テレビによると、リレーションシップ (関係) は絶対に利用しないほうがよいのですが、データベースに関しては違います。
このコラムは Hey,Database Design Guy! ではないので、データベース設計の説明に多くの時間を費やすつもりはありません。代わりに、リレーショナル クエリの記述について説明できるように、とても単純なリレーショナル データベース設計を紹介するにとどめます。このデータベースには 2 つのテーブルがあります。1 つ目は Computers という名前で、ComputerName と SerialNumber という 2 つのフィールドで構成されています。ComputerName フィールドにはコンピュータ名が格納され、SerialNumber フィールドにはお察しのとおりのものが格納されます。そうです、シリアル番号です。
では、いったいどこにディスク ドライブの情報が格納されるのでしょうか。それは 2 つ目の DiskDrives という名前のテーブルに格納されます。このテーブルには、SerialNumber、DriveLetter、および DriveSize という名前の一目瞭然な 3 つのフィールドがあります。
ここで重要なフィールドは SerialNumber です。このフィールド名に聞き覚えがあるなら、それは当然です。Computers テーブルにもまったく同じ名前のフィールドがあります。これは事故や偶然によるものではなく、わざとそうしました。これら 2 つのテーブル間にリレーションシップを確立するためには、どちらのテーブルにも存在するフィールドが 1 つ必要です。このようなフィールドにより、どのディスク ドライブがどのコンピュータに属しているかを区別できます。
なぜ、2 つのテーブルをリンクさせるのに、たとえばコンピュータ名ではなくシリアル番号を使用したのでしょうか。これについては正当な理由があります。コンピュータ名は変更できます (また、変更することが多いです) が、一般的に、シリアル番号は変更されないからです。
データベース設計についての説明は十分でしょう。図 2 を見てみましょう。これは、Computers と Disk Drive の 2 つのテーブルを検索して、各コンピュータに搭載されているディスク ドライブの一覧を取得できるスクリプトです。図 3 は、このスクリプトで返されるデータです。
Figure 3 検索結果 (Close Figure 3)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-01
E:

atl-ws-02
C:

atl-ws-02
D:
Figure 2 テーブルの検索 (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
 "Provider = Microsoft.Jet.OLEDB.4.0; " & _
 "Data Source = c:\scripts\test.mdb"

objRecordSet.Open "SELECT Computers.*, DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber " & _
 "ORDER BY Computers.ComputerName, DiskDrives.Drive", objConnection, adOpenStatic, _
  adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
 Wscript.Echo objRecordset.Fields.Item("ComputerName")
 Wscript.Echo objRecordset.Fields.Item("Drive")
 Wscript.Echo
 objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
今月のコラムでは、データベースへの接続や操作の基本事項について説明するつもりはありません。データベースをスクリプトで操作することに不慣れな場合は、Scripting Guys の Web キャスト「システム管理者のためのスクリプトによるデータベースの操作」(go.microsoft.com/fwlink/?LinkId=22089) を参照してください。Scripting Guys が説明するのは、今 Access データベース (C:\Scripts\Test.mdb) に接続しているということと、Computers および DiskDrives という名前のリレーショナル テーブルを操作しているということだけです。これは、スクリプトを見れば非常に明快なことです。
それから、もう 1 つ説明できるのは、このスクリプトを Access 2007 で動作させるために 1 つちょっとした変更が必要だということです。次のようにプロバイダを Microsoft.Jet.OLEDB.4.0 から Microsoft.ACE.OLEDB.12.0 に変更する必要があります。これは重要です。
objConnection.Open _
 "Provider = Microsoft.ACE.OLEDB.12.0; " & _
 "Data Source = c:\scripts\test.accdb"
これで完了です。次に、この 2 つのテーブルからデータを取得する SQL クエリについて説明しましょう。
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
このクエリは複雑でしょうか。もしかすると、少し複雑かもしれません。では、このクエリを少し分解して、わかりやすくしてみましょう。
クエリの最初の部分は実際非常に簡単です。Computers テーブルと DiskDrives テーブルの両方にあるすべてのフィールドを選択する必要があるので、次のような SQL クエリがあります。
SELECT Computers.*, DiskDrives.*
この部分は、それほど難しくないでしょう。もちろん、アスタリスクは、"すべて" を意味する単なるワイルドカード文字です。
以前に SQL クエリを記述したことがある (または SQL クエリ言語のサブセットを使用する Windows® Management Instrumentation (WMI) クエリを記述したことがある) 場合、手順はおわかりでしょう。選択する必要があるアイテムを指定したら、これらのアイテムを選択してくる場所を指定します。したがって、クエリ パズルの次のピースは下記のようになります。
FROM Computers INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber
このスクリプトを見てうろたえないでください。確かに、これは典型的な FROM ステートメントよりも複雑ですが、このステートメントを使用するには正当な理由があります。典型的な SQL クエリでは 1 つのテーブルからデータを選択しますが、今回は一度に 2 つのテーブルからデータを選択する必要があるため、このような複雑な FROM ステートメントを使用しています。
この構文とそれがどのように機能するのかについて詳しく見ていきましょう。ご覧のとおり、スクリプトでは Computers テーブルと DiskDrives テーブルからデータを選択しています。ただし、and は使用せず、代わりに INNER JOIN という表現を使用しています。この表現は、リレーションシップの種類を定義しています。つまり、どのようにして 2 つの異なるテーブルからの情報を 1 つのレコードセットに結合するかを示しています (結合には他にも種類がありますが、それらについては少し後で説明します)。
先ほど説明したとおり、テーブル間のリレーションシップの種類は自由に指定できます。また、それらのテーブルがどう関係付けるかについても厳密に指定できます。次のコード部分では、以上のような処理を行います。
ON Computers.SerialNumber = DiskDrives.SerialNumber
ここでは、テーブルの結合方法を定義しています。Computers テーブルの SerialNumber フィールドと DiskDrives テーブルの SerialNumber フィールドが一致するレコードをグループにまとめます。もし異なるフィールド (たとえば、ComputerName) を結合フィールドとして使用していたとしたら、どうなるでしょうか。その場合は、コードは次のようになります。
ON Computers.ComputerName = DiskDrives.ComputerName
疑問に思っている読者のために一言付け加えておきますが、2 つのフィールドが同じ名前である必要はありません。必要なのは、同じデータが含まれているということだけです。ただし、同じ名前を使用すると、リレーショナル フィールドを特定しやすくなります。ここで、1 つだけ少し気を付けておくことがあります。同じ名前のフィールドが 2 つあるので、これらのフィールドのうちの 1 つを参照する場合には、常に「テーブル名.フィールド名」という構文を使用する必要があります。つまり、Wscript.Echo obj- Recordset.Fields.Item("Computers.SerialNumber") のようなコードを使用します。
これで必要な作業はすべて完了です。クエリの残りの部分では、データを、コンピュータ名で並べ替えてから、ドライブ名で並べ替えているだけです。
ORDER BY ComputerName, Drive
それほど複雑ではなかったでしょう。ちょっと中断して、今度は結合について説明しましょう。なぜ、このクエリでは内部結合を使用したのでしょうか。答えは簡単です。内部結合は、各テーブルで一致する値のあるレコードだけを返します。つまり、シリアル番号 121989 があると仮定すると、このシリアル番号が Computers と DiskDrives テーブルの両方にある場合に、対応するレコードが返されます (もちろん、シリアル番号はどこにでも格納できるわけではなく、SerialNumber フィールドに格納されています)。わかりますよね。よかった。
シリアル番号が 121989 のコンピュータがあるとします。ただし、そのシリアル番号のディスク ドライブはありません。このような場合は、シリアル番号 121989 のコンピュータのデータは返されません。これは、内部結合が、各結合テーブル内のレコードに一致する値がある場合だけ情報を返すからです。
つまり、内部結合クエリはハード ディスクを搭載しているすべてのコンピュータを返しますが、ハード ディスクが搭載されていないコンピュータとコンピュータに搭載されていないハード ディスクは返しません。多くの場合、このような情報を必要とするので、これは便利です。しかし、ハード ディスクを搭載していないコンピュータの一覧やコンピュータに搭載されていないハード ディスクの一覧が必要な場合はどうでしょうか。そのときはどうすればよいのでしょうか。
このような場合には、外部結合の出番となります (そうです、外部結合は、そのためのものなのです)。今回のコラムでは、外部結合には左外部結合と右外部結合の 2 種類だけしかないということにさせてください。このデータベースには 2 つのテーブルがあります。Computers テーブル (マスタ テーブルなので "左" テーブルと見なされます) と DiskDrives テーブル (マスタ テーブルではないので "右" テーブルと見なされます) です。返されるレコードセットに、ディスク ドライブが搭載されていないコンピュータも含め、すべてのコンピュータが含まれている必要があるとします。このような場合は、LEFT OUTER JOIN 構文を使用し、クエリは次のようになります。
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "LEFT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
おそらくおわかりだと思いますが、左外部結合では右テーブルに対応するレコードがなくても、左テーブルのすべてのレコードが返されます。つまり、すべてのコンピュータが返されますが、右テーブル (DiskDrives) から返されるのはコンピュータと関連付けられているレコードだけです。
また、コンピュータに搭載されていないハード ディスクも含めた、すべてのハード ディスクの一覧が必要になる場合があります。この関係において DiskDrives テーブルは右テーブルなので、次のように RIGHT OUTER JOIN 構文を使用します。
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "RIGHT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
さて、考えてみたのですが、この関係において DiskDrives が右テーブルならば、Computers は左テーブルではなく、夫テーブルと呼ばれてもよいのではないでしょうか。しかし、Scripting Guys の何人かが辛い経験から知っているとおり、夫婦という関係において、夫は決して権利のあるエンティティ (存在) ではないのです。
右外部結合を使用すると、右テーブルのすべてのレコード (すべてのディスク ドライブ) が返されますが、コンピュータ (左テーブルのレコード) については、ディスク ドライブと関連付けられているレコードだけが返されます。
今はこの原理があまりわからないかもしれませんが、データベースを少し操作してみれば、どのように動作するかを理解できると思います。操作するデータベースが必要な場合は、microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx でサンプルを提供しているのでご利用ください。
外部結合を使用する場合は、少なくともスクリプトの最初の行に On Error Resume Next を記述する必要があります。これは重要です。その理由は、ここで左外部結合を実行すると仮定すると、ハード ディスクが搭載されていないコンピュータを取得する可能性があるからです。ハード ディスクが搭載されていないコンピュータも返す必要があったので、少なくとも、ドライブ文字を表示する次のコード行に遭遇するまでの間なら、これで問題ありません。
Wscript.Echo objRecordset.Fields.Item("Drive")
ハード ディスクが搭載されていないコンピュータには Drive フィールドがないので、スクリプトは次のエラーで動作を停止してしまいます。
C:\Scripts\database.vbs(22, 9) Microsoft VBScript runtime error: Type mismatch
ただし、On Error Resume Next を実装すると、スクリプトはコンピュータにディスク ドライブがないという事実を無視することができ、そのまま処理を続けることができます。また、次のようなコードを使用すると、Drive フィールドの値を確認してから適切なアクションを実行することができます。
If IsNull(objRecordset.Fields.Item("Drive")) _Then
    Wscript.Echo "No disk drives installed."
Else
    Wscript.Echo _
      objRecordset.Fields.Item("Drive")
End If
このコードを使用すると、実際のドライブ文字ではなく、Null 値が返されるかどうかを確認できます。Null 値が返された場合には、"No disk drives installed." というメッセージを表示します。Null 値が返されない場合は、単純に Drive フィールドの値を表示します。図 4 に示すような最終結果が得られます。
Figure 4 適切な結果の表示 (Close Figure 4)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-02
C:

atl-ws-02
D:

alt-ws-03
No disk drives installed.
詳しくは説明しませんが、他にもいくつかのクエリを見てみましょう。たとえば、次にコンピュータの一覧とそのコンピュータに搭載されたディスク ドライブの一覧を返す内部結合のクエリを示します。このクエリでは、ディスク ドライブが 50 GB より大きいという条件を指定しています (ドライブ サイズは GB 単位で格納されていると仮定しています)。
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "WHERE DriveSize > 50 " & _
 "ORDER BY Computers.ComputerName, " & _
 "DiskDrives.Drive", objConnection, _
 adOpenStatic, adLockOptimistic
おわかりのように、ここでは一般的な WHERE 句を元のクエリに追加しただけです。
WHERE DriveSize > 50
では、コンピュータのドライブ E に関する情報だけが必要な場合はどうすればよいでしょうか。この場合も、次のように適切な WHERE 句を追加するだけでよいのです。
WHERE Drive = 'E:'
次は多少複雑なクエリです。このクエリでは、ディスク ドライブが搭載されていないコンピュータのコレクションを返します。
objRecordSet.Open _
 "SELECT Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "FROM Computers LEFT JOIN DiskDrives " & _
 "ON Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "GROUP BY Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "HAVING (DiskDrives.Drive) Is Null " & _
 "ORDER BY Computers.ComputerName", _
 objConnection, adOpenStatic, adLockOptimistic
既に言及したように、このクエリは少し複雑ですが、スペースが不足してきたので動作については説明しません。しかし、このクエリは正常に実行されます。それが最も重要なことなのです。
そして、おそらくその次に最も重要なのは、何度も指摘したように、本当に重要なのはリレーションシップ (関係) だということです。しかし、常に良好な関係を保てるとは限りません。「アニー・ホール」の最後でウディ・アレンがこう言っています。「関係というのはサメと同じで常に前進してないと死ぬ。僕たちの関係はサメの死骸だ。」と。ウディが内部結合と外部結合について知っていれば、このような結末にはならなかったと思います。このコラムで紹介したクエリ技術を使えば、常に適切な関係 (リレーションシップ) を築くことができます。

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


 Exchange に関する Queue &amp; A: セットアップ、メッセージ ジャーナリング、ストレージのオプションなど
Exchange に関する Queue & A
セットアップ、メッセージ ジャーナリング、ストレージのオプションなど
KC Lemson and Nino Bilic

質問 - Exchange Server 2007 セットアップを実行していますが、前提条件の確認は省略できるでしょうか。前提条件の確認で報告される問題すべてを解決したくありません。とにかくセットアップを実行して完了させたいのです。

回答 - 手短にお答えすると、残念ながらできません。前提条件の確認で報告された問題がセットアップの続行を妨げるようなものであった場合、これらの問題を解決しないと、長い目で見て Exchange でのエクスペリエンスに悪い影響があります。
ExBPA.PreReqs.xml ファイル (Exchange 2007 セットアップの前提条件の一覧のあるファイル) を編集し、セットアップを続行できない原因となっている確認を除外しようとした管理者もいます。しかし、この方法はうまくいきません。この XML ファイルはデジタル署名されていて、内容が変更されると、署名が無効になるためです。
これはすべて、適切に機能しないインストールが作成されないようにするための措置です。マイクロソフトでは、さまざまな環境で Exchange 2007 をテストし、ある構成と設定は他のものよりも優れていることや、構成や設定によっては深刻な問題が発生する可能性があることを確認しています。前提条件は、経験とテストを基に、セットアップが成功する確率を最大限に高めるために設定されています。
純粋に Exchange 2007 の前提条件の確認に問題があることが原因で、使用中の環境でのセットアップが失敗する場合は、Exchange サポートに連絡してください。

質問 - セットアップ ログの場所を教えてください。C: ドライブのルートにはありませんでした。

回答 - すべてのセットアップ ログは %SYSTEMDRIVE%\ExchangeSetupLogs ディレクトリに格納されるようになりました。つまり、ほとんどの場合、c:\ExchangeSetupLogs に格納されます。このディレクトリには複数のファイルがありますが、次の 2 つが該当するファイルです。
ExchangeSetup.log これは、セットアップの実行時に使用されたタスクとパラメータに関する情報が記録されているログです。サーバーの役割を構成する際、そのサーバーを構成するために実行されたタスクに関する情報も、このログに記録されます。また、サーバーのセットアップに関する情報も、ほとんどこのログに記録されています。さらに、Service Pack のセットアップに関する情報も、このファイルに記録されます。
ExchangeSetup.msilog このファイルには、セットアップのアンパック フェーズに関する情報が含まれています。Microsoft® インストーラが一時的な場所からファイルを目的の場所にコピーするとき、このファイルに情報を記録します。したがって、問題がセットアップ中のファイルのコピーやファイルへのアクセスに関係していると思われる場合は、このログを参照してください。

質問 - 前提条件の確認は Exchange Server ベスト プラクティス アナライザ (BPA) によって実行されていると理解しています。この前提条件のレポートはどこにあるのでしょうか。
回答 - 前提条件の確認中に BPA が作成したレポートを確認する必要がある場合は、次のフォルダを参照してください。
%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs
ファイル名には、次のような標準形式が使用されます。
ExBPA.<dateandtime>.data.xml
特定の前提条件の確認によって確認された内容を知るには、表示されたエラー メッセージが含まれている XML ファイルを検索してください。そのメッセージのすぐ上に、テストされたルール定義が記載されています。
質問 - セットアップ ログを参照する方法を教えてください。どのような方法がありますか。
回答 - セットアップ ログを参照するには、基本的に 2 とおりの方法があります。Exchange 管理シェルから Get-SetupLog を実行するか、メモ帳などの任意のテキスト エディタでセットアップ ログ ファイルを開きます。
Get-SetupLog を使用する場合は、次のようなコマンドを使用すると、警告やエラーの情報を取得できます。
Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error
外観を整えてデータを表示したい場合は、Exchange 2007 PowerShell Scriptacular デモ パックで提供されている Out-HTML.ps1 および Out-IE.ps1 スクリプトを入手してください (詳細については、Exchange Server チームのブログ (msexchangeteam.com/archive/2006/12/27/431998.aspx) を参照してください)。
これらのスクリプトを入手したら、これらを Exchange スクリプト フォルダ (既定では c:\program files\microsoft\exchange server\scripts) に格納して、次のコマンドを実行します。
Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE
これにより、参照しやすいブラウザ ウィンドウが開かれ、セットアップ中に発生した可能性のあるエラーが HTML 形式で表示されます (図 1 を参照)。
図 1 Out-HTML と Out-IE によって参照しやすい形式で表示されたセットアップ ログ
図 1 Out-HTML と Out-IE によって参照しやすい形式で表示されたセットアップ ログ
メモ帳を使用して exchangesetup.log を参照する場合は、次のヒントを参考にしてください。
  • セットアップの開始時刻を確認するには、"[0] Starting Microsoft Exchange 2007 Setup" ([0] Microsoft Exchange 2007 セットアップを開始しています) という文字列を見つけます。
  • セットアップの終了時刻を確認するには、"[0] End of Setup" ([0] セットアップの終了) という文字列を見つけます。
  • 主なセットアップ タスクは、"[0] **************" という文字列によって区切られています。
  • セットアップを実行したアカウントを確認するには、"[0] Logged on user" ([0] ログオン ユーザー) という文字列を見つけます。
  • セットアップ中に使用されたドメイン コントローラを確認するには、"[0] Setup will use the domain controller" ([0] ドメイン コントローラを使用します) という文字列を見つけます。
一般的に、メモ帳を使用してセットアップ ログを参照する場合は、ファイルの最後から時間をさかのぼる形で読み始めて、問題が何であるかを確認します。通常、エラーはセットアップ ログに記録された情報の最後の方に含まれています。

質問 - 現在所有している PBX で Exchange 2007 ユニファイド メッセージングを使用できるでしょうか。

回答 - おそらく可能です。サポートされている VoIP ゲートウェイと PBX の一覧については、microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx を参照してください。サポートされる製品の一覧に変更があった場合は、このページに変更情報が追加されます。
質問 - Small Business Server 2003 と Exchange を運用している顧客がいます。この会社では、経営方針に従ってすべてのメールを監視する必要があります。この監視を行うために、すべての受信メールと送信メールのコピーを管理者のアカウントに送信したいと考えています。これを行うにはどうすればよいでしょうか。
回答 - この状況に必要な機能はメッセージ ジャーナリングです。この機能を使用すると、特定のメールボックス データベースとの間で送受信されたすべてのメッセージのコピーを、別個のジャーナリング メールボックスに保持することができます。また、どの程度詳細なジャーナル コピーを作成するか (たとえば、BCC 受信者情報もキャプチャするか) を構成できるさまざまなオプションが用意されています。さらに、go.microsoft.com/fwlink/?LinkId=93725 からその他のツールをダウンロードして、機能を拡張することもできます。Exchange 2003 のジャーナリングは、データベース レベルで有効になるため、そのデータベース内のすべてのユーザーがジャーナリングの対象になります。ジャーナリングされたメッセージを保持するメールボックスを作成したら、Exchange システム マネージャでメールボックス ストアのプロパティを表示し、このストアのメールボックスとの間で送受信されたメッセージをアーカイブすることを指定するチェック ボックスをオンにします。また、経営方針によっては、メールボックス マネージャを有効にして、自動的に古いジャーナル コピーをジャーナル メールボックスから削除することもできます。
Exchange 2003 には、アーカイブ シンクと呼ばれる、ジャーナリングに似た別の機能があります。メッセージのコピーを Exchange 内の別のメールボックスに保存するジャーナリングと異なり、アーカイブ シンクはメッセージをサーバーのハード ドライブ上の指定されたフォルダに保存します。2 つの似たような機能が用意されているのはなぜでしょうか。ジャーナリングは基本的に規制遵守のシナリオで使用することを目的とした機能ですが、アーカイブ シンクは、インターネットを経由して送受信されたメッセージをすべてキャプチャする場合などに役立ちます。
Exchange 2007 ではこのようなシナリオが大幅に簡素化され、ユーザー単位または配布リスト (DL) 単位で容易にジャーナルを作成できます。メールのジャーナルが作成されていることをユーザーに知られたくない場合は、DL をグローバル アドレス一覧に表示されないようにするか (これは DL の非表示のメンバシップとは異なります)、ユーザーにカスタム属性を設定し、クエリ ベース配布グループ (動的配布リストや DDL とも呼ばれます) を作成して、このカスタム属性が設定されているすべてのユーザーを制限するようにします。組織全体のすべてのメールのジャーナルを同じ場所に作成する場合は、ジャーナリング ルールを作成するときに受信者フィールドを空白にします。また、Exchange 2007 でデータベース以外の単位でジャーナリングを使用する場合、対象のユーザー用のエンタープライズ クライアント アクセス ライセンス (CAL) が必要です。詳細については、microsoft.com/exchange/howtobuy/licensingFAQ.mspx を参照してください。この CAL やその他の機能が必要でない場合は、Exchange 2003 のデータベース単位のジャーナリング機能を使用できます。また、2006 年 12 月の TechNet Magazine に掲載された David Strome の記事「Exchange 2007 の強化されたジャーナリング」(technetmagazine.com/issues/2006/12/journaling) を参照してください。

質問 - すべてのユーザーが Microsoft Office 2003 を実行しています。2008 年にハードウェアを更新するまでは、2007 Office system に移行する計画はありません。しかし、このために一部の機能が使用できないという情報を目にしました。ユニファイド メッセージングは使用できるでしょうか。

回答 - もちろんです。Office 2003 では、ユニファイド メッセージング対応ユーザーは、ボイスメール メッセージと FAX を各自のメールボックスで受信できるほか、電話を使用して各自のメールボックスにアクセスすることもできます。Outlook 2007 にアップグレードしなければ利用できないユニファイド メッセージング機能は、Outlook の [オプション] タブからボイスメールの設定を構成する機能と、Outlook のボイスメール メッセージに表示され、別途メディア プレーヤーを起動しなくてもインラインでメッセージを再生できる特殊なカスタム フォームです。また、音声メモを作成し、これをボイスメール メッセージに保存する機能も利用できません。ただし Outlook 2007 がなくても、ユニファイド メッセージング対応ユーザーは、OWA 2007 を使用して (OWA のオプション ページから) ユニファイド メッセージングの設定にアクセスしたり、OWA のボイスメール用のカスタム フォームを使用したりできます。

質問 - 弊社では既にストレージ エリア ネットワーク (SAN) を展開していて、このネットワークに Exchange 2007 を接続しようと考えています。ただし、直接接続型ストレージ (DAS) についての話をいろいろと耳にして、DAS を選択すべきかどうか迷っています。どう思われますか。

回答 - このご質問に対しては正解というものはありません。御社の方針とシナリオによります (特に既に SAN を展開されていますから)。新規に SAN の購入、SAN の追加、またはアップグレードを検討しているのであれば、DAS を強くお勧めします。次の話を参考にしてください。2007 年 6 月現在、Microsoft IT は 17 台の Exchange 2007 メールボックス サーバーを展開し、40,000 個のメールボックス (クォータのサイズは 500 MB ～ 10 GB) をホストしています。いずれも、DAS でクラスタ連続レプリケーション (CCR) を使用しています。9 月までに、152,500 個のメールボックスをホストする 35 台の Exchange 2007 メールボックス サーバーを、すべて DAS で展開する計画を立てています。ですから、DAS がエンタープライズ規模の展開に適していて、機能するかどうかを質問された場合、答えは間違いなく「はい」です。DAS は、Microsoft IT が全体のストレージ コストを削減しながらユーザー クォータを増やすうえで、重要な役目を果たしてきています。このトポロジと展開の詳細、およびこれにより削減できたコストについては、microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx を参照してください。
すべてのサーバーを同じ SAN に接続すると、かなりのストレージを節約できるように思えますが、まったくリスクがないわけではありません。たとえば、よくある問題の 1 つは、SAN に接続されているソフトウェアの用途が異なることに関連しています。たとえば、毎日午後 5 時にバッチ処理を実行する人事アプリケーションが SAN 上にある場合、この処理中に I/O が増加することで、Exchange ユーザーが深刻な影響を受ける可能性があります。I/O が確定的でないことは、共有 SAN の展開においてよくある問題の 1 つです。
他に DAS の利点として気が付いたことは、専任のストレージ管理者や専用の機器を必要としないため、管理が比較的簡単なことです。段階的に拡張できるため、後からの購入や拡張も容易です。また、通常は、予備費を残しておきたい場合に、予算を使い切ってしまわずに済むぐらい安価です。

質問 - 初めて Exchange 2007 サーバーをインストールしました。そこで、Outlook 2003 を使用してこのサーバーに接続しようとすると、使用している Outlook のバージョンが管理者によってブロックされているというエラー メッセージが表示されます。("Exchange Server 管理者は、お使いのバージョンの Outlook の使用をブロックしました。詳細については管理者に問い合わせてください。") しかし、私自身が管理者であり、ブロックした覚えなどありません。どうなっているのでしょうか。

回答 - これは予期されていない動作です。Exchange 2007 のインストール中、セットアップ ウィザードにより、Outlook 2003 以前のクライアントか Entourage クライアントが組織内で実行されているかどうかが確認されます ( 図 2 を参照)。この質問に対して [いいえ] を選択した場合、上記の問題が発生する可能性があります。
図 2 Exchange 2007 セットアップの古いバージョンのクライアントに関する質問
図 2 Exchange 2007 セットアップの古いバージョンのクライアントに関する質問
セットアップの完了後にこの問題を解決するには、Exchange 管理コンソールまたは Exchange 管理シェルを使用してパブリック フォルダ ストアを作成し、Information Store サービスを再開します。この場合、Information Store サービスの再開は必須です。このサービスが再開されないと、古いバージョンのクライアント (Outlook 2003 以前) はサーバーに接続できません。
また、Exchange 2007 無人セットアップを実行している場合は、/EnableLegacyOutlook スイッチを使用して、古いバージョンのクライアントに関する質問への回答を指定できます。

質問 - Exchange 2007 では、サーバーに古いバージョンの Outlook を使用して接続するかどうかが問題になるのはなぜですか。また、パブリック フォルダ ストアを作成し、Information Store サービスを再開すると、この問題が解決するのはなぜですか。

回答 - これらのご質問に対する答えは、パブリック フォルダ ストアが存在するかどうかに関係しています。まず、思い出していただくと、以前のバージョンの Exchange のパブリック フォルダ ストアは、ユーザーの空き時間情報データを格納するために使用されていました。古いバージョンの Outlook ユーザーが MAPI または RPC over HTTP を使用して Exchange サーバーに接続し、予定表に情報を公開すると、このユーザーの空き時間状態に関する情報もサーバーに公開され、Schedule+ フォルダと呼ばれる特殊なパブリック フォルダに保存されます。これが、古いバージョンの Outlook クライアントがユーザーの空き時間情報データをサーバーに公開する唯一の方法であると同時に、古いバージョンの Outlook が他のユーザーの空き時間情報を読み取る唯一の方法でもあります。
Exchange 2007 はこれを踏まえて設計されており、パブリック フォルダ ストアが存在しない場合、以前のバージョンのクライアントをブロックします。Exchange 2007 が古いバージョンのクライアントの接続を許可していたら、Outlook はパブリック フォルダ ストアに接続して空き時間情報データを公開できないため、クライアントで頻繁にエラーが発生していたと思います。また、別のユーザーとの会議のスケジュールを設定する場合など、空き時間情報を参照できないため、クライアントの機能が制限されていたでしょう。また、この設計が、パブリック フォルダ ストアを作成することで問題が解決する理由でもあります。このストアを作成すると、Exchange 2007 サーバーによって、古いバージョンのクライアントが空き時間情報の公開機能を使用できることが認識され、メールボックスへのログオンが許可されます。
以上のことから言えることがもう 1 つあります。それは、Outlook 2007 クライアントが、空き時間情報の公開にパブリック フォルダ ストアを必要としないということです。これは本当ですが、注意点が 1 つあります。
ここではあまり詳細な説明はしませんが、Exchange 2007 サーバーにパブリック フォルダ ストアが存在する場合は、Outlook 2007 クライアントもユーザーの空き時間情報データをこのストアに公開するとだけお伝えしておきます。この理由は、(一部は古いバージョンの Outlook クライアントであると思われる) 他のクライアントが、Outlook 2007 ユーザーの空き時間情報を参照できるようにするためです。この情報がパブリック フォルダ ストアに存在しない場合、なんらかの動作によってこの情報がパブリック フォルダ ストアにコピーされるわけではないため、古いバージョンのクライアントが参照できる Outlook 2007 ユーザーの情報はありません。ただし、パブリック フォルダ ストアが存在しない場合、Outlook 2007 クライアントは空き時間情報データを公開しません。パブリック ストアが存在せず、すべてのクライアントのバージョンが Outlook 2007 以上である場合は、空き時間情報を参照するための別のメカニズムが使用されます。このメカニズムでは、予定表データが直接ユーザーのメールボックスから読み取られ、この情報のコピーが別の場所に作成されることはありません。この詳細については、Exchange Server のヘルプ ファイルで可用性サービスについて参照するか、Exchange のオンライン ドキュメント (go.microsoft.com/fwlink/?LinkId=69434) を参照してください。

質問 - レジストリ キーを使用した MAPI クライアントのブロックに関するサポート技術情報 288894 を読みました (support.microsoft.com/kb/288894 を参照)。サーバーのレジストリを確認しましたが、このキーは設定されていませんでした。Exchange 2007 Information Store はどのようにして、この古いバージョンのクライアントをブロックするのですか。

回答 - 非常によい質問ですね。実際、Exchange 2007 Information Store は、古いバージョンのクライアントを無効にするために、このサポート技術情報で述べられている "Disable MAPI Clients" レジストリ値を使用しません。この理由は、パブリック フォルダ ストアが存在しない可能性があるためです。つまり、パブリック フォルダ ストアが存在しない場合、このレジストリ値を変更しないと、これらのクライアントのブロックが解除される可能性があります。
Outlook 2007 よりも古いクライアントをブロックするこの動作は、Exchange 2007 Information Store にハードコーディングされています。サービスの開始時に、Exchange 2007 Information Store はパブリック フォルダ ストアの有無を確認し、Outlook 2007 のみの接続を許可するか、古いバージョンもメールボックスに接続できるようにするかを決定します。この確認は、サービスの開始時にのみ実行されます。パブリック フォルダ ストアを作成したら、変更を反映するために Information Store サービスを再開する必要があるのは、このためです。

KC Lemson は、Exchange Server のユーザー エクスペリエンス担当マネージャです。現在、無認可の有名大学で博士号の取得を目指しています。
Nino Bilic は、Exchange Server のサポータビリティ プログラム マネージャです。現在、Forza Motorsports 2 のレースカーのプロドライバーになることを考えています。


 セキュリティ ウォッチ: ユーザー アカウント制御の長期的な影響
セキュリティ ウォッチ
ユーザー アカウント制御の長期的な影響
Dr. Jesper M. Johansson

管理者としてコンピュータを実行することに問題があるのは明らかです。ユーザーを攻撃するマルウェア、またはユーザーが実行するアプリケーションは、侵害したコンピュータの 90% 以上を完全に制御します。Windows Vista のユーザー アカウント制御 (UAC) 機能は、いたるところで見られるセキュリティ上の問題に対するマイクロソフトのソリューションです。
この問題とは、現在、Windows プラットフォームで 90% を超えるユーザーが管理者特権でコンピュータを実行しているという事実です。Windows® XP では、私がそうしているように、標準ユーザーとしての実行ができますが、これには非常な苦痛を伴うことがあります。たとえば、Windows XP の使用中に頻繁に出張や旅行をすると、標準ユーザーではシステムのタイム ゾーンを変更できないことがわかります。
UAC は、この状況を変えると期待されている機能です。実は、これが 1 つ目の誤解です。UAC は、単独の機能ではなく機能のコレクションであり、そのほとんどはあまりわかりやすくありません。UAC のすべての実装の詳細について、ここで深く分析するつもりはないので、詳細が知りたい場合は、2007 年 6 月の TechNet Magazine の Mark Russinovich の記事をお読みになることを強くお勧めします。これはオンラインで入手できます (technetmagazine.com/issues/2007/06/UAC)。
このコラムでは、UAC が何であって何でないか、そして Windows Vista® を実行しているシステムの管理方法にどんな影響を与えるかについて、偏見を挟まずに説明したいと思います。

UAC についての誤解
UAC の最も目につく機能は、図 1 に示す昇格ダイアログです。実際、UAC とは何かについて Windows Vista ユーザーにアンケートを実施すれば、大半の人がうっとうしい昇格ダイアログについて言及するでしょう。
図 1 管理者承認モードの管理者のための UAC の同意ダイアログ
図 1 管理者承認モードの管理者のための UAC の同意ダイアログ
UAC の可視性やあらゆる意見にもかかわらず、私は UAC についての議論のほとんどは、UAC が本来何であるかにはあまり関係ないと思います。実際に、世間で混乱があるのは間違いないようです。評論家たちは「Vista の最も迷惑な機能」といったタイトルで、ブログ、ニュースグループの記事、コラムなどを書き、どれほど多くの人がこの機能をオフにするか、そしてそれがなぜそれほど迷惑なのかを自信たっぷりに指摘しています。
UAC の背景にある論理的根拠を理解しようとする人がほとんどいないのですから、まずは UAC が何であるかを見ていくことからこのコラムを始めましょう。

UAC とは何か
UAC は、より多くの人が標準ユーザーとして実行できるようにする試みです。ある意味で、これはその取り組みの「バージョン 2.0」と言えるでしょう。「バージョン 1.0」は Windows NT® 3.1 で初めて導入され、ユーザーが非管理者として実行することができるようになりました。これは、16 ビットの Windows 3.1 とその後継である Windows 3.11、Windows 95、Windows 98、および Windows Me とは異なる根本的な新機能でした。これらのバージョンの Windows には、権限の低いユーザーという概念はありませんでした。非管理者が実際に"何が"できたかどうかは多くの要因によりさまざまでしたが、Windows XP および Windows Server® 2003 まで、最小のユーザー特権での実行は、たいていの場合、「苦痛」と「役立たず」の間のどこかに該当しました。Windows Vista は、対話型のユーザー特権に関して言えば、正しいことを簡単に実現することを目指した初めてのテクノロジをもたらしました。
UAC の目標は、管理者として実行するアプリケーションを、管理者として実行しないことによってある程度保護することであるという主張は正しいのですが、それは決して UAC の第一の目的ではありませんでした。第一の目的は、より多くのユーザーが標準ユーザーとしてコンピュータを実行する方向に、業界を向かわせることでした。これにより開発者は、標準ユーザーとして操作できるプログラムをたくさん書いてユーザーが昇格する必要がある状況を減らすように求められます。開発者が UAC 準拠のアプリケーションを多数作成すれば、ユーザーに表示される昇格メッセージの数が減り、ユーザー エクスペリエンスが改善します。その過程で、理想的には、ほとんどの人が管理者として実行しなくなり、さらにうまくいけば、彼らは表示される昇格プロンプトにまじめに向き合うようになります。プロンプトが少ないほど、それを許可する前に慎重に考えるであろうユーザーが増えます。
理論的には、そのようになります。その延長で、確かに、マルウェアは減るかもしれません。しかしそれはユーザーが UAC を常に有効にしているかどうかによります。そしてユーザーがそうするかどうかは、開発者が UAC と連携するソフトウェアを書くかどうかに、またユーザーがプロンプトを高速クリックの練習台として見るのをやめ、昇格要求が正当かどうかを本当に検討することにかかっています。
UAC は、ほとんど常に非管理者として実行できるユーザーの数を増やすという第一の目標を達成するために、それを構成する、次のような多くの小さい目標を達成するように設計されています。
  1. 管理者アカウントへの昇格が必要になるシナリオの数を減らす。
  2. 従来のようにその場しのぎで runas.exe を使用したり、アカウントをログアウトして別のアカウントでログインし直したりするよりも、昇格する方がずっと簡単になるようにする (可能な場合は自動化)。つまり、ソフトウェア ベンダがアプリケーションを修正するまでのギャップを埋める。
  3. 管理者として実行するアプリケーションを分離して、それ以外のアプリケーションから保護する。
  4. 無防備な特定のアプリケーションを、可能な場合はいつでもより低い特権で実行できるようにする。
これらの目標のうち 2 つは、非管理者として実行するユーザー エクスペリエンスをできるだけ快適にすることを目指しています。2 つは、特に無防備なアプリケーションの保護に関係しています。
おもしろいことに、一般に UAC として考えられている機能に関連するのはこのうち 2 つだけ、そして実際の昇格タスクに関係するのは 1 つだけです。それでも、人々の不満の対象となるのは、アプリケーションから追加の特権を求められた場合の昇格です。これが UAC を構成するテクノロジ コレクションのなかで実際に目に見える唯一のものだからです。第一の最重要な目標は、昇格にはまったく関係ありません。その目標は、単により多くの人がほとんど常に非管理者として実行できるようにすることでした。実際、その意図は昇格イベントの数を減らすことにあると言うこともできます。
昇格タスク自体に関連する目標は、2 番目と 3 番目です。2 番目の目標は、Windows XP よりも昇格を簡単にすることについてのものです。3 番目の目標は、昇格して実行するアプリケーションをある程度保護することについてのものです。残りの目標は、まったく別の問題に関係しています。ただし、これらの目標はいずれもオペレーティング システムに対する変更を必要としていました。この点に興味がある方は、前述の Mark Russinovich の記事にそのような変更についての詳しい説明があるので参照してください。
前述のように、この世は UAC を無効にすべしというアドバイスで満ちあふれています。多数のユーザーが、自分で試しもせずにそれに従っていることでしょう。そしてもっと多くの人が、UAC があらかじめ無効にされた Windows Vista ビルドをインストールしたコンピュータを大型店で買っていることでしょう。小売業者が自社の既定の展開イメージでオペレーティング システムの重要なセキュリティ機能を無効にしているのは恥ずべきことだと思います。
残念なことに、UAC をオフにするというアドバイスのほとんどは、使い始めてすぐの経験に基づいています。コンピュータをセットアップする間は、ソフトウェアをインストールして必要な変更を行うので、かなり多くのプロンプトが表示されます。コンピュータの構成中は、ご存知のように、コンピュータが安定した状態になった後とはまったく違う管理作業がいろいろあります。最初の数週間は、その後の数週間とは大きく異なります。UAC を比較的安定した状態のコンピュータで使ってみれば、それが実は特に厄介でもなんでもないことがわかると思います。

UAC とは何ではないのか
UAC は、Windows 史上最も迷惑な機能になるように意図して設計されたわけではありません。むしろ、このテクノロジ セットが設計されたのは、ユーザーがここ数年間遭遇してきたように、潜在的に悪意のあるコードにシステムを頻繁にさらさなくてもすむ道に、私たちを向かわせるためでした。
現在の形の UAC が、真に有能な攻撃者や、そうした人の手助けを受ける人をひるませることはありません。悪人たちは、UAC を打ち砕く方法が他に考えつかない場合、ほぼ確実にユーザーに頼んでユーザー自身にやってもらうという手段に訴えるでしょう。ダンスするブタの動画とセキュリティ情報のどちらかを選ばせた場合、いつでもブタを選ぶ人の方が多いことを私たちは経験上知っています。ユーザーは、ダイアログを消す方法は知っているので、それ以外の方法を私たちが何とかして教えこむまでは、ダイアログを消し続けるでしょう。これは、警告ダイアログが多すぎること、その中のメッセージが役に立たないこと、ユーザーが購入するあらゆるデバイスのマニュアルの多くに、「セキュリティの警告ダイアログが表示されたら [はい] をクリックして閉じてください」という指示が含まれているといった事実などの、多くの要因による結果です。
UAC が絶対確実なセキュリティを提供することはありません。実際、UAC は、なつかしのローカル特権昇格攻撃を思い出させます。これは、著しく軽視されている類の攻撃です。なぜなら、Windows では、ほとんどの人が管理者だったので、他の管理者への昇格はかなり無意味だったからです。とはいっても、UAC は、そのような攻撃の性質を間違いなく変え、ゲームのルールを 20 年以上 UNIX で主流になっているのと非常に似たものに変化させています。
UAC は、悪意のある人がユーザーの個人データを盗むのを止めるものではありません。ユーザーは、自分の個人データに特権に関係なくアクセスできます。同様に、アプリケーションは、悪意のあるアプリケーションも含めて、そのデータにアクセスできます。UAC はそれを変えませんし、変えることもできません。私たちがエンド ユーザーに事あるごとに植え付けなければならない態度、つまり、用心深く、疑り深く、被害妄想気味という態度で臨む必要をなくしてくれることもありません。
UAC は、昇格特権で実行しているアプリケーションを、同じログイン セッションで通常の特権で実行しているアプリケーションによるすべての攻撃から保護するようには設計されませんでした。UAC は、不十分なプロセス分離を提供してはいますが、アプリケーションをお互いから隔離することは UAC の設計目標ではありませんでした。

うわさ
UAC についてのうわさと、その機能に関する誤解の一因となっていたのはマイクロソフト自体でした。たとえば、『Windows Vista Security Guide』の「Defend Against Malware」の章では、UAC はそのための主要なテクノロジであるとされています (microsoft.com/technet/windowsvista/security/guide.mspx)。ほとんどの部分で、UAC をオンにして実行することが推奨されています。また、UAC を使用してマルウェアを打倒する場合の考慮事項が多数挙げられています。しかし、一点、明らかに抜けていることがあります。それは、UAC がマルウェアを阻止することはなく、その意図もないということです。
今日の Windows セキュリティの世界に身を置く非常に聡明な思想家の何人か、たとえば Joanna Rutkowska は、UAC の目的を理解していました。彼女の 2007 年 2 月 4 日のブログの投稿によると、UAC は「Vista に導入された新しいセキュリティ メカニズムであり、その第一の目標は、ユーザーに、管理者としてではなく制限のあるアカウントを使って作業させること」です (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html)。彼女はおおむね正しいのですが、私だったら「作業させる ("force")」ではなく「作業できるようにする ("enable")」という表現を使います。
いずれにしても、これは Windows に対する一般的な攻撃の性質の大きな変化を意味します。このコラムで既に述べたように、ローカル特権昇格の脆弱性 (ユーザーがローカルの標準ユーザーからローカルの管理者に昇格できる) が、これまで Windows プラットフォームでは特に注目されることがありませんでした。
Windows Vista では、ユーザーが標準ユーザーとして実行するという考えになったため、突然ローカル特権昇格の問題が脚光を浴びることになりました。残念ながら、ここでも UAC の制限に直面します。前に説明したように、効果的な分離手段がない、つまり、同じデスクトップの複数のプロセスを分離するセキュリティ境界がないのです。OS には、明らかに不要な通信経路をブロックする一定の保護手段がありますが、それらすべての経路をブロックすることは不可能であり望ましくもありません。したがって、マイクロソフトは、その存在しないセキュリティ境界への侵害をセキュリティ侵害と見なしていません。Mark Russinovich は、blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx のブログの投稿で、同様な指摘をしています。
Mark は完全に的を射ています。マイクロソフトは、同じデスクトップ上の低い特権のプロセスと昇格されたプロセスとの間にセキュリティ境界がないという事実を十分認識しています。同一デスクトップ上のプロセス間を分離する意図がまったくなかったので、そのような分離がないことがわかったときに、それをセキュリティの脆弱性とは言えません。そのことで明らかにマルウェアと戦う第一級のメカニズムとしての UAC の価値は損なわれます。しかし、マイクロソフトのサイトを含むさまざまなところで読者が目にする記述とは異なるかもしれませんが、本来 UAC はそのような目的で設計されたものではないのです。
セキュリティ境界がないという事実によって、より多くの人がなるべくいつでも標準ユーザーとして実行できるようにするという第一の目標に関して UAC の価値が損なわれるでしょうか。答えはノーです。悪意のある低特権のアプリケーションと昇格アプリケーションの間に頑丈なセキュリティ境界があろうとなかろうと、より多くのユーザーが効果的に UAC を使用して、その Windows Vista コンピュータを標準ユーザーとして実行できるという事実は変わりません。実際に、業界の人が人々に信じさせようとしていることに反して、私は、Windows Vista で標準ユーザーとしてこの記事を (ついでに言えば Windows Vista のセキュリティに関する私の本一冊も) 書きましたが、私が書いた内容について同意を求める UAC のプロンプトはただの一度も表示されませんでした!
UAC がすべてのセキュリティ問題を軽減するわけではなく、または私を含む多くの人が心底欲しがっているような特性、つまりマルウェアに対する第一級の保護を提供しないことは事実ですが、だからといって UAC がセキュリティ テクノロジではないということはありません。個々のユーザー アカウントでユーザーを区別する機能が、それ自体でシステムへのマルウェアの侵入を阻止することはありません。しかし、その事実を拡大解釈して、ユーザー アカウントはこのためセキュリティ テクノロジではないと言う人はいないでしょう。UAC は私たちが望むようにすべての問題を解決することはありませんが、それは UAC で解決できる問題に価値がないという意味にはなりません。
UAC は、悪意のあるコードがコンピュータに侵入するのを防いだり、(ずる賢いプログラミングや空飛ぶブタ (不可能と思われることが実現することのシンボル) などのいかなる手段であれ) 何らかの方法で侵入したコードの実行を阻止したりすることはしません。これらについては、大幅に向上した Windows ファイアウォール、Windows Defender、その他のマルウェア対策プログラムなどのテクノロジに任せています。それらのセキュリティ テクノロジは、いずれもそれぞれのミッションに 100% 成功する可能性はありません。それでも、それらはすべて有益なセキュリティ テクノロジであり、すべてそれなりに意味があります。しかし、私が何度も言っているように、たとえすべての攻撃経路を遮断したとしても、要はユーザーしだいなのです。キーボードに向かっている人が悪意のあるコードの実行を許可することを選択した場合、その被害を抑えるのに役立つような技術的な緩和策はどこにもありません。

ベスト プラクティス
UAC をどのように使用するべきでしょうか。管理者承認モードで管理者として実行するべきでしょうか。何度か述べたように、UAC は、低い特権のアプリケーションから同じデスクトップ上のより高い特権のアプリケーションへのコードの侵入を防ぐことはできません。つまり、管理者承認モードで実行しても、標準ユーザーとして実行しセッション内で昇格 (肩越し (over-the-shoulder) 昇格) しても、効果的な分離は実現されません。しかし、どちらの対応策も、Windows XP で管理者として実行したり Windows Vista で UAC をオフにして作業したりするよりも、ずっとましです。ただし、いずれは、おそらく対話型デスクトップで昇格アプリケーションを悪用するようなマルウェアが書かれることでしょう
そのときに、どのような実行方法をとるかは、各人のリスク管理の方針しだいで決まります。標準ユーザーとして実行し、肩越し昇格を使用してアプリケーションを昇格する場合は、昇格アプリケーションに、通常とは別のユーザー環境が用意されます。これは、悪意のある非昇格アプリケーションが昇格アプリケーションのユーザー環境を汚染するという汚染攻撃のリスクを低減します。しかし、それで非昇格アプリケーションが昇格アプリケーションを制御できなくなるわけではありません。何週間も前に実行された悪意のあるアプリケーションが、今日実行する昇格アプリケーションを汚染することは簡単ではありませんが、実行中の悪意のあるアプリケーションであれば、昇格アプリケーションを制御できる可能性があります。管理者承認モードの使用と肩越し昇格のリスクのトレードオフを、使いやすさの点から考慮する必要があります。
これによって 図 2 にまとめた UAC のベスト プラクティスが導かれます。私の意見で間違いなく最適なオプションは、同時に最も複雑でもあります。ただし、本当に被害妄想気味の人や無防備な人にとって最適なオプションは、標準ユーザーとして実行し、決して昇格しないことです。ある意味では、Windows XP で管理者として実行しているときに、いったん悪意のあるコードを実行してしまうと、それでゲーム オーバーになっていました。Windows Vista では、悪意のあるコードを実行し、その後、同一セッション内で昇格した場合は、ゲーム オーバーになる可能性があります。どんなアプローチであれ、自分にとって最適な動作をし、快適なレベルの保護を提供するものを選んでください。
Figure 2 アカウント昇格のベスト プラクティス (Close Figure 2)

保護レベル | 昇格方法
より悪い | UAC をオフにする
悪い | 自動的に管理者に昇格する
良い | 管理者承認モードで実行する
より良い | 標準ユーザーとして実行し、別の管理アカウントに昇格する
最良 | 標準ユーザーとして実行し、UAC を使って昇格する代わりにユーザーを別の管理アカウントに切り替える
ついでながら、本当に被害妄想の人は、ベンダがアプリケーションを管理者として実行する必要があると言っても信用しません。ベンダにこう言われてもそれが誤りである最も明らかな例の 1 つは Visual Studio® 2005 Service Pack 1 です。Visual Studio を起動すると、管理者として実行するように指示されます。しかし、これが該当するのは、特定のタスクを実行する必要がある開発者にとってだけです。詳細については、msdn2.microsoft.com/en-us/vstudio/aa972193.aspx を参照してください。

ユーザーに力を与える
ユーザーには、より多くの適切な決断を行うための力を与える必要があります。業界には、セキュリティ上の決断はユーザーに見えないようにすべきだと信じているセキュリティ専門家の一団がいます。口には出しませんが、彼らは、ユーザーはセキュリティに興味がないだけでなく、それを適切に処理する方法を学べるほど知的でもないということをその根拠としています。<お好みのセキュリティ対策テクノロジをここに入れてください> に依存することによってのみ、彼らは適切に保護されるのです。
人々を対象とした攻撃にテクノロジによってどうすれば究極的な保護を提供できるのか、私にはわかりません。今日の攻撃の大多数は、事実上すべてのフィッシング攻撃も含めて、主に人々と彼らがコンピュータを実行する方法をターゲットにしており、そのコンピュータ内のテクノロジを攻撃するものではありません。これらの攻撃で最も効果的なのは、人々に対する攻撃とテクノロジに対する攻撃を組み合わせたものかもしれませんが、それでもたいていの場合、実行にはユーザーの操作が必要です。テクノロジを対象としていない攻撃に対する保護を、テクノロジだけに期待することはできません。私は少し前にもこの件についてあれこれ書いています (technetmagazine.com/issues/2006/07/SecurityWatch)。
UAC は、既にユーザーにセキュリティ上の決定を迫っています。一方、ユーザーにそのような決定をさせないようにするソリューションを作ろうというテクノロジ ベンダも既にあります。ユーザーがセキュリティのことで悩まされたくないと思っているのは事実です。しかし、他のソフトウェアの意図を認識できるソフトウェアがないのも事実です。Web サイトがクレジット カード番号の入力を求めているのは、Windows Vista 用セキュリティ製品を出荷するためなのか、それとも闇の犯罪組織に番号を送るためなのかを判断できる侵入防止システムは存在しません。それができるのはエンド ユーザーだけであり、しかも適切な情報が与えられた場合だけです。ソフトウェア エンジニアとして、私たちは、セキュリティ上の知的な決断を自分自身で下さなければならないという事実にユーザーを慣れさせ、その方法を教え、またそのために必要な情報を与えなければなりません。
ユーザーがセキュリティの決断を下さなくても済むようにするという現在の方針に私たちが固執しても、結局は彼らを守れないことを認識するだけです。そのうちにユーザーは、侵入され、プライバシーが侵害され、銀行口座番号や ID を盗まれ、尊厳や自尊心を傷つけられるのにうんざりするはずです。こうなると、人々は、業界を維持するために私たちが彼らに買ってもらわなければならない製品を使用するのをやめるでしょう。ハイテク業界には、コンピュータや「e-何々」にはセキュリティ上の問題があるという事実を公表しなければ、ユーザーは私たちが投じた製品を何でも盲目的に使用すると信じている人たちがいます。これほど真実とかけ離れていることはありません。私たちがオープンでも正直でもなかったことをついにユーザーが知ったとき、彼らは信頼をすべて失くし、私たちの製品に背を向けることでしょう。そしてそれは、事実を隠すことで守ろうとした、まさにその業界の崩壊を招くのです。
UAC は、ユーザーに自分のシステムのセキュリティに関して、責任を負う力を与える道筋への胸躍る一歩です。これは決して完全なセキュリティ ソリューションではありませんが、ユーザーが少ない特権で実行するのに役立つ最初の試みとしては、正しい方向への大きな一歩であることは間違いありません。

Dr. Jesper M. Johansson は、ソフトウェアのセキュリティ問題に取り組む Principal Security Engineer で、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、コンピュータ セキュリティの分野で 20 年以上の経験があります。


 デスクトップ ファイル: Windows PE を使用した PC の復旧
デスクトップ ファイル
Windows PE を使用した PC の復旧
Wes Miller

以前のコラムで、Windows PE の最初の構想は、それを展開環境にすることだったと説明したことがあります。すべての優れた製品と同じように、Windows PE も単なる展開環境を超えて進化しました。顧客 (当初は OEM) は、製造用とユーザー自己復旧用のソリューション構築に意欲を燃やし、数社は
その両方の目的で機能する Windows® PE ソリューションを開発しました。
今日存在する復旧ツールのほとんどは、展開プロセスのミラーリングによって、システムを正常と確認されていた状態に戻すことを前提としています。Windows Vista® では、Windows XP よりも復旧作業がずっと簡単になっており、イメージングのサポートも組み込まれています (今月の TechNet Magazine に掲載されている Windows Vista バックアップ テクノロジについての Christine Fok の記事を参照してください)。
今月のコラムでは、Windows PE を基にした独自の復旧ソリューションの構築について説明します。Windows PE 2.0 は、すべての Windows ライセンスで無料で入手できる Windows 自動インストール キット (AIK) のコンポーネントです。このライセンスは、展開だけでなく、復旧およびトラブルシューティングのための Windows PE の使用にも適用されます。
独自のカスタマイズや調整の考慮はもちろん必要ですが、ここでは、Windows XP と Windows Vista のどちらを展開する場合であっても留意すべき一般的なポイントについて説明します。イメージングについての知識がある方は、既にご存知のことばかりです。
Windows PE 復旧ソリューションの主要コンポーネントは次のとおりです。
  • Windows PE
  • イメージング ユーティリティ
  • それらをまとめるスクリプト (または正規のアプリケーション)
オプションで、SQL サポートおよび Active Directory® Service Interfaces (ADSI) サポートを含めることもできます。SQL 接続を使用すると、インストールに何が必要かを定義する "部品表" のようなものをシステムに持たせることができるソリューションを間接的に構築できます。同様に、Active Directory に接続すると、マシン アカウント オブジェクト (MAO) プロパティごとの処理に役立ちます。
Windows PE に ADSI を含めることはマイクロソフトのサポート対象外ですが、この方法を説明するオンラインの記事は多数あります。正しく設定できれば、これは非常にうまく機能します。そのような裏技を使いたくない場合は、SQL サポートを追加して、Windows PE 復旧ツール用のワークフローをそこに組み込むことができます。ADSI プロパティが必要な場合は、同じ SQL Server™ に対してクエリを実行し、次に、実質的にパススルーとして機能する ADSI を経由して Active Directory に対してクエリを実行するスケジュール タスクをサーバー システムに設定できます。
これは、完全なソリューションではなく、スクリプトを作成したりその他の自動化を行ったりする必要がありますが、この設計によって Windows PE から Active Directory と対話できるようになります。
LDIFDE ユーティリティを使用して Windows PE 内から Active Directory 情報を読み取ることもできます。詳細については、このトピックについてのサポート技術情報の記事 support.microsoft.com/kb/237677 を参照してください。たとえば、次のようなコマンドを使用できます。
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
このコマンドを入力すると、指定したコンピュータ オブジェクトから x:\output.ldf に属性が取得されます。これで出力を解析できます。

SKU、プログラム ファイル、および言語
展開する必要がある Windows のバージョン、アーキテクチャ、および言語を考慮する必要があります。小規模でロケールが特定された組織であれば、1 種類の OS (Windows XP または Windows Vista) だけを展開したり、何であれ新しい PC に既にインストールされているものを使用すると考えられます。おそらく、x64 Windows システムを展開することは、たとえあったとしてもそれほど多くはないでしょう。また、サポートが必要な言語は 1 つだけのはずです。しかし、もっと規模が大きくグローバルな組織であれば、扱うアーキテクチャ、バージョン、構成は多くなるのが普通です。
以前のコラムで書いたように、x64 および x86 のボリューム イメージを同じ Windows Imaging (WIM) 形式のファイルに格納することはできますが、領域の節約にはなりません。復旧ソリューションを構築し、両方のアーキテクチャを対象にする必要がある場合は、それぞれを別の WIM に保存する必要があります。Windows XP と Windows Vista の両方を展開およびサポートする場合も、同じイメージに両方のオペレーティング システムを保存しても節約になりません。領域の節約を実現できるのは、同一アプリケーション (たとえば 2007 Microsoft® Office system) の多数のインスタンスを両方の展開に含める場合だけです。この場合はアプリケーション ファイルを複数回保存する必要はありませんが、それでも領域の著しい節約にはならないでしょう。
Windows PE のブート方法
Windows PE 1.6
リモート インストール サービス (RIS) からの
PXE ブート (RAMDisk なし)
ハード ディスク ドライブ
USB フラッシュ ドライブ
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB フラッシュ ドライブ
RAMDisk ハード ディスク ドライブ

Windows PE 2.0
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB フラッシュ ドライブ
RAMDisk ハード ディスク ドライブ

RIS からの PXE ブート は、PXE が必要な場合には最適ですが、この方法では PXE RAMDisk よりも起動に時間がかかり、消費するネットワーク リソースも多くなることに注意する必要があります。
ハード ディスク ドライブ は、使用メモリは最小ですが、ドライブをロックします。この方法は、デュアル パーティションを交互に切り替える復旧シナリオを使用する場合は理想的です。
USB フラッシュ ドライブ は、起動は簡単ですが、起動するシステムが OEM によって UFD ブート可能であると確認されず、Windows Vista Capable ロゴ (UFD ブート サポートをロゴの要件として保証している) がない場合、(RAMDisk と RAMDisk なしのどちらのシナリオでも) UFD の動作は予測できません。UFD ブートには、(読み書きの両方で) 高パフォーマンスのフラッシュ ドライブ、および USB コントローラおよび BIOS による Hi-Speed USB サポートが必要です。
RAMDisk ブート (すべてのバリエーションを含む) には、より多くのメモリが必要ですが、最適なパフォーマンスを実現できます。また、Windows PE をメモリ内の RAMDisk に入れておくことができます。Windows PE 1.6 の RAMDisk ブートは、一般に最低でも 256 MB の RAM があるシステムでのみ使用すべきです。Windows PE 2.0 (常に RAMDisk WIM ブートが行われます) では、一般に最低でも 384 MB の RAM があるシステムでのみ実行すべきです。

特定バージョンの Windows の複数の SKU を同じ WIM に格納すると、領域を大幅に節約できることに注意してください。たとえば、Windows XP Professional と Windows XP Tablet PC Edition、または Windows Vista Business Edition と Windows Vista Ultimate Edition を組み合わせるとします。同じリリースおよびサービス パック レベルの 2 つの SKU は、いずれもほぼ同じコードおよびファイルを使用するので、これらの組み合わせでは領域を効率的に使用できます。
最後は、言語です。組織が大きいほど、対応が必要な言語数が増えます。Windows XP では、ローカライズされたビルドと複数言語ユーザー インターフェイス (MUI) のどちらを使用するかを選択できます。完全にローカライズされた Windows XP のビルドでは、短い文字列までほとんどすべてが対象の言語にローカライズされています。一方、MUI では、基本言語は英語ですが、MUI 言語パック (後の Language Interface Pack) では、可能な限り多くの文字列が変更されます (MUI は Windows 2000 である程度成功していましたが、Windows XP および Windows Server 2003 ではさらによい結果を残しています)。
組織で MUI を使用する場合は、さまざまな言語のバージョンを同じ WIM に組み合わせると非常に効果的です。これは、それらがすべてコア レベルでは英語のバイナリを使用するからです。ただし、これは Windows Vista より前に発売されたローカライズ バージョンには該当しません。バイナリ自体がローカライズされているので、複数の言語間ではバイナリが一致しません。これは、各言語のオペレーティング システムのほぼ全体 (およびローカライズされたアプリケーション) を格納する必要があることを意味します。
Windows Vista では、ローカライズ バージョン (単一のバイナリの一部としてその内部のリソースをローカライズしたもの) は廃止されたと考えることができます。Windows Vista は、英語を含む各言語の .mui リソース ファイルを使用します。基本的に、Windows Vista は言語に依存せず、ほとんどすべての言語情報は MUI ファイルに存在します。したがって、複数の言語バージョンの Windows Vista を同じ WIM に格納すると、領域を大幅に節約できます。2 ～ 4 またはそれ以上の数の言語を 1 つの WIM として保存しても、イメージが劇的に増加することはありません。また、後で変更が必要になった場合は、言語を切り替えたり追加したりできます。
つまり、ソリューションを構築する場合は、使用する Windows のバージョンを、他のアプリケーションのバージョン同様に考慮し、同一バイナリを共有して、ファイルのインスタンスを 1 つだけ保存すれば済むようにします。これは、組織全体で必要な WIM ファイルの数を特定するのに役立ちます。

ユーザーのシナリオ
一般に、組織が大きくなればなるほど、複雑さも増します。これは、単にサイズの問題ではなく、導入されるすべての不確定要素によるものです。ユーザーや部署の増加に伴い、特定のニーズも多くなります。
以前、ある多国籍企業の仕事をしたことがありました。この会社は、何万人ものユーザーを抱え、地理的および組織的に 1 か所からすべてを管理する展開プロセスを採用していました。この組織の経営者は、いつも非常に難しい質問を投げかけてきました。たとえば、彼にとってアフリカのある地域に駐在しているリモート ユーザーが懸念材料でした。彼らには安定したネットワーク接続手段がなく、事実、その多くは電話回線から数百マイル離れたところで活動していました。彼は、このようなユーザーが、何日もシステムを停止させたり長距離を移動したりしなくても自分でシステムを復旧できるようにするにはどうすればいいかを知る必要がありました。
製品を開発する場合は (ここでは、復旧ソリューションを製品として考えてください)、ユーザーのことを考える必要があります。特定のビジネス ニーズについて考慮するのは当然ですが、同様に、さまざまなタイプのユーザーにはそれぞれ異なる複雑な要素があることも考慮します。ユース ケースを導入し、短い説明を使って、サポートが必要な各タイプのエンド ユーザーについて記述する必要があります。これによって、うっかり復旧ソリューションから除外していたユーザーに気付いたり、各タイプのユーザーのニーズを確実にすくい上げたりすることができます。

適切な Windows PE のバージョン
もう 1 つの重要な決定事項は、自分のニーズに合っているのはどのバージョンの Windows PE であるかの判断です。それには、このコラムの以前の連載記事が役に立ちますが、ここではもう少し明確な判断をしてみましょう。次のいずれかに該当する場合は、Windows PE 1.6 を使用する必要があります。
  • Windows XP (または Windows Server 2003) だけを復旧する。
  • ACPI (Advanced Configuration and Power Interface) 準拠ではないシステムを復旧する。
  • RAM が 512 MB 未満のシステムを復旧する。
  • RAM が 256 MB 未満で、PXE (Pre-Boot eXecution) ブートを必要とするシステムを復旧する。
次のいずれかに該当する場合は、Windows PE 2.0 を使用する必要があります。
  • Windows Vista (または Windows Server 2008) だけを復旧する。
  • Windows Vista および Windows XP を復旧する。
  • BitLocker™ を使用している。
ImageX (「作成、更新、および保存」を参照) およびほとんどのサードパーティ製のイメージング ソリューションは、どちらのバージョンの Windows PE でも適切に機能します。

Windows PE をブートする
次に考慮すべきことは、Windows PE のブート方法です。ここで主要な役割を果たすのがユーザー シナリオです。ユーザーが復旧用に CD-ROM や DVD を持ち歩くことは現実的でしょうか。旅行中に CD-ROM や DVD をノートパソコンに挿入できるでしょうか。そして、この復旧メディアをどのようにして更新すればいいでしょうか。リムーバブル メディア上の復旧イメージは、すぐに古くなります。
私が見た中で最も一般的なシナリオとして群を抜いていたのは、セカンダリ ハード ディスク パーティションです。そしてもう 1 つの方法は PXE ブートです。また、その他にも外部 USB ドライブや、USB フラッシュ ドライブ (UFD) の使用も検討できますが、対象のハードウェアが UFD デバイスからのブートを明示的にサポートしている必要がある点に注意してください。
補足記事の「Windows PE のブート方法」で、各バージョンの Windows PE のブートでサポートされている方法と、それぞれの方法についての重要な考慮事項を確認できます。
Windows PE のブートでの目標は、次のような特定の条件を満たしつつ復旧プロセスを開始できるようにすることです。
  • ユーザーの操作を最小限にする。
  • 携帯するパーツ (リムーバブル メディアまたはリムーバブル デバイス) を最小限にする。
  • PC がネットワークに接続できない可能性がある。
  • PC をローカルで起動できない (Windows の起動に失敗する) 可能性がある。
たいていの場合、管理者は、ドライブ障害のことも考えて、Windows PE をハード ディスクに (フラットに、または RAMDisk に) 配置するオプションを選択肢から除外します。しかし実際のところ、今日のディスクの信頼性と、物理ドライブで実際に障害が発生した場合はいずれにしてもユーザー自身でそのシステムを復旧することはできないという事実を考えれば、これは有効なオプションです。
私が気に入っているのは、セカンダリ パーティションを作成して、そこに復旧イメージを保存する方法です。パーティションを非表示にすることについては、あまりメリットはないと思います。単にユーザーを惑わせるだけです。アクセス制御リスト (ACL) をそこで使用することも、ユーザーがローカル管理者でない限り、有効ではありません。
Windows で使用されるパーティションを圧縮することによって (補足記事「復旧パーティションを作成する」を参照)、Windows PE と復旧イメージを保存するために十分な空き領域を捻出できることがあります。Windows PE をセカンダリ パーティションに配置するには、復旧パーティションに適切なブート セクタを作成し、Windows PE をそのパーティションに配置するだけです (Windows AIK および以前のバージョンの Windows PE のドキュメントにこのプロセスの説明があるので、ここでは詳細は割愛します)。覚えておくべき重要なポイントは、ブートに使用されるパーティションが、どちらのパーティションがアクティブとしてマークされているかによって決まることです。Diskpart には、アクティブ フラグと、それと同じくらい重要な非アクティブ フラグの機能があります。Windows 内から (または Windows PE のコピー内から) 復旧パーティションを起動するには、Diskpart を使用してアクティブ パーティションを切り替えます (図 1 を参照)。以下は、単一ディスクのデュアル パーティション システムの切り替えに使用される Diskpart スクリプトの例です (diskpart /s nameofscript.txt を使用)。
SEL DIS 0
SEL PAR 1
INACTIVE
SEL PAR 2
ACTIVE
EXIT
図 1 Diskpart によるアクティブ パーティションの変更
図 1 Diskpart によるアクティブ パーティションの変更
これは、多数のコンシューマ復旧ツールでパーティションの交互切り替えに使用されているプロセスです。非表示の OEM パーティションなどの特定のパーティション タイプでは、これは Windows PE 内からのみ実行できます。これらのツールによって、非表示の OEM パーティション タイプが再表示されることもあります。

作成、更新、および保存
復旧パーティションを作成する
Windows には手を付けずに復旧パーティションを作成するプロセスは、手順さえわかれば、難しくはありません。何をすればいいかをざっと説明しましょう。このプロセスでは Windows PE 2.0 が必要であることに注意してください。展開または復旧に Windows PE 2.0 を使用しないかもしれませんが、このタスクではバージョン 2.0 を使用する必要があります。このプロセスは、Windows Vista の展開時にも使用できます。また、BitLocker ブート ファイル用のブート パーティションの作成にも使用できます。これは、BitLocker は少なくとも 2 つのパーティション (ブート ファイル用と Windows システムの残り部分のために 1 つずつ) を必要とするからです。
  1. デフラグを実行してディスクを最適化する (これによって非常に時間のかかる圧縮処理を高速化できます)。
  2. Windows PE 2.0 を起動する。
  3. Diskpart を実行する (必要な場合は、手順 4 ～ 9 のスクリプトを作成し、Diskpart に次の引数を渡すことも可能: /s 自分のスクリプト名)。
  4. SEL VOL 1 (または圧縮するボリューム名)
  5. SHRINK DESIRED=N MIN=N (メガバイト単位で指定。DESIRED は目標値、MIN は必要な絶対最小値)
  6. 圧縮完了後に、SEL DIS 0 を実行する。
  7. CRE PAR PRI (ディスクの残り領域以外のサイズを指定する場合は SIZE=N を指定できます)
  8. ASSIGN LETTER=N:(この文字は Windows PE でのみ使用)
  9. Diskpart を終了する。
  10. FORMAT N:/Q /Y /FS:NTFS (新しいパーティションを NTFS でフォーマットします)
  11. bootsect N を実行する (2.0 の場合は /nt60、1.x の場合は /nt52)。
  12. 必要な Windows PE ファイルを復旧パーティションにコピーする。
  13. システムをシャットダウンする。

ImageX は無料で入手できるソリューションですが、既に使用しているイメージング ツールがあるかもしれません。どれでも一番使いやすいものを使用してください。ImageX の使用を考えている方のために、(価格以外で) 私が気に入っている点を挙げておきます。ImageX は、特に圧縮において威力を発揮します。また、イメージの追加や編集が比較的簡単というのも長所です。
さらに、ImageX では、既存のデータを破壊しないで 1 つ以上のボリュームをイメージングできる点も気に入っています。これにより、ユーザー データを、邪魔にならないところに移動するだけで保存できます。つまり、Windows を復旧するときに、ボリューム全体を消去する必要はありません。
それから、もちろんイメージの保存先を決める必要があります。ソリューションで復旧パーティションを使用している場合は、そこに WIM またはその他のイメージング ファイルを保存できます。標準の OS イメージを作成してそれをネットワーク上に保存する Windows 展開サービス (WDS) の使用も検討できます。これによって、インフラストラクチャ全体で利用できる共通の復旧ソリューションの構築が可能になります。もちろん、各地の現場にユーザーがいる (前に挙げた外国の辺ぴな場所にいる社員など) 場合は、彼らがネットワークに接続できないときに利用できる独自のソリューションを確保しておく必要があります。
既に述べたように、DVDなどのメディアも使用できますが、このオプションを一般的に使用することを個人的にお勧めしない理由はたくさんあります。たとえば、イメージのサイズはすぐに大きくなり、DVD のサイズを超えてしまいます。また、このようなディスクの更新は簡単ではありません。光学式メディアは問題外だという意味にはとらないでください。必要なのは、どのようなシナリオがどのようなタイプのユーザーに最適であるかを十分に検討することです。もうおわかりかもしれませんが、私のお気に入りを挙げておきましょう。それは、イメージを復旧パーティション、USB ハード ディスク、USB フラッシュ ドライブ、また可能な場合は WDS を使用してネットワークに保存する方法です。
WDS が選択肢として魅力的な理由の 1 つは、一元化されたイメージを簡単に更新できることです。Windows Update で毎月更新プログラムがリリースされ、その更新が通常重要であることはご承知だと思います。ソリューションは、可能な限り最新の復旧イメージを維持できるように設計してください。WDS を使用すると、各サーバーのイメージを更新でき、それですべて完了します。

ユーザー データおよび設定についての考慮事項
復旧ソリューションを設計する際に注意が必要な点があります。復旧ソリューションの計画で重要なのは、ユーザー データの安全性も確保することです。復旧を実行している現場のユーザーを、その過程で自分の重要なデータをすべて失うという目に合わせたくはありません。理想的なのは、システム復旧の処理方法に慎重である場合を除いて、ユーザーのデータを C: パーティション以外の別の場所に保存することです。
前述のように、ImageX はデータを破壊せずにディスクを復旧できます。たとえば、復旧完了後にユーザーまたはスクリプトが手動でファイルを復旧できるように、既存の Documents and Settings (または Users) ディレクトリ ツリーを別のディレクトリに移動します。自分のファイルをすべて自分のプロファイル内に保存しているユーザー、または移動プロファイルを使用しているユーザーは、ほとんどの場合、ユーザー データを失うことなくシステムを復旧できます。しかしそれでも、細心の注意を払って復旧ソリューションを設計している場合、または完璧なバックアップ ソリューションがある場合を除いて、ユーザー データを多少失う可能性があることを忘れないでください。
いくら設計が完全でも、情報を自分のプロファイル以外の場所に保存するユーザーは存在します。ソリューションでは、誤ってユーザー データを消去する可能性を必ず考慮して、事前にユーザーに警告する必要があります。
暗号化ファイル システム (EFS) を使用する場合は、キー復旧プランを実行していることを確認します。暗号化の復旧ができないせいでデータを失いたくはありません。同様に、BitLocker の場合は、暗号化されたボリュームの復旧についても必ず準備しておきます。これは、Windows PE 2.0 を使用することを意味します (1.x では BitLocker と対話できません)。BitLocker の復旧の詳細については、blogs.msdn.com/si_team を参照してください。
最後に、自分のカスタマイズやアプリケーションの一部が消えたときに混乱するユーザーがいるという事実への対処を考えておきます。(アプリケーションおよび Windows 自体の) カスタマイズの保存先は、ユーザー プロファイルには限られず、不規則です。OS パーティション全体を復旧するときに、「X はどこに行った?」とか「Word で Y が表示されなくなったのはなぜ?」といった問い合わせをしてくるユーザーがいます。ユーザーには事前に説明して、環境が以前とまったく同じになるとは限らないことを認識させてください。
Windows PE を使用した独自の復旧ソリューションの作成には時間がかかり、ソリューションの計画および設計時にはユーザーについて考慮する必要があります。復旧ソリューションは、あまり複雑にする必要はありません。限られた技術サポートと最小の時間でユーザーが元どおりに仕事ができるようになれば十分です。

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


 フィールド ノート: フリー フードとトレーニングのヒント
フィールド ノート
フリー フードとトレーニングのヒント
Michael Dragone

私は、従業員数が 約 150 人の権限保険会社に勤務しています。当社の主な基幹業務アプリケーションは Web ベースであるため、コンピューティング要件は、非常に単純です。そのため、主に Internet Explorer® と、そして、言うまでもありませんが Microsoft® Office を使用しています。
このように比較的単純なアプリケーション展開では、ユーザーがこれらのアプリケーションを使用して日常的に問題が発生することは、あるとしても非常に少ないと思うでしょう。その予測は大筋では間違っていません。発生する問題の大半は、TechNet Magazine の平均的な読者なら数秒で解決できる類のものです。
私は、経験から、このような問題を最小限に抑えるには、適切なユーザー教育が不可欠であることを学びました。読者の皆さんがユーザーに同様の対策を講じられること願い、当社がユーザーに対して実践していることを 2 つご紹介します。
1 つ目は、トレーニング クラスの開催です。当社では、導入した新しいシステム、展開予定の新しいアプリケーション、および設定された新しいポリシーについて紹介する講習会を頻繁に行っています。同様に、大幅なシステムの変更を導入する場合は、その変更内容を紹介して質問に答えることを目的とした、特別な講習会を行います。この講習会は、ユーザーが変更に対応できるように、変更を導入する前に行います。
たとえば、当社で電話システムの大規模なアップグレード展開を計画しているとします。ユーザーは、今後も現在と同じように Outlook® からボイスメールにアクセスできますが、それを行うために使用するソフトウェアが変更されます。実際に展開を行う時期よりもかなり前に、電話システムのベンダがユーザーに新しいインターフェイスのデモンストレーションを行い、質問を受け付ける、トレーニング セッションの開催を計画します。
また、ユーザーが抱えている既知の問題についての講習会も行います。トラブル チケット システムを操作した経験があれば、既知の問題がどのようなものかわかるでしょう。たとえば、あるユーザーが、2 つのシステムでは別のパスワードを使用する必要がある理由を理解していないことがありました。このことについて、いくら口頭で説明しても理解してもらうことはできませんでしたが、PowerPoint® のスライドの描写を見せたら納得してもらえました。
私は、経験から、トピックに関係なく、ミーティングを成功させるには、フリー フードと気楽な雰囲気が重要であることを学びました。たとえ "くだらない" 質問でも、ユーザーが何でも質問しやすいようにします。
2 つ目は、社内を歩き回ることです。私は、毎日 10 ～ 15 分間はユーザーとの交流の機会を持つようにしています。おかしな方法で操作を実行しているユーザーを見かけたら、立ち止まって、何を実行しているのかと、その理由について、数分間話をします。多くの場合、そのユーザーには、はるかに簡単な別の方法を提示することができます。たとえば、あるユーザーは、誤って Outlook ツール バーの配置を頻繁に変更していましたが、問題を修正する方法がわかりませんでした。ある日私がこのことに気づくまで、彼は密かに苦しんでいました。また誤ってツール バーの配置を変更したときに好きな配置に戻すことができるように、ツール バーに変更を加える方法を彼に伝授しました。
他のユーザーも、さまざまな理由で、ヘルプ デスクや技術サポート グループに問い合わせたくない問題を抱えている可能性があります。あるユーザーは、自分の質問は低レベルだから IT 部門の手を借りるには値しないと考えて、恥ずかしがっているかもしれません。IT 部門では、キーボードやマウスの交換が必要な場合に備えて代用品を用意していますが、ユーザーは、そのことを知らずに、性能の悪いキーボードやマウスを使い続けていることがあります。ユーザーとの対話に数分間の時間を割くことによって、ここで紹介したような問題の多くを解決し、次回のトレーニング クラスの題材を見つけることができます (トレーニングの開催時にはフリー フードもお忘れなく)。
業務におけるすべての側面で、ユーザーのことを念頭に置いておくことが重要です。すべてではないにしろ、システム、ポリシー、および手順に加えた変更の大半は、なんらかの影響をユーザーに与えます。ユーザーにはそれぞれ個性があるので、このような変更に対して異なる反応を示します。
多くの場合、テクノロジの才能があると自負する IT プロフェッショナルにとって、テクノロジの知識が少ないユーザーの手助けをするのは厄介な作業です。少しの辛抱とユーザー トレーニングによって、ユーザーが、私たち IT プロフェッショナルと同じくらいコンピュータを好きになってもらうようにすることができます。もちろん、少しずつですが。

Michael Dragone は、ニューヨークの権限保険会社に勤めるシステム エンジニアです。また、MCDST と MCSE メッセージングの認定資格を持っています。余暇には、海岸で愛犬と戯れながら長い距離を散歩したり、修正プログラムが完全に適用されたサーバーを整備したりしています。


 Windows 秘話: 既知の DLL のバランスを取る
Windows 秘話
既知の DLL のバランスを取る
Raymond Chen

"既知の DLL" と非公式に呼ばれる Windows の機能は、カーネルのモジュール ローダーが特別に処理する DLL (ダイナミック リンク ライブラリ) のリストのことです。ローダーがプログラムを読み込むときに既知の DLL に動的にリンクされていることがわかると、即座にその既知のコピーを使用し、モジュールの読み込み時に通常行う検索アルゴリズムを無視します。確かにかなり不十分ではありますが、これをセキュリティ機能と考える人もいます。しかし、実際には、この機能の目的はセキュリティではありません。既知の DLL は本来はパフォーマンスに関する機能でした。
既知の DLL 機能のしくみは長い時間をかけて変化してきました。あるバージョンの Windows® では、カーネルが既知の DLL のリストを出発点として使用し、既知の DLL からリンクされるすべての DLL を調べ、さらにそれらの DLL からリンクされる DLL を次々に調べていきます。このプロセスでは、すべての依存関係の推移閉包が作成され、これらの依存関係はすべて既知として扱われます。Windows のバージョンによっては、この推移閉包が作成されないものもあります。このようなバージョンでは、明示的に既知としてリストされている DLL だけが既知の DLL として扱われます。あるバージョンの Windows では、既知の DLL はシステムの起動時にカーネルによって事前に読み込まれます。他のバージョンでは、このような事前読み込みを行わずに、カーネルは DLL のパスを検索するという手間を省くためだけに、既知の DLL のリストを使用します。
バージョンごとに異なるのは、既知の DLL のリストの解釈だけではありません。KnownDLLs レジストリ キーの内容も異なることがあります。Windows パフォーマンス チームは、既知の DLL のリストだけでなく、アプリケーションが Windows をどのように使用するかを把握して、リストが一連の DLL に変換されるときに使用される規則も変更しています。これは、エンジニアリングではいつも行われることですが、トレードオフという 1 つのゲームです。既知の DLL をシステムの起動時に事前に読み込んでおけば、それらの DLL を使用するアプリケーションの起動は高速になりますが、そこには代償を伴います。つまり、それらの DLL が実際に使用されるかどうかにかかわらずメモリに残るため、システムの起動に時間がかかり、メモリの使用量が増加することになります。これは、他を犠牲にしてでも一部のコンポーネントのパフォーマンスを向上させるというゲームです。適切なバランスをとることは困難な作業です。また、おわかりのように、このバランスは使用パターンが進化するたびに絶えず調整されることになります。
あまり明らかにはされていない既知の DLL の結果として、既知の DLL はローカルにリダイレクトされる DLL よりも優先されるという点があります (ローカルにリダイレクトされる DLL については、2007 年 1 月号のこのコラムで説明しました)。考えてみると、これは思いがけない動作ではなく、実際に予測される動作であることがわかるでしょう。結局のところ、既知の DLL のリストの目的は、検索パスを省略し、DLL の読み込み速度を上げることです。カーネルがローカルにリダイレクトされる DLL を確認する必要があれば、DLL の読み込み速度が遅くなるだけです。検索パスにたった 1 つのディレクトリを追加することはそれほど大変なことではないと考えるかもしれませんが、その 1 つのディレクトリが地球の真中にあるネットワーク サーバーだとすると、1 つのディレクトリを追加しただけで、パフォーマンスが大幅に低下することもありえます。
信じられないかもしれませんが、既知の DLL のリストに含まれる特定の DLL に依存するプログラムに出会いました。このプログラムは、アプリケーション ディレクトリに Version.dll というファイルを保持していました。通常の規則に基づくと、この Version.dll のプライベート コピーはシステム ディレクトリにある Version.dll よりも優先されますが、Windows XP では、Version.dll が既知の DLL としてリストされています。つまり、アプリケーション ディレクトリにあるコピーは無視され、システム ディレクトリ内のバージョンが使用されます。
Windows Vista® では、Version.dll は既知の DLL としてリストされません。これは、パフォーマンス チームのメンバが、コストを十分に正当化できるほど、アプリケーションが Version.dll を使用していないと判断したためと考えられます。その結果、実際にアプリケーションが依存するのはカーネル上の DLL であり、プログラムが自身のアプリケーション ディレクトリにインストールした DLL は無視されるため、このプログラムは Windows Vista で機能しなくなります。プログラムは意図的に検索パスに DLL をインストールしていましたが、Windows に依存することで、その DLL が無視されたのです。間違いなく Windows にファイルを無視させる必要があるのなら、最初にファイルをインストールしない方がもっと効率的なメカニズムです。意外だったのは、プログラムを作成した会社が、セキュリティ ホールが見つかったと主張して、バグを届け出たことです。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。彼の T シャツのサイズについてはわかりませんが。