Problem solve Get help with specific problems with your technologies, process and projects.

How Exchange Server 2010 Shadow Redundancy prevents message loss

Hub transport servers are more resilient in Exchange Server 2010 because of Shadow Redundancy. See how this feature protects you from message loss – even during a hub transport server failure.

Exchange Server 2010 includes Shadow Redundancy, a feature that prevents message loss and makes it possible to take a hub transport server offline for maintenance without interrupting mail flow. This tip from Exchange Server expert Brien Posey takes an in-depth look at Shadow Redundancy.

One of the most significant architectural changes that Microsoft made in Exchange Server 2007 was the introduction of the hub transport server. Microsoft designed the hub transport server so that all messages had to pass through a centralized transport pipeline, opening the door for transport rules and transport-level archiving. However, it also made Exchange Server 2007 vulnerable to hub transport failures.

Exchange Server 2007 hub transport servers use a database that acts as a message queue. As soon as a message is sent to the next hop , the message is deleted from the hub transport database. Because there are no safeguards around the hub transport database, message loss can occur if a hub transport server fails.

Microsoft built safeguards for clustered mailbox servers; when a message is sent to a recipient whose mailbox resides on a clustered mailbox server, a copy of the message is placed into a transport dumpster on the hub transport server. If one of the cluster nodes fails, recently sent items can be retransmitted so that messages are not lost during failover.

Although the transport dumpster protects against message loss, it's only protects mailboxes that reside on a clustered mailbox server. The transport dumpster also does not protect against message loss for messages flowing between the hub transport server and an edge transport server.

Shadow Redundancy makes hub transport servers more resilient against message loss. In Exchange Server 2010, hub transport servers still use a transport database as a message queue. Exchange Server 2007 deleted messages from the database as soon as they were sent to the next hop; however, Shadow Redundancy keeps messages in the database until Exchange confirms that they were been delivered. This way, if message delivery fails, messages could be retransmitted.

More on Exchange Server 2010:
New OWA features in Exchange Server 2010

Understanding the Legal Hold role in Exchange Server 2010

What's new in Microsoft Outlook 2010?

Although the basic premise behind Shadow Redundancy is simple, the actual mechanics used are not. Previous versions of Exchange Server were not designed to verify message delivery. Microsoft has extended SMTP service so that SMTP hosts can negotiate Shadow Redundancy support in Exchange Server 2010.

This approach enables hub transport redundancy. Although no version of Exchange supports clustering hub transport servers, Shadow Redundancy produces the same result. Simply put, the failure of a hub transport server no longer leads to message loss.

If redundant hub transport servers exist, messages will be automatically rerouted through one of the remaining hub transport servers. The best part about this is that Exchange Server does not require that copies of every message be sent to each hub transport server in case of failure. This is possible because each server that a message passes through retains its own shadow queue.

For example, imagine a user with a mailbox on Server 1 sends a message to a user whose mailbox is on Server 2. The sender composes the message in Outlook and its sent to his outbox on Server 1. Server 1 places a copy of the message into a shadow queue, and then sends the message to the hub transport server. Let's assume that the hub transport server receives the message, but fails before it can confirm that the message has been delivered to the recipient's mailbox on Server 2.

Server 1 will eventually reach a timeout threshold and realize that it received no delivery confirmation. Server 1 -- which still has a copy of the message in its shadow queue -- attempts to send the message again. Since the original hub transport server used is offline, the message is sent through a different hub transport server. This time, Server 2 confirms receipt of the message. Server 1 eventually receives the confirmation and the message is removed from its shadow queue.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was last published in March 2010

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close