Tag Archives: Hybrid Configurations

“Enable Centralized Mail Transport” / “Route all Internet-bound messages through your on-premises Exchange servers” and NDR Remote Server returned ‘550 5.7.1 Unable to relay’

BACKGROUND

You configure the Hybrid with the option to route back e-mail from Exchange Online users to your On-premise organization Before sending them to the Internet.

  • In the Exchange 2013 Hybrid Configuration Wizard, this option is called: “Enable Centralized Mail Transport”
  • In the Exchange 2010 Hybrid Configuration Wizard, this option is called: “Route all Internet-bound messages through your on-premises Exchange servers”

This is not the default option, but is necessary for some organizations due to compliance or message tracking reasons.

What it does is that it is adding a wildcard (*) in the send connector in FOPE/EOP, that normally only is used for your shared domains, to route back e-mail to users On-premise that have not been migrated to Exchange Online. The wildcard enables this send connector for all domains on the Internet, thus route the e-mail back to your On-premise Exchange Environment.

Your On-premise Exchange Environment can without any problem route e-mail to your internal, not yet migrated users, because that Exchange Environment knows about those domains and their recipients. Internet recipients, on the other hand, will require your message from the Exchange Online user to be RELAYED outside your On-premise Exchange, back to the Internet.

This fails with the following NDR (bounce message) information to the sender in Exchange Online:

Remote Server returned ‘550 5.7.1 Unable to relay’

CAUSE

The receive connector that the Hybrid Configuration Wizard creates on-premise to Catch the e-mail that Exchange Online sends back is not fully configured and ready for use after running the Hybrid Wizard.

RESOLUTION

To fix the “Inbound from Office 365” receive connector, you need to both populate the list of allowed IP-addresses and enable the receive connector for relaying.

Follow these steps:

  1. Open the Receive Connector properties in EMC or ECP (2010 or 2013 on-premise)
  2. First, open the Network tab/settings to investigate the list of remote servers, “Receive mail from remote servers that have these IP addresses”.
  3. The list of allowed IP-addresses is supposed to be populated by the Hybrid Configuration Wizard – BUT IT IS NOT COMPLETE! Use this article to verify each address space is included in this list: http://help.outlook.com/en-us/140/gg263350.aspx . Make sure to read the complete article to understand that the list of IP-addresses is subject to change etc.
  4. After making sure that your list of allowed IP-addresses is complete, you still need to enable the receive connector to allow further relaying to Internet recipients when the message origins from Exchange Online:
  5. Fire up Exchange Management Shell and run this PowerShell command to enable the “Inbound from Office 365” receive connector for relaying:

Get-ReceiveConnector ” Inbound from Office 365 ” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

After filling up the list of allowed IP-addresses and enabled it for relaying to Internet recipients, your mail flow will work as expected with the “Centralized Mail Transport” / “Route all Internet-bound messages through On-premise” option enabled.

Note: Be careful not to add excessive IP-address ranges to your receive connector. You do not want to create an open relay – make sure that you only allow Exchange Online hosts to relay.

 

 

Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired. (Be PATIENT!)

BACKGROUND

You are running this command to see if you are on top of your Hybrid Configuration or not:

Test-FederationTrust | fl

It looks pretty good, but fails at the end with this depressing statement:

Id      : OrganizationCertificate
Type    : Error
Message : Certificate referenced by property OrgPrivCertificate in the FederationTrust object is expired.

 Naturally, you investigate the Exchange Delegation Federation Certificate on your side and find that is good for another five years! So why is it telling you that it is expired?

CAUSE

If you start investigating this issue, you will find pointers to ADSIEdit and how to cycle up new certificates etc. My advice: Don’t go there. If this configuration is against Office 365/Exchange Online/Microsoft Federation Gateway – it is probably more simple than that. Microsoft Federation Gateway (MFG) is very sensitive when it comes to time.

RESOLUTION

Notes from the field:

  1. MFG is sensitive about time. Investigate your time zone settings, external time source (AD PDC Emulator settings and VM hypervisors etc.)
  2. If time settings are OK, just WAIT!

Waiting will solve this problem. For the configuration that made me write this blog post, it took 45 minutes, but I suggest that you should wait as long as time allows you. Just leave all remote PS sessions for the Office 365 tenant in question for a couple of hours and try again. The result after waiting  (no configuration made in the meantime):

[PS] C:\>Test-FederationTrust | fl

Id      : FederationTrustConfiguration
Type    : Success
Message : FederationTrust object in ActiveDirectory is valid.
Id      : FederationMetadata
Type    : Success
Message : The federation trust contains the same certificates published by the security token service in its federation metadata.
Id      : StsCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.
Id      : StsPreviousCertificate
Type    : Success
Message : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.
Id      : OrganizationCertificate
Type    : Success
Message : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object. Id      : TokenRequest
Type    : Success Message : Request for delegation token succeeded.
Id      : TokenValidation
Type    : Success
Message : Requested delegation token is valid.

 

After cracking one of these, you really feel like an Exchange genius. Awesome.