シャドウ冗長Shadow redundancy

に適用されます: Exchange Server 2013Applies to: Exchange Server 2013

シャドウの冗長性は、メールボックスに配信している、前に、メッセージの冗長コピーを提供する、Microsoft Exchange Server 2010 で導入されました。Exchange 2010 トランスポート サーバー上のトランスポート データベースからメッセージを削除して、サーバーの確認メッセージの配信パスでは、次のホップまでシャドウの冗長性は遅延配信を完了しました。トランスポート サーバーに正常に配信される前に次のホップが失敗した場合、トランスポート サーバーには、その次ホップにメッセージが再送信されます。Exchange 2010 サーバーは、シャドウ冗長のサポートをアドバタイズするのには XSHADOW の動詞を使用します。SMTP サーバーは、シャドウ冗長をサポートしていませんでした、使用される Exchange 2010 は受信確認のメッセージの冗長コピーを作成する受信コネクタに構成された時間間隔に基づくを遅延します。Shadow redundancy was introduced in Microsoft Exchange Server 2010 to provide redundant copies of messages before they're delivered to mailboxes. In Exchange 2010, shadow redundancy delayed deleting a message from the transport database on a transport server until the server verified the next hop in the message delivery path completed delivery. If the next hop failed before reporting successful delivery back to the transport server, the transport server resubmitted the message to that next hop. Exchange 2010 servers used the XSHADOW verb to advertise their shadow redundancy support. If an SMTP server didn't support shadow redundancy, Exchange 2010 used delayed acknowledgement based on a configured time interval on the Receive connector to make a redundant copy of the message.

シャドウの冗長性では、Microsoft Exchange Server 2013 の主な改善は、トランスポート サーバーは、受信確認メッセージを送信側サーバーを正常に受信する前に受信したメッセージの冗長コピーを今すぐ、です。送信側サーバーのサポートまたはシャドウの冗長性のためのサポートの不足は関係ありません。これにより、転送中にいるときに Exchange 2013 トランスポート パイプライン内のすべてのメッセージが冗長化行われていることを確認します。Exchange 2013 は、元のメッセージが転送中に失われたと判断された場合、メッセージの冗長コピーを再送信します。The major improvement to shadow redundancy in Microsoft Exchange Server 2013 is that the transport server now makes a redundant copy of any messages it receives before it acknowledges successfully receiving the message back to the sending server. The sending server's support or lack of support for shadow redundancy doesn't matter. This helps to ensure that all messages in the Exchange 2013 transport pipeline are made redundant while they're in transit. If Exchange 2013 determines the original message was lost in transit, the redundant copy of the message is redelivered.

内容Contents

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

シャドウ冗長のための要件Requirements for shadow redundancy

シャドウ冗長は既定で有効Shadow redundancy is enabled by default

シャドウ メッセージの作成方法How shadow messages are created

SMTP のタイムアウトSMTP timeouts

シャドウ メッセージの保持方法How shadow messages are maintained

停止後のメッセージの処理Message processing after an outage

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

次の表で、シャドウの冗長性のコンポーネントを説明します。以下の用語は、このトピック全体で使用されます。The following table describes the components of shadow redundancy. These terms are used throughout the topic.

用語Term 説明Description

トランスポート サーバーTransport server

内のメッセージ キューには、メッセージのルーティングを担当する Exchange サーバーです。Exchange 2013 では、トランスポート サーバーは、メールボックス サーバー (メールボックス サーバーのトランスポート サービス)。An Exchange server that has message queues and is responsible for routing messages. In Exchange 2013, a transport server is a Mailbox server (the Transport service on the Mailbox server).

トランスポート データベースTransport database

2013 の Exchange トランスポート サーバーでメッセージ キュー データベースです。シャドウ キューとセーフティ ネットも、トランスポート データベースに格納されます。The message queue database on an Exchange 2013 transport server. Shadow queues and Safety Net are also stored in the transport database.

トランスポート高可用性境界Transport high availability boundary

データベース可用性グループ (DAG) 環境内の DAG、または非 DAG 環境内の Active Directory サイト。トランスポート高可用性境界内のトランスポート サーバーにメッセージが到着すると、Exchange は境界内のトランスポート サーバーで、メッセージの冗長コピー 2 部の保持を試みます。メッセージがトランスポート高可用性境界から送信されると、Exchange はメッセージの冗長コピーの保持を停止します。A database availability group (DAG) in DAG environments, or an Active Directory site in non-DAG environments. When a message arrives on a transport server in the transport high availability boundary, Exchange tries to maintain 2 redundant copies of the message on transport servers within the boundary. When a message leaves the transport high availability boundary, Exchange stops maintaining redundant copies of the message.

プライマリ メッセージPrimary message

配信用のトランスポート パイプラインに送信されるメッセージ。The message submitted into the transport pipeline for delivery.

シャドウ メッセージShadow message

プライマリ メッセージがプライマリ サーバーによって正常に処理されたことをシャドウ サーバーが確認するまで、シャドウ サーバーが保持するメッセージの情報コピー。The redundant copy of the message that the shadow server retains until it confirms the primary message was successfully processed by the primary server.

プライマリ サーバーPrimary server

プライマリ メッセージを処理しているトランスポート サーバー。The transport server that's currently processing the primary message.

シャドウ サーバーShadow server

プライマリ サーバーのシャドウ メッセージを保持するトランスポート サーバー。トランスポート サーバーは、あるメッセージではプライマリ サーバーに、およびその他のメッセージではシャドウ サーバーに同時になることがあります。The transport server that holds the shadow message for the primary server. A transport server may be the primary server for some messages and the shadow server for other messages simultaneously.

シャドウ キューShadow queue

シャドウ サーバーがシャドウ メッセージを格納する配信キュー。複数受信者が設定されたメッセージの場合、プライマリ メッセージのそれぞれの次のホップはそれぞれのシャドウ キューを必要とします。The delivery queue where the shadow server stores shadow messages. For messages with multiple recipients, each next hop for the primary message requires separate shadow queues.

破棄状態Discard status

トランスポート サーバーがシャドウ メッセージ用に保持する情報。プライマリ メッセージが正常に処理されたことを示します。The information a transport server maintains for shadow messages that indicate the primary message has been successfully processed.

破棄通知Discard notification

