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 org1.com as the sender organization and org2.com 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 user@org2.com through smart host 192.168.0.112 (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 192.168.0.211 (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 user1@org1.com to administrator@org2.com 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 user1@org1.com to administrator@org2.com 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
   1 2	<,XSHADOW MGE5N2Q4YjgtNTg4MC00MGYzLWEzNWUtOWE3ZDk4ZGJjMDFlQFVDLUhDMS51bmlib3gubWVA, >,250 tStREZcEVUiXW96O4lqrJA==,

3. We then see HUBOrg1.com assigning a unique XSHADOW id to the message being sent in:
   1	<,MAIL FROM:<user1@org1.com> SIZE=4641 XSHADOW=845e8916-2efb-444f-b7ea-5e676ddfa6a5,

4. Finally HUBOrg1 queries for messages ready to be removed from the shadow redundancy and HUBOrg2 replies that there are none.
   1 2	<,XQDISCARD 50, >,"251 OK, no discard events",

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.

Conclusion

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: