Exchange Server 2003 Service Pack 1 ベースのサイトへのサイト統合に関する問題

文書翻訳 文書翻訳
文書番号: 841659 - 対象製品
すべて展開する | すべて折りたたむ

目次

概要

Microsoft Exchange Server 2003 Service Pack 1 を中央サイトにインストールした後、サイトの統合を開始して、リモート サイトの Exchange Server コンピュータを中央サイトに移行することができます。サイトの統合時には、いくつかの問題が発生する可能性があります。サイトの統合を開始する前に、フォレスト内のすべての Active Directory コネクタ (ADC) を、Exchange Server 2003 Service Pack 1 に含まれているバージョンの ADC にアップグレードする必要があります。

また、リモート サイトとオブジェクトの移動先である中央サイトの間で Exchange Server 5.5 ディレクトリ複製コネクタのスケジュールが正しく構成されていることを確認することをお勧めします。Exchange Server 2003 Active Directory コネクタの動作と、その実行中にサイトにどのような影響があるかは、各ネットワークにおける多くの要因によって異なります。

サイト間でのパブリック フォルダの移動後、管理グループ間での移動後、およびオブジェクトのリセット後には、いくつかの問題が発生する可能性があります。サイト間での移動を行うための準備として、この資料で説明する動作と問題を確認しておくことをお勧めします。

はじめに

サイトの統合とは、リモート サイトを 1 つの大規模な中央サイトまたは複数の大規模なサイトに統合する処理のことです。中央サイトを展開し、クライアントが Outlook 2003 の実行を開始した後、管理者はリモート サイトのコンテンツの統合を開始できます。サイトの統合を行うと、主なコンテンツ、パブリック フォルダ、メールボックス、およびディレクトリ オブジェクトが統合されます。また、オフライン アドレス帳、外部コネクタなどのサービスも中央サイトに統合されます。この資料では、サイトの統合時に発生する可能性がある既知の問題について概説します。また、考えられる問題の原因、回避策、および解決方法についても説明します。これらの情報を参考にして、発生が予想される問題について理解し、サイトの統合を適切に完了してください。

Exchange Server 2003 Service Pack 1 の Active Directory コネクタをインストールする

サイトの統合には、Microsoft Exchange Server 2003 Service Pack 1 の Active Directory コネクタ (ADC) が必要です。Exchange Server 2003 Service Pack 1 の Exchange システム マネージャのグラフィカル ユーザー インターフェイス (GUI) を使用しても、フォレスト内のすべての ADC が Exchange Server 2003 Service Pack 1 にアップグレードされるまでは、サイト間での移動を行うことはできません。

Exchange Server 5.5 ディレクトリ複製コネクタのスケジュールを更新する (オプション)

サイト間での移動時には、ディレクトリに多くの変更が加えられることがあります。管理者には、オブジェクトの移動先である中央サイトとリモート サイトの間で、Exchange Server 5.5 ディレクトリ複製コネクタのスケジュールを設定することをお勧めします。中央サイトから統合元のリモート サイトに変更のレプリケーションが迅速に実行されるように、管理者は次の操作を行うことができます。
  • リモート サイトと中央サイトの間で、Exchange Server 5.5 ディレクトリ複製コネクタを直接設定します。
  • Active Directory ディレクトリ サービスの変更のレプリケート元として ADC に構成されるレプリケーション ブリッジヘッドと複製コネクタで、中央サイト内の同じサーバーを使用します。
  • Exchange Server 5.5 のレプリケーションのスケジュールを [常に] または短期間に設定します。
これらの変更は必ずしも行う必要はありませんが、実施することを強くお勧めします。これらの変更を行わないと、ディレクトリ レプリケーションまたは ADC レプリケーションに遅延が発生した場合に、サイト間での移動後に実行される自動クリーンアップ処理に時間がかかる可能性があります。

ADC の動作

移動前の ADC の動作

管理グループ間でパブリック フォルダの移動が完了する前に、ADC は、クリーンアップ処理のいくつかのステージを完了します。管理グループ間の移動時の ADC のクリーンアップが完了するまでは、メッセージ配信に影響があります。

ADC のクリーンアップが完了するまでに要する時間は、環境、Exchange Server 5.5 サイト間でのレプリケーション、および Active Directory から Exchange Server 5.5 へのレプリケーションによって異なります。

たとえば、配布リストのクリーンアップとスタブ オブジェクトの削除は 12 時間おきに実行されます。これらの処理は同時に完了します。より小規模な環境では、1 回のクリーンアップ サイクルまたは 12 時間で完了する場合があります。より大規模な環境では、2 回以上のクリーンアップ サイクルを要する場合もあり、完了するまでに 24 時間近くかかることがあります。より大規模な環境では、以下の原因によって、配布リストのクリーンアップとスタブ オブジェクトの削除が完了するまでの時間が長くなることがあります。
  • Active Directory から Exchange Server 5.5 へのレプリケーションが完了するまでに要する時間
  • Exchange Server 5.5 でのサイト間のレプリケーション
