Shadow-Redundanz in Exchange ServerShadow redundancy in Exchange Server

Die Funktion Shadow-Redundanz wurde in Exchange 2010 eingeführt, um redundante Kopien von Nachrichten bereitzustellen, bevor diese an Postfächer zugestellt werden. In Exchange 2010 führte die Shadow-Redundanz dazu, dass Nachrichten erst aus der Warteschlangendatenbank eines Hub-Transport-Servers gelöscht werden konnten, nachdem der Server festgestellt hatte, dass der nächste Hop auf dem Nachrichtenübermittlungspfad die Zustellung abgeschlossen hat. Kam es auf dem nächsten Hop zu einem Fehler, bevor er eine erfolgreiche Zustellung an den Hub-Transport-Server melden konnte, übermittelte der Server die Nachricht erneut an diesen Hop. Hub-Transport-Server unter Exchange 2010 verwendeten das Verb XSHADOW, um bekannt zu machen, dass sie Shadow-Redundanz unterstützen. Unterstützte ein Quellmessagingserver Shadow-Redundanz nicht, verzögerte Exchange 2010 die Bestätigung um ein auf dem Empfangsconnector konfiguriertes Zeitintervall, um eine redundante Kopie der Nachricht zu erstellen.Shadow redundancy was introduced in Exchange 2010 to provide redundant copies of messages before they're delivered to mailboxes. In Exchange 2010, shadow redundancy delayed deleting a message from the queue database on a Hub Transport server until the server verified that the next hop in the message delivery path had completed delivery. If the next hop failed before reporting successful delivery back to the Hub Transport server, the server resubmitted the message to that next hop. Exchange 2010 Hub Transport servers used the XSHADOW verb to advertise their shadow redundancy support. If a source messaging server didn't support shadow redundancy, Exchange 2010 used delayed acknowledgment based on a configured time interval on the Receive connector to make a redundant copy of the message.

