マルチフェーズの移行を実行する

マルチフェーズの移行の手順は、その多くが単一フェーズの移行と共通しています。手順を何回も実行する点が異なりますが、単一フェーズの移行を計画する場合に検討した項目の大半は、マルチフェーズの移行の場合も関連があります。

重要 :
ロータス ノーツ R5/R6、Exchange Server 2003、および Windows Server 2003 Active Directory の間の相互運用性に関するダウンロード可能なツール、ガイダンス、およびその他のリソースの詳細については、Microsoft のコラボレーション プラットフォームへの移行に関するリソースについてのページを参照してください (このサイトは英語の場合があります)。

ただし、ユーザーを移行する前に、相互運用性の要件により生じるその他のいくつかの問題に対処する必要があります。マルチフェーズの移行を正常に完了するには、次の条件を満たす必要があります。

1. メッセージ転送が中断されないように、メッセージ パスを保持   移行を実行している間、相手が社内のユーザーであるかどうかに関係なく、すべての相手と電子メールを交換できなければなりません。ユーザーのメールボックスがどこに存在しているかにかかわらず、正しい宛先にメッセージが転送されるようにする必要があります。
2. ディレクトリ情報の同期によるアドレス帳情報の一貫性と最新性の確保   電子メール メッセージを送信する場合、宛先をアドレス一覧から選択でき、正しい相手にメッセージが送信される必要があります。この要件を満たすため、メールボックスを Exchange 2003 に移行している間、移行元と移行先の両方のメッセージング ディレクトリで、ユーザーおよび配布リストの正確な情報を保持する必要があります。
3. 予定表情報の同期による、すべてのユーザーへの最新の空き時間情報の提供   多くの会社では、会議のスケジュールを調整するための主な手段として、従来のメッセージング システムに含まれる予定表管理コンポーネントを使用しています。Exchange 2003 への移行中は、この機能を保持する必要があります。他のユーザーがいつ会議に出席可能かをユーザーが確認でき、会議出席依頼がシステム間で転送されるようになっている必要があります。

図 1 に示すフローチャートをガイドとして使用して、マルチフェーズの移行における適切な手順を判断します。

メッセージ パスを保持する

メールボックスを Exchange 2003 組織に移行する前に、内部および外部のユーザーからのメッセージが確実に正しく配信されるようにするメッセージ転送トポロジを実装する必要があります。このトポロジを実装した後で、テスト用メールボックスを作成するか、または、いくつかのテスト用アカウントを Exchange 2003 に移行してメッセージ ルーティングが期待どおりに動作することを確認します。

Exchange 2003 を既存のメッセージング インフラストラクチャに接続し、メッセージ パスを保持するには、次の質問に回答できる必要があります。

1. どのような方法でメッセージ転送を維持しますか。   メッセージング システム間のメッセージ ルーティングを構成するには次の 2 つのオプションがあります。
   1. Connector for Novell GroupWise など、メッセージをルーティングするための Exchange 2003 コネクタのうちの 1 つを使用します。Exchange 2003 コネクタにはメッセージ転送やディレクトリ同期の機能があるため、サポートされている従来のメッセージング システムに対してはこの方法をお勧めします。専用のコネクタ経由でメッセージを転送することにより、あるシステムから別のシステムにメッセージ形式を変換するときに、ほとんどのメッセージ プロパティを保持できます。ほとんどのタイプのメッセージは、コネクタ経由で送信できます。他のシステムの同様のメッセージ タイプにマップできないメッセージは、通常、標準的な電子メール メッセージに変換されます。
   2. 専用のコネクタ コンポーネントがない場合は、SMTP または X.400 のコネクタを使用して、2 つのメッセージング システム間でメッセージのルーティングを行うことを検討してください。たとえば、既存のメッセージング システムで、インターネットへの SMTP 接続が可能な場合は、Exchange サーバーに SMTP コネクタを実装し、SMTP 接続を通じてすべてのメッセージをルーティングできます。SMTP コネクタの場合、メッセージの転送しかできず、ディレクトリの同期を実行できない点が大きな制約となります。このため、半自動の同期メカニズムを実装するか、またはディレクトリを手動で更新する必要があります。両方のメッセージング システムが X.400 をサポートしている環境に X.400 を実装する場合も、SMTP コネクタと同様の利点と制約があります。