クリーンアップをより短時間で行うには、接続許可書を右クリックし、[今すぐレプリケート] をクリックします。ただし、処理速度は次の要素に左右されます。
  • Active Directory から Exchange Server 5.5 へのレプリケーションが完了するまでに要する時間
  • Exchange Server 5.5 でのサイト間のレプリケーション


リンクされた Exchange Server 5.5 および Active Directory オブジェクトに関する、管理グループ間での移動中の ADC の動作

スタブ Exchange Server 5.5 オブジェクトと Active Directory オブジェクトは、サイト間での移動時にリンクが解除されます。パブリック フォルダ移行ツール (PFMigrate) では、ADC グローバル名で新しい NM_MOVED_CROSS_SITE フラグを使用して、両方のオブジェクトに別の ADC グローバル名の値を割り当てます。ADC はこれらの 2 つのオブジェクトをリンクしません。したがって、クリーンアップの終了時に、Active Directory オブジェクトを削除せずに、スタブ オブジェクトを削除できます。

ADC は、スタブ Exchange Server 5.5 オブジェクトが Active Directory にレプリケートされることを防止します。これは、ADC GlobalNames が削除されてから別の値で再スタンプされるためです。ADC でレプリケーションが防止されないと、パブリック フォルダ ディレクトリ オブジェクトが Active Directory にレプリケートされ、その結果、オブジェクトが重複します。また、ADCGlobalNames がすべてのドメイン コントローラにレプリケートされないと、ユーザーが Active Directory オブジェクトにリンクし直される場合もあります。PFMigrate は、パブリック フォルダに ADCDoNotReplicate を X.500 プロキシ アドレスとしてスタンプします。この ADCDoNotReplicate スタンプによって、ADC はこのオブジェクトを Active Directory にレプリケートしないことを認識します。ADC GlobalNames はサイト間でレプリケートされないため、サイト間のビット (cross-site bit) を使用してこの動作を停止することはできません。そのため、ローカル サイト以外のサイトの変更をレプリケートする接続許可書はサイト間のビットを認識せず、削除と更新がレプリケートされます。

ADC のクリーンアップの動作

配布グループの更新
Exchange Server 5.5 では、古い Exchange Server 5.5 パブリック フォルダ オブジェクトを配布リストから削除し、移動後のパブリック フォルダを Active Directory からの配布リスト内で更新する必要があります。

ドメイン オブジェクトは、Active Directory 内の最も基本的なオブジェクトの 1 つです。これ以外のオブジェクトはすべてドメイン オブジェクトの下位のオブジェクトです。ドメイン オブジェクトの識別名 (DN) は、ドメインの DNS 名のドメイン コンポーネント (dc) で構成されます。たとえば、microsoft.com ドメインのオブジェクトの DN は dc=microsoft,dc=com です。このオブジェクトに使用される objectclass は domainDNS、objectcategory は DomainDNS です。

配布リストのメンバシップは DN に基づいています。また、そのメンバシップは、パブリック フォルダを管理グループ間で移動する際に変更されません。したがって、Active Directory はパブリック フォルダの正しいメンバシップを保持します。ADC は Exchange Server 5.5 にレプリケートする際に、ADCGlobalNames コマンドを使用してグループのメンバシップと DN リンクを参照します。ADC は、Active Directory グループのレプリケーションを強制することで Exchange Server 5.5 配布リストを更新できますが、Exchange Server 5.5 サイト間で遅延が発生する場合があります。この問題を回避するために、ADC は Exchange Server 5.5 ディレクトリの検索時に新しいオブジェクトを検出できなかった場合、古いオブジェクトにリンクし直せるように DN リンクの参照を完了します。

古い Exchange Server 5.5 パブリック フォルダが削除され、配布リストのクリーンアップの終了後にこのパブリック フォルダがスタブ オブジェクトとして保持されていない場合、このパブリック フォルダは配布リストから削除され、配布リストのメンバシップを失います。これは、配布リストが Active Directory にレプリケートされ、配布リストからユーザーが削除された場合に発生する可能性があります。ただし、スタブ パブリック フォルダが保持されているため、これらの配布リストをクリーンアップするプロセスが必要です。そのプロセスによって、新しく移動されたパブリック フォルダ オブジェクトを Exchange Server 5.5 サイト間で配布リストに追加し、最終的にスタブ パブリック フォルダ オブジェクトを削除できるようにする必要があります。この動作は、以下の 2 つのいずれかの方法で発生する場合があります。
  • PFMigrate プロセスが、Active Directory 内にある、移動後のパブリック フォルダが所属するすべての配布リストを処理します。したがって、Active Directory は、Exchange Server 5.5 に正しいメンバシップをレプリケートします。レプリケートされた ObjectVersion 属性は Active Directory 内で更新されます。
  • 配布リストが移動先サイト内に存在しない場合、ADC は、パブリック フォルダが所属するすべての配布リストを自動的かつ強制的にレプリケートできます。PFMigrate は、管理グループ間で移動されるすべてのパブリック フォルダに X500:ADCDeleteWhenUnlinked プロキシ値をスタンプし、配布リストのメンバシップを参照します。ADC は、X500:ADCDeleteWhenUnlinked をプロキシ アドレスとして持つオブジェクトを検索してレプリケーションを強制的に実行します。配布グループがローカル サイト内に存在する場合、ADC は、新しいサイト内にある新しいパブリック フォルダに正しいメンバシップを持つ Active Directory 内のグループにアクセスして、Exchange Server 5.5 へのレプリケーションを強制的に実行します。この動作は、未解決の DN リンクをディレクトリ クリーンアップによって解決するために、ADC のフェーズに追加されました。この動作は 12 時間おきに実行されます。



元の Exchange Server 5.5 サイト内にあるスタブ オブジェクトの削除


X500:ADCDeleteWhenUnlinked プロキシ値は、オブジェクトの MemberOf 属性が空の場合にそのオブジェクトを削除する必要があることを示すために、PFMigrate プロセスによってオブジェクトにスタンプされます。この属性は、前に説明した更新後の配布リストの動作が理由でオブジェクトがどの配布グループにも所属しないことを示します。この動作も、未解決の DN リンクをディレクトリ クリーンアップによって解決するために、ADC のフェーズに追加されました。

Outlook Web Access と Outlook の開封済み/未読の状態

パブリック フォルダがサイト間で移動されて別のサーバーに移動すると、パブリック フォルダ内のメッセージの開封済み/未読の状態が失われます。この現象は、開封済み/未読の状態がサーバー間でレプリケートされないために発生します。そのため、ユーザーが Outlook Web Access を使用している場合、または Outlook がサイト間で移動済みのパブリック フォルダにアクセスした場合、すべてのメッセージが未開封として表示されます。この現象は、パブリック フォルダのレプリカをサイト内で移動した場合も発生します。この現象は、サイト間での移動時に限って発生するものではありません。

サイト間で移動されたパブリック フォルダへのアクセス

以下の現象が発生する場合があります。
  • 移動後のパブリック フォルダへのアクセスが一時的に拒否される。
  • パブリック フォルダの新しいホームにリダイレクトされない。
  • 新しいパブリック フォルダに一部のコンテンツしか存在しない。
この現象は、以下のいずれかの理由で発生する場合があります。
  • サイト間で移動されたパブリック フォルダにアクセスする、ユーザーのサーバー上で、レプリカ一覧が更新されていない場合、ユーザーはレプリカ一覧が更新されるまで、更新前のレプリカ一覧に接続されます。更新前のレプリカが削除されると、ユーザーはパブリック フォルダへのアクセスを受信しなくなります。レプリカ一覧は、サイト間での移動後の 5 分以内に更新されることが想定されています。ただし、パブリック フォルダのレプリカが削除される前に、レプリカ一覧をレプリケートできない場合、ユーザーはレプリカ一覧が更新されるまで、パブリック フォルダにアクセスできません。
  • ユーザーは、新しいサイトにすべてのコンテンツがレプリケートされる前に、その新しいサイトに接続してパブリック フォルダにアクセスする場合があります。


パブリック フォルダの類似性

パブリック フォルダの類似性が新しいサイトに設定されていないと、パブリック フォルダへのアクセスが完了しない場合があります。この現象が発生するのは、パブリック フォルダをサイト間で移動する前に、パブリック フォルダの新しい "ホーム" サイトに対して類似性が構成されている必要があるためです。また、この現象は、パブリック フォルダのレプリカを移動した場合にも発生し、サイト間での移動時に限って発生するものではありません。

パブリック フォルダの類似性とは、クライアント プログラムが別のサイト内のサーバーの参照およびパブリック フォルダへのアクセスを行うための機能です。これは、パブリック フォルダをローカル サイトにレプリケートする代わりに実行されます。通常、パブリック フォルダの類似性は、高帯域幅の接続が存在する場合に使用されます。

: メールボックスの移動時に移動元サイトと移動先サイトの両方でレプリカを提供するためのガイダンスに従っている場合、パブリック フォルダの類似性は必要ありません。類似性は、メールボックスの移動前または移動後にパブリック フォルダ全体が移動される場合に必要です。

既知の問題 : サイト間でパブリック フォルダを移動した後に発生する現象

パブリック フォルダへの電子メール メッセージ送信時の Exchange Server 5.5 ユーザーと Exchange Server 2003 ユーザーへの影響

管理グループ間での移動中、および ADC による Exchange Server 5.5 ディレクトリ オブジェクトのクリーンアップ中に、ユーザーがパブリック フォルダに電子メール メッセージを送信すると、メッセージ配布の問題が発生する場合があります。

: サイト間での移動中、ユーザーは、次のエラーを含む配信不能レポート (NDR) を受信する場合があります。
アクセスが拒否されました。0x80070005




