Exchange Serverでのシャドウ冗長性

  • [アーティクル]

Exchange 2010 において、メッセージをメールボックスに配信する前にメッセージの冗長コピーを提供するため、シャドウ冗長が導入されました。 Exchange 2010 では、メッセージ配信パスの次のホップで配信が完了したことをサーバーが確認するまで、シャドウ冗長がハブ トランスポート サーバー上のキュー データベースからのメッセージの削除を遅延させました。 次のホップで、ハブ トランスポート サーバーに正常配信を報告する前に失敗した場合、トランスポート サーバーはその次のホップにメッセージを再送信していました。 Exchange 2010 ハブ トランスポート サーバーは XSHADOW コマンドを使用して、サーバーのシャドウ冗長サポートを通知していました。 ソース メッセージング サーバーがシャドウ冗長をサポートしていない場合、Exchange 2010 は受信コネクタで構成された時間間隔を基に遅延した肯定応答を使用して、メッセージの冗長コピーを作成していました。

Exchange 2016 と Exchange 2019 には、Exchange 2013 のシャドウ冗長性に加えられたのと同じ機能強化があります。メールボックス サーバー上のトランスポート サービスは、メッセージの受信を確認する前に受信したメッセージの冗長コピーを送信サーバーに作成するようになりました。 転送中のメッセージの冗長コピーを維持することは、シャドウ冗長性が送信サーバーのサポートされている機能に依存しないため、動作する可能性があるベスト エフォート以上の作業です (シャドウ冗長性のサポートまたはサポート不足は関係ありません)。 これにより、転送中にトランスポート パイプライン内のすべてのメッセージが冗長になります。 Exchange が転送中に元のメッセージが失われたと判断した場合、メッセージの冗長コピーは再配信されます。

Exchange Serverでのトランスポート高可用性機能の詳細については、「Exchange Serverでのトランスポートの高可用性」を参照してください。 メッセージが正常に配信された後のメッセージ冗長性の詳細については、「Exchange Serverのセーフティ ネット」を参照してください。

シャドウ冗長のコンポーネント

次の表は、メールボックス サーバー上のトランスポート サービスにおけるシャドウ冗長のコンポーネントを示しています。 以下の用語は、このトピック全体で使用されます。

用語 説明
トランスポート高可用性境界 データベース可用性グループ (DAG) 環境内の DAG、または非 DAG 環境内の Active Directory サイト。 複数の Active Directory サイトにまたがる DAG の場合、DAG そのものは境界です (サイトではない)。

メッセージがトランスポート高可用性境界内のメールボックス サーバーに届くと、Exchange は境界内のメールボックス サーバーでメッセージの 2 つの冗長コピーを保持しようとします。 メッセージがトランスポート高可用性境界を離れるとき、Exchange はメッセージの冗長コピーの保持をやめます。
プライマリ メッセージ 配信用のトランスポート パイプラインに送信されるメッセージ。
シャドウ メッセージ プライマリ メッセージがプライマリ サーバーによって正常に処理されたことをシャドウ サーバーが確認するまで、シャドウ サーバーが保持するメッセージの情報コピー。
プライマリ サーバー プライマリ メッセージを処理しているメールボックス サーバー。
シャドウ サーバー プライマリ サーバーのシャドウ メッセージを保持するメールボックス サーバー。 メールボックス サーバーは、あるメッセージではプライマリ サーバーに、その他のメッセージではシャドウ サーバーに同時になることがあります。
シャドウ キュー シャドウ サーバーがシャドウ メッセージを格納する配信キュー。 複数受信者が設定されたメッセージの場合、プライマリ メッセージのそれぞれの次のホップはそれぞれのシャドウ キューを必要とします。
破棄状態 メールボックス サーバーがシャドウ メッセージ用に保持する情報。プライマリ メッセージが正常に処理されたことを示します。
破棄通知 シャドウ サーバーがプライマリ サーバーから受信する応答。シャドウ メッセージが破棄可能な状態であることを示します。
セーフティ ネット Exchange 2013 以降でのトランスポート収集の改良版。 メールボックス サーバー上のトランスポート サービスにより正常に処理されたか、メールボックス受信者に正常に配信されたメッセージは、セーフティ ネットに移動します。 詳細については、「Exchange Serverのセーフティ ネット」を参照してください。
シャドウ冗長マネージャー シャドウ冗長を管理するトランスポート コンポーネント。
ハートビート プライマリ サーバーとシャドウ サーバーが、互いの稼働状況を確認するためのプロセス。

