Hi!
It’s been a while since I wrote my last article, but I’ve been quite busy with a few other things lately…
In this article, I wanted to talk to you about a feature that has been available in Exchange Server 2010 since Service Pack 1, but is often “forgotten” about: Shadow Redundancy Promotion.
Shadow Redundancy
Over the past few edition of Exchange Server, Microsoft has made significant improvements to the high availability and resiliency of the Transport service. These improvements ensured that the risk of losing messages in transit was greatly reduced.
Exchange Server 2007 first introduced the Transport Dumpster; a feature that made an Exchange 2007 Hub Transport server keep a local queue of messages that were delivered recently. In case a failover occurred, the mailbox server would automatically request messages from the “transport dumpster” to be resubmitted. Although this mechanism prevents messages from being lost during a failover, it’s only available to mailboxes in a cluster. More importantly, it does not offer any protection for messages that are being sent between Hub Transport Servers and between Hub- and Edge Transport Servers.
Then came Exchange Server 2010 which introduced ‘Shadow Redundancy’. This feature is in a lot of ways similar to the “Transport Dumpster”: a message is kept in the local transport queue until the next hop(s) for that message acknowledge they have successfully received the message. If any of the ‘next hops’ would not acknowledge the receipt, the message(s) would be resubmitted.
The following image graphically explains how Shadow Redundancy works (in a nutshell!):
“The Problem”
The problem with Shadow Redundancy is, that it only works for servers that support Shadow Redundancy (seems logical, doesn’t it?). However, in some scenario’s Shadow Redundancy just might not be enough. Image the following: you receive an email from a mail server that does not support Shadow Redundancy. In this case, the Exchange server cannot use Shadow Redundancy but will try to achieve the same result by delaying receipt acknowledgement to the sending server (External) until it has received the confirmation that the message has been received by the next hop in line (Brussels).
The receipt acknowledgement, however, cannot be delayed infinitely. In some cases, the receiving server (Antwerp) cannot send the message further down the route because the next hop is unavailable. This can be due to a failure or perhaps because of maintenance happing on that server. If that’s the case, there’s a small risk that mails might get lost IF this particular Hub/Edge Transport server fails (in the example below that would be the server in Antwerp):
If the server in Antwerp would fail after it has sent the receipt acknowledgement but before it was able to relay the message to Brussels; the message would be lost.
The Solution
Since Service Pack 1, Exchange has a new feature called “Shadow Redundancy Promotion”. With this feature enabled, the Transport Server (Antwerp) will try to relay the message to another Transport server in the organization (Gent) whenever it’s not able to relay to the destination (Brussels). By doing so, it injects the message into the shadow redundancy pipeline. As a result, the message is now protected from failure from the server in Antwerp (or Gent):
Enabling Shadow Redundancy Promotion
To enable the feature, you will have to make some changes to the EdgeTransport.exe.config file which you can find in the “Bin”-directory under your Exchange Server installation path:
In that file, change the value for “ShadowRedundancyPromotionEnabled” from “False” to “True”:
Save the changes and restart the Transport Service to activate them. Et voilà, you’re done! 
Until later!
Michael
