混在モードにおけるサイト統合の重要な考慮事項
リモートの Microsoft® Exchange サイト統合について考慮する前に、サイト統合に関する以下の推奨事項および前提条件と、サイトの統合中または統合後に発生する可能性のある問題について理解しておく必要があります。
クライアント コンピュータを Microsoft Office Outlook®** 2003 にアップグレードする** サイトを統合する前に、リモート サイトのクライアント コンピュータを Outlook 2003 にアップグレードし、Exchange キャッシュ モードを有効にします。Exchange キャッシュ モードによって、リモート ユーザーはネットワーク接続の有無にかかわらずローカル キャッシュを使用して作業できるので、この機能はサイト統合の重要なコンポーネントです。クライアント コンピュータの Outlook をアップグレードし、Exchange キャッシュ モードを有効にすると、ユーザーのメールボックスのローカル コピーが作成されます。ローカル コピーを作成してからメールボックスを移動すると、ローカル サイトからメールボックスを移動した後に生じるダウンロード トラフィックの増大を回避できます。この方法は、リモート サイトと中央サイト間のネットワーク帯域幅が制限されている場合に特に有効です。Outlook の以前のバージョンおよびその他の電子メール アプリケーションを使用するクライアント コンピュータもサポートされますが、その場合、これらのクライアント コンピュータは Exchange キャッシュ モードを活用することはできません。また、サポートに関する問題の発生を最小限に抑えるためには、Outlook 2003 のエンド ユーザー トレーニングおよびアップグレード プロセスの準備を計画に組み込む必要があります。
ADC を Exchange 2003 SP1 にアップグレードする サイト統合の後にオブジェクトおよび配布リストをクリーンアップする新しい機能が含まれる Exchange 2003 SP1 バージョンの ADC (Active Directory Connector) を使用します。サイト間でメールボックスを移動すると、ADC はユーザー オブジェクトとユーザーが所属するすべての配布グループを更新します。その結果、変更内容がディレクトリ間でレプリケートされるので、ユーザーは引き続きメールを受信できます。
可能な場合は、Microsoft Windows® ドメインを統合する 委任の設定、キー マネージメント サービスの証明書の発行、Outlook を経由したグループの更新に関する問題を避けるため、リモートの Windows ドメインおよび Exchange メールボックスを同時に統合することをお勧めします。Microsoft Active Directory® ディレクトリ サービスにおいて、Outlook は更新するオブジェクトと同じドメインにあるグローバル カタログ サーバーを使用する必要があります。たとえば、メールボックスへのアクセスを委任する際に、ユーザー オブジェクトがリモート ドメインにある場合、ユーザーが中央のドメインの Outlook にログオンしても、委任を設定することはできません。これは、Outlook は中央のドメインを指定していますが、ユーザー オブジェクトはリモート ドメインにあるためです。中央のドメインのグローバル カタログ サーバーには、他のドメインにあるディレクトリ オブジェクトの読み取り専用のコピーが含まれます。Exchange ドメインと Windows ドメインを同時に統合できない場合は、Outlook クライアントで次のレジストリ キーを構成して、ディレクトリ オブジェクトが含まれる中央のドメインのグローバル カタログ サーバーを使用するようにします。
- 場所
- HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider
- 名前
- DS サーバー
- 種類
- REG_SZ (文字列)
- 値
- <グローバル カタログ サーバーの完全修飾ドメイン名>
- 場所
ディレクトリ サービス/インフォメーション ストア (DS/IS) 整合性調整機能の修正プログラムを適用し、この機能を使用して Exchange 5.5 パブリック フォルダへのアクセスを保持する Exchange 5.5 パブリック フォルダを移動する前にユーザーおよびグループを中央サイトに移動すると、パブリック フォルダのアクセス制御リスト (ACL) の整合性が失われ、ユーザーはパブリック フォルダにアクセスできなくなります。この問題を回避するには、次の 2 つの方法があります。
- 方法 1 : ユーザーとグループを移動した後に DS/IS 整合性調整機能を実行し、新しいユーザーとグループの情報を使用してパブリック フォルダの ACL を更新します。
- 方法 2 : 最初に中央サイトにパブリック フォルダをレプリケートし、次にユーザーとグループを移動します。また、コネクタ経由でパブリック フォルダを参照できることを確認します。
.gif "note")
注 :Exchange 5.5 サイトの統合を開始する前に、すべての Exchange 5.5 パブリック フォルダ サーバーに Exchange 5.5 DS/IS 整合性調整機能の修正プログラム (https://go.microsoft.com/fwlink/?linkid=3052&kbid=836489 から入手できます) を適用します。この修正プログラムを適用すると、サイト間での移動後にパブリック フォルダの ACL が正しく更新されるため、ユーザーおよびグループがパブリック フォルダに引き続きアクセスできるようになります。
オフライン アドレス帳の完全なダウンロードを計画する サイト間で複数のメールボックスを移動する前に、すべてのリモート サイトの Outlook クライアント コンピュータでオフライン アドレス帳の完全なダウンロードをサポートできる十分な帯域幅があるかどうかを確認する必要があります。オフライン アドレス帳の完全なダウンロードが必要な理由については、後の「オフライン アドレス帳のダウンロード」を参照してください。
メールボックスの移動後に Outlook プロファイルを更新する 管理グループ間でメールボックスを移動した後に、移動したメールボックスにユーザーがログオンできるように、Outlook プロファイルを更新する必要があります。Exchange プロファイル更新ツール (exprofre.exe) は、クライアント コンピュータで実行し、ユーザーの Outlook プロファイルを自動的に更新するためのコマンドライン ツールです。exprofre.exe は、既定の Outlook プロファイルを変更し、移動後のメールボックスにユーザーが正常にログオンできるようにします。このツールは、Exchange Server 2003 のツールおよびアップデート Web サイト (https://go.microsoft.com/fwlink/?linkid=21316) から入手できます (このサイトは英語の場合があります)。
オフライン アドレス帳のダウンロード
Exchange キャッシュ モードを使用する Outlook クライアント コンピュータには、電子メール アドレスを解決するためにオフライン アドレス帳が必要となります。オフライン アドレス帳は、パブリック フォルダ サーバーに保存されます。オフライン アドレス帳の完全なダウンロードは、次のような状況で発生します。
- サイトを統合する場合に、Exchange キャッシュ モードを使用し、メールボックスが移動されたすべてのユーザーが、オフライン アドレス帳の完全なダウンロードを受け取ります。このダウンロードは、メールボックスの移動後にユーザーが初めて Outlook を起動するときに発生します。
- 多くのディレクトリが変更された場合 (サイト間で多くのメールボックスを移動するか、Exchange トポロジを変更した場合など)、Exchange キャッシュ モードを使用するすべてのユーザーが、オフライン アドレス帳の完全なダウンロードを受け取ります。
オフライン アドレス帳の完全なダウンロードに関する影響および発生する状況の詳細については、マイクロソフト サポート技術情報の文書番号 839826 (https://go.microsoft.com/fwlink/?linkid=3052&kbid=839826) を参照してください。
| 注 : |
|---|
| アドレス帳のサイズ、使用可能な帯域幅、およびリモート サイトへの接続の待ち時間によっては、オフライン アドレス帳の完全なダウンロードが組織の制限要因になることがあります。 |
このダウンロードのボリュームによっては、ネットワークと Outlook の両方でパフォーマンスの問題が発生する可能性があります。オフライン アドレス帳のダウンロードの所要時間を特定する場合は、すべてのリモート サイトへのネットワーク接続の帯域幅、転送されるデータ量、およびネットワーク接続の待ち時間を考慮します。転送されるデータ量は、オフライン アドレス帳のサイズにリモート サイトのユーザー数を掛けて計算できます。
| 注 : |
|---|
| 例 : オフライン アドレス帳が 20 MB で、Exchange キャッシュ モードを使用する Outlook ユーザーが 25 人存在する場合、レプリケートが必要なデータの推定量は 500 MB (20 MB のオフライン アドレス帳 x 25 ユーザー = 500 MB) です。 |
ネットワークの待ち時間は、ネットワーク内の 2 点間でデータを転送するために必要な時間です。待ち時間は、ネットワーク接続が飽和するまでにかかる時間を決定する要素です。待ち時間が長い場合、データ転送の速度が低下するので、ネットワーク接続が飽和するまでの時間は長くなります。逆に、待ち時間が短い場合、データ転送は迅速に処理されるので、多くのクライアントが同時にオフライン アドレス帳をダウンロードした場合に接続が飽和する可能性が高くなります。
サイト間で複数のメールボックスを移動する前に、リモート サイトのすべての Outlook ユーザーによるオフライン アドレス帳の完全なダウンロードをサポートできる、十分な帯域幅があることを確認する必要があります。転送するデータ量およびネットワークの待ち時間を考慮することによって、ネットワークに対するダウンロードの影響を評価する必要があります。
空き時間機能
混在モードの組織において、メールボックスの移動ウィザードを使用してサイト間でメールボックスを移動する場合、メールボックスの移動ウィザードは、新しい legacyExchangeDN 属性を使用して対応するユーザー オブジェクトを更新します。ウィザードが legacyExchangeDN 属性を更新するので、Free/Busy システム フォルダを移動する必要はありません。ユーザーの空き時間データは、ユーザーが新しいメールボックスにログオンした後に新しい legacyExchangeDN 属性を使用して再発行されます。
| 注 : |
|---|
| 空き時間データは、サイト間でメールボックスを移動した直後に新しいサーバーに転送されるのではなく、ユーザーがメールボックスにログオンするか、または会議出席依頼の作成または承認などの予定表の操作を実行してから 15 分後に新しいサーバーに転送されます。 |
サイト統合のプロセスに関する既知の制限
ここでは、サイト統合に関する既知の制限について説明します。サイト統合のプロセスは、手順を実行する順序、ディレクトリ情報をレプリケートするための所要時間、Exchange データをサイト間でレプリケートするための所要時間など、さまざまな要素の影響を受けます。さらに、サイト間でメールボックスおよびユーザーの移動を行うと、他のメール機能も影響を受ける可能性があります。サイトの統合を計画するには、ここに記載されているすべての既知の問題を理解する必要があります。
メールボックス移動時のネットワーク トラフィックの増加 サイト間でメールボックスを移動する場合、サイト間のネットワーク トラフィックの増加を考慮する必要があります。トラフィックの増加量は、移動を計画しているメールボックスのサイズの合計と同じになります。
ディレクトリのレプリケーション トラフィックの増加 Exchange 5.5 サイトから中央の Exchange サイトにメールボックスを移動する場合、ADC がユーザーおよび配布グループを更新し、リモート サイトの古いオブジェクトを削除する際にディレクトリのレプリケーション トラフィックが増加することが予想されます。このプロセスの所要時間は、環境の規模、Exchange 5.5 サイト間のレプリケーション速度、および Exchange 5.5 と Active Directory 間のレプリケーション速度に依存します。既定では、ディレクトリのクリーンアップは 12 時間ごとに実行されます。小規模な環境では、ディレクトリのクリーンアップは次回の自動レプリケーション セッションで完了することもあります。大規模な環境では複数回のセッションが必要になることもあります。
.gif "important")
重要 :ディレクトリのクリーンアップの効率を高めるには、Active Directory コネクタ マネージャおよび Exchange 5.5 管理ツールを使用してレプリケーションを開始します。 パブリック フォルダのレプリケーション トラフィックの増加 Exchange パブリック フォルダ移行ツール (pfMigrate) を使用してパブリック フォルダを中央サイトに移動する場合、パブリック フォルダの階層を更新し、フォルダの内容をサイト間でレプリケートする際にトラフィックが増加することが予想されます。pfMigrate ツールと DS/IS 整合性調整機能は、レプリケーション トラフィックを増やす原因になります。
Microsoft Exchange Server 5.5 メールボックスを移動した後で Unicode 形式で自動的に再作成されない、ANSI 形式のキャッシュされたオフライン フォルダ ファイル Exchange Server 5.5 メールボックスを Exchange Server 2003 または Microsoft Exchange 2000 Server を実行しているコンピュータに移動した後、ユーザーのキャッシュされたオフライン フォルダ (.ost) ファイルおよびオフライン アドレス帳 (.oab) ファイルが ANSI 形式のままとなります。ANSI 形式のキャッシュされたオフライン フォルダ (.ost) ファイルには 2 GB のサイズ制限があります。また、このファイルは ANSI 形式であるため、オフライン アドレス帳ファイルも ANSI 形式を使用します。さらに、マイクロソフト サポート技術情報の文書番号 841207 に記載されている解決方法では、影響を受けるクライアント コンピュータすべてに対してオフライン アドレス帳の完全ダウンロードを行う必要があります。このダウンロードにより、ネットワーク トラフィックが大幅に増加する可能性があります。
キャッシュされたオフライン フォルダ ファイルが Exchange 2003 または Exchange 2000 で Unicode 形式ではなく ANSI 形式で作成される問題の詳細および解決方法については、マイクロソフト サポート技術情報の文書番号 841207「Outlook 2003 オフライン キャッシュされたフォルダ ファイルは、Unicode 形式での ANSI 形式で in exchange 2003 または in exchange 2000 作成されます。」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=841207) を参照してください。
Outlook 2003 での Unicode の使用の詳細については、Outlook 2003 の Unicode オプションの構成についてのページ (https://go.microsoft.com/fwlink/?LinkId=33526) を参照してください (このサイトは英語の場合があります)。代理ユーザーはアクセスできなくなる場合がある Outlook の委任アクセスを保持するには、リモートの Exchange 5.5 サイトから中央サイトに代理ユーザーおよびその管理者を一緒に移動します。一緒に移動できない場合は、代理ユーザーよりも先に管理者を移動するか、移動後に再度代理ユーザーにアクセス権を付与します。
履歴内受信者を再指定する必要がある 履歴内受信者は、メールボックス ストアのすべてのアーカイブされたメッセージを受け取るように構成されたユーザーです。サイト間で履歴内受信者を移動する前に、履歴内受信者の指定を別のユーザーに割り当てます。移動後に、ユーザーを履歴内受信者として再指定できます。
受信トレイ ルールは機能しない場合がある ユーザーのメールボックスが Exchange 2003 SP1 サーバーにない場合、他のサイトに移動したユーザーに基づくすべての受信トレイ ルールは、移動したユーザーの legacyExchangeDN 属性が変更されるため機能しなくなります。ただし、ルールは作成し直すことができます。ユーザーのメールボックスが Exchange 2003 SP1 サーバーにある場合、ルールは引き続き機能します。この問題は、使用するメールボックスを移動したユーザーに影響するのではなく、移動したユーザーに基づいたルールを指定しているユーザーにのみ影響します。Exchange 2003 SP1 サーバーがすべてのユーザーのメールボックスをホストすると、ルールは再び機能するようになります。
ユーザー名が一時的に Exchange 5.5 の GAL に表示されない場合がある Exchange 5.5 では、別のサイトに移動したユーザーの名前が、ディレクトリ レプリケーションが完了するまで、一時的にグローバル アドレス一覧 (GAL) に表示されない場合があります。この間に新しい Exchange 5.5 オブジェクトが新しいサイトにレプリケートされ、リモート サイトの元の Exchange 5.5 オブジェクトは非表示になります。Exchange 2003 の GAL への影響はありません。
一部のユーザーが移行後に配信不能レポートを受け取る場合がある Exchange 5.5 から中央サイトにメールボックスを移動した後に、まだ移動されていない Exchange 5.5 ユーザーが移動済みの Exchange 5.5 ユーザーからのメールに返信すると、配信不能レポート (NDR) を受け取ります。この状況は、Exchange 5.5 のディレクトリ レプリケーションが完了するまで続きます。この状況を回避するには、ADC マネージャで [今すぐレプリケート] を選択してレプリケーションを強制的に実行します。もう 1 つの方法は、Exchange 2000 または Exchange 2003 のブリッジヘッド サーバーを経由するように、Exchange 5.5 メールをリダイレクトすることです。これらのサーバーは新しいメールボックスにメールを転送することができます。
注 :NDR を減らすには、Exchange 5.5 サイト間のサイト コネクタを削除し、すべてのメールが中央サイトまたは Exchange 2003 サーバーを経由するように中央サイトへのコネクタを作成します。 リソース メールボックスの空き時間データを再送信するために、権限を持ったユーザーが予定表のアクションを実行する必要がある メールボックスを別のサイトに移動しても、空き時間データは新しいサーバーに転送されません。ユーザーの空き時間データは、ユーザーがメールボックスにログオンするか、会議出席依頼の作成または承諾などの予定表の操作を実行してから 15 分後に新しいサーバーに送信されます。ただし、会議室などのリソース メールボックスの場合は、リソース メールボックスにアクセス可能なユーザーがメールボックスを開き、予定表の操作を実行して空き時間情報を再送信する必要があります。
キー マネージメント サービスは証明書のエクスポートが必要 X.509 v3 証明書を使用している場合、キー マネージメント サービスは、サイト間の移動後も引き続き機能します。しかし、v1 証明書を使用している場合はキー マネジメント サービスは機能しません。v1 証明書を使用する場合、サイト間で移動されたユーザーは以前のメールを解読できますが、新しいメールに対する署名または暗号化はできません。キー マネージメント サービスを使用している場合は、同じキー マネージメント サービス サーバーが中央サイトにサービスを提供している場合も含めて、別のサイトにユーザーを移動する前に証明書をエクスポートします。移動後に中央サイトのキー マネージメント サービス サーバーに証明書をインポートします。さらに Exchange プロファイル更新ツール (exprofre.exe) を実行します。
Exchange Conferencing Server はネイティブ モードへの切り替えが必要 Exchange Conferencing Server を実行している場合、Exchange のネイティブ モードに切り替えてからサイトを統合する必要があります。この手順に従うと、legacyExchangeDN 属性に関する問題を回避することができ、引き続き Exchange Conferencing Server の機能を使用できます。