シャドウ サーバーがプライマリ サーバーから受信する応答。シャドウ メッセージが破棄可能な状態であることを示します。The response a shadow server receives from a primary server indicating a shadow message is ready to be discarded.

セーフティ ネットSafety Net

Exchange 2013 トランスポートのバージョンを改善するごみ箱をあさる。正常に処理されず、またメールボックス サーバーのトランスポート サービスによって、メールボックスの受信者に配信されるメッセージは、セーフティ ネットに移動します。詳細については、セーフティ ネットを参照してください。The Exchange 2013 improved version of the transport dumpster. Messages that are successfully processed or delivered to a mailbox recipient by the Transport service on a Mailbox server are moved into Safety Net. For more information, see Safety Net.

シャドウ冗長マネージャーShadow Redundancy Manager

シャドウ冗長を管理するトランスポート コンポーネント。The transport component that manages shadow redundancy.

ハートビートHeartbeat

プライマリ サーバーとシャドウ サーバーが、互いの稼働状況を確認するためのプロセス。The process that allows primary servers and shadow servers to verify the availability of each other.

ページのトップへReturn to top

シャドウ冗長のための要件Requirements for shadow redundancy

明らかに感じるかもしれませんが、シャドウの冗長性には、複数の Exchange 2013 メールボックス サーバーが必要です。メールボックス サーバーは、スタンドアロン サーバー、またはメールボックス サーバーとクライアント アクセス サーバーが同じコンピューターにインストールできます。Although it may seem obvious, shadow redundancy requires multiple Exchange 2013 Mailbox servers. The Mailbox server can be standalone servers, or Mailbox servers and Client Access servers installed on the same computer.

  • メールボックス サーバーが DAG のメンバーではない場合、その他のメールボックス サーバーがローカル Active Directory サイト内に存在する必要があります。If the Mailbox server isn't a member of a DAG, the other Mailbox servers must be in the local Active Directory site.

  • メールボックス サーバーが DAG のメンバーである場合、その他のメールボックス サーバーは同じ DAG に属す必要があります。DAG に属すその他のメールボックスは、ローカル Active Directory サイト、またはリモートの Active Directory サイトのいずれに存在してもかまいません。DAG が複数の Active Directory サイトにまたがる場合、シャドウの冗長性はサイトの回復性のため、リモート Active Directory サイトにメッセージの冗長コピーを作成しようとします。If the Mailbox server is a member of a DAG, the other Mailbox servers must belong to the same DAG. The other Mailbox servers that belong to the DAG can be in the local Active Directory site or in a remote Active Directory site. If the DAG spans multiple Active Directory sites, shadow redundancy prefers creating a redundant copy of the message in a remote Active Directory site for site resiliency.

シャドウの冗長性が送信中のメッセージを保護できない状況を以下に挙げます:These are the situations where shadow redundancy can't protect messages in transit:

  • 単一 Exchange サーバー環境内。In single Exchange server environments.

  • プロビジョニング不足の DAG 内。In under-provisioned DAGs.

  • メッセージのシャドウ冗長性に係わる 1 つまたは複数のトランスポート サーバーで同時に障害が発生しているとき。During the simultaneous failure of two or more transport servers involved in the shadow redundancy of a message.

ページのトップへReturn to top

シャドウ冗長は既定で有効Shadow redundancy is enabled by default

既定では、シャドウ冗長になってグローバルにすべてのメールボックス サーバーのトランスポート サービスにセット組織コマンドレットのShadowRedundancyEnabledパラメーターを使用しています。既定では、メールボックス サーバー上のトランスポート サービスは、メッセージの冗長コピーを作成できない場合は、メッセージを拒否することはできません。ただし、組織の一連のコマンドレットのRejectMessageOnShadowFailureパラメーターを使用してメッセージの冗長コピーが作成されていない場合にメッセージを拒否するのには、Exchange 2013 を構成できます。一時的な障害が発生、メッセージは拒否されますが、送信側サーバーがメッセージを再転送することができます。SMTP 応答コードは、451 4.4.0 Message failed to be made redundant.にできない冗長化された組織が利用できる複数の Exchange 2013 メールボックス サーバーを持つ場合にのみメッセージを拒否するのには、Exchange 2013 を構成する必要があります。By default, shadow redundancy is enabled globally in the Transport service on all Mailbox servers by using the ShadowRedundancyEnabled parameter on the Set-TransportConfig cmdlet. By default, if the Transport service on a Mailbox server can't create a redundant copy of a message, the message is not rejected. However, you can configure Exchange 2013 to reject a message if a redundant copy of the message isn't created by using the RejectMessageOnShadowFailure parameter on the Set-TransportConfig cmdlet. The message is rejected with a transient failure, but the sending server can transmit the message again. The SMTP response code is 451 4.4.0 Message failed to be made redundant. You should configure Exchange 2013 to reject messages that can't be made redundant only when your organization has multiple Exchange 2013 Mailbox servers available.

次の表で、シャドウの冗長性を有効にするパラメーターを説明します。The following table describes the parameters that enable shadow redundancy.

シャドウの冗長性を有効にするパラメーターParameters that enable shadow redundancy

パラメーターParameter 既定値Default value 説明Description

Set-TransportConfigShadowRedundancyEnabledShadowRedundancyEnabled on Set-TransportConfig

$true

  • $true有効では、組織内のすべてのトランスポート サーバーの冗長性をシャドウします。$true enables shadow redundancy on all transport servers in the organization.

  • $false無効には、組織内のすべてのトランスポート サーバーの冗長性をシャドウします。$false disables shadow redundancy on all transport servers in the organization.

Set-TransportConfigRejectMessageOnShadowFailureRejectMessageOnShadowFailure on Set-TransportConfig