Exchange 2016 und Exchange 2019 haben dieselben Verbesserungen wie bei der Shadow-Redundanz in Exchange 2013: der Transport Dienst auf einem Postfachserver erstellt jetzt eine redundante Kopie aller Nachrichten, die er erhält, bevor er den Empfang der Nachricht an den sendender Server.Exchange 2016 and Exchange 2019 have the same improvements that were made to shadow redundancy in Exchange 2013: the Transport service on a Mailbox server now makes a redundant copy of any message it receives before acknowledging the receipt of the message to the sending server. Das beibehalten redundanter Kopien von Nachrichten während der Übertragung ist mehr als ein optimaler Aufwand, der möglicherweise nicht funktioniert, da die Shadow-Redundanz nun nicht von den unterstützten Features des sendenden Servers abhängt (Unterstützung oder fehlende Unterstützung für Shadow-Redundanz spielt keine Rolle).Maintaining redundant copies of messages in transit is more than a best effort that may or may not work, because now shadow redundancy doesn't depend the sending server's supported features (support or lack of support for shadow redundancy doesn't matter). Dadurch wird sichergestellt, dass alle Nachrichten in der Transportpipeline während der Übertragung redundant ausgeführt werden.This helps to ensure that all messages in the transport pipeline are made redundant while they're in transit. Wenn Exchange feststellt, dass die ursprüngliche Nachricht während der Übertragung verloren ging, wird die redundante Kopie der Nachricht erneut zugestellt.If Exchange determines the original message was lost in transit, the redundant copy of the message is redelivered.

Weitere Informationen zu Transportfeatures für hohe Verfügbarkeit in Exchange Server finden Sie unter Transport High Availability in Exchange Server.For more information about transport high availability features in Exchange Server, see Transport high availability in Exchange Server. Weitere Informationen zur Nachrichten Redundanz, nachdem eine Nachricht erfolgreich zugestellt wurde, finden Sie unter Safety Net in Exchange Server.For more information about message redundancy after a message has been successfully delivered, see Safety Net in Exchange Server.

Komponenten der Funktion Shadow-RedundanzShadow redundancy components

In dieser Tabelle sind die Komponenten der Shadow-Redundanz-Funktion im Transportdienst auf Postfachservern aufgeführt. Alle diese Begriffe werden im weiteren Verlauf des Artikels verwendet.This table describes the components of shadow redundancy in the Transport service on Mailbox servers. These terms are used throughout the topic.

BegriffTerm BeschreibungDescription
Grenze für TransporthochverfügbarkeitTransport high availability boundary Hierbei handelt es sich um eine Database Availability Group (DAG) in DAG-Umgebungen bzw. einen Active Directory-Standort in Umgebungen ohne DAGs. Im Falle einer DAG, die sich über mehrere Active Directory-Standorte erstreckt, ist dennoch die DAG die Grenze (nicht der Standort).A database availability group (DAG) in DAG environments, or an Active Directory site in non-DAG environments. For DAGs that span multiple Active Directory sites, the DAG itself is still the boundary (not the site).

Geht eine Nachricht auf einem Postfachserver innerhalb der Grenze für Transporthochverfügbarkeit ein, versucht Exchange, zwei redundante Kopien der Nachricht auf Postfachservern innerhalb der Grenze vorzuhalten. Verlässt eine Nachricht die Grenze für Transporthochverfügbarkeit, stoppt Exchange die Shadow-Redundanz-Funktion.When a message arrives on a Mailbox server in the transport high availability boundary, Exchange tries to maintain two redundant copies of the message on Mailbox servers within the boundary. When a message leaves the transport high availability boundary, Exchange stops maintaining redundant copies of the message.
Primäre NachrichtPrimary message Die Nachricht, die zur Zustellung an die Transportpipeline übermittelt wird.The message submitted into the transport pipeline for delivery.
Shadow-NachrichtShadow message Die redundante Kopie der Nachricht, die der Shadow-Server beibehält, bis bestätigt wird, dass die primäre Nachricht erfolgreich durch den primären Server verarbeitet wurde.The redundant copy of the message that the shadow server retains until it confirms the primary message was successfully processed by the primary server.
Primärer ServerPrimary server Der Postfachserver, der die primäre Nachricht aktuell verarbeitetThe Mailbox server that's currently processing the primary message.
Shadow-ServerShadow server Der Postfachserver, der für den primären Server die Shadow-Nachricht vorhält. Ein Postfachserver kann gleichzeitig primärer Server für einige Nachrichten und Shadow-Server für andere Nachrichten sein.The Mailbox server that holds the shadow message for the primary server. A Mailbox server may be the primary server for some messages and the shadow server for other messages simultaneously.
Shadow-WarteschlangeShadow queue Die Zustellungswarteschlange, in der der Shadow-Server die Shadow-Nachrichten speichert. Bei Nachrichten mit mehreren Empfängern erfordert jeder nächste Hop für die primäre Nachricht eine separate Shadow-Warteschlange.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.
LöschstatusDiscard status Auf dem Postfachserver hinterlegte Information zu einer Shadow-Nachricht, die angibt, ob die primäre Nachricht erfolgreich verarbeitet wurdeThe information that the Mailbox server maintains for shadow messages to indicate the primary message has been successfully processed.
LöschbenachrichtigungDiscard notification Die von einem primären Server an einen Shadow-Server gesendete Antwort, dass eine Shadow-Nachricht gelöscht werden kann.The response a shadow server receives from a primary server indicating a shadow message is ready to be discarded.
SicherheitsnetzSafety Net Die verbesserte Version des Transportdumpsters in Exchange 2013 oder höher.The improved version of the transport dumpster in Exchange 2013 or later. Nachrichten, die vom Transportdienst auf einem Postfachserver erfolgreich verarbeitet oder einem Postfachempfänger zugestellt wurden, werden in das Sicherheitsnetz verschoben.Messages that are successfully processed or delivered to a mailbox recipient by the Transport service on a Mailbox server are moved into Safety Net. Weitere Informationen finden Sie unter Safety Net in Exchange Server.For more information, see Safety Net in Exchange Server.
Shadow-Redundanz-ManagerShadow Redundancy Manager Die Transportkomponente, die die Shadow-Redundanz verwaltet.The transport component that manages shadow redundancy.
TaktsignalHeartbeat Der Prozess, der es primären und Shadow-Servern ermöglicht, ihre gegenseitige Verfügbarkeit zu überprüfen.The process that allows primary servers and shadow servers to verify the availability of each other.

Anforderungen für die Funktion Shadow-RedundanzRequirements for shadow redundancy

Auch wenn es offensichtlich scheint, erfordert die Shadow-Redundanz mehrere Postfachserver:Although it may seem obvious, shadow redundancy requires multiple Mailbox servers:

  • Wenn der Postfachserver kein Mitglied einer DAG ist, müssen sich die anderen Postfachserver am lokalen Active Directory-Standort befinden.If the Mailbox server isn't a member of a DAG, the other Mailbox servers must be in the local Active Directory site.

  • Wenn der Postfachserver Mitglied einer DAG ist, müssen die anderen Postfachserver zu derselben DAG gehören. Die übrigen Mitglieder der DAG dürfen sich am lokalen Active Directory-Standort oder an einem Remotestandort befinden. Wenn sich die DAG über mehrere Active Directory-Standorte erstreckt, erstellt die Funktion Shadow-Redundanz die redundante Kopie der Nachricht aus Gründen der Standortausfallsicherheit standardmäßig bevorzugt an einem Remotestandort.If the Mailbox server is a member of a DAG, the other Mailbox servers must belong to the same DAG. The other DAG members can be in the local Active Directory site, or in a remote site. By default, if the DAG spans multiple Active Directory sites, shadow redundancy prefers creating a redundant copy of the message in a remote site for site resiliency.

In folgenden Situationen bietet Shadow-Redundanz keinen Schutz für Nachrichten während der Übermittlung:These are the situations where shadow redundancy can't protect messages in transit:

  • In Umgebungen mit lediglich einem einzigen Exchange-ServerIn single Exchange server environments.

  • In DAGs mit unzureichenden RessourcenIn under-provisioned DAGs.

  • Beim gleichzeitigen Ausfall von zwei oder mehr Postfachservern, die Shadow-Redundanz für eine Nachricht bereitstellenDuring the simultaneous failure of two or more Mailbox servers involved in the shadow redundancy of a message.

Shadow-Redundanz standardmäßig aktiviertShadow redundancy is enabled by default

Die Funktion Shadow-Redundanz ist standardmäßig global im Transportdienst jedes Postfachservers aktiviert. In der folgenden Tabelle sind die Parameter beschrieben, über die die Funktion Shadow-Redundanz aktiviert wird.By default, shadow redundancy is enabled globally in the Transport service on all Mailbox servers. This table describes the parameters that enable shadow redundancy.

ParameterParameter StandardwertDefault value BeschreibungDescription
ShadowRedundancyEnabled für Set-TransportConfigShadowRedundancyEnabled on Set-TransportConfig $true $true: Shadow-Redundanz ist auf allen Postfachservern in der Organisation aktiviert.$true: Shadow redundancy is enabled on all Mailbox servers in the organization.

$false: Shadow-Redundanz ist auf allen Postfachservern in der Organisation deaktiviert.$false: Shadow redundancy is disabled on all Mailbox servers in the organization.
RejectMessageOnShadowFailure für Set-TransportConfigRejectMessageOnShadowFailure on Set-TransportConfig $false $false: Wenn eine Shadow-Kopie der Nachricht nicht erstellt werden kann, wird die primäre Nachricht ohnehin von Postfachservern in der Organisation akzeptiert.$false: When a shadow copy of the message can't be created, the primary message is accepted anyway by Mailbox servers in the organization. Von der Nachricht wird dann während der Übermittlung keine redundante Kopie erstellt.These messages aren't redundantly persisted while they're in transit.

$true: Keine Nachricht wird von einem Postfachserver in der Organisation akzeptiert oder bestätigt, bis eine Shadow-Kopie der Nachricht erfolgreich erstellt wurde.$true: No message is accepted or acknowledged by any Mailbox server in the organization until a shadow copy of the message is successfully created. Der sendende Server kann die Nachricht jedoch erneut übermitteln.If a shadow copy of the message can't be created, the primary message is rejected with a transient error, but the sending server can transmit the message again. Der SMTP-Antwortcode 451 4.4.0 Message failed to be made redundantlautet.The SMTP response code is 451 4.4.0 Message failed to be made redundant. Von allen Nachrichten in der Organisation wird während der Übermittlung eine redundante Kopie vorgehalten.All messages in the organization are redundantly persisted while they're in transit.

Hinweis: verwenden $true Sie nur, wenn Sie über mehrere Postfachserver am gleichen DAG-oder Active Directory-Standort verfügen, damit eine Shadow-Kopie der Nachricht erstellt werden kann.Note: Use $true only if you have multiple Mailbox servers in the same DAG or Active Directory site so a shadow copy of the message can be created.

Dieser Parameter ist nur dann sinnvoll __ , wenn $trueShadowRedundancyEnabled ist.This parameter is only meaningful when ShadowRedundancyEnabled is $true.

Erstellen von Shadow-NachrichtenHow shadow messages are created

Der Hauptzweck von Shadow-Redundanz besteht darin, während der Übermittlung einer Nachricht zu jedem Zeitpunkt zwei Kopien der Nachricht innerhalb der Grenze für Transporthochverfügbarkeit vorzuhalten. Wo und wann die redundante Kopie der Nachricht erstellt wird, hängt vom Absender und vom Empfänger der Nachricht ab. Es gibt drei Nachrichtentypen, die jeweils bedingen, wie Shadow-Nachrichten erstellt werden: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 determining factors for creating shadow messages:

  • Nachrichten, die von Absendern außerhalb einer Grenze für Transporthochverfügbarkeit (DAG oder Active Directory-Standort [in Umgebungen ohne DAGs]) gesendet werdenMessages received from outside a transport high availability boundary (the DAG, or an Active Directory site in non-DAG environments).

  • Nachrichten, die an Empfänger außerhalb einer Transportgrenze für Hochverfügbarkeit gesendet werden.Messages sent outside a transport high availability boundary.

  • Nachrichten, die vom Dienst für die Postfachtransportübermittlung von einem Postfachserver innerhalb der Transportgrenze für Hochverfügbarkeit empfangen werden.Messages received from the Mailbox Transport Submission service from a Mailbox server within the transport high availability boundary.

Die Funktion Shadow-Redundanz verfolgt niemals Shadow-Nachrichten, die die Grenze für Transporthochverfügbarkeit verlassen. Sobald eine Nachricht die Grenze für Transporthochverfügbarkeit überschreitet, wird die Funktion Shadow-Redundanz angestoßen oder erneut gestartet. Dadurch wird einerseits der zum Vorhalten von Shadow-Nachrichten erforderliche Datenverkehr reduziert und andererseits eine erneute Übermittlung von Shadow-Nachrichten über die Grenze für Transporthochverfügbarkeit hinweg verhindert. Exchange 2010-basierte Hub-Transport-Server stellen einen Sonderfall dar und werden später in diesem Artikel behandelt.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 across the transport high availability boundary. Exchange 2010 Hub Transport servers are a special case, and are discussed later in this topic.

Nachrichten, die von Absendern außerhalb einer Grenze für Transporthochverfügbarkeit gesendet werdenMessages received from outside a transport high availability boundary

Wenn der Transportdienst auf einem Postfachserver eine Nachricht von einem Absender außerhalb der Grenze für Transporthochverfügbarkeit empfängt, spielt es für den Postfachserver keine Rolle, ob der sendende Server Shadow-Redundanz unterstützt oder nicht. Solange die Funktion Shadow-Redundanz aktiviert ist, erstellt der Postfachserver, der die Nachricht empfängt, eine redundante Kopie der Nachricht auf einem anderen Postfachserver innerhalb der Grenze für Transporthochverfügbarkeit und bestätigt dann dem sendenden Server den Empfang der Nachricht. Hier ein Beispiel für den Prozess:When the Transport service on a 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:

Erzeugen von Shadow-Nachrichten

  1. Ein Messagingserver übermittelt eine Nachricht an den Transportdienst auf einem Postfachserver. Der Postfachserver ist der primäre Server, die Nachricht ist die primäre Nachricht.A messaging 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. Noch während die ursprüngliche SMTP-Sitzung mit dem Messagingserver aktiv ist, öffnet der Transportdienst auf dem primären Server simultan eine neue SMTP-Sitzung mit dem Transportdienst auf einem anderen Postfachserver in der Organisation, um eine redundante Kopie der Nachricht zu erstellen.While the original SMTP session with the messaging 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.

    • Wenn der primäre Server Mitglied einer DAG ist, stellt der primäre Server eine Verbindung zu einem anderen Postfachserver in derselben Dag her.If the primary server is a member of a DAG, the primary server connects to a different Mailbox server in the same DAG. Wenn sich die DAG über mehrere Active Directory-Standorte erstreckt, wird standardmäßig ein Postfachserver an einem anderen Active Directory Standort bevorzugt (der Standardwert des Parameters shadowmessagepreferencesetting gesteuert für das PreferRemoteCmdlet "CmdletSet -TransportConfig " LocalOnlyist, Sie können ihn jedoch in RemoteOnly oder ändern).If the DAG spans multiple Active Directory sites, a Mailbox server in a different Active Directory site is preferred by default (the default value of the ShadowMessagePreferenceSetting parameter on the Set-TransportConfig cmdlet is PreferRemote, but you can change it to RemoteOnly or LocalOnly).

    • Wenn der primäre Server kein Mitglied einer DAG ist, stellt der primäre Server eine Verbindung mit einem anderen Postfachserver am selben Active Directory Standort (unabhängig vom Wert des shadowmessagepreferencesetting gesteuert -Parameters) her.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 ShadowMessagePreferenceSetting parameter).

  3. Der primäre Server übermittelt eine Kopie der Nachricht an den Transportdienst auf einem anderen Postfachserver. Dieser Transportdienst bestätigt die erfolgreiche Erstellung der Nachrichtenkopie. Die Kopie der Nachricht ist die Shadow-Nachricht. Der Postfachserver, auf dem sie gespeichert ist, ist der Shadow-Server für den primären Server. Die Nachricht befindet sich in einer Shadow-Warteschlange auf dem Shadow-Server.The primary server transmits a copy of the message to the Transport service on another 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. Sobald der primäre Server die Bestätigung vom Shadow-Server erhalten hat, bestätigt er dem ursprünglichen Messagingserver in der ursprünglichen SMTP-Sitzung den Erhalt der primären Nachricht, und die SMTP-Sitzung wird geschlossen.After the primary server receives acknowledgment from the shadow server, the primary server acknowledges the receipt of the primary message to the original messaging server in the original SMTP session, and the SMTP session is closed.

