If a message travels through multiple servers that support shadow redundancy, the shadow messages are retained on a server only until the next server in the message path confirms delivery. To illustrate how this works, consider an organization that has five Active Directory sites with Hub Transport servers installed. The sites are connected to each other as shown in the following figure. The organization has New York and London sites configured as hub sites, so the messages from Chicago or Atlanta need to go through Hub Transport servers in the New York and London sites to get to the Dublin site.

Assume that a message is sent by a user in the Chicago site to a user in the Dublin site. This message will need to travel through the New York and London sites to get to Dublin. In this case, the following occurs:

1. The Hub Transport server in Chicago will send the message to the Hub Transport server in New York, and it will retain a shadow copy of the message.
   
   
2. The New York Hub Transport server will send the message to the Hub Transport server in London and queue a discard status for the Chicago hub.
   
   
3. The Chicago hub queries the New York hub for discard status and receives the discard notification for the message. At this time, it can remove the shadow message from its database. Whether the message was delivered from London to Dublin doesn't have an impact on when the Chicago server deletes the shadow message.
   
   

When using database availability groups (DAGs), the messages that are already committed to mailbox databases are protected with the DAG architecture. For any message delivered to a mailbox database that's part of a DAG, the shadow copy for that message is retained in the transport dumpster until that message is replicated to all DAG members. Similarly, any message submitted to Hub Transport servers from a DAG member has two copies, one in the Hub Transport server queue waiting for delivery, and a shadow copy in the sender's Sent Items folder. This approach is a key component of shadow redundancy.

However, when the Hub Transport and Mailbox server roles coexist on the same server, and you have mailbox databases that are part of a DAG, Hub Transport servers may have to route a message through an extra hop to avoid having the primary message and the shadow message on the same server hardware. Specifically, the Hub Transport server role attempts to avoid the following two scenarios because a failure of a single server may result in the loss of both the primary and shadow messages:

• During message delivery, where the active mailbox database of the message recipient and the transport dumpster containing the shadow copy of the message are on the same server    To avoid this scenario, the Hub Transport server routes the message through another Hub Transport server within the site to ensure that the shadow message ends up on different server hardware. However, if no other Hub Transport servers are available, it delivers the message directly.
  
  
• During message submission, where the transport queue holding the primary message and the shadow message in the Sent Items folder of the sender are on the same server   To avoid this scenario, the store driver prefers other Hub Transport servers in the site for message submission. However, if no other Hub Transport servers are available in the site, it submits the message to the local Hub Transport server.
  
  

For more information about Hub Transport and Mailbox server role coexistence when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs.

Whether shadow redundancy will be used or not is decided while establishing a new SMTP connection. If both servers in an SMTP connection support shadow redundancy, the workflow mentioned previously is used. However, there will be situations where Exchange 2010 transport servers exchange messages with mail servers that don't support shadow redundancy. These could be third-party mail servers, earlier versions of Exchange, or an Exchange 2010 organization that hasn't enabled shadow redundancy.

When an Exchange 2010 transport server that supports shadow redundancy establishes a connection with a server that doesn't support shadow redundancy, the following events take place:

1. Exchange establishes an SMTP connection to the target server.
   
   
2. The target server doesn't advertise shadow redundancy support.
   
   
3. Because the target server doesn't support redundancy, Exchange will perform the following for each message:
   
   
   1. Deliver the message to the target server.
      
      
   2. Shadow Redundancy Manager will mark that the message is delivered to the next hop.
      
      
   3. Delete the message after it's delivered to all of the next hops.
      
      

When a server that doesn't support shadow redundancy establishes a connection with an Exchange 2010 server, the following events take place:

1. The sending server establishes an SMTP connection with Exchange.
   
   
2. Exchange advertises shadow redundancy support.
   
   
3. The sending server doesn't support shadow redundancy and therefore it won't use it. It will deliver messages to the Exchange server.
   
   
4. For each message Exchange receives, it will do the following:
   
   
   1. Deliver the message to the next hop, or make a shadow copy of it.
      
      
   2. Send acknowledgement to the sending server.
      
      