$false

  • $falseメッセージのシャドウ コピーを作成することはできません、ときに、プライマリ メッセージは組織内のトランスポート サーバーで受け付けします。これらのメッセージはいない転送中にいるときに重複して永続化されます。$false When a shadow copy of the message can't be created, the primary message is accepted anyway by transport servers in the organization. Those messages aren't redundantly persisted while they're in transit.

  • $trueメッセージはありませんが承諾または、メッセージのシャドウ コピーが正常に作成されるまでに、組織内のすべてのトランスポート サーバーによって確認されます。メッセージのシャドウ コピーを作成することはできません、主メッセージは一時的なエラーで拒否されます。転送中にいるときに、組織内のすべてのメッセージが重複して永続化されます。$true No message is accepted or acknowledged by any transport server in the organization until a shadow copy of the message is successfully created. If a shadow copy of the message can't be created, the primary message is rejected with a transient error. All messages in the organization are redundantly persisted while they're in transit.

    この値を設定する必要があります$trueメッセージのシャドウ コピーを作成することができます、DAG または Active Directory サイトに複数の Exchange 2013 メールボックス サーバーがある場合にのみです。You should set this value to $true only if you have multiple Exchange 2013 Mailbox servers in a DAG or Active Directory site where a shadow copy of the message can be created.

このパラメーターは、 ShadowRedundancyEnabledの場合にのみ意味のある$trueThis parameter is only meaningful when ShadowRedundancyEnabled is $true.

ページのトップへReturn to top

シャドウ メッセージの作成方法How shadow messages are created

シャドウの冗長性の主要な目標は、メッセージが送信中であるときに、トランスポート高可用性境界内で、常にメッセージのコピーを 2 部保持することにあります。メッセージの冗長コピーが作成される場所とタイミングは、メッセージの送信元と送信先によって異なります。3 つの主要な決定要因があります:The main goal of shadow redundancy is to always have two copies of a message within a transport high availability boundary while the message is in transit. Where and when the redundant copy of the message is created depends on where the message came from and where the message is going. There are three major determining factors:

  • トランスポート高可用性境界の外部から受信したメッセージ。Messages received from outside a transport high availability boundary.

  • トランスポート高可用性境界の外部に送信されるメッセージ。Messages sent outside a transport high availability boundary.

  • トランスポート高可用性境界の内部にあるメールボックス サーバーの、メールボックス トランスポート発信サービスから受信したメッセージ。Messages received from the Mailbox Transport Submission service from a Mailbox server within the transport high availability boundary.

トランスポート高可用性境界とは、以下のいずれかの項目を指します:A transport high availability boundary is one of the following:

  • DAG (DAG のメンバーであるメールボックス サーバーの場合)。これには、複数の Active Directory サイトにまたがる DAG が含まれます。A DAG, for Mailbox servers that are members of a DAG. This includes a DAG that spans multiple Active Directory sites.

  • Active Directory サイト (DAG に属さないメールボックス サーバーの場合)。An Active Directory site, for Mailbox servers that don't belong to a DAG.

シャドウの冗長性は、トランスポートの高可用性の境界を越えて決してシャドウ メッセージを追跡します。メッセージは、トランスポートの高可用性の境界を越えている場合、シャドウの冗長性は開始または再起動します。これは、シャドウ メッセージ メンテナンス トラフィックが軽減されからトランスポートの高可用性の境界で発生しているメッセージの再送信をシャドウします。Exchange 2010 ハブ トランスポート サーバーは特殊なケースでは、このトピックで後述Shadow redundancy never tracks shadow messages across a transport high availability boundary. When a message crosses the transport high availability boundary, shadow redundancy begins or restarts. This reduces shadow message maintenance traffic and prevents shadow message resubmissions from occurring across the transport high availability boundary. Exchange 2010 Hub Transport servers are a special case, and are discussed later in this topic.

トランスポート高可用性境界の外部から受信したメッセージMessages received from outside a transport high availability boundary

Exchange 2013 メールボックス サーバー上のトランスポート サービスは、トランスポートの高可用性の境界の外側からメッセージを受信するメールボックス サーバーされていない送信元サーバーでサポートまたはシャドウの冗長性のためのサポートの欠如について関係しています。シャドウ冗長性を有効にする場合に限り、メッセージを受信するメールボックス サーバーでは、メッセージの冗長コピー トランスポートの高可用性の境界内の別のメールボックス サーバーで、送信するメッセージの受信を確認する前にサーバーです。プロセスのしくみの例を以下に示します。When the Transport service on an Exchange 2013 Mailbox server receives a message from outside the transport high availability boundary, the Mailbox server isn't concerned about the support or lack of support for shadow redundancy by the sending server. As long as shadow redundancy is enabled, the Mailbox server that receives the message makes a redundant copy of the message on another Mailbox server within the transport high availability boundary before acknowledging receipt of the message back to the sending server. Here's an example of how the process works:

シャドウ メッセージの作成Shadow message creation

  1. SMTP サーバーは、メールボックス サーバー上のトランスポート サービスにメッセージを送信します。メールボックス サーバーはプライマリ サーバーで、メッセージはプライマリ メッセージです。An SMTP server transmits a message to the Transport service on a Mailbox server. The Mailbox server is the primary server, and the message is the primary message.

  2. SMTP サーバーとの元の SMTP セッションがアクティブであれば、プライマリ サーバー上のトランスポート サービスは、組織内の異なるメールボックス サーバー上のトランスポート サービスとの新しい SMTP セッションを同時に開き、メッセージの冗長コピーを作成します。While the original SMTP session with the SMTP server is still active, the Transport service on primary server opens a new, simultaneous SMTP session with the Transport service on a different Mailbox server in the organization to create a redundant copy of the message.

    • プライマリ サーバーが DAG のメンバーである場合は、プライマリ サーバーは、同じ DAG 内の別のメールボックス サーバーに接続します。DAG は、複数の Active Directory サイトにまたがっている場合、既定で別の Active Directory サイト内のメールボックス サーバーが優先します。この設定は、設定 TransportServiceコマンドレットのShadowMessagePreferenceパラメーターによって制御されます。既定値は、PreferRemoteに変更することができますが、RemoteOnlyまたはLocalOnlyIf the primary server is a member of a DAG, the primary server connects to a different Mailbox server in the same DAG. If the DAG spans multiple Active Directory sites, a Mailbox server in a different Active Directory site is preferred by default. This setting is controlled by the ShadowMessagePreference parameter on the Set-TransportService cmdlet. The default value is PreferRemote, but you can change it to RemoteOnly or LocalOnly.

    • プライマリ サーバーが DAG のメンバーではない場合、ShadowMessagePreference パラメーターの値にかかわらず、プライマリ サーバーは同じ Active Directory サイト内の異なるメールボックス サーバーに接続します。If the primary server isn't a member of a DAG, the primary server connects to a different Mailbox server in the same Active Directory Site, regardless of the value of the ShadowMessagePreference parameter.

  3. プライマリ サーバーはその他のメールボックス サーバー上のトランスポート サービスにメッセージのコピーを送信し、そのメールボックス サーバー上のトランスポート サービスは、メッセージのコピーが正常に作成された旨の肯定応答を行います。メッセージのコピーはシャドウ メッセージであり、そのメッセージを保持するメールボックス サーバーは、プライマリ サーバーのシャドウ サーバーになります。メッセージは、シャドウ サーバー上のシャドウ キューに存在します。The primary server transmits a copy of the message to the Transport service on other Mailbox server, and Transport service on the other Mailbox server acknowledges that the copy of the message was created successfully. The copy of the message is the shadow message, and the Mailbox server that holds it is the shadow server for the primary server. The message exists in a shadow queue on the shadow server.

  4. プライマリ サーバーがシャドウ サーバーから肯定応答を受信すると、元の SMTP セッションの元の SMTP サーバーに対し、プライマリ メッセージを受信した旨の肯定応答を行い、その SMTP セッションは閉じられます。After the primary server receives acknowledgement from the shadow server, the primary server acknowledges the receipt of the primary message to the original SMTP server in the original SMTP session, and the SMTP session is closed.