仕訳ルール


フォルダ ID (FID) に基づく、パブリック フォルダとの間でメッセージを移動する仕訳ルールは、パブリック フォルダを管理グループ間で移動した後、機能しなくなります。次のようなメッセージが表示される場合があります。
目的のフォルダが見つかりませんでした。




グローバル アドレス一覧内における移動後のパブリック フォルダ


管理グループ間で移動されたパブリック フォルダが、Exchange Server 5.5 のグローバル アドレス一覧に表示されない場合があります。この現象は、古いサイトの元の Exchange Server 5.5 オブジェクトが非表示に設定されていて、新しい Exchange Server 5.5 オブジェクトが Active Directory から新しいサイトにレプリケートされる前に発生する可能性があります。管理グループ間で移動されたパブリック フォルダは、Active Directory、Exchange 2000 Server グローバル アドレス一覧、または Exchange Server 2003 グローバル アドレス一覧内では影響を受けません。



履歴


Exchange Server 5.5 または Exchange 2000 Server の履歴で使用するパブリック フォルダが管理グループ間で移動されると、履歴が機能しなくなります。この問題は、LegacyExchangeDN 属性が変更されることが理由で発生します。

: Exchange 2000 および Exchange Server 2003 のパブリック フォルダへの履歴はサポートされていません。これを行うと、Exchange 環境で機能とパフォーマンスの両面で問題が発生する可能性があります。サイト間の移動後、履歴を再構成する場合は、パブリック フォルダではなく、メールボックスを対象にするように履歴を変更します。



組織フォーム


組織フォームは、PFMigrate スクリプトによってサイト間で移動されません。組織フォームはシステム フォルダの一部で、管理者は、組織フォームと他のシステム フォルダに関してパブリック フォルダのレプリカ一覧を手動で更新する必要があります。


パブリック フォルダを使用するサードパーティ製プログラム


パブリック フォルダがサイト間で移動された後、パブリック フォルダとそのパブリック フォルダの LegacyExchangeDN 属性を使用するサードパーティ製プログラムが機能しなくなる場合があります。

プロキシ アドレス
パブリック フォルダには、古いサイトの元のプロキシ アドレスが保持されます。また、受信者ポリシーが管理グループのメンバシップに基づく場合でも、パブリック フォルダは、移動中の管理グループからは新しいプロキシ アドレスを取得しません。

パブリック フォルダに同じ種類のプロキシが既に存在する場合、受信者更新サービスは、更新後のプロキシをスタンプしません。新しい管理グループのメンバシップに基づいてユーザーに適用される受信者ポリシーの新しいプロキシ アドレスを受信するには、受信者ポリシーの [今すぐこのポリシーを適用] をクリックし、受信者更新サービスを再構築します。この作業はネットワークのパフォーマンスに影響する場合があるため、必要でない限り行わないことをお勧めします。

プロキシ アドレスが更新されていない場合でも、電子メール メッセージのフローに影響はありません。ただし、システムで、非常に限定されたいくつかの制限チェックを実行する場合は、アドレスが更新されていないと、問題が発生する可能性があります。たとえば、次のシナリオを考えます。
  • AG1 は、domain1.com の電子メール メッセージを受け付けます。
  • AG2 は、domain2.com の電子メール メッセージを受け付けます。
  • 2 つの管理グループを接続するコネクタは、組織の外部のユーザーからの電子メール メッセージの送信を許可しません。
  • したがって、電子メール メッセージは NDR を生成します。電子メール メッセージはコネクタを介して送信されません。




ディレクトリ サービス/インフォメーション ストア整合性調整機能の "ホーム サーバーのリセット" オプションの実行


パブリック フォルダをサイト間で移動した後は、すべてのディレクトリ レプリケーションが完了するまで、ディレクトリ サービス/インフォメーション ストア (DS/IS) 整合性調整機能を "ディレクトリと同期して、パブリックのホーム サーバーの値をリセット" オプションを有効にした状態で実行しないことをお勧めします。DS/IS 整合性調整機能は必要でない限り実行しないことをお勧めします。DS/IS 整合性調整機能を実行する場合は、パブリック フォルダのサイト間での移動が完了した後で実行してください。
パブリック フォルダがサイト間で移動された直後に、DS/IS 整合性調整機能を実行すると、PFMigrate によって指定された移動先サイトとは別のサイトにパブリック フォルダのホームがリセットされる場合があります。この現象は、以下の条件に該当する場合に発生する可能性があります。
  • PFMigrate を実行して、サイト内のすべてのパブリック フォルダのレプリカを新しいサイト内の移動先サーバーに追加した。
  • PFMigrate を実行して、移動元サイト内のすべてのサーバーからパブリック フォルダのレプリカをすべて削除した。
  • 格納された属性が Active Directory から Exchange Server 5.5 ディレクトリにレプリケートされる前に、管理者が DS/IS 整合性調整機能を実行した。