シャドウ冗長のための要件

明らかなように見えるかもしれませんが、シャドウ冗長性には複数のメールボックス サーバーが必要です。

  • メールボックス サーバーが DAG のメンバーではない場合、その他のメールボックス サーバーがローカル Active Directory サイト内に存在する必要があります。

  • メールボックス サーバーが DAG のメンバーである場合、その他のメールボックス サーバーは同じ DAG に属す必要があります。 他の DAG メンバーは、ローカル Active Directory サイトまたはリモート サイトのいずれに存在してもかまいません。 既定では、DAG が複数の Active Directory サイトにまたがる場合、シャドウ冗長はサイトの回復性のため、リモート サイトにメッセージの冗長コピーを作成しようとします。

シャドウ冗長が送信中のメッセージを保護できない状況を以下に挙げます:

  • 単一 Exchange サーバー環境内。

  • プロビジョニング不足の DAG 内。

  • メッセージのシャドウ冗長に係わる 2 つ以上のメールボックス サーバーで同時に障害が発生しているとき。

シャドウ冗長は既定で有効

既定では、シャドウ冗長はすべてのメールボックス サーバー上のトランスポート サービスでグローバルに有効です。 次の表に、シャドウ冗長を有効にするパラメーターを示します。

パラメーター 既定値 説明
Set-TransportConfig の ShadowRedundancyEnabled $true $true: 組織内のすべてのメールボックス サーバーでシャドウ冗長性が有効になっています。

$false: 組織内のすべてのメールボックス サーバーでシャドウ冗長性が無効になっています。
Set-TransportConfig の RejectMessageOnShadowFailure $false $false: メッセージのシャドウ コピーを作成できない場合、プライマリ メッセージは組織内のメールボックス サーバーによって受け入れられます。 このようなメッセージは、送信中に冗長化で保持されません。

$true: メッセージのシャドウ コピーが正常に作成されるまで、組織内のどのメールボックス サーバーでもメッセージは受け入れも確認もされません。 メッセージのシャドウ コピーを作成できない場合、プライマリ メッセージは一時的エラーにより却下されますが、送信元サーバーはメッセージを再度送信できます。 SMTP 応答コードは です 451 4.4.0 Message failed to be made redundant。 組織内のすべてのメッセージは、送信中に冗長化で保持されます。

注: メッセージのシャドウ コピーを作成できるように、同じ DAG または Active Directory サイトに複数のメールボックス サーバーがある場合にのみ使用 $true します。

このパラメーターは、 ShadowRedundancyEnabled が の $true場合にのみ意味があります。

シャドウ メッセージの作成方法

シャドウ冗長の主要な目標は、メッセージが送信中であるときに、トランスポート高可用性境界内で、常にメッセージのコピーを 2 部保持することにあります。 メッセージの冗長コピーが作成される場所とタイミングは、メッセージの送信元と送信先によって異なります。 シャドウ メッセージの作成には、3 つの決定要因があります。

  • トランスポート高可用性境界の外部から受信したメッセージ (DAG、もしくは非 DAG 環境内の Active Directory サイト)。

  • トランスポート高可用性境界の外部に送信されるメッセージ。

  • トランスポート高可用性境界の内部にあるメールボックス サーバーの、メールボックス トランスポート発信サービスから受信したメッセージ。