Nachrichten, die an Empfänger außerhalb einer Grenze für Transporthochverfügbarkeit gesendet werdenMessages sent outside a transport high availability boundary

Wenn ein Postfachserver eine Nachricht an einen Empfänger außerhalb der Grenze für Transporthochverfügbarkeit übermittelt und der Messagingserver auf der Gegenseite den Erhalt der Nachricht bestätigt, verschiebt der Postfachserver die Nachricht in das Sicherheitsnetz.When a Mailbox server transmits a message outside the transport high availability boundary, and the messaging server on the other side acknowledges successful receipt of the message, and the Mailbox server moves the message into Safety Net. Die Nachricht kann aus dem Sicherheitsnetz nicht erneut übermittelt werden, nachdem die primäre Nachricht erfolgreich über die Grenze für Transporthochverfügbarkeit hinweg übermittelt wurde.No resubmission of the message from Safety Net can occur after the primary message has been successfully transmitted across the transport high availability boundary. Weitere Informationen zu Sicherheitsnetzen finden Sie unter Safety Net in Exchange Server.For more information about Safety Net, see Safety Net in Exchange Server.

Nachrichten, die innerhalb einer Grenze für Transporthochverfügbarkeit übermittelt werdenMessages transmitted within a transport high availability boundary

Das Nachrichtenrouting ist so optimiert, dass beim Erreichen des endgültigen Ziels in einer DAG-oder Active Directory-Website in der Regel mehrere Hops zwischen Servern innerhalb der Ziel-DAG oder an einem Standort erforderlich sind.Message routing is optimized so that when the ultimate destination is in a DAG or Active Directory site, multiple hops between servers within the destination DAG or site aren't typically required. Nachdem die Nachricht vom Transport Dienst auf einem Postfachserver in der Ziel-DAG oder Active Directory akzeptiert wurde, ist der nächste Hop für die Nachricht in der Regel das ultimative Ziel selbst (beispielsweise der Postfachserver, der die aktive Kopie des Zielpostfach).After the message is accepted by the Transport service on a Mailbox server in the destination DAG or Active Directory, the next hop for the message is typically the ultimate destination itself (for example, the Mailbox server that holds the active copy of the destination mailbox). Das Ziel der Shadow-Redundanz, zwei Kopien einer Nachricht in Transit zu halten, wird erfüllt, wenn eine Shadow-Kopie der Nachricht an einer beliebigen Stelle innerhalb der DAG-oder Active Directory-Website vorhanden ist.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. Normalerweise erfordern nur Failover-Szenarien in einer DAG, bei denen das Redirect-Message- Cmdlet zum Ablassen der aktiven Nachrichtenwarteschlangen auf einem Postfachserver erforderlich ist, mehrere Hops innerhalb derselben Transport-hoch Verfügbarkeits Grenze.Typically, only failover scenarios in a DAG that require the Redirect-Message cmdlet to drain the active message queues on a Mailbox server would require multiple hops within the same transport high availability boundary.

