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
1 |
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.
1 |
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:
1 |
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):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
+,, *,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
1 2 |
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:
1 2 |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
+,, *,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:
1 |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
+,, *,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, |
- The SMTPAcceptXShadow in the start of the conversation shows that the permissions have been applied correctly.
- We can see the 2 HUB servers starting XSHADOW
12<,XSHADOW MGE5N2Q4YjgtNTg4MC00MGYzLWEzNWUtOWE3ZDk4ZGJjMDFlQFVDLUhDMS51bmlib3gubWVA,>,250 tStREZcEVUiXW96O4lqrJA==,
- 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,
- Finally HUBOrg1 queries for messages ready to be removed from the shadow redundancy and HUBOrg2 replies that there are none.
12<,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.
1 2 |
<,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:
1 2 |
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:
1 2 |
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 |
Load comments