In previous articles, I discuss the transport pipeline and how Exchange 2019 routes inbound and outbound messages using Send and Receive Connectors. In this article, I cover how to manage Exchange 2019 Send and Receive Connectors, including moving to new versions of Exchange.

Managing Send Connectors

Exchange Server uses Send Connectors to route messages to other Exchange Server, to other organizations, or to the Internet. Send Connector information in Active Directory. This way all servers in the organization know about the Send Connector’s existence and an Exchange server can make routing decisions. This hasn’t changed in the last 15 years or so.

Send Connectors do not need much management, but there are some properties that need attention. An important property of a Send Connector is the SourceTransportServers property. This is the property that determines which Exchange servers can use the Send Connector. Exchange servers send their messages to the servers listed in the SourceTransportServers property so that those servers can route messages over the Send Connector for further processing, for example to the Internet.

When a new Exchange server is installed in the organization, the new Exchange server can be added to the Send Connector. You can do this using the Exchange Admin Center by navigating to Mail flow → Send Connectors. Select the Send Connector and open its properties. Select Scoping and in the Source Servers section click the + icon to add a new Exchange server.

Send connectors can also be updated with PowerShell. In this example, we add an Exchange server called EXCH2019 to a Send Connector called ‘To Internet’:

Set-SendConnector -Identity "To Internet" -SourceTransportServer @{Add="EXCH2019"}

To remove a server from a Send Connector, run Set-SendConnector and specify the server name. In this example, the server is called EXCH2013:

Set-SendConnector -Identity "To Internet" -SourceTransportServer @{Remove="EXCH2013"}

Make sure that you use the @{Add=”Value”} option to add an Exchange server. If you pass a simple server name, like -SourceTransportServers “EXCH04”, the command overwrites any existing servers with the new value, meaning that the other Exchange servers can no longer route messages via the Send Connector.

A note from the field: make sure that any Exchange server added to a Send Connector is not restricted by a firewall. If it is, it cannot send messages on port 25 and it will queue these messages up to the point the messages are deleted from the queue. Eventually, message loss will occur.

When the Send Connector is configured to use smart hosts and a change occurs in the smart hosts, use the Exchange Admin Console to add or remove a smart host. Open the Exchange Admin Center and navigate to Mail flow → Send Connectors. Select the Send Connector and open its properties. Select Delivery and under the ‘route mail through smart hosts’, use the + icon to add a new smart host.

Smart hosts can also be added using the Exchange Management Shell. This example adds an additional host with the IP address 192.168.10.10 to the Send Connector:

Set-SendConnector -Identity "To Internet" -SmartHosts @{Add="192.168.10.10"}

Similarly, this example removes a smart host from the Send Connector:

Set-SendConnector -Identity "To Internet" -SmartHosts @{Remove="192.168.10.9"}

Managing Receive Connectors

Receive Connectors are configured per server, and when something changes in your mail flow, Receive Connectors need special attention. When adding new Exchange servers, new Receive Connectors are added as well.

My approach is to leave the default Receive Connectors as is and add additional Receive Connectors for special purposes. An SMTP Relay connector is an example of such an additional Receive Connector.

When adding IP addresses of application servers or multifunctional devices to a Relay Connector, you can use the Exchange Admin Center, but when a lot of IP addresses are used it’s much easier to add the set using the Exchange Management Shell.

To get a list of all IP addresses that are allowed to use a Relay Connector use the following PowerShell example:

Get-ReceiveConnector "Relay Connector" | Format-List RemoteIPRanges

It will return something like the following:

RemoteIPRanges : {10.0.0.99, 10.0.0.23, 10.0.0.22, 10.0.0.21, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.11, 10.0.0.12, 10.0. 0.13, 10.0.0.4, 10.0.0.5, 10.0.0.6, 10.0.0.7, 10.0.0.8, 10.0.0.9, 10.0.0.10, 10.0.0.15, 10.0.0.16, 10. 0.0.17, 10.0.0.18, 10.0.0.19, 10.0.0.20, 10.0.0.14}

