I apologise for the rather wordy title here. That title is intentional so hopefully, the search algorithms will land you on this page in case you’re currently experiencing this issue, besides, who says blog titles always need to be short?
THE PROBLEM
Recently I encountered an issue after introducing an Exchange 2019 server into an organisation with a single Exchange 2016 server. After installing Exchange 2019, we found the Exchange 2016 server was unable to send emails to Exchange 2019. However, Exchange 2019 could send emails to Exchange 2016.
So, we’ve identified the issue. Mail flow in one direction is not working, and it appears to be an issue with the older Exchange 2016 server.
THE TESTING
Messages destined to the Exchange 2019 server were stuck in a message queue called “Unknown”. In this case, no error messages were marked with an error, and the queue wasn’t marked with the name of the destination Exchange 2019 server or Active Directory site. After uncovering the issue, I did a simple mail flow test by connecting to a mailbox hosted on Exchange 2016 and sending a message to a mailbox hosted on Exchange 2019. The message was found in this Unknown queue, and I never received a bounce back message. The mailbox was receiving emails from the Exchange 2019 mailbox, so I know that the servers should be able to communicate with each other.
Another test to run between Exchange servers is the “Test-MailFlow” command. For example:
Test-Mailflow Exchange2016Server -TargetMailboxServer Exchange2019Server
The example above tests mail flow from the Exchange 2016 server to the Exchange 2019 server. In our case, this test also failed.
The enabled internet send connector on Exchange 2016 was sending messages to external recipients, so I know the server was not having mail flow in other scenarios. It can receive mail from Exchange 2019 and from the internet, it can send to other Exchange 2016 mailboxes, and it can send to the internet.
Always start with the simplest step, so step one was to restart the transport agent on the 2016 server. After restarting the service, I waited for a few moments however the Unknown queue was still full of messages destined for Exchange 2019 and nothing was delivered to the server.
In the past, I have found misconfigured custom receive connectors to be the cause. So, for example, if a custom receive connector is set to scope to entire subnets, including the IP address of Exchange servers on the subnet, this could cause Exchange to Exchange mail flow issues. However, all connectors were configured correctly, the Exchange 2019 server’s IP address was not included in the list of approved IP addresses on the custom connectors, and the same was true for Exchange 2019 custom receive connectors and the Exchange 2016 IP address. This means the two servers were using (or attempting to) the default receive connectors to receive email from each other, which is how Exchange is designed to work.
THE SOLUTION
After some time, it was brought to my attention that the domain had been upgraded recently. The uptime on the Exchange 2016 server showed it had been running since before the time of the AD upgrade. Legacy domain controllers were removed from the environment prior to the upgrade of the domain.
Finally, we decided to try the old “Have you tried turning it off and on again” trick. The thought being the two major schema changes had occurred recently, the upgrade of the domain, and the extension of Exchange 2019, and sometimes Exchange servers can be prone to hook into older domain controllers. Maybe Exchange 2016 was having a hard time interpreting Exchange 2019 from an email perspective.
We rebooted. We waited. The server came up. Boom! The Unknown message queue was cleared! Emails from Exchange 2016 to Exchange 2019 were delivered!
CONCLUSION
In conclusion, when experiencing multiple changes in an environment, it is best to understand those changes and to make sure you don’t rule out the most obvious troubleshooting steps. And always, always reboot your Exchange servers when domain controllers are removed from the domain and replaced with new domain controllers.
Other words of wisdom can be found from me here.
