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, if 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.
[adrotate banner=”51″]
hi paul
when i migrate one mailbox from old exchange 2010 to new exchange 2016 my client can send email but it can receive email from another person in internal domain ? what can i do ??
Hi Paul ,
Thank you for the great articles you do post , I need some help, I can create edge 2016 server and subscribe it to the AD site, but how can I add one additional Edge Server for redundancy could you please share the steps , in my exchange 2010 environment I have two Mailbox Servers and for HUB/CAS Servers I have two servers which is using NLB and a virtual name x.domain.com how can I achieve the same for my new exchange 2016 environment?
Hi Paul
Love your work, my colleagues and I follow your site and your articles all the time.
Is there any reason that I wouldn’t do transport cutover before cas cutover if I could verify all namespaces associated with smtp mailflow didn’t overlap with cas namespaces.
Have done mnu different flavors of exchange migration over the years, Always doing CAS first. However a current customer has asked to do smtp cutover first.
Thanks
Paul, just got done last night following migrating to 2016 from 2013.
Thank you so much for the series of articles!
Exchange 2013 not decommisioned yet, but mailboxes moved (except for handful of unused ones)
But Exchange 2013 still touches some emails for some reason.
I’ve got two Exchange boxes: 2013 and 2016. No perimeter servers. I am running Symantec Mail Security For Microsoft Exchange and that is on both servers, 2013 and 2016.
Here’s a (names changed) copy of the headers from an email:
Received: from Exchange2013.mycool.com (10.10.1.38) by
Exchange16.mycool.com (10.10.1.58) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.1.1034.26 via Mailbox Transport; Mon, 23 Oct 2017 07:34:26 -0500
Received: from Exchange2016.mycool.com (10.10.1.58) by
Exchange2013.mycool.org (10.10.1.38) with Microsoft SMTP Server (TLS) id
15.0.1293.2; Mon, 23 Oct 2017 07:34:25 -0500
Received: from bounce.aimarketinggrp.com (192.28.148.235) by smtp.mycool.com
(10.10.1.58) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via
Frontend Transport; Mon, 23 Oct 2017 07:34:25 -0500
Is it normal for Exchange2016 to toss email over to Exchange 2013 for no real reason? Some kind of load balancing or something going on?
Thank you again!
I can’t tell from that info why it’s routing to the 2013 server. Looks like inbound mail from an external sender. Is SMTP forwarding from your firewall to the 2013 server or to the 2016 server?
SMTP is forwarding to the 2016 server. (I see some typos in my modified log but the IPs are correct).
I’ve powered down 2013 and mail is flowing well.
I do see some 3008 events that [Owa] failed to refresh mailbox server for database in resource forest.mycool.com and it goes on “Could not connect to Exchange2013.mycool.com” which makes sense as it’s shut down.
The only issue on the client side is a sporadic issue with search on Outlook 2016 – “We’re having trouble fetching results from the server” that just appeared with the 2013 shutdown. I’ve checked and my mailbox indexes on 2016 are all healthy.
I have this same issue where, after migrating from 2013 to 2016, it seems that when receiving email from an external client (gmail in this instance), the email is received by my smart host, then forwarded as expected to my 2016 server. It is then forwarded back to my 2013 server (which contains no mailboxes anymore), then back to my 2016 server and delivered to mailbox.
When sending to external client, same issue. Exchange 2013 is also still being utilized for mail flow and I don’t know why. Internal email is being used by Exchange 2016 only as far as I can tell.
Paul, I’ve followed your guide on Plurasight with my subscription, but this issue isn’t addressed. Any ideas where to look? I’m just not understanding why 2013 is still involved in mail flow at this point when all DNS records have been changed to 2016, smart host is forwarding to 2016, MX internally was updated to reflect my 2016 server, etc.
Mail is flowing, but why is it using 2013 for external based or external originating emails?
That sounds normal to me. Exchange is making use of all available transport services in the site.
There’s a diagram here that is a good reference:
https://technet.microsoft.com/en-us/library/aa996349(v=exchg.160).aspx
Also some scenarios like what happens to inbound mail. Note that the front end transport service can proxy the connection to *any* available transport service in the site, it doesn’t necessarily need to be the server hosting the mailbox.
There’s some more detail on routing here:
https://technet.microsoft.com/en-us/library/aa998825(v=exchg.160).aspx
Read the section “Routing in the Front End Transport service on Mailbox servers” to understand the front end transport service behaviour. Also read the section on what constitutes a delivery group.
For outbound, you might be able to change the behaviour by taking the 2013 server out of the source server list for the send connector.
We are attempting to migrate to 2016 to 2010. We have a 3rd-party security appliance doing spam filtering and such, which is what our 2010 Send Connectors are directed to send through. We have a 2010 Client Access server in our DMZ for OWA purposes. We are wanting to replicate this setup in 2016.
If the 2016 Edge server is only providing OWA access, do we need an Edge Subscription?
Running your CAS in the DMZ is not a supported scenario. If you’ve got some DMZ requirements for incoming client traffic then you should look at a reverse proxy or load balancer like an F5, Netscaler, Kemp, etc.
The Edge Transport server is involved in mail flow only. It doesn’t handle any client connectivity for OWA or other client access services.
At what point in the process of upgrading Exchange 2010 using this guide (no transport server) and Exchange 2016 co-existance…is there danger of any mail downtime? Wouldn’t you be able to test Exchange 2016 connectivity before anyone is migrated to it? I assume there could be some downtime if something wasn’t configured on correctly on 2016 after changing the public NAT to point to the 2016 server, but I’m assuming that could be avoided by testing connectivity with 2016 before making that change? Thanks for all your work on this guide.
You can test the mail flow by using telnet. An unauthenticated telnet connection is basically the same as an unauthenticated SMTP connection from the internet.
An Exchange 2016 server is configured by default to accept inbound internet email. You would only break it if you messed with the configuration of the receive connectors that Exchange setup creates, or if you created a custom connector that conflicted with them.
All change carries risk though. I usually do the mail flow cutovers after hours for customers who are nervous about the potential impact. You can quickly test the change and roll back if necessary.
Paul, can you please share the Visio diagrams you used for this Exchange 2016 series?
Probably not. They files aren’t really in a shareable condition.
© by Exchangeserverpro.com 🙂