Shadow-Redundanz mit Exchange 2010 Hub-Transport-Servern am gleichen Active Directory Standort in Exchange 2016-OrganisationenShadow redundancy with Exchange 2010 Hub Transport servers in the same Active Directory site in Exchange 2016 organizations

Wenn ein Exchange 2010-Hub-Transport-Server eine Nachricht an einen Exchange 2016-Postfachserver am gleichen Active Directory-Standort überträgt, kündigt der Exchange 2010-Hub-Transport-Server über den XSHADOW-Befehl Unterstützung für die Shadow-Redundanz an, der Postfachserver kündigt jedoch keine Unterstützung für die Shadow-Redundanz an. Dies verhindert, dass der Exchange 2010-Hub-Transport-Server eine Shadow-Kopie der Nachricht auf einem Exchange 2016-Postfachserver erstellt.When an Exchange 2010 Hub Transport server transmits a message to an Exchange 2016 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 2016 Mailbox server.

Wenn der Transportdienst auf einem Exchange 2016-Postfachserver eine Nachricht an einen Exchange 2010-basierten Hub-Transport-Server am selben Active Directory-Standort übermittelt, erstellt der Exchange 2016-Postfachserver eine Shadow-Kopie der Nachricht für den Exchange 2010-basierten Hub-Transport-Server. Nachdem der Exchange 2016-Postfachserver die Bestätigung über den Empfang der Nachricht vom Exchange 2010-basierten Hub-Transport-Server erhalten hat, verschiebt der Exchange 2016-Postfachserver die erfolgreich verarbeitete Nachricht in das Sicherheitsnetz. Die erfolgreich verarbeiteten Nachrichten, die vom Exchange 2016-Postfachserver im Sicherheitsnetz gespeichert werden, werden jedoch niemals erneut an den Exchange 2010-basierten Hub-Transport-Server übertragen.When the Transport service on an Exchange 2016 Mailbox server transmits a message to an Exchange 2010 Hub Transport in the same Active Directory site, the Exchange 2016 Mailbox server shadows the message for the Exchange 2010 Hub Transport server. After the Exchange 2016 Mailbox server receives acknowledgment from the Exchange 2010 Hub Transport server that the message was successfully received, the Exchange 2016 Mailbox server moves the successfully processed message into Safety Net. However, the successfully processed messages stored in Safety Net by Exchange 2016 Mailbox are never resubmitted to the Exchange 2010 Hub Transport servers.

SMTP-TimeoutsSMTP timeouts

