Updated Migration Advice: Remove the last Exchange Server?

The last time I published articles on the topic of email migration was in the long, long ago: in the before time. Yes, before pandemics and novel coronaviruses, but also before we had the option to remove the last Exchange server. Some have asked me if I would change any of my instructions or advice for migrating from Exchange on-premises to Exchange Online in light of these recent developments.

My short answer is: it depends, and even then, only if you want to.

For the longer version, read on.

Do you really need hybrid?

The first thing to note is that the new process for removing the last Exchange server is only going to be applicable to a minority of SMB tenants who require long-term hybrid identities with directory synchronization. Why? Because the vast majority of SMB’s should be focused on removing traditional AD anyway, and migrating toward cloud-only identities in Azure AD (as many have already done).

When someone says they absolutely cannot get rid of the local AD, that usually means there is either some legacy thinking, or a legacy Line of Business application standing in your way. This blog has often dedicated articles to dismantling the barriers related to the former problem, but when it comes to the latter (LOB apps), how should we address them?*

First, determine if there are actually dependencies here or not. For example, there may be web-and-mobile friendly alternative apps of which the stakeholders are unaware. If not, and you have to stick with the existing app, next you must ask: Does the application rely on Active Directory or Exchange mail attributes in any way? If so, you may have a legitimate reason to keep these systems around, if not, then proceed accordingly. Most of the time, the perception is different than the reality: most apps do not actually have a hard requirement for AD.

In some circumstances (where supported), legacy apps can be hosted in a virtual desktop environment by a service provider, or in Azure, leveraging Azure AD DS or a standalone pair of small-sized VM’s promoted as DC’s, along with Azure Virtual Desktop or similar. And of course, there is always the old refresh your server on-premises if none of these other options appeal to you.

Assuming you have exhausted your other choices (e.g. drop-and-shop) and you’re still stuck with a legacy AD (either on-prem or in the cloud), then your next step is to decide how important it is for you to keep the same credentials for this legacy app as you have for say, your email and cloud-based applications. Very important? Then consider keeping a hybrid connection. Not so important? Perhaps it is time to isolate this app from the rest of your (more modern) environment.

And what about legacy file shares?

Another place people get stuck is on larger-sized file migrations, particularly where there are lots of really large files like CAD drawings, etc. In this case you have similar choices to make. Just think of this requirement no differently than other legacy LOB apps.

How much of this storage is “current” and how much is just archival and can be pushed to an alternative cloud platform such as Azure Files or even a third-party cloud storage solution? Or, if you are going to elect to keep a local file system, will it be Windows-based and connected to the same identity/credentials as your email and other cloud apps? Or should you isolate this on a separate, purpose-driven system or alternative solution?

These choices will be up to you. Again I want to point out that this a niche case, and that the demand for this kind of solution is going to be an exception, not the rule. Most SMB’s with typical information workers can simply move files to OneDrive/SPO/Teams, and/or Dropbox, Box, Citrix ShareFile, or similar. In other words, cloud-based apps that can be connected to Azure AD for SSO and better security.

The hybrid path (only if you need to or want to)

Most of the time, small organizations are coming from older systems, such as Windows Small Business Server 2011, or Windows Server Standard 2008R2, 2012, 2012R2, or 2016, with Exchange Server 2010, 2013 or 2016 installed on top of one of those systems. If you are coming from anything older than that, then I would recommend a third-party tool to assist in the migration process. Otherwise, hybrid or “remove move” migrations will be the best migration option for you (or you can still use third-party tools if you prefer).

Once you are done with the migration, then you can either keep an Exchange 2016 or 2019 server around for hybrid purposes (like we have always done), or, now, you can choose to get rid of it. But for this option you will need to have Exchange Server 2019: so if you came from say 2016, add a 2019 server and run the latest cumulative update before executing the process to remove the 2016 as well as the last 2019 server. Remember that even after you “remove” the last Exchange server (really you’re just shutting it off forever), you are still dependent on the local AD for your identities and specifically for all the mail related attributes: the source of authority is still on-premises, and the Azure AD Connect synchronization must still remain in place just as before (so not that much has changed, really).

Review this Microsoft docs article for more details on how this “Exchange Server Free” hybrid environment looks in practice. Two main differences:

1. You will no longer have to maintain a server with Exchange installed on it for hybrid management purposes
2. You will no longer have the Exchange management web UI, and instead you will only have some PowerShell cmdlets with which to manage the attributes

Actually, Steve Goodman over at Practical 365 has provided a graphical web-based tool for managing the Exchange attributes after removing the last 2019 server. See this article for more details.

Okay, so the proper migration steps would be:

1. Make sure your source environment has latest available cumulative updates
2. Add your domain name(s) to Microsoft 365, verify (add TXT) but do not cut over MX yet
3. Configure Azure AD Connect to sync identities & on-premises passwords to the cloud
4. Run the Hybrid Configuration Wizard (HCW) / alt: third-party tool setup
5. Create your remote move migration batches / alt: third-party migration batch setup
6. Migrate public folder data (if applicable, usually try to replace w/ Groups, Teams, etc. instead)
7. Finalize your migration batches
8. Cut over MX records, SMTP relays, etc.
9. New post-migration and clean-up tasks:
   1. If needed, add or upgrade to Exchange server 2019 (latest CU)
      • Remove older Exchange servers as applicable
   2. Follow the process to shutdown the last Exchange 2019 server permanently (optional)
      • Moving forward, update processes to manipulate mail attributes using the new cmdlets
   3. Consider configuring Hybrid Azure AD Join for your PC’s and configure device-based Conditional Access to improve security

Similar to how we have always done things, with a few extra items tagged onto the end.

Cloud-only identity (the preferred path)

As always, I encourage you to strongly consider severing your ties to that old beast known as Active Directory. Most folks can get by just fine (better actually) without it. In this case your migration looks very similar to the above, except that your post-migration tasks will include a different subset of items:

1. Remove Azure AD Connect + Exchange hybrid
2. Move shared files & other apps to the cloud or cloud-based alternatives (and setup SSO to Azure AD wherever possible)
3. Join PCs to Azure AD and configure device-based Conditional Access
4. Move DHCP from AD to firewall or router
5. Shut down the AD domain forever

In this configuration you are in the best possible position to implement additional security & compliance capabilities, and take full advantage of the other goodness the cloud has to offer, without carrying any of the baggage of days past.

I really do think that the hybrid path appeals to a dwindling subset of SMB organizations: the vast, vast majority of you should be looking to cut ties and go toward cloud-only identities, even if it means managing a separate credential set/security boundary for a legacy app in some cases (especially if it is going to be temporary). But, if you are one of those “special case” customers, we now have the option to maintain a hybrid environment, without necessarily keeping that old Exchange server around. Some may still prefer to keep the Exchange server, and that’s totally fine as well.

If I were forced to keep a legacy AD around, I personally would choose to kill the directory synchronization and just maintain a separate security boundary for that application specifically. But that is due to my own preferences and risk tolerances. You may come to a different conclusion. I won’t shame you for it, as everyone has a right to be wrong. At least now you know how to do the wrong thing the right way.

:)