2. **外部ユーザーとの間の通信をどのようにサポートしますか。   **メッセージ ルーティング保持のための 2 番目のタスクとして、インターネット メールの配信が中断されないようにすることが挙げられます。既存のメッセージング システムを Exchange 2003 に移行するときに、インターネット電子メール機能も移行します。外部ソースから Exchange 2003 のメールボックスにメッセージが配信されるようにルーティングを変更する必要があります。移行シナリオで外部との通信を実現するには、次のオプションがあります。

   1. 移行するユーザーの SMTP アドレスの中の、ドメイン ネーム システム (DNS) のドメイン名を変更   企業の中には、移行を自社の DNS ドメイン名を変更する機会としてとらえている場合があります。移行で DNS ドメイン名が変更されると、Exchange 2003 組織内のユーザーは、従来のメッセージング システムのものとは異なる SMTP アドレスを使用することになります。このような環境でインターネット メッセージ ルーティングを処理するには、組織内の 1 つ以上の Exchange サーバーで SMTP コネクタを構成し、インターネット メールの送受信を行います。SMTP コネクタは新しい SMTP アドレス用のすべての電子メールの配信を処理し、現行のメッセージング システムは引き続き従来の SMTP アドレスを処理します (図 2)。
      

   2. 移行するユーザーについては SMTP アドレスに含まれる DNS ドメイン名を変更し、それ以外のユーザーについては Address Rewrite ツールを使用   SMTP ドメイン名の変更を計画している会社の場合、ユーザーが従来の環境にいるか、既に Exchange 2003 組織にいるかに関係なく、通常、一度にすべてのユーザーについて SMTP ドメイン名を変更したいと考えます。これは、Address Rewrite を有効にして、すべての SMTP メッセージを Exchange 2003 経由でルーティングすることで実現できます (図 3)。Address Rewrite とは、従来のシステムから SMTP 経由で受信したインターネット宛てのメッセージ内の SMTP アドレスを、対応する連絡先のプライマリ SMTP アドレスに変換する機能です。Address Rewrite を正常に使用するには、従来のシステム内の各ユーザーに対応付けられた、メール アドレスを含む連絡先が Active Directory 内に存在し、さらにそれらの連絡先オブジェクトについて送信メッセージに対する返信アドレスとして使用するプライマリ SMTP アドレスを指定する必要があります。詳細については、Address Rewrite (Exarcfg.exe) ツールに付属の Readme ファイルを参照してください。このツールは https://go.microsoft.com/fwlink/?LinkId=25932 からダウンロードできます。
      

   3. 既存の外部 SMTP 電子メールアドレスを保持し、解決できない受信者に対しては SMTP ルーティングを実行   移行時に DNS ドメイン名を変更することは、企業合併の場合にとられる方法の 1 つですが、ほとんどの企業は Exchange 2003 への移行の前後で同じ SMTP アドレスを使用して、顧客やビジネス上のパートナーとの通信が通常どおり継続されるようにしたいと考えます。SMTP アドレスを変更せずに済ませる 1 つの方法として、すべての受信インターネット メールを受信するように Exchange 2003 を構成し、さらに Exchange 2003 を使用して解決されない受信者のメッセージを従来のメッセージング システムにルーティングする方法があります (図 4)。この構成では、他のメッセージング システムが受信者を解決するか、または存在しない受信者についての NDR を生成するようにする必要があります。
      

      重要 :
      解決できない受信者のメッセージを Exchange Server 2003 に送信するように従来のメッセージング システムを構成しないでください。送信するように構成した場合、どちらのシステムでも解決できない受信者宛てのメッセージが、両システムのサーバー間をループする可能性があります。たとえば、Exchange 2003 は従来のシステムと同じルーティング メカニズムを使用して SMTP メッセージを配信するため、図 4 のように、受信 SMTP メッセージを従来のシステムに配信したり、解決できない受信者を Exchange 2003 にルーティングしたりしないようにしてください。このため、図 4 では従来のシステムからの送信メッセージのみを示しています。受信メッセージは、まず Exchange 2003 サーバーに到着します。

   4. **既存の外部 SMTP 電子メール アドレスを保持し、中央のスマート ホストを使用して受信メッセージを従来のメッセージング システムと Exchange 2003 にルーティングする   **メッセージのループが発生する可能性があるため、受信者を解決できないメッセージの転送はお勧めしません。グローバル エイリアス一覧を使用して外部 SMTP アドレスを保持しながら中央のスマート ホストを使用する方が簡単です。メッセージを受信した場合は、スマート ホストがエイリアス一覧を読み取り、受信者情報を対応する内部アドレスに置き換えてから、メッセージをルーティングします (図 5)。このアドレス マッピングは、受信メッセージと送信メッセージに対して実行できます。
      

   5. 既存の外部 SMTP 電子メール アドレスを保持し、従来のメッセージング システムを使用して受信メッセージを Exchange 2003 組織にルーティングする   インターネット メールの送受信のため、既存のメッセージング システムが直接インターネットに接続されていて、Exchange 2003 へのダイレクト コネクタを導入している場合は、このダイレクト コネクタを使用して、2 つのメッセージング システム間における SMTP メッセージのルーティングを行うことができます (図 6)。このようにするには、移行する各 Exchange 2003 ユーザーに対応するネイティブ受信者オブジェクトが Exchange 以外のメッセージング システムのディレクトリ内に作成されるよう、最初にディレクトリ同期を構成する必要があります。Exchange 以外のディレクトリ内の受信者オブジェクトは、必要に応じて SMTP アドレスに関連付けられます。従来のシステムは、受信メッセージを受信すると、ネイティブな内部形式に変換します。これには受信者の SMTP アドレスを従来のシステムにとってネイティブなアドレスに変換する処理が伴います。変換されたアドレスが Exchange 2003 組織内の受信者を指している場合、メッセージは Exchange 2003 へのコネクタを経由してさらにルーティングされます。送信メッセージの場合も同様の処理が行われます。従来のメッセージング システムは、Exchange コネクタからのメッセージを受信し、メッセージを内部形式に変換します。さらに、Exchange 以外のアドレスを対応する SMTP アドレスに変換し、そのメッセージをインターネット上の送信先に送信します。
      

   6. 既存の外部 SMTP 電子メール アドレスを保持し、Exchange 2003 を使用して受信メッセージを従来のメッセージング システムにルーティングする   従来のメッセージング システムでメッセージの変換とルーティングを行うことのデメリットは、すべてのインターネット通信が移行元のシステムに依存している点にあります。すべての受信および送信 SMTP メッセージの処理に Exchange 2003 を使用する方が効果的です (図 7)。ただし、ディレクトリ同期は引き続き必要なため、従来のメッセージング システム内の各ユーザーに対応する受信者オブジェクトが Active Directory 内に作成されます。
      