Während des Versuchs, eine redundante Kopie einer Nachricht zu erstellen, könnte es bei der SMTP-Verbindung zwischen dem sendenden Server und dem primären Server oder zwischen dem primären Server und dem Shadow-Server zu einem Timeout kommen.During the attempt to make a redundant copy of the message, the SMTP connection between servers (the sending server and the primary server, or the primary server and the shadow server) could timeout. Empfangsconnectors und Sendeconnectors verfügen beide über einen ConnectionInactivityTimeout -Parameter, wenn Daten tatsächlich auf dem Connector übertragen werden.Receive connectors and Send connectors both have a ConnectionInactivityTimeOut parameter for when data is actually being transmitted on the connector. Empfangsconnectors haben auch einen absoluten ConnectionTimeout -Parameter.Receive connectors also have an absolute ConnectionTimeOut parameter.

Wenn ein Timeout einer SMTP-Sitzung vorliegt, bevor die Shadow-Kopie der Nachricht erfolgreich erstellt und bestätigt wird, wird das Ergebnis durch den Parameter RejectMessageOnShadowFailure im Cmdlet Set-TransportConfig gesteuert.If 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. Standardmäßig ist $falseder Wert dieses Parameters, was bedeutet, dass die primäre Nachricht akzeptiert wird, ohne dass eine Schattenkopie erstellt wird.By default, the value of this parameter is $false, which means the primary message is accepted without a shadow copy being created. Wenn der Wert dieses Parameters $true ist, wird die primäre Nachricht mit dem vorübergehenden Fehler 451 4.4.0zurückgewiesen.If the value of this parameter is $true the primary message is rejected with the transient error 451 4.4.0.

Wenn die Shadow-Kopie einer Nachricht erfolgreich erstellt wurde, aber ein Timeout in der SMTP-Sitzung zwischen dem sendenden Server und dem primären Server auftritt, nimmt der primäre Server die primäre Nachricht an und verarbeitet sie. Der sendende Server übermittelt die unbestätigte Nachricht erneut, die Funktion zur Erkennung von Nachrichtenduplikaten verhindert jedoch, dass den Benutzern von Exchange-Postfächern die Nachricht doppelt angezeigt wird. Wenn der sendende Server die Nachricht erneut übermittelt, erstellt der primäre Server eine weitere Shadow-Kopie der Nachricht. Es besteht keine Beziehung zwischen den Shadow-Nachrichten, die erstellt werden, wenn der sendende Server Nachrichten erneut übermittelt.If the shadow copy of a message is successfully created, but the SMTP session between the sending server and the primary server times out, the primary server accepts and processes the primary message. The sending server will re-deliver the unacknowledged message, but duplicate message detection will prevent Exchange mailbox users from seeing the duplicate messages. When the sending 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 server.

In der folgenden Tabelle werden die Parameter beschrieben, die die Erstellung von Shadow-Nachrichten steuern.The following table describes the parameters that control the creation of shadow messages

QuelleSource StandardwertDefault value BeschreibungDescription
ShadowMessagePreferenceSetting für Set-TransportConfigShadowMessagePreferenceSetting on Set-TransportConfig PreferRemote Dieser Parameter wird nur verwendet, wenn der primäre Server, der versucht, eine Shadow-Kopie der Nachricht zu erstellen, Mitglied einer DAG ist, die sich über mehrere Active Directory-Standorte erstreckt.This parameter is only used when the primary server that's trying to make a shadow copy of the message is a member of a DAG that spans multiple Active Directory sites.
PreferRemote: Versuchen Sie, eine Shadow-Kopie der Nachricht auf einem DAG-Mitglied in einer anderen Active Directory Website basierend auf der Anzahl der durch den MaxRetriesForRemoteSiteShadow -Parameter angegebenen Versuche zu erstellen.PreferRemote: Try to make a shadow copy of the message on a DAG member in a different Active Directory site based on the number of attempts specified by the MaxRetriesForRemoteSiteShadow parameter. Wenn der Vorgang fehlschlägt, erstellen Sie eine Shadow-Kopie der Nachricht auf einem DAG-Mitglied auf der lokalen Active Directory Website basierend auf der Anzahl der durch den MaxRetriesForLocalSiteShadow -Parameter angegebenen Versuche.If the operation fails, try make a shadow copy of the message on a DAG member in the local Active Directory site based on the number of attempts specified by the MaxRetriesForLocalSiteShadow parameter.
LocalOnly: Versuchen Sie, eine Shadow-Kopie der Nachricht nur auf einem DAG-Mitglied in der lokalen Active Directory Website basierend auf der Anzahl der durch den MaxRetriesForLocalSiteShadow -Parameter angegebenen Versuche zu erstellen.LocalOnly: Try to make a shadow copy of the message only on a DAG member in the local Active Directory site based on the number of attempts specified by the MaxRetriesForLocalSiteShadow parameter.
RemoteOnly: Versuchen Sie, die Shadow-Kopie der Nachricht nur auf einem DAG-Mitglied in einer anderen Active Directory Website basierend auf der Anzahl der durch den MaxRetriesForRemoteSiteShadow -Parameter angegebenen Versuche zu erstellen.RemoteOnly: Try to make shadow copy of the message only on a DAG member in a different Active Directory site based on the number of attempts specified by the MaxRetriesForRemoteSiteShadow parameter.
MaxRetriesForRemoteSiteShadow für Set-TransportConfigMaxRetriesForRemoteSiteShadow on Set-TransportConfig 44 Dieser Parameter gibt die maximale Anzahl von versuchen an, eine Shadow-Kopie der Nachricht auf einem anderen Server in der DAG zu erstellen, wenn __ der Wert des PreferRemote shadowmessagepreferencesetting gesteuert-Parameters ( RemoteOnlyder Standardwert) oder ist.This parameter specifies the maximum number of attempts to create a shadow copy of the message on another server in the DAG when the value of the ShadowMessagePreferenceSetting parameter is PreferRemote (the default value) or RemoteOnly.

Dieser Parameter wird nur verwendet, wenn der Postfachserver Mitglied einer sich über mehrere Active Directory-Standorte erstreckenden DAG ist.This parameter is only used when the Mailbox server is a member of a DAG that spans multiple Active Directory sites.

