No Mail Flow On-Premises To/From Office 365

Posted on by

KB ID 0001631

Problem

I upgraded my On-Premises Hybrid Exchange server recently, from Exchange 2016 to Exchange 2019. I remembered to add the new server onto the Office 365 send connector, but there was no mail flow between an on premises mailbox and an office365 mailbox?

Solution

This happens because, (even if you are using the same certificate on the new and old servers) the certificate that is used for TLS security between your on-premises Exchange server and Exchange online, does not get ’embedded’ properly on the send/receive connectors. You may see either (or both) of the following two problems.

Check The Office 365 Mail Flow

Log into Office 365 > Admin > Exchange Admin Center > Mail Flow > Connectors > Select the ‘Outbound’ connector > Validate this connector.

Herein lies the problem!

450 4.4.317 Cannot connect to remote server [Message=SubjectMismatch] [LastAttemptedServerName={on-prem-fqdn}] [LastAttemptedIP={on-prem-ip}}:25] [{outlook-FQDN}]

At first I thought the on-premises server was presenting the wrong cert for TLS, turns out it was not presenting a cert at all! You can check by executing the following command on the RECEIVE CONNECTOR;

[box]

Get-ReceiveConnector "{SERVER-NAME}\Default Frontend {SERVER-NAME}" | fl TlsCertificateName

[/box]

If it returns no entry (like the image below), then you need to simply attach the correct certificate. To do that first get the ‘thumbprint’ of the correct certificate;

[box]

Get-ExchangeCertificate

[/box]

Copy the correct thumbprint, and embed it with the following commands;

[box]

$tlscert=Get-ExchangeCertificate {THUMBPRINT}
$tlscertname="<I>$($TLScert.Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector "{SERVER_NAME}\Default Frontend {SERVER_NAME}" | Set-ReceiveConnector -TlsCertificateName $tlscertname
Restart-Service MSExchangeTransport

[/box]

Now test validation again from Office 365 portal.

Check The Office On-Premises Mail Flow

To do this, open Exchange Tools > Queue Viewer, and you will probably see something like this;

454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found.

To fix this, the procedure is much the same as above, only this time you perform the procedure on the SEND CONNECTOR ;

Note: I’m assuming you are using the same Thumbprint you used above,

[box]

$tlscert=Get-ExchangeCertificate -Thumbprint {THUMBPRINT}
$tlscertname = (‘<I>’+$tlscert.issuer+'<S>’+$tlscert.subject)
Set-SendConnector -Identity "Outbound to Office 365" -TLSCertificateName $tlscertname
Restart-Service MSExchangeTransport

[/box]

By the time you go back to Queue viewer the queues should have started to empty.

Related Articles, References, Credits, or External Links

NA

26 thoughts on “No Mail Flow On-Premises To/From Office 365”

  4. Hi,

    I have a sophos firewall with mail scan function between the On-premise Exchange en office 365
    The current configuration is Hybride (in migration preparation).

    I have a wildcard certificate wich is assign to bot connectors, but still get the:

    450.4.4.317 Cannot connect to remote server [Message=UntrustedRoot]…

    Reply ↓

  6. An absolute legend! Undoubtedly one of the most authoritative IT portals on the internet. Always straight to the point. Thanks for your massive contribution to the community.

    Reply ↓

  9. Much appreciated! This saved me today when a cert expired that I didn’t even realize we were still using.

    Reply ↓

  14. Thanks. Always appreciate your contributions.

    I ran into a similar issue today after recently replacing a certificate and re-running the HCW. It wasn’t a missing cert assignment, binding or the older cert being present in the cert store.

    In my case, I had to update the “Outbound…” connector in EXO by changing the Security Restrictions settings from “Issued by a trusted certificate authority (CA)” to “Any digital certificate, including self-signed certificates”.

    Not sure if the issue is that we use a wildcard cert but I’ve worked with MS on this previously and this is the setting they recommended to resolve the issue.

    Reply ↓

  15. Thank you for an informative article.
    As it turns out, in our Hybrid configuration, re-running the Hybrid wizard and selecting the new certificate did the trick.

    Reply ↓

  16. Excellent!
    To resolve the issue I was going to mess up the FQDN in the Default Frontend SERVERNAME connector, replacing the internal (.local) fqdn with an external one.

    Reply ↓

  18. Thanks, this solved my issue. I had a new connector working fine in Azure for two weeks, then created a new one for the other Azure DC and whilst mail out was working fine mail in to BOTH Edges suddenly stopped. Validating the mail connector in 365 showed the error and I assigned the cert to both receive connectors and mailflow in worked fine.

    Reply ↓

  19. You just saved my whole week with this one! Thank you. Very little other documentation on this issue. Glad to see you have a donate button.

    Reply ↓

Leave a Reply

Your email address will not be published. Required fields are marked *