I hear from quite a lot of people that break their internal Exchange mail flow by configuring receive connectors and send connectors. This issue comes up fairly regularly, so I figured it’s time to write a post about it, as well as some of the other common issues I see in the field.
For the connector issues, I suspect part of the misunderstanding in this area is that back in the Exchange 2003 era there was the concept of routing groups and routing group connectors. The Exchange 2003 servers within a routing group could talk to each other just fine, but you needed to create routing group connectors to get the servers in two different routing groups to talk to each other.
When you upgraded to Exchange 2007 or 2010, additional routing group connectors were required to facilitate the routing of email messages between the legacy routing groups and the new routing group that held the Exchange 2007/2010 servers. However, beyond that coexistence requirement, the Exchange 2007 or later servers don’t use routing groups and routing group connectors to determine how and where they route internal email. Instead, Exchange 2007 and later uses the Active Directory site topology. There’s a few things administrators can do to control or influence that internal routing, but that is not relevant to the main point of this article, which is that no additional connectors are required for any two Exchange 2007 or later servers to communicate with each other.
As I mentioned earlier, I suspect the Exchange 2003 way of doing things, and the experience during the 2003 to 2007/2010 upgrade, left the impression on some people that they needed to:
- Create a send connector to route or relay email from Server A to Server B, or from Server A to the internet via Server B
- Create a custom receive connector on Server B so that Server A can send email to it
Neither of those is the correct way to establish internal mail flow, and in fact you’re more likely to break internal mail flow if you try either of those things. Exchange 2007, 2010, 2013 and 2016 all come pre-configured with the appropriate connectors for internal mail flow.
But wait, what if you’ve installed your new Exchange server, and found that one or more of the following conditions exists:
- Mail flow doesn’t work between mailboxes on the old and new servers
- Trying to route outbound email via the new server doesn’t work, e.g. email gets stuck in the queue on the old server
- Lots of managed availability probe emails are queuing up on one or both of the servers
In those situations the problem is usually a mis-configuration, a fault, or something interfering with communication between the two servers. Here’s my suggestions on how to investigate the problem.
- Draw a picture. You should be able to identify every network hop between the two servers. That includes network devices like switches, routers, firewalls, WAN accelerators, and so on.
- Remove any firewall restrictions. Firewalling two Exchange servers from each other is not supported. If there’s a firewall, insert an Any/Any rule for Exchange servers. Windows Firewall is okay, because Exchange inserts the required rules during setup. In fact, don’t disable the Windows Firewall on Exchange servers.
- Remove any WAN compression/accelerator configurations. In my experience these tend to break server-to-server authentication. A pass-through rule for Exchange IPs to talk to each other without interference should be configured.
- Remove any host-based security products that interfere with SMTP communications. Many such programs default to blocking SMTP to mitigate the risk of mass-mailing worms. Obviously that will kill SMTP for Exchange servers as well. Some of the products are also very invasive, and keep working even if you “disable” them. A full uninstall may be required if you can’t work out a configuration that doesn’t interfere with SMTP.
- If you’ve configured a relay connector on your Exchange server, that may be causing the issue. The configuration of a relay connector isn’t suitable for Exchange server-to-server communications. Configure the SMTP banner on your receive connectors to match the connector name (use Jeff Guillet’s tip here). Telnet from one Exchange server to another. If you see the relay connector name in the SMTP banner, then the issue is likely that the IP address of the Exchange server (or an IP range that includes the Exchange server) has been added to the remote IP range on the relay connector. It will need to be removed for server-to-server communication to work.
This article There’s No Need to Create Connectors for Internal Exchange Server Mail Flow is © 2016 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