トランスポート高可用性境界の外部に送信されるメッセージMessages sent outside a transport high availability boundary

Exchange 2013 のトランスポート サーバーは、トランスポートの高可用性の境界外へのメッセージを送信すると、相手側の SMTP サーバーに受信確認メッセージの受信に成功した、トランスポート サーバーは、セーフティ ネットにメッセージを移動します。トランスポートの高可用性の境界を越えて主メッセージが正常に送信された後のセーフティ ネットからのメッセージの再送信は行われません。セーフティ ネットの詳細については、セーフティ ネットを参照してください。When an Exchange 2013 transport server transmits a message outside the transport high availability boundary, and the SMTP server on the other side acknowledges successful receipt of the message, the transport server moves the message into Safety Net. No resubmission of the message from Safety Net can occur after the primary message has been successfully transmitted across the transport high availability boundary. For more information about Safety Net, see Safety Net.

トランスポート高可用性境界の内部で送信されるメッセージMessages transmitted within a transport high availability boundary

メッセージのルーティングは、DAG または Active Directory サイトの最終的な宛先がある場合、また、この DAG または Active Directory サイト内のメールボックス サーバーのトランスポート サービスとの間の複数のホップは通常必要でないように、Exchange 2013 で最適化されます。メッセージの最終的な宛先を保持している DAG または Active Directory サイト内のメールボックス サーバーのトランスポート サービスでメッセージを受信すると、メッセージの次ホップは通常自体最終的な宛先です。転送中のメッセージの 2 つのコピーを維持するシャドウの冗長性の目的は、DAG または Active Directory サイト内で任意の場所をメッセージの 1 つのシャドウ コピーが存在する場合に満たされます。通常、フェイル オーバーのシナリオのみ、DAG のメールボックス サーバー上のアクティブなキューをドレインするのには "リダイレクト"メッセージコマンドレットを必要とするには、同じトランスポートの高可用性の境界内の複数のホップを必要があります。Message routing is optimized in Exchange 2013 so that when the ultimate destination is in a DAG or Active Directory site, multiple hops between the Transport service on Mailbox servers in that DAG or Active Directory site aren't typically required. Once the message is accepted by the Transport service on a Mailbox server in the DAG or Active Directory site that holds the ultimate destination for the message, the next hop for the message is typically the ultimate destination itself. Shadow redundancy's goal of keeping two copies of a message in transit is fulfilled when one shadow copy of the message exists anywhere within the DAG or Active Directory site. Typically, only failover scenarios in a DAG that require the Redirect-Message cmdlet to drain the active queues on a Mailbox server would require multiple hops within the same transport high availability boundary.

同じ Active Directory サイト内の Exchange 2010 ハブ トランスポート サーバーによるシャドウ冗長Shadow redundancy with Exchange 2010 Hub Transport servers in the same Active Directory site

Exchange 2010 ハブ トランスポート サーバーが、XSHADOW コマンドでは、メールボックス サーバーを使用してシャドウ冗長性のためのサポートをアドバタイズする、Exchange 2010 ハブ トランスポート サーバーが同じ Active Directory サイト内の Exchange 2013 メールボックス サーバーにメッセージを送信するときシャドウの冗長性のためのサポートを提供しません。これは Exchange 2010 ハブ トランスポート サーバーが Exchange 2013 メールボックス サーバーで、メッセージのシャドウ コピーを作成することを防ぎます。When an Exchange 2010 Hub Transport server transmits a message to an Exchange 2013 Mailbox server in the same Active Directory site, the Exchange 2010 Hub Transport server advertises support for shadow redundancy using the XSHADOW command, but the Mailbox server doesn't advertise support for shadow redundancy. This prevents the Exchange 2010 Hub Transport server from creating a shadow copy of the message on an Exchange 2013 Mailbox server.

Exchange 2013 メールボックス サーバー上のトランスポート サービスは、同じ Active Directory サイト内の Exchange 2010 ハブ トランスポートにメッセージを送信、Exchange 2013 メールボックス サーバーは Exchange 2010 ハブ トランスポート サーバーのメッセージをシャドウします。メッセージが正常に受信する Exchange 2010 ハブ トランスポート サーバーから Exchange 2013 メールボックス サーバーが受信確認を受け取ると、Exchange 2013 メールボックス サーバーは、セーフティ ネットに正常に処理されたメッセージを移動します。ただし、セーフティ ネットから Exchange 2013 メールボックスが正常に処理されたメッセージは Exchange 2010 ハブ トランスポート サーバーに再送信しません。When the Transport service on an Exchange 2013 Mailbox server transmits a message to an Exchange 2010 Hub Transport in the same Active Directory site, the Exchange 2013 Mailbox server shadows the message for the Exchange 2010 Hub Transport server. After the Exchange 2013 Mailbox server receives acknowledgement from the Exchange 2010 Hub Transport server that the message was successfully received, the Exchange 2013 Mailbox server moves the successfully processed message into Safety Net. However, the successfully processed messages stored in Safety Net by Exchange 2013 Mailbox are never resubmitted to the Exchange 2010 Hub Transport servers.

ページのトップへReturn to top