シャドウ冗長は、トランスポート高可用性境界を越えてシャドウ メッセージを追跡することはありません。 メッセージがトランスポート高可用性境界を越えると、シャドウ冗長は開始または再開します。 これにより、シャドウ メッセージの保守トラフィックを減らし、シャドウ メッセージがトランスポート高可用性境界を越えて再送信されることを防ぎます。 Exchange 2010 ハブ トランスポート サーバーは特別なケースであり、本稿で後述します。

トランスポート高可用性境界の外部から受信したメッセージ

メールボックス サーバー上のトランスポート サービスがトランスポート高可用性境界の外部からメッセージを受信する場合、メールボックス サーバーは、送信元サーバーがシャドウ冗長をサポートするかどうかを問題としません。 シャドウ冗長が有効である限り、メッセージを受信するメールボックス サーバーは、メッセージを受信した旨の肯定応答を送信元サーバーに送信する前に、トランスポート高可用性境界内の別のメールボックス サーバー上にメッセージの冗長コピーを作成します。 処理の仕組みの一例を以下に示します。

シャドウ メッセージの作成。

  1. メッセージング サーバーは、メールボックス サーバー上のトランスポート サービスにメッセージを送信します。 メールボックス サーバーはプライマリ サーバーで、メッセージはプライマリ メッセージです。

  2. メッセージング サーバーとの元の SMTP セッションがアクティブであれば、プライマリ サーバー上のトランスポート サービスは、組織内の異なるメールボックス サーバー上のトランスポート サービスとの新しい SMTP セッションを同時に開き、メッセージの冗長コピーを作成します。

    • プライマリ サーバーが DAG のメンバーである場合、プライマリ サーバーは同じ DAG の異なるメールボックス サーバーに接続します。 DAG が複数の Active Directory サイトにまたがる場合、別の Active Directory サイト内のメールボックス サーバーが既定で優先されます (Set-TransportConfig コマンドレットの ShadowMessagePreferenceSetting パラメーターの既定値は ですPreferRemoteが、 または LocalOnlyにRemoteOnly変更できます)。

    • プライマリ サーバーが DAG のメンバーでない場合、プライマリ サーバーは、( ShadowMessagePreferenceSetting パラメーターの値に関係なく) 同じ Active Directory サイト内の別のメールボックス サーバーに接続します。

  3. プライマリ サーバーはその他のメールボックス サーバー上のトランスポート サービスにメッセージのコピーを送信し、そのメールボックス サーバー上のトランスポート サービスは、メッセージのコピーが正常に作成された旨の肯定応答を行います。 メッセージのコピーはシャドウ メッセージであり、そのメッセージを保持するメールボックス サーバーは、プライマリ サーバーのシャドウ サーバーになります。 メッセージは、シャドウ サーバー上のシャドウ キューに存在します。

  4. プライマリ サーバーがシャドウ サーバーから肯定応答を受信すると、元の SMTP セッションの元のメッセージング サーバーに対し、プライマリ メッセージを受信した旨の肯定応答を行い、その SMTP セッションは閉じられます。

トランスポート高可用性境界の外部に送信されるメッセージ

メールボックス サーバーがトランスポートの高可用性境界の外でメッセージを送信し、反対側のメッセージング サーバーがメッセージの受信に成功したことを確認し、メールボックス サーバーがメッセージを Safety Net に移動する場合。 プライマリ メッセージがトランスポートの高可用性境界を越えて正常に送信された後、Safety Net からのメッセージの再送信は行われません。 セーフティ ネットの詳細については、「Exchange Serverのセーフティ ネット」を参照してください。

トランスポート高可用性境界の内部で送信されるメッセージ

