No Mail Flow On-Premises To/From Office 365

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

Message=SubjectMismatch Error

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;

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

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;

Get-ExchangeCertificate  

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

$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

Validate connector Office365 Fails

Now test validation again from Office 365 portal.

Sucessfully Validate Office365 Fails

Check The Office On-Premises Mail Flow

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

Send Connector to Office 365 Fails

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,

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

Send Connector to Office 365 TLS Name

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

Related Articles, References, Credits, or External Links

NA

Author: PeteLong

Share This Post On

24 Comments

  1. Thanks man. This really helped. You are awesome!

    Post a Reply
    • Great! Saved my day.

      Post a Reply
    • This worked like a charm. Thank you so much.

      Post a Reply
  2. Mate – You sir are a legend 🙂

    Post a Reply
  3. brilliant, many thanks buddy!

    Post a Reply
  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]…

    Post a Reply
  5. Simply amazing tech articles. This one saved me hours!

    Post a 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.

    Post a Reply
  7. Funcionó!!! Muchas gracias

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

    Post a Reply
  9. Pete – your articles are the best in e world man !!!

    Post a Reply
  10. Great! Saved my day.

    Thank you very much

    Post a Reply
  11. Thankyou, this worked a treat

    Post a Reply
  12. You are life saver. after two days found your article work charm

    Post a Reply
  13. 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.

    Post a Reply
  14. 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.

    Post a Reply
  15. 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.

    Post a Reply
  16. 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.

    Post a Reply
    • Hi Matt – Thats great news, glad I’m still managing to help somebody!

      Post a Reply

Leave a Reply to Giuliano Cancel reply

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