This article applies to:
Exchange 2010, Exchange 2016, SMTP
In this article I will show an example of Exchange 2010 to Exchange 2016 mail flow trobleshooting, based on a recent customer support case.
PROBLEM
The customer is in a process of migrating from Exchange 2010 to Exchange 2016. The environment consists of 2 Exchange 2010 servers and 2 Exchange 2016 servers. All 4 Exchange Servers are located in the same Active Directory site. As a part of the migration some of the mailboxes are moved from Exchange 2010 to Exchange 2016.
The customer now reports a problem that users with mailboxes on Exchange 2010, are not able to send emails to users with mailboxes on Exchange 2016. Sending of emails in the opposite direction, from Exchange 2016 to Exchange 2010, is working fine.
ANALYSIS
As a first step, we will check the queues, in order to determine where the messages got stuck. For this you can use the following PowerShell command:
This will give us a list of all email queus from all Exchange servers, that are not empty.
As you can see the top 2 queues are in status Retry which shows us that the Exchange 2010 servers have correctly routed the e-mails towards Exchange 2016. But for some reason those are not accepted on the Exchange 2016 side.
If we further expand our PowerShell comannd with Format-List at the end, we will also be able to see the exact error message.
Under LastError we can see the exact SMTP error message:
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.
By default, Exchange server 2016 receives email messages from other Exchange server via the SMTP connector named Default Frontend <Severname>. This connector is configured to allow connections from Exchange Servers and usage of Exchange Authentication method for authentication. As we can see here, this is configured correctly.
So where is the catch then? Why can’t the Exchange 2010 servers connect to Exchange 2016 by using Exchange authentication?
CAUSE
This indicates that the connection from Exchange 2010 servers lands with another connector on the Exchange 2016 server and not the default one. This would occur if you have additional custom connectors on your Exchange 2016 server, and one of them has the IP addresses of the Exchange 2010 servers configured. In such case, that custom connector would by used instead of the Default Connector.
And after investigation of other connectors on the Exchange 2016 machines, exaclty this turns out to be the case: both Exchange 2016 servers have a Relay connector where IPs of the Exchange 2010 servers are listed.
And, if we look at the configuration of the Relay connectors on our Exchange 2016 Servers, we can see that Exchange Authentication protocol is not configured, neither are Exchange Servers allowed to connect. This explains the error message. And this also explains why failover was not possible (both Exchange 2016 servers were configured in this way).
SOLUTION
Solution here is to simply remove the IP address of the Exchange 2010 servers from the Relay connector on the Exchange 2016 servers.
On the next queue retry Exchange 2010 will establish connection correctly via Default Frontend connector and messages will be delivered normally.
In case you don’t want to wait, you can force the queue retry manually by using the Retry-Queue PowerShell command.
He lives in Zurich, Switzerland and is a dedicated specialist, with 30 years of professional work experience in IT.
Before starting Exchangemaster GmbH he worked as a system engineer and project manager with customers of all sizes and across many industries: From small ISV startups and a NGO humanitarian organizations up to largest international corporations like Stryker, Swisscom, British Telecom and Nyrstar.
He spent his entire career delivering Microsoft based infrastructure solutions with main focus on Active Directory and Exchange. During those years, he collected a valuable work experience on 8 Exchange generations (2019, 2016, 2013, 2010, 2007, 2003, 2000 and 5.5) and has delivered services to a user base of more than 3.2 million mailboxes in on-premise, hybrid and Office 365 deployments.
Beside working on customer projects, he is a regular speaker and expert at Microsoft conferences and user groups. As a Microsoft Certified Trainer he also teaches Microsoft Official Curriculum courses to technical professionals around Europe.
For his work he has received numerous awards.
In 2005 he was the first member to be elected into the MCP Hall of Fame by Windows IT Pro Magazine readers choice (as 1 of 6 worldwide).
From 2005-2017, Dejan has been awarded by Microsoft Corporation with the yearly Microsoft Most Valuable Professional award in area of Exchange for 12 years in a row (one of approximately 100 worldwide and, at the time, the only 1 such in Switzerland).
- FAQ 000181 – How to enable mailbox auditing using PowerShell - August 1, 2023
- FAQ 000180 – How to set Microsoft Teams Room Device to use internal NTP server - December 15, 2021
- FAQ 000178 – How to change the sender and reply E-mail address in Microsoft Bookings - January 11, 2021
Thank you for sharing, that was my issue.
that was my issue also , thanks for this article
Thanks – my issue as well.
Thanks, our customer had the whole server range within the relay, we excluded both Exchange IPs that helped 🙂
Had this issue, this article heled a lot