メッセージ ルーティングは最適化されるため、最終的な送信先が DAG 内部または Active Directory サイトである場合、送信先の DAG またはサイト内のサーバー間の複数ホップは、通常必要ありません。 送信先の DAG または Active Directory のメールボックス サーバー上のトランスポート サービスがメッセージを受け入れた後、メッセージの次のホップは通常最終的な送信先になります (たとえば、送信先メールボックスのアクティブなコピーを保持するメールボックス サーバー)。 メッセージの 2 つのコピーを転送中に保持するというシャドウ冗長性の目標は、メッセージの 1 つのシャドウ コピーが DAG または Active Directory サイト内の 任意の場所 に存在する場合に実現されます。 通常、メールボックス サーバー上のアクティブ メッセージ キューをドレインするのに Redirect-Message コマンドレットを必要とする DAG 内のフェールオーバー シナリオでのみ、同一トランスポート高可用性境界内に複数のホップが必要になります。

Exchange 2016 組織の同じ Active Directory サイト内の Exchange 2010 ハブ トランスポート サーバーによるシャドウ冗長性

Exchange 2010 ハブ トランスポート サーバーが同じ Active Directory サイト内の Exchange 2016 メールボックス サーバーにメッセージを送信するとき、Exchange 2010 ハブ トランスポート サーバーは、XSHADOW コマンドを使用してシャドウの冗長性のサポートを通知しますが、メールボックス サーバーはシャドウの冗長性のサポートを通知しません。 これで、Exchange 2010 ハブ トランスポート サーバーが Exchange 2016 メールボックス サーバー上にメッセージのシャドウ コピーを作成するのを防ぎます。

Exchange 2016 メールボックス サーバー上のトランスポート サービスが、同じ Active Directory サイト内の Exchange 2010 ハブ トランスポートにメッセージを送信するとき、Exchange 2016 メールボックス サーバーは Exchange 2010 ハブ トランスポート サーバー向けのメッセージをシャドウ コピーします。 Exchange 2016 メールボックス サーバーが Exchange 2010 ハブ トランスポート サーバーからメッセージを正常に受信した旨の肯定応答を受信すると、Exchange 2016 メールボックス サーバーはセーフティ ネットに正常に処理されたメッセージを移動します。 ただし、Exchange 2016 メールボックスによりセーフティ ネットに格納された正常に処理されたメッセージは、Exchange 2010 ハブ トランスポート サーバーに再送信されることはありません。

SMTP のタイムアウト

メッセージの冗長コピーの作成を試行している間に、サーバー間 (送信元サーバーとプライマリ サーバー間、またはプライマリ サーバーとシャドウ サーバー間) の SMTP 接続はタイムアウトすることがあります。 受信コネクタと送信コネクタの両方に、データが実際にコネクタで送信されている場合の ConnectionInactivityTimeOut パラメーターがあります。 受信コネクタには、絶対 ConnectionTimeOut パラメーターもあります。

メッセージのシャドウ コピーが正常に作成されて確認される前に SMTP セッションのいずれかがタイムアウトした場合、結果は Set-TransportConfig コマンドレットの RejectMessageOnShadowFailure パラメーターによって制御されます。 既定では、このパラメーターの値は です $false。つまり、シャドウ コピーが作成されずにプライマリ メッセージが受け入れられます。 このパラメーターの値がプライマリ メッセージの $true 場合は、一時的なエラー 451 4.4.0で拒否されます。

メッセージのシャドウ コピーが正常に作成された場合に、送信元サーバーとプライマリ サーバー間の SMTP セッションがタイムアウトすると、プライマリ サーバーはプライマリ メッセージを受け入れ、処理します。 送信元サーバーは肯定応答されていないメッセージを再配信しますが、重複メッセージ検出機能により、Exchange メールボックス ユーザーが重複メッセージを受け取ることはありません。 送信元サーバーがメッセージを再送信すると、プライマリ サーバーはメッセージのシャドウ コピーをもう 1 部作成します。 送信元サーバーによるメッセージの再送信中に作成されたシャドウ メッセージ間に関係はありません。

次の表で、シャドウ メッセージの作成を制御するパラメーターを説明します

