Click here to monitor SSC
  • Av rating:
  • Total votes: 13
  • Total comments: 0
Antoine Khater

Extending Exchange 2010 Shadow Redundancy Cross Forest

01 December 2011

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 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

New-SendConnector "To Org2" -AddressSpaces org2.com -SmartHosts 192.168.0.112 -Usage Custom -SourceTransportServers HUBOrg1

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.

Get-SendConnector “To Org2” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights ms-Exch-SMTP-Send-XSHADOW

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:

New-ReceiveConnector "From Org1" –Server HUBOrg2 -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.211 -Usage Custom -ProtocolLoggingLevel Verbose -PermissionGroups ExchangeServers,AnonymousUsers -Banner “220 Trusted Partner” -AuthMechanism ExternalAuthoritative

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):

+,,

*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders SMTPAcceptXShadow,Set Session Permissions

*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders, Set Session Permissions

>,220 Trusted Parner,

<,EHLO HUBOrg1.org1.com,

>,250-HUBOrg2.org2.com Hello [192.168.0.211],

>,250-SIZE 10485760,

>,250-PIPELINING,

>,250-DSN,

>,250-ENHANCEDSTATUSCODES,

>,250-AUTH,

>,250-8BITMIME,

>,250-BINARYMIME,

>,250-CHUNKING,

>,250-XEXCH50,

>,250 XSHADOW,

<,XSHADOW NGYwNzg5MWMtOWIyMC00ZGUwLTgwMjMtY2UxNTFkMGJhYjUyQFVDLUhDMS51bmlib3gubWVA,

>,550 5.7.1 Not authorized,

<,MAIL FROM:<user1@org1.com> SIZE=4641,

*,08CE6319F8EF390E;2011-10-27T23:47:50.757Z;1,receiving message

<,RCPT TO:<administrator@org2.com>,

>,250 2.1.0 Sender OK,

>,250 2.1.5 Recipient OK,

<,BDAT 3008 LAST,

Tarpit for '0.00:00:01.734' due to 'DelayedAck',Delivered

>,250 2.6.0 <25222D15A1608F488FEC8DBB9F6478482A778498@MBOrg1.org1.com> [InternalId=8] Queued mail for delivery,

<,QUIT,

>,221 2.0.0 Service closing transmission channel,

-,,Local

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

New-SendConnector "To Org2" -AddressSpaces org2.com -SmartHosts 192.168.0.112 -Usage Custom -SourceTransportServers HUBOrg1

Get-SendConnector “To Org2” | Add-ADPermission -User “MS Exchange\Externally Secured Servers” -ExtendedRights ms-Exch-SMTP-Send-XSHADOW

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:

New-ReceiveConnector "From Org2" -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.211 -Usage Custom -ProtocolLoggingLevel Verbose -PermissionGroups ExchangeServers -Banner “220 Trusted Parner” -AuthMechanism ExternalAuthoritative

Get-ReceiveConnector “From Org2” | Add-ADPermission -User “MS Exchange\Externally Secured Servers” -ExtendedRights ms-Exch-SMTP-Accept-XSHADOW

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:

+,,

*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions

*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders SMTPAcceptXShadow,Set Session Permissions

>,220 Trusted Parner,

<,EHLO HUBOrg1.org1.com,

>,250-HUBOrg2.org2.com Hello [192.168.0.211],

>,250-SIZE 10485760,

>,250-PIPELINING,

>,250-DSN,

>,250-ENHANCEDSTATUSCODES,

>,250-AUTH,

>,250-8BITMIME,

>,250-BINARYMIME,

>,250-CHUNKING,

>,250-XEXCH50,

>,250 XSHADOW,

<,MAIL FROM:<user1@org1.com> SIZE=4238,

*,08CE631A5D8CC629;2011-10-27T23:50:39.562Z;1,receiving message

<,RCPT TO:<administrator@org2.com>,

>,250 2.1.0 Sender OK,

>,250 2.1.5 Recipient OK,

<,BDAT 2812 LAST,

*,Tarpit for '0.00:00:01.484' due to 'DelayedAck',Delivered

>,250 2.6.0 <25222D15A1608F488FEC8DBB9F6478482A7784A4@HUBOrg1.org1.com> [InternalId=8] Queued mail for delivery,

<,QUIT,

>,221 2.0.0 Service closing transmission channel,

-,,Local

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:

Set-SendConnector "To Org2" -SmartHostAuthMechanism ExternalAuthoritative

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:

+,,

*,None,Set Session Permissions

*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders SMTPAcceptXShadow,Set Session Permissions

>,220 Trusted Parner,

<,EHLO HUBOrg1.org1.com,

>,250-HUBOrg2.org2.com Hello [192.168.0.211],

>,250-SIZE 10485760,

>,250-PIPELINING,

>,250-DSN,

>,250-ENHANCEDSTATUSCODES,