Wenn eine Shadow-Kopie der Nachricht nach der angegebenen Anzahl von versuchen nicht erfolgreich erstellt wurde, hängt das Ergebnis vom Wert des RejectMessageOnShadowFailure -Parameters ab:If a shadow copy of the message isn't successfully created after the specified number of attempts, the result depends of the value of the RejectMessageOnShadowFailure parameter:
$true: Die primäre Nachricht wird mit einem vorübergehenden Fehler zurückgewiesen.$true: The primary message is rejected with a transient error.
$false: Die primäre Nachricht wird trotzdem akzeptiert, wird aber nicht redundant gespeichert.$false: The primary message is accepted anyway, but isn't redundantly persisted.
MaxRetriesForLocalSiteShadow für Set-TransportConfigMaxRetriesForLocalSiteShadow on Set-TransportConfig 22 Dieser Parameter legt fest, wie oft höchstens versucht wird, eine Shadow-Kopie der Nachricht auf einem anderen Postfachserver am lokalen Active Directory-Standort zu erstellen, wenn:This parameter specifies the maximum number of attempts to create a shadow copy of the message on another Mailbox server in the local Active Directory site when:
• Der Postfachserver ist Mitglied einer DAG, die sich über mehrere Active Directory-Standorte erstreckt, und der __ Wert des shadowmessagepreferencesetting gesteuert PreferRemote -Parameters ist ( LocalOnlyder Standardwert) oder.• The Mailbox server is a member of a DAG that spans multiple Active Directory sites, and the value of the ShadowMessagePreferenceSetting parameter is PreferRemote (the default value) or LocalOnly.
• Der Postfachserver ist Mitglied einer DAG, die sich an einem Active Directory Standort befindet.• The Mailbox server is a member of a DAG that's in one Active Directory site.
• Der Postfachserver ist kein Mitglied einer DAG.• The Mailbox server isn't a member of a DAG.

Wenn eine Shadow-Kopie der Nachricht nach der angegebenen Anzahl von versuchen nicht erfolgreich erstellt wurde, hängt das Ergebnis vom Wert des RejectMessageOnShadowFailure -Parameters ab:If a shadow copy of the message isn't successfully created after the specified number of attempts, the result depends of the value of the RejectMessageOnShadowFailure parameter:
$true: Die primäre Nachricht wird mit einem vorübergehenden Fehler zurückgewiesen.$true: The primary message is rejected with a transient error.
$false: die primäre Nachricht wird trotzdem akzeptiert, wird aber nicht redundant gespeichert.ò $false: The primary message is accepted anyway, but isn't redundantly persisted.
ConnectionInactivityTimeout für Set-ReceiveConnectorConnectionInactivityTimeout on Set-ReceiveConnector 5 Minuten für Empfangsconnectors im Transportdienst auf Postfachservern5 minutes for Receive connectors in the Transport service on Mailbox servers Dieser Parameter legt fest, wie lange eine offene SMTP-Verbindung zum Quellmessagingserver höchstens im Leerlauf verbleiben darf, bevor sie beendet wird.This parameter specifies the maximum time that an open SMTP connection with the source messaging server can remain idle before the connection is closed. Der Wert dieses Parameters muss größer als der Wert des ConnectionTimeout -Parameters sein.The value of this parameter must be greater than the value of the ConnectionTimeout parameter.
ConnectionTimeout für Set-ReceiveConnectorConnectionTimeout on Set-ReceiveConnector 10 Minuten für Empfangsconnectors im Transportdienst auf Postfachservern10 minutes for Receive connectors in the Transport service on Mailbox servers Dieser Parameter legt fest, wie lange eine SMTP-Verbindung zum Quellmessagingserver maximal geöffnet bleiben darf, und greift auch, wenn der Server Daten übermittelt.This parameter specifies the maximum time that an SMTP connection with the source messaging server can remain open, even if the server is transmitting data. Der Wert dieses Parameters muss größer als der Wert des ConnectionInactivityTimeout -Parameters sein.The value of this parameter must be greater than the value of the ConnectionInactivityTimeout parameter.
ConnectionInactivityTimeOut für Set-SendConnectorConnectionInactivityTimeOut on Set-SendConnector 10 Minuten10 minutes Mit diesem Parameter wird die maximale Zeit angegeben, für die eine geöffnete SMTP-Verbindung zu einem Zielmessagingserver im Leerlauf bleiben kann, bis die Verbindung geschlossen wird.This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed.

Verwalten von Shadow-NachrichtenHow shadow messages are maintained

Nachdem eine Shadow-Nachricht erstellt wurde, müssen verschiedene weitere Aufgaben ausgeführt werden. Der primäre Server und der Shadow-Server müssen in Kontakt bleiben, um den Fortschritt der Nachricht nachzuverfolgen.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.

Wenn der primäre Server die Nachricht erfolgreich an den nächsten Hop übertragen hat und dieser Hop den Empfang der Nachricht bestätigt hat, aktualisiert der primäre Server den Löschstatus der Nachricht in "Übertragung abgeschlossen". Beim Löschstatus handelt es sich im Grunde um eine Nachricht, die eine Liste von Nachrichten enthält, die überwacht werden. Eine erfolgreich übermittelte Nachricht muss nicht in der Shadow-Warteschlange verbleiben. Sobald der Shadow-Server also die Bestätigung erhalten hat, dass der primäre Server die Nachricht erfolgreich an den nächsten Hop übertragen hat, verschiebt der Shadow-Server die Shadow-Nachricht aus der Shadow-Warteschlange in das Sicherheitsnetz.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.

Der Shadow-Server bestimmt den verwerfenstatus der Shadow-Nachrichten in seinen Schatten Warteschlangen, indem er den primären Server abfragt.The shadow server determines the discard status of the shadow messages in its shadow queues by querying the primary server. Wenn der Shadow-Server aus irgendeinem Grund eine SMTP-Sitzung mit dem primären Server öffnet (einschließlich der Übertragung anderer nicht verwandter Nachrichten), gibt der Shadow-Server den XQDISCARD -Befehl aus, um den verwerfenstatus der primären Nachrichten zu ermitteln.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. Andernfalls wird der Shadow-Server automatisch eine SMTP-Sitzung mit dem primären Server nach einem vorkonfigurierten Zeitintervall (dem Parameter ShadowHeartbeatFrequentcy im CmdletSet -TransportConfig ; der Standardwert ist 2 Minuten) geöffnet.Otherwise, the shadow server will automatically open an SMTP session with the primary server after a preconfigured time interval (the ShadowHeartbeatFrequentcy parameter on the Set-TransportConfig cmdlet; the default value is 2 minutes).