SMTP のタイムアウトSMTP timeouts

メッセージの冗長コピーの作成を試行している間、送信 SMTP サーバーとプライマリ サーバー間の SMTP 接続、またはプライマリ サーバーとシャドウ サーバー間の SMTP セッションはタイムアウトすることがあります。受信コネクタと送信コネクタの両方に、データがコネクタで実際に送信されるまでの時間のための ConnectionInactivityTimeOut パラメーターがあります。受信コネクタには、絶対 ConnectionTimeOut パラメーターもあります。During the attempt to make a redundant copy of the message, the SMTP connection between the sending SMTP server and the primary server, or the SMTP session between the primary server and the shadow server could timeout. Receive connectors and Send connectors both have a ConnectionInactivityTimeOut parameter for when data is actually being transmitted on the connector. Receive connectors also have an absolute ConnectionTimeOut parameter.

作成されていて、受信確認メッセージのシャドウ コピーする前に SMTP セッションのタイムアウトのいずれかが正常に、結果は、組織の一連のコマンドレットのRejectMessageOnShadowFailureパラメーターで制御されます。このパラメーターの値は、既定では、 $false、シャドウ コピーが作成されることがなく受け入れられる主なメッセージを意味します。このパラメーターの値がの場合$true主メッセージは拒否され、一時的なエラー 451 4.4.0If any of the SMTP sessions time out before the shadow copy of the message is successfully created and acknowledged, the result is controlled by the RejectMessageOnShadowFailure parameter on the Set-TransportConfig cmdlet. By default, the value of this parameter is $false, which means the primary message is accepted without a shadow copy being created. If the value of this parameter is $true the primary message is rejected with the transient error 451 4.4.0.

メッセージのシャドウ コピーが正常に作成された場合に、送信 SMTP サーバーとプライマリ サーバー間の SMTP セッションがタイムアウトすると、プライマリ サーバーはプライマリ メッセージを受け入れ、処理します。送信 SMTP サーバーは肯定応答されていないメッセージを再配信しますが、重複メッセージ検出機能により、Exchange メールボックス ユーザーが重複メッセージを受け取ることはありません。送信 SMTP サーバーがメッセージを再送信すると、プライマリ サーバーはメッセージのシャドウ コピーをもう 1 部作成します。送信 SMTP サーバーによるメッセージの再送信中に作成されたシャドウ メッセージ間に関係はありません。If the shadow copy of a message is successfully created, but the SMTP session between the sending SMTP server and the primary server times out, the primary server accepts and processes the primary message. The sending SMTP server will re-deliver the unacknowledged message, but duplicate message detection will prevent Exchange mailbox users from seeing the duplicate messages. When the sending SMTP server resubmits the message, the primary server will create another shadow copy of the message. There's no relationship between the shadow messages created during message resubmissions by the sending SMTP server.

次の表で、シャドウ メッセージの作成を制御するパラメーターを説明しますThe following table describes the parameters that control the creation of shadow messages

シャドウ メッセージ作成パラメーターShadow message creation parameters

ソースSource 既定値Default value 説明Description

Set-TransportConfigShadowMessagePreferenceSettingShadowMessagePreferenceSetting on Set-TransportConfig

PreferRemote

  • PreferRemote別の Active Directory サイト内のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとしてください。操作が失敗した場合は、ローカルの Active Directory サイト内のサーバーにメッセージのシャドウ コピーを作成してみてください。PreferRemote Try to make a shadow copy of the message on a Mailbox server in a different Active Directory site. If the operation fails, try make a shadow copy of the message on a server in the local Active Directory site.

  • LocalOnlyメッセージのシャドウ コピーは、トランスポート サーバーでローカルの Active Directory サイトにしか作成する必要があります。LocalOnly A shadow copy of the message should only be made on a transport server in the local Active Directory site.

  • RemoteOnly: メッセージのシャドウ コピーは、別の Active Directory サイト内のトランスポート サーバーでしか作成する必要があります。RemoteOnly: A shadow copy of the message should only be made on a transport server in a different Active Directory site.

このパラメーターは、メッセージのシャドウ コピーを作成しようとしているプライマリ サーバーが、複数の Active Directory サイトにまたがる DAG のメンバーであるメールボックス サーバーである場合にのみ、有効です。This parameter is only meaningful when the primary server that's trying to make a shadow copy of the message is a Mailbox server that's a member of a DAG that spans multiple Active Directory sites.

Set-TransportConfigMaxRetriesForRemoteSiteShadowMaxRetriesForRemoteSiteShadow on Set-TransportConfig

4 4

このパラメーターは、メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合にのみ、有効です。This parameter is used when the Mailbox server is a member of a DAG that spans multiple Active Directory sites.

  • ShadowMessagePreferenceSetting設定されている場合PreferRemoteによって指定された時間の数は、リモートの Active directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成するメールボックス サーバーは、まずMaxRetriesForRemoteSiteShadow。これが失敗した場合は、メールボックス サーバーは、 MaxRetriesForLocalSiteShadowで指定された回数まで、ローカルの Active Directory サイトに別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。If ShadowMessagePreferenceSetting is set to PreferRemote, first the Mailbox server tries to create a shadow copy of the message on another Mailbox server in a remote Active directory site up to the number of times specified by MaxRetriesForRemoteSiteShadow. If this fails, the Mailbox server tries to create a shadow copy of the message on a different Mailbox server in the local Active Directory site up to the number of times specified by MaxRetriesForLocalSiteShadow.

  • ShadowMessagePreferenceSetting設定されている場合RemoteOnlyMaxRetriesForRemoteSiteShadow によって指定された時間の数は、リモートの Active Directory サイト内のメールボックス サーバーにメッセージのシャドウ コピーを作成するだけしようとしたメールボックス サーバー.If ShadowMessagePreferenceSetting is set to RemoteOnly, the Mailbox server only tries to create a shadow copy of the message on a Mailbox server in a remote Active Directory site up to the number of times specified by MaxRetriesForRemoteSiteShadow.

  • The

メッセージのシャドウ コピーが正常に作成できない場合:When a shadow copy of the message can't be successfully created:

  • RejectMessageOnShadowFailureの場合$true、主メッセージは拒否され、一時的なエラーです。If RejectMessageOnShadowFailure is $true, the primary message is rejected with a transient error.

  • RejectMessageOnShadowFailureの場合$false、主メッセージを受け入れられるが、冗長的に永続化されていません。If RejectMessageOnShadowFailure is $false, the primary message is accepted anyway, but isn't redundantly persisted.

