Understanding the Shadow Redundancy feature in Exchange 2013

Shadow redundancy provides a way of ensuring a redundant copy of a message is kept on the transport service (which is part of the Mailbox Server in Exchange 2013.) This provides a way of re-sending a message if it is lost somewhere during the delivery of the mail item.

The Client Access Server simply relays / is used to proxy mailflow between the inner boundary (mailboxes) and the outer boundaries (e.g. egress mail to the internet.) and does not feature / support Shadow Redundancy.

There are certain requirements in order to successfully implement shadow redundancy:
- Must be two or more Mailbox Servers (obviously!)
- Must be a primary and a secondary server
- Must be part of the same DAG (Database Availability Group) or part of the same domain

In order for Shadow Redundancy to work correctly as stated above you require at least two Mailbox servers - one of which will be used to store the redundant copy of the message on.

Shadow redundancy is only supported on Exchange 2010 and above and the transport service identifies whether a given transport service supports the feature by checking for the "XSHADOW" verb. Further if there were multiple hops to a destination for a piece of mail the "Shadow Copy" of the message would only be retained on the last hop that had a success message from its next hop.

Transport high availability boundary: Is defined within a DAG (Database Availability Group) which could potentially span across multiple AD sites OR An AD site (local) for Mailbox server. Shadow redundancy operates ONLY within a transport high availability boundary.

Explanation of the flow: Say a transport service (on TS1) received an ingress email from the internet via an Edge Server - the message would be routed to the next hop (TS2) to it's destination e.g. another transport service. The message would be placed in a queue called "Shadow Redundancy Queue" on TS1 until the message has been successfully delivered (either to its final destination or next hop in the path.) TS1 will periodically poll TS2 to ask whether any of the messages it's sent on to it have been successfully delivered and once confirmed the message will be deleted from "Shadow Redundancy Queue" on TS1.

You can also find an extract from TechNet below that explains this process (although bare in mind it is using Exchange 2010 as an example):


Shadow redundancy can be turned on or off by the "Set-TransportConfig" powershell cmdlet (but it is worth noting that by default it is turned on in Exchange 2013.)

Set-TransportConfig -ShadowRedundancyEnabled $false