 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

Exchange 2007 に移行するなら、ここに来られて正解です。今月は、アップグレードに向けてどのような準備をすればよいか、Exchange 管理シェルを使用して Exchange を管理するスクリプトを記述する方法、および Outlook Web Access と Exchange 2007 を統合するときに、あらゆる場所からのアクセスとユニファイド メッセージングを実現する方法について説明します。

また、Exchange Server 2007 と Outlook 2007 クライアントの両方に盛り込まれる最新の強化点をすべて理解し、Sender ID Framework を使用して効率的にスパムと戦う方法を学習し、優れた制御と遵守を導く Exchange 2007 のジャーナリングについて調べます。
特集
Exchange Server 2007 Exchange 2007 へのインフラストラクチャのアップグレード

組織の規模にかかわらず、Exchange Server 2007 への移行をスムーズに行うには、事前の計画が必要です。適切な計画を立てれば、サービスの中断を回避することができます。この記事では、アップグレードの実行に必要な手順について説明します。

Kate Follis Exchange 管理シェルでのコマンドの実行

Exchange 管理シェルでは、Exchange Server 2007 のすべての側面を管理するための強力なインターフェイスが管理者に提供されます。ここでは、スクリプト記述の開始、アプリケーションの統合などの強力な管理作業の実行をコマンドラインから行う方法の概要を説明します。

David Strome Exchange と Outlook を併用するメリット

Exchange Server 2007 と Microsoft Office Outlook 2007 を併用すると、コミュニケーションとコラボレーションが飛躍的に向上します。構成の簡略化、検索機能の向上、ユニファイド メッセージングなどについて見ていきながら、どのように強化されるかを説明します。

Michael Khalili Exchange Server 2007 との常時接続

通信は、かつてないほど強力になりました。この記事では、Exchange Server 2007 に組み込まれたユニファイド メッセージングと Outlook Web Access の機能により、任意の場所からメッセージにアクセスすることがどのように実現されているのかについて説明します。

Joshua Trupin Exchange 2007 の強力なジャーナリング

Exchange Server 2007 では、柔軟性が大幅に向上したジャーナリング機能が提供されるので、特定のユーザー アカウントの監視や、大規模組織内の遵守要件を満たすことが簡単になります。

David Strome Sender ID を使ったスパムやフィッシングと戦い

Sender ID Framework (SIDF) を基に構築された電子メール認証は、幅広く導入されており、スパム メッセージやフィッシング メッセージとの戦いにおいて大きく進歩しています。実際、世界中で送信されている電子メールのうち、3 分の 1 を超える電子メールが既に認証されていて、SIDF に準拠しています。

Craig Spiezle および Alexander Nikolayev
コラム
編集長からのごあいさつ

皆さんと近づくために

Joshua Trupin ツールボックス

IT プロフェッショナル向けの新製品

Greg Steen Windows PowerShell

簡単なコマンド、強力な管理機能

Don Jones 事後分析

Exchange 5.5 からの移行

Whitney Roberts 		SQL に関する Q&A

再起動の防止、複数の更新プログラムのインストールなど

Nancy Michell Hey, Scripting Guy!

カップホルダーはどこえ消えた?

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

グローバルに信頼された PKI の展開

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

Windows Imaging 形式について

Wes Miller Windows 秘話

RunOnce 待ち

Raymond Chen


 Exchange Server 2007: Exchange 2007 へのインフラストラクチャのアップグレード
Exchange Server 2007 Kate Follis

Exchange 2007 へのインフラストラクチャのアップグレード
概要:
  • Exchange 2007 の新機能
  • アップグレードの準備
  • 役割に基づいた展開
  • メッセージ ルーティング トポロジ

以前私は Exchange Server 5.5 から Exchange 2000 Server への移行に関する授業を担当していました。講義は朝の 8 時半に始まり、午後 6 時ごろに終わります。私は教室から出るとくたくたになっていました。
ディレクトリ リソースを移行するだけでも多くの準備作業があり、加えて NTDSNoMatch によってたびたび混乱させられたり、Windows NT® 4.0 に信頼を拒否されることもありました。時間の制約もあって、Exchange 2000 Server の管理についてはほとんど触れることができませんでしたが、何人かの熱心な生徒たちは、金曜の夜に教室を出た後から週末にかけて移行を完了させる計画を立てていました。私はもっと時間をかけて計画するよう注意しましたが、聞き入れてくれたかどうかはわかりません。
Exchange 2000 Server または Exchange Server 2003 から Exchange Server 2007 への移行を行う場合も注意することは同じです。つまり、計画に時間をかける必要があります。実際の移行プロセスは組織ごと、および現在の展開の複雑さによって異なりますが、どの移行プロセスでもいくつかの段階を踏む必要があります。小さな組織ではこうした段階を 1 つのプロジェクトとして進めるかもしれませんが、大きな組織ではしばらくの間共存モードで運用し、徐々にサーバーの役割を導入して Exchange をサポートすることになるでしょう。エンドツーエンド プロセスは、移行期間全体を通じてメッセージング機能と安定性を維持するように設計されます。この記事では、Exchange Server 2007 へのアップグレードを行う際に、組織内のメッセージ フローを維持するために不可欠な手順について説明します。

考慮事項
最初に注意する必要があるのは、Exchange Server 2007 は 64 ビット ハードウェア上で展開する必要があり、Exchange の以前のバージョンからのインプレース アップグレードをサポートしていないことです。既存のメッセージング サービスを Exchange 2007 に移行するには、スイング アップグレード方式を使用する必要があります。また、Exchange 2007 サーバーの追加をサポートするには、Exchange 組織がネイティブ モードで実行されている必要があるので、組織で現在 Exchange 5.5 を使用している場合は、一時的に Exchange Server 2003 にアップグレードしてから Exchange 2007 に移行する必要があります。
移行を計画する際は、Exchange 2007 のいくつかの重要な変更点について考慮する必要があります。たとえば、Exchange 2007 では役割に基づいた展開が導入されるので、提供するメッセージング サービスを選択し、それらのサービス固有のサーバーの役割を展開できます。サーバーの役割は、専用ハードウェアにそれぞれ展開するか、同じ物理サーバーに複数の役割をインストールし、別々のエンティティとして管理できます。各サーバーの役割の詳細については、補足記事の「Exchange 2007 サーバーの役割」を参照してください。
Exchange Server 2007 サーバーの役割
メールボックス サーバー メールボックス サーバーの役割は、組織のメッセージ ストレージを提供します。Exchange 2007 では、サーバーごとに最大 50 個のストアをサポートできます。これらのストアを 50 個の異なるストレージ グループとして展開するか、1 個のストレージ グループに 50 個までストアを作成することができます。メールボックス サーバーの役割は、クラスタとして展開できる唯一の役割なので、クラスタを使用する場合は、専用ハードウェアにメールボックス サーバーをインストールする必要があります。
クライアント アクセス サーバー クライアント アクセス サーバーの役割は、フロントエンド サーバーによって提供される機能を置き換えます。この役割は、POP3、IMAP4、Outlook® Web Access (OWA)、RPC over HTTPS (現在は Outlook Anywhere として知られています)、および Exchange ActiveSync® を使用して Exchange にアクセスしているクライアントにメールボックスへのアクセスを提供します。
ハブ トランスポート サーバー この役割は、Exchange 組織用の SMTP および MAPI メッセージ トランスポート サービスを提供します。組織内のユーザーが送受信するすべてのメッセージはハブ トランスポート サーバーで処理されます。これにより、トランスポート パイプラインのさまざまなポイントで起動されるエージェントによって提供されるサーバー ベースのルールやジャーナリング ポリシーがすべてのメッセージに適用されるというメリットが得られます。
ユニファイド メッセージング サーバー この役割は、メールボックスへの音声アクセスを提供します。この役割はメッセージや予定表アイテムへの電話によるアクセスを提供するために IP/VoIP ゲートウェイや IP-PBX と統合されるので、応答の記録も可能になります。これは Exchange に初めて導入された役割なので、Exchange の以前のバージョンと相互運用することはできません。
エッジ トランスポート サーバー 通常、エッジ トランスポート サーバーは境界ネットワークに展開されます。この役割は Exchange 組織とインターネットとの間の SMTP メッセージ トランスポートや、トランスポート エージェントを使用したスパム対策処理とウイルス対策の処理を提供します。これにより、組織のサーバーと境界ネットワーク サーバーの両方に関して、1 つのテクノロジに基づいた標準化が可能になります。このシームレスな対話モデルにより、管理が簡略化され、境界サーバーを容易に統合できるようになります。

トポロジの調査
では、どの部分から作業を始めましょうか。まず現在の状況を知らなければ、目標を見つけ出すことは困難です。現在の環境を評価し、Exchange 環境と Active Directory® 環境のトポロジを文書化する時間をとりましょう。Exchange 2007 では、リンク状態によるルーティング、およびルーティング グループとコネクタに基づいたトポロジが廃止されます。代わりに、今までに組織で Active Directory トポロジの設計に対して行った投資を活用します。その結果、Exchange のすべての受信者データと構成データを Active Directory に格納し、ルーティング トポロジを Active Directory サイトの構成から派生します。また、すべてのサーバーの役割でサイト認識機能が使用され、他のサーバーの役割で実行されているサービスが検出されます。
現在の Active Directory サイトのトポロジで基になる物理ネットワークが活用されているかどうか、およびすべての Active Directory サイトが関連するサブネットを保持しているかどうかを確認してから、既存の Active Directory サイトと IP サイト リンクを文書化します。また、すべての Exchange 2003 サーバーの物理的な場所、およびルーティング グループとルーティング グループ コネクタの構造も文書化します。
次の手順は、移行プロセスで最も注意が必要な、ルーティング グループに基づいた Exchange ルーティング インフラストラクチャから Active Directory サイトに基づいたルーティング インフラストラクチャへの移行です。通常、小規模組織の場合、この移行プロセスは単純ですが、多くのルーティング グループが存在する大規模組織では、Exchange 2003 と Exchange 2007 が共存している場合、中間段階の計画を注意深く立てる必要があります。最終的な目標は、Exchange 2007 ユーザーから外部ネットワークの Exchange 2003 メールボックスに送信されたメッセージを低帯域幅接続でいくつかのリモート ルーティング グループを経由してルーティングすることです。
まず現在のトポロジについて、次のようないくつかの前提を立ててみましょう。
  • Exchange 2003 組織がネイティブ モードで実行されている。
  • 複数のルーティング グループが存在する。
  • 複数の Active Directory サイトが存在する。
図 1 は、Exchange と Active Directory のトポロジを示しています。準備段階で詳細な計画を立てることにより、設計の質も向上します。
図 1 Exchange と Active Directory のトポロジ
図 1 Exchange と Active Directory のトポロジ (画像を縮小するには、ここをクリックします)
図 1 Exchange と Active Directory のトポロジ
図 1 Exchange と Active Directory のトポロジ (画像を拡大するには、ここをクリックします)

Exchange 2007 での Active Directory の使用
Exchange 2007 サーバーの起動時、このサーバーによって提供されるサービスを他の Exchange 2007 サーバーが見つけるのに役立つサイト属性がスタンプされます。SMTP を使用して組織内のメッセージを転送できるのは、ハブ トランスポート サーバーだけです。メールボックス サーバーを含む Active Directory サイトにはそれぞれハブ トランスポート サーバーも含まれている必要があります。また、メールボックス ユーザーがメールボックスへのアクセスに MAPI 以外の方式でアクセスしている場合は、クライアント アクセス サーバーも含まれている必要があります。メッセージを配信用に処理する必要がある場合、メッセージは常にハブ トランスポート サーバーを経由します。このサーバーで、メッセージのルーティング方法が決定されます。メッセージの送信先がハブ トランスポート サーバーと同じ Active Directory サイトのメールボックス サーバーの場合、ハブ トランスポート サーバーはそのサーバーのメールボックスにメッセージを配信します。メッセージの送信先が他のサイトのメールボックス サーバーの場合、ハブ トランスポート サーバーはリモート サイトのハブ トランスポート サーバーに直接メッセージを中継します。
ハブ トランスポート サーバーは、Active Directory の IP サイト リンクのコスト情報を使用して、受信者のメールボックスがある Active Directory サイトまでの最小コストのルートを算出します。ルート選択アルゴリズムは Exchange 2003 と非常によく似ていますが、基になっているのはルーティング グループ コネクタのコストではなく IP サイト リンクのコストです。また、メッセージは途中の各ハブ トランスポート サーバーで止まることなく、直接送信元から送信先に移動します。では、ハブ トランスポート サーバーが IP ネットワークに依存してメッセージを転送している場合、なぜ最小コストのルートをわざわざ算出するのでしょうか。これにはいくつか理由があります。1 つはメッセージの分岐を遅らせるためです。複数の受信者に送信されるメッセージは、場合によっては複数の Active Directory サイトのメールボックス サーバーに配信する必要があります。Exchange 2007 は、最初のハブ トランスポート サーバーでメッセージを分割するのではなく、ルーティング パスの分岐に達したときに分割します。その結果、メッセージは分岐ポイントを表す Active Directory サイトのハブ トランスポート サーバーに直接中継されます。この動作を遅延ファンアウトといいます。
最小コストのルートは、送信先にメッセージが到達しなかった場合にメッセージを格納するキューの決定にも使用されます。メッセージが送信先の Active Directory サイトのハブ トランスポート サーバーに到達しなかった場合、送信元のハブ トランスポート サーバーはルーティング パスに従って、次に近い Active Directory サイトのハブ トランスポート サーバーへの配信を試みます。メッセージの配信は、利用可能なハブ トランスポート サーバーが存在する Active Directory サイトにメッセージが到達するまで、最小コストのルートに基づいて続行されます。最終的に、送信先の Active Directory サイトへのルートの途中に利用可能なハブ トランスポート サーバーが存在しなかった場合、メッセージはローカルのキューに格納されます。この方式では、メッセージをできるだけ配信ポイントに近いキューに格納することにより、ネットワーク障害の診断の確度を高めることができます。このような動作を、単一障害点でのキュー登録といいます。
Exchange 2003 の動作方式は、まったく異なります。Exchange 2003 では、ルーティング グループ コネクタに割り当てられたコストに基づいて、あるルーティング グループから別のルーティング グループまでの最小コストのルートを算出します。ルーティング パスの途中にある各ルーティング グループ内のブリッジヘッド サーバーが、メッセージを受信して中継します。パスの次のコネクタが利用できない場合、別のルートの算出が試行されます。また、接続が利用できないことを他の Exchange サーバーに通知するために、リンク状態更新メッセージが Exchange 組織全体に配信されます。ブリッジヘッド サーバーは、接続を利用できることを示すリンク状態の通知を受け取るまで、利用できないコネクタに近いコネクタへの接続を試みます。
大規模組織で移行を行う際の課題は、共存運用期間中のメール フローの維持です。Exchange 2007 を環境に導入する際にこの継続性を実現するために、すべての Exchange 2007 サーバーは 1 つのルーティング グループにメンバとして追加されます。つまり、Exchange 2007 サーバーがどの Active Directory サイトに属していても、Exchange 2003 はその 1 つのルーティング グループに属しているサーバーとして認識します。これにより、このルーティング グループと Exchange 2003 ルーティング グループとの間にルーティング グループ コネクタを確立できるので、Exchange 2003 は Exchange 2007 へのメッセージのルーティング方法を決定できます。Exchange 2007 もこのルーティング グループ コネクタを使用して、Exchange 2003 へのメッセージのルーティング方法を決定します。ただし、Exchange 2007 は常に別の Exchange 2007 サーバーを経由したメッセージのルーティングを試みるので、Exchange 2003 ルーティング グループをバックボーンとして経由して別の Exchange 2007 サーバーに到達することはありません。

最初の Exchange 2007 サーバーの導入
Exchange 2003 組織に最初の Exchange 2007 サーバーをインストールする際には、最初のルーティング グループ コネクタを確立する Exchange 2003 ブリッジヘッド サーバーを選択する必要があります。
図 2 は、最初の Exchange 2007 サーバーの導入が組織のトポロジに与える影響を示しています。
図 2 最初の Exchange 2007 サーバーのインストール
図 2 最初の Exchange 2007 サーバーのインストール (画像を縮小するには、ここをクリックします)
図 2 最初の Exchange 2007 サーバーのインストール
図 2 最初の Exchange 2007 サーバーのインストール (画像を拡大するには、ここをクリックします)
ここまでは順調ですね。Exchange 2007 によって作成されるルーティング グループ コネクタの既定のコストは 1 だけであることに注意してください。メールは通常どおり Exchange 2003 サーバーを経由します。Exchange 2003 サーバーから Exchange 2007 サーバーのユーザーにメッセージが送信された場合、そのメッセージは Acapulco ルーティング グループを経由します。ルーティング グループ コネクタの作成時に、選択した Exchange 2003 ブリッジヘッド サーバーは自動的に ExchangeLegacyInterop ユニバーサル セキュリティ グループにメンバとして追加され、Exchange 2007 との間でメッセージを送受信するための適切なアクセス許可を与えられました。コネクタの送信元または送信先のサーバーとして Exchange 2007 サーバーが指定されている場合、ルーティング グループ コネクタを作成するには、常に Exchange 管理シェルの New-RoutingGroupConnector を使用する必要があります。また Set-RoutingGroupConnector コマンドレットを使用して、ルーティング グループ コネクタの構成を変更することもできます。たとえば、最初のルーティング グループ コネクタに送信元と送信先のサーバーを追加して、冗長性を提供することができます (詳細については、David Strome が今回の TechNet Magazine で執筆した Exchange 管理シェルに関する記事を参照してください)。

一部のメールボックスを移動するための準備
次は、Exchange 2003 サーバーから Exchange 2007 サーバーに一部のメールボックスを移動します。これを行うには、Move-Mailbox コマンドレットを使用します。ただし、Exchange 2003 サーバーを解除する前に、Exchange 2007 サーバーに送信コネクタと受信コネクタを作成し、Exchange 2003 サーバーで外部の SMTP アドレス空間へのルーティングを処理するために定義された SMTP コネクタを作成したコネクタに置き換えるとよいでしょう。
次の図では、Acapulco ルーティング グループのリソースが Exchange 2007 に移動されています。Acapulco ルーティング グループを解除することはできますが、解除した場合は異なるルーティング グループへのルーティング グループ コネクタを確立する必要があります。図 3 では、Miami North ルーティング グループのブリッジヘッド サーバーへのルーティング グループ コネクタを構成しました。
図 3 ルーティング グループ コネクタの構成
図 3 ルーティング グループ コネクタの構成 (画像を縮小するには、ここをクリックします)
図 3 ルーティング グループ コネクタの構成
図 3 ルーティング グループ コネクタの構成 (画像を拡大するには、ここをクリックします)
次に LA East ルーティング グループを Exchange 2007 に移行しましょう。この状況でルーティングを維持するには、少し注意が必要です。図 4 では、Exchange 2007 が Los Angeles サイトにインストールされ、2 番目のルーティング グループが解除されていますが、追加のルーティング グループ コネクタは作成されていません。
図 4 Los Angeles サイトにインストールされた Exchange 2007
図 4 Los Angeles サイトにインストールされた Exchange 2007 (画像を縮小するには、ここをクリックします)
図 4 Los Angeles サイトにインストールされた Exchange 2007
図 4 Los Angeles サイトにインストールされた Exchange 2007 (画像を拡大するには、ここをクリックします)
メッセージが Los Angeles サイトの Exchange 2007 サーバーから LA West ルーティング グループの Exchange 2003 サーバーに送信された場合、このメッセージは Acapulco、Miami North、Miami South の順に中継され、ようやく LA West に到達します。また、メッセージが LA West ルーティング グループの Exchange 2003 サーバーから Los Angeles サイトの Exchange 2007 サーバーに送信された場合、このメッセージは Miami South、Miami North、Acapulco の順に中継され、ようやく Los Angeles に戻ってきます。何ということでしょう。
この状況を回避するには、2 番目のルーティング グループ コネクタを追加する必要があります。図 5 は、Los Angeles サイトに追加された、LA West から Exchange 2007 サーバーまでのルーティング グループ コネクタを示しています。注 : ルーティング グループ コネクタをあまり増やしたくない場合は、ハブで適切に接続された Active Directory サイト内で最初のルーティング グループ コネクタが構成されていることを確認してください。
図 5 より効率的なルーティング
図 5 より効率的なルーティング (画像を縮小するには、ここをクリックします)
図 5 より効率的なルーティング
図 5 より効率的なルーティング (画像を拡大するには、ここをクリックします)
これにより、すぐには明らかにならないかもしれませんが、問題が発生します。現在、Exchange 2007 ルーティング グループの中継元と中継先は複数存在します。Exchange 2007 ルーティング グループはリンク状態を使用しないので、ルーティングのループが発生する可能性があります。Exchange 2003 サーバーは利用できないコネクタに近い別のルートを選択する場合がありますが、Exchange 2007 は常に最小コストのルートを選択します。この問題を回避するには、重要でないリンク状態更新メッセージを抑制します。これにより、コネクタが利用できないことを通知するリンク状態メッセージを受信せず、構成が変更されたことを通知するリンク状態メッセージを受信することができます。ここでの目的は、Exchange 2003 サーバーに新しいルーティング グループ コネクタについて通知することに加えて、これらのサーバーで別のルートの計算が試行されないようにすることなので、この動作は重要です。この結果、Exchange 2003 サーバーは Exchange 2007 サーバーと同じ単一障害点でのキュー登録動作を行います。
図 6 では、さらに多くの Exchange 2003 リソースを Exchange 2007 に移行しました。リンク状態更新が抑制されているので、論理ルーティング パスを維持するルーティング グループ コネクタを注意深く確立しました。
図 6 Exchange 2007 に移行された多くの Exchange 2003 リソース
図 6 Exchange 2007 に移行された多くの Exchange 2003 リソース (画像を縮小するには、ここをクリックします)
図 6 Exchange 2007 に移行された多くの Exchange 2003 リソース
図 6 Exchange 2007 に移行された多くの Exchange 2003 リソース (画像を拡大するには、ここをクリックします)
また別の問題が発生しました。Redmond と Vancouver にリンク状態の離れ小島ができてしまいました。メールは Miami を経由すれば正常に送信先に到達しますが、Redmond と Miami がリンク状態の構成の変更を通知する手段がありません。現在のルーティング テーブルを維持するには、Redmond と Vancouver の間に別のルーティング グループ コネクタを構成する必要があります。このルーティング グループ コネクタのコストを調整することにより、Exchange 2003 がその接続上でルーティングは実行できなくても、リンク状態の構成が変更された場合はその変更を通知できるようにします。
注意深く計画を立てることにより、2 つの異なる Exchange ルーティング トポロジを維持することによって発生する可能性がある問題を回避できます。最もシームレスに移行を行うには、Exchange 2007 サーバーのみが実行されている間に、ルーティング グループを 1 つずつ移行します。
ここまで、Exchange 2007 のルーティングに関する変更点と、それらが移行に与える影響について説明してきました。Exchange 2007 への移行を計画する際の考慮事項は、他にもいくつかあります。
Exchange 2003 フロントエンド サーバーは、Exchange 2007 メールボックスにはアクセスできません。ただし、Exchange 2007 クライアント アクセス サーバーからは、問題なく Exchange 2003 メールボックスに接続できます。Exchange 2007 クライアント アクセス サーバーを使用した場合、単純にメールボックスが格納されているメールボックス サーバーと同じバージョンの OWA が表示されます。別のハードウェアに Exchange 2007 を展開している場合は、クライアント アクセス サーバーが Active Directory サイトに導入される最初の役割になります。メールボックスへのパブリック インターネット アクセスを提供する Exchange 2003 フロントエンド サーバーは、メールボックスを Exchange 2007 に移行する前に Exchange 2007 クライアント アクセス サーバーに置き換える必要があります。
MAPI 以外のクライアント (OWA は最近では不可欠になってきました) が存在する場合、メールボックス サーバーの役割を含むサイトには、それぞれクライアント アクセス サーバーの役割とハブ トランスポート サーバーも必要であることを説明しました。サーバーの役割間でハードウェアを共有する場合、選択する役割にはクライアント アクセス サーバーを含めるようにしてください。通常のインストールには、ハブ トランスポート サーバーの役割、クライアント アクセス サーバーの役割、およびメールボックス サーバーの役割が含まれます。これらはすべて、Exchange 環境が完全に機能するために必要な役割です。
移行プロセスに関するもう 1 つの考慮事項は、クライアント アプリケーション (Outlook) をアップグレードするタイミングです。クライアントを Outlook 2007 にアップグレードするまで、強化された不在時メッセージの設定やメールボックスの管理フォルダ機能など、Exchange 2007 サーバーのすべての機能を最大限に活用することはできません。
また、エッジ トランスポート サーバーの役割を展開するタイミングも決定する必要があります。技術的には、他の Exchange 2007 サーバーの役割を導入する前または導入した後に、現在の境界ネットワークの SMTP リレー ホストとスマート ホストをエッジ トランスポート サーバーに置き換えることは可能です。ただし、エッジ トランスポート サーバーを最初に展開した場合、Exchange 2003 がエッジ トランスポート サーバーに必要な受信者データと構成データを Active Directory から ADAM (Active Directory Application Mode) にレプリケートする方法がなくなるので、全体的な機能が制限されます。
1 つ以上のハブ トランスポート サーバーをインストールした後、境界ネットワークにエッジ トランスポート サーバーを展開してから、ハブ トランスポート サーバーがある Active Directory サイトをエッジ トランスポート サーバーが購読するように設定できます。ハブ トランスポート サーバーの EdgeSync サービスにより、Active Directory の受信者データのサブセットが ADAM にレプリケートされます。
このデータにより、エッジ トランスポート サーバーで受信者参照とセーフリスト集約を実行できるので、エッジ トランスポート サーバーで実行されているスパム対策エージェントを最大限に活用できるようになります。また EdgeSync により、Exchange 組織とインターネットとの間のエンドツーエンドのメール フローに必要な送信コネクタが作成されます。これにより、外部アドレス空間へのルーティングを提供する Exchange 2003 SMTP コネクタの置換プロセスが簡略化されます。
Exchange 2007 への移行計画に少し時間を割けば、簡単な方法が見つかり、問題を回避することができます。

Kate Follis は、Exchange 2007 テクニカル ライティング チームのシニア コンテンツ パブリッシャです。彼女のグループは、エッジ トランスポート サーバーの役割とハブ トランスポート サーバーの役割を専門に扱っています。Kate は、マイクロソフトに勤務する前の数年間マイクロソフト認定トレーナーとして Exchange と Active Directory について教えていました。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Exchange Server 2007: Exchange 管理シェルでのコマンドの実行
Exchange Server 2007 David Strome

Exchange 管理シェルでのコマンドの実行
概要:
  • Exchange 管理シェルのしくみ
  • コマンドレットの使用法
  • コマンドレットとコマンドの比較

Exchange 環境を管理する場合、次期 Exchange Server 2007 には Exchange 管理シェルと呼ばれる新しいコマンドライン インターフェイスが含まれていることを耳にしていると思います。
Exchange 管理シェルは Microsoft Windows PowerShell テクノロジを基盤として構築され、Exchange Server 2007 のすべての側面をコマンド ラインから管理するために使用できる、強力な管理インターフェイスです。ここでは、コマンド ラインから、Exchange 管理シェルと直接対話操作を実行したり、自動化のためのスクリプトを記述したり、アプリケーションを基になるエンジンと統合したりできます。図 1 に、Exchange 管理シェルの実際の使用例を示します。
図 1 Exchange 管理シェル
図 1 Exchange 管理シェル (画像を縮小するには、ここをクリックします)
図 1 Exchange 管理シェル
図 1 Exchange 管理シェル (画像を拡大するには、ここをクリックします)
Exchange 管理コンソールでは、操作の実行に Exchange 管理シェルを使用するだけではありません。ウィザードを使用して、実行するコマンドを示すこともできます。ウィザードで作成したコマンドをコピーして、コマンド ラインまたはスクリプトに直接貼り付けます。パラメータを自由に変更した後、WhatIf パラメータを使用してスクリプトまたはコマンドをテストします。これにより、環境に変更を加える前に結果を表示することができます。
Exchange 管理シェルでは、現在のスクリプト ソリューションに統合される堅牢で柔軟性のあるスクリプト プラットフォームが提供されます。また、COM や Windows Management Instrumentation (WMI) などのデータ ソースとネイティブに通信することができます。Exchange 管理シェルは .NET Framework に基づいており、コマンドレット (Exchange 管理シェル内の機能の最小単位) を使用して、テキスト形式ではなく構造化されたデータを受け取って返します。コマンドレットの詳細については、この後すぐに説明します。

Windows PowerShell スナップイン
Exchange 管理シェルを理解するには、まず、Exchange 管理シェルが Windows PowerShell™ にどのように関連しているかを調べます。Windows PowerShell は、.NET Framework に基づいた、強力で柔軟性のある新しいコマンドライン インターフェイスです。Windows PowerShell は、他のシェルの最も優れたいくつかの機能と組み合わせたもので、新しい機能も数多く追加されています。Windows PowerShell は、他のアプリケーションのホストになるようにデザインされています。これは、Microsoft 管理コンソール (MMC) が、アプリケーションと共に提供されるさまざまなスナップインのホストとして動作するのと同じです。Exchange 管理シェルは、Windows PowerShell の最初のスナップインとしてリリースされます。
スナップインとは、アプリケーションや主要コンポーネントの管理に使用するコマンドレットの集まりです。スナップインは、最初に読み込んでおかないと使用できません。さいわい、Exchange 管理シェル スナップインは、きわめて簡単に起動できます。ただし、起動方法を説明する前に、Exchange 管理シェルを使用する際に理解しておく必要がある主要概念を説明します。
コマンドレット : コマンドレットは、他のシェル内の組み込みコマンド (cmd.exe の dir コマンドなど) に似ています。これらの一般的なコマンドと同様に、コマンドレットは Exchange 管理シェル内のコマンド ラインから直接呼び出すことができ、個別のプロセスとしてではなく、シェルのコンテキストで実行されます。他のシェル内のコマンドとは異なり、コマンドレットには動詞と名詞を組み合わせたわかりやすい名前が付けられています。動詞の部分はコマンドレットが実行する処理を表し、名詞の部分は処理の対象となるコンポーネントまたは機能を表します。
これにより、各コマンドレットがどのような処理を行うかに悩む必要がありません。Move-Mailbox コマンドレットを見れば、これが何に使用されるか正確にわかります。
通常のコマンドとコマンドレットの違いについては、Windows® SDK の Windows PowerShell セクションにある補足記事の「Cmdlets vs. Commands」(windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx) (英語) を参照してください。
Identity パラメータと位置パラメータ : Identity パラメータは、ほとんどの Exchange 関連のコマンドレットで使用できます。このパラメータを使用すると、Exchange Server 2007 の特定のオブジェクトを表す一意識別子にアクセスできます。これにより、最適な一意値を使用して、特定の Exchange オブジェクトに対する処理を実行できます。
Identity パラメータは、他のパラメータからの値のコレクションです。これらの値はオブジェクト セットの中で一意であることが保証されています。ユーザーは、Name や DistriguishedName など、他のパラメータの値を指定できます。または、GUID のようにシステム生成の値にすることもできます。使用する追加パラメータ (該当する場合) およびその設定方法は、参照するオブジェクトによって異なります。
また、Identity パラメータは、位置パラメータとも考えられます。位置パラメータとは、パラメータの名前を指定しないで値を指定できるパラメータです。Parameter Position 属性が整数の場合、パラメータは位置パラメータです。この整数は、コマンドレットがパラメータの値を見つけることができるコマンド ライン上の位置を示します。Identity は、先頭位置 0 に存在する位置パラメータなので、この位置に入力されるパラメータ名なしのすべての値は、Identity パラメータの値と見なされます。これにより、コマンドを入力するときにキー入力の回数が減ります。たとえば、次のような記述があるとします。
Get-Mailbox –Identity "Kim Akers"
これは、次のように記述しても、同じ処理が実行されます。
Get-Mailbox "Kim Akers"
パイプライン処理 : Exchange 管理シェルのパイプライン処理とは、あるコマンドレットで操作を実行するときに、別のコマンドレットの出力を使用することです。パイプライン処理は、パイプ記号 "|" を使用して実現します。同じ名詞コマンドレット セットのすべての動詞は、別のコマンドからパイプライン処理をとおして渡された情報を使用できます。一部の名詞コマンドレット セットでは、パイプラインをとおして別の名詞コマンドレット セットにデータを渡すこともできます。
パイプライン処理を使用して 2 つ以上のコマンドレットの操作を結合すると、小さなコンポーネントを組み合わせることで、より強力な処理を実行できます。たとえば、あるコマンドレットを使用してデータを収集します。次に、そのデータを 2 番目のコマンドレットに渡し、データにフィルタを適用してサブセットに分類します。さらに、そのデータを 3 番目のコマンドレットに渡してサブセットのみを処理します。