Set-TransportConfigMaxRetriesForLocalSiteShadowMaxRetriesForLocalSiteShadow on Set-TransportConfig

2 2

このパラメーターは、以下の状況で使用します:This parameter is used in the following circumstances:

  • メールボックス サーバーが複数の Active Directory サイトにまたがる DAG のメンバーである場合。If the Mailbox server is a member of a DAG that spans multiple Active Directory sites.

    1. ShadowMessagePreferenceSetting設定されている場合PreferRemoteによって指定された時間の数は、リモートの Active directory サイト内の別のメールボックス サーバーにメッセージのシャドウ コピーを作成するメールボックス サーバーは、まずMaxRetriesForRemoteSiteShadow。これが失敗した場合は、メールボックス サーバーは、 MaxRetriesForLocalSiteShadowで指定された回数まで、ローカルの Active Directory サイトに別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようとします。If ShadowMessagePreferenceSetting is set to PreferRemote, first the Mailbox server tries to create a shadow copy of the message on another Mailbox server in a remote Active directory site up to the number of times specified by MaxRetriesForRemoteSiteShadow. If this fails, the Mailbox server tries to create a shadow copy of the message on a different Mailbox server in the local Active Directory site up to the number of times specified by MaxRetriesForLocalSiteShadow.

    2. ShadowMessagePreferenceSetting設定されている場合LocalOnly、のみ、メールボックス サーバーは、で指定された回数まで、ローカルの Active Directory サイトに別のメールボックス サーバーにメッセージのシャドウ コピーを作成しようMaxRetriesForLocalSiteShadowIf ShadowMessagePreferenceSetting is set to LocalOnly, the Mailbox server only tries to create a shadow copy of the message on a different Mailbox server in the local Active Directory site up to the number of times specified by the MaxRetriesForLocalSiteShadow.

  • メールボックス サーバーが DAG のメンバーではない場合、またはメールボックス サーバーがある Active Directory サイトに含まれる DAG のメンバーである場合、メールボックス サーバーは、MaxRetriesForLocalSiteShadow によって指定されている回数まで、ローカル Active Directory サイトの別のメールボックス サーバーでメッセージのシャドウ コピーを作成しようとします。If the Mailbox server isn't a member of a DAG, or if the Mailbox server is a member of a DAG that's in one Active Directory site, the Mailbox server only tries to create a shadow copy of the message on a different Mailbox server in the local Active Directory site up to the number of times specified by MaxRetriesForLocalSiteShadow.

メッセージのシャドウ コピーが正常に作成できない場合:When a shadow copy of the message can't be successfully created:

  • RejectMessageOnShadowFailureの場合$true、主メッセージは拒否され、一時的なエラーです。If RejectMessageOnShadowFailure is $true, the primary message is rejected with a transient error.

  • RejectMessageOnShadowFailureの場合$false、主メッセージを受け入れられるが、冗長的に永続化されていません。If RejectMessageOnShadowFailure is $false, the primary message is accepted anyway, but isn't redundantly persisted.

Set-ReceiveConnectorConnectionInactivityTimeoutConnectionInactivityTimeout on Set-ReceiveConnector

メールボックス サーバー上のトランスポート サービスで 5 分5 minutes in the Transport service on Mailbox servers

クライアント アクセス サーバー上のフロント エンド トランスポート サービスで 5 分。5 minutes in the Front End Transport service on Client Access servers.

エッジ トランスポート サーバーで 1 分。1 minute on Edge Transport servers.

このパラメーターには、送信元のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。このパラメーターの値は、ConnectionTimeout パラメーターによって指定される値未満にする必要があります。This parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. The value of this parameter must be smaller than the value specified by the ConnectionTimeout parameter.

Set-ReceiveConnectorConnectionTimeoutConnectionTimeout on Set-ReceiveConnector

メールボックス サーバー上のトランスポート サービスで 10 分10 minutes in the Transport service on Mailbox servers

クライアント アクセス サーバー上のフロント エンド トランスポート サービスで 10 分。10 minutes in the Front End Transport service on Client Access servers.

エッジ トランスポート サーバーで 5 分。5 minutes on Edge Transport servers.

このパラメーターには、送信元のメッセージング サーバーとの SMTP 接続を開いておくことができる時間の上限を指定します。この制限は、送信元のメッセージング サーバーがデータを転送していても適用されます。このパラメーターの値は、ConnectionInactivityTimeout パラメーターによって指定される値より大きくする必要があります。This parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. The value of this parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter.

Set-SendConnectorConnectionInactivityTimeOutConnectionInactivityTimeOut on Set-SendConnector

10 分10 minutes

このパラメーターには、送信先のメッセージング サーバーとの SMTP 接続をアイドル状態のまま開いておくことができる時間の上限を指定します。この上限に達すると接続は閉じられます。This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed.

ページのトップへReturn to top

シャドウ メッセージの保持方法How shadow messages are maintained

メッセージが正常に作成されてからも、シャドウの冗長性の作業は続きます。プライマリ サーバーとシャドウ サーバーは、メッセージの進行状況を追跡するため、互いに通信し続ける必要があります。After a shadow message is successfully created, the work of shadow redundancy has only just begun. The primary server and the shadow server need to stay in contact with each other to track the progress of the message.

プライマリ サーバーがメッセージを次のホップに正常に送信し、次のホップがメッセージ受信の肯定応答を行うと、プライマリ サーバーは配信完了としてメッセージの破棄状態を更新します。破棄状態とは基本的に、監視対象メッセージの一覧を含むメッセージのことです。正常に配信されたメッセージはシャドウ キューに保持する必要はなくなるため、プライマリ サーバーがメッセージを次のホップにまで正常に送信したことをシャドウ サーバーが認識すると、シャドウ サーバーはシャドウ キューからセーフティ ネットに、シャドウ メッセージを移動します。When the primary server successfully transmits the message to the next hop, and the next hop acknowledges receipt of the message, the primary server updates the discard status of the message as delivery complete. The discard status is basically a message that contains of list of messages that are being monitored. A successfully delivered message doesn't need to be kept in a shadow queue, so once the shadow server knows the primary server has successfully transmitted the message to the next hop, the shadow server moves the shadow message from the shadow queue into Safety Net.

シャドウ サーバーは、プライマリ サーバーを照会することにより、シャドウ キューにシャドウ メッセージの破棄状態を決定します。シャドウ サーバーがプライマリ サーバーで、関連のない他のメッセージの送信を含め、何らかの理由で SMTP セッションを開いた場合、シャドウ サーバーは、プライマリ メッセージの破棄状態を確認するのにはXQDISCARDコマンドを発行します。シャドウ サーバーまだ開かれている場合、SMTP セッション プライマリ サーバーと構成済みの時間間隔の後、シャドウ サーバーがプライマリ サーバーに SMTP セッションを開くし、 XQDISCARDコマンドを発行します。時間間隔は、組織の一連のコマンドレットのShadowHeartbeatFrequentcyパラメーターによって制御されます。既定値は、2 分です。影後サーバーがプライマリ サーバーとの SMTP セッションを開きますプライマリ サーバーで応答の通知を破棄するシャドウ サーバーの照会に適用されるメッセージの。Exchange 2013、破棄の通知がディスクに保存、メモリではなく。そのため、Microsoft Exchange トランスポート サービスが再起動した場合、破棄の通知が永続化されます。サービスが開始されると、正常に処理されたメッセージのプライマリ サーバーがまだ知っているし、シャドウ サーバーにその情報があります。The shadow server determines the discard status of the shadow messages in its shadow queues by querying the primary server. If the shadow server opens an SMTP session with the primary server for any reason, including the transmission of other unrelated messages, the shadow server issues the XQDISCARD command to determine the discard status of the primary messages. If the shadow server hasn't opened an SMTP session with the primary server after a preconfigured time interval, the shadow server will open an SMTP session with the primary server and issue the XQDISCARD command. The time interval is controlled by the ShadowHeartbeatFrequentcy parameter on the Set-TransportConfig cmdlet. The default value is 2 minutes. After the shadow server opens an SMTP session with the primary server, the primary server responds with the discard notifications for messages that apply to the querying shadow server. In Exchange 2013, discard notifications are stored on disk, not in memory. Therefore, if the Microsoft Exchange Transport service restarts, the discard notifications are persisted. After the service starts, the primary server still knows about the messages it successfully processed, and that information is available to the shadow server.

シャドウ サーバーとプライマリ サーバー間の SMTP 通信は、ハートビートとして使用されます。これにより、サーバーの稼働状況を判断します。シャドウ サーバーが、事前構成された時間間隔を経過してもプライマリ サーバーとの SMTP セッションを開けない場合、またはプライマリ サーバーのトランスポート データベースに異なるデータベース ID が設定されている場合、シャドウ サーバーは自身をプライマリ サーバーに昇格し、シャドウ メッセージをプライマリ メッセージに昇格し、次のホップにメッセージを送信します。間隔は、Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーターによって制御されます。既定値は 3 時間です。The SMTP communication between the shadow server and the primary server is used as the heartbeat that determines the availability of the servers. If the shadow server can't open an SMTP session with the primary server after a preconfigured time interval, or if the transport database of the primary server has a different database ID, the shadow server promotes itself as the primary server, promotes the shadow messages as primary messages, and transmits the messages to the next hop. The time interval is controlled by the ShadowResubmitTimeSpan parameter on the Set-TransportConfig cmdlet. The default value is 3 hours.

シャドウ冗長マネージャーは、シャドウの冗長性を管理する責任者である Exchange 2013 のトランスポート サーバーのコア コンポーネントです。シャドウ冗長マネージャーは、サーバーが現在処理しているすべての主要なメッセージは、次の情報の管理を担当します。Shadow Redundancy Manager is the core component of an Exchange 2013 transport server that's responsible for managing shadow redundancy. Shadow Redundancy Manager is responsible for maintaining the following information for all the primary messages that a server is currently processing:

  • 各プライマリ メッセージを処理中のシャドウ サーバー。The shadow server for each primary message being processed.

  • シャドウ サーバーに送信される破棄状態。The discard status to be sent to shadow servers.

シャドウの冗長性マネージャーは、シャドウ サーバーがシャドウ キューに保持するすべてのシャドウ メッセージに対し、以下の操作を実行します:Shadow Redundancy Manager is responsible for the following for all the shadow messages that a shadow server has in its shadow queues:

  • シャドウ メッセージごとのプライマリ サーバーの一覧の維持。Maintaining the list of primary servers for each shadow message.

  • 元のデータベース ID と、メッセージのプライマリ コピーが格納されているキュー データベースの現在の ID の比較。Comparing the original database ID and the current database ID of the queue database where the primary copy of the message is stored.

  • キューにシャドウ メッセージを持っている各プライマリ サーバーの可用性の確認。Checking the availability of each primary server for which a shadow message is queued.

  • プライマリ サーバーからの通知の破棄処理。Processing discard notifications from primary servers.

  • 適切な破棄通知すべてを受信した後に、シャドウ キューからシャドウ メッセージを削除。Removing the shadow messages from the shadow queues after all expected discard notifications are received.

  • シャドウ サーバーがシャドウ メッセージの所有権を引き継いでプライマリ サーバーになる時期の決定。Deciding when the shadow server should take ownership of shadow messages, becoming a primary server.

  • メッセージの分岐、および配信状態通知 (DSN) およびジャーナル レポートなどのその他の副次的メッセージの追跡。これにより、メッセージのすべてのフォークが完全に処理されるまで、メッセージの冗長コピーが解放されないことを確認します。Tracking message bifurcations and other side-effect messages like delivery status notifications (DSNs) and journal reports to verify the redundant copy of the message isn't released until all forks of the message are fully processed.

次の表で、シャドウ メッセージの保持方法を制御するパラメーターを説明します。The following table describes the parameters that control how shadow messages are maintained.

パラメーターParameter 既定値Default value 説明Description

Set-TransportConfigShadowHeartbeatFrequencyShadowHeartbeatFrequency on Set-TransportConfig

2 分2 minutes

シャドウ サーバーが、メッセージの破棄状態をチェックするのにプライマリ サーバーへの SMTP 接続を開くまでに待機する最長時間。The maximum amount of time a shadow server waits before opening an SMTP connection to the primary server to check the discard status of messages.

