Exchange SMTP relaying migration

Question

Hello everyone,

I’m currently facing a situation regarding SMTP relaying with our last Exchange Server, whose only purpose is management and relaying.  

All mailboxes are on Exchange Online.

The server is running on Windows Server 2019 with Exchange 2019 CU12 installed.

Naturally, we need to update this to the latest CU. However, since SMTP relaying is a critical part of our infrastructure, I cannot schedule any downtime. Furthermore, our CIO has requested that we make the relaying setup redundant to eliminate the Single Point of Failure.

With this in mind, we devised a plan to migrate to a new pair of Exchange Servers.

We’ve installed two new Windows Server 2022 servers and installed Exchange Server 2019 CU14 on them. No connectors or additional configurations have been set up yet, and they reside in the same network segment as the current production server.

We were planning to set up a sort of testing environment before rerouting SMTP traffic to the new servers. However, our plans were unexpectedly interrupted.

Approximately an hour after the installation of the two new CU14 servers was completed, we began receiving complaints that some relayed emails were not being received by certain users—although it seemed to work fine for others.

We immediately suspected that the new servers were somehow interfering with the existing SMTP relay, even though we hadn’t configured anything on them yet.

To resolve this, I stopped the Transport Service on both new servers, and everything appears to be working again without any issues.

Additional information:  

We currently route SMTP traffic to the production server via a Fortinet Load Balancer setup, where the Exchange PROD server is the only member server. Therefore, we did not expect the new servers to receive anything.

The Problem:

What steps can we take to ensure that SMTP traffic flows only through the production server and not through the new servers for now?  

We would like to restart the Transport Service on the new servers to begin SMTP relay testing using a separate DNS entry and Fortinet LB setup running in parallel to production.

The plan is to conduct testing this way, and after successful completion, switch routing to the new Load Balancer setup to go live with the new servers.Hello everyone,

I’m currently facing a situation regarding SMTP relaying with our last Exchange Server, whose only purpose is management and relaying.  

All mailboxes are on Exchange Online.

The server is running on Windows Server 2019 with Exchange 2019 CU12 installed.

Naturally, we need to update this to the latest CU. However, since SMTP relaying is a critical part of our infrastructure, I cannot schedule any downtime. Furthermore, our CIO has requested that we make the relaying setup redundant to eliminate the Single Point of Failure.

With this in mind, we devised a plan to migrate to a new pair of Exchange Servers.

We’ve installed two new Windows Server 2022 servers and installed Exchange Server 2019 CU14 on them. No connectors or additional configurations have been set up yet, and they reside in the same network segment as the current production server.

We were planning to set up a sort of testing environment before rerouting SMTP traffic to the new servers. However, our plans were unexpectedly interrupted.

Approximately an hour after the installation of the two new CU14 servers was completed, we began receiving complaints that some relayed emails were not being received by certain users—although it seemed to work fine for others.

We immediately suspected that the new servers were somehow interfering with the existing SMTP relay, even though we hadn’t configured anything on them yet.

To resolve this, I stopped the Transport Service on both new servers, and everything appears to be working again without any issues.

Additional information:  

We currently route SMTP traffic to the production server via a Fortinet Load Balancer setup, where the Exchange PROD server is the only member server. Therefore, we did not expect the new servers to receive anything.

The Problem:

What steps can we take to ensure that SMTP traffic flows only through the production server and not through the new servers for now?  

We would like to restart the Transport Service on the new servers to begin SMTP relay testing using a separate DNS entry and Fortinet LB setup running in parallel to production.

The plan is to conduct testing this way, and after successful completion, switch routing to the new Load Balancer setup to go live with the new servers.

Answer 1

Hi, @E J

With your description, you can try using some of the following steps to ensure that the SMTP traffic goes only through the production server and not through the new server:

1.Ensure that Fortinet Load Balancer routes traffic only to the existing production Exchange server and that the new server is not part of any load balancing pool for SMTP traffic. Double-check all policies and rules to confirm this configuration.

2.Ensure that the new server is not configured as an MX record in DNS. Update the internal and external DNS to point only to the IP address of the old server. Remove any DNS entries that may inadvertently point to the new server.

3.To test the new server in isolation, configure a separate DNS entry and update the Fortinet Load Balancer to handle this new setting. For example: Create a new DNS entry that points to the Fortinet Load Balancer (for example, “smtp-test.yourdomain.com”). Configure the Fortinet Load Balancer to route traffic only from “smtp-test.yourdomain.com” to the new Exchange server.

4.After confirming that the above steps have been configured correctly, you can perform a full test after restarting the transport service on the new Exchange server to ensure that the new server is handling the SMTP relay traffic correctly.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".