ソース 既定値 説明
Set-TransportConfig の ShadowMessagePreferenceSetting PreferRemote このパラメーターは、メッセージのシャドウ コピーを作成しようとしているプライマリ サーバーが、複数の Active Directory サイトにまたがる DAG のメンバーである場合にのみ使用します。
  • PreferRemote: MaxRetriesForRemoteSiteShadow パラメーターで指定された試行回数に基づいて、別の Active Directory サイトの DAG メンバーでメッセージのシャドウ コピーを作成してみてください。 操作が失敗した場合は、 MaxRetriesForLocalSiteShadow パラメーターで指定された試行回数に基づいて、ローカル Active Directory サイトの DAG メンバーでメッセージのシャドウ コピーを作成してみてください。
  • LocalOnly: MaxRetriesForLocalSiteShadow パラメーターで指定された試行回数に基づいて、ローカル Active Directory サイトの DAG メンバーでのみメッセージのシャドウ コピーを作成してみてください。
  • RemoteOnly: MaxRetriesForRemoteSiteShadow パラメーターで指定された試行回数に基づいて、別の Active Directory サイトの DAG メンバーでのみメッセージのシャドウ コピーを作成してみてください。
Set-TransportConfig の MaxRetriesForRemoteSiteShadow 4 このパラメーターは、 ShadowMessagePreferenceSetting パラメーター PreferRemote の値が (既定値) または RemoteOnlyである場合に、DAG 内の別のサーバーでメッセージのシャドウ コピーを作成する試行の最大数を指定します。

このパラメーターは、メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合のみ使用します。

指定した試行回数が経過してもメッセージのシャドウ コピーが正常に作成されない場合、結果は RejectMessageOnShadowFailure パラメーターの値によって異なります。

  • $true: プライマリ メッセージは一時的なエラーで拒否されます。
  • $false: プライマリ メッセージは、とにかく受け入れられますが、冗長に永続化されません。
Set-TransportConfig の MaxRetriesForLocalSiteShadow 2 このパラメーターは、次の場合に、ローカル Active Directory サイトの他のメールボックス サーバーでメッセージのシャドウ コピーの作成を試行する最大回数を指定します。
  • メールボックス サーバーは、複数の Active Directory サイトにまたがる DAG のメンバーであり、 ShadowMessagePreferenceSetting パラメーターの値は PreferRemote (既定値) または LocalOnlyです。
  • メールボックス サーバーが、1 つの Active Directory サイト内の DAG のメンバーである。
  • メールボックス サーバーが DAG のメンバーではない。

指定した試行回数が経過してもメッセージのシャドウ コピーが正常に作成されない場合、結果は RejectMessageOnShadowFailure パラメーターの値によって異なります。

  • $true: プライマリ メッセージは一時的なエラーで拒否されます。
  • $false: プライマリ メッセージは、とにかく受け入れられますが、冗長に永続化されません。
Set-ReceiveConnector の ConnectionInactivityTimeout メールボックス サーバー上のトランスポート サービスでの受信コネクタの場合、5 分 このパラメーターは、接続が閉じられる前に、ソース メッセージング サーバーとの開いている SMTP 接続がアイドル状態を維持できる最大時間を指定します。 このパラメーターの値は、 ConnectionTimeout パラメーターの値より大きくする必要があります。
Set-ReceiveConnector の ConnectionTimeout メールボックス サーバー上のトランスポート サービスでの受信コネクタの場合、10 分 このパラメーターは、サーバーがデータを送信している場合でも、ソース メッセージング サーバーとの SMTP 接続を開いたままにできる最大時間を指定します。 このパラメーターの値は、ConnectionInactivityTimeout パラメーターの値より大きくなければなりません。
Set-SendConnector の ConnectionInactivityTimeOut 10 分 このパラメーターには、送信先のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。

シャドウ メッセージの保持方法

