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.

Note:
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:

A. MAPI/Windows Mobile Client Submission

B. Mail Flow from Mailbox Server to Hub Transport Server

C. Message Delivery from Hub Transport Server to Mailbox Server

D. Mail Flow Between Exchange 2010 Transport Servers

E. Mail Flow from Exchange 2010 Transport Servers to Mail Servers That Don't Support Shadow Redundancy

F. Mail Flow from Mail Servers That Don't Support Shadow Redundancy to Exchange 2010 Transport Servers

The following sections explain what happens for each mail flow scenario.

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.

Return to the list of mail flow scenarios

The following actions take place when an Exchange 2010 Mailbox server submits messages to an Exchange 2010 Hub Transport server.

Important:
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.

1. The mail submission service notifies the Hub Transport server that there is a new message.
   
   
2. The Hub Transport server picks up the message from the Outbox of the mailbox submitting the message and stores it in its database.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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 message.
   
   

Return to the list of mail flow scenarios

The following actions take place when an Exchange 2010 Hub Transport server delivers messages to an Exchange 2010 Mailbox server.

Important:
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.

1. The Hub Transport server delivers the message to the destination mailboxes.
   
   
2. After the message is delivered to all the destination mailboxes, the Hub Transport server adds the message to the transport dumpster.
   
   
3. 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 server.
   
   
4. The previous hop deletes the corresponding shadow message.
   
   

Return to the list of mail flow scenarios

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.

1. Hub01 establishes an SMTP connection to Edge01.
   
   
2. Edge01 advertises shadow redundancy support.
   
   
3. 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.
   
   
4. For each message that Hub01 needs to send to Edge01:
   
   
   1. Hub01 transmits the message to Edge01.
      
      
   2. Edge01 marks the message as shadowed by Hub01.
      
      
   3. Hub01 marks Edge01 as the primary server and adds it to its shadow queue for Edge01.
      
      
   4. Hub01 prepares discard notifications for the message to be sent to the hop from which it received the message.
      
      
5. Hub01 queries Edge01 for discard status of messages it has previously submitted to Edge01.
   
   
6. 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 sessions.
   
   
7. Hub01 deletes all shadow messages for which Edge01 has sent a discard notification.
   
   

Return to the list of mail flow scenarios

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.

1. Hub01 establishes an SMTP connection to Legacy01.
   
   
2. Legacy01 doesn't advertise shadow redundancy support.
   
   
3. Because Legacy01 didn't advertise shadow redundancy, Hub01 doesn't initiate shadow redundancy on the SMTP session.
   
   
4. Hub01 delivers the message to Legacy01.
   
   
5. Hub01 deletes the message.
   
   
6. Hub01 prepares discard notifications for the hop from which it received the message.
   
   

Return to the list of mail flow scenarios

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 server.
  
  
• 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:

1. Internet01 establishes an SMTP connection to Edge01.
   
   
2. Edge01 advertises shadow redundancy support.
   
   
3. Because Internet01 doesn't support shadow redundancy, it simply sends the message to Edge01.
   
   
4. Edge01 marks the message as a delayed acknowledgement message.
   
   
5. Edge01 delivers the message to the next hops using the steps outlined in scenario D.
   
   
6. Edge01 queries the next hops for the discard status of the message.
   
   
7. After Edge01 receives discard notifications from all of the next hops, it sends the acknowledgement to Internet01.
   
   
8. 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.

Return to the list of mail flow scenarios