Exchange 管理シェルの起動
シェルを読み込む最も簡単な方法は、[スタート] ボタンをクリックし、[プログラム] をポイントして、[Microsoft Exchange Server 2007]、[Exchange 管理シェル] の順にクリックする方法です。
Exchange 管理シェル スナップインを読み込む 2 つ目の方法は、Windows PowerShell セッションから手動で行う方法です。[スタート] ボタンをクリックし、[プログラム] をポイントします。次に、[Windows PowerShell] をクリックします。起動したら、次のコマンドを実行して Exchange 管理シェルを読み込みます。
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
[プログラム] メニューのエントリを使用して Exchange 管理シェル スナップインを読み込む方法は、Add-PSSnapin コマンドレットを使用してこのスナップインを手動で起動する方法とはやや異なります。[プログラム] メニューのエントリを使用するときは、Exchange 管理シェル スナップインを読み込むだけでなく、Windows PowerShell スクリプトを実行してカスタマイズされた Exchange 管理環境が設定されます。Exchange 管理シェルを手動で読み込んだ後に同様の管理環境を設定する場合は、インストールされた Exchange の bin ディレクトリ (C:\Program Files\Microsoft\Exchange Server\Bin など) に変更を加えてください。その後、次のコマンドを実行します。
.\Exchange.ps1
Exchange.ps1 スクリプトを見て、ニーズを満たすように Windows PowerShell 環境をカスタマイズする方法を確認してください。Exchange 管理シェルを読み込むと、図 2 のような画面が表示されます。
図 2 Exchange 管理シェルのようこそ画面
図 2 Exchange 管理シェルのようこそ画面 (画像を縮小するには、ここをクリックします)
図 2 Exchange 管理シェルのようこそ画面
図 2 Exchange 管理シェルのようこそ画面 (画像を拡大するには、ここをクリックします)

手始めに
Exchange 管理シェルにはコマンドレットが多数あるため、Get-Help コマンドレットと Exchange Server 2007 のヘルプ ファイルは貴重な資料になります。Exchange Server 2007 ヘルプ ファイルの「操作」には、ほとんどの管理作業の実行手順が記載されています。
「Get-Help」とだけ入力すると、ヘルプ項目を参照するための一般的なヘルプ情報が表示されます。特定のコマンドレットに関するヘルプを参照するには、「Get-Help」の後に情報が必要なコマンドレットを入力します。Detailed、Full、および Example の各パラメータを使用して、表示される情報を制御できます。これらのパラメータは、コマンドの最後に追加するだけです。たとえば、「Get-Help cmdlet name –Full」と入力すると、指定したコマンドレットについて提供できるすべてのヘルプ セクションを返します。
コマンドレットの 1 つまたは複数の特定のパラメータに関する情報を取得する場合は、Get-Help と共に Parameters パラメータを使用できます。つまり、Set-Mailbox コマンドレットの "quota" という語が含まれるすべてのパラメータとその説明を表示する場合は、次のコマンドを使用します。
Get-Help Set-Mailbox –Parameter *quota*
特定の役割のサーバーまたはコンポーネント機能を管理するコマンドレット、または機能の特定のスコープ全体のオブジェクトに影響するコマンドレットの一覧を表示することもできます。Get-Help コマンドレットでは、Role、Component、および Functionality の 3 つのパラメータを指定して処理を実行できます。これらのパラメータを指定して Get-Help コマンドレットを使用するときは、これらのパラメータに指定する値をワイルドカード文字 "*" で囲む必要があります。各パラメータを使用して Get-Help を呼び出す方法の例を次に示します。
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
詳細については、Exchange Server 2007 ヘルプ ファイルの「ヘルプについて」で、使用できる役割、コンポーネント、および機能の値の一覧を参照してください。

コマンド出力の書式設定
Exchange 管理シェルの既定では、出力が画面に表示されるときは、各オブジェクトに使用できるプロパティのサブセットのみが表示されます。ただし、コマンドの出力を Format-List、Format-Table、および Format-Wide の書式設定コマンドレットにパイプすることで、すべてのプロパティに簡単にアクセスできます。おそらく通常は Format-List と Format-Table を使用することになるため、これらについて具体的に説明します。
Format-List コマンドレットは、パイプラインから入力を受け取り、各オブジェクトの指定されたすべてのプロパティの一覧を縦に並べた列で出力します。Property パラメータを使用して、表示するプロパティを指定できます (Property パラメータは位置パラメータなので、パラメータ名を指定する必要はなく、値だけを指定できます)。パラメータを指定しないで Format-List コマンドレットを呼び出すと、すべてのプロパティが出力されます。このコマンドレットでは、行は切り捨てられずに、折り返されます。Format-List コマンドレットの最適な使用方法の 1 つは、コマンドレットの既定の出力を変更して、追加情報や目的を絞った情報を取得できるようにすることです。たとえば、次のように記述します。
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
図 3 に、このコマンドの出力を示します。
図 3 Format-List の出力例
図 3 Format-List の出力例 (画像を縮小するには、ここをクリックします)
図 3 Format-List の出力例
図 3 Format-List の出力例 (画像を拡大するには、ここをクリックします)
Format-Table コマンドレットでは、ラベル ヘッダーとプロパティ データの列を備えた表形式で項目が表示されます。既定では、Get-Mailbox や Get-JournalRule などの多くのコマンドレットが出力に表形式を使用します。Format-Table コマンドレットのパラメータには、Properties パラメータと GroupBy パラメータがあります。これらのパラメータは、Format-List コマンドレットの場合とまったく同じように機能します。プロパティ情報が長い行になる場合でも、行の最後が切り捨てられることなく完全に表示されるようにするには、次のように Wrap パラメータを使用します。
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
図 4 に、出力結果を示します。
図 4 Format-Table の出力例
図 4 Format-Table の出力例 (画像を縮小するには、ここをクリックします)
図 4 Format-Table の出力例
図 4 Format-Table の出力例 (画像を拡大するには、ここをクリックします)
ワイルドカード文字を使用すると、各プロパティ名を個別に入力しなくても、一致する複数のプロパティを出力できます。たとえば、次のように記述すると、"E-mail" で始まるすべてのプロパティが返されます。
Get-Mailbox | Format-List Email*

実践
これで基本的なコマンドがいくつか身に付いたので、次の例を実行してみましょう。これらの例によって、Exchange 管理シェルは強力で柔軟性が高く、実用的であることが明らかになります。
最初に試すコマンドでは、User1 ～ User10 の 10 人のユーザーを作成します。
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
これを細かく分けて考えてみましょう。コマンド 1..10 で整数 1 ～ 10 を出力し、これらの整数をパイプラインをとおして ForEach コマンドレットに渡します。ForEach コマンドレットは、受け取った値で各オブジェクトを処理し、オブジェクトごとに {} 内のコマンドを実行します。Net User コマンドでは新しいドメイン ユーザーを作成し、Enable-Mailbox コマンドレットではローカル サーバー上の "メールボックス データベース" 内に新しいメールボックスを作成します。2 つのコマンドをセミコロンで区切って、同じコマンド ラインに配置することができます。変数 $_ は、パイプライン内の現在のオブジェクトの値を含む特殊な変数です。この例では、変数 $_ にはパイプラインに現在存在する整数が含まれます。
次の例では、サーバー MBX に存在するメールボックスを表示し、各メールボックスの Name、Database、および quota の各プロパティを返すことができます。
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Get-Mailbox コマンドレットによって、Server パラメータに指定されたサーバー上にある各メールボックスが返され、各メールボックス オブジェクトの出力が Format-Table コマンドレットにパイプ出力されます。Format-Table コマンドレットの既定では、表示するプロパティを指定しないと、コマンドレットから返されるすべてのプロパティを表示します。ここでは、Name プロパティおよび Database プロパティと、文字列 "quota" が含まれるすべてのプロパティが要求されています。このコマンドの出力は 図 5 のようになります。
図 5 Get-Mailbox のコマンド出力
図 5 Get-Mailbox のコマンド出力 (画像を縮小するには、ここをクリックします)
図 5 Get-Mailbox のコマンド出力
図 5 Get-Mailbox のコマンド出力 (画像を拡大するには、ここをクリックします)
この例では、タイトルに "Manager" が含まれる、組織全体のすべてのメールが有効なユーザーに対して、送信できるクォータの制限を 600 MB に設定します。
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Get-User コマンドレットを単独で実行すると、メールが有効ではないユーザーを含めて、Active Directory 内のすべてのユーザー オブジェクトが返されます。Set-Mailbox コマンドレットで使用できるユーザー オブジェクトのセットを取得するには、Get-User コマンドレットに、メールが有効なユーザーである Active Directory ユーザー オブジェクトのみを返すように指示する必要があります。RecipientTypeDetails パラメータには、Active Directory の受信者の種類を指定できます。この場合は UserMailbox を指定しています。次に、メールが有効なユーザーの中からマネージャのセットを取得する必要があります。この例では、各 Active Directory ユーザー オブジェクトの Title プロパティには値が設定されています。この値を使用して、Filter パラメータによってマネージャであるユーザーを判別できます。このパラメータでは、サーバーに、条件を満たす Active Directory オブジェクトのみを返すように指示します。これは、サーバー側のフィルタ処理と呼ばれます。オブジェクトのセットを取得したら、このセットを Set-Mailbox コマンドレットに渡します。これにより、各メールボックスの ProhibitSendQuota プロパティが 600 MB に設定されます。
次に、コマンドの結果をテストして、配布グループのメンバであるすべてのメールボックスを削除します。このコマンドは次のとおりです。
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
最初のコマンドレットでは、Fourth Year Students 配布グループのメンバである受信者オブジェクトを取得しています。次に、RecipientType が "UserMailbox" と一致する受信者オブジェクトのみが、Remove-Mailbox コマンドレットに渡されます。Remove-Mailbox コマンドレットでは、メールボックスを削除するのではなく、実行する処理と処理の対象となるオブジェクトを削除します。Get-DistributionGroupMember コマンドレットでは、"Fourth Year Students" 配布グループのメンバであるすべての受信者オブジェクトの一覧を取得します。ただし、Remove-Mailbox コマンドレットはメールが有効なユーザーにしか機能しないため、"UserMailbox" 以外の全種類の受信者を除外する必要があります。他のコマンドレットとは異なり、Get-DistributionGroupMember コマンドレットには Filter パラメータがありません。つまり、このコマンドレットではサーバー側のフィルタ処理を実行できません。(パフォーマンス上のメリットがないので) サーバー側のフィルタ処理を実行しないコマンドレットでは、Where コマンドレットを使用してクライアント側のフィルタ処理を実行できます。Where コマンドレットは、すべてのオブジェクトを取得してローカル クライアント コンピュータでフィルタ処理を実行します。Where コマンドレットでは、指定した条件に一致するオブジェクトのみを許可します。RecipientType が "UserMailbox" であるオブジェクトが、Remove-Mailbox コマンドレットに送信されます。このコマンドレットにより、Active Directory ユーザー オブジェクトが削除され、メールボックスは削除とマークされます。WhatIf パラメータを使用すると、Remove-Mailbox コマンドレットによって次のようなテキストが表示されます。
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
このコマンドによって予期する処理が実行されることに満足したら、WhatIf を使用せずに再度コマンドを実行します。動詞 Remove などが含まれる特定のコマンドレットでは、変更が加えられる前に、シェルから自動的に確認のメッセージが表示されます。各変更を続行するか、次回から確認のメッセージを表示しないようにシェルに指示するか、この後の処理をキャンセルするかを選択できます。自動的に確認のメッセージが表示されるように実装されていないコマンドレットの場合、Confirm パラメータを使用して強制的に表示されるようにできます。

まとめ
これでコマンドレットのすばらしさをわかっていただけたので、自分で実践してみて、Exchange 管理シェルと Microsoft Windows PowerShell が、どちらも今後のシステム管理作業で大いに役立つことを確かめてください。この 2 つのトピックに関する詳細については、次のリソースを参照してください。管理シェルについては、http://www.microsoft.com/technet/prodtechnol/exchange/E2k7/JA/Help/ExchHelp/726f0073-bfe5-4db0-a02b-9bb8ee16deb1.mspx?mfr=true にある Exchange Server 2007 ヘルプ ファイルを参照してください。Windows Powershell については、go.microsoft.com/fwlink/?LinkId=71134 にあるスクリプト センター (英語) を参照してください。また、msexchangeteam.com にある Exchange チームのブログ (英語) も参照してください。

David Strome は、マイクロソフトの Exchange User Education グループのテクニカル ライターになって 1 年余りです。David は、ワシントン州レドモンドのマイクロソフトに勤務する前は、カナダのブリティッシュ コロンビアのさまざまな企業で、約 10 年間 Exchange Server のインストールの設計、実装、および管理に携わっていました。連絡先は dstrome@microsoft.com (英語のみ) です。


 Exchange Server 2007: Exchange と Outlook を併用するメリット
Exchange Server 2007 Michael Khalili

Exchange と Outlook を併用するメリット
概要:
  • 設定の簡略化
  • ボイス メール、ファックス、電子メールの統合
  • 準拠用の管理フォルダ

長年にわたって、Microsoft Exchange Server と Outlook は何百万人ものユーザーに信頼性の高い電子メールを提供し、共同作業や予定表の管理を支援し、連絡先の整理を容易にしてきました。この 2 つの組み合わせでこれ以上何ができるのか疑問に思う方もいるかもしれません。
Exchange Server 2007 と Microsoft Office Outlook 2007 がまもなくリリースされます。この 2 つを併用すると、コミュニケーションとコラボレーションの分野が飛躍的に向上します。
Exchange Server 2007 と Office Outlook® 2007 によって提供される機能強化は、Outlook クライアントを起動すればすぐにわかります。以前のバージョンでは、ユーザーは Exchange メールボックス サーバーの名前を知っている必要があり、これには多くのユーザーが苦労しました。このために、頻繁にヘルプデスクに電話をしたり、初期化のための複雑なスクリプトを用意したりすることになり、効率的なメッセージング環境の実行にコストと複雑さを増大させました。Exchange の自動検出 Web サービスを使用すると、クライアントがドメインに参加していれば Outlook によって自動的にアカウントが構成されます。クライアントがドメインに参加していない場合にユーザーが入力する必要があるのは、名前、電子メール アドレス、およびパスワードだけです。それ以外は Outlook と Exchange によって割り出されます (図 1 参照)。
図 1 アカウントの設定
図 1 アカウントの設定 (画像を縮小するには、ここをクリックします)
図 1 アカウントの設定
図 1 アカウントの設定 (画像を拡大するには、ここをクリックします)
同様に、昔 (と言ってもほぼ差し支えないと思いますが) は、Outlook の初回使用時に設定が必要なだけでなく、メール サーバーが変わるたびに再構成が必要でした。メールボックスの移行が迫っているという警告の電子メールが送信されても、忙しい従業員たちは差し迫った移行に関してほとんど注意を払わず、ある朝出社してみたら Outlook からロックアウトされていた、などということが起こっていました。ここでまたヘルプデスクに電話することになるのです。これも自動検出 Web サービスによって解決されます。ユーザーのメールボックス サーバーが変更されると、Outlook は古い構成が無効になったことを認識し、自動検出 Web サービスに再び照会して、クライアントを新しいメールボックス用に再構成します。この一連のプロセスはエンド ユーザーがまったく意識することなく処理されます。

予定表を作り直す
これまでは、ほとんどの予定表ロジックは Outlook に備わっていました。会議の更新はそれぞれ個別の会議出席依頼として扱われていたので、間違った順序で通知が届く場合がありました。会議の更新が 2 件立て続けに送信され、受信者が 2 件目の更新を 1 件目より先に受け取った場合、受信者は古い情報を予定表に入れてしまう可能性があります。さらに、Smartphone や PDA を使用して Outlook の情報にアクセスすると、データを表示する方法によって空き時間情報が異なる場合がありました。
解決策は、すべての予定表ロジックを Outlook クライアントから Exchange Server 2007 に移すことでした。会議出席依頼がサーバーで受信されると、ユーザーがその予定を承諾または辞退するまで、その会議は自動的に仮の予定として予定表に配置されます。その会議の時間や場所の変更が受信されると、会議は自動的に更新され、ユーザーが誤って承諾しないように、古い出席依頼は自動的に古い情報として記録されます。適切な最新の会議だけが存在するようにするため、このロジックはすべてのクライアント (Office Outlook、Outlook Web Access、Outlook Mobile、および他のサードパーティのクライアント) で一貫したものになります。
予定表がきわめて正確なので、ユーザーの生産性を高める新しいツールの提供が可能になります。これまでは、多数の忙しい従業員のために会議を設定することは容易ではありませんでした。ユーザーは会議のための空き時間を手動で探す必要がありました。通知された複数の日にちの間をスクロールして、全出席者にとって都合のよい時間を見つけなければならなかったのです。Outlook 2007 のスケジュール アシスタントを使用すると、図 2 に示されるように、全員にとって都合のよい時間が探し出されます。必須出席者、任意出席者、および希望する部屋やリソースを入力すると、スケジュール アシスタントによって会議に最適な複数の日にちが色付きで表示されます。日にちを 1 つ選択すると、同じ構成を使用して、その日の中で最も都合のよい時間が探し出されます。
図 2 スケジュール アシスタント
図 2 スケジュール アシスタント (画像を縮小するには、ここをクリックします)
図 2 スケジュール アシスタント
図 2 スケジュール アシスタント (画像を拡大するには、ここをクリックします)
スケジュール アシスタントは、まず必須出席者、次に任意出席者、最後に部屋やリソース、という優先順位に従って、会議に最適な時間を決定します。スケジュール アシスタントを使用すると、フレックス タイム制や異なるタイム ゾーンなどの問題の処理も簡単になります。ユーザーは、毎朝の出社時間と一日の終わりの退社時間を決めて、自分の勤務時間を個別に設定することができます。したがって、午前 9 時や 10 時まで出社しない朝寝坊の人は、この時刻が自分の勤務開始時間になるように設定することができます。他のユーザーが会議のスケジュールを設定する場合に、午前 8 時などの早めの時刻は候補に挙がらなくなります。2 つの異なるタイム ゾーンのグループ (たとえばロンドンのグループとロサンゼルスのグループ) が会議をする必要がある場合、両グループの勤務時間の中で、重なる時間帯だけが候補として挙げられます。どちらかのグループは会議の時間が午前 2 時になるなどということなく、ロンドンのユーザーは午後遅くに、ロサンゼルスのユーザーは朝一番に会議をすることになります。

干し草の山の中から針を探す
平均的なユーザーの受信トレイに届く電子メール メッセージの数は、年々、驚くべきペースで増加しています。かつては、一般的な職場のメールボックスに格納されているメッセージは数百ほどでしたが、今では 1 日でそれと同数のメッセージが届くユーザーもいます。ビジネスの運営にとって重大な多くの情報が、この膨大なメッセージに埋もれてしまいます。適切な情報を必要なときに見つけることは、かなりの難題になります。
Office Outlook 2007 と Exchange Server 2007 の検索機能は、以前のバージョンと比較して大幅に向上しました。ユーザーがキャッシュ モードの場合もオンライン モードの場合も、同じ検索アルゴリズムがメッセージに適用されます。オンライン モードの場合は、検索クエリが Exchange サーバーに送信され、Exchange サーバーで検索が実行されます。Exchange Server 2003 のインデクサよりも最高 35 倍の速度の Exchange コンテンツ インデクサを使用して、メッセージをすばやく検索、取得することが可能になります。キャッシュ モードの場合は、Windows® デスクトップ サーチ 3.0 に基づいたクイック検索が使用され、インデックス エンジンが強化されて CPU 時間が短縮されます。図 3 に示すように、検索は、件名、本文、宛先、差出人の各フィールドにある文字列だけでなく、添付ファイルにある文字列についても実行することができます。
図 3 重要な電子メール メッセージを検索する新しい方法
図 3 重要な電子メール メッセージを検索する新しい方法 (画像を縮小するには、ここをクリックします)
図 3 重要な電子メール メッセージを検索する新しい方法
図 3 重要な電子メール メッセージを検索する新しい方法 (画像を拡大するには、ここをクリックします)

ユニファイド メッセージングを使用してあらゆる場所からアクセスする
Exchange Server 2007 の組み込みコンポーネントである Exchange ユニファイド メッセージングでは、電子メール、ボイス メール、ファックスなど、ビジネス上のあらゆる種類の通信が 1 つの受信トレイに届きます。従来のシステムでは、ボイス メールを利用するには電話、電子メールを利用するにはコンピュータ、ファックスを利用するには専用のファックスが使用されています。Exchange ユニファイド メッセージングを使用すると、ユーザーは特定の時間や場所でのニーズに最適なクライアントを選択することができます。Outlook 内では、ボイス メール メッセージとファックス メッセージが、受信トレイの中で電子メール メッセージとまったく同列に表示されます。ボイス メール メッセージを選択すると、メッセージにはプレーヤーが埋め込まれており、閲覧ウィンドウから直接メッセージを再生できるようになっています (図 4 参照)。
図 4 Outlook でボイス メール メッセージを再生する
図 4 Outlook でボイス メール メッセージを再生する (画像を縮小するには、ここをクリックします)
図 4 Outlook でボイス メール メッセージを再生する
図 4 Outlook でボイス メール メッセージを再生する (画像を拡大するには、ここをクリックします)
また、Outlook では、関連付けを考慮してメッセージを処理することができます。通常、ボイス メールを聞くときは紙にメモを取ります。これらのメモはメッセージと関連付けされていないので、なくなってしまうことがあります。これでは効率的なコミュニケーションとはとても言えません。Exchange ユニファイド メッセージングを使用すると、Outlook の中で直接メモを取ることができます。メモはメッセージと共に保持され、検索可能なテキストとしてインデックスが作成されるので、常に該当するボイス メール メッセージと関連付けて表示されます。そのため、Exchange Server 2007 や Office Outlook 2007 の高度な検索を使用してすぐに見つけることができます。
また、Outlook では、多くのボイス メール オプションを管理することができます (図 5 参照)。たとえば、ユーザーはボイス メールのメールボックスの暗証番号 (PIN) をクライアントから変更できます (PIN の再設定はボイス メール システムに関するヘルプデスクへの電話の原因の多数を占めます)。Outlook のボイス メール オプションを使用すると、ユーザーは新しい PIN を生成し自分宛てに電子メールで送信することができます。この PIN を使用して Exchange ユニファイド メッセージングの電話インターフェイスである Outlook Voice Access に 1 回アクセスすることができ、そこで PIN の変更を求められます。
図 5 PIN 再設定オプションを含むユニファイド メッセージング
図 5 PIN 再設定オプションを含むユニファイド メッセージング (画像を縮小するには、ここをクリックします)
図 5 PIN 再設定オプションを含むユニファイド メッセージング
図 5 PIN 再設定オプションを含むユニファイド メッセージング (画像を拡大するには、ここをクリックします)

セキュリティの確保と保護のために
現在、企業のメッセージング環境は多くの脅威に直面しています。Outlook と Exchange は連携して、このような脅威に対処します。スパムもそんな脅威の 1 つですが、Office Outlook 2007 ではスパムへの新しい対処方法である Outlook 電子メールの消印がサポートされます。Outlook によって送信メールにちょっとした演算パズルが実行され、このパズルの解答がメッセージに付加されます。そして結果は Exchange でチェックされます。これらの演算パズルは、正当なメールが一般的にそうであるように、単発で実行された場合は CPU 時間をほとんど使いませんが、スパム送信者がコンピュータで大量の電子メールに対してこのようなパズルを作成しようとすると、コンピュータに非常に大きな負荷がかかります。したがって、Outlook 電子メールの消印が押されたメッセージは押されていないメッセージよりも正当である可能性がはるかに高く、Exchange が各電子メール メッセージの正当性を判断する際にはこれが考慮されます。
スパムのような古くからの脅威に加えて、最近の規制制度もメッセージング システムの要件を変化させています。サーベンス オクスリー法、HIPAA、バーゼル II などの法令では、記録の保持や破棄に関して厳密なルールが定められています。この新たな要求を満たすために、Exchange と Outlook では管理フォルダが導入されています。管理フォルダは管理者によって特定の種類のメッセージ用に設定されます。エンド ユーザーが Outlook を使用すると、これらのフォルダは、何が格納されるべきかについての説明付きで表示されます (図 6 参照)。Exchange のトランスポート ルールを使用して、メッセージを自動的に特定のフォルダに送信することもできます。特定の管理フォルダでメッセージがそのフォルダのアーカイブ ポリシー、保存ポリシー、および有効期限ポリシーを保持すると、それらのメッセージは自動的に組織のポリシーと整合性の取れた方法で処理されます。
図 6 電子メールの準拠規則が適用される管理フォルダ
図 6 電子メールの準拠規則が適用される管理フォルダ (画像を縮小するには、ここをクリックします)
図 6 電子メールの準拠規則が適用される管理フォルダ
図 6 電子メールの準拠規則が適用される管理フォルダ (画像を拡大するには、ここをクリックします)
どんなに注意していても、規則違反が発生してしまうことはあります。このような場合には、迅速な特定と修復が不可欠です。Exchange に用意されている高速検索は、コンプライアンス担当者が、規則違反を特定する手がかりになりうるメッセージを見つけるための非常に重要なツールとなります。このような違反を見つけ出し修正するために、メールボックス間を横断して検索を実行することができます。

より管理しやすい環境
Exchange Server 2007 と Office Outlook 2007 を併用すると、以前のバージョンよりもはるかに向上したメッセージング システムが提供されます。きわめて重要なビジネス コミュニケーションのすべてを 1 か所に集め、検索しやすく、設定しやすく、特別な設定なしでもより安全で規則に準拠したものにします。2 つを併用することで、一歩進んだコラボレーションとコミュニケーションが可能になります。

Michael Khaliliは、Exchange Server のプロダクト マネージャとして、クライアント アクセスとユニファイド メッセージングを担当しています。特に、Outlook と Exchange の統合を担当しています。


 Exchange Server 2007: Exchange Server 2007 との常時接続
Exchange Server 2007 Joshua Trupin

Exchange Server 2007 との常時接続
概要:
  • Outlook Web Access の機能強化
  • Exchange Server 2007 のユニファイド メッセージング
  • ISA Server 2006 との併用によるセキュリティ強化

数年前、オンライン通信では、基本的なことが行われていました。POP3 や SMTP を使用して電子メールを送信していました。非常にシンプルでした。けれども、ニーズは変化します。現在、組織では、従業員が
作業を行うタイミングや方法を柔軟に選択でき、作業を安全に行えるようにする必要があります。Microsoft® Exchange Server 2007 には、Microsoft Office Outlook® Web Access (OWA) やユニファイド メッセージングなど、このようなニーズに対応する組み込みの機能が用意されています。この記事では、Exchange Server 2007 の 2 つの新しい主要コンポーネントについて説明します。また、これらのコンポーネントが、今日の企業で必要とされるより強力な通信プラットフォームを作成する上で、以前のバージョンのコンポーネントと比較して、どう優れているのかについても説明します。
OWA は、Exchange Server 5.5 から Exchange Server に導入されました。正直なところ、初期のバージョンは、それほど優れたものではなく、Web ブラウザを使用して Exchange Server のメールボックスにアクセスするために導入されたコンポーネントで、Outlook の機能は、ほとんど使用しませんでした。
Exchange Server 2003 に同梱された OWA では機能が強化され、エンド ユーザーにとって物事が良い方向に進み始めました。ブラウザ ベースの操作は、クライアント プログラムを操作しているのと変わらないくらい快適になりました。Exchange Server 2007 の OWA では、以前のバージョンをまったく新しく書き直し、HTTP を経由した RPC や ASP.NET 2.0 などの他の最近の技術的な革新を元に構築したので、さらなに機能が強化されました。
たとえば、OWA による表示方法を見てみましょう。以前のバージョンの OWA は、格納プロセス中に、メールボックス サーバーによって表示されていました。そのため、メールボックス サーバーに負荷がかかり、システムの他の処理速度が低下しました。Outlook Web Access 2007 では、クライアント アクセス サーバー (CAS) 上で ASP.NET を使用してデータを表示しています。ページの処理がメールボックス サーバー以外の場所で行われるようになるため、サーバーのパフォーマンスが向上します。
フロント エンドで行われる処理も変更されました。以前のバージョンの Exchange Server では、OWA の HTTP 要求は、該当するメールボックス サーバーにプロキシ処理されていましたが、Exchange Server 2007 では、RPC 経由で適切なメールボックス サーバーからデータを直接取得することによって、OWA に関連するトラフィックを軽減しています。これは、企業ネットワークへの仮想プライベート ネットワーク (VPN) 接続を使用していないクライアントで Outlook を使用できるようにする処理と基本的に同じ処理です。このように取得されたデータが OWA に表示されます。Exchange Server 2007 では、OWA の要求をプロキシ処理できますが、これらの要求をメールボックス サーバーに直接送信するのではなく、他の CAS サーバーに転送します。
図 1 は、Exchange Server 2007 の OWA のアーキテクチャです。
図 1 OWA が Exchange Server のリソースにアクセスする方法
図 1 OWA が Exchange Server のリソースにアクセスする方法 (画像を縮小するには、ここをクリックします)
図 1 OWA が Exchange Server のリソースにアクセスする方法
図 1 OWA が Exchange Server のリソースにアクセスする方法 (画像を拡大するには、ここをクリックします)

