The mail flow cutover during an Exchange 2016 migration usually needs to be considered for three scenarios:
- Inbound internet mail flow
- Outbound internet mail flow
- Internal application relay
For some organizations there’ll be additional scenarios to consider as well, such as secure mail flow with partners. But for most customers, the above three points will be applicable. Let’s take a look at each of them in turn.
Inbound Internet Mail Flow
Inbound mail flow is controlled by the MX records in your DNS zone. The MX records for your domain will most likely point to either:
- An externally hosted email security service, that scans email for viruses and spam and then routes the clean mail to your Exchange server by making an SMTP connection to your external router or firewall, which NATs the connection to an internal Exchange server.
- A public IP address on your external router or firewall that NATs the SMTP connections to an internally hosted email security server or appliance, where email is scanned and then routed to your internal Exchange servers.
- A public IP address on your external router or firewall that NATs the SMTP connections directly to your Exchange servers.
Your specific email routing topology should have been discovered during the planning stages of your project. So, depending on your scenario, the inbound internet mail flow cutover actions will be different.
- For an externally hosted email security service, the change usually involves updating your firewall configuration so that the SMTP connections are NATed to your new Exchange 2016 server. The MX records usually do not change in this scenario.
- For internal email security servers or appliances, the MX are also not changed, and the cutover is performed by updating the configuration of the email security server to route the mail to the new Exchange 2016 server.
- For the third scenario, which applies to Not Real University, the change is also performed by updating the firewall NAT rule, but there is also Edge Transport servers to consider, which I’ll cover in more detail in a moment.
You can also read more about managing MX records and changes to inbound mail flow routing here.
For the Not Real University scenario, an Exchange 2013 Edge Transport server is running in the perimeter network to handle inbound mail flow. The new Exchange 2016 Mailbox server has been deployed in the organization, but the Edge Subscription has not been updated yet, so no direct mail flow is occurring between the Exchange 2016 server and the Exchange 2013 Edge Transport server. All inbound and outbound mail flow still goes via the Exchange 2010 and 2013 servers.
A new Exchange 2016 Edge Transport server is deployed in the perimeter network and is ready to be used. Until it has an Edge Subscription created, it will not yet participate in mail flow.
On the Exchange 2016 Edge Transport server a new Edge Subscription file is created.
[PS] C:\Admin>New-EdgeSubscription -FileName C:\Admin\Edge2016.xml
A DNS record is added to the internal DNS zone so that the Exchange servers in the organization can resolve the new Edge Transport server’s name, which is NREDGE16.notrealuniversity.com.
Edge Transport servers are subscribed to a site, not to individual servers. The name of the Active Directory site that hosts the internal Exchange servers is “Default-First-Site-Name”.
[PS] C:\Admin>Get-ADSite Name HubSiteEnabled ---- -------------- Default-First-Site-Name False
So, after copying the XML file generated on the Edge Transport server to the Exchange 2016 Mailbox server, the command to run is:
[PS] C:\Admin>New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\Admin\Edge2016.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site-Name" Name Site Domain ---- ---- ------ NREDGE16 notrealuniversity... notrealuniversity... WARNING: EdgeSync requires that the Mailbox servers in Active Directory site Default-First-Site-Name be able to resolve the IP address for NREDGE16.notrealuniversity.com and be able to connect to that host on port 50636.
When they’re ready to make the change, Not Real University updates the firewall NAT rule so that inbound SMTP connections go to the Exchange 2016 Edge Transport server instead of the Exchange 2013 Edge Transport server. By sending test messages from an external mailbox, confirming they are received by the internal mailbox, and analyzing message headers just to be sure, they can validate that internal mail flow is now working through the new Exchange 2016 Edge Transport server. At this stage they consider it safe to remove the Edge Subscription for the Exchange 2013 Edge Transport server, and then decommission the server itself.
[PS] C:\>Get-EdgeSubscription -Identity NREDGE13 Name Site Domain ---- ---- ------ NREDGE13 notrealuniversity... notrealuniversity... [PS] C:\>Remove-EdgeSubscription -Identity NREDGE13
Outbound Internet Mail Flow
As with inbound mail flow, there are often multiple scenarios that could be in place for outbound mail flow from an Exchange organization. Outbound mail flow is controlled by send connectors, or if Edge Transport servers are used then outbound mail flow is established by an Edge Subscription. There may also be a combination of both in place for complex mail routing scenarios.
If send connectors are being used, the cutover of outbound mail flow is usually as simple as updating the source transport servers in the properties of the existing send connector. You can read more about managing send connectors here. The new Exchange 2016 server will need outbound SMTP access through the firewall to be able to send the outbound emails.
For Not Real University, the Edge Transport server is used for outbound mail flow. Because the Edge Subscription has been established for the Exchange 2016 Edge Transport server, and the Exchange 2013 Edge Subscription has been removed, outbound mail flow will now be sent via the Exchange 2016 Edge Transport server.
Internal Application Relay
Internal devices and applications that require SMTP to send emails and notifications can make use of the receive connectors on Exchange servers. For an existing environment like Not Real University, an application relay connector will be hosted by either the Exchange 2010 or Exchange 2013 server for this purpose. Since those servers will be decommissioned, the relay functionality needs to be migrated to the Exchange 2016 server.
The process is basically as simple as:
- Creating a new SMTP relay connector on the Exchange 2016 Mailbox server, and include the same remote IP addresses and ranges that exist on the connector hosted by Exchange 2010 or 2013.
- Updating the DNS alias that internal devices and applications use for their SMTP connections.
To test the change before updating DNS, which impacts all devices and applications using that alias, you can add another DNS alias (e.g. “smtptest.notrealuniversity.com”) and point that to the Exchange 2016 Mailbox server IP address, then update a few test devices or applications to use that alias for a few days or weeks until you’re satisfied that it is working correctly. You can then cutover the remaining devices and applications by updating the mail DNS alias for SMTP.
If any devices are using the old server’s real name or IP address for SMTP, they will continue to do so and won’t move with the DNS alias to begin using Exchange 2016 for SMTP relay. This will be evident in the protocol logs of the receive connector on the old servers. You can deal with that now, or deal with it when the time comes to decommission the old servers. However, it it’s not dealt with at all, then you can expect those devices and applications to start failing to send their email notifications when the old servers are decommissioned.
In the next part of this article series, we’ll begin the mailbox migration to Exchange Server 2016.