The main principle behind shadow redundancy is maintaining a copy of the message on the previous hop until the server verifies that it has successfully delivered it to all the next hops. This isn't possible when an Exchange 2010 transport server is receiving a message from a mail server that doesn't support shadow redundancy. This mail server can be an Exchange server running an older version of Exchange, a standard SMTP client, or a non-Exchange mail server on the Internet. In this case, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the mail server until it verifies that the message has been successfully delivered to all the next hops internally. This way, if the Exchange 2010 server fails, the sending mail server will assume that the message was never delivered to Exchange and will attempt delivery again.

However, the delivery of the message to the next hops may take a long time due to the complexity of your routing infrastructure, or failure of one of the next hops. In this case, to prevent the SMTP session from timing out, the Exchange 2010 transport server will send an acknowledgement to the sending mail server. In this case, the mail redundancy isn't guaranteed, but it's a best effort. For example, a message may be lost in the following scenario: An Internet mail server transmits a message to an Edge Transport server. The Edge Transport server can't communicate with the Hub Transport server due to a network problem and acknowledges the receipt of the message to the Internet mail server. The Edge Transport server then fails and can't be recovered before the network problem is resolved. At this point, the message is lost.

The delayed acknowledgement time-out value is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. To learn more about configuring this attribute, see Configure Shadow Redundancy.

There are cases where it's unlikely a message will be delivered before the delayed acknowledgement time-out is reached. In these cases, the transport server uses one of the following methods to handle messages:

• Skipping delayed acknowledgement    By default, the transport server skips the delayed acknowledgement to maintain SMTP receive throughput. In essence, the transport server issues an acknowledgment before the time-out is reached.
  
  
• Shadow redundancy promotion    In Microsoft Exchange Server 2010 Service Pack 1 (SP1), instead of skipping the delayed acknowledgement, the transport server can be configured to relay the message to any other transport server in the site. This effectively inserts the message into the shadow redundancy pipeline, thereby protecting the message. This process is called shadow redundancy promotion. This approach minimizes the number of unprotected messages in the organization when compared to the skipping delayed acknowledgement method. By default, this feature is disabled. To enable shadow redundancy promotion, an administrator must edit the Edgetransport.exe.config file, change the shadowredundancypromotionenabled key to true, save the changes to the file, and then restart the Microsoft Exchange Transport service (MSExchangeTransport.exe). For more information about how to do this, see the “Enable Shadow Redundancy Promotion“ section in the Configure Shadow Redundancy topic.
  
  

The following table lists different scenarios ion which a transport server bypasses delayed acknowledgement, and describes how an Exchange 2010 server handles that scenario.

Return to top

Shadow Redundancy Manager uses heartbeat to determine the availability of the servers for which shadow messages are queued. During the SMTP session between two servers that both support shadow redundancy, the server that initiates the connection queries the target server for discard status of messages previously submitted to that server. The initiating server accomplishes this by issuing an XQUERYDISCARD command. In response, the target server returns the discard notifications. This exchange between the two servers is used as the heartbeat for shadow redundancy.

There is a time-out value for the heartbeat. If no connections are established to a server for which Shadow Redundancy Manager is maintaining a shadow queue for that duration, the server will attempt to establish an SMTP connection with the primary server specifically to query the discard status and reset the timer. The time-out value is controlled by the ShadowHeartbeatTimeoutInterval parameter of the Set-TransportConfig cmdlet. The default value for this parameter is 300 seconds in the release to manufacture (RTM) version of Exchange 2010, and 900 seconds in Exchange 2010 SP1.

If the server can't establish a connection to a primary server when the time-out value is reached, it will reset the timer and try again. If the time-out value is reached twelve times in a row (three times in a row in Exchange 2010 RTM), the server will conclude that the primary server has failed and will assume ownership of the shadow messages and begin to generate discard notifications for them to send to the primary server that failed. The number of time-outs a server will wait before deciding a primary server has failed is controlled by the ShadowHeartbeatRetryCount parameter of the Set-TransportConfig cmdlet.

To learn more about configuring the shadow redundancy heartbeat, see Configure Shadow Redundancy.

Return to top