ただし、Active Directory が Exchange Server 5.5 とレプリケートした後は、DS/IS 整合性調整機能を実行しても問題ありません。

管理グループ間でメールボックスを移動した後に発生する現象のトラブルシューティング

Exchange Server 5.5 ユーザーと Exchange Server 2003 ユーザーへの影響

管理グループ間での移動中、および ADC による Exchange Server 5.5 ディレクトリ オブジェクトのクリーンアップ中には、メッセージ配信の問題がいくつか発生します。この現象に対応できるように、発生が予想される問題について十分に確認しておくことをお勧めします。

メール フローの問題

メールボックスが移動された後の短時間、メッセージが別のサイト内のサーバー用にキューに格納される場合があります。これは、そのサーバーがローカル サイト内に存在するかのように行われます。この現象は、メッセージ転送エージェント (MTA) がサイト間でのユーザーの移動方法を認識していないために発生します。そのため、MTA は、PR_IN_TRANSIT ブロックが解放された後、いくつかの誤った想定を行います。

メッセージの配信試行は、リモート プロシージャ コール (RPC) によって実行されます。X400 コネクタのみでサイトを接続している場合、およびサイトが同じセキュリティ コンテキスト (同じサービス アカウント) を使用していない場合、メッセージの配信試行は失敗します。また、Exchange 5.5 サーバー上では、次のようなエラー メッセージが記録される場合もあります。



種類 : 警告
ソース : MSExchangeMTA
分類 : Interface
イベント ID : 9318
ユーザー : N/A
コンピュータ : Exchange5.5ServerName
説明 : RPC 通信エラーが発生しました。RPC をバインドできません。LTAB (ローカリティ テーブル) インデックス: 6、NT/MTA エラー コード: 1753。コマンド エラー 1753、バインド エラー 0、リモート サーバー名 ExchangeServerName です。[MAIN BASE 1 500 %10] (14)



この問題を回避するには、サイト間に一時的にサイト コネクタを作成します。これにより、問題があるサーバー間に直接 RPC 接続を確立できます。この接続により、メールを配信できるようになります。サイト間でのメールボックスの移動が完了し、MTA がユーザーの正しいルーティングを適切に特定した後は、この問題は発生しません。



仕訳ルール


ユーザーとその Exchange LegacyExchangeDN に基づく任意の仕訳ルールがクライアント側またはサーバー側に存在する場合に、ユーザーを管理グループ間で移動すると、ユーザーの LegacyExchangeDN が変更されるため、仕訳ルールが無効になります。ただし、ユーザーが Exchange Server 2003 Service Pack 1 以降をベースにしたサーバー上に存在する場合は、仕訳ルールは解除されません。Exchange Server 2003 Service Pack 1 では、仕訳ルールは管理グループ間での移動後に機能します。これは、メールボックス ストアに対する変更により、ユーザーの LegacyExchangeDN が変更された場合でも仕訳ルールが機能できるようになるためです。 Exchange Server 2003 Service Pack 1 サーバー上での仕訳処理では、LegacyExchangeDN 属性を使用する代わりに、管理グループ間での移動時に追加された追加の X.500 プロキシ アドレスを使用できます。

ユーザーのホーム サーバーが Exchange Server 2003 Service Pack 1 を実行していない場合、管理グループ間で移動されるユーザーに基づく仕訳ルールは再作成する必要があります。



グローバル アドレス一覧内における移動後のユーザー
管理グループ間で移動されたユーザーが、短時間、Exchange Server 5.5 のグローバル アドレス一覧に表示されない場合があります。この現象は、古いサイト内の元の Exchange Server 5.5 オブジェクトが非表示に設定され、新しい Exchange Server 5.5 オブジェクトが Active Directory の新しいサイトにレプリケートされるまでの間に発生する可能性があります。管理グループ間で移動されたユーザーは、Active Directory、Exchange 2000 Server、および Exchange Server 2003 のグローバル アドレス一覧内では影響を受けません。

プロキシ アドレス


ユーザーは、古いサイトの元のプロキシ アドレスを保持します。ただし、受信者ポリシーが管理グループのメンバシップに基づく場合でも、ユーザーは、移動中の管理グループからは新しいプロキシ アドレスを取得しません。

ユーザーに同じ種類のプロキシが既に存在する場合、受信者更新サービスは、更新後のプロキシをスタンプしません。新しい管理グループのメンバシップに基づいてユーザーに適用される受信者ポリシーの新しいプロキシ アドレスを受信するには、受信者ポリシーの [今すぐ適用] をクリックし、受信者更新サービスを再構築します。この作業はネットワークのパフォーマンスに影響する場合があるため、受信者更新サービスが必要でない限り行わないことをお勧めします。