管理
改良された Exchange Server 2007 のアーキテクチャでは、OWA を管理するオプションも強化されました。OWA の管理には、Exchange 管理コンソールまたは Exchange 管理シェルを使用できますが、構成設定は複数の場所に保存されます。
Exchange 管理コンソールを使用すると、ほとんどの構成設定にアクセスできます。たとえば、セグメンテーション、添付ファイルのブロック、認証などを使用する機能を有効または無効にしたり、予定表、仕事リスト、スペル チェックなどの機能にアクセスしたりすることができます。Exchange 管理コンソールを使用して行える操作は、Exchange 管理シェルのタスクを使用して行うこともできます。
Exchange 管理シェルを使用すると、OWA の新しい仮想ディレクトリを作成したり、削除したりすることができます。また、ユーザー単位で、セグメンテーションの設定を制御したり、既定の言語設定を変更したりすることができます。
既定では、フォーム ベースの認証のタイムアウト値は Windows レジストリに格納されます (タイムアウトの設定は、Exchange 管理コンソールや Exchange 管理シェルからはアクセスできません)。添付ファイルのブロックやセグメンテーションなど、OWA 固有の設定は、Active Directory® からアクセスできます。IIS メタベースには、IIS の動作に影響を及ぼす設定 (認証、GZIP) が格納され、web.config には、OWA の添付ファイルのアップロード処理を制御する ASP.NET の設定 (maxuploadsize など) が格納されています。

認証
OWA には、サーバー側の認証においていくつかの選択肢が用意されています。セットアップ完了後、セキュリティは既定でフォーム ベースの認証になります。ただし、この設定は組織のニーズに応じて強化することができます。IIS では、Active Directory に対して認証を行い、アクセスしているユーザーが適切なドメインのアクセス許可を持っていることを確認します。また、基本認証、ダイジェスト認証、RSA SecurID、または SmartCard サインインを使用して、電子メールにアクセスすることもできます。
OWA で利用できる最高レベルのセキュリティは、Kerberos と NTLM を組み合わせた Windows 統合認証です。実際、Windows 統合認証は、Outlook Web Access 2007 の Web パーツにアクセスしたり、Active Directory サイト間の CAS のプロキシ処理に必要です。また、Windows 統合認証を使用すると、イントラネットで OWA にアクセスするユーザーにもメリットがあります。信頼されているユーザーであれば、Windows クライアント認証によりシングル サインオンが実現されるので、OWA にログオンする必要がありません。
既定のフォーム ベースの認証を使用している場合、一定時間操作が行われないと、OWA は自動的にタイムアウトします。ユーザーがログイン時に共有のコンピュータまたは個人のコンピュータのどちらのオプションを選択したかによって、タイムアウトの時間は異なります。タイムアウトの時間は、共有のコンピュータであれば 15 分であったり、個人のコンピュータであれば最大 8 時間までのタイムアウトの時間が設定されていることがあります。共有のコンピュータと個人のコンピュータのどちらを選択するかによって、他のセキュリティ設定の構成方法も異なる可能性があるため、このオプションの選択は重要です。たとえば、共有のコンピュータでは添付ファイルをブロックしたり、認証のタイムアウトを変更したりすることができます。フォーム ベースの認証は、基本的に、図 2 に示すように 4 つの手順から成るプロセスです。
図 2 認証プロセス
  1. クライアントがサーバーに要求を送信します (非暗号化)。
  2. サーバーは暗号化した Cookie をクライアントに返します。
  3. サーバーでは、継続的に新しい暗号化キーを破棄して作成し、メモリには最も新しいものを 3 つ保持します。
  4. 期限が切れているが、メモリ内にある暗号化キーを使用して要求を送信したクライアントは、最新の暗号化キーで暗号化された新しい Cookie を受け取ります。
    - または -
    有効期限が切れている、破棄されてタイムアウトしている暗号化キーを使用して要求を送信したクライアントは、再度ログインする必要があります。

msExchQueryBaseDN は、特定のユーザーに対して OWA のアドレス帳のサブセクションのみが表示されるようにするためのメカニズムです。msExchQueryBaseDN は、Active Directory ユーザー オブジェクトに設定され、アドレス一覧 (AL) または組織単位 (OU) をポイントします。この AL は、ユーザーのグローバル アドレス一覧 (GAL) として使用され、ユーザーには、この OU のユーザー アカウントのみを含む GAL が表示されます。msExchQueryBaseDN は LDAP を使用して設定できます。

旧バージョンとの互換性
Exchange Server 2007 の Outlook Web Access の中核を成しているのは CAS です。この CAS モデルは、以前のバージョンの Exchange Server を実行しているサーバーとの間で最大限の相互運用性を実現することを目的に構築されています。このモデルが動作するには、CAS サーバーと関連付けられているメールボックス サーバーをアップグレードする前に、CAS サーバーを展開またはアップグレードする必要があります。
CAS の役割を持つ Exchange Server 2007 サーバーを使用して、Exchange Server 2000 および Exchange Server 2003 を実行しているサーバー上にあるメールボックスに接続することができます。HTTP を経由した RPC および Exchange ActiveSync® は、どちらも部分的なサイトのアップグレードに対応します。/exchange、/public、または /exchweb 仮想ディレクトリからアクセスすれば、OWA と WebDAV も機能します。また、Exchange Server 2007 を実行しているサーバー上には、以前のバージョンの Exchange Server 用のカスタム OWA 仮想ディレクトリを作成することもできます。

ISA Server 2006 は友達
Exchange Server 2007 の Outlook Web Access では多くの機能強化が行われましたが、Internet Security and Acceleration (ISA) Server 2006 と組み合わせて使用することで、その機能をさらに強化できます。
ISA Server 2006 は、統合エッジ セキュリティ ゲートウェイです。ISA Server はインターネットで発生する脅威からサイトを保護するのに役立つだけでなく、アプリケーションやデータへのリモート アクセスをセキュリティで保護するのにも役立ちます。これは OWA が目的としていることでもあるので、この 2 つの製品を組み合わせることによって、すべてのコンピューティング概念の相乗効果を得られます (ISA Server の詳細については、microsoft.com/japan/isaserver/prodinfo/ を参照してください)。
ISA Server 2006 には、時間のない Exchange Server の管理者に役立つ機能があります。たとえば、Web 公開負荷分散 (WPLB) 機能を使用すると、HTTP の Cookie を使用して負荷を分散することができます。クライアントの IP アドレスが変更されても、クライアントとサーバー間の関係を維持できます。ISA Server 2006 では、GZIP 形式の圧縮と展開機能が提供されるので、トラフィックを解析したり、圧縮処理の負荷を Web サーバーからオフロードしたりすることが可能になります。ISA Server 2004 では、OWA で HTTP 圧縮を使用するか、または ISA Server でフォーム ベースの認証を使用するかのいずれかを選択する必要がありました。幸い、ISA Server 2006 では、両方を同時にサポートできます。
また、ISA Server を使用すると、OWA リンクの変換を実行できます。ISA Server では、OWA 電子メールに挿入されているイントラネットのリンクを、適切なインターネット リンクに変換することができます。これは便利な機能ですが、OWA を公開している ISA Server のアレイと同じ場所にイントラネットのリンクを公開する必要があるということに注意する必要があります。
おそらく最も重要なことは、ISA Server 2006 では、ネットワークを保護するのに役立つ事前認証が境界で実行されることです。事前認証は、悪意のある HTTP トラフィックがサーバーにアクセスできないようにすることを目的としています。CAS にリダイレクトされたトラフィックが有効なトラフィックである場合、ISA Server では、そのトラフィックを境界からドメインにアクセスできるようにします (境界サーバーは、イントラネット ドメインの外側に配置されているので、ドメインに属していないトラフィックをブロックできます。CAS は、境界ドメインに配置しないでください。CAS は、イントラネット ドメインに配置して、Active Directory ユーザー アカウントにアクセスできるようにする必要があります)。

Outlook Web Access のトラブルシューティング
Outlook Web Access 2007 では、監視とトラブルシューティングを強化するための新しいツールが導入されました。CAS サーバーでは監視タスクが自動的に実行されます。監視タスクでは、各メールボックス サーバーの接続だけでなく、OWA ログオンのテストも行います。また、Exchange Server 2007 には、これまでよりも詳細なイベント ログ メッセージやパフォーマンス カウンタが用意されています。
Exchange Server のベスト プラクティス アナライザは強化され、OWA が正しく構成されていない場合には、管理者に警告やエラー メッセージが表示されるようになりました (このツールの詳細については、microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange (英語) を参照してください)。LogParser ツールを使用して IIS ログから OWA の使用状況レポートを生成することもできます (このツールの詳細については、microsoft.com/technet/technetmag/issues/2006/10/LogParser (英語) を参照してください)。

ユニファイド メッセージング
OWA ではモバイル ビジネスのニーズに対応していますが、ユニファイド メッセージングでは、1 つの場所にさまざまな形式のメッセージを統合します (そのため、このような名前が付けられています)。現在、電子メールは Exchange Server 上に格納され、ボイス (電話やボイス メール) はテレフォニー サーバーで利用できます。電子メールはデスクトップで受信し、ボイス メールは電話を使用して受け取ります。読者の皆さんが言わんとしていることはわかっていますが、FAX メッセージについての説明は割愛させてください。
Exchange Server 2007 のユニファイド メッセージングを使用すると、組織では、ユーザーが Outlook や OWA を使用してアクセスできる 1 つの受信トレイに電子メール、ボイス メール、および FAX データを配信することが可能になります。ユニファイド メッセージングは、逆の用途にも使用できます。つまり、ユーザーは、Outlook Voice Access を使用し、電話でボイス メール、電子メール、連絡先、および予定表にアクセスすることができます。
システム管理者にとってのメリットは、ユニファイド メッセージングを使用すると、Exchange Server とテレフォニー サーバーのインフラストラクチャを組み合わせて、単一のストア ソリューション、単一のディレクトリ、および単一のトランスポートが提供されるので、メッセージングが簡略化されることです。各ユーザーのメールボックスが 1 つになれば、全体的な複雑さのレベルが低くなります。
最も優れている点は、既存のサーバーにも使用できることです。また、Exchange Server 2007 とテレフォニーについての知識があれば、それほど多くのことを習得する必要はありません。ユニファイド メッセージングの機能は Exchange Server に統合されているので、使用するセキュリティ モデルと受信トレイは同じです。また、OWA を使用してボイス メールや FAX データにアクセスすることもできます。
図 3 は、ユニファイド メッセージング サーバーの役割がインストールされた Exchange Server 2007 環境におけるユニファイド メッセージングのアーキテクチャを示します。後で簡単なテストを行うかもしれないので、この図をよく見ておいてください。今度は、ユニファイド メッセージングのアーキテクチャについて、もう少し詳しく説明しましょう。
図 3 ユニファイド メッセージングによるボイス、FAX、および電子メールによる通信の統合
図 3 ユニファイド メッセージングによるボイス、FAX、および電子メールによる通信の統合 (画像を縮小するには、ここをクリックします)
図 3 ユニファイド メッセージングによるボイス、FAX、および電子メールによる通信の統合
図 3 ユニファイド メッセージングによるボイス、FAX、および電子メールによる通信の統合 (画像を拡大するには、ここをクリックします)
企業でユニファイド メッセージングを設定する場合には、把握しておく必要のある要素があります。Exchange Server には、テレフォニー ハードウェアを表すオブジェクトが含まれています。これらのオブジェクトでは、Exchange Server 環境内における関係を定義できます。Exchange Server のユニファイド メッセージングのシステム オブジェクトには、UM Server、UM Dial Plan、UM IP Gateway、UM Hunt Group、UM Mailbox Policy、および UM Auto Attendant があります。これらのオブジェクトの役割を説明しましょう。
UM Server オブジェクトは、UM の役割がインストールされている Active Directory に作成されます。このオブジェクトにより、管理コントロールで、Exchange Server 2007 のユニファイド メッセージング展開のセットアップとプロパティを制御できます。UM Dial Plan は、ユニファイド メッセージングの基本的な管理単位で、内部で拡張機能がどのように使用されるのかを表します。UM Dial Plan に含まれるすべてのユーザーは、内線番号を使用して他のユーザーにアクセスできます。他の場所を結合している場合は、通常、各場所ごとに独自の UM Dial Plan を使用します。
UM IP Gateway オブジェクトは、物理的なボイスオーバー IP (VoIP) ゲートウェイまたはセッション開始プロトコル (SIP) 対応の IP Private Branch Exchange (PBX) を表します。ユニファイド メッセージング サーバーでは、IP または VoIP ゲートウェイ デバイスからの呼び出しを受け取ることができます。UM Hunt Group では、UM IP Gateway を UM Dial Plan にリンクします。PBX で UM Hunt Group が構成されると、このこのオブジェクトを表す UM Hunt Group が Active Directory に作成されます。UM Hunt Group を構成して、IP ゲートウェイの負荷分散を行うことができます。これらのゲートウェイでは、単一の UM Hunt Group を複数のゲートウェイと関連付けることによって負荷分散を実現します。UM Mailbox Policy は、ボイス メールの Classes of Service と似ています。このオブジェクトには、UM Dial Plan およびユーザーとグループの運用ポリシーを設定するプロパティが含まれます。
UM Auto Attendant は、単一の UM Dial Plan と関連付けられます。このオブジェクトはカスタマイズして複数のタスクを実行することができます。たとえば、日時指定でタスクを記録したり、定義したりするカスタム プロンプトを実行できます。UM Auto Attendant は、アドレスの一覧を使用してスコープを設定できます。
図 4 は、これらの 6 つのユニファイド メッセージング オブジェクトが、どのように連動するのかを示しています。
図 4 ユニファイド メッセージング テレフォニー オブジェクトの対話
図 4 ユニファイド メッセージング テレフォニー オブジェクトの対話 (画像を縮小するには、ここをクリックします)
図 4 ユニファイド メッセージング テレフォニー オブジェクトの対話
図 4 ユニファイド メッセージング テレフォニー オブジェクトの対話 (画像を拡大するには、ここをクリックします)

セットアップ
ユーザーが Exchange Server 2007 のメールボックスを設定したら、管理者は、そのメールボックスのユニファイド メッセージングを有効にする必要があります。これを行うには、管理者が、UM Dial Plan でメールボックスを UM Mailbox Policy と内線番号の両方と関連付ける必要があります。PBX は、ユニファイド メッセージングへの呼び出しを RNA (ring, no answer) でルーティングするように構成する必要があります。PBX では、まず、ユーザーの内線に呼び出しをルーティングします。RNA が発生すると、呼び出しは VoIP ゲートウェイにルーティングされ、その後、ユニファイド メッセージング サーバーにルーティングされます。
ユニファイド メッセージングはスケーラブルです。回線交換を行っている PBX チャネルとユニファイド メッセージング サーバーは必要な数だけ追加して、処理能力を上げることができます。VoIP ゲートウェイを使用すると、IP ベースの呼び出しはユニファイド メッセージング サーバーに配信されます。これは、多くの企業にとって新しい機能であるため、ネットワークの詳細な分析を行い、IP ネットワークがデータとボイスの両方に対応できる帯域幅を備えていることを確認する必要があります。
一般的な Exchange Server 2007 のユニファイド メッセージング サーバーでは、同時に 50 ～ 200 の IP 呼び出しと、最大で 200 の着信ボイスと FAX 呼び出しを処理できます (着信ボイスと FAX 呼び出しの既定値は 100 です)。これよりも多くの処理量に対応する必要がある場合、またはフォールト トレランスを強化する場合は、追加のユニファイド メッセージング サーバーを構築できます。

まとめ
これで、Exchange Server 2007 で提供される Outlook Web Access とユニファイド メッセージングの概要の説明は終わりです。組織では、これらの機能を組み合わせて使用すると大きなメリットを得られます。Outlook Web Access を使用すると、どこからでも安全に電子メールにアクセスできます。また、ユニファイド メッセージングを使用すると、電子メール、ボイス メール、FAX メッセージ、および他のデータを Exchange Server 2007 のメールボックスに配信して、1 つの場所で通信データを管理できるようになります。

Joshua Trupin MSDN Magazine と TechNet Magazine の編集主幹です。彼は、MSJ、MIND、MSDN Magazine、および TechNet Magazine などで多数の記事を執筆しています。また、彼の著書には、『Hoop Stats: The Basketball Abstract』(英語) があります。


 Exchange Server 2007: Exchange 2007 の強力なジャーナリング
Exchange Server 2007 David Strome

Exchange 2007 の強力なジャーナリング
概要:
  • Exchange Server 2007 のジャーナル ルール
  • ジャーナル ルールの新規作成ウィザード
  • ジャーナル レポートの内容

あるユーザーとの間で送受信した電子メール メッセージのジャーナルの作成が必要になり、検索対象のメールボックスだけでなく、そのメールボックス ストアにある他の 300 ものメール ボックスからメッセージを探すことになったことはありますか。
Microsoft Exchange Server 2007 ではこのような問題が解決され、必要な制御をきめ細かに行うことができます。
エンタープライズ クライアント アクセス ライセンス (CAL) により、受信者ごとのジャーナリングが利用できるようになり、ジャーナルの作成対象ユーザーを指定できます。ジャーナル ルールを使用すれば、ジャーナルを作成する受信者と送信者のみを対象に指定できるようになりました。たとえば、1 つのメールボックスに絞り込んだり、販売部門のすべての担当者に範囲を拡張したりできます。このとき、指定する担当者のメールボックスが、同じサーバー、同じ Active Directory® サイト、さらには同じ Exchange 組織にさえ含まれる必要はありません。Active Directory のレプリケーションにより、組織内でハブ トランスポート サーバーの役割を実行しているすべてのコンピュータに、変更が自動的に適用されます。

ジャーナリングのしくみ
Exchange Server 2003 では、ジャーナリングが各物理サーバーの個々のメールボックス ストアに実装されていました。組織内のすべてのメールボックスのジャーナルを作成する場合は、各メールボックス ストアでジャーナリングを構成する必要がありました。また、1 人の受信者のメッセージのジャーナルを作成する場合は、そのユーザーのメールボックス ストアに含まれるすべてのユーザーのジャーナルを作成するか、そのユーザー専用に新しいメールボックスを作成する必要がありました。
Exchange Server 2007 のジャーナリングでは、Exchange の新しい役割ベースのトポロジが使用されるようになります。図 1 に示すように、メールボックスとユニファイド メッセージング サーバー、その他の Exchange システム、サード パーティのアプリケーション、およびインターネットからメッセージを送受信するとき、すべてのメッセージがハブ トランスポート サーバーによって処理されます。すべてのハブ トランスポート サーバーには、メッセージにジャーナル ルールを適用する役割がある、ジャーナリング エージェントと呼ばれるトランスポート エージェントがあります。このジャーナリング エージェントがハブ トランスポート サーバーに配置されるため、メッセージが受信者に届く前に、このエージェントですべてのメッセージを見つけて評価します。ジャーナリング エージェントは、分類後のメッセージに対して操作を行います。これにより、確実にすべてのメッセージの受信者および送信者の属性にアクセスし、メッセージが受信者に直接送信されたかどうか、または配布グループの展開によって受信されたかどうかをエージェントで判断できます。Exchange Server 2007 の組織内から送信されたメッセージでは、受信者が To、Cc、または Bcc のどの行に含まれていたかもわかります。
図 1 ハブ トランスポート サーバーのメール フロー
図 1 ハブ トランスポート サーバーのメール フロー (画像を縮小するには、ここをクリックします)
図 1 ハブ トランスポート サーバーのメール フロー
図 1 ハブ トランスポート サーバーのメール フロー (画像を拡大するには、ここをクリックします)
ジャーナリング エージェントでは、メッセージがハブ トランスポート サーバー経由で移動するため、管理者が構成したジャーナル ルールがメッセージに適用されます。これらのルールにより、エージェントがメッセージに関する情報をキャプチャして、この情報を元のメッセージと共にジャーナル メールボックスに転送するかどうかが決まります。このデータは、ジャーナル レポートと呼ばれるメッセージで送信されます。
以前のバージョンの Exchange では、複数のサーバーに構成を適用する必要がありました。しかし、Exchange Server 2007 でジャーナル ルールを作成すると、その変更は Active Directory を経由して、組織内のすべてのハブ トランスポート サーバーに適用されます。すべてのハブ トランスポート サーバー、つまりすべてのジャーナリング エージェントは、Active Directory から同じ構成を読み取ります。したがって、このように完全に同じ構成を使用することで、すべてのジャーナリング エージェントで同じジャーナリング構成が確実に適用されます。
組織全体に構成の変更をレプリケートし、ハブ トランスポート サーバーで読み取りを行う必要があるため、ジャーナル ルールを作成または変更するときは、Active Directory のレプリケーション時間を考慮してください。レプリケーションには数時間かかる可能性があります。ジャーナリング構成が更新されるタイミングを特定できるように、Exchange では各サーバーのセキュリティ イベント ログにイベントを記録します。
Exchange Server 2007 では、ジャーナル メールボックスが使用できない、いっぱい、正しく構成されていない、オフラインなどの理由で、ジャーナル レポートが失われることはありません (メッセージが失われることは要件に準拠していないことになるので、このことはさまざまな法律上や規則上の要件を満たす場合に特に役立ちます)。ジャーナル レポートをジャーナル メールボックスに配信できない場合は、ジャーナル メールボックスが使用できるようになるまで、このレポートはハブ トランスポート サーバーのキューに残ります。これにより急速にキューが増加する可能性があるので、ジャーナル メールボックスの可用性を監視して、正しく操作が行われることを確認します。ジャーナル メールボックスが長時間にわたって使用できないままになる場合は、代わりのジャーナル メールボックスを構成して、キューに登録されているレポートを受信できます。

ジャーナル作成内容の決定
ジャーナル ルールの作成を開始する前に、対象とするユーザーと、ジャーナルを作成するデータの種類を明確に決める必要があります。ジャーナル ルールでユーザーを指定することで、ジャーナルを作成する特定のユーザーを選択できます。たとえば、こうしたユーザーは規制要件の制約を受けたり、電子メール メッセージやその他の通信を証拠として収集する必要がある法的手続きに関係している場合があります。
ジャーナルを作成する受信者の指定に加えて、Internal、External、および Global のオプションを使用して、ジャーナルを作成するメッセージのスコープを決定することもできます。Internal は組織内のメッセージのみを対象としますが、External は送信者または受信者の 1 人が組織外のメッセージを対象とします。Global は、組織内外両方のメッセージを対象とします (Global オプションではハブ トランスポート サーバーを経由するすべてのメッセージのジャーナルを作成します。このとき、Internal スコープと External スコープを使用するルールで既に処理されたメッセージのジャーナルも作成することに注意してください)。
Exchange Server 2007 ではユニファイド メッセージングがサポートされているため、ユーザーの受信トレイですべての電子メール、ボイスメール、およびファックスを収集するように Exchange を構成できます。つまり、このすべてのデータのジャーナルを作成したり、特定のデータを除外するように選択することもできます。
標準の CAL で Echange Server 2007 を実行している場合でも、メールボックス ストアごとのジャーナリングを使用できます。ただし、新しい受信者ごとのジャーナリング機能を使用する場合は、Exchange Server 2007 のエンタープライズ CAL にアップグレードする必要があります。

ジャーナル メールボックスの配置場所
ジャーナルの作成対象を決定したら、ジャーナル レポートの送信先を決定する必要があります。複数のサイトがある場合にジャーナル メールボックスの配置先を決定するときは、現在のネットワーク トポロジまたは計画しているネットワーク トポロジを考慮する必要があります。組織の規模とメールボックスの数によって異なりますが、ジャーナリングを行うと反復的なレポートが大量に作成される可能性があります。
ただし、配置先を Exchange のメールボックスにこだわる必要はありません。ジャーナル レポートは、任意の有効な SMTP アドレスに送信できます。このアドレスでは、Exchange Hosted Services、サード パーティのアーカイブ ソリューションを指すか、配布グループを使用してこれらのすべての組み合わせを指すことができます。ただし、ジャーナル レポートの送信先にはそれぞれ一定のセキュリティが関係してくることに注意してください。
ジャーナル メールボックスの配置先に関係なく、Active Directory 内にメールボックス用の受信者オブジェクトを作成する必要があります。このオブジェクトは、Exchange Server 2007 メールボックス、メールを Exchange Hosted Services やサード パーティのアーカイブ ソリューションにリダイレクトするメールが有効な連絡先、またはメールボックスと連絡先の両方を含む配布リストにすることができます。

ジャーナル レポートの内容
ジャーナリング エージェントでは、メッセージのジャーナルを作成するときに、ジャーナル レポート内の元のメッセージについてできるだけ詳細にキャプチャを試みます。その後、このレポートがジャーナル メールボックスに送信されます。この情報は、メッセージの目的、メッセージの受信者、およびメッセージの送信者を判断するために非常に重要です。たとえば、受信者が識別される場所 (To フィールドに直接アドレスが入力されているか、Cc フィールドに含まれているか、単に配布リストの一部に含まれているか) は、受信者がメッセージの内容にどの程度かかわっているかを判断するのに役立ちます。元のメッセージは、添付ファイルとして含まれます。図 2 のスクリーンショットは、david@contoso.com に送信されたメッセージが christine@contoso.com に転送されたことを示すジャーナル レポートと、Sales_Group@contoso.com 配布グループに送信されたメッセージが展開され、Sales Group 配布グループのメンバである受信者 lukas@contoso.com がメッセージを受信したことを示すもう 1 つのジャーナル レポートを示しています。両方のレポートには元のメッセージが添付ファイルとして含まれており、元の送信者は brian@contoso.com で、"Sales forecast" という件名が付いています。
図 2 転送された受信者と展開された配布グループの受信者を示すジャーナル レポート
図 2 転送された受信者と展開された配布グループの受信者を示すジャーナル レポート (画像を縮小するには、ここをクリックします)
図 2 転送された受信者と展開された配布グループの受信者を示すジャーナル レポート
図 2 転送された受信者と展開された配布グループの受信者を示すジャーナル レポート (画像を拡大するには、ここをクリックします)
Exchange では、正しいことがわかっている情報の分類のみを行います。自動的に正しいと判断できない情報は、ジャーナル レポートの適切なフィールドに配置されます。図 2 は、ジャーナル レポートの本文に含まれるフィールドを説明しています。

セキュリティのすべて
既定では、同じ Exchange 組織内で Exchange Server 2007 を実行しているコンピュータどうしの通信がすべて暗号化されます。この暗号化には、ジャーナル レポートも含まれます。Exchange Server では、次のように、ジャーナル レポートが改ざんされるリスクを減らすのに役立つさまざまな対策を講じています。
  • Exchange 2007 組織のハブ トランスポート サーバーとメールボックス サーバー間に、セキュリティ保護されたリンクが使用されます。
  • ジャーナル レポートは、元のメッセージの送信者に代わって "Microsoft Exchange" として送信されます。
  • ハブ トランスポート サーバーとメールボックス サーバー間のセッションが認証されます。
  • 同じ Exchange 2007 組織内のハブ トランスポート サーバーとメールボックス サーバー間でジャーナル レポートが送信されるときは、認証済みの接続のみが許可されます。
メールボックスには、組織内の受信者に送信されたメッセージ、および組織内の受信者から送信されたメッセージが含まれるため、ジャーナル メールボックスを作成するときはそのメールボックスのセキュリティを確保する必要があります。一部のメッセージは、法的手続きの一部であるか、規制要件の制約を受ける場合があります。また、さまざまな法律では、調査機関に提出されるまでメッセージが改ざんされていない状態であることが求められます。ジャーナル メールボックスのセキュリティを向上するには、Microsoft Exchange 送信者からのメッセージのみを許可するようにジャーナル メールボックスを構成します。また、ジャーナル メールボックスに送信されるすべてのメッセージは、認証済みのユーザーによって送信される必要があります。図 3 に、ジャーナル メールボックスで構成されたメッセージの配信制限を示します。次の Exchange 管理シェル コマンドを使用して、これらのメッセージの配信制限を構成することもできます。
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
図 3 メッセージの配信制限
図 3 メッセージの配信制限 (画像を縮小するには、ここをクリックします)
図 3 メッセージの配信制限
図 3 メッセージの配信制限 (画像を拡大するには、ここをクリックします)
Exchange Server 2007 組織外にあるジャーナル メールボックスにジャーナル レポートを送信する場合は、Exchange Server 2007 コンピュータと受信サーバー間の接続を手動で暗号化し、セキュリティを確保する必要があります。これを行うには、2 つのシステム間でトランスポート層セキュリティ (TLS) を使用する必要があります。TLS では受信側システムでの認証が必要です。受信側システムで Microsoft Exchange 受信者の SMTP アドレス (この SMTP アドレスは、Exchange_UMUnique GUID@contoso.com のようになります) からのメッセージのみを許可し、Microsoft Exchange 受信者からのメッセージのみを許可するように、メッセージの転送に使用される Active Directory 連絡先を構成します。

