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.
Exchange Server 2010 Shadow Redundancy
Download: https://tlniurl.com/2vzB4Q
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.
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.
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.
This parameter is only meaningful when ShadowRedundancyEnabled is $true.How shadow messages are createdThe 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:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.MaxRetriesForRemoteSiteShadow on Set-TransportConfig4This parameter is used when the Mailbox server is a member of a DAG that spans multiple Active Directory sites. 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.
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: If RejectMessageOnShadowFailure is $true, the primary message is rejected with a transient error.
If RejectMessageOnShadowFailure is $false, the primary message is accepted anyway, but isn't redundantly persisted.
MaxRetriesForLocalSiteShadow on Set-TransportConfig2This parameter is used in the following circumstances: If the Mailbox server is a member of a DAG that spans multiple Active Directory sites. 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.
If 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.
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: If RejectMessageOnShadowFailure is $true, the primary message is rejected with a transient error.
If RejectMessageOnShadowFailure is $false, the primary message is accepted anyway, but isn't redundantly persisted.
ConnectionInactivityTimeout on Set-ReceiveConnector5 minutes in the Transport service on Mailbox servers 5 minutes in the Front End Transport service on Client Access servers. 1 minute on Edge Transport servers.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.ConnectionTimeout on Set-ReceiveConnector10 minutes in the Transport service on Mailbox servers 10 minutes in the Front End Transport service on Client Access servers. 5 minutes on Edge Transport servers.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.ConnectionInactivityTimeOut on Set-SendConnector10 minutesThis parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed.How shadow messages are maintainedAfter 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. 2ff7e9595c
Comments