3. パフォーマンス上のボトルネックをどのように回避しますか。   最適なメッセージ転送速度を実現するために、複数のブリッジヘッド サーバーの実装が必要な場合があります。単一の Exchange 2003 サーバーで同じ種類の Exchange コネクタを複数構成することは通常できないため、複数のブリッジヘッド サーバーが必要です。また、Connector for Novell GroupWise は、Exchange 以外のメッセージング環境の場合、1 つのシステムのみに接続することができます。Exchange 2003 に間接的に接続されたポストオフィス上の受信者宛てのメッセージは、従来のメッセージング環境内で送信先にルーティングする必要があります。

   注 :
   複数のブリッジヘッド サーバーとメッセージング コネクタを同じ Exchange 以外の環境に実装する予定の場合は、メッセージ ループなどの転送の問題を回避するために、ルーティング トポロジの概要を慎重に計画する必要があります。

ディレクトリ情報を同期する

従来のメッセージング システムと Exchange 2003 との間の相互運用性を維持するための 2 つ目の重要なタスクは、移行時に両方のメッセージング システムで正確なディレクトリ情報を提供することです。ユーザーが社内の他の受信者に電子メールを送信するときには、アドレス一覧からユーザー名を選択できる必要があり、メッセージは適切なメールボックスに配信される必要があります。

Exchange コネクタを介したディレクトリの自動同期

ディレクトリ情報の同期をとる方法の 1 つは、Exchange 2003 コネクタのいずれかを使用することです。Connector for Novell GroupWise は、ディレクトリ情報の同期をサポートしています。これらのコネクタを使用する場合、以下を含むさまざまな設定を構成することができます。

• **同期をとる属性   **もう一方のメッセージング システムに対し、各ユーザーのすべての属性を同期する必要のない場合は、ディレクトリの同期から属性を除外することができます。
• **同期をとるディレクトリ エントリ   **たとえば、メールボックスが有効なユーザー アカウントのすべてについてディレクトリ情報を同期し、連絡先またはメールが有効なグループの同期はとらないようにすることができます。
• Active Directory 内の組織単位   選択した組織単位に基づいて、従来のメッセージング システムとの間で同期をとる受信者オブジェクトを指定することができます。また、従来のメールボックスを参照するすべての受信者オブジェクトのターゲット組織単位を指定することもできます。
• **作成する受信者オブジェクトの種類   **無効な Windows ユーザー アカウント、有効な Windows ユーザー アカウント、または Active Directory の連絡先を作成できます。
• **グループまたは配布リストの複製の有無   **Exchange 以外のメッセージング システムから配布リストを複製するコネクタを構成すると、その配布リストについて Active Directory 内にメールの有効な連絡先項目が作成されます。Exchange ユーザーが配布リストの連絡先に電子メールを送信すると、メッセージは連絡先で指定されている電子メール アドレスに送信され、配布リストが拡張されている場合は他のメッセージング システムにメッセージが配信され、配布リスト内のすべての受信者に電子メールが配布されます。