Set-TransportConfigShadowResubmitTimeSpanShadowResubmitTimeSpan on Set-TransportConfig

3 時間3 hours

サーバーがプライマリ サーバーで障害が発生したと判断するまでの待ち時間。この時間が経過すると、サーバーは、シャドウ キューにある、到達不可能なプライマリ サーバーのためのシャドウ メッセージの所有権を引き継ぎます。How long a server waits before deciding that a primary server has failed and assumes ownership of shadow messages in the shadow queue for the primary server that's unreachable.

Set-TransportConfigShadowMessageAutoDiscardIntervalShadowMessageAutoDiscardInterval on Set-TransportConfig

2 日2 days

サーバーが、正常に配信されたメッセージの破棄イベントを保持する期間。プライマリ サーバーは、シャドウ サーバーがクエリを実行するまで破棄イベントをキューに保持します。ただし、パラメーターで指定した期間内にプライマリ サーバーに対してシャドウ サーバーがクエリを実行しない場合は、プライマリ サーバーは、キューにある破棄イベントを削除します。How long a server retains discard events for successfully delivered messages. A primary server queues discard events until queried by the shadow server. However, if the shadow server doesn't query the primary server for the duration specified in this parameter, the primary server deletes the queued discard events.

Set-TransportConfigSafetyNetHoldTimeSafetyNetHoldTime on Set-TransportConfig

2 日2 days

正常に処理されたメッセージがセーフティ ネットで保持される期間。肯定応答されていないシャドウ メッセージは、Set-TransportServiceSafetyNetHoldTimeMessageExpirationTimeout の合計時間が経過すると、セーフティ ネットから事実上失効します。How long successfully processed messages are retained in Safety Net. Unacknowledged shadow messages eventually expire from Safety Net after the sum of SafetyNetHoldTime and MessageExpirationTimeout on Set-TransportService.

Set-TransportServiceMessageExpirationTimeoutMessageExpirationTimeout on Set-TransportService

2 日2 days

期限前にメッセージがキューに残る時間。How long a message can remain in a queue before it expires.

ページのトップへReturn to top

停止後のメッセージの処理Message processing after an outage

シャドウの冗長サーバーの停止によるメッセージの損失を最小限に抑えることができます。トランスポート サーバーが停止後に再度オンラインになる場合として、次の 2 つのシナリオがあります。Shadow redundancy minimizes message loss due to server outages. When a transport server comes back online after an outage, there are two scenarios:

  • サーバーが新しいトランスポート データベースで再度オンラインになる   このシナリオでは、トランスポート データベースはデータの破損またはハードウェアのエラーが原因で回復不能となっています。この場合、トランスポート データベースは新しいデータベース ID を持つため、組織内の他のトランスポート サーバーはこれを新しいルートと認識します。これは、サーバーが回復できず、新しいサーバーが代わりにプロビジョニングされた場合にも適用されます。The server comes back online with a new transport database In this scenario, the transport database is unrecoverable due to data corruption or hardware failure. In this case, because the transport server will have a new database ID, it will be recognized as a new route by the other transport servers in the organization. This also applies to the situation where a server couldn't be recovered, and a new server was provisioned as a replacement.

  • サーバーが同じトランスポート データベースで再度オンラインになる   このシナリオでは、特定のトランスポート サーバーで障害は発生していないものの、長時間オフラインであったため、シャドウ サーバーがメッセージの所有権を引き継ぎ、メッセージを再送信します。たとえばネットワーク カードのエラーや、長時間のサーバー保守などが、このシナリオの原因となります。The server comes back online with the same transport database In this scenario, the particular transport server didn't fail, but was offline long enough for the shadow server to assume ownership of the messages and resubmit them. For example, a network card failure, or a long maintenance on the server would cause this scenario.

次の表に、シャドウの冗長性がこれらの 2 つのシナリオにどのように対応するのかをまとめます。分かりやすくするため、停止したサーバーの名前を Mailbox01 とします。The following table summarizes how shadow redundancy reacts to these two scenarios. For clarity, assume that the server that had an outage is named Mailbox01.

メッセージの回復のシナリオでの処理Message processing in recovery scenarios

回復のシナリオRecovery scenario 実行された処理Actions taken

Mailbox01 で新しいデータベースがオンラインに復帰する。Mailbox01 comes back online with a new database.

Mailbox01 が使用不可となると、Mailbox01 のシャドウ メッセージをキューに持つ各サーバーは、それらのメッセージの所有権を引き継ぎ、メッセージを再送信します。メッセージは送信先に配信されます。When Mailbox01 becomes unavailable, each server that has shadow messages queued for Mailbox01 will assume ownership of those messages and resubmit them. The messages then get delivered to their destinations.

メッセージの最大遅延は、Set-TransportConfig コマンドレットの ShadowHeartbeatFrequency パラメーターの値になります。この既定値は 2 分です。The maximum delay for messages is the value of the ShadowHeartbeatFrequency parameter on the Set-TransportConfig cmdlet. The default value is 2 minutes.

Mailbox01 で同じデータベースがオンラインに復帰する。Mailbox01 comes back online with the same database.

Mailbox01 がオンラインに復帰すると、Mailbox01 はキューにあるメッセージを配信します。しかし、このメッセージは Mailbox01 のメッセージのシャドウ コピーを保持するサーバーにより既に配信済みです。結果として、これらのメッセージは重複配信されることになります。重複メッセージ検出機能により、Exchange メールボックス ユーザーが重複メッセージを受け取ることはありません。ただし、Exchange 以外のメッセージング システム上の受信者は、メッセージの重複コピーを受け取ることがあります。After Mailbox01 comes back online, it will deliver the messages in its queues, which have already been delivered by the servers that hold shadow copies of messages for Mailbox01. This will result in duplicate delivery of these messages. Exchange mailbox users won't see duplicate messages due to duplicate message detection. However, recipients on non-Exchange messaging systems may receive duplicate copies of messages.

メッセージの最大遅延は、Set-TransportConfig コマンドレットの ShadowResubmitTimeSpan パラメーターの値になります。既定値は 3 時間です。The maximum delay for messages is the value of the ShadowResubmitTimeSpan parameter on the Set-TransportConfig cmdlet. The default value is 3 hours.

ページのトップへReturn to top