ジャーナル ルールの実装
説明はもう十分なので、いくつかのルールを実装しましょう。ジャーナリング エージェントのジャーナル ルールは、Exchange 管理シェルまたは Exchange 管理コンソールのいずれかで構成できます。各ルールは、受信者、スコープ、およびジャーナル メールボックスの設定を構成するために使用できます。既定では、ジャーナル ルールは作成時に有効になります。ジャーナルの電子メール アドレスに指定する値は、Exchange Server 2007 組織の既存の受信者オブジェクトにする必要があります。この受信者オブジェクトは、メールボックス、配布グループ、動的な配布グループ、または SMTP アドレスにメールを送信する連絡先にできます。
Exchange 管理コンソールを使用すると、ジャーナル ルールの新規作成ウィザードによって、新しいジャーナル ルールを作成できます。[組織の構成] セクションで、サーバーの役割として [ハブ トランスポート] を選択します。操作ウィンドウで [ジャーナル ルールの新規作成] をクリックします。ここでは、ルール名、ジャーナル電子メール アドレス、およびスコープの値を指定する必要があります。組織内のすべての受信者のメッセージのジャーナルを作成するジャーナル ルールが必要な場合は、[受信者] フィールドの値を指定する必要はありません。ジャーナル ルールが作成されるときに、ジャーナル ルールを無効にするかどうかを選択することもできます。図 4 は、brian@contoso.com から送信されたすべてのメッセージまたはこのアドレスに送信されたすべてのメッセージのジャーナルを作成するサンプル構成を示しています。ジャーナルが作成されたメッセージは、Compliance Mailbox という名前のジャーナル メールボックスに送信されます。
図 4 ジャーナル ルールの新規作成ウィザード
図 4 ジャーナル ルールの新規作成ウィザード (画像を縮小するには、ここをクリックします)
図 4 ジャーナル ルールの新規作成ウィザード
図 4 ジャーナル ルールの新規作成ウィザード (画像を拡大するには、ここをクリックします)
Exchange 管理シェルでは、次の 6 つのコマンドレットを使用してジャーナリング エージェントを管理できます。
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
New-JournalRule コマンドレットによって、新しいジャーナル ルールを作成できます。この方法で新しいジャーナル ルールを作成するための基本的な条件は、ウィザードを使用するときと同じ、Name、Scope、および JournalEmailAddress の各パラメータの値を指定する必要があります。ウィザードの場合と同様ですが、組織内のすべての受信者のメッセージのジャーナルを作成するジャーナル ルールの場合は、Recipient パラメータの値を指定する必要はありません。また、ジャーナル ルールが作成されるときに、ジャーナル ルールを無効にする場合は、Enabled パラメータの値を $False に指定する必要があります。図 4 に示した構成と同じ構成のジャーナル ルールを作成するには、次のコマンドを使用します。
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Get-JournalRule コマンドレットを使用して、作成したすべてのジャーナル ルールの一覧を表示します。このコマンドレットを単独で実行すると、組織内で構成されているすべてのジャーナル ルールとその構成設定の概要一覧が表示されます。ジャーナル ルールに関する利用可能な情報をすべて表示する場合は、Get-JournalRule コマンドレットを Format-List コマンドレットにパイプすることができます。パイプにより、1 つのコマンドレットの出力が次のコマンドレットに送られるため、2 番目のコマンドレットはこの出力を受けて新たな処理を実行できます。たとえば Format-List コマンドレットは、受信したすべての出力を表示します。上記で作成したジャーナル ルールについて使用できるすべての情報を表示するには、次のコマンドを使用できます。
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
ジャーナル ルールを有効または無効にするには、Enable-JournalRule コマンドレットおよび Disable-JournalRule コマンドレットを使用します。これらのコマンドレットを使用するとき、Identity パラメータでジャーナル ルールの名前を指定する必要があります。たとえば、先ほど作成したジャーナル ルールを無効にするには、次のコマンドを使用します。
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Set-JournalRule コマンドレットでは、既存のジャーナル ルールを変更できます。ジャーナル ルールの名前は Identity パラメータで指定し、ジャーナリング エージェントにどのルールを変更するかを通知します。その後、Recipient、JournalEmailAddress、Scope またはこれらのパラメータのすべての組み合わせを、新しい値と共に指定します。たとえば、作成したルールの JournalEmailAddress パラメータに格納されている値を変更するには、次のコマンドを使用します。
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
最後に、Remove-JournalRule コマンドレットを使用して、既存のジャーナル ルールを削除できます。Identity パラメータを使用して、削除するジャーナル ルールの名前を指定します。サンプルのジャーナル ルールを削除するには、次のコマンドを使用します。
Remove-JournalRule "Brian Smith Journal Rule"
これを実行すると、Exchange 管理シェルから、ジャーナル ルールを本当に削除するかどうかを確認するメッセージが表示されます。最後にヒントを 1 つ紹介します。ほぼすべてのコマンドレットでは、Identity パラメータのラベルを省略し、パラメータ値のみを指定することができます。

David Strome は、マイクロソフトの Exchange User Education グループのテクニカル ライターになって 1 年余りです。David は、ワシントン州レドモンドのマイクロソフトに勤務する前は、カナダのブリティッシュ コロンビアのさまざまな企業で、約 10 年間 Exchange Server のインストールの設計、実装、および管理に携わっていました。連絡先は dstrome@microsoft.com (英語のみ) です。


 Exchange Server 2007: Sender ID を使ったスパムやフィッシングと戦い
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

Sender ID を使ったスパムやフィッシングと戦い
概要:
  • Sender ID の基本
  • Exchange Server での Sender ID の構成
  • 認証の利点

スパムの脅威の増大への対応策として、多くの ID テクノロジやフィルタ テクノロジが開発されました。これらのテクノロジは、効果を上げるために、各電子メール メッセージに関する特定の質問に依存しています。たとえば、だれが電子メールを送信したのかという質問があります。
残念ながら、メッセージの送信者を問う基本的な質問に必ずしも簡単に答えられるわけではありません。通常、電子メールは、送信者や送信者の代わりに動作するコンピュータの認証を行わずに、インターネット経由で送信されます。実際、他人のふりをしながら電子メール メッセージを送信することは簡単で、スプーフィングされたメッセージを自動的に検出する方法はありません。
電子メールの送受信に使用される簡易メール転送プロトコル (SMTP) は、電子メール メッセージの送信者を確認するように設計されていません。この技術的な抜け穴を利用して、任意の名前やアドレスが送信者として挿入される可能性があります。コンテンツ フィルタやスパム対策はヘッダー情報のみに依存するため、この場合にメッセージの実際の送信元が、メッセージの送信元とされている場所かどうかを確認することができません。
電子メールの認証は、特にこの抜け穴に対処します。認証により、送信側と受信側の両方の電子メール システムで、メッセージが送信元とされているドメインから送信されていることを確認します。これにより、組織は迷惑メールのフィルタ処理を効率的かつ簡単に行えるようになります。さらに、電子メールで指定されている受信者には正当な電子メールが届くことが保証されます。
現在、電子メールの認証に使用できる無償の方法が 2 つあります。1 つは Sender ID Framework (SIDF)、もう 1 つは DomainKeys Identified Mail (DKIM) です。SIDF は、Sender Policy Framework (SPF) と Microsoft Caller ID for E-Mail を融合して作成されたインターネット プロトコル (IP) を基盤としたソリューションです。2006 年 4 月に、インターネット技術標準化委員会 (IETF) は、Sender ID 仕様を RFC 4405 ～ 4408 として発行しました。マイクロソフトを含む、業界やビジネスの関係者が合同で、ビジネスや技術的価値、安定性、完成度、展開しやすさ、送受信のパフォーマンスへの最小限の影響、ISP や企業環境の電子メール エコシステムとの相互運用性などの要因に基づいて SIDF の展開を推奨しています。
DKIM は、Yahoo! の DomainKeys と Cisco Systems Inc. の Identified Internet Mail (IIM) を融合したものです。2006 年 1 月に、IETF は DKIM ワーキング グループの作成を承認しました。仕様については IETF で調査中です。
スパムに対抗できる完璧な解決策はありませんが、SIDF は、スプーフィングされたドメインに対処するための、業界にとって重要な第一歩となるものです。そのため、SIDF は、スパムやフィッシングの攻撃を軽減し、オンラインの信頼と信用を高める重要な要素といえます。世界中の組織は、急速に SIDF を採用しつつあります。現在、SPF レコードを公開している企業やドメイン所有者が 550 万を超え、SIDF で保護されているユーザーが 6 億を超えています。現時点では、世界中で毎日送信されている電子メールのうち、3 分の 1 を超える電子メールが認証されていて、SIDF に準拠しています。
SIDF の開発と世界規模での採用は、多くの組織や企業が貢献しサポートしなければ実現しないでしょう。現在は、AOL、Authentication and Online Trust Alliance (AOTA)、Bell Canada、E-Mail Senders Provider Coalition (ESPC)、CipherTrust、Cisco Systems、IronPort Systems、MarkMonitor、Port25 Solutions Inc、Sendmail、Symantec、TRUSTe、VeriSign などの企業に支えられています。

Sender ID について
業界の一部の調査では、フィッシング詐欺の 95% 以上がスプーフィングされたドメインによるもので、送信者の電子メール アドレスをスプーフィングしたことを示しています。SIDF がスパム対策処理に関して大きな効果を得られるのはこの点です。SIDF は、それ自体がスパムの問題を解決するのではなく、スパムやフィッシングの攻撃の影響を最小限に抑えるのに大きく貢献します。SIDF は迷惑メールの送信を妨げることはしません。ただし、迷惑メールをより簡単に検出することができます。このフレームワークは、電子メールの送信者が自分のドメイン名、評価、ブランドを保護する際に役立ちます。これは、送信者の評価や電子メールの動作に基づいてフィルタ処理上の決定を行うための堅牢な基盤となります。
Sender ID は、各電子メール メッセージが送信元とされているインターネット ドメインから発信されていることを確認しようとします。この処理は、電子メールの送信元サーバーのアドレスを、ドメイン所有者が電子メールの送信を承認したサーバーの登録済み一覧と照合することによって実行されます。メッセージがユーザーの受信ボックスに配信される前に、インターネット サービス プロバイダ (ISP) または受信者のメール サーバーによって自動的に検証が実行されます。
Sender ID またはその他の認証メカニズムはコンテンツ フィルタ システムに代わるものではないことに注意してください。SIDF と DKIM はどちらも実際のメッセージのコンテンツをスキャンしません。代わりに、認証では、メッセージに示された送信者と実際の送信元が同じかどうかを検証した結果が受信メール システムに通知されます。スパムやフィッシングの悪用が行われている多くの状況では、示されている送信元ドメインと実際の送信元ドメインが異なるため、この方法を使用すると、これらのメッセージを自動的に識別し、受信用メール ストリームから切り離すことができます。
SIDF 内の SPF レコードは、ドメインに関連付けられたすべての発信メール サーバーの単純なテキスト レコードを、各 IP アドレスと共に提供します。組織は SPF レコードをその DNS サーバー ゾーン ファイルに公開します。その後、このファイルは、受信者のメール サーバーで確認されます。SPF レコードの設定は、短時間で簡単に行うことができ、料金はかかりません。Sender ID Framework SPF Record Wizard では、ドメインのメール サーバーを調査し、投稿できるようにカスタマイズされたレコードを作成するための段階的なプロセスを提供します (SPF レコードの公開の詳細については、http://www.microsoft.com/japan/mscorp/safety/technologies/senderid/default.mspx を参照してください。このウィザードには、http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ (英語) から直接アクセスできます)。
受信側の SMTP メール サーバーは、SPF レコードが存在するため、DNS 内のドメインのゾーン ファイルに ping を実行します。送信側サーバーの IP アドレスは、検出後に、一覧に示された IP アドレスと照合されます。一致する IP アドレスがあれば、メッセージは本物と確認されます。一方、送信者のドメインの SPF レコードがメッセージの送信元の IP アドレスと一致しない場合、照合は失敗し、結果として、負のスコアが迷惑メール フォルダに配置される可能性があります。図 1 はこのプロセスを示しています。
図 1 受信メッセージの SPF レコードの確認
図 1 受信メッセージの SPF レコードの確認 (画像を縮小するには、ここをクリックします)
図 1 受信メッセージの SPF レコードの確認
図 1 受信メッセージの SPF レコードの確認 (画像を拡大するには、ここをクリックします)
メッセージが迷惑メールと判断されたら、受信側メール サーバーは、SIDF を使用することで、過去の動作、送信者の評価、メッセージのコンテンツ、および必要に応じて定義された他の条件に基づいてメッセージを分析できます。この機能により、追加の保護機能が提供されます。たとえば、スパムの発信者は、類似するドメインや公開された SPF レコードを登録し、ユーザーや受信側ネットワークをだましてメールが正当な送信者から送信されていると思い込ませることができます。その場合、電子メール メッセージが認証チェックに合格する可能性があるとしても、送信者の評価がスパムの発信者であれば、メッセージを十分にブロック、破棄、または削除できます。

Sender ID の展開オプション
SIDF を使用した送信電子メールの認証は、インフラストラクチャの変更やソフトウェアの更新を必要とせず、クライアント ソフトウェアやサーバー ソフトウェアに固有ではありません。ただし、自社や従業員を保護するために受信の認証を組み込む組織は、受信用システムやメッセージ転送エージェント (MTA) を更新し、SIDF をサポートするソフトウェアや機器を展開する必要があります。主要な市販およびオープン ソースの MTA やスパム対策ベンダ (Microsoft® Exchange Server や Exchange Hosted Filtering を含む) の大半は統合ソリューションを提供します。
マイクロソフトは、マイクロソフトのメッセージング製品すべてに SIDF を統合しました。このようなメッセージング製品には、Microsoft Exchange Server 2003 Service Pack 2 (SP2)、Exchange Server 2007、Microsoft Exchange Hosted Filtering、Microsoft Windows Live™ Mail、MSN® Hotmail®、Outlook® Express、および Office Outlook のメッセージング/コラボレーション クライアントがあります。
ただし、マイクロソフトでもスパムの受信が免除されることはありません。マイクロソフトで毎日受信するトラフィックは平均で約 1500 万のメッセージです。また、最近のスパムの攻撃では、その量の 2 ～ 4 倍ものトラフィックを受信することがわかりました。このような環境で、スパムをうまく防ぐ方法は、使用可能なテクノロジを慎重に実装することにあります。
マイクロソフトは、社内の Exchange Server スパム対策ソリューションを Exchange Server 2003 の Sender ID フィルタや Exchange Server 2007 の Sender ID エージェントに基づいて実行しています。Exchange Server のどちらのバージョンでも、Sender ID の状態は、対応する DNS サーバーにある Sender ID レコードの評価に基づいています。実際のドメインを特定するには、次の優先順位で RFC 2822 メッセージ ヘッダーを調査します。
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
送信者のドメイン (または、電子メール システムが他のメール サーバーの代わりにメールを合法的に転送できるため、最近メッセージをメッセージング ストリームに挿入するエンティティ) は、定義された順序で記載されているヘッダーの最初の定義を探すことによって特定されます。これらのヘッダーが検出されない場合、SIDF は、SMTP RFC 2821 MAIL FROM 句を使用します。

Sender ID の構成
Exchange Server 2007 では、エッジ トランスポートの役割がインストールされていないサーバーで Sender ID エージェントを有効にできます。Sender ID エージェントが有効な場合、受信コネクタ経由で送信されるメッセージをフィルタ処理します。つまり、(外部ソースから) 受信するすべての非認証のトラフィックは、Sender ID の処理対象となります。Exchange Server 2003 では、Sender ID の状態が EXCH50 BLOB 内のサーバー間で保持されます。Exchange Server 2007 では、これはメッセージ メタデータにも追加されました。最終的な送信先では、どちらも今後クライアントが使用するために MAPI プロパティに変換されます。
Exchange Server 2003 の [メッセージの配信プロパティ] で使用できる Sender ID フィルタの構成では、Exchange Server の失敗した検証への対処方法を指定するだけです。
Exchange Server 2007 で Sender ID を有効にするには、図 2 に示すように、エッジ トランスポートの役割が構成されたサーバーの Exchange 管理コンソールを開き、[スパム対策] タブをクリックし、[Sender ID] を選択して、[Actions (アクション)] 作業ウィンドウの [Enable (有効)] または [Disable (無効)] をクリックし、Sender ID エージェントのオンとオフを切り替えます。さらに、図 3 に示すように、Exchange 管理シェルを使用して、Sender ID を有効または無効にできます。
図 2 Exchange Server 2007 の Exchange 管理コンソールでの Sender ID エージェントの制御
図 2 Exchange Server 2007 の Exchange 管理コンソールでの Sender ID エージェントの制御 (画像を縮小するには、ここをクリックします)
図 2 Exchange Server 2007 の Exchange 管理コンソールでの Sender ID エージェントの制御
図 2 Exchange Server 2007 の Exchange 管理コンソールでの Sender ID エージェントの制御 (画像を拡大するには、ここをクリックします)
図 3 Exchange 管理シェルを使用して Sender ID を有効にする
図 3 Exchange 管理シェルを使用して Sender ID を有効にする (画像を縮小するには、ここをクリックします)
図 3 Exchange 管理シェルを使用して Sender ID を有効にする
図 3 Exchange 管理シェルを使用して Sender ID を有効にする (画像を拡大するには、ここをクリックします)
[Sender ID のプロパティ] ダイアログ ボックスでは、エージェントの状態 (有効または無効) を反映します。[アクション] タブには、Exchange Server 2003 で使用できるのと良く似たオプションがあります (図 4 参照)。
図 4 Exchange Server 2007 の [Sender ID のプロパティ] ダイアログの [アクション]
図 4 Exchange Server 2007 の [Sender ID のプロパティ] ダイアログの [アクション] (画像を縮小するには、ここをクリックします)
図 4 Exchange Server 2007 の [Sender ID のプロパティ] ダイアログの [アクション]
図 4 Exchange Server 2007 の [Sender ID のプロパティ] ダイアログの [アクション] (画像を拡大するには、ここをクリックします)
Sender ID の実装と機能に関しては、Exchange Server 2003 と Exchange Server 2007 に重要な相違はありません。Sender ID フィルタ (Exchange Server 2003) と Sender ID エージェント (Exchange Server 2007) の両方で、展開と検証に同じ基本アルゴリズムが使用されています。考えられるアクションの範囲も同じです。[メッセージの削除] (自動削除)、[メッセージを拒否する] (500 レベルの SMTP プロトコルの応答)、[Sender ID の結果をメッセージにスタンプして処理を続行する] というアクションがあります。この最後のオプションは、Exchange Server の両方のバージョンの既定のアクションです。
Exchange Server 2007 では、状態コードの FAIL も TempError も、[メッセージを拒否する] アクションをトリガできます (Exchange Server 2003 では、このアクションをトリガできるのは、状態コード FAIL だけです)。Sender ID エージェントは、状態コードが TempError のメッセージで [メッセージを拒否する] アクションをトリガするように明示的に構成されている必要があります。既定では、これらのメッセージはシステムに受信され、Sender ID の結果をスタンプされた後、処理されるためです。
この構成オプションは、グラフィカル ユーザー インターフェイスでは提供されていないため、Exchange 管理シェルを使用して、TempError 状態コード用に Sender ID のアクションを構成する必要があります。たとえば、Sender ID エージェントが状態コード TempError のメッセージを拒否するように設定するには、次の Sender ID エージェントのコマンドレットを実行します。
Set-SenderIDConfig -TempErrorAction Reject
Exchange Server 2007 での Sender ID の状態の結果および考えられるアクションの範囲は、Exchange Server 2003 の Sender ID フィルタの範囲に類似しています。これについては、図 5 を参照してください。
Figure 5 Exchange Server 2007 の Sender ID の状態とアクション (Close Figure 5)

Sender ID の状態 | 説明 | アクション
Neutral | 発行された Sender ID データは明示的に判断できません。 | StampStatus
Pass | IP アドレスは許可セットに含まれています。 | StampStatus
Fail | IP アドレスは許可されていないセットに含まれています。 | StampStatus、Delete、または Reject
SoftFail | IP アドレスは許可されていないセットに含まれている可能性があります。 | StampStatus
None | 発行されたデータがありません。 | StampStatus
TempError | DNS サーバーが使用できないなどの一時的なエラーが発生しています。 | StampStatus または Reject
PermError | レコード形式のエラーなどの回復不可能なエラーが発生しています。 | StampStatus
Exchange は (構成されている場合) Sender ID の検証に失敗したメッセージのみを削除します。他の結果では、メッセージの削除はトリガされません。結果の状態が Neutral、None、SoftFail、TempError、または PermError の受信メッセージは、適切にスタンプされ、さらにスパム対策を検証するために渡されます。メッセージの形式がまったくもって不適切で、FROM IP アドレスが存在しないときには、Sender ID の状態をメッセージにスタンプすることができない場合があります。この状況では、メッセージは破棄も拒否もされません。むしろ、メッセージは、Sender ID の状態が設定されていないと以降の処理のために渡され、認識を高めるために適切なイベントがログに記録されます。
Exchange Server 2007 では、Sender ID の検証から除外する送信者ドメインや Exchange Server 受信者を簡単に定義できます。繰り返しますが、この構成オプションは、Exchange 管理シェルからしか利用できません。たとえば、ドメイン contoso.com を Sender ID フィルタから除外するには、次のコマンドを実行します。
Set-SenderIDConfig -BypassedSenderDomains contoso.com
同様に、指定した Exchange Server 受信者に送信されたメッセージを Sender ID フィルタから除外するには、次のコマンドを実行します。
Set-SenderIDConfig -BypassedRecipients user@contoso.com
Exchange Server 2007 では、Exchange 管理シェルのコマンドレットで設定されていてもグラフィカル ユーザー インターフェイスから使用できない Sender ID の構成値は、図 6 に示すように、Exchange 管理シェルで Get-SenderIDConfig コマンドを実行して簡単に取得することができます。
図 6 Sender ID の構成のコマンドレット
図 6 Sender ID の構成のコマンドレット (画像を縮小するには、ここをクリックします)
図 6 Sender ID の構成のコマンドレット
図 6 Sender ID の構成のコマンドレット (画像を拡大するには、ここをクリックします)
Exchange 管理シェルは、IP アドレスと対応するドメイン名を迅速に手動で検証する際に使用できます。Sender ID の状態を確認するには、次のコマンドを実行します。
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
ドメインが存在しない場合、結果は図 7 のようになります。
図 7 アドレスの Sender ID の状態の確認
図 7 アドレスの Sender ID の状態の確認 (画像を縮小するには、ここをクリックします)
図 7 アドレスの Sender ID の状態の確認
図 7 アドレスの Sender ID の状態の確認 (画像を拡大するには、ここをクリックします)

Sender ID の利点
電子メール メッセージを認証したりユーザーが受信するスパムの量を削減する場合の明白な利点とは別に、プロトコルとしての SIDF には他の利点があります。マイクロソフトは、SIDF の開発時に、パフォーマンス、コスト、展開とスケーラビリティ、相互運用性など、いくつかの主要な目標に注目しました。
SIDF は、最初に、電子メールの送信者を認証し、送信者の評価スコアの適用を許可します。その結果、スパムやスプーフィングされた電子メール メッセージを大幅に削減し、既知の送信者や信頼された送信者からの正当な電子メール配信の確実性が高まる可能性があります。SPF レコードは無償で作成できるので、SIDF に準拠する組織であれば簡単に作成できます。新しい標準の規定に準拠したい組織はそうできます。SIDF を使用すると、SPF レコードを公開するのと同じくらい簡単に準拠できます。
SIDF は、可能な限り既存のソフトウェア内で動作するように開発されました。これは、さまざまな電子メール アーキテクチャやクライアントとサーバーのソフトウェアで使用できます。認証サービスでは、効果を上げるために、小規模なホーム メール サーバーと同様、大規模な ISP のニーズに簡単に応じることができるようにする必要があります。SIDF は、1 台から数千台もの電子メール サーバーに加え、電子メール サーバーを別の組織にアウトソーシングする人々もサポートできます。
2007 年 4 月 18 ～ 19 日に、マイクロソフトと 30 を超える組織やパートナーから成る業界団体は、マサチューセッツ州のボストンで、Authentication & Online Identity Summit を開催します。この 2 日間のプログラムでは、ケース スタディを調査して Sender ID のテクニカル レビューを行い、電子メールの認証のビジネス価値について詳しく説明します。詳細については、http://aotalliance.org/summit2007 (英語) を参照してください。さらに、ツールやリソースなどの情報については、http://www.microsoft.com/japan/mscorp/safety/technologies/senderid/default.mspx や http://www.microsoft.com/japan/exchange/default.mspx を参照してください。

Craig Spiezle は、マイクロソフトの Windows Live Safety のテクノロジ戦略と計画の責任者です。Craig は、電子メール認証のプロダクト マネージャとして、Sender ID を業界に導入する際の原動力となりました。1992 年にマイクロソフトに入社した後、国際マーケティング、製品サポート戦略、OEM、新興市場の開発など、複数の管理職に就きました。
Alexander Nikolayev は、マイクロソフトのプログラム マネージャであり、サーバー側プロトコル、トランスポート コア、Exchange Server および Windows Server のスパム対策コンポーネントの責任者です。彼は、メアリー大学から MBA を取得しました。Exchange チームのブログ (blogs.technet.com/exchange) (英語) で彼の投稿を参照してください。


 編集長からのごあいさつ: 皆さんと近づくために
編集長からのごあいさつ
皆さんと近づくために

TECHNET MAGAZINE は、今、皆さんが手にしているこの雑誌以外でも見ることができます。私たちのチームは、全世界 10 億人以上にコンテンツを見ていただくための新しい Web サイト作りに懸命に取り組んできました。11 月号から、すべての記事を英語、スペイン語、フランス語、ドイツ語、ロシア語、簡体字中国語、ポルトガル語 (ブラジル) の 7 言語に翻訳してオンラインで公開しています。英語版は既にオンラインで公開していましたが、新しく 6 言語を追加したことで、私たちのコンテンツを母語でお読みいただける読者が 16 億人以上増えました。すばらしいことです。
それだけではなく、サイトを使いやすくするための機能も大幅に追加しました。新しい RSS は、カスタマイズして日付、コラム、執筆者、トピック別にコンテンツを選択できます。複数の条件を適用したり、条件に合うコンテンツを抽出したりできます。technetmagazine.com/rss (英語) で、あなただけのフィードをすぐに作成できます。
また、新しいトピック ページを設置しました。Windows Vista に備えて IT プロフェッショナルが行う必要があることは、technetmagazine.com/vista (英語) にすべて記載してあります。メール管理者の皆さんは、technetmagazine.com/exchange (英語) をぜひチェックしてください。technetmagazine.com/topics (英語) には注目のトピックが 32 個ありますが、これは今後追加する予定です (11 月の時点で、セキュリティ関連の記事を 43 本取り揃えています)。
それだけではありません。TechNet Magazine や IT プロフェッショナルの世界をさらに深く理解できるようになりました。TechNet Magazine の編集者の 1 人、Joshua Hoffman が blogs.technet.com/tnmag (英語) で本誌のブログを公開中です。私も、www.technetmagazine.com/podcast (英語) でこのサイトのポッドキャストを月 1 回ホストしています。毎回、記事の執筆者を迎え、雑誌には書かれていない記事の疑問をぶつけます。TechNet Magazine の一流の執筆者が語る、記事や取り組んでいる仕事についての話をお楽しみください。
TechNet Magazine を IT プロフェッショナルにとって最も役立つリソースにするため、私たちは精一杯努力しています。2006 年は充実した 1 年でしたが、これに満足せず、さらに皆さんの声に耳を傾けたいと考えているので、コメントをお寄せください。編集チームへのアドレスは、tnmag@microsoft.com (英語) です。いつでも投稿をお待ちしています。
£JOSHUA TRUPIN

次のマイクロソフト技術支援スタッフに心より感謝します。Kevin Allison、Jessica Arnold、Sebastian Bengochea、Naveen Chand、Li Chen、Alpa Dave、Jill Frank、Mihai Jalobeanu、Darcy Jayne、Harry Katz、Kerry Landen、Todd Luttinen、Brett Muzzey、Bruce Payette、Tony Smith、Shawn Thomas、Jim Truher、Scot Vidican


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

Web アプリケーションのストレス テスト
WAPT Web アプリケーション ストレス ツール
www.loadtestingtool.com (英語)
現行の Web アプリケーションのパフォーマンスを知ることは、インフラストラクチャの規模を適切に決めるためにも、負荷が高いときにサイトをチェックした CEO にサーバーがビジーというエラーが表示される理由を聞かれるのを避けるためにも重要です。比較的安価で使いやすい Web アプリケーション用ストレス パフォーマンス テスト ツールをお探しなら、SoftLogica LLC の WAPT 4.0 を検討してください。
WAPT 4.0 は Windows® のほとんどのバージョンで実行できますが、古い Windows はソケットの制限があるので、完全な性能を発揮するには Windows 2000、Windows XP、または Windows Server® 2003 を使用します。仮想ユーザーを使用する他の一般的なパフォーマンス テスト アプリケーションと同様に、搭載するメモリ、プロセッサ、およびネットワーク接続の性能が高いほど、WAPT を使用したシミュレーションに投入できる仮想ユーザーは増加します。
ドキュメントには、仮想ユーザーの制限は 512MB の RAM、2.4 GHz の Pentium 4、ギガビット イーサネット インターフェイスを搭載した条件で約 2,000 名と書かれていますが、テストするアプリケーションの種類やテスト プロファイルをどのように作成するかによっても変動します。また、仮想ユーザーのプロファイルでユーザーの思考時間として設定できる要求間の待機時間も、テストに影響を及ぼします。
仮想ユーザー プロファイルの設定が完了したら (1 つのテスト シナリオに複数設定できます)、そのプロファイルに合わせてテスト プランを作成します。WAPT では、テスト シーケンスを初期操作、メイン操作、最終操作に 3 分割します。機能面ではなく論理面での分割方法ですが、ログインまたは登録機能をたとえば初期操作に、ログアウト操作を最終操作に組み入れることを想定しています。WAPT では、要求を手作業で入力するか、統合ブラウザ レコーダでこのプロファイルのユーザーの動向を追跡できます。次に、全般設定に進んで、このテストでかける負荷、およびその負荷を固定するか一定の時間内に増加させていくかを指定します。テストの間、テスト シナリオのパフォーマンス統計をリアルタイムに表示できます。テスト終了後は、結果を後で参照できるように HTML または CSV で保存できます。
価格 :1 台あたり $350
Web アプリケーションの最新版のパフォーマンスを知ることは、インフラストラクチャの規模を適切に決めるためにも、サイトをチェックした CEO にサーバーがビジーというエラーが表示される理由を聞かれるのを避けるためにも重要です。比較的安価で使いやすい Web アプリケーション用ストレス パフォーマンス テスト ツールをお探しなら、SoftLogica LLC の WAPT 4.0 を検討してください。
WAPT 4.0 は Windows® のほとんどのバージョンで実行できますが、古い Windows はソケットの制限があるので、完全な性能を発揮するには Windows 2000、Windows XP、または Windows Server® 2003 を使用します。仮想ユーザーを使用する他の一般的なパフォーマンス テスト アプリケーションと同様に、搭載するメモリ、プロセッサ、およびネットワーク接続の性能が高いほど、WAPT を使用したシミュレーションに投入できる仮想ユーザーは増加します。
WAPT Web アプリケーション ストレス ツール
WAPT Web アプリケーション ストレス ツール (画像を縮小するには、ここをクリックします)
WAPT Web アプリケーション ストレス ツール
WAPT Web アプリケーション ストレス ツール (画像を拡大するには、ここをクリックします)
ドキュメントには、仮想ユーザーの制限は 512MB の RAM、2.4 GHz の Pentium 4、ギガビット イーサネット インターフェイスを搭載した条件で約 2,000 名と書かれていますが、テストするアプリケーションの種類やテスト プロファイルをどのように作成するかによっても変動します。また、仮想ユーザーのプロファイルでユーザーの思考時間として設定できる要求間の待機時間も、テストに影響を及ぼします。
仮想ユーザー プロファイルの設定が完了したら (1 つのテスト シナリオに複数設定できます)、そのプロファイルに合わせてテスト プランを作成します。WAPT では、テスト シーケンスを初期操作、メイン操作、最終操作に 3 分割します。機能面ではなく論理面での分割方法ですが、ログインまたは登録機能をたとえば初期操作に、ログアウト操作を最終操作に組み入れることを想定しています。WAPT では、要求を手作業で入力するか、統合ブラウザ レコーダでこのプロファイルのユーザーの動向を追跡できます。次に、全般設定に進んで、このテストでかける負荷、およびその負荷を固定するか一定の時間内に増加させていくかを指定します。テストの間、テスト シナリオのパフォーマンス統計をリアルタイムに表示できます。テスト終了後は、結果を後で参照できるように HTML または CSV で保存できます。
価格 :1 台あたり $350

ブック レビュー
Content Networking Fundamentals
www.ciscopress.com (英語)
コンテンツは王様です。そして、Silvano Da Ros 著『Content Networking Fundamentals』(Cisco Press 刊、2006 年) を読むと、コンテンツ配信インフラストラクチャの強化を一気に進めることができます。この本は自らうたっているとおり、"コンテンツ ネットワーキングの理論と実践的応用をくまなく紹介" しています。内容は当然 Cisco のネットワーク装置に偏っていますが、コンテンツ ネットワーキングのさまざまな構成要素をわかりやすく説明しているだけでなく、インフラストラクチャでどのような種類のコンテンツ ネットワーキング製品を使用していても当てはまる原理をコンテンツ ネットワーキングに組み入れるための実践的なガイドラインが記載されています。
本の冒頭で、(OSI 参照モデルの第 4 ～ 7 層の通信パフォーマンスが向上するための) コンテンツ ネットワーキングのさまざまな要素を概観します。次に、XML、HTML、WAP などの主要なコンテンツ プレゼンテーション形式と、ネットワーク エッジでの XSLT によるコンテンツ変換についての基本を、ストリーミング メディアの配信を扱うセクションも交えて紹介します。最後に、全体とローカルでのサーバーの負荷分散、ファイアウォールの負荷分散、コンテンツ キャッシュ デバイス (Cisco のコンテンツ サービス スイッチなど) の使用について説明しながら、スケーラビリティと可用性の話を進めます。
Cisco のコンテンツ サービス スイッチをインフラストラクチャで使用する読者のため、セキュリティで保護されたコンテンツの切り替えに関する章もあります。SSL 用コンテンツ サービス モジュールを構成する場合の詳細が、URL の構成およびヘッダーの書き換えと共に説明されています。任意のブランドにロイヤリティを示すネットワークのプロには、さまざまなキュー メカニズムと回線の混雑の管理について書かれた QoS に関する章が役立つでしょう。
(Cisco Press の発行なので) Cisco のハードウェア実装の比重が大きいですが、"コンテンツ ネットワーキング" というあいまいな専門用語を、コンテンツ配信インフラストラクチャに適用できる実用的な方法論にするのに役立つ 1 冊です。
価格 :$55.00

サービスの監視
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp (英語)
IT プロフェッショナルの良し悪しを決める要素の 1 つが、組織のエンド ユーザーよりも前に問題に気付く (できれば修正までする) 能力です。したがって、提供しているさまざまなサービスが正常に稼動していることを検証するため、情報を収集する効果的な監視システムを持つことが重要です。そのような場合に、ExclamationSoft の WebWatchBot が役立ちます。
このアプリケーションは、一般に思い付くサービスをすべて監視できます。サービスが実行中であることを検証するだけでなく、さらに高度な機能があります。サービスが適切に機能しているかどうかを実際にテストするのです。たとえば、FTP 検証機能では実際にファイルのアップロードとダウンロードを行います。DNS 監視では 40 種類の中から任意のクエリ コマンドを実行し、応答に含まれる文字列を検索します。POP3 と SMTP のテストでは実際にログインしてメールのパフォーマンスを報告します。
WebWatchBot
WebWatchBot (画像を縮小するには、ここをクリックします)
WebWatchBot
WebWatchBot (画像を拡大するには、ここをクリックします)
また、一連の手順をトランザクションとしてまとめ、そのトランザクション全体のエラーまたは過度の遅延 (しきい値で設定します) を報告できます。HTTP と HTTPS の URL 監視、および特定のコンテンツの存在確認も行います。さらに、クエリを実行したり、テンプレート化した応答とデータを照合したりするデータベース モニタを設定できます。
価格 :$495.95 (1 ユーザー ライセンスごと)

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。彼はいつも IT プロフェッショナルが操作および開発を容易に行える新しいツールや方法を探しています。


 Windows PowerShell: 簡単なコマンド、強力な管理機能
Windows PowerShell
簡単なコマンド、強力な管理機能
Don Jones
このコラムは、Windows PowerShell のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

実現するまで時間がかかりましたが、Windows PowerShell はもうすぐ起動できるようになります。つまり、Windows 管理者が注目するときがやってきました。Windows PowerShell は、さまざまな管理作業を自動化するためのおそらく最も簡単で柔軟性のある方法となるものを提供するので、これを使えば作業をより効率的かつ効果的に進められるようになります。
でももっと重要なのは、マイクロソフトが Windows PowerShell™ を基に Exchange Server 2007 や System Center 2007 などの製品のグラフィカルな管理コンソールを構築していることです。つまり、Windows PowerShell 内からほとんどの管理作業を実行できるようになります。マイクロソフトは長い年月をかけて、より多くの製品の管理機能で同じことを行えるようにするつもりです。したがって、Windows PowerShell は最終的にはマイクロソフトのほとんどすべてのサーバー製品を管理するための最初の万能ツールになります。まずは、この新しいコラムで Windows PowerShell について定期的にお話します。ソフトウェアのコピーをダウンロードしてください。

強力さと容易さ
Windows PowerShell は、その名前のとおりシェルであり、Windows NT® 3.1 以降のコマンド プロンプト (Cmd.exe) とよく似ています。Cmd.exe が消えたわけではなく、Windows PowerShell の可用性を備えたうえで、Cmd.exe を引き続き使用する理由がいくつかあります。
Windows PowerShell の使用と Cmd.exe の使用にはそれほど違いはありません。唯一の違いは、Windows PowerShell の方が強力だということです。Cmd.exe と同様、Windows PowerShell には組み込みのスクリプト言語がありますが、Cmd.exe の基本バッチ言語よりもはるかに柔軟性があります。どれくらい柔軟なのでしょうか。Windows PowerShell では、6 個前後の組み込みのキーワードだけを含む言語を使用して、非常に複雑な作業を自動化できます。
スクリプトについては既に説明したので、セキュリティについても触れておいた方がよいでしょう。Windows PowerShell では、マイクロソフトが過去 10 年余りの間、セキュリティについて学習してきたことを生かしています。既定では、Windows PowerShell はスクリプトを実行しません。個別のコマンドを対話的に実行するためにのみ使用できます。スクリプトを有効にすると、デジタル署名付きのスクリプトのみを実行するよう Windows PowerShell に指示できます。このすべてによって、Windows PowerShell が次の VBScript になることはないということを確信できます。VBScript は悪意のあるスクリプトを作成するために悪用されることが多かった、ある意味偉大な言語です。VBScript も消滅してはいませんが、Windows PowerShell の方が多くの異なる作業に簡単に使用できることがおわかりでしょう。
Cmd.exe でできることは、Windows PowerShell でもほとんどすべて実現できます。たとえば、ipconfig を実行すると、おなじみの出力が表示されます。しかし、Windows PowerShell は外部の実行可能ファイルではない、まったく新しいコマンド セットを導入しています。これらのコマンドレットは Windows PowerShell に組み込まれています (Windows PowerShell の使用を開始するときに最も役立つコマンドレットの一部を見てみるには、「すぐに使用できる 10 個の主なコマンドレット」を参照してください)。
すぐに使用できる 10 個の主なコマンドレット
  • Get-Command は利用可能なすべてのコマンドレットの一覧を取得します。
  • Get-Help はコマンドレットと概念に関するヘルプ情報を表示します。
  • Get-WMIObject は WMI を使用して管理情報を取得します。
  • Get-EventLog は Windows イベント ログを取得します。
  • Get-Process はアクティブなプロセスを 1 つ取得するか、その一覧を取得します。
  • Get-Service は Windows サービスを取得します。
  • Get-Content はテキスト ファイルを読み取ります。読み取るとき、各行を 1 つの子オブジェクトと見なします。
  • Add-Content は内容をテキスト ファイルに追加します。
  • Copy-Item はファイル、フォルダ、その他のオブジェクトをコピーします。
  • Get-Acl はアクセス制御リスト (ACL) を取得します。
Windows PowerShell に含まれているコマンドレットの完全な一覧については、windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx (英語) を参照してください。
すべてのコマンドレットの名前は、理解しやすく覚えやすいように、動詞と名詞を組み合わせた標準の形式になっています。たとえば、Get-Command コマンドレットを実行すると、使用できるすべてのコマンドレットが一覧表示されます。おそらく管理者にとって最も役立つコマンドレットは Get-WMIObject です。たとえば、Server2 がどの Service Pack を実行しているのかを知りたい場合は、以下のコードを実行するだけです。
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
VBScript を使用してこれと同じ情報を取得するには、数行のコードを記述する必要があります。他のコマンドレットではサービス (Start-Service、Stop-Service など)、プロセス (Stop-Process など)、ファイル (Rename-Item、Copy-Item、Remove-Item、Move-Item、など) や、その他の項目を操作できます。これらのコマンドレットの多くは、エイリアスと呼ばれるショートカット名を持っています。Get-WMIObject の場合は、gwmi と入力するだけ済みます。Get-Alias を実行すると、これらのショートカット名の一覧が表示されます。

オブジェクト指向の理由
Microsoft® .NET Framework を基に構築された Windows PowerShell は、完全にオブジェクト指向です。通常それについて興奮するのはソフトウェア開発者だけですが、この場合、オブジェクト指向によって管理者の時間を大幅に節約できます。これは、管理者がテキストベースのシェルで豊富なオブジェクトを直接操作できるようになったためです。次の例について考えてみましょう。
Get-Process | Sort-Object pm –desc | Select-Object –first 10
上記のコードはたった 1 行ですが、パイプ記号で区切られた 3 つの異なるコマンドレットを含んでいます (コマンドレットは瞬時に増やすことができます)。最初のコマンドレットは実行中のすべてのプロセスを取得して、それらのオブジェクトを Sort-Object に渡します (つまり、パイプします)。2 番目のコマンドレットは各プロセス オブジェクトの pm (物理メモリ) プロパティを降順に並べ替えます。並べ替えられたプロセス オブジェクトのコレクションは Select-Object にパイプされ、最初の 10 個が選択され表示されます。では、表示結果を見てみましょう。この単純な行によって、図 1 のように、コンピュータ上の上位 10 個の物理メモリ コンシューマが表示されます。これは、何らかのトラブルシューティングを行うときにさっと調べることができる非常に効率的な方法と言えます。
図 1 単純なコマンドレットを使用したトラブルシューティング
図 1 単純なコマンドレットを使用したトラブルシューティング (画像を縮小するには、ここをクリックします)
図 1 単純なコマンドレットを使用したトラブルシューティング
図 1 単純なコマンドレットを使用したトラブルシューティング (画像を拡大するには、ここをクリックします)
パイプ (通常は日本語キーボードの円記号キーにある縦線文字) の使用は、Windows PowerShell を非常に高性能にするのに不可欠です。この文字を使用して、あるコマンドレットから別のコマンドレットにオブジェクトを渡す (パイプする) ことができ、さらに結果の精度を上げたり、表示用に書式設定したりすることができます。このメカニズムが動作するのは、各コマンドレットが純粋なテキストではなく 1 つ以上のオブジェクトを返し、後続のコマンドレットに、動作する完全なオブジェクトを提供するためです。
Windows PowerShell のオブジェクトはその変数まで幅広く使用されています。そして事前に変数を宣言しておく必要はありません。変数名の前にドル記号 ($) を付けるだけで変数の使用を開始できます。必須ではありませんが、変数に格納するデータの型を Windows PowerShell に通知することもできます。Windows PowerShell で変数を非常に強力な .NET Framework 型の 1 つにマップして、多数の追加の組み込み機能を提供することができます。たとえば、コンピュータ名の入力を求めて、コンピュータから Service Pack のバージョンを取得したいのですが、コンピュータ名を入力するユーザーが (\\Server2 のように) 2 個の円記号を含めるかどうかがわからないとします。Get-WMIObject コマンドレットが円記号を必要としないことはわかっているので、コンピュータ名を String 変数に保存し、Replace メソッドを使用して円記号を空の文字列に置き換えることができます。その例を次に示します。
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
–Computer パラメータの値は $c 変数に格納されています。その変数は最初は文字列として作成されたので、.NET Framework の String 型のすべての機能 (Replace メソッドを含む) を選択しました。もちろん、これらの機能をすべて理解するにはしばらくかかりますが、例を通してそれらの機能を簡単に選択できるようにします。Windows PowerShell 自体が学習を簡略化するのに役立ちます。たとえば、「$c = $c.」(ピリオドを忘れないでください) と入力し、Tab キーを押すと、Windows PowerShell が Clone() という String 型の最初のメソッドを表示します。Tab キーを押し続けると、Windows PowerShell は使用できるすべてのメソッドを繰り返し表示します。基本的には、これを行うと、Windows PowerShell が String 型をどのように処理するのかがわかります。
以下はもっと厄介な作業です。ファイルからコンピュータ名の一覧を読み取り、1 行に 1 つのコンピュータ名を表示します。また、各コンピュータの Service Pack 番号も表示します。VBScript では、この作業は 10 行以上のコードが必要です。Cmd.exe では、複雑なバッチ ファイルを使用する必要があります。Windows PowerShell では、この作業はたった 1 行で済みます。
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Get-Content コマンドレットは C:\Computers.txt のコンテンツを読み取ります。ファイルの各行はそれ自体でオブジェクトになります。このオブジェクト (つまりコンピュータ名) のコレクションは、foreach コマンドにパイプされます。foreach は ForEach-Object コマンドレットの単なるエイリアスに過ぎません。中かっこの中のコマンドは、パイプされる各オブジェクトに 1 回ずつ繰り返されます。この例では、各コンピュータ名に対して 1 回ずつ実行されます。特殊な変数 $_ は、現在のオブジェクト (つまり、現在のコンピュータ名) を格納します。
中かっこの中には実際には 2 つのコマンドがあります。最初のコマンドは $_ の内容を出力することによって、現在のコンピュータ名を表示するだけです。2 番目のコマンドは今ではおなじみの gwmi です。このコマンドは、ファイルに一覧表示されているすべてのコンピュータの Service Pack のバージョンの一覧を返します。このすべてが比較的わかりやすい 1 行のコードで完了しました。
–Property パラメータと –Computer パラメータの名前が略されていることに注意してください。Windows PowerShell ではパラメータ名を一意に識別できればいいのです。

読みやすさと再利用
コマンドとパラメータを 1 行で記述すると、読みやすさは得られません。Windows PowerShell ではこの行をもっと読みやすいように分割でき、スクリプトを記述することなく、シェルに直接入力できます。コードは、次のようになります。
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
今回はファイルの内容は変数 $names に格納されます。この例では依然として foreach を使用していますが、パイプラインを使用して入力されていないので、ループするオブジェクトのコレクションと、各オブジェクトに格納する変数、つまり、”($name in $names)” 部分を指定する必要があります。それ以外はまったく同じで、Enter キーを押すとすぐに、コードが実行され、結果が表示されます。
これと同じコードを繰り返し使用する場合は、そのコードから関数を作成するだけです。もう一度言いますが、これは直接シェルに入力できます。
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
ご覧のとおり、それほど変更された箇所はありません。これは前の例を Get-ServicePacks という関数で囲んでいるだけです (この関数の名前は Windows PowerShell の動詞と名前で構成される名前付け規則に従っています)。関数には $file という入力パラメータが付いていて、Get-Content コマンドレットで置き換えられるので、関数の実行時に別のファイルを指定することができます。関数は既に定義されているので、コマンドレットのような関数名を呼び出して、入力パラメータを渡すことによって、コードを単純に実行できます。
PS C:\> Get-ServicePacks c:\computers.txt
図 2 は結果を示しています。
ここでの弱点は、この関数が存在するのは Windows PowerShell のインスタンスが実行中の場合のみに限られることです。シェルを終了すると、関数は消滅します。この関数は Windows PowerShell プロファイルにコピーできます。これは、Windows PowerShell が起動するたびに実行される、一種の自動実行スクリプトです。これにより、開くすべての Windows PowerShell ウィンドウでその関数を利用できるようになります。または、必要に応じて、関数を単独のスクリプトに作成することができます。そうすると、スクリプトのパスとファイル名を入力するだけでスクリプトを実行できます。
図 2 Get-ServicePacks 関数の 実行結果
図 2 Get-ServicePacks 関数の 実行結果

まるでファイル (またはフォルダ)
Windows PowerShell は関数とコマンドレットだけではありません。どんなものがあるのかを示す簡単な例として、ファイル管理を見てみましょう。Cmd.exe でドライブやフォルダを移動する操作はよくご存知でしょう。たとえば、「C:」と入力すると、C ドライブに切り替わり、「cd \test」と入力すると、C:\Test フォルダに移動します。Windows PowerShell はまったく同じ動作をしますが、cd は Set-Location コマンドレットの単なるエイリアスです。
使用できるドライバをすべて一覧表示するコマンドレットである Get-PSDrive を実行してみます。通常の C: ドライブ、D: ドライブ、およびおそらく A: ドライブに加えて、Cert という名前のドライブ、Env という名前のドライブ、HKCU や HKLM という名前のドライブも見つかります。Windows PowerShell は実際にはストレージ リソースの多くの異なる種類を "ドライブ" として公開しており、ファイルのようなおなじみのナビゲーション インターフェイスを使用して利用できるローカル証明書ストア、環境変数、レジストリ変数のようなものを作成します。
「Set-Location HKLM:」(またはショートカットを好む場合は「cd hklm:」) と入力して Enter キーを押すことにより、HKEY_LOCAL_MACHINE レジストリ ハイブに変更します。その後、cd software\microsoft を実行して SOFTWARE\Microsoft キーに変更します。Get-ChildItem コマンドレットのエイリアスである dir を使用して、レジストリのこの部分にあるサブキーを一覧表示できます。キーを削除する場合は、del を使用して、キーがファイルやフォルダであるかのように削除できます (ただし、必要なキーを削除したりレジストリを誤って変更すると、重大な問題が発生する可能性があるのでご注意ください)。
この柔軟性はすべてプロバイダから提供されており、リソース (レジストリや証明書ストアなど) をファイル システムのような形式にマップします。マイクロソフトは追加のプロバイダを通して Windows PowerShell を拡張する計画を立てています。たとえば、ファイル システムであるかのように Exchange Server ストアを移動する機能を提供します。Windows で使用されている多様なリポジトリを採用して、すべてが同様に見えるようにするだけでなく、既によく知っているコマンドや技法を使用してそれらのリポジトリをすべて管理可能にするという点で、これは非常に重要な技法です。

安全な設計
Windows PowerShell がセキュリティと安全性を念頭に置いて設計されたということは既にお話しました。Windows PowerShell の主要なセキュリティ機能はその実行ポリシーです。既定では、このポリシーは Restricted に設定されています。この設定は、Get-ExecutionPolicy コマンドレットを実行することによって確認できます。Restricted モードでは、スクリプトは実行されません。これで以上です。それが既定のモードなので、Windows PowerShell を使用して特別な構成を行わずにスクリプトを実行することはできません。
他のモードを指定するには、Set-ExecutionPolicy コマンドレットを使用します。個人的には RemoteSigned モードが気に入っています。このモードでは、ローカル スクリプト (リモート スクリプトではない) を、デジタル署名なしで実行できるので、スクリプトを開発してテストする最も簡単な方法が提供されます。AllSigned モードは、スクリプトが信頼されている発行元から発行された証明書を使用してデジタル署名されていない限り、スクリプトは実行されません。最後に、Unrestricted ポリシーの場合は、何でも実行されます。Windows PowerShell を起動して、コンピュータを侵害する可能性のある悪意のあるスクリプトを実行する場合、このポリシーは使わないことをお勧めします。また、実行ポリシーはグループ ポリシーでも管理されるので、ローカルの設定は上書きされることに注意してください (Set-ExecutionPolicy は、グループ ポリシーの設定でローカルの設定が上書きされる場合に、警告を通知します)。
さらに、Windows PowerShell はパスを指定しない限り、現在のディレクトリからスクリプトを実行しません。コマンドの乗っ取りを防ぐように設計されているのです。IPConfig.ps1 というスクリプトを作成した人がいるとします (PS1 は Windows PowerShell スクリプト ファイルのファイル名子拡張子です)。現在のフォルダに含まれていないファイルを実行できるとしたら、実際には Windows プログラム Ipconfig.exe を実行するつもりだったのに、「ipconfig」と入力すると、このユーザーが作成したスクリプトを実行してしまうという危険性があります Windows PowerShell は現在のフォルダに含まれていないスクリプトは実行しないので、この間違いは起こりません。現在のフォルダ以外の場所にあるスクリプトを実行する場合は、パスを指定するだけです。.たとえば、「\myscript」と指定します。現在のフォルダを明示的に参照することによって、スクリプトを実行しているのであって、シェル コマンドを実行しているのではないことがわかります。
Windows PowerShell には、実験を安全に行う機能も備わっています。たとえば、この恐ろしい組み合わせを考えてみてください (ただし、決して試さないでください)。
Get-Process | Stop-Process
Get-Process コマンドレットはプロセス オブジェクトのコレクションを作成して Stop-Process コマンドレットにパイプします。これにより、本当にプロセスが停止します。その結果、重要な Windows プロセスが強制終了されてから約 5 秒後にブルー スクリーンが表示され、STOP エラーが発生します。しかし、次のように非常に便利な –Whatif パラメータを追加することによって、何が起きるのかを実際に発生させることなく見ることができます。
Get-process | Stop-Process -Whatif
これを Windows PowerShell で実行すると、コマンドレットによって何が行われたのか (実際には行われていません) を通知するステートメントの集まりが返されます。Windows PowerShell のオンライン ヘルプ システム (help エイリアスを使用してアクセスできます) では、–Whatif パラメータについてはまだ文書化されていませんが、覚えておいてください。–Whatif パラメータはスクリプトとコマンドレットをテストするための優れたツールで、悪影響を与えたり混乱を招くような操作を実際には一切行わずに結果を確認できます。

まとめ
このバージョンの Windows PowerShell には含まれていない機能の中で、おそらく最も重要なのは、Active Directory® サービス インターフェイス (ADSI) のサポートです。Windows PowerShell では Active Directory で動作する非常に堅牢な .NET クラスを使用できますが、便利な Get-ADSIObject コマンドレットはまだ備わっていません。そのため、ディレクトリ オブジェクトを操作するのが少し困難です。
また、Windows PowerShell は 1 つの作業の実行に対し、多数の異なる方法を提供しています。それはすばらしいことですが、特定の作業について理解するときに、各作業を行う方法について 6 個の異なる例を見ていくことになるので、Windows PowerShell を学習するうえで混乱が生じることがあります。
そのすべてを長い期間をかけて解決する予定です。また、Windows PowerShell チームは引き続き製品に機能を追加していきます。最新情報を入手するには、チームのブログ (英語) を参照してください。

Don Jones は ScriptingAnswers.com の創立者で、『Windows PowerShell: TFM』 (英語、2006 年、SAPIEN Press 発行) の共著者でもあります。Don の連絡先は don@scriptinganswers.com です。


 事後分析: Exchange 5.5 からの移行
事後分析
Exchange 5.5 からの移行
Whitney Roberts

プロジェクト
ケンタッキー州教育省では、既存の Microsoft® Exchange Server 5.5 実装から Exchange Server 2003 に移行する必要がありました。このシステムは、1 年度に約 600,000 名の教職員と生徒をサポートします。
担当者
プロジェクトは、KiZAN Technologies のコンサルタントによる支援を受け、ケンタッキー州教育省の教育テクノロジ局 (OET) が推進しました。既存の Exchange 5.5 実装の管理は OET 局員が監督していました。Exchange サーバーの日常的な運営は、各学区の職員が担当していました。
課題
教育省は、ケンタッキー州内の全 178 学区に、技術的な指示を出します。各学区は WAN で相互に接続されていましたが、学区ごと独自に管理している Exchange 5.5 サーバーをホストしており、それらのサーバーを個別にアップグレードする必要がありました。このアップグレードの成果として、Outlook® 2003 キャッシュ モード クライアントのサポート、Outlook Web Access (OWA) のエクスペリエンスの向上、電子メール アドレス体系の標準化などが期待されました。
新しい電子メール サーバー クライアント インフラストラクチャを展開する以外に、多くの学区が生徒への電子メール サポートを導入しました。州と連邦双方の政策により、生徒の情報を保護し、各学区の外部には非公開にする必要がありました。
計画
Active Directory® コネクタ (ADC) を使用できなかったので、新しい Exchange 組織を作成して、その組織に移行しました。電子メール アドレスの標準化とは、各学区を識別する新しいサブドメインと、400 個を超える新しい受信者ポリシーの両方を作成することでした。生徒のアドレスを保護するため、グローバル アドレス一覧 (GAL) と学区別のカスタム アドレス一覧から構成されるシステムを構築する必要がありました。
実際の移行には、ユーザーが適切なアドレス一覧に表示されるようにするため、新しいハードウェアのステージング、学区のメンバシップとユーザーの種類に基づくメールボックスの作成と構成、および学区のメンバシップとユーザーの種類に基づく拡張属性の設定が必要でした。
構成を誤っているアカウント属性やグループ メンバシップを検出して訂正し、新しいメールボックスが公開要件を満たして適切に提供されるようにするため、Visual Basic® ベースのアプリケーションを作成しました。このアプリケーションを全 178 学区に展開し、学区のサーバーから定期的に実行します。

背景
外見上、この移行は努力が必要で、技術的に困難な作業だとは思われないかもしれません。しかし、私が思い起こす限り、ビジネス要件のルールと、このプロジェクトのビジネス要件は驚きと発見の連続でした。
何年にもわたって、管理が分散して標準が乱立した結果、サポートの連携が取れなくなり、OET が主にその収拾に当たっていました。また、Exchange 5.5 実装が学区と教育省の要件を同時に満たすようにする責任が OET にはありました。これは、生徒の電子メールを利用している学区では、州と連邦のガイドラインに従い、生徒の情報を学区の外部に公開しないで保護することを意味します (ed.gov/policy/gen/guid/fpco/ferpa/index.html (英語) を参照してください)。
これらのガイドラインがあるために、Exchange 5.5 では GAL データを共有する他の学区や他の州機関に学区内の生徒の情報をレプリケートできませんでした。というのは、178 個の Exchange 5.5 サイトすべてで、生徒を非表示にし、一覧をレプリケートして、生徒の非表示を解除して、最後にアドレス一覧にインポートするエクスポート/インポートを手作業で行う必要があったからです。この方法を行えば、他学区には職員のデータしか公開されず、情報を持つ学区では自学区のすべてのデータと他学区の職員のデータのみが公開されます。
既存のシステムの強みと弱みを踏まえて、メッセージ インフラストラクチャのアップグレードはいくつかの条件を満たす必要がありました。まず、ケンタッキー州教育省は、このシステム全体で使用する共通でわかりやすい SMTP 命名体系の標準化を目指しました。この体系では、教員と生徒に個別の SMTP アドレス空間を提供する必要がありました。
新しいシステムでは、メッセージ管理と可用性維持の責任から学区を解放するための、一括管理サービスを提供する必要がありました。これは、災害復旧、メール フロー、およびヘルプデスクの電話サポートの管理を一元化することを意味します。したがって新しいシステムには、任意のユーザーの地理的な場所や帰属する学区にとらわれず、すべての学区のユーザー構成を標準化するための一元的な方法が必要でした。
さらに、全学区で共通の統一された名前空間を使用して、モバイル デバイスから Web ベースで安全に電子メールにアクセスできるようにする必要がありました。
これらの要件の多くが既存の Exchange 5.5 システムに実装されていなかったこともあり、Exchange 2003 へのアップグレードは前途多難に見えました。

ソリューションの構成
上記のビジネス要件を満たすため、展開に当たり Exchange 固有のオプションを決定しました。
標準化が行われていないこと、および純粋な Exchange 5.5 環境だったことから、ADC は使用しませんでした。代わりに、新しい Exchange 組織を作成し、その組織に移行しました。
各学区で職員と生徒の電子メールを整理、標準化したところ、400 個を超える新しい受信者ポリシーができあがりました。各学区を一意に識別するサブドメインを使用し、さらに学区内で生徒を識別できることが要件に盛り込まれました。たとえば、Shelby 郡の場合、プライマリ サブドメインが shelby.kyschools.us になります。各学区の生徒には、stu. というサブドメインを与えました。Shelby 郡の生徒のアドレスは stu.shelby.kyschools.us となります。
生徒のアドレスは所属する学区内のみで公開して、職員のアドレスは他学区にも公開するという制限もありました。そのため、図 1 および図 2 で示すような、GAL とカスタム アドレス一覧から構成される込み入ったシステムを構築する必要がありました。Exchange 2003 に移行するメリットは、アクセス許可を使用してアドレス一覧をセキュリティで保護できること、およびグループ メンバシップを使用して各アドレス一覧へのアクセスを制御できることです。この機能を活用し、学区レベルのセキュリティ グループを 2 つ作成しました (職員用と生徒用)。続けて、それぞれのグループに対応する学区の職員と生徒の GAL とアドレス一覧をセキュリティで保護し、特定の学区のユーザー アカウントのみが特定のアドレス一覧にアクセスできるようにしました。既定の GAL とアドレス一覧を削除し、各アドレス一覧のアクセス制御リスト (ACL) から Everyone グループおよび Authenticated Users グループを除外したことで、特定の学区の特定の種類のユーザーが参照できるアドレス一覧を事前に選択できるようになりました。
図 1 役割に基づくカスタム アドレス一覧
図 1 役割に基づくカスタム アドレス一覧 (画像を縮小するには、ここをクリックします)
図 1 役割に基づくカスタム アドレス一覧
図 1 役割に基づくカスタム アドレス一覧 (画像を拡大するには、ここをクリックします)
しかし、アクセス許可で解決できたのは、公開/非公開の問題の一部のみでした。どのアドレス一覧にだれを公開するかを制御する方法を考案する必要がありました。基本となるライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリを作成し、そのクエリで職員と生徒の公開/非公開をクエリできるようにしました。次に、アドレス一覧および GAL ごとにこのクエリを少しずつカスタマイズしました。たとえば、Shelby の職員の GAL に使用する LDAP クエリは、Shelby の職員と生徒、および州内のすべての他学区の全職員のみを表示します (他学区の生徒は表示されません)。Shelby の生徒の GAL には、Shelby の職員と生徒のみが公開され、州内の他学区の職員や生徒は公開されません。このクエリを、組織内のすべての学区について繰り返しました。図 3 に、この複雑な移行で使用した LDAP クエリの例を示します。
Figure 3 アドレス一覧の LDAP クエリ (Close Figure 3)

職員用 GAL の LDAP クエリ
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
学区のアドレス一覧の LDAP クエリ
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
学区の生徒のアドレス一覧の LDAP クエリ
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
学区の職員のオフライン アドレス一覧の LDAP クエリ
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
図 2 職員と生徒を分離したグローバル アドレス一覧
図 2 職員と生徒を分離したグローバル アドレス一覧 (画像を縮小するには、ここをクリックします)
図 2 職員と生徒を分離したグローバル アドレス一覧
図 2 職員と生徒を分離したグローバル アドレス一覧 (画像を拡大するには、ここをクリックします)
Exchange ユーザー プロパティ extensionAttribute14 (カスタム属性 14) および extensionAttribute15 (カスタム属性 15) のカスタム値は、LDAP クエリの背後にある識別メカニズムです。州内のすべての職員と生徒は、ユーザーの種類を示す特定の値を extensionAttribute14 で、学区の帰属を示す一意の値を extensionAttribute15 で使用します。学区別の一意の値と、ユーザーの種類を示す共通の値を使用することで、各学区の各ユーザーに必要な情報が的確に公開されます。
このアドレス一覧は、非キャッシュ モードの Outlook または OWA を使用して電子メールにアクセスするユーザーに対して適切に機能しました (msExchQueryBaseDN 属性を使用して、各ユーザーが OWA で正しいアドレス一覧にアクセスできるようにしました)。しかし、キャッシュ モードで Outlook を実行しているユーザーに、別の問題が発生しました。カスタマイズした GAL は指定のオフライン アドレス帳 (OAB) として認識されないので、GAL と重複するアドレス一覧を別に作成する必要がありました。キャッシュ モードのユーザーのため、各学区のメールボックス ストアを適切な OAB アドレス一覧で構成しました。すべてを考慮すると、全 178 学区のさまざまな種類のユーザーに完全な機能を提供するには、1,500 個を超えるアドレス一覧が必要でした。

準拠の確認
配置する構造が適切に機能するには、新しく確立した標準に従うことが最も重要でした。組織内のすべての Exchange ユーザーに対して、高度な作業を行う必要がありました。各ユーザーが、すべての学区の Exchange サーバーで正しい場所に配置され、正しいアドレス一覧に公開される必要があるためです。
適切なアドレス一覧を開くためのアクセス許可はセキュリティ グループによって与えられるため、ユーザーは学区のドメイン内の適切なセキュリティ グループに属す必要がありました。また、学区と組織単位 (OU) のメンバシップに基づき、msExchQuerybaseDN 属性を正しく設定する必要がありました。ユーザーの種類はユーザーの OU で判断します。
次に、学区のメンバシップとユーザーの種類に基づき、適切なサーバーの適切なストアにユーザーのメールボックスを作成しました。その結果、Outlook キャッシュ モードを正しく機能させるため、サービス レベル、メールボックスのサイズ制限、およびオフライン アドレス帳のアドレス一覧に影響が及びました。ユーザーが適切なアドレス一覧に表示され、それ以外のアドレス一覧に表示されないようにするため、学区のメンバシップとユーザーの種類に基づいて拡張属性を設定しました。
最後に、アカウントの属性またはグループ メンバシップが、不適切な値に誤って構成 (または変更) された場合に自動修正するための方法が必要でした。ユーザーをある OU から学区ドメイン内の別の OU に移動すると、ユーザーの分類が変わることになるので、メールボックスの場所、GAL の選択、アドレス一覧の表示/非表示を更新する必要があります。
以上の作業を完遂し、Active Directory の整合性と正確性が保証されるプロビジョニング システムが必要でした。私たちは、学区の Exchange 2003 サーバーから定期的に実行する Visual Basic ベースのコンソール アプリケーションを作成しました。このアプリケーションは、ポリシーと標準に従っているかどうかをチェックすると共に、新しいオブジェクトの作成と、プロビジョニングを行います。全 178 学区にこのアプリケーションを展開しました。
当面の作業は、スクリプトを実行して短時間で信頼できる結果を得るには複雑すぎると感じていました。そこで、効率の良さ、エラーと例外の処理のサポートが構造化されていること、将来的に最小限の書き直しのみで内部コードを Microsoft Identity Integration Server (MIIS) 拡張コードに簡単に対応させられることから、Visual Basic ベースのアプリケーションが適切なソリューションだと判断しました。
新しい組織に移行する途中だったので、共存の方法を模索する必要がありました。新しい環境でサポートする既存の SMTP ドメインは 178 個を超えていました。生徒用の電子メール ドメインがある学区とそうでない学区があったためです。しかし、私たちは、学区を一度に 1 つずつ移行して、他の学区に影響を及ぼすことなく、既存のメッセージとアドレスを新しいシステムに移行する余裕がありました。ただし、Exchange 5.5 から Exchange 2003 に学区を移行するときに、電子メール フローを中断することは避ける必要がありました。つまり、Exchange 2003 Active Directory と既存の Exchange 5.5 ディレクトリを何かしらの方法で同期する必要がありました。マイクロソフトはケンタッキー州教育省による MIIS の使用を移行期間中のみに制限しました。そのため、移行の前、期間中、後に MIIS 経由で 2 つの Exchange 組織を同期するカスタム拡張コードを開発して使用しました。
新しい Exchange 組織への移行は、必然的に MAPI クライアント構成に影響します。移行の際に再構成が必要な MAPI ユーザー プロファイルが、学区レベルで数万件あるという事実に直面しました。マイクロソフトが Exchange プロファイル更新ツール (ExProfRe.exe) をリリースしていたので、それを使用して学区のプロファイルを移行しました。学区レベルのプロファイル移行を自動的に実行するため、あらかじめ読み込んだ値で ExProfRe.exe を実行するパッケージ インストーラを作成しました。このインストーラをグループ ポリシー経由で呼び出しました。組織間のプロファイル自動移行の成功率は、ほぼ 100% でした。

ハードウェアのアップグレード
新しい Exchange 2003 サーバーは、地理的に分散していた Exchange 5.5 サーバーの後継になるので、このソリューションは、Exchange 5.5 展開と同数のユーザーに加え、追加される生徒用アカウントの負荷をハードウェア面でサポートできる必要がありました。学区間のすべてのトラフィック (インターネットおよび内部ネットワーク) が専用の T1 回線 (学区によっては複数の T1 回線を持ちます) を流れるように WAN トポロジをデザインしたので、サーバーを学区内でローカルにホストする必要がありました。
予算、管理、設備の都合により、Exchange サーバーには記憶域ネットワーク (SAN) で接続したストレージがありません。すべてのストレージを内部ネットワーク経由か、または直接接続する必要がありました。ほとんどの学区にはサーバー ラックと集中冷房が整ったデータセンターの設備がないので、できる限り自己完結型のサーバーを構成する必要がありました。ほとんどの学区はユーザーが 5,000 名未満なので、サーバーを 1 台のみ展開しました。ユーザーが 5,000 名以上の学区では、高性能の (または複数の) サーバーを使用したり、ストレージを増設したりしました。また、生徒と職員のトラフィックを分離するため、独立したフロントエンド サーバーを設置する場合もありました。
ほとんどの学区で、最大 15,000 RPM の Ultra320 SCSI ドライブ、複数の RAID コントローラ、および 4GB の RAM を搭載したデュアルプロセッサ サーバーを展開しました。大規模な学区には、1 台以上のクワッドプロセッサ サーバーと、必要に応じて簡易フロントエンド サーバーを設置しました。展開前のベンチマークおよびパフォーマンスのテストでは、使用率と負荷に問題はありませんでした。ただし、各学区での使用度合いの違いにより、サーバー全体のパフォーマンスを実際に決まります。

実証テスト
運用環境は 178 個のドメインを含む Active Directory フォレストですが、実証試験 (POC) 環境は 13 個の学区ドメインと空のルート ドメインに規模を縮小しました。テスト ドメインは、すべて運用ドメインからエクスポートしたデータを使用しました。Exchange 5.5 の仮想サーバーを構築し、選抜した学区のデータベースのコピーで構成して、移行プロセスと計画環境からの構築をテストできるようにしました。POC テスト環境全体は、ベースラインを設け、固定し、必要に応じて展開し直せるように、仮想マシンで構成しました。
スクリプト (VBScript を使用)、Systems Management Server (SMS) インストーラ パッケージ、およびコンソール アプリケーションのさまざまな組み合わせを考案、コーディング、およびテストして最終的に承認しました。最後に、受信ポリシー、GAL、カスタム アドレス一覧、アクセス許可を含めた Exchange 2003 の最初のセットアップと構成を行うスクリプトを用意しました。さらに、管理者グループの構成、学区ドメインの構成 (セキュリティ グループの作成とアクセス許可の委任)、および展開後の移行のための構成もスクリプトで行います。
Exchange 2003 サーバーのステージングには、大きな課題がありました。全 178 ドメインで、移行の他の部分に悪影響を与えないようにして、すべての Exchange サーバーを正常にインストールする必要がありました。Exchange 2003 は Exchange 2000 と異なり、ドメインの最初の Exchange 2003 サーバーがインストールされるまでドメイン固有の Exchange Domain Servers グループが組織の ACL に追加されません (Exchange 2000 では、DomainPrep プロセスを実行すると追加されます)。必要なセキュリティ グループがすべて Active Directory の組織オブジェクトに列挙されるようにするため、あるドメインでインストールを行い、そのドメインから Active Directory レプリケーション ハブ サイトに Active Directory を手動でレプリケートして、次にインストールする学区にそのレプリケーションをプルする必要がありました。前の学区の Exchange Domain Servers グループが組織オブジェクトの ACL に追加されたことを確認しないと、次の学区を安全にインストールできませんでした。1 つのドメインでもこのプロセスの手順を誤ると、(最低でも) その学区を再インストールする必要がありました。再インストールを怠ると、組織オブジェクトの ACL に他のすべての学区が正しく列挙されないことが原因で、他の学区が学区間で通信できなくなります。
展開、構成、サーバーのステージング、および移行を全体的に何度もテストした後で、POC 環境でこのプロセスが有効に機能すると判断しました。

移行と肥大化の問題
プロジェクト チームが POC の手順と結果を承認して、移行の開始準備が整いました。OET は、プロセスと結果を直接把握できるように、最初は自分たちで移行を行いました。移行の際、すべてのサーバーは既にステージングを終え、初期環境の検証が済んでいました。すべてのフロントエンド プロトコル サーバーおよびメールボックス サーバーは正しく配置され、ユーザーによる運用に入る準備が整っていました。
移行計画は順調に実行されました。21 時間後、別のサーバーに内容を転送して OET の作業は終了し、Exchange 2003 が稼動しました。さいわい、Outlook プロファイルを Exchange 5.5 から Exchange 2003 に移行するときは、大きな問題が発生しませんでした。私たちは単純なロジックを基に、さまざまな構成で ExProfRe.exe を呼び出すバッチ ファイルのパッケージを作成しました。このバッチ ファイルと ExProfRe.exe を各学区のドメイン コントローラ (DC) の Netlogon 共有に配布しておき、グループ ポリシーを使用して移行の最後にすべてのクライアントにバッチを実行しました。OET でこの方法がうまく機能したので、私たちはプロセスを先に進める自信を持ちました。
この時点で、OET の展開に対する経験を基に、移行計画の再レビューと再承認を行いました。移行を進めるため、最初の運用サイトにする 6 個の学区を選定しました。各学区で移行を行う前に、Exchange 5.5 から学区のメールボックスについての最新情報を MIIS で読み取って、学区ドメインの対応ユーザーを更新します。組織間でのメールボックスのデータ移動には、Exchange 移行ウィザード (Mailmig.exe) を使用しました。メールボックスのデータを移動する間、MIIS が最初に Active Directory にエクスポートしたプロキシ アドレスが収集され更新されました。移行のときは、フロントエンドの SMTP サーバーのキューにメールが入り、移行、移行後のサーバー構成、およびユーザー テストが完了した後で解放されます。この段階で、その学区は ExProfRe.exe を使用して広範囲にクライアントを移行できる準備が整います。

RUS についての論争
Outlook クライアントが正常に機能するには、最終的にプロビジョニング ソリューションで属性値を設定する必要がありました。アカウントを設定する作業を完了するには受信者更新サービス (RUS) も必要ですが、RUS はプロビジョニングの完了後にのみ実行するべきです。そのため、学区の RUS インスタンス (全 178 個) のスケジュールを実行されないように設定して、プロビジョニングの完了後に RUS を起動するコードを使用しました。
ほとんどの学区はユーザーが 5,000 名未満で、1 日に発生する更新はユーザー数に比べわずかです。プロビジョニング システムが 1 日の実行の最後で再構築ではなく更新を行うことで、RUS は短時間で完了しました。しかし、ユーザーが 10,000 名を超える学区もあります。このような環境での更新は時間がかかりました。このように大きなドメインで RUS の再構築を完全に行うと、1 週間以上かかります。RUS は実行時にすべてのオブジェクトの種類を評価するので、大きなドメインでの再構築は負荷が高すぎます。
移行の戦略は考案できませんでした (Exchange 製品グループのメンバと協力して解決策を考案してみました) が、プロビジョニング コードを拡張して、通常なら RUS が行う動作の大部分をこのコードで行うようにしました。RUS が作業を完了するまで待つことなく、すぐにログインできるようにするため、最初のプロビジョニングのときに showInAddressBook 属性と proxyAddresses 属性に値を設定します。フロントエンドの Exchange 2003 プロトコル サーバーの 1 台で実行する手動のタスクも作成しました。これは、環境に誤って受信者ポリシーが適用された場合に、システムのすべての RUS のタスク一覧に列挙されないようにするため、LDIFDE でのインポートを定期的に行い RUS の gatewayProxy アドレスを消去するタスクです。

カテゴライザの問題
生徒のデータを学区外に出さないようにするため、生徒が学区外のユーザーやシステム外部のインターネット アドレスに電子メールを送信できないようにするコントロールを実装しました。コネクタと関連アイテムを複雑に組み合わせたシステムを構築するのではなく、Exchange 2003 のあまり知られていないある機能を実装し、学区からフロントエンド プロトコル サーバーのある中央ハブを結ぶ既存のルーティング グループ コネクタで、コネクタの制限を使用しました。各ドメインに、職員用と生徒用の 2 つのセキュリティ グループを作成し、これらのグループをコネクタの制限に追加しました。
レジストリでコネクタの制限をチェックするようにしたところ、パフォーマンスが低下する問題が見られました。メッセージが、同じサーバーの受信者宛てであっても、カテゴライザとローカルの配信キューに数時間スタックするのです。この問題は、移行する学区が増えるにつれ悪化しました。短期的な解決策としてコネクタの制限のチェックを無効にすると、メール配信のパフォーマンスが改善しました。調査を進めた結果、メッセージを送信するときに、カテゴライザが自身のドメインの 2 つのグループのメンバシップだけでなく、他の 177 個のドメインにあるその 2 つのグループのメンバシップをチェックしていたことがわかりました。このチェックは、サーバーに着信または送信されるすべてのメッセージに行われていました。
この後、マイクロソフトとサポート ケースを開きました。評価を終えて、マイクロソフトは現在、カテゴライザを単純なトポロジ モードで動作することで、問題を改善する修正プログラムを作成しています。この記事の公開時点で、修正プログラムに関する詳細は公開されていませんが、目標は、カテゴライザでルーティング トポロジについて仮定を行い、すべてのコネクタのグループ メンバシップをチェックしないようにする設定を実現することです。

得られた教訓
このプロジェクトから改めて学んだことがあるとすれば、ビジネス要件によってコンサルタントのすべての業務が決定されることです。ビジネス要件の妥当性とソリューションの複雑さをはかりにかけることが何度もありました。このコラムに書いた判断や選択は、今回の環境 (時間がなくてここで説明できなかった要因も含む)、リソース、およびビジネス要件に最も適合していると考えたものです。プロジェクトが異なれば、別の判断が下されるかもしれませんが、このコラムが皆さんの検討材料になればと思っています。今回のプロジェクトでは、Exchange 2003 と Active Directory を使用したことで、この複雑な移行のすべての要件を満たす柔軟性を得ることができました。ケンタッキー州教育省での展開の規模は相当でしたが、実際のソリューションはむしろ単純であり、Active Directory と Exchange 2003 のあまり活用されていないと思われる機能を使用して構築されています。
また、トラブルシューティングやリスクおよび問題の管理にスムーズに対処する方法を訓練する経験にも恵まれました。現地に赴いてのトラブルシューティングが適切な場合と、マイクロソフト製品サポート サービスの知識のあるスタッフに電話連絡する必要がある場合があります。

今後の展望
ケンタッキー州教育省の環境は独特です。展開を進める間、教育省の要件を満たすために Exchange のほぼすべての機能を使用またはカスタマイズしました。現在は、すべての環境全体の展開と移行が無事完了し、追加機能を実装する段階です。各学区が Windows Mobile® プラットフォームに関心を寄せていることが既にわかっています。モバイル デバイス導入の動きは今後も継続すると見られます。
サーバー統合により、大きな価値を得ることができます。ケンタッキー州教育省は、現在、Active Directory 環境の一部の仮想化を目指しています。さらに、Exchange 2007 のリリースを控え、メッセージ システムのアップグレードの要件を調べ始めました。
同省は、Live Communication Server、Live Meeting Server などでコラボレーションを提供する検討を進めています。Exchange サーバーと Active Directory サーバーを管理および監視するため、Microsoft Operations Manager 2005 も現在展開中です。

成果
この実装の良し悪しや普及の度合いは、ケンタッキー州の公立学校システムを利用するすべての子供に影響します。私自身の子供や、このプロジェクトで共に働いた仲間の子供も例外ではありません。ケンタッキー州教育省は、この実装を導入したことで、今までになく短時間に、安全で標準化されたテクノロジを採用しました。このようなプロジェクトの一員になれたことを誇りに思っています。

Whitney Roberts は KiZAN Technologies (www.kizan.com (英語)) のプリンシパル コンサルタントであり、Exchange 4.0 のリリース以来、Exchange の業務を行っています。


 SQL に関する Q&amp;A: 再起動の防止、複数の更新プログラムのインストールなど
SQL に関する Q&A
再起動の防止、複数の更新プログラムのインストールなど
Nancy Michell

再起動の防止

Q 一般に、修正プログラムなどを SQL Server やサーバー オペレーティング システムに適用する際に、再起動の回数を制限する方法はありますか。

A まず、インストール後に行われるほとんどの再起動は、インストーラにハードコーディングされたものではないことを知っておくとよいでしょう。通常は、ファイルがロックされている場合に再起動が行われます。つまり、他のアプリケーションやオペレーティング システムが現在使用 (ロック) しているファイルをインストーラが更新しようとしています。このような再起動を回避するには、問題のファイルを使用しているプロセスがないことを確認するだけです。では、これを行うにはどうすればよいでしょうか。
最初に、インストール中に使用されていたファイル、およびロックされたファイルを特定します。最も簡単な方法は、レジストリの HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations でこのようなファイルを探すことです。このレジストリ キーを確認すると、2 つのことがわかります。1 つは本当にファイルがロックされていることが原因で再起動の要求が発生したかどうか、もう 1 つはどのファイルがロックされたのかということです。インストール後、再起動の前にこれらのキーを調べることにより、再起動が要求された原因を特定し、今後のインストールでその原因を取り除くための対策を講じることができる可能性があります。
表示されるエントリは 2 種類あります。ファイルに読み取りロックがかけられている場合は、ファイルごとに 1 行のエントリが表示されます。これは、更新されたファイルが既にディスク上に存在するが、そのファイルの一時コピーがまだ使用されているので削除する必要があることを示しています。ファイルに書き込みロックがかけられている場合は、ファイルごとに 2 行のエントリが表示されます。これは、更新がまだ行われておらず、アプリケーションの状態が不明であるため、ファイルを使用できないことを示しています。まさにセットアップが途中で停止されたことを示します。この場合、1 行は実際のファイル、もう 1 行は一時ファイル (再起動時に実際のファイルになります) を示しています。
次の手順は多くの要素に依存しますが、目的はロックされたファイルを使用しているソフトウェアを特定することです。可能な場合は、依存関係チェック ツールを使用します。チェック ツールがない場合は、MSDN® の DLL HELP データベース (support.microsoft.com/kb/815065 を参照) を使用します。
特定したソフトウェアにサービスが含まれている場合は、そのサービスを手動で停止してから再度テストを行います。アプリケーションの場合は、終了してから再度テストを行います。複数のアプリケーションが 1 つのファイルを使用していることもあるので、その場合はそれらのアプリケーションをすべて終了する必要があります。
これらの (テスト環境での) テストの結果、運用環境でインストールを実行する前に停止する必要があるアプリケーションとサービスの一覧が得られます。これで、インストーラがインストールするファイルをロックするソフトウェアが存在しなくなるので、運用環境では再起動が要求されません。もちろん、インストールが完了したらこれらのソフトウェアを再起動することを忘れないでください。
この解決策のメリットは、通常、ロックがそれほど変更されないということです。このため、一度システムのパターンを理解すれば、そのシステムを使用している間、多くの再起動を回避できます。
もう 1 つ紹介したい技があります。SQL Server™ や他の製品の複数のバージョンが並列インストールされていて、さらにこれらの製品間のバージョン レベルも異なる場合があります。更新は常に最新のバージョンから行う必要があります。この更新によってすべてのファイルが最新のバージョンに置き換えられ、他のすべてのインスタンスを更新する際にロックに関する問題が発生しなくなる可能性は高いと言えます。たとえば、SQL Server 2000 SP3 のインスタンスが 3 つある場合、1 つ目のインスタンスを SP4 にアップグレードすると MSXML3.dll ファイルがアップグレードされ、再起動が必要になります。ここで再起動を行ったとしましょう。これで MSXML3.dll ファイルが更新されるので、残りの 2 つのインスタンスを SP4 にアップグレードするときに再起動が不要になります。SQL Server 2000 インスタンスの前に SQL Server 2005 インスタンスをアップグレードした場合や、SQL Server 7.0 インスタンスの前に SQL Server 2000 インスタンスをアップグレードした場合も同じことが言えます。これは一般に再起動の回数を最小限に抑えるために使用される、非常に効果の高い方法です。
大きな枠組みで考えると、マイクロソフトの開発チームはさまざまな場面で再起動を回避したりその回数を制限するための研究を数多く行ってきました。今回は「SQL に関する Q&A」のコラムなので、SQL Server を例に挙げてみましょう。
SQL Server 2005 の開発時に、SQL Server チームは Microsoft® Data Access Components (MDAC) 全体を更新するのではなく、SQL Server に必要な MDAC のコードを新しい SQLNCLI ファイルに分離し、残りの MDAC を再度 OS に組み込みました。これがどのように役立つのでしょうか。Windows® オペレーティング システム自体が MDAC を使用し、これらのファイルを常にロックしています。このため、SQL Server の Service Pack やその他のパッケージのインストール時には常に再起動が必要でした。SQL Server 2005 では、OS が使用している MDAC ファイルに対して処理を行うことなく SQL Server 2005 用の MDAC を更新するので、再起動が不要になります。
さらに、SQL Server 2005 SP1 セットアップには依存関係チェック機能と一時停止機能が組み込まれています。この機能により、ロックされているファイルとロックをかけている可能性が高いソフトウェアが表示され、再起動を行うことなくその場でロックを解除してセットアップを続行できます。つまり、テスト ラボでテストを行うことなくリアルタイムでロックに対処できます。もちろん、再起動が発生してもかまわない場合や無人モードで実行している場合など、単純に続行して再起動を行うことも常に可能です。この機能により、ファイルをロックしているソフトウェアの特定が非常に簡単になります。
また、Microsoft インストーラ テクノロジによる既存の PendingFileRenameOperations (PFR) の処理も強化されました。SQL Server 2000 セットアップでは、上記で説明したレジストリ キーにファイル名が追加されるとセットアップがブロックされることを思い出してください。SQL Server 2005 セットアップには、それらのファイルが SQL Server に属している (競合が発生している可能性がある) 場合のみセットアップをブロックするという優れた機能がありますが、そのような場合でも PFR キーを参照し、再起動を要求することなく直接それらのファイルを更新できる場合がほとんどです。このテクノロジは、現在あらゆる更新プログラムの実行に使用されている標準 Microsoft インストーラの MSI と update.exe の両方に、ある程度ではありますが含まれています。
再起動が行われることがわかっているファイルにはどのようなものがあるでしょうか。最大の原因になるファイルの 1 つが MSXML3.dll です。このファイルは常に Windows SVCHost サービスによってロックされるので、このサービスを含むコンピュータでは再起動が必要になります。またこのファイルは、ほとんどの MDAC スタック (mdac_typ.exe) にも含まれています。さいわい、MDAC は Windows Server® 2003 と Windows XP SP2 以降に含まれています。SQL Server 開発チームが msxmlsql.dll を分離するというすばらしい仕事をしたことによって、SQL Server の更新プログラムを適用するときの再起動はなくなりましたが、もうしばらくはときどき再起動が発生するでしょう。発生した場合の対策はありません。SVCHost を終了すると、更新プログラムを実行できなくなります。
また、update.exe パッケージのアンインストール プロセスでも特殊な動作が発生します。いずれかの update.exe パッケージをアンインストールすると、インストーラの配置済みファイルが (もちろん PFR キーの外部で) ロックされます。これにより、再起動を行ってそのロックを解除するまで他の update.exe パッケージを実行できなくなります。この場合は、この動作が発生することを承知して、修正プログラムのアンインストール後に再起動を計画するしかありません。
もう 1 つの問題は断続性です。すべてのプログラムが、実行中に常にファイルをロックしているわけではありません。実際、共有 DLL はほとんどの場合、特定の時点でしか使用されません。つまり、他のプログラムは負荷とコード パスに応じて、必要なときだけこれらのファイルにアクセスします。これは、10 回テストを行ってファイルがロックされなくても、運用環境への展開時にファイルがロックされる可能性があるということです。あいにく、この問題に対する効果的な解決策はありません。負荷 (少なくとも適切な目安) も含め、できるだけ運用環境に近いテスト環境を構築し、このような変化が発生しないように十分なテストを行ってください。
OS の Service Pack とアップグレードは再起動を必要とします。下位バージョン (Windows 2000、Windows XP などの以前のバージョン) では、pendingfilerenameoperations レジストリ キーが空の場合でも、再起動が完了するまでインストールは完了しませんでした。この再起動中に、コードをインストールするための例外パッケージの登録操作が実行される場合があります。これらの操作は Service Pack のセットアップの一部ではなく、アップグレード シナリオによって起動される、現在のオペレーティング システムの埋め込みコマンドです。これらのコマンドにより、現在使用している特定のコードをアップグレード後も使用できるようになります。
最後に、PFR キーはファイルのバージョン チェックを実行せず、シリアル化の順序も強制しません。つまり、リストに格納された順にファイルの置換が開始されます。しかし、ハード ディスクに適用される順序は、最初に置換を開始したファイルが最初に適用されるのではなく、置換が最後に完了したファイルが最後に適用されます。これは理にかなっていますが、同じパスに同じファイルの 2 つのコピーがあり、それぞれが異なるバージョンを指している場合、再起動後の結果は一定ではありません。このような問題が発生した場合は、問題を解決する必要があります。問題があるかどうかがわからない場合は、単純に再起動後に両方のインストーラを実行します。正しいファイルが適用されている場合、追加操作は不要です。誤ったファイルが適用されている場合、正しいファイルを含むパッケージを実行すると問題は解決します。率直に言うと、必要な結果を考えるよりもこの方法を使用した方が時間がかからず、安全です。

複数の Service Pack のインストール

Q 4 ノード クラスタで 8 個のクラスタ化された SQL Server 2000 インスタンスを実行しており、最小限の再起動回数で SP4 をインストールすることを考えています。8 個のインスタンスすべてに SP4 を順番にインストールして、最後にすべてのノードを再起動することはできますか。

A 特定の Windows サーバー (クラスタ化されていない場合も含みます) に 1 つの SQL Server SP4 インスタンスを完全にインストールした後は、そのサーバー上にある他の SQL Server インスタンスに SQL Server SP4 をインストールしても再起動は行われません。これは、ツール、MDAC、MSXML など、すべての共有ファイルが既に正しいバージョンであり、ロックされていても、これ以上更新する必要がないためです。共有されていないすべてのファイルは、最初のインスタンスでのみ使用され、このインスタンスはセットアップによって停止されます。バージョンが異なる複数の SQL Server インスタンスを実行している場合、最も新しいインスタンスを最初に更新してください。

Network Service としての実行

Q NT AUTHORITY\NETWORK SERVICE アカウントとは何ですか。またその主な目的は何ですか。さらに、このアカウントに sysadmin (sa) 権限を与えた場合、セキュリティ面でどのような影響がありますか。

A ネットワーク上の Network Service アカウントの ID (コンピュータ ID) は System アカウントと同じですが、ローカル コンピュータに対する特権が System アカウントよりも制限されています。このため、あるサービスからネットワーク リソースにアクセスする必要がある場合 (おそらくドメイン コントローラでアカウント名を解決することが目的です)、System、ドメイン アカウント、または Network Service で実行する必要があります。一般には、ローカル コンピュータのみを対象とし、特権が制限されている Network Service を使用した方が安全です。
Network Service を SQL Server の sysadmin に追加すると、ローカル コンピュータで Network Service として実行している他のすべてのサービスに、サーバーに対するフル コントロール権限が与えられます。この状況は、SQL Server サービス アカウントを Network Service で実行するように構成している場合などに発生します。サーバーの機能 (ループバック接続の許可など) を有効にするには、SQL Server サービス アカウントを sysadmin のメンバとして追加する必要があります。SQL Server で Network Service を管理者として実行するのはセキュリティ面から見てあまりよくありませんが、同じ目的にドメイン アカウントを使用するよりは適切でしょう (適切でない場合もあります)。また、SQL Server を LocalSystem で実行するよりも安全です。
Network Service に sysadmin 特権を与えたくない場合、次に検討する選択肢は、1 つ以上の Windows NT® のインストールで SQL Server を実行するときに専用のドメイン アカウントを使用する方法です。
次の記事に関連情報が記載されています。microsoft.com/japan/msdn/enterprise/pag/securityguidance/paght000009.aspx と microsoft.com/technet/security/topics/serversecurity/serviceaccount (英語) を参照してください。

複数のデータベースの作成

Q データを複数のデータベースに分割し、最大 250 個ぐらいのデータベースを同時にオンラインにすることを考えています。アクティブなクエリに使用できるデータベースは、いずれの時点でも 20% のみであると予想しています。データベースの数を増やすメリットはありますか。

A 1 つのデータベース サーバー インスタンスに配置するデータベースの数は、ビジネス ニーズと管理上の要素に応じて決定する必要があります。1 つのサーバー インスタンスに複数のデータベースを作成する際のオーバーヘッドはほとんどありませんが、データベースの数が増えると、バックアップと復元、ミラーリング、ユーザー アカウント、ユーザー ロールなどのメンテナンス タスクにかかる管理オーバーヘッドが増加します。管理上の複雑さが増すことにより、データベースを追加するメリットが相殺される可能性があります。
一般的な規則としては、1 つのアプリケーションに関連するデータは、障害からの復旧を容易にするために、すべて 1 つのデータベースに格納しておきます。アプリケーションのデータが複数のデータベースに分散した場合、フェールオーバー中にすべてのデータベースを復旧する必要があります。この場合、復旧が遅れるだけでなく、復旧できないデータベースがあった場合は復旧自体が失敗します。
そうは言うものの、次のようにデータを複数のデータベースに分散させる理由もあります。
  • データのサブセットのバックアップ要件が他のデータと異なる。
  • 特定のデータに、異なるデータベース所有者などの別のセキュリティ コンテキストが必要である。
  • データを格納する目的が履歴の保存であり、読み取り専用モードでデータを保持する必要がある。

技術的知識を提供してくれたマイクロソフトの次の IT Pro に感謝します。Ramon Arjona、Frank De Waelle、Robert Djabarov、Herman Learmond-Criqui、Maxwell Myrick、Ruslan Ovechkin、Uttam Parui、Shashi Ramaka、Gary Roos、Gavin Sharpe、Vijay Sirohi、Jimmie Thompson、Madhusudhanan Vadlamaani。

Nancy Michell


 Hey, Scripting Guy!: カップホルダーはどこえ消えた?
Hey, Scripting Guy!
カップホルダーはどこえ消えた?
Microsoft Scripting Guy
このコラムは、Windows PowerShell のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

一般的に新しいテクノロジが導入されると、ユーザーが新しいテクノロジとその前身のテクノロジを差別化できるようになるには時間がかかります。たとえば、初期の自動車を例にお話をしましょう。初期の自動車は、馬がない馬車として認識されていましたが、他に特徴がなかったので、このように考えられていたのは仕方がないことでした。突き詰めると、初期の自動車と馬車の違いは、馬を使用するかしないかという 1 点だけでした。それ以外に、これらの 2 つのものを区別する要素はありませんでした。
今日、自動車と馬車を間違える人は、まずいないでしょう。これは、時間の経過とともに、自動車メーカーが、自動車と馬車の的確な差別化を図ることに成功した証です。たとえば、現在、工場で作られたばかりの自動車には、CD プレーヤー、エアコン、カーナビが備え付けられていますが、そのような装置がある馬車はほとんどないでしょう。1880 年代の馬車に乗っているところを想像してみてください。少しの間、フラペチーノを横に置おいておきたいと思っても、残念ながら、当時の馬車にはそのような場所はありません。これに対して、スポーツ多目的車 (SUV) には、標準で 17 個ものカップホルダーが備え付けられていたり、ドライバー専用のカップホルダーが 3 個備え付けられている車種もあります。また、最新モデルでは、飲み物を冷やしたり、温めたりできるカップホルダーが備え付けられているものもあります。
注 : ドライブ中、一度に 3 種類の飲み物を飲めないという状態に耐えなければならない時代があったのは信じ難いことです。1 ～ 2 種類の好きな飲み物だけでドライブするなんて、到底不可能です。
新しいテクノロジが成功を収めるには、既存の信頼できるテクノロジの代わりに新しい未知のテクノロジを採用する然るべき根拠が必要です。当初 DVD は、自宅で映画を楽しめるようにすることを目的とし、ビデオデッキと何ら変わりありませんでした。しかし、DVD はビデオデッキよりもかなり高価で、DVD プレーヤーを使用して番組を録画することはできませんでした。ご存知のとおり、DVD は、一世を風靡したわけではありませんでした。実際、DVD が VHS の地位を脅かすようになったのは、DVD メーカーが、未公開シーン、出演者のインタビューなど、カセット テープで提供されていなかったものを DVD ディスクに収録するようになってからです。DVD が普及するには、ただ自宅で映画を見れるという機能だけでは不十分で、DVD メーカーは、既存の機能を上回る機能を提供する必要がありました。
注 : この DVD の特典を実際に見ているのかというのは、また別の話です。既にあるものは、あって当然と思うのが人情です。偶然にも、Scripting Guys は、TechNet Magazine で紹介していないコラムとシステム管理スクリプトの別の結末を収録した DVD を発売することを検討しているところでした。

Windows PowerShell を使用する
Windows PowerShell™ は、マイクロソフトによってリリースされた新しいコマンド シェルおよびスクリプト テクノロジです。このテクノロジは、既に紹介したシナリオの一例です。Windows PowerShell という用語を初めて聞くときには、一般的に、次のようなことも同時に耳にすると思います。
  • Windows PowerShell を使用すると、プロセスやサービスを管理できる。
  • Windows PowerShell を使用すると、イベント ログからイベントを取得できる。
  • Windows PowerShell を使用すると、WMI を使用してコンピュータを管理できる。
この情報は、すべて事実です。また、これらは有益かつ重要なタスクです。しかし、ここで問題となるのは、これらのタスクは、VBScript や Windows スクリプト ホストを使用して既に実現できていることです。旧バージョンとの互換性は重要で、VBScript で実現できることができなければ、Windows PowerShell はたいした革新ではないと見なされます (たとえば、仮に映画を見ることができない DVD プレーヤーが実在することを想像してみてください。そのような DVD プレーヤーを持っている Scripting Guy がいるので、実際は仮の話ではありませんが、とにかく、映画を見ることができない DVD プレーヤーを欲しいと思う人はいないでしょう。)
Windows PowerShell を使用しても VBScript が実現できることと同じことしか実現できないなら、そもそも、このコラムでこのテクノロジを取り上げたりすることはありません。正直なところ、VBScript にはカップホルダーはありません。また、Windows PowerShell にもカップホルダーはありません。では、どちらのスクリプト テクノロジを使用するかという判断は、何を基準にしたらよいのでしょうか。
正直なところ、どちらのスクリプト テクノロジを使用しても、それほど大きな違いはないかもしれません。けれども、カップホルダーがないことを除けば、Windows PowerShell には、VBScript にない機能が用意されています。必要な処理がプロセスとサービスの管理だけであれば、「壊れていないものを修理するな」(If it ain't broke, don't fix it) という諺があるように、Windows PowerShell を採用すべき大きな理由はありません (Scripting Guys に言わせると、この諺は、"修正すると壊れるから止めておきなさい" という意味になります)。Windows PowerShell が非常に魅力的なテクノロジとなるのは、VBScript では実現できないことに使用できるときです。たとえば、Windows PowerShell を使用するとファイルの最終書き込み時刻を変更することができます。

最終書き込み時刻を変更する
空耳ではありません。Windows PowerShell を使用すると、ファイルの最終書き込み時刻を変更することができます。バージョン管理の簡略化など、さまざまな理由により、スクリプト作成者は、ファイルの最終書き込み時刻 (または作成時刻) を変更できるようになる日を待ち望んでいました。残念ながら、このような機能は Windows Management Instrumentation (WMI) にも FileSystemObject にもありませんでした。どちらのテクノロジを使用した場合も、ファイルの日付や時刻は読み取り専用の属性でした。
しかし、Windows PowerShell では、次のコマンドを実行するだけで、ファイルの最終書き込み時刻を現在の日付と時刻に変更することができます。
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
このコマンドの動作について説明する前に、多くの読者が抱いていると思われる疑問にお答えしておきましょう。Windows PowerShell では WMI で変更できない最終書き込み時刻をなぜ変更できるのでしょうか。これは Windows PowerShell によくある誤解なので、他のことについて説明する前に、まずこの点について説明することにしました。Windows PowerShell は、単に WMI を使用する新しい方法であると思われがちです。もちろん、Windows PowerShell を使用して WMI のデータにアクセスできるのは事実です。また、追加のコマンドレット (ネイティブな Windows PowerShell コマンド) が構築されるまで、多くのシステム管理スクリプトは、依然として WMI に依存しています。しかし、基本的に、Windows PowerShell は .NET Framework に基づいており、Windows PowerShell のコマンドレットでは、一般的に WMI オブジェクトではなく .NET オブジェクトを処理します。.NET Framework で利用できるプロパティは WMI で利用できるプロパティと同一であるとは限らないので、この点は重要です。
たとえば、Get-Item コマンドレットを使用してファイルをバインドすると、WMI の CIM_Datafile クラスのインスタンスではなく、.NET オブジェクトが返されます。たいした問題ではないと思うかも知れませんが、これは大きな問題です。.NET オブジェクトで公開されるファイルの管理に関するプロパティやメソッドは、WMI オブジェクトで公開されるものと若干異なります。しかし、既に説明したように、プロパティが読み取り専用であるのか、または読み取り/書き込みであるのか、という小さな違いが重要になってきます。
Get-Item コマンドレットから返されたのが .NET オブジェクトであることを、どのように判別しているのかについて説明しましょう。この場合 (また、多くの場合)、処理しているオブジェクトの種類 (または、利用できるプロパティとメソッド) を特定するには、オブジェクトをファイルにバインドし、そのオブジェクトを Get-Member コマンドレットに渡すのが最も簡単な方法です。次に例を示します。
Get-Item c:\scripts\test.txt | Get-Member
このコマンドの結果は図 1 のようになります。ご覧のように、これは .NET オブジェクトです (Script Guys が、このようなことについて間違えることはありません)。
Figure 1 Get-Item で返されるオブジェクトのメンバ (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
偶然にも、この単純なコマンドは、Windows PowerShell が持つ別の 2 つの興味深く、かつ有益な機能を例示しています。それは、パイプラインとメタ情報です。今回のコラムでは、これらの機能についての技術的な説明は行いませんが、パイプラインの基本的な概念は、コマンドレットを使用してオブジェクトを取得し、そのオブジェクトを別のコマンドレットに渡せるということです。このコマンドでは、Get-Item コマンドレットを使用して、C:\Scripts\Test.txt ファイルを表すオブジェクトを取得し、パイプラインを使用して、このオブジェクトを (オブジェクトとして) Get-Member コマンドレットに渡しています (Windows PowerShell コマンドでは、| 文字はパイプラインを表します)。
その後、Get-Member コマンドでは、受け取ったオブジェクトのプロパティとメソッドを取得します。これは Windows PowerShell の優れた機能の一例で、メタ情報 (情報に関する情報) に間単にアクセスできます。Windows PowerShell では、Get-Member や Get-Command などのコマンドレットを使用することによって、利用できる WMI のクラス、プロパティ、およびメソッドに関する情報を取得する WMI スクリプトを記述するのとほぼ同じ方法で、必要なデータを取得することができます。
Get-Member では、WMI スクリプトよりも、多くの処理を行うことができます。WMI スクリプトでは WMI オブジェクトに関する情報を取得できますが、FileSystemObject など、他の COM オブジェクトに関する情報を取得することはできません。しかし、Windows PowerShell では、それが可能です。Get-Member では、バインドまたは作成できる任意のオブジェクトに関する情報を取得できます。FileSystemObject で使用できるメソッドがわからない場合は、次のコマンドを実行すると、このオブジェクトに関する情報を取得できます。
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
これは、非常に便利な機能ですが、あまり活用されていません。
なかなか便利ですね。ファイル C:\Scripts\Test.txt で利用できるプロパティとメソッドの一覧をスクロールしていくと、次のような行があると思います。
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
興味深いことに、LastWriteTime は、get (読み取り) と set (書き込み) の両方をサポートしているプロパティです。これは、Windows PowerShell を使用して、ファイルの最終書き込み時刻を変更できるということになるのでしょうか。ふむ。
Windows PowerShell の用語集
エイリアス 既存のコマンドレットを表すカスタマイズ可能な名前。Windows PowerShell には、一般的なシェル コマンドを対応するコマンドレットにマップする多数の既定のエイリアスが用意されています。
コマンドレット 他のシェルの組み込みコマンドと類似した、Windows PowerShell における機能の最小単位。
コマンド Windows PowerShell における実行単位。コマンドには、パイプラインを使用した複数の操作を含めたり、; 文字を使用して 1 行に複数のコマンドを含めたりすることができます。
フラペチーノ スターバックスで販売しているアイス コーヒー。
Monad/MSH/Microsoft Command Shell Windows PowerShell のコード ネーム。
オブジェクト システムまたはコマンドから取得する構造化されたデータ。Windows PowerShell では、データを .NET オブジェクトとして操作するので、ユーザーはテキスト ベースのコマンド出力を解析する必要なく、名前でオブジェクトのプロパティを操作できます。
パラメータ コマンド ラインでコマンドレットに設定するオプション。Windows PowerShell では、パラメータの指定にハイフン (-) を使用します。
パイプライン あるコマンドの出力を別のコマンドの入力として送信できるようにします。パイプと呼ばれることもあり、コマンドでは | 文字で表されます。
プロファイル Windows PowerShell の起動時に読み込まれる設定で、シェルの動作を指定できます。
スクリプト ファイルとして保存され、またファイルから実行できる 1 つ以上のコマンド。Windows PowerShell では、スクリプト ファイルの拡張子に .ps1 を使用します。
シェル コマンドとコマンドレットの両方を実行できるコマンド ライン環境。
変数 コマンドの実行中にその値を設定、変更、または取得できるオブジェクトまたはパラメータ。

Test.txt の最終書き込み時刻を現在の日付と時刻に設定するコマンドの説明に戻りましょう。以下にこのコードを示します。
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
ご覧のとおり、このコマンドではたいした処理は行っていません。まず、$a という名前の変数を定義します。次に、Get-Item コマンドレットを使用してファイル C:\Scripts\Test.txt に接続します。このコマンドにより、このオブジェクトを変数 $a に格納します。セミコロンを入力した後に、LastWriteTime プロパティの値を現在の日付と時刻に設定します (セミコロンを使用すると 1 行で複数のコマンドを実行できます)。これは、カップホルダーの埋め合わせになりますよね。

少し高度な処理を実行する
もちろん、最終書き込み時刻を現在の日付と時刻以外の日時に変更することは可能です。たとえば、次のコマンドについて考えてみましょう。
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
今度は、3 つのコマンドを使用します。まず、Get-Date コマンドレットを使用して、5/22/2006, 8:15 PM に一致する DateTime オブジェクトを作成しました。最終書き込み時刻を現在の日付と時刻に設定したスクリプトでは、Get-Date を使用して DateTime オブジェクトを作成しませんでしたが、その理由は単に、Date コマンドでは DateTime オブジェクトが自動的に返されるからです (このことを確認するには、Windows PowerShell コンソールで「Date | Get-Member」コマンドを実行してみてください)。
必要な日付と時刻を設定した DateTime オブジェクトを作成したら、次は、Get-Item コマンドを使用してファイル Test.txt を表すオブジェクトを取得します (このオブジェクトは、変数 $a に格納します)。最後に、変数 $b が表す値を LastWriteTime プロパティに設定します (この処理は次のコマンドで行っています)。
$a.LastWriteTime = $b
信じられないかもしれませんが、最終書き込み時刻の変更については、まだ半分もお見せしていません。次の何の変哲もないコマンドを見てみてください。
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
このコマンドの興味深い点は何だと思いますか。このコマンドで行われる処理を見てみましょう。前半部分は簡単です。ここでも、5/22/2006, 8:15 PM に一致する DateTime オブジェクトを作成していますが、後半部分では Get-Item コマンドレットではなく、次のコマンドを使用しています。
Get-ChildItem c:\scripts
このコマンドには、どのような意味があるのでしょうか。Get-ChildItem コマンドレットをフォルダに適用すると、そのフォルダに含まれているすべてのファイルが返されます。このファイル コレクションを取得し、パイプラインを使用して、このコレクションに含まれるすべてのアイテムを ForEach-Object コマンドレットに渡します (ここでも | 文字を使用しています)。
ForEach-Object は、これらのファイルをどのように処理するのでしょうか。もちろん、このコマンドレットでは、各ファイルの LastWirteTime プロパティの値を変更します。
ForEach-Object {$_.LastWriteTime = $b}
注 : 今月のコラムは、Windows PowerShell の初心者を対象としているわけではありませんが、$_ は For Each ループの現在の項目を表す特別な変数であることはお知らせしておきましょう。これは、次のような VBScript ループの objItem に相当するものです。
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Windows PowerShell コマンドの実行が完了すると、C:\Scripts フォルダにあるすべてのファイルの最終書き込み時刻は同じになります。ぜひ、新しいテクノロジである Windows PowerShell を使用して、ファイルの最終書き込み時刻を変更してみてください。
このコマンドの変化形は一晩かけて紹介することもできます。たとえば、フォルダ C:\Scripts にある .txt ファイルについてのみ最終書き込み時刻を変更する場合は、次のコマンドを実行します。
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

食欲を刺激する
Windows PowerShell は非常に優れています。しかし、このコラムの目的は、Windows PowerShell の販促活動でもなく、VBScript スクリプトを廃止して、Windows PowerShell に移行するのを推奨することでもありません。VBScript スクリプトで必要な処理を行え、その処理が必要な場合は、現状のままにしておくべきです。バッチ ファイル、コマンド ライン ツール、おまじない、コンピュータの管理に使用するツールについても同様です。「壊れていないものを修理するな」という諺をお忘れなく。
このコラムで説明したのは、Windows PowerShell を使用して、既に実現できている処理を行えるということではありません。Windows PowerShell を使用すると、.NET Framework にアクセスすることが可能になるので、これまでに実現できなかった処理が行えるようになるということです。その一例が、ファイル (または一連のファイル) の最終書き込み時刻の変更です。このようなニーズに対応できる処理は、他にもあります。Windows PowerShell には、このような優れた機能があるため、このテクノロジの導入を検討してみる価値はあると思います。
多くの読者にとって、このコラムは異色な Windows PowerShell の紹介だったと思います。このコラムでは "Hello, world" のような単純なサンプルを使用する代わりに、パイプラインやコマンドレットなどの専門用語の知識があることを前提に、Windows PowerShell のマルチパート コマンドを紹介するサンプルを使用しました。これは意図的に行いました。Windows PowerShell を試したユーザーは少ないという状況を把握していたので、コンピュータで実行しているサービスの一覧を取得する方法を紹介したら、読者の皆さんをがっかりさせ、皆さんがこのコラムを読まずに、その前に行っていた作業に戻ってしまうのではないかということを懸念していました。
注 : このコラムを読む前に行っていた作業が車の運転でなければよいのですが。多くの人にとって、運転しながら 3 種類の飲み物を飲む、DVD を見る、携帯電話で話をするという 3 つの作業を同時に行うのは、十分に困難だと思います。それに "TechNet Magazine を読む" という作業を加えるのはあまりにも過酷な作業だと思いますから。
おっと、多くの人にとってとは言いましたが、すべての人にとってとは言っていませんよ。

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


 セキュリティ ウォッチ: グローバルに信頼された PKI の展開
セキュリティ ウォッチ
グローバルに信頼された PKI の展開
John Morello
このコラムに含まれているプレリリース情報は変更される可能性あります。

公開キー基盤 (PKI) は、さまざまなアプリケーション、オペレーティング システム、および ID 領域間で信頼を築く際の基本要素です。PKI は、階層信頼モデルに基づいて構築されます。階層信頼モデルでは、エンド エンティティは最上位のルート レベルの共通キーを信頼するため、そのルートによって署名されたその他のキーは暗黙的に信頼されます。
この構造により、適切に設計された PKI は、他の証明機関 (CA) を追加することで簡単に拡張できます。このとき、エンド エンティティは変更されません。
通常、PKI はここで示す 2 つの方法のいずれかを使用して実装します。最も一般的なのは、暗黙的に信頼されたグローバル ルート プロバイダ (Cybertrust や VeriSign) の 1 つから必要に応じて証明書を購入する方法です。これらの証明書の用途の多くは、Web サイト上のトラフィックをセキュリティで保護することですが、仮想プライベート ネットワーク (VPN) の暗号化、電子メールの署名、および同様の作業にも使用できます。このようなグローバル ルートは最新のすべての Web ブラウザおよびオペレーティング システムに組み込まれているため、この方法は、組織の境界を越えた信頼関係を簡単に拡張できます。ただし、この方法では、これらの証明書を必要に応じて購入するため、大規模な組織内で広く展開するにはコストがかかる可能性があります。
最近、内部 PKI モデルはさらに普及しました。名前のとおり、内部 PKI は、組織が所有するネットワーク内でのみ信頼されます。このモデルでは、組織が証明書を使用してそのネットワーク上にすべてのユーザーとコンピューティング デバイスを準備する低コストの方法を提供します。この方法は、スマート カード ログオン、暗号化ファイル システム (EFS)、およびセキュリティで保護されたワイヤレス ネットワークなどのテクノロジを促進するためによく使用されます。欠点は、これらの証明書がグローバルに信頼されていないため、外部に接続するアプリケーションには適さないことです。したがって、内部 PKI を展開した組織の多くは、通常、ハイブリッド手法を採用し、グローバルに信頼されたルートのいずれかから公開アプリケーション用の証明書を購入します。
しかし、両方の利点を生かすことができたらどうなるでしょうか。組織が独自の (内部証明書の発行によりコストを削減した) PKI を実行し、同時に、独自のローカル システムから公的に信頼された証明書をすべて配布できるとしたらどうなるでしょう。このようなソリューションでは、内部 PKI の利点 (Active Directory® の統合、自動登録、およびローカライズされた IT サポート) が得られるうえに、グローバルに信頼されたルートの主な利点も得られます。ルイジアナ州立大学 (LSU) には、まさにそれを実現するシステムがあります。セキュリティ ウォッチのこの記事では、LSU で実装したソリューションを詳しく見ていきます。その技術的な設計について説明し、同様のシステムを展開する際に使用するベスト プラクティスを取り上げます。ここで説明するソリューションは、環境、リソース、およびビジネス要件への特定のニーズを満たしたソリューションであることに注意する必要があります。自分にとって適切なソリューションの種類を判断するために、ビジネスのこのようなすべての側面をあらかじめ評価する必要があります。

LSU での PKI の展開
LSU は、学生、教職員、およびスタッフの総数が 40,000 名を超す主要な研究大学です。LSU では多数の Web サイトを公開しており、その多くは、トランスポート層セキュリティを必要とします。トランスポート層セキュリティは、Secure Sockets Layer (SSL) 証明書を表す適切な用語です。LSU は、グローバルに信頼されているルート プロバイダの証明書に年間数千ドルを使っていました。
一方で、LSU には、適切に設計された内部 PKI から大きな利点を得るという IT セキュリティの他の目標がありました。LSU の目標と要件を考えると、ハイブリッド モデルを選択するだろうと想像するかもしれません。しかしそうではなく、より革新的な手法だと感じたものを採用しました。
グローバルに信頼されたルートの 1 つである Cybertrust と協力し、LSU の敷地内に、Cybertrust ルート CA に従属する CA を展開しました (図 1 参照)。Cybertrust は、このサービスを Cybertrust の OmniRoot プログラムで提供します。このシナリオでは、LSU は、LSU が所有する機器でローカルに実行される CA を構築して運用します。ただし、既に説明した内部モデルとは異なり、LSU の CA は自己署名入りではなく、そのキーは (キーで署名される CA と共に)、実際には、最新のすべてのオペレーティング システムやブラウザの間で暗黙的に信頼されます。技術的には、この設計は、x.509 標準の開放性を論理的に展開したものです。PKI はこれらの標準に基づいて構築されるため、さまざまなベンダが作成したシステムを同じ階層全体にプラグインできます。そうは言うものの、OmniRoot ソリューションに関して特に興味深い点は、サービスの利用規約です。
図 1 Cybertrust グローバル ルート証明書
図 1 Cybertrust グローバル ルート証明書 (画像を縮小するには、ここをクリックします)
図 1 Cybertrust グローバル ルート証明書
図 1 Cybertrust グローバル ルート証明書 (画像を拡大するには、ここをクリックします)
OmniRoot サービスは、LSU で実装したような PKI 展開用に特別に設計されています。OmniRoot プログラムでは、組織は、プログラムに参加するための固定年間費を Cybertrust に支払います。その後は、公開用に作成された証明書の料金を証明書ごとに支払います。つまり、LSU は、証明書の合計費用については心配することなく、内部で使用するのに必要なだけ証明書を発行できます。一方で、公開されている証明書のコストは、現在、大学が必要に応じて証明書を購入したときに支払った金額よりも大幅に削減されています。
当然のことですが、技術的な観点から言うと、内部証明書と公開証明書は同じです。これらの証明書は、同じ CA チェーンから発行され、暗号化の強度が同じです。また、同じ登録機関のシステムを介して配布されます。この 2 つの証明書の相違点は、ランセンス条項のみです。
最終的には、より低コストで、LSU の IT セキュリティ プラットフォームを展開および拡張できるようになりました。この実現により、LSU のこの種の PKI ソリューションにとって優れたビジネス ケースが作成されました。では、展開の技術的な詳細を見てみましょう。

PKI 階層
LSU の PKI 階層は 2 層設計に基づいて構築されます。この設計には、Cybertrust によって管理されるルート層と、LSU で実行されているオンライン発行 CA が含まれています (図 2 参照)。ルート層は、階層内の信頼のアンカーを構成します。つまり、階層内の任意の CA から発行されるすべての証明書の信頼関係は、ルート CA の支配下に入ります (図 3 参照)。したがって、階層内のすべての CA、証明書、およびエンド エンティティ間の結び付きは、通常はルート CA によって形成されます。Cybertrust グローバル ルートは Windows® および他のほぼすべての最新のコンピューティング システムに既に組み込まれているため、この結び付きが自動的に LSU のネットワークを越えて適用されます。
Figure 2 2 層の PKI 階層 (Close Figure 2)

ルート層 (Cybertrust) | 発行元の層 (LSU)
Cybertrust が管理している | LSU が管理している
Cybertrust のセキュリティで保護されたデータセンターに配置されている | LSU のバトンルージュ キャンパスに配置されている
最新のほぼすべてのコンピューティング システムの既定のルート証明書に含まれている | LSU のシステム構成内のエンド エンティティに証明書を発行する
 | LSU が発行する証明書は Cybertrust ルートに分類されるため、グローバルに信頼される
図 3 LSU の発行元 CA から発行された証明書
図 3 LSU の発行元 CA から発行された証明書 (画像を縮小するには、ここをクリックします)
図 3 LSU の発行元 CA から発行された証明書
図 3 LSU の発行元 CA から発行された証明書 (画像を拡大するには、ここをクリックします)
Cybertrust は、セキュリティで保護されたホスティング施設の 1 つでルート CA を管理します。ホスティング施設は、強力で物理的なセキュリティ制御を使用します。このセキュリティ制御には、侵入者を捕らえる罠、バイオメトリックスによるロック、銅で完全外装された保管金庫などがあります。Cybertrust は、セキュリティ ポリシーおよび証明書ポリシーに準拠していることを証明した組織の発行元 CA に対してのみ証明書を発行します。
LSU の発行元 CA は、エンド エンティティが接続するシステムで、LSU のユーザーやコンピュータの数に対して証明書を提供します。その証明書は、階層内で証明書の上にある Cybertrust CA によって署名されています。また、その証明書自体を Cybertrust ルート CA にチェーンする証明書を発行します (図 3 参照)。

発行元の OS とハードウェア
LSU は、発行元 CA に、Service Pack 1 を適用した Windows Server® 2003 Enterprise Edition を使用しています。Windows Server 2003 証明機関サービスには、キーのアーカイブ、Delta CRL (証明書失効リスト)、および "バージョン 2" テンプレートなどの新しい機能が多数用意されています。発行元 CA として使用される Windows インスタンスは、LSU の標準的な Windows Server 構築ポリシーに従って構築されます。このインスタンスは、関連するすべてのセキュリティ更新プログラムで更新され、標準 LSU の変更管理方法およびソフトウェアのインベントリや更新ツールを使用して管理されます。つまり、CA サービス自体を管理する独自の側面はいくつかありますが、基本のサーバー ハードウェアおよびオペレーティング システムは組織の既存の IT 運用に簡単に統合されます。
サーバー インストールに関する LSU の標準的なベスト プラクティスに従う以外に、Windows Server 2003 Service Pack 1 にあるセキュリティ構成ウィザード (SCW) も利用しました。SCW では、Windows Server で実行できるさまざまなワークロードの依存関係マトリックスを含むデータベース、およびこれらのワークロードに必要なセキュリティ設定を使用します。このデータベースには、CA が提供する 2 つの主な役割として CA サービス自体と IIS (PKI のセルフサービス Web サイトを提供) があります。
SCW を使用して、これらのワークロードの実行に必要なサービスを除くすべてのサービスを無効にするセキュリティ テンプレートを簡単に作成したほか、サーバーのネットワーク スタックを強化しました。その後、scwcmd.exe を使用してこのテンプレートをグループ ポリシー オブジェクト (GPO) に変換し、組織単位のレベルでサーバーに適用できるようにしました。LSU CA の役割ベースのセキュリティ構成がコンピュータ固有ではなく Active Directory 内に格納されているため、この方法によって、拡張と障害回復が簡略化されます。
LSU の発行元 CA は、3.2 GHz の Intel Xeon プロセッサ 2 基、4 GB の RAM 2 基、および 146 GB の SCSI ハード ディスク 5 基が搭載された IBM xSeries 346 サーバー上に構築されています。CA サービスのパフォーマンスの要求、および LSU でハードウェア セキュリティ モジュールを使用しているという事実を前提として、このプラットフォームは相当の寿命とヘッドルームを発展のために提供する必要があります。
ここでは、2 つの RAID 1 アレイを作成してデータベースおよびログ ファイルを別々の物理スピンドルに分類するための標準的なベスト プラクティスに従いました。5 番目のハード ディスクは、ホット スペアとして保持され、いずれかのアレイに使用できます。1 つ目のアレイを、CA データベースを保持するシステム ボリュームとしてマウントしました。2 つ目のアレイは、ログ ファイルや他のさまざまなデータ ファイル (CRL など) に使用されます。CA データベースは、Active Directory などの Windows の他の部分にあるのと同じ Jet テクノロジに基づいているため、ここでは、他の Jet ベースのストレージ ソリューション用のメンテナンスとディスク構成に関するものと同じベスト プラクティスが適合します。
ハードウェア セキュリティ モジュール (HSM) は、オペレーティング システムから切り離して管理されている専用のハードウェア デバイスです。通常、HSM は、PCI アダプタとして提供されますが、ネットワークベースの機器としても使用できます。これらのモジュールは、CA キーのセキュリティで保護されたハードウェア ストアに加え、署名操作および暗号化操作を促進する専用の暗号化プロセッサも提供します。Windows は CryptoAPI インターフェイスを介して HSM を使用します。HSM は、暗号化サービス プロバイダ (CSP) デバイスと見なされます。OmniRoot プログラムでは、各 CA が少なくとも FIPS 140-2 レベル 3 (レベル 4 のデバイスは非常にまれです) 用に認定された HSM をキーの生成やストレージに使用することを必要とします。HSM は、高度なセキュリティで保護された一意のデバイスなので、相当な財政投資を必要とします。そのため、通常、PCI ベースの HSM の記載価格の範囲は 10,000 ～ 15,000 ドルです。
LSU の設計では、nCipher nShield 500 TPS (500 トランザクション数/秒のモデル) は、直接接続された HSM として使用されます ("直接接続" とは、複数のホストで共有されるネットワーク ベースの HSM とは対照的に、サーバーの内部にあり、そのサーバーのみで使用できることを意味します)。HSM は、FIPS 140-2 レベル 3 デバイスで、キー マテリアルの K of N 保護を提供します。HSM は、危険にさらされている秘密キーに対して強力な保護を提供します。攻撃者がそのキーにアクセスするには、HSM ストレージだけでなく、定義された数のアクセス トークンとその PIN も所有する必要があります。
HSM は、悪意のある人物によるコンテンツの改ざんを防ぐように設計されていることに注意することが重要です。したがって、HSM は、連続して失敗したログオン試行に対して厳重な制限を設けています。LSU の設計では、10 回連続で失敗した後、ストレージは削除されます。取り消しは不可能です。
セットアップ時に 1 つの CA を用意したため、ネットワーク ベースの HSM の価格プレミアムは正当化できません。ただし、組織で 2 つ以上の CA を実装する予定がある場合、ネットワーク ベースの HSM を 1 つ購入して CA 間で共有すると、コストを大幅に削減できます。この方法では、すべてのキー ストレージを同じトークン セットで保護できるため、トークンの管理も容易になります。

Active Directory と登録
Windows ベースの PKI ソリューションの主な利点の 1 つは、PKI に参加するエンティティに追加のソフトウェアをインストールする必要なく、証明書の配布が実現することです。それだけでなく、ほとんどの証明書の配布は、自動登録とグループ ポリシーを組み合わせることで自動的に管理されるため、エンド ユーザーが気付くことはありません。LSU は、このテクノロジを使用して、コンピュータの証明書を、Active Directory のメンバであるコンピュータに自動的に配布します。また、カスタマイズした Web サイトを使用して、自動証明書要求機能を Windows 以外のホストに提供します。
既に説明したように、OmniRoot プログラムは、公で使用されている証明書と内部で使用されている証明書を区別します。証明書は、LSU 組織内に属していないシステムやユーザーによって使用される場合 (たとえば、入学希望者が SSL でセキュリティが保護された Web サイトを使用して入学願書を提出する場合) に公開証明書と見なされます。LSU 組織内で使用される証明書 (LSU のサーバーでデータを暗号化する際に使用される証明書など) は、内部証明書と見なされます。
OmniRoot プログラムのコストは公開されている証明書の数に基づいているため、発行される公開証明書の数や発行先を追跡できる必要があります。したがって、公開を目的とした証明書の場合、テンプレートの識別名は "PublicCertificate" で始まり、表示名は "Public Certificate" で始まります。たとえば、公開されている LSU TLS 証明書テンプレートは、既定の Windows Web Server テンプレートに基づいており、Public Certificate LSU Web Server と呼ばれています。内部で使用される Web サーバーの場合、2 番目のテンプレートは Internal Certificate LSU Web Server と呼ばれています。技術的には、2 つのテンプレートは同じです。つまり、名前が異なるだけで、課金が簡単になります。
証明書を IPSec で使用するためにすべての部門を登録するなど、一括登録が必要な場合は、自動登録を使用します。自動登録は、Windows に組み込まれた、単純で非常に効率的なツールです。PKI 管理者の視点から、必要な操作は、テンプレートのアクセス制御リストの変更だけです。この変更により、証明書を必要とするユーザーまたはコンピュータのグループに、自動登録の権限が付与されます。その後、これらのエンティティは、Active Directory を自動的にチェックし、自動登録アクセス許可を設定したテンプレートを列挙して、そのテンプレートを含む CA を探し、証明書を自動登録します。さらに、自動登録機能により、テンプレートが優先され、期限切れになる前に自動的に更新される場合に証明書が置き換えられます。
証明書を使用した Web サーバーの準備など、一括操作以外の目的では、セルフサービス Web サイトを使用します。この Web サイトを使用すると、ユーザーは Web ブラウザ経由で証明書を要求できます。このサイトは、Windows Server 2003 (/certsrv 仮想ディレクトリ) に付属する Web 登録ページのカスタマイズされたバージョンです。そのため、ここでの実装では、LSU の標準的な Web の商標を含め、要求ページ上の適切な既定のエントリを事前に完成します。また、このサイトから送信された要求が承認を求める場合、Windows CA サービスの既定の終了モジュールを使用して、PKI 管理チームに自動的に電子メールを送信します。

失効の設計
各証明書には有効期間があります。LSU はときどき、有効期間が終了する前に特定の証明書を無効にする必要があります (たとえば、有効期間が 2007 年 5 月までの証明書を従業員に提供していて、その従業員が 2007 年 1 月で LSU を辞める場合が考えられます)。このような失効は CRL によって実現します。CRL は、CA が署名した証明書のシリアル番号の一覧を含むファイルです。CRL に含まれているシリアル番号は、有効期間の期限は切れていなくても、LSU が信頼できると見なさなくなった証明書を表します。クライアントは、この CRL をダウンロードして確認し、証明書の有効性を判断できます。
x.509 v3 証明書 (ルート CA 証明書自体を除く) には、有効な CRL へのポインタが必要です。このポインタは、CRL 配布ポイント (CDP) といいます。CRL 配布ポイントは、証明書自体に含まれているため (図 4 参照)、証明書が発行された後に変更することはできません。CRL は、CA からの証明書が有効であることを保証するのに不可欠です。このため、LSU の CRL は物理的な冗長性があり、可用性が高く、外部の人間がアクセスできることを確認します。
図 4 LSU の CRL 配布ポイント
図 4 LSU の CRL 配布ポイント (画像を縮小するには、ここをクリックします)
図 4 LSU の CRL 配布ポイント
図 4 LSU の CRL 配布ポイント (画像を拡大するには、ここをクリックします)
(LSU のように) Active Directory と統合されている Windows Server ベースの CA は、その CRL を Active Directory に自動的に発行し、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) 経由でアクセスできるようにします。既定の発行場所は、フォレストの Public Key Services コンテナ内の CDP コンテナです (図 5 参照)。この発行場所は、自動レプリケーション、フォールト トレランス、および CDP 参照の場所を提供する優れたオプションです。
図 5 CDP コンテナ
図 5 CDP コンテナ (画像を縮小するには、ここをクリックします)
図 5 CDP コンテナ
図 5 CDP コンテナ (画像を拡大するには、ここをクリックします)
ただし、LSU の設計では、PKI を使用する Windows 以外のコンピュータや Active Directory 以外のコンピュータが多数あります。また、LSU は大規模な組織ですが、そのユーザーの大半が 10 Gbps のバックボーンを持つ同じキャンパス ネットワーク上に存在します。これにより、Active Directory ベースの CDP の発行の利点は最小限にしか得られません。
その結果、HTTP パスに CRL のみを発行することで、冗長性のあるホスティング プラットフォームを簡単に作成できるようになります (主要な Web サイトは既にミラー化されています)。また、これによって、クライアントの LDAP 参照の有効化に関して考えられる複雑さがなくなります。CRL は毎日発行し、Delta CRL は時間単位で発行します。

今後の展開
現在の PKI では、大学というコミュニティに強力なセキュリティ ソリューションを提供しますが、その機能を強化する予定です。Windows Vista™ および次期バージョンの Windows Server (コードネーム "Longhorn") には、調査を予定している新しい重要な管理機能が多数用意されています。特に、計画済みのオンライン証明書状態プロトコル (OCSP) クライアントと応答側の機能、楕円曲線暗号化アルゴリズムと SHA-256 アルゴリズムのサポート、および大幅に向上した自動登録インターフェイスに関心があります。さらに、Windows XP Service Pack 3 には、資格情報の移動として知られる機能が搭載される予定です。この機能は、プロファイルの移動に関連するオーバーヘッドなしで、キーのペアをセキュリティで保護した状態で移動できます。最後に、Certificate Lifecycle Manager (現在ベータ版を入手可能) の使用について調査し、レポート機能および管理機能を向上させます。
要するに、LSU の PKI は、多くの重要な IT 機能に使用される基本的なセキュリティ サービスを大学に提供します。Cybertrust の OmniRoot サービスを使用すると、LSU の他の IT システムと適切に統合される PKI を実行できます。また、Windows CA サービスでソリューションを構築することにより、効率的な証明書の配布機能と管理機能を所有し、既存のディレクトリと ID 管理システムの優れた統合を行えます。つまり、PKI の強力なセキュリティとシームレスな信頼に対する構想は、既に LSU で実現しています。

John Morello は、ルイジアナ州立大学を首席で卒業し、マイクロソフトで Microsoft Consulting Services (MCS) のシニア コンサルタントを 6 年間務めました。MCS では、Deloitte、GE、およびさまざまな連邦組織などの戦略的なクライアント向けに PKI を設計していました。現在は、LSU で CISO 補佐を務めています。


 デスクトップ ファイル: Windows Imaging 形式について
デスクトップ ファイル
Windows Imaging 形式について
Wes Miller
このコラムは、Windows 展開ツールのプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

Windows Vista のリリースで、Windows のインストール方法および展開方法が大きく変わります。Windows Vista (および Windows Server の次期バージョンであるコードネーム "Longhorn") のセットアップ エンジンと一連の展開ツールは、書き直されました。これらの変更点と
変更に至った Windows® 展開チームの成果については、少し前の TechNet Magazine の記事で説明しました。ただ、このトピックについては説明することが多くあるため、この新連載のコラムで、Windows PE、Windows のインストールと展開、および Windows の管理とセキュリティに関する他のトピックについて説明します。
初回は、新しい Windows Imaging 形式 (WIM) について説明します。イメージングの詳細についてよくご存じない場合は、補足記事の「通常のイメージング プロセス」で概要を一読してください。次のコラムでは、Windows 自動インストール キットについて説明します。Windows 自動インストール キットとは、WIM イメージの作成および操作に使用するコマンドライン ツール ImageX と、リモート インストール サービス (RIS) に替わる機能である Windows 展開サービス (WDS) を含む一連の新しいツールです。これらのツールによって、OS の展開がどのように容易になるかについて見てみます。

ターニング ポイント
毎年、Windows 展開チームには、OEM および企業ユーザーから同じフィードバックが寄せられてきました。その内容は、イメージングのサポートを充実させること、およびマイクロソフトが統一的なイメージング ツールを提供することを望むものです。ユーザーは、サードパーティ ベンダを選択し、その複雑な製品について学習することを望んでいません。また、これらの OEM および企業ユーザーから、Windows を展開するために使用するイメージング ツールに費用をかけるのが当然とは思わないという苦情をよく聞きました。代わりに、マイクロソフトがこれらのツールを提供することを望んでいます。
Windows Vista™ の開発初期に、Windows 展開チームは非常に大きな賭けに出ました。コンポーネントの多くが 10 年近く使用されてきたセットアップ エンジン全体を、完全に破棄することにしました。セットアップ作業は常に脆弱で、非常に多くの手順がありました。プロセスを高速化し、不要な手順を排除して、Windows セットアップ全体の信頼性を強化したいと考えました。これを実現するため、長い間使用していた手作業を伴うエンジンからセットアップ プロセス全体を変え、完全にイメージベースのセットアップ プロセスに置き換えることにしました。

新しいイメージ形式の設計
セットアップを設計し直すプロセスの初期に、使用するイメージの種類の定義に着手しました。典型的な論点は、セクタかファイルか、という点でした。つまり、ボリュームのコピーをセクタごとの複製として格納するイメージ形式を使用するか、またはすべてのファイルを個々に格納するイメージ形式を使用するか、という点です。多くの人が期待するメリットは、速度 (セクタでのアプローチ) と圧縮 (ファイルベースのアプローチ) です。最終的に、この 2 つの中間的な、優れた形式に落ち着きました。それは、優れたパフォーマンスを実現するだけでなく、優れた圧縮機能も提供します。
まず、OEM および企業ユーザーのニーズを満たすイメージ形式を設計するために達成するべきいくつかの主要な目標を定義しました。その一覧は、ファイルベースのアーキテクチャに大きく傾いていました。チームのメンバ全員がこのアプローチのメリットを認識していたため、最初にこの方向で始まりました。その後すぐに WIM ファイルが誕生しました (参考までに、WIM の "M" に意味はありません。WIM は、リリース マイルストーン近くに定期的に行われる Windows チームのイベントを基に名づけられました。また、*.WI という略語が奇妙に見えるという理由もあります)。それでは、新しいイメージ形式に対する一連の目標を見てみましょう。
Windows ファイル システム形式に依存しない イメージ形式は、Windows でサポートされる両方のファイル システムのアーキテクチャで機能する必要がありました。実行時にはほぼすべてのシステムで NTFS が使用されますが、多くの OEM および企業は、Windows の展開に MS-DOS® を使用するため、一時的に FAT ファイル システムを使用します。その後、NTFS に変換します。Windows Vista でもこのサポートを継続する必要がありました。
ボリュームのサイズに依存しない 大きなボリュームをキャプチャしてそれよりも小さなボリュームに適用するという昔からの問題を回避する必要がありました。イメージング ツールでパーティションを操作してこの問題を回避できても、その信頼性は低くなります。ファイルベースのアーキテクチャでは、イメージを構成するファイルと同じサイズの領域しか必要ありません。ファイル システムは独自に復元されるため、ボリューム サイズに依存しません。
通常のイメージング プロセス
OEM で多数のシステムを複製するとき、または大規模な組織で多数のコンピュータに Windows を展開するときには、通常、イメージング テクノロジを使用します。その際、ホスト システムを導入し、それを適切に構築して、対象のシステムに複製することが前提になります。イメージング プロセスについてよくご存じない場合のため、ここに簡単な概要を示します。
  1. 管理者は、システムに Windows をインストールし、希望どおりに構成します。これには、コンポーネントの追加と削除、よく使用するアプリケーションのインストール、および UI や他の設定の微調整といった操作が伴います。このシステムをホスト システムと呼ぶことにします。
  2. 管理者はその後、(マイクロソフトが Windows 展開ツールの形式で提供している) Sysprep を実行します。このツールにより、Windows のインストール環境を一意に識別する属性 (コンピュータ名や Windows セキュリティ ID (SID) などのシステムの一意の識別子) がクリーンアップされます。これらは、Sysprep の後半部分が実行されるとリセットされます。
  3. 次に、管理者は、コンピュータをシャットダウンし、Windows PE、MS-DOS、または別の OS を選択して再起動し、イメージング アプリケーションを実行できるようにします。
  4. 次に、イメージング ツールを実行し、参照システムのイメージを作成します。このイメージは、参照ディスクまたは参照パーティションの完全な複製を含むファイル (またはファイルのコレクション) です。
  5. システムがシャットダウンされます。管理者はイメージをアーカイブします。このイメージは、必要に応じて (アプリケーション、修正プログラム、および Service Pack を追加して) 更新できます。
  6. イメージを 1 台以上のコンピュータに複製します。その後、Sysprep により簡略モードのセットアップ (Sysprep を実行している Windows のバージョンと Sysprep の構成方法によってミニセットアップまたは Windows Welcome と呼ばれます) が実行されて、作業が完了します。この段階では、setupcl.exe と呼ばれるネイティブモードの小さな実行可能ファイルが使用されます。

システム アーキテクチャに依存しない イメージ アーキテクチャは、Windows によってサポートされるあらゆるアーキテクチャと連携する必要がありました。当時、これは、まったく異なる x86 アーキテクチャと IA64 (Intel Itanium) アーキテクチャのサポートを意味していました。現在では、これに x64 (AMD64 および EM64T) アーキテクチャも含まれます。
短時間でキャプチャおよび適用できる イメージは、圧縮をかけても、ある程度短時間にキャプチャできる必要がありました。しかしそれよりも、イメージを短時間で適用できることの方が重要でした。
非破壊的なイメージの適用をサポートする システム回復に使用するツールを更新するだけでなく、(ユーザーのデータまたはアプリケーションを壊さずに Windows を置き換えることができるように) アップグレード オプションを差し替えていたため、既にボリューム上にあるデータを一切破壊せずにシステムのイメージを適用できるようにしたいと考えました。セクタベースの形式では、かなりの作業を行わないとユーザーはこれを実行できません。一般に、ボリューム全体を復元するか、まったく何も行わないかです。
大幅な圧縮をサポートする Windows Vista の開発当初は、まだ CD での出荷に重点を置いていました。Windows XP のイメージが 1 GB 近くであることを考えると、イメージをできるだけ小さく圧縮することが重要であると考えました。セクタベースのイメージを圧縮する方法はありますが、このような実装は不確定要素があり不安でした。多くのセクタベースの形式では、ディスク上の空の領域を省略し、領域を節約します (常に 0 なのに、なぜイメージに 0 を記録するのでしょうか)。しかし、ファイルベースのアプローチを使用することで、からの領域を扱わなくなったので、これを本質的に処理しました。
ファイルの単一インスタンスをサポートする これは前の問題と同じです。Windows では、同じファイルの複数のコピーがいくつかの異なる場所に格納されます。ファイルベースのアプローチにより、各ファイルの 1 つのインスタンスのみを格納し、必要に応じてそのファイルを使用することが簡単になりました。
複数のメディア (ディスク) への分割をサポートする 私たちは、WIM 開発当初から、1 枚の CD にイメージを収めることができたとしても、複数枚のメディアをサポートする必要があることを認識していました。Windows を 1 枚の CD で出荷しても、ユーザーがアプリケーションや Service Pack などを追加すると、そのイメージは 1 枚の CD または DVD のサイズを超える可能性があります。そのため、独自のインストールおよび復元手段のためにイメージを複数のメディアに分割できるようにする必要がありました。
1 つの BLOB ファイルで複数のボリューム イメージをサポートする 1 つのイメージですべての用が足りることはほとんどありません。"単一インスタンス" を設計したとき、複数のボリュームを取得する機能も含めました。同じ圧縮と単一インスタンスがそれぞれのボリューム間で機能します。そのため、Windows XP Professional のイメージを取得し、(Windows XP Professional を含む) Windows XP Tablet PC Edition の新しいイメージを追加すると、イメージは 2 つのバージョン間で明らかに異なるファイルの分だけ増加します。
その結果、OEM および企業ユーザーは、サイズを急激に増加されることなく多くの派生イメージを相互に追加できます。この機能は、セクタベースの形式では容易に達成できなかったと考えられます。

WIM のしくみ
WIM 形式は、基本理念を満たしながら、できるだけ簡単になるように設計されました。ファイルベースのアプローチによりこれを実現できました。ただ、これは実際どのように機能するのでしょうか。
簡単に言うと、WIM ファイルは CAB ファイル (ZIP 形式に似ていますが、マイクロソフトが、設計し、所有しています) と同じように考えることができます。実際、WIM が "CAB の息子" と呼ばれているのを聞いたことがあります。WIM ファイルと CAB ファイルの主な違いは、WIM イメージは、ファイル自体のキャプチャと圧縮に加え、特定のボリューム イメージにキャプチャされたボリュームを構成するファイルとディレクトリに適用されるメタデータも格納します。そのため、これは、イメージが作成されたときのとおりにボリュームを復元するために必要なメタ情報 (アクセス制御リスト (ACL)、短いファイル名、長いファイル名、属性など) が含まれるアーカイブ ファイルのようなものです。
キャプチャ プロセスの間は、パーティションの情報 (サイズまたは種類) が収集されないことに注意してください。適用プロセスでも、システムのパーティションは分割されません。多くのイメージング ツールとは異なり、ImageX はパーティションに依存しないので、適用前にパーティションを作成して、フォーマットする必要があります。イメージの適用前のプロセスを自動化するには、Diskpart およびフォーマット用コマンドライン ツールを使用する必要があります。
ボリューム イメージに格納できるものに制限はありません。2 種類のボリューム、火曜日と木曜日にキャプチャした同じボリューム、Service Pack を適用したイメージと適用していないイメージなど、ニーズに合わせて格納できます。理解すべき主な点は、同一のファイルが 1 度しかキャプチャされないということです。2 つのボリューム イメージに共通なファイルが少ないほど、より多くの領域が使用されます。
また、WIM 形式は、以前のバージョンの Windows でも使用できる設計になっています。Windows 2000 でも Windows Vista と同じように機能します。では、イメージをキャプチャしたり、適用したりするときに実際に何が起こるかについて詳しく見てみましょう。。

イメージのキャプチャ
ボリューム イメージをキャプチャするとき、次の手順が実行されます。
ボリュームのメタデータがキャプチャされる ImageX が、ファイル名、NTFS の ACL など、ボリュームのファイル システムの属性に関するデータを収集します (スクリプト ファイルを使用して、特定のファイルを除外できます)。
ファイル データがキャプチャされる ファイルが ImageX によって読み込まれます。各ファイルがボリュームに読み込まれ、ファイルに関する特定のデータを収集する準備を整えます。
ファイル ハッシュが生成される ファイル自体を基にしたファイルの暗号化ハッシュが生成されます。このハッシュは、イメージのファイルの一意の識別子になります。
重複の調査と除外が行われる 同じハッシュの別のファイルがイメージに既に存在する場合、これが同じファイルであると想定され、新しいファイルは既に存在しているファイルをポイントすることで参照されます。
一意のファイル データが圧縮される CAB や他の多くのアーカイブ形式とは異なり、WIM ファイルの各ファイルは、1 つのデータ ストリームとしてグループ化されたファイルのコレクションとしてではなく、個別に圧縮されます。また、圧縮を行わないという選択もできます。その場合、この手順は省略されます。
ボリュームのメタデータが圧縮されて格納される すべてのファイルがアーカイブされると、ボリュームのメタデータ エントリが作成されます。このメタデータには、ボリュームのイメージに追加された各ファイルが列挙されます。
イメージの XML データが生成されて格納される このデータは、キャプチャされた各ボリューム イメージの参照です。たとえば、ImageX /info を実行すると、この XML データが表示されます。
キャッシュされた WIM データのインデックスが記述される 最後に、(キャッシュされたデータと共に) マスタ データのインデックスが記述されます。このインデックスは、WIM 全体のマスタ ファイル テーブルであり、ハッシュごとに 1 つのエントリを含みます。
ご覧のとおり、ファイルベースの WIM が作成されます。さらに、イメージに追加するボリュームの数にかかわらず、できあがる WIM ファイルは 1 つです。

イメージのオーバーロード
WIM の開発を始めたとき、同じようなソリューションを開発しているチームは数多くありました。Automated Deployment Services チームは、私たちとは異なるユーザー層に向けたイメージング ソリューションを開発していました。そのアプローチは、実装の低レベル部分の詳細が非常に興味深かったのですが、イメージング エンジンが、当時主流を占めていたセクタ ベースでした。Windows XP Embedded チームも、セクタベースのイメージング エンジンを構築し、組み込みの独立系ハードウェア ベンダ (IHV) が独自のイメージをシステムの製造時に展開できるようにしました。2003 年にマイクロソフトが Virtual PC チームを買収したとき、バーチャル ハード ディスク (VHD) ファイル用の別のファイル形式がもたらされました。
これらすべての形式は、セクタベースが中核となっていました。これらのソリューションは、各ユーザー層のニーズは満たしましたが、WIM のガイドラインは満たしません。その結果、私たちはイメージをキャプチャするための新しい WIM 形式と ImageX コマンドライン ツールの構築を続けました。最終的に、WIM 形式は、Windows Vista ベータの一部として公開されるずっと前に、他の多くのチームに採用されました。たとえば、SMS チームは、Operating System Deployment Feature Pack で WIM を早期に実装しました。

イメージの適用
では、対になるプロセスであるイメージの適用について見てみましょう。
キャッシュされた WIM データのインデックスが読み込まれる これは、前の処理の最後の手順に関連します。このインデックスはマスタ インデックスであるため、どのボリューム イメージを適用するかを指定した後、最初に WIM から読み込まれます。
イメージのメタデータが取得されて読み込まれる ImageX が、各ボリューム イメージに固有のメタデータを読み込みます。
ディレクトリ構造が作成される すべてのファイルの復元先が存在することを確認するため、ボリュームのディレクトリ ツリー全体が作成されます。
ファイル データが抽出される ファイルは、アーカイブされた順番どおりに WIM から抽出されます。
ファイル データが適用される ファイルが読み込まれ、展開されて (ボリューム イメージを WIM で圧縮した場合)、参照先の各場所にコピーされます。最後に、各ファイルのすべてのメタデータが適用されます。
すべてのディレクトリのメタデータが適用される ディレクトリの ACL によってはイメージを正しく適用できない可能性があるため、これが最後の手順であることが重要です。

柔軟な圧縮
WIM イメージ形式の主な目標の 1 つは、柔軟な圧縮のオプションを提供することでした。そのため、必要に応じて圧縮をかけてボリューム イメージをキャプチャできる一方、圧縮せずにイメージをキャプチャすることもできる機能を提供しました。後者のオプションは、イメージをあえて圧縮する必要がない場合や、高速なキャプチャが重要な場合に適切です。
圧縮について言うと、覚えておくべきいくつかの基本事項があります。圧縮は、常に、展開よりも時間がかかります。圧縮効果が高い圧縮アルゴリズムほど、特定のデータ セットを圧縮するのにより長い時間がかかります。また、圧縮アルゴリズムを多くのデータに適用するほど、圧縮率が高まります。
WIM イメージは、XPress または LZX 圧縮を使用して圧縮できます。また、もちろん、圧縮をしないように選択することもできます。XPress は、多少の圧縮が必要でも、キャプチャ プロセスにあまり長い時間をかけたくない場合に適切です。LZX は圧縮率が最も高いですが、おわかりのとおり、この方法にはかなりの時間がかかります。
圧縮を使用しない場合、イメージは最短でキャプチャできますが、サイズが最大になります。圧縮の種類は WIM ごとに選択します。WIM に 1 つのボリューム イメージをキャプチャしたら、その後のすべてのボリューム イメージも同じ圧縮設定でキャプチャされます。
WIM イメージはファイルごとに圧縮されるため、圧縮が完全でないことに注意してください。これは意図的な決定でした。こうすることで、イメージをより容易に編集することができます。キャプチャ後にイメージを編集する機能は、重要なオプションです。イメージをキャプチャした後にファイルを編集するには、ファイル データとそのメタデータを置き換える必要があります。WIM 全体を 1 度にすべて圧縮した場合、ファイル編集のサポートの設計が、(仮にできたとしても) 非常に複雑になっていたでしょう。また、イメージ内のファイルの置き換えに、非常に長い時間がかかるでしょう。私たちは折り合いを付け、適切に圧縮できて、ツールを使用して編集することもできる形式を考案しました。
Windows Vista 用に設計したイメージング機能がどのように機能するかについて、理解していただけたでしょうか。次のコラムでは、WIM イメージの管理と展開に使用できるいくつかのツールについて説明しながら、ImageX および Windows 展開サービスについて詳しく見ていきます。

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


 Windows 秘話: RunOnce 待ち
Windows 秘話
RunOnce 待ち
Raymond Chen

プロセスの途中でシステムを再起動する必要があるインストールについて考えてみましょう。たとえば、プログラムでは、現在使用中のシステム DLL をアップグレードする必要のある場合があります。新しい DLL ファイルをインストールするには、途中でシステムを再起動する必要があります。また、DLL がアップグレードされたら、インストールの次の段階でその DLL を使用できるようにする必要があります。
RunOnce キーは、このようなシナリオ、つまりセットアップの途中で行われる再起動後にインストール プロセスを完了する必要があるセットアップ プログラムで使用することを目的としていました (これはプログラムには落ち度がないと信じられていた昔の話になりますが)。
Windows® Explorer では、RunOnce プログラムの実行が完了するまでデスクトップやタスク バーを作成しません。これは RunOnce がセットアップ プログラムで使用されるものであるという原則に基づいて動作しているためです。実行中の RunOnce プログラムでは、システム構成データを変更している可能性があり、システムの構成中にユーザーがシステムを使用するのは望ましいことではありません。
たとえば、RunOnce プログラムが、インストールしたばかりのファイルのベース アドレスを再割り当てし、バインドしているとします (そのファイルにはシェル拡張を構成するものもあります)。実行可能ファイルの更新中に、ユーザーがプログラムを実行したり、拡張をアクティブ化するようなことがあっては困ります。
RunOnce が "セットアップ プログラムで使用されるものである" という原則のもう 1 つの落とし穴は、RunOnce キーは、管理者権限を持つユーザーがログオンしている場合にのみ処理されるということです。つまり、管理者以外のユーザーは、インストールを完了することができません。また、管理者以外のユーザーについて RunOnce キーを実行すると、このキーは "一度だけ実行される" というものではなくなってしまいます。これは、大きなジレンマです。では、"この RunOnce は実行済みなので、もう実行しなくてよい" ということを通知するには、どうしたらよいでしょうか。このシステム全体にかかわる状態を変更するには、管理者特権が必要です。当然、管理者以外のユーザーには管理者特権がありません。そのため、このプログラムは 1 回だけ実行されるのではなく、管理者特権を持つユーザーがログオンするまで繰り返し実行されることになります。

(画像を縮小するには、ここをクリックします)

(画像を拡大するには、ここをクリックします)
RunOnce は、プログラムのインストール プロセスを最終確定することを目的としているので、Windows セットアップで認識されます。Service Pack をインストールしたり、新しいバージョンの Windows にアップグレードする際には、セットアップ ウィザードで RunOnce キーが確認されます。このキーに値が設定されている場合は、他のプログラムでインストール プロセスが実行中であること、オペレーティング システムをアップグレードするにはそのインストール プロセスを終了する必要があることを通知するエラー メッセージが表示されます。プログラムのインストール中にオペレーティング システムを変更するのは望ましくないので、これは適切な動作でしょう。
RunOnce のデザインを紐解くと、このキーの過去がわかります。このキーは、Windows 95 で導入されました。Windows 95 では、管理者と管理者以外のユーザーは区別されませんでした。つまり、Windows 95 では、すべてのユーザーが管理者であったので、RunOnce を使用したプログラムは、再起動後に実行する操作について RunOnce に依存することができました。
最近の Windows オペレーティング システム (特に Windows Vista™) では、数か月もの間、管理者特権を持つユーザーがログオンしないという状況が発生し得ます。その結果、RunOnce を実行する必要があるプログラムでは、インストール完了まで非常に長い待ち時間が発生する可能性があります。
余談ですが、私は永続的な RunOnce を見たことがあります。このプログラムでは、プログラムが実行されるたびに RunOnce キーに自身を追加していました。これは、プログラムのインストールではなく、プログラムの通常操作の一環となっているので RunOnce キーの目的に明らかに違反しています。その結果、Windows セットアップでは、インストールが実行中であるというエラーが常に表示されてしまいます。
このように、この迷惑な 1 つのプログラムが永続的にインストール プロセスが実行中であると主張し続けるため、ユーザーはオペレーティング システムをアップグレードできません。このプログラムは、今日の時点ではインストールが完了しませんが、いつかは確実に完了するでしょう。『ゴドーを待ちながら』の話と大差ありませんね。けれども、RunOnce には実存的危機が伴わないことを祈りたいものです。

Raymond Chen の Web サイト The Old New Thing (英語) では、Windows の歴史と Win32 プログラミングを扱っています。現在は、偶然にも『The Old New Thing』(Addison-Wesley、2007 年) というタイトルの書籍の執筆にも取り組んでいます。