Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2010-06-07
The shadow redundancy feature in Microsoft Exchange Server 2010 provides redundancy for messages for the entire time they're in transit. The general message flow is explained in Understanding Shadow Redundancy. This topic explains in detail what happens for each specific message flow scenario that can involve Exchange.
Mail Flow Scenarios
The following figure shows each possible redundancy scenario in an Exchange organization and how message redundancy is achieved in each scenario. The shaded area shows where shadow redundancy is in effect. Exchange 2010 shadow redundancy prevents data loss while messages are in transit within the shaded area.
|Client Access servers are omitted from the figure for simplicity.|
As can be seen from the preceding figure, all mail flow paths possible in an Exchange organization fit into one of the following scenarios:
The following sections explain what happens for each mail flow scenario.
A. MAPI/Windows Mobile Client Submission
Message submissions from MAPI or Windows Mobile clients aren't redundant. After the message is successfully stored on the Mailbox server, Exchange high availability features can take effect and help prevent data loss. This scenario provides a complete picture of message flow, from beginning to end.
B. Mail Flow from Mailbox Server to Hub Transport Server
The following actions take place when an Exchange 2010 Mailbox server submits messages to an Exchange 2010 Hub Transport server.
|Exchange 2010 Mailbox servers can't communicate with transport servers running previous versions of Exchange. Therefore, this topic only discusses mail flow from an Exchange 2010 Mailbox server to an Exchange 2010 Hub Transport server.|
- The mail submission service notifies the Hub Transport server
that there is a new message.
- The Hub Transport server picks up the message from the Outbox
of the mailbox submitting the message and stores it in its
- If the message has recipients on Mailbox servers that are in
the same Active Directory site, the Hub Transport server delivers
the message to the destination mailboxes, following the steps
listed in scenario C. For all other recipients, the Hub Transport
server delivers the message to the next hop.
- After delivery to the next hop is complete, the Hub Transport
server notifies the Mailbox server that it has finished processing
the message and assumed ownership of the message. After this
notification, the message is deleted from the Outbox.
- If none of the other hops for the message support shadow
redundancy, the Hub Transport server deletes the message.
Otherwise, it converts the message to a shadow message by storing
it in the shadow queues for the hops to which it delivered the
C. Message Delivery from Hub Transport Server to Mailbox Server
The following actions take place when an Exchange 2010 Hub Transport server delivers messages to an Exchange 2010 Mailbox server.
|Exchange 2010 Hub Transport servers can't communicate with Mailbox servers running previous versions of Exchange. Therefore, this topic only discusses mail flow from an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server.|
- The Hub Transport server delivers the message to the
- After the message is delivered to all the destination
mailboxes, the Hub Transport server adds the message to the
- The Hub Transport server queues discard notifications to the
hop from which it has received the message. These discard
notifications are created when the hop queries the Hub Transport
- The previous hop deletes the corresponding shadow message.
D. Mail Flow between Exchange 2010 Transport Servers
The mail flow process is identical for all message exchanges between transport servers running Exchange 2010, whether it's between two Hub Transport servers or between a Hub Transport server and an Edge Transport server. The following actions take place when a message is transferred from one Exchange 2010 transport server to another. For clarity purposes, assume that the server that's sending the message is called Hub01 and the server that's receiving the message is called Edge01.
- Hub01 establishes an SMTP connection to Edge01.
- Edge01 advertises shadow redundancy support.
- Hub01 requests shadow redundancy in the SMTP session by issuing
an XSHADOW command. The process is similar to establishing
Transport Layer Security (TLS) on an SMTP session.
- For each message that Hub01 needs to send to Edge01:
- Hub01 transmits the message to Edge01.
- Edge01 marks the message as shadowed by Hub01.
- Hub01 marks Edge01 as the primary server and adds it to its
shadow queue for Edge01.
- Hub01 prepares discard notifications for the message to be sent
to the hop from which it received the message.
- Hub01 transmits the message to Edge01.
- Hub01 queries Edge01 for discard status of messages it has
previously submitted to Edge01.
- Edge01 sends all discard notifications that it has prepared for
Hub01. These could be for messages that are sent in the same SMTP
session or for those that were sent during previous SMTP
- Hub01 deletes all shadow messages for which Edge01 has sent a
E. Mail Flow from Exchange 2010 Transport Servers to Mail Servers That Don't Support Shadow Redundancy
Neither Exchange Server 2007 transport servers nor Exchange Server 2003 bridgehead servers support shadow redundancy. Therefore, if you have a coexistence scenario with previous versions of Exchange, Exchange 2010 redundancy features can guarantee message delivery only until the legacy Exchange hop, and not all the way to its destination. The same applies to the scenario where Exchange 2010 Edge Transport servers send messages to non-Exchange mail servers.
The following actions take place when an Exchange 2010 Hub Transport server sends a message to an Exchange transport server running a previous version of Exchange, or an Exchange 2010 Edge Transport server sends a message to a non-Exchange mail server. For clarity, assume that an Exchange 2010 Hub Transport server called Hub01 is sending a message to an older Exchange transport server called Legacy01.
- Hub01 establishes an SMTP connection to Legacy01.
- Legacy01 doesn't advertise shadow redundancy support.
- Because Legacy01 didn't advertise shadow redundancy, Hub01
doesn't initiate shadow redundancy on the SMTP session.
- Hub01 delivers the message to Legacy01.
- Hub01 deletes the message.
- Hub01 prepares discard notifications for the hop from which it
received the message.
F. Mail Flow from Mail Servers That Don't Support Shadow Redundancy to Exchange 2010 Transport Servers
There are four entry points to an Exchange organization where a mail server that doesn't support shadow redundancy may establish an SMTP connection to an Exchange 2010 transport server and send messages.
- An Exchange 2010 Unified Messaging (UM) server connecting to an
Exchange 2010 Hub Transport server.
- An Exchange transport server that's running Exchange 2007 or
Exchange 2003 connecting to an Exchange 2010 Hub Transport
- A non-Exchange mail server on the Internet connecting to an
Exchange 2010 Edge Transport server.
- A non-Exchange mail server in the organization, such as a UNIX
server, or an SMTP client that's submitting messages to an Exchange
2010 Hub Transport server.
In this scenario, Exchange 2010 achieves shadow redundancy using a feature called delayed acknowledgement. When an Exchange 2010 transport server receives a message from a mail server that doesn't support shadow redundancy, it delays sending an acknowledgement to the sending mail server until it has confirmed that the message has been successfully delivered to its destination. For more information about delayed acknowledgement, see Understanding Shadow Redundancy.
To illustrate this scenario, assume that an Exchange 2010 Edge Transport server called Edge01 is receiving a message from a non-Exchange mail server on the Internet called Internet01. In this example, the following actions take place:
- Internet01 establishes an SMTP connection to Edge01.
- Edge01 advertises shadow redundancy support.
- Because Internet01 doesn't support shadow redundancy, it simply
sends the message to Edge01.
- Edge01 marks the message as a delayed acknowledgement
- Edge01 delivers the message to the next hops using the steps
outlined in scenario D.
- Edge01 queries the next hops for the discard status of the
- After Edge01 receives discard notifications from all of the
next hops, it sends the acknowledgement to Internet01.
- Edge01 deletes the message from its database.
Note: If Edge01 can't verify successful delivery of the message to all of the next hops within 30 seconds, it will time out and send an acknowledgement to Internet01. This time-out value is controlled by the value of the MaxAcknowledgementDelay attribute of the Receive connector.