Active Directory のディレクトリ情報を保持するもう 1 つの方法は、このトピックで前述したツールとテクノロジを使用して、半自動化されたディレクトリ同期プロセスを実装することです。従来のシステムに含まれるディレクトリ情報の自動更新に関するプログラミング インターフェイスの詳細については、ベンダにお問い合わせください。

ディレクトリ関連の問題を処理する

ディレクトリ情報の同期に使用するテクノロジに問わず、ディレクトリ情報を保持する際に、以下のような問題が発生する可能性があります。

• 配布リストのメンバシップを手動で更新する必要がある   配布リストを同期する場合、どちらのメッセージング システムの配布リストにも電子メールを送信できます。ただし、ディレクトリを同期する場合、配布リストのメンバは含まれません。配布リストは、Active Directory 内ではメールが有効な連絡先として表示されます。Exchange 2003 にメールボックスを移行する場合、配布リストのメンバは、新しい Exchange 2003 組織に存在することになるため、従来のメッセージング システムからは削除されます。メールボックスが移行されたユーザーは、通常、従来のシステムのメールボックスを削除した時点で従来のメッセージング システムの配布リストのメンバではなくなります。そのため、配布リスト宛てにメッセージを送信しても、意図した受信者にメッセージが配信されるとは限りません。
  これに対処する 1 つの方法は、メンバ リストの正確さを確保するために、従来のシステムの配布リストを手動または自動で更新する方法を実装することです。すべてのユーザーを Exchange 2003 に移行したら、メールが有効な配布グループの形式で、Active Directory 内にそのグループを再作成できます。より良い方法は、メールボックスを Exchange 2003 に移行する前に、Active Directory 内にメールが有効な配布グループを移行することです。Active Directory 内のメールが有効な配布グループには、Exchange 2003 メールボックスと、まだ従来のメッセージング システム内にいる受信者のためのメールが有効な連絡先の両方を含めることができます。ディレクトリ同期によってメールが有効な連絡先を作成した場合、これらの連絡先は Exchange 移行ウィザードによって、移行中にメールボックスが有効なユーザー アカウントで置き換えられます。連絡先の組織単位を、新しいユーザー アカウントの移行先コンテナとして指定すると、移行ウィザードによってグループ メンバシップが自動的に更新されます。
• 配布リストによりコネクタの負荷が増加   配布リストは、連絡先オブジェクトとして同期されます。このため、ディレクトリ同期では、配布リストのメンバ情報は含まれません。配布リストまたはメールの有効な配布グループに送信されたメッセージは、まず最初に、メンバ情報が利用可能なシステムに送信される必要があります。このシステムがリストを展開し、各受信者にメッセージを配信します。この場合、メッセージはゲートウェイ コネクタを何度も通過するという状況になります。これを回避するには、ディレクトリ同期の対象から配布リストを除外するしかありません。さらには、Active Directory 内のメールの有効な配布グループを介して、従来のシステムから配布リストを反映するプロセスを実装する必要があります。そして、移行の各フェーズが終了した後に、配布リストのメンバを手動または半自動で更新する必要があります。このようにして、従来のメッセージング システムと Exchange 2003 の両方でメンバ情報が利用できるようになり、余分なメッセージ転送を発生させずに直ちにメンバ情報を展開することができます。
• クライアントがローカルのアドレス情報を使用   クライアントが電子メール アドレスを解決するときに、サーバーベースのアドレス リストではなく、個人用アドレス帳 (PAB) または Outlook のアドレス帳を使用するように構成されている場合、ローカルのアドレス帳の情報が古いままではメッセージが配信されないことがあります。たとえば、ユーザーは従来のメールボックス用のアドレスを PAB に格納しているとします。そのメールボックスを Exchange 2003 に移行する場合、サーバーベースのアドレス リストはディレクトリ同期を通じて更新されます。ただし、ディレクトリ同期にはローカルのアドレス リポジトリは含まれておらず、PAB または Outlook のアドレス帳を使用して電子メール アドレスを解決するようにクライアントが構成されている場合は、ユーザーがメールボックス宛てに送信したメッセージは依然として古い電子メール アドレスにルーティングされます。この問題は、サーバーベースのアドレス リストを使用して電子メール アドレスを解決するようにクライアントを再構成することで修正できます。クライアントを再構成しない場合は、ユーザーが PAB 情報を更新する必要があります。
• ユーザーが古い電子メール アドレスでメッセージに返信する   移行中、ユーザーが古い電子メール メッセージに返信すると、エラーが生じるという問題がよく起きます。このような症状は、ユーザーが Exchange 以外の電子メール アカウントからメッセージを送信した場合で、メールボックスが Exchange 2003 に移行している場合に生じる可能性があります。このメッセージにユーザーが返信すると、返信メッセージは古い電子メール アドレス宛てに送信されます。その結果、メッセージは正しいメールボックスに配信されません。この問題を解決するには、電子メール メッセージに返信するときに、受信者の名前を入力し直すか、またはサーバーベースのアドレス リストから改めて受信者の名前を選択するようユーザーに指導する方法しかありません。ユーザーが受信者を指定し直せば、正しいアドレス情報が使用され、メッセージが正しいメールボックスに到達します。
• Active Directory の受信者情報が重複する   メッセージ転送のため複数のコネクタを実装する場合、同じ受信者の同期が重複して行われないように、注意深くディレクトリ同期を構成する必要があります。ディレクトリ同期は 1 つのコネクタでのみ実行してください。