メッセージが正常に作成されてからも、シャドウの冗長性の作業は続きます。 プライマリ サーバーとシャドウ サーバーは、メッセージの進行状況を追跡するため、互いに通信し続ける必要があります。

プライマリ サーバーがメッセージを次のホップに正常に送信し、次のホップがメッセージ受信の肯定応答を行うと、プライマリ サーバーは配信完了としてメッセージの破棄状態を更新します。 破棄状態とは基本的に、監視対象メッセージの一覧を含むメッセージのことです。 正常に配信されたメッセージはシャドウ キューに保持する必要はなくなるため、プライマリ サーバーがメッセージを次のホップにまで正常に送信したことをシャドウ サーバーが認識すると、シャドウ サーバーはシャドウ キューからセーフティ ネットに、シャドウ メッセージを移動します。

シャドウ サーバーは、プライマリ サーバーを照会して、シャドウ キュー内のシャドウ メッセージの破棄状態を決定します。 シャドウ サーバーがなんらかの理由でプライマリ サーバーとの SMTP セッション (その他の無関係メッセージの送信を含む) を開くと、シャドウ サーバーは XQDISCARD コマンドを発行して、プライマリ メッセージの破棄状態を判断します。 それ以外の場合、シャドウ サーバーは事前構成された時間間隔 (Set-TransportConfig コマンドレットの ShadowHeartbeatFrequency パラメーター、既定値は 2 分) の後にプライマリ サーバーとの SMTP セッションを自動的に開きます。

シャドウ サーバーがプライマリ サーバーとの SMTP セッションを開くと、プライマリ サーバーは照会を行ったシャドウ サーバーに適用されるメッセージの破棄通知を応答します。 破棄通知はディスクに保存されるので (メモリではない)、Microsoft Exchange トランスポート サービスが再起動しても破棄通知は保持されます。 サービスが起動すると、プライマリ サーバーは正常に処理したメッセージを把握しているため、その情報はシャドウ サーバーにも通知されます。

シャドウ サーバーとプライマリ サーバーの間の SMTP 通信は、サーバーの可用性を決定する ハートビート として使用されます。 シャドウ サーバーが事前構成された時間間隔 (Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーター、既定値は 3 時間) の後にプライマリ サーバーとの SMTP セッションを開くことができない場合、シャドウ サーバーはプライマリ サーバーとして自身を昇格し、シャドウ メッセージをプライマリ メッセージとして昇格させ、メッセージを次ホップに送信します。 ただし、シャドウ サーバーがプライマリ サーバーのキュー データベース ID が変更されたことを検出するたびに、シャドウ サーバーは自身をプライマリ サーバーとして昇格させ、シャドウ メッセージをプライマリ メッセージとして昇格させ、メッセージを次ホップに送信します。 これは 、ShadowResubmitTimeSpan パラメーター値が渡される前によく発生する可能性があります。

シャドウ冗長マネージャーは、シャドウ冗長を管理する メールボックス サーバーのコア コンポーネントです。 シャドウ冗長マネージャーによって、サーバーが現在処理中であるすべてのプライマリ メッセージの、以下の情報が保持されます。

  • 各プライマリ メッセージを処理中のシャドウ サーバー。

  • シャドウ サーバーに送信される破棄状態。

シャドウ冗長マネージャーは、シャドウ サーバーがシャドウ キューに保持するすべてのシャドウ メッセージに対し、以下の操作を実行します。

  • シャドウ メッセージごとのプライマリ サーバーの一覧の維持。

  • 元のデータベース ID と、メッセージのプライマリ コピーが格納されているキュー データベースの現在の ID の比較。

  • キューにシャドウ メッセージを持っている各プライマリ サーバーの可用性の確認。

  • プライマリ サーバーからの通知の破棄処理。

  • 適切な破棄通知すべてを受信した後に、シャドウ キューからシャドウ メッセージを削除。

  • シャドウ サーバーがシャドウ メッセージの所有権を引き継いでプライマリ サーバーになる時期の決定。

  • メッセージ分岐の追跡と、配信状態通知 (DSN、配信不能レポート、またはバウンス メッセージとも呼ばれる) およびジャーナル レポートなどのその他の副次的メッセージの追跡。これにより、メッセージのすべてのフォークが完全に処理されるまで、メッセージの冗長コピーが解放されないことを確認します。