プロキシ アドレスが更新されていない場合でも、電子メール メッセージのフローに影響はありません。ただし、システムで、非常に限定されたいくつかの制限チェックを実行する場合は、アドレスが更新されていないと、問題が発生する可能性があります。たとえば、次のシナリオを考えます。
  • AG1 は、domain1.com の電子メール メッセージを受け付けます。
  • AG2 は、domain2.com の電子メール メッセージを受け付けます。
  • 2 つの管理グループを接続するコネクタは、組織の外部のユーザーが電子メールを送信することを許可しません。
  • したがって、電子メール メッセージは NDR を生成します。電子メール メッセージはコネクタを介して送信されません。

Outlook Web Access ログオン プロセス


フロントエンド/バックエンド実装の場合、ユーザーは "明示的なログオン" または "暗黙的なログオン" のいずれかを利用することで、Outlook Web Access (OWA) を介してメールボックスにアクセスできます。明示的なログオンの URL では、ユーザーがアクセスするサーバーとメールボックスを指定します。この URL の形式は、http://servername/exchange/username/ で、servername は OWA のフロントエンド サーバーまたはバックエンド サーバーの名前、username はユーザーの Microsoft Windows アカウントの名前です。ユーザーが明示的なログオンを使用して Outlook Web Access (OWA) にアクセスすると、ログオンが機能しない場合があります。この問題が発生するのは、ユーザーが管理グループ間で移動されたときに、そのユーザーが Outlook Web Access (OWA) で使用する HTTP 仮想ディレクトリが変更されたためです。これが変更される理由は、ユーザーの Exchange メールボックスのバックエンド サーバーが変更されるためです。新しい HTTP 仮想ディレクトリ上の SMTP アドレスが、ユーザーが使用する SMTP アドレスでない場合は、ログオン エラーが発生します。

: デフォルトの Exchange Outlook Web Access 仮想ディレクトリは、デフォルトの受信者ポリシーとそのポリシー内の SMTP アドレスを使用するようにすべてハード コードされています。新しい仮想ディレクトリを作成する場合は、SMTP アドレスごとに異なる受信者ポリシーのみを使用できます。

この問題は、以下のシナリオのいずれかで発生する可能性があります。
  • シナリオ 1 : 移動元サイトが、サイトごとに SMTP アドレスが異なる純粋な Exchange Server 5.5 サイトであり、現在のメールボックスに設定された Exchange Server 5.5 上の SMTP アドレスが、Exchange Server 2003 Service Pack 1 サーバー上のデフォルトの Exchange 仮想ディレクトリの SMTP アドレスと一致しません。このシナリオでは、ユーザーが Exchange Server 5.5 から Exchange Server 2003 に移動し、Outlook Web Access で明示的なログオンを使用して Exchange Server 2003 Service Pack 1 サーバーへのログオンを試みても、ログオンできません。
  • シナリオ 2 : Exchange 2000 Server/Exchange Server 2003 の混在環境または純粋環境で、ユーザーが Outlook Web Access 用に現在使用している専用の仮想ディレクトリが、管理者によって作成され、デフォルトの仮想ディレクトリではありません。その専用の仮想ディレクトリは、受信者ポリシーの SMTP アドレスを使用します。この受信者ポリシーは、Exchange 組織内のメールボックスが使用する SMTP アドレスも提供します。つまり、これらの SMTP アドレスは一致しています。ユーザーが新しいサイトに移動されると、SMTP アドレスは、デフォルトの Exchange Outlook Web Access 仮想ディレクトリを使用するようにセットアップされた新しい Exchange メールボックス サーバーに移動されます。このデフォルトの Exchange 仮想ディレクトリは、デフォルトの受信者ポリシーを使用し、ユーザーの SMTP アドレスとは別の SMTP アドレスを持ちます。したがって、ユーザーが Exchange Server 5.5 から Exchange Server 2003 に移動し、Outlook Web Access で明示的なログオンを使用して Exchange Server 2003 Service Pack 1 サーバーへのログオンを試みても、ログオンできません。
シナリオ 1 および 2 の問題を回避するには、以下のいずれかの回避策を使用します。
  • 新しいサイト内に、ユーザーの移動先である新しいメールボックス サーバー専用の仮想ディレクトリを作成します。新しい専用の仮想ディレクトリで、ユーザーの SMTP アドレスを含む受信者ポリシーを指定します。
  • 混在サイトまたは純粋な Exchange 2000 Server シナリオでは、デフォルトの受信者ポリシーの SMTP アドレスを、移動後のユーザーに適用する受信者ポリシーに追加します。受信者更新サービスが更新された後、デフォルトの仮想ディレクトリと一致する追加の SMTP プロキシがユーザーに割り当てられます。
  • 正しい SMTP アドレスを移動後のユーザーに手動で追加します。