>,250-AUTH,

>,250-8BITMIME,

>,250-BINARYMIME,

>,250-CHUNKING,

>,250-XEXCH50,

>,250 XSHADOW,

<,XSHADOW MGE5N2Q4YjgtNTg4MC00MGYzLWEzNWUtOWE3ZDk4ZGJjMDFlQFVDLUhDMS51bmlib3gubWVA,

>,250 tStREZcEVUiXW96O4lqrJA==,

<,MAIL FROM:<user1@org1.com> SIZE=4641 XSHADOW=845e8916-2efb-444f-b7ea-5e676ddfa6a5,

*,08CE631B9A1713A9;2011-10-28T00:00:49.882Z;1,receiving message

<,RCPT TO:<administrator@org2.com>,

>,250 2.1.0 Sender OK,

>,250 2.1.5 Recipient OK,

<,XEXCH50 1076 2,

>,354 Send binary data,

>,250 2.0.0 XEXCH50 OK,

<,BDAT 3008 LAST,

>,250 2.6.0 <25222D15A1608F488FEC8DBB9F6478482A778522@HUBOrg1.org1.com> [InternalId=9] Queued mail for delivery,

<,XQDISCARD 50,

>,"251 OK, no discard events",

<,QUIT,

>,221 2.0.0 Service closing transmission channel,

  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

    <,XSHADOW MGE5N2Q4YjgtNTg4MC00MGYzLWEzNWUtOWE3ZDk4ZGJjMDFlQFVDLUhDMS51bmlib3gubWVA,

    >,250 tStREZcEVUiXW96O4lqrJA==,

  3. We then see HUBOrg1.com assigning a unique XSHADOW id to the message being sent in:

    <,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.

    <,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.

<,XQDISCARD 50,

>,250 845e8916-2efb-444f-b7ea-5e676ddfa6a5,

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:

New-SendConnector "To Org2" -AddressSpaces Org2.com -SmartHosts 192.168.0.112 -Usage Custom -SmartHostAuthMechanism ExternalAuthoritative -SourceTransportServers HUBOrg1

Get-SendConnector “To Org2” | Add-ADPermission -User “MS Exchange\Externally Secured Servers” -ExtendedRights ms-Exch-SMTP-Send-XSHADOW

On the receiver side:

New-ReceiveConnector "From Org1" -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.0.211 -Usage Custom -ProtocolLoggingLevel Verbose -PermissionGroups ExchangeServers -Banner “220 Trusted Parner” -AuthMechanism ExternalAuthoritative

Get-ReceiveConnector “From Org1” | Add-ADPermission -User “MS Exchange\Externally Secured Servers” -ExtendedRights ms-Exch-SMTP-Accept-XSHADOW

Antoine Khater

Author profile:

Antoine has been working in IT consultancy and solution integration since 1998, and considers himself lucky to be one of the few making a living out of his passion. On the side, he has also been a MCSE since 1999, and recently upgraded to being a MCITP, including MCITP: Enterprise Messaging Administrator 2007/2010 and an official Microsoft Certified Trainer (since 2001). He blogs regularly at ZeroHourSleep, and can also be found on twitter as @zerohoursleep.

Search for other articles by Antoine Khater

Rate this article:   Avg rating: from a total of 13 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.
 

Top Rated

Migrating to Microsoft BPOS - Part II
 In his last article, Johan gave us a crystal clear guide to preparing to migrate from an on-premises... Read more...

Emulating the Exchange 2003 RUS for Out-of-Band Mailbox Provisioning in Exchange 2007
 Exchange's Recipient Update Service was important in Exchange 2000 or 2003 in order to complete the... Read more...

The Postmasters
 The Exchange Team introduces themselves, and keeps you up-to-date Read more...

For this Exchange Server Archiver, “Transparency” Fits
 Sometimes, it is a great relief when a user of your software gives it a tough test and then reports... Read more...

Hunting in Packs, Seamless-ness and Happy Holidays
 I attended DevConnections (Exchange) last month and was blown away by the technical talks. Speakers... Read more...

Most Viewed

Upgrade Exchange 2003 to Exchange 2010
  In this article, the first of two in which Jaap describes how to move from Exchange Server 2003... Read more...

Upgrade Exchange 2003 to Exchange 2010 - Part II
 In Jaap's second article on upgrading straight from Exchange Server 2003 to 2010, he explains how to... Read more...

Goodbye Exchange ExMerge, Hello Export-Mailbox
 ExMerge was a great way of exporting a mailbox to an Exchange PST file, or for removing all occurences... Read more...

Exchange E-mail Addresses and the Outlook Address Cache
 Because Exchange auto-complete cache uses X.500 addresses for e-mail sent to addresses within the... Read more...

Using Exchange 2007 for Resource Booking
 The process of booking various resources to go with a meeting room just got a whole lot easier with... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.