• [アーティクル]

Exchange Server 2007

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

Kate Follis

 

概要:

  • 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 のトポロジ **(画像を拡大するには、ここをクリックします)

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 サーバーのインストール **(画像を拡大するには、ここをクリックします)

ここまでは順調ですね。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** ルーティング グループ コネクタの構成 **(画像を拡大するには、ここをクリックします)

次に LA East ルーティング グループを Exchange 2007 に移行しましょう。この状況でルーティングを維持するには、少し注意が必要です。図 4 では、Exchange 2007 が Los Angeles サイトにインストールされ、2 番目のルーティング グループが解除されていますが、追加のルーティング グループ コネクタは作成されていません。

図 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** より効率的なルーティング **(画像を拡大するには、ここをクリックします)

これにより、すぐには明らかにならないかもしれませんが、問題が発生します。現在、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 リソース **(画像を拡大するには、ここをクリックします)

また別の問題が発生しました。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 について教えていました。

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