When adding an IP address, use the @{Add=”IP Address”} option as explained in the Send Connector section to retain any IP addresses already in place. To add an IP address 10.0.0.99 to the Relay Connector, use this PowerShell command as an example:

Set-ReceiveConnector "Relay Connector" -RemoteIPRanges @{Add="10.0.0.99"}

To add multiple IP addresses in one command, add the IP addresses to the Add option, so the command will look like:

Set-ReceiveConnector "Relay Connector" -RemoteIPRanges @{Add="10.0.0.99","10.0.0.100","10.0.0.101"}

Similarly, this PowerShell example removes an IP address from the Receive Connector:

Set-ReceiveConnector "Relay Connector" -RemoteIPRanges @{Remove="10.0.0.99"}

Sometimes the list of IP addresses to add is too long to type out or the IP addresses come from an external source. In an Exchange migration project, I received a list of IP addresses from a parallel project implementing new multifunctional devices in the organization.

To import such a list of IP addresses in a text file called ‘IPAddresses.txt’ to the Relay Connector, use the following PowerShell commands as an example:

$RC = Get-ReceiveConnector "Relay Connector"
Get-Content .\IPAddresses.txt | foreach {$RC.RemoteIPRanges += "$_"}
Set-ReceiveConnector "Relay Connector" -RemoteIPRanges $RC.RemoteIPRanges

When migrating an older Exchange version with a Relay Connector to a newer Exchange version you must migrate the Relay Connector to the new Exchange server as well. Fellow MVP Thomas Stensitzki has written a PowerShell script that copies a Receive Connector from one (old) Exchange server to another (new) Exchange server. You can find more information here.

Personally, I don’t copy an entire Receive Connector from one Exchange server to another server. Instead, I create a new Receive Connector based on the needs of an organization. The RemoteIPRanges property is something that you don’t want to add manually, so I use PowerShell to copy its value to the new Receive Connector. To do this, use these PowerShell commands as an example:

$RemoteIP = Get-ReceiveConnector "Old Relay Connector" | Select RemoteIPRanges
Set-ReceiveConnector -Identity "New Relay Connector" -RemoteIPRanges $RemoteIP

This way you have a new Relay Connector which uses all remote IP addresses from the old Relay Connector.

When the new Exchange server is in use and the old Exchange server is still running, you should check the Receive Connectors on the old Exchange server to see if any application servers or devices still use the old Exchange server. This is logged in the protocol receive logfiles on the Exchange server. Checking these files manually is doable but painful, I use a PowerShell script called SMTP-Review.ps1 which retrieves the IP addresses from all hosts from the protocol receive logfiles. I use the script published by Ali Tajran which you can download here. This script checks if any host is still using a Receive Connector on an (old) Exchange server. If the old Exchange server is not running anymore there’s no option to discover lingering connections to this server, other than waiting for helpdesk calls from users that they cannot relay messages anymore.

Summary

In this article, I showed you some examples of maintenance actions I encounter frequently.

Send and Receive Connectors on an Exchange server do not need daily maintenance, but instead, they need maintenance when something changes in your infrastructure. These changes can be adding or removing the Exchange server, changes in SMTP routing, or moving Relay Connectors.

Microsoft Platform Migration Planning and Consolidation

Simplify migration planning, overcome migration challenges, and finish projects faster while minimizing the costs, risks and disruptions to users.

About the Author

Jaap Wesselius

Jaap is an independent consultant based in The Netherlands. Starting with Exchange 5.0 in 1997, he has been working with Exchange for almost half of his life. After leaving Microsoft as an employee, Jaap started as an independent consultant in 2006, continuing to work with Exchange and later on with Exchange Online. Besides consulting work, Jaap is an author of several books (some coauthoring with Michel de Rooij), blogger, presenter, and these days part-time (kids leaving the house) dad. Besides working with Exchange, Jaap is also a motorcycle enthusiast, owning several motorcycles. For his work in the community, Jaap received the MVP award back in 2007, an award that was constantly re-awarded up to this day, something he is very proud of.

Leave a Reply