予定表情報を同期する

Exchange 2003 に移行する際にほとんどの会社が実行したいと考える 3 つ目のタスクとして、従来のメッセージング システムと Exchange 2003 のユーザーが、もう一方のシステムのユーザーの予定表データ (特に空き時間情報) にアクセスできるようにして、会議のスケジュール調整をスムーズにすることが挙げられます。この目的を果たすため、Exchange 2003 には Microsoft Exchange 2003 Calendar Connector が含まれています。予定表コネクタは、Connector for GroupWise を使用するコンポーネントです。

以下は、Exchange 2003 ユーザーが Novell GroupWise のユーザーについて空き時間情報を照会するときに生じるプロセスの説明です。

1. Exchange ユーザーが別のユーザーの空き時間情報を照会するとき、予定表コネクタが要求を受け取ります。
2. Exchange 2003 は、SCHEDULE+ FREE BUSY という名前のシステム フォルダ (隠しパブリック フォルダの) に空き時間情報を格納しています。予定表コネクタは、予定表コネクタがインストールされているサーバーにある、このパブリック フォルダのレプリカをチェックします。要求されたユーザーの空き時間情報があらかじめ構成された時間内に更新されていた場合、予定表コネクタはその情報を要求元のユーザーに返します。更新されていなかった場合、予定表コネクタは Novell GroupWise を実行するサーバーに更新された空き時間情報を要求します。この要求では、Exchange 以外のメッセージング システム専用のプログラミング可能なインターフェイスを使用します (予定表コネクタは、時間内に応答を受信しない場合、SCHEDULE+ FREE BUSY パブリック フォルダに現在格納されている情報を返します)。
3. 予定表コネクタは、プログラミング可能なインターフェイスを通じて、Exchange 以外のメッセージング システムのスケジュール設定コンポーネントを起動して、ローカル ユーザーの予定表情報を検索します。スケジュール設定コンポーネントは、適切なプログラミング可能なインターフェイスに空き時間情報を返します。
4. 予定表コネクタが空き時間情報を受信し、Exchange 形式に変換します。次に、予定表コネクタは SCHEDULE+ FREE BUSY パブリック フォルダに空き時間情報を追加して、問い合わせてきた Exchange 2003 ユーザー宛てに更新済みの情報を送信します。

以下は、Exchange 以外のメッセージング システムのユーザーが、Exchange 2003 のユーザーについて予定表情報を照会するときに生じるプロセスの説明です。

1. ユーザーが Exchange ユーザーの空き時間情報を照会すると、その要求は予定表管理コンポーネントに送信されます。
2. 予定表管理コンポーネントは、要求された情報がリモート サーバーまたはポストオフィスにあることを検出し、要求をそのシステムに転送します。
3. リモート サーバーまたはポストオフィスは、実際には Exchange 2003 サーバーであるため、予定表コネクタは予定表情報の要求を傍受します。
4. 予定表コネクタは要求を処理し、SCHEDULE+ FREE BUSY パブリック フォルダで要求された空き時間情報をチェックして、応答を Exchange 以外のメッセージング システムに返します。
5. 情報は適切な形式に変換され、情報を要求したユーザーに提供されます。