Nachdem der Shadow-Server eine SMTP-Sitzung mit dem primären Server geöffnet hat, antwortet der primäre Server mit den verwerfen-Benachrichtigungen für Nachrichten, die für den Abfrage Schatten Server gelten.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. Benachrichtigungen verwerfen werden auf dem Datenträger gespeichert (nicht im Arbeitsspeicher), wenn der Microsoft Exchange-Transport Dienst also neu gestartet wird, bleiben die verwerfen-Benachrichtigungen erhalten.Discard notifications are stored on disk (not in memory) so, if the Microsoft Exchange Transport service restarts, the discard notifications persist. Nachdem der Dienst gestartet wurde, kennt der primäre Server weiterhin die Nachrichten, die er erfolgreich verarbeitet hat, und diese Informationen stehen dem Shadow-Server zur Verfügung.After the service starts, the primary server still knows about the messages it successfully processed, and that information is available to the shadow server.

Die SMTP-Kommunikation zwischen dem Shadow-Server und dem primären Server wird als Heartbeat herangezogen, der die Verfügbarkeit der Server bestimmt.The SMTP communication between the shadow server and the primary server is used as the heartbeat that determines the availability of the servers. Wenn der Shadow-Server nach einem vorkonfigurierten Zeitintervall (festgelegt im Parameter ShadowResubmitTimeSpan im Cmdlet Set-TransportConfig; Standardwert = 3 Stunden) keine SMTP-Sitzung mit dem primären Server öffnen kann, stuft sich der Shadow-Server selbst zum primären Server herauf, stuft die Shadow-Nachrichten zu primären Nachrichten herauf und übermittelt die Nachrichten an den nächsten Hop.If the shadow server can't open an SMTP session with the primary server after a preconfigured time interval (the ShadowResubmitTimeSpan parameter on the Set-TransportConfig cmdlet; the default value is 3 hours) the shadow server promotes itself as the primary server, promotes the shadow messages as primary messages, and transmits the messages to the next hop. Auch wenn der Shadow-Server erkennt, dass sich die ID der Warteschlangendatenbank auf dem primären Server geändert hat, stuft er sich selbst zum primären Server herauf, stuft die Shadow-Nachrichten zu primären Nachrichten herauf und übermittelt die Nachrichten an den nächsten Hop.But, whenever the shadow server detects that the queue database ID of the primary server has changed, the shadow server also promotes itself as the primary server, promotes the shadow messages as primary messages, and transmits the messages to the next hop. Das kann deutlich vor dem Ablauf des im Parameter ShadowResubmitTimeSpan festgelegten Zeitintervalls eintreten.This could happen well before the ShadowResubmitTimeSpan parameter value has passed.

Der \*Shadow-Redundanz-Manager\* ist die wichtigste Komponente auf einem Postfachserver, der Shadow-Redundanz bereitstellt. Der Shadow-Redundanz-Manager speichert die folgenden Informationen zu allen primären Nachrichten, die ein Server aktuell verarbeitet:*Shadow Redundancy Manager* is the core component on a Mailbox 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:
  • Shadow-Server jeder primären Nachricht, die aktuell verarbeitet wirdThe shadow server for each primary message that's being processed.

  • Löschstatus, der an die Shadow-Server gesendet wirdThe discard status to be sent to shadow servers.

Der Shadow-Redundanz-Manager übernimmt für alle Shadow-Nachrichten, die ein Shadow-Server in seiner Shadow-Warteschlange vorhält, die folgenden Aufgaben:Shadow Redundancy Manager is responsible for the following actions for all the shadow messages that a shadow server has in its shadow queues:

  • Verwalten der Liste primärer Server für jede Shadow-Nachricht.Maintaining the list of primary servers for each shadow message.

  • Vergleichen der ursprünglichen Datenbank-ID mit der aktuellen Datenbank-ID für die Warteschlangendatenbank, in der primäre Kopie der Nachricht gespeichert ist.Comparing the original database ID and the current database ID of the queue database where the primary copy of the message is stored.

  • Überprüfen der Verfügbarkeit aller primären Server, für die sich eine Shadow-Nachricht in der Warteschlange befindet.Checking the availability of each primary server for which a shadow message is queued.

  • Verarbeiten von Löschbenachrichtigungen von primären Servern.Processing discard notifications from primary servers.

  • Entfernen der Shadow-Nachrichten aus den Shadow-Warteschlangen, nachdem alle erwarteten Löschbenachrichtigungen empfangen wurden.Removing the shadow messages from the shadow queues after all expected discard notifications are received.

  • Entscheidung darüber, ob der Shadow-Server den Besitz von Shadow-Nachrichten übernimmt und zu einem primären Server wird.Deciding when the shadow server should take ownership of shadow messages, becoming a primary server.

  • Nachverfolgen von Nachrichtengabelungen und sonstigen Nachrichten wie beispielsweise Benachrichtigungen über den Zustellungsstatus (auch DSNs [Delivery Status Notifications], Unzustellbarkeitsberichte, NDRs [Non-Delivery Reports] oder Unzustellbarkeitsnachrichten genannt) oder Journalberichten, um sicherzustellen, dass die redundante Nachrichtenkopie erst freigegeben wird, wenn alle Kopien der Nachricht vollständig verarbeitet wurdenTracking message bifurcations and other side-effect messages like delivery status notifications (also known as DSNs, non-delivery reports, NDRs, or bounce messages) and journal reports to verify that the redundant copy of the message isn't released until all forks of the message are fully processed.

In der folgenden Tabelle werden die Parameter beschrieben, die steuern, wie Shadow-Nachrichten vorgehalten werden.This table describes the parameters that control how shadow messages are maintained.

