Simple Talk is now part of the Redgate Community hub - find out why

Extending Exchange 2010 Shadow Redundancy Cross Forest

When a customer asks for an Exchange Server feature that you have no idea how to implement, and you just get one item coming up on Google, then you've got the blues. Antoine relates the struggle from that point to successful delivery of the feature.

I have recently been faced with a new challenge at a customer of mine who wanted to extend the Exchange 2010 Shadow Redundancy feature beyond the borders of his forest to include a partner’s Exchange 2010 organization.

My first reaction was that it cannot be done but then, a quick internet search, returned only one relevant match to my query. A blog post about Brian Reid, a Microsoft Certified Master Instructor, stated “some of the required lab exercises include shadow redundancy cross forest”.

I was on my own; I knew it could be done and I needed to find out how. The following excerpt from “Understanding Shadow Redundancy” got me started:

“When an SMTP connection is established to an Exchange 2010 transport server, it will advertise shadow redundancy support if the ms-Exch-SMTP-Accept-XSHADOW extended right exists on the Receive connector being used. In addition, the authentication mechanism on the Receive connector should be either Exchange Server authentication or Externally Secured.

When an Exchange 2010 transport server establishes an SMTP connection to another server that advertises shadow redundancy support, it will issue an XSHADOW command only if the session has been granted the ms-Exch-SMTP-Send-XSHADOW extended right.”

So the basic idea was to create, on the sender organization side, a send connector and assign to it the ms-Exch-SMTP-Send-XSHADOW extended permission and a receive connector, on the receiver organization side and assign to the latter the ms-Exch-SMTP-Accept-XSHADOW extended permission. And this is exactly what I did.

For this article I will use as the sender organization and as the receiver organization; you will need, of course, to change the PowerShell commands to fit your environment.

Attempt 1

To create the send connector I have used the following PowerShell command

This would create a send connector called “To Org2” routing all emails sent to through smart host (the HUB server of org2) and set HUBOrg1, responsible for this domain’s mail routing.

Next thing to do was assigning the ms-Exch-SMTP-Send-XSHADOW specified in the article; this was done piping the Get-SendConnector cmdlet with the ADD-ADPermission cmdlet as follows.

As you can see this command allows Anonymous the ms-Exch-SMTP-Send-XSHADOW extended rights.

Now, on org2, a receive connector was created using the following:

A closer look to the above shows that we are creating a receive connector on HUBOrg2 and allowing remote IP (the HUB server of Org1) to use it. This receive connector will also allow Anonymous connections to it.

The Authentication Mechanism was set to “ExternalAuthoritative” because, as per Microsoft Article above, “the authentication mechanism on the Receive connector should be either Exchange Server authentication or Externally Secured.”

Finally protocol logging was enabled on this connector to help me with the troubleshooting.

After this small setup a test email was sent from to but no shadow redundancy queue showed up on the HUBOrg1 server.

A closer look in the SmtpReceive logs revealed some interesting information; the SMTP conversation between the 2 servers looked like the following (I have highlighted the relevant portion of the conversation):

It looked like HUBOrg1 did try to issue an XSHADOW command but was not authorized by HUBOrg2 although the permission were set correctly since the second line of the conversation shows SMTPAcceptXShadow.

Attempt 2

The failure of my first attempt got me thinking, what if “Not Authorized” error was because HUBOrg1, the sender, was identifying itself as anonymous? What if the permissions should be assigned to Externally Secured Servers instead?

I decided to follow this path so I deleted both, the send and receive connectors previously created, and started over, this time the send connector was created as follows

The main difference between this connector and the one previously created is that, this time, the permissions were given to “MS Exchange\Externally Secured Servers” instead of “NT AUTHORITY\ANONYMOUS LOGON”.

With the same logic the Receive connector was created:

After the test email was sent from to no shadow redundancy queue appeared in the queue viewer and this time the SMTP conversation was:

What was weird in this conversation is that there was not even a XSHADOW command initiated like previously. It was like HUBOrg2 did not advertise itself as supporting Shadow Redundancy although the permission was showing in the start of the conversation (highlighted in yellow).

Then it hit me, the reason for this was because SMTPAcceptXShadow permission was given to the Externally Secured Servers however HUBOrg1 was still identifying itself as anonymous.

Attempt 3

This time I did not recreate all connectors however I just changed the Smart Host authentication on the send connector with the below command and sent another test email:

To my joy the Shadow Redundancy queue showed up in the queue viewer of HUBOrg1, I had it working!

Let’s take a look at the SMTP conversation once more:

  1. The SMTPAcceptXShadow in the start of the conversation shows that the permissions have been applied correctly.
  2. We can see the 2 HUB servers starting XSHADOW
  3. We then see assigning a unique XSHADOW id to the message being sent in:
  4. Finally HUBOrg1 queries for messages ready to be removed from the shadow redundancy and HUBOrg2 replies that there are none.

Here is another SMTP conversation taken from the same log file a bit later showing the same query from HUBOrg1 asking about messaged to be removed from the shadow redundancy queue (XQDISCARD 50) but this time HUBOrg2 is replying with the unique XSHADOW id of the mail sent earlier informing HUBOrg1 that the email was delivered correctly to the next hop and it can be removed from the shadow redundancy queue.


This challenge turned out harder than I thought it would but I have learned a great deal solving it. Here are the commands you will need to run to get this working in your environment

On the sender side:

On the receiver side:

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.


Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.