次の表で、シャドウ メッセージの保持方法を制御するパラメーターを説明します。

パラメーター 既定値 説明
Set-TransportConfig の ShadowHeartbeatFrequency 2 分 シャドウ サーバーが、メッセージの破棄状態をチェックするのにプライマリ サーバーへの SMTP 接続を開くまでに待機する最長時間。
Set-TransportConfig の ShadowResubmitTimeSpan 3 時間 サーバーがプライマリ サーバーで障害が発生したと判断するまでの待ち時間。この時間が経過すると、サーバーは、シャドウ キューにある、到達不可能なプライマリ サーバーのためのシャドウ メッセージの所有権を引き継ぎます。

プライマリ サーバーのキュー データベースが別のデータベース ID を持つと分かった場合、このパラメーターの値の前に、シャドウ サーバーは自身をプライマリ サーバーとして昇格することもできることに注意してください。
Set-TransportConfig の ShadowMessageAutoDiscardInterval 2 日 サーバーが、正常に配信されたメッセージの破棄イベントを保持する期間。 プライマリ サーバーは、シャドウ サーバーがクエリを実行するまで破棄イベントをキューに保持します。 ただし、パラメーターで指定した期間内にプライマリ サーバーに対してシャドウ サーバーがクエリを実行しない場合は、プライマリ サーバーは、キューにある破棄イベントを削除します。
Set-TransportConfig の SafetyNetHoldTime 2 日 正常に処理されたメッセージがセーフティ ネットで保持される期間。 未確認のシャドウ メッセージは、Set-TransportService コマンドレットの SafetyNetHoldTime パラメーターと MessageExpirationTimeout パラメーター値の合計の後に、最終的に Safety Net から期限切れになります。
Set-TransportService の MessageExpirationTimeout 2 日 期限前にメッセージがキューに残る時間。

停止後のメッセージの処理

次の表は、シャドウ冗長がどのようにメッセージの損失を最小限に抑えるかをまとめています。 分かりやすくするため、停止したサーバーの名前を Mailbox01 とします。

回復のシナリオ 実行された処理
ShadowResubmitTimeSpan パラメーターの値 (既定では 3 時間) が経過する前に、Mailbox01 は新しいキュー データベースでオンラインに復帰します。

このシナリオは、データの破損またはハードウェアの故障によりキュー データベースが回復不可能な場合に発生します。

 新しいキュー データベース ID がMailbox01 で検出されると、Mailbox01 のシャドウ メッセージをキューに持つ各サーバーは、それらのメッセージの所有権を引き継ぎ、メッセージを再送信します。 メッセージは送信先に配信されます。

新しいキュー データベースが検出された後のメッセージ送信の最大遅延は、 ShadowHeartbeatFrequency パラメーターの値 (既定では 2 分) です。
Mailbox01 は、 ShadowResubmitTimeSpan パラメーターの値が (既定では 3 時間) 経過した後、同じデータベースでオンラインに戻ります。

このシナリオは、ネットワーク カード障害の後、またはサーバー上の時間がかかる保守の後に発生することがあります。

 Mailbox01 がオンラインに戻ると、メールボックス 01 のメッセージのシャドウ コピーを保持するサーバーによって既に配信されているキューにメッセージが配信されます。 これにより、これらのメッセージが重複して配信されます。 Exchange メールボックス ユーザーには、重複メッセージ検出のために重複メッセージが表示されません。 ただし、他のメッセージング システムの受信者には、メッセージの重複コピーが表示される場合があります。

メッセージ送信の最大遅延は、 ShadowResubmitTimeSpan パラメーターの値です。