ParameterParameter StandardwertDefault value BeschreibungDescription
ShadowHeartbeatFrequency für Set-TransportConfigShadowHeartbeatFrequency on Set-TransportConfig 2 Minuten2 minutes Die maximale Zeitspanne, die ein Shadow-Server wartet, bevor er eine SMTP-Verbindung mit dem primären Server herstellt, um den Löschstatus von Nachrichten zu überprüfen.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.
ShadowResubmitTimeSpan für Set-TransportConfigShadowResubmitTimeSpan on Set-TransportConfig 3 Stunden3 hours Gibt an, wie lange ein Server wartet, bevor er entscheidet, dass beim primären Server ein Fehler aufgetreten ist, und den Besitz für die Shadow-Nachrichten in der Shadow-Warteschlange des nicht erreichbaren primären Servers übernimmt.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.

Beachten Sie: Ein Shadow-Server kann sich bereits vor Ablauf des in diesem Parameter definierten Zeitintervalls zum primären Server hochstufen, wenn er feststellt, dass sich die Datenbank-ID der Warteschlangendatenbank auf dem primären Server geändert hat.Note that a shadow server can also promote itself as the primary server before the value of this parameter when the queue database of the primary server is found to have a different database ID.
ShadowMessageAutoDiscardInterval für Set-TransportConfigShadowMessageAutoDiscardInterval on Set-TransportConfig 2 Tage2 days Gibt an, wie lange ein Server Löschereignisse für erfolgreich übermittelte Nachrichten aufbewahrt. Ein primärer Server stellt Löschereignisse so lange in die Warteschlange, bis er vom Shadow-Server abgefragt wird. Wenn der Shadow-Server den primären Server während des in diesem Parameter festgelegten Zeitraums nicht abfragt, löscht der primäre Server die Löschereignisse in der Warteschlange.How long a server retains discard events for successfully delivered messages. A primary server queues discard events until it's 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.
SafetyNetHoldTime für Set-TransportConfigSafetyNetHoldTime on Set-TransportConfig 2 Tage2 days Gibt an, wie lange erfolgreich verarbeitete Nachrichten im Sicherheitsnetz aufbewahrt werden.How long successfully processed messages are retained in Safety Net. Nicht bestätigte Shadow-Nachrichten laufen schließlich vom Sicherheitsnetz ab, nachdem die Summe der SafetyNetHoldTime -und MessageExpirationTimeOut -Parameterwerte im Cmdlet " Transportservice" festgelegt wurde .Unacknowledged shadow messages eventually expire from Safety Net after the sum of the SafetyNetHoldTime and MessageExpirationTimeout parameter values on the Set-TransportService cmdlet.
MessageExpirationTimeout für Set-TransportServiceMessageExpirationTimeout on Set-TransportService 2 Tage2 days Gibt an, wie lange eine Nachricht in einer Warteschlange verbleiben kann, bevor sie abläuft.How long a message can remain in a queue before it expires.

Nachrichtenverarbeitung nach einem AusfallMessage processing after an outage

In dieser Tabelle wird beschrieben, wie mittels Shadow-Redundanz der Nachrichtenverlust während Serverausfällen auf ein Minimum reduziert wird. Zum einfacheren Verständnis nennen wir den ausgefallenen Server „Mailbox01".This table summarizes how shadow redundancy minimizes message loss due to server outages. For clarity, the server that had an outage is named Mailbox01.

Szenario für die WiederherstellungRecovery scenario Durchgeführte AktionenActions taken
Bezeichnung Mailbox01 wird mit einer neuen Warteschlangendatenbank wieder online geschaltet, bevor der Wert des ShadowResubmitTimeSpan -Parameters übergeben wurde (standardmäßig 3 Stunden).Mailbox01 comes back online with a new queue database before the value of the ShadowResubmitTimeSpan parameter has passed (by default, 3 hours).

Dieses Szenario kann eintreten, wenn die Warteschlangendatenbank aufgrund von Datenbeschädigungen oder Hardwaredefekten nicht mehr wiederhergestellt werden kann.This scenario can occur when the queue database is unrecoverable due to data corruption or hardware failure.
Alle Server, die Shadow-Nachrichten für Mailbox01 in ihrer Warteschlange vorhalten, übernehmen die Verantwortung für diese Nachrichten, sobald sie erkennen, dass sich die ID der Warteschlangendatenbank auf Mailbox01 geändert hat. Anschließend übermitteln sie die Nachrichten erneut. Die Nachrichten werden dann an ihr jeweiliges Ziel zugestellt. When the new queue database ID is detected on Mailbox01, each server that has shadow messages queued for Mailbox01 will assume ownership of those messages and resubmit them. The messages are then delivered to their destinations.

Die maximale Verzögerung bei der Nachrichtenübermittlung nach dem Erkennen der neuen Warteschlangendatenbank ist der Wert des ShadowHeartbeatFrequency -Parameters (standardmäßig 2 Minuten).The maximum delay for message submission after the new queue database is detected is the value of the ShadowHeartbeatFrequency parameter (by default, 2 minutes).
Bezeichnung Mailbox01 wird mit derselben Datenbank wieder online geschaltet, nachdem der Wert des ShadowResubmitTimeSpan -Parameters übergeben wurde (standardmäßig 3 Stunden).Mailbox01 comes back online with the same database after the value of the ShadowResubmitTimeSpan parameter has passed (by default, 3 hours).

Dieses Szenario kann eintreten, wenn eine Netzwerkkarte ausfällt oder zeitaufwendige Wartungsarbeiten an einem Server erforderlich sind.This scenario can occur after a network card failure, or time-consuming maintenance on the server.
Sobald der Server Mailbox01 wieder online geschaltet wird, übermittelt er die Nachrichten in seinen Warteschlangen; diese Nachrichten wurden bereits von den Servern übermittelt, die für Mailbox01 die Schattenkopien der Nachrichten vorgehalten haben. Dadurch werden diese Nachrichten doppelt zugestellt. Empfänger mit Exchange-Postfach werden die doppelten Nachrichten dank der Funktion zur Erkennung von Nachrichtenduplikaten nicht sehen. Empfänger, die andere Messaging-Systeme benutzen, sehen die Duplikate der Nachrichten jedoch möglicherweise.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 other messaging systems might see duplicate copies of messages.

Die maximale Verzögerung bei der Nachrichtenübermittlung ist der Wert des ShadowResubmitTimeSpan -Parameters.The maximum delay for message submission is the value of the ShadowResubmitTimeSpan parameter.