Exchange Server 2003 Service Pack 1 に含まれる修正により、SMTP アドレスを暗黙的なログオンまたは明示的なログオンで使用してこの問題を回避できるようになります。Exchange Server 2003 Service Pack 1 ベースのサーバーに接続すると、Outlook Web Access は常に以下のシナリオで機能します。
  • 暗黙的なログオン
    たとえば、OWA アクセス用の URL を次の形式で入力します。
    http://Server/exchange
  • ユーザー プリンシパル名 (UPN) または SMTP アドレスを使用する明示的なログオン
    たとえば、OWA アクセス用の URL を次の形式で入力します。
    http://server/exchange/user@Domain_Name.com

HTTP 仮想ディレクトリの SMTP アドレスを持たないユーザーのエイリアスを使用して明示的なログオンを試みると、ログオンが完了しません。たとえば、OWA アクセス用の URL を http://Server/exchange/User の形式で入力しても、Exchange サーバーのメールボックスにアクセスしません。この問題は、ユーザーのエイリアスを使用する明示的なログオンが OWA で使用されると常に発生し、管理グループ間のシナリオに限って発生するものではありません。



空き時間情報とリソース メールボックス


サイト間でメールボックスが移動された後は、空き時間情報が再発行される必要があります。ユーザーのメールボックスの場合、ユーザーが Outlook を使用して Exchange サーバーにログオンし、予定表のアクションを実行した 15 分後に、空き情報が再発行されます。たとえば、ユーザーが会議出席依頼の承諾、削除、または作成を行った場合、予定表の空き時間情報は 15 分後に再発行されます。

会議室などのリソース メールボックスの所有者は、メールボックスを開き、予定表のアクションを実行して空き時間情報を再発行する必要があります。

この現象が発生するのは、ユーザーの新しい LegacyExchangeDN 属性に対する空き時間情報メッセージが移動先サイト内に存在しないにもかかわらず、予定表の変更が行われるまで Outlook が更新を発行せず、Outlook の "ローカル" の空き時間情報キャッシュの整合性が取れない状態になるためです。また、この現象は、GUIDGen プロセスを通してサイトのシステム フォルダをリセットする場合にも発生します。

また、UpdateFB ツールを使用して、この空き時間情報の再発行処理を自動化することもできます。

UpdateFB ツールの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
294282 [XADM] Updatefb.exe を使用して、存在しない空き時間データを再発行する方法


オフライン アドレス帳

オフライン アドレス帳のダウンロードとリモート サイト
Exchange Server 2003 以前のバージョンが実行されるリモート サイトで、Outlook 2003 をキャッシュ モードで実行するときは、リモート サイトのすべてのクライアントがオフライン アドレス帳の完全ダウンロードを実行するのに十分な帯域幅があることを確認する必要があります。



低速リンクを経由するリモート サイト


Outlook 2003 をキャッシュ モードで使用するメールボックスが、リモート Exchange Server 5.5 サーバーから中央の Exchange 2003 SP1 サーバーに移動される場合、この移動がサイト間で行われるかどうかにかかわらず、オフライン アドレス帳の完全ダウンロードを実行する必要があります。また、ディレクトリに大幅な変更が加えられた場合、または新しい管理グループが追加または削除された場合は、キャッシュ モードのユーザーに関してオフライン アドレス帳の完全ダウンロードが発生します。したがって、リモート サイトでは、リモート サイトのすべてのクライアントがオフライン アドレス帳の完全ダウンロードを実行できるだけの十分な帯域幅があることを確認する必要があります。



オフライン アドレス帳の完全ダウンロードに関する追加情報


通常、Outlook クライアントにはオフライン アドレス帳の差分ダウンロードのみが表示されます。これは、オフライン アドレス帳の完全ダウンロードの小さなサブセットで、グローバル アドレス一覧のすべての情報ではなく、変更された情報のみが含まれています。ただし、Outlook クライアントがオフライン アドレス帳の完全ダウンロードを実行する必要がある場合もあります。ディレクトリに非常に多くの変更が加えられている場合 (たとえば、多数の新規アカウント、名前の変更、Exchange 管理グループの追加や削除)、キャッシュ モードのすべてのクライアントは、オフライン アドレス帳のすべての情報で更新されます。また、Exchange Server 5.5 から新しい Exchange Server 2003 サーバーに移動されるクライアントは、オフライン アドレス帳のすべての新しい情報も受信します。

Exchange Server 2003 でオフライン アドレス帳の完全ダウンロードの影響範囲を小さくする方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
867623 Exchange Server 2003 でオフライン アドレス帳の完全ダウンロードを調整して、LAN への影響を小さくする方法


ディレクトリ更新の発生まで待機する

管理者は、電子メール メッセージが配信不能レポート (NDR) を生成せずに配信できるようになる前に、ディレクトリ更新が発生するまで待機する必要があります。

既知の問題 : オブジェクトのリセット後に発生する現象

Exchange Server 5.5 と Exchange Server 2003 で連絡先および配布リストに電子メールを送信するユーザーのメッセージ配信への影響

管理グループ間での移動中、および ADC による Exchange Server 5.5 ディレクトリ オブジェクトのクリーンアップ中に、ユーザーが連絡先および配布リストに電子メール メッセージを送信すると、メッセージ配信に関する問題がいくつか発生する場合があります。

仕訳ルール


管理グループ間での移動時に配布リストやグループが移動されると、DL が送信者または受信者のメッセージを処理する仕訳ルールが、Exchange Server 2003 Service Pack 1 より前の Exchange サーバー上でホストされるメールボックスに対して機能しなくなります。これらの仕訳ルールは再作成する必要があります。また、仕訳ルールが適用されたメールボックスは、Exchange 2003 SP1 を実行するサーバーに移動する必要があります。



グローバル アドレス一覧内における移動後のパブリック フォルダ


連絡先/配布リストが移動されたとき、これらが Exchange Server 5.5 のグローバル アドレス一覧に表示されない場合があります。この現象が発生するのは、古いサイト内にある元の Exchange Server 5.5 オブジェクトが非表示に設定されてから、新しい Exchange Server 5.5 オブジェクトが Active Directory の新しいサイトにレプリケートされるまでの間です。Active Directory、Exchange 2000 Server グローバル アドレス一覧、または Exchange Server 2003 グローバル アドレス一覧内の再格納されたオブジェクトには影響しません。



プロキシ アドレス


移動されるオブジェクトは、古いサイトの元のプロキシ アドレスを保持します。ただし、受信者ポリシーが管理グループのメンバシップに基づく場合でも、オブジェクトが管理グループ間で移動されたときには新しいプロキシ アドレスを取得しません。

移動されるオブジェクトに同じ種類のプロキシが既に存在する場合、受信者更新サービスは、オブジェクトに更新後のプロキシをスタンプしません。新しい管理グループのメンバシップに基づいてオブジェクトに適用される受信者ポリシーの新しいプロキシ アドレスを受信するには、受信者ポリシーの [今すぐ適用] をクリックし、受信者更新サービスを再構築します。この作業はネットワークのパフォーマンスに影響する場合があるため、必要でない限り行わないことをお勧めします。
プロキシ アドレスが更新されていない場合でも、電子メール メッセージのフローに影響はありません。ただし、システムで、非常に限定されたいくつかの制限チェックを実行する場合は、アドレスが更新されていないと、問題が発生する可能性があります。たとえば、次のシナリオを考えます。
  • AG1 は、domain1.com の電子メール メッセージを受け付けます。
  • AG2 は、domain2.com の電子メール メッセージを受け付けます。
  • 2 つの管理グループを接続するコネクタは、組織の外部のユーザーが電子メール メッセージを送信することを許可しません。
  • そのため、電子メール メッセージは NDR を生成します。電子メール メッセージはコネクタを介して送信されません。


サイト間で移動された連絡先で X.500 アドレスが組織間の ADC によって上書きされる


次のようなシナリオを考えます。組織間の接続許可書 (CA) によって組織内に連絡先を作成します。この連絡先は、別の組織内のメールボックスを表します。この連絡先をサイト間で移動すると、移動後の連絡先に、移動元サイトの連絡先の元のディレクトリ名が X.500 アドレス形式でスタンプされます。ただし、この連絡先が表すメールボックスが変更された場合は、その変更が移動後の連絡先オブジェクトにレプリケートされ、ADC が X.500 アドレスを上書きします。

この問題を回避するには、次のうち 1 つまたは複数の手順を使用します。
  • ADC を新しいサイトに対して再構成し、ツールを実行します (X.500 アドレスはすべて失われます)。
  • サイト間で移動する前に、Exchange Server 5.5 から LegacyExchangeDN をエクスポートします。次に、LegacyExchangeDN を Exchange Server 5.5 メールボックスの X.500 アドレスとしてインポートします。
  • Exchange ネイティブ モードに切り替え、連絡先を移動しません。


ADC が完了するまで待機する


Active Directory が Exchange Server 5.5 レプリケーション、サイト内レプリケーション、およびサイト間レプリケーションを完了するまで待機する必要があります。Exchange Server 5.5 ディレクトリが同期され、ADC が実行されて変更箇所が修正されるまでは、電子メール メッセージのフローや他の操作に影響があります。

ディレクトリ サービス/インフォメーション ストア整合性調整機能を実行する


パブリック フォルダへのアクセス権が付与されている配布リストがサイト間で移動された後は、修正プログラムを適用済みのディレクトリ サービス/インフォメーション ストア (DS/IS) 整合性調整機能ツールを実行して、配布リストからパブリック フォルダにアクセスできるようにする必要があります。

関連情報

関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
843107 Exchange Server 2003 Service Pack 1 で pfMigrate ツールを使用して、パブリック フォルダのサイト間の移動操作を実行する方法

関連情報

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 841659 (最終更新日 2005-02-24) を基に作成したものです。

プロパティ

文書番号: 841659 - 最終更新日: 2007年11月21日 - リビジョン: 4.1
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 2003 Service Pack 1
キーワード:?
kbinfo kbexchange2003sp1fix KB841659
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com