In a recent article I discussed the requirement to retain an on-premises Exchange Server after migrating to Office 365 when directory synchronization is being used. That article addresses a very frequently asked question in online forums. However, a less frequently discussed scenario is the safe decommissioning of on-premises Exchange Server when directory sync is not being used.
There's a few ways to end up in a post-migration scenario where Exchange can safely be removed:
- You used a cutover migration to Office 365, and have no plans or business requirement to later implement directory synchronization
- You used a staged migration to Office 365, and have turned off directory synchronization
- You used a hybrid migration to Office 365, and you've removed the hybrid configuration and have turned off directory synchronization
The common element of those three scenarios is that directory synchronization is not being used. If you still plan to use directory synchronization, your server needs to stay.
Assuming it's safe to get rid of Exchange, the biggest mistake people make at this point is just turning off the Exchange Server. Some people do it because they're unaware of proper removal steps, and others do it because they might want to turn it back on some day to recover some data from it.
Exchange Server does need to be properly uninstalled from your environment due to the integration it has with Active Directory. You might think that it doesn't matter, your email is running in the cloud now anyway, but one day in the future you might have a need to reintroduce Exchange to the environment, and the existence of an old server object in AD is going to cause you problems. On one project I worked on, the customer needed to off-board from Office 365 to on-premises Exchange. The consultants who had previously migrated the customer to Office 365 had just turned off the old Exchange 2007 server. When we came along to install Exchange 2013, we ran into problems with the old server object that ultimately cost more time (and money) than a proper removal would have in the first place.
To correctly remove Exchange you need to uninstall the Exchange Server software from the server it is running on. At its simplest, that means going in to Add/Remove Programs and hitting the Uninstall button for Exchange. But there are some preparation steps involved.
To begin with, Microsoft does publish some information about uninstalling Exchange.
- How and When to Decommission your On-Premises Exchange Servers in a Hybrid Deployment (covers multiple scenarios)
- Modify or Remove Exchange 2010
- Decommissioning Legacy Exchange Servers (PFE blog post written for 2007 but many concepts still apply to 2010 and later)
- Remove the Last Legacy Server from an Exchange 2010 Organization (covers removal of 2003 and 2007)
- How to Remove the Last Legacy Exchange Server from an Organization (covers removal of 2000 and 2003 – I really hope you don't need this one!)
If you're unfamiliar with removal of Exchange servers you should read through those articles. You'll notice they repeat the same concepts, and even though none of them cover the topic in full they all give you an idea of what's involved. I've also written some tutorials for removing Exchange servers after on-premises migrations.
If you haven't completed any of the preparation steps to allow Exchange to be uninstalled, you'll be blocked and a message will explain what you still need to do (e.g. disable remaining mailboxes, remove connectors). Setup can't detect all of the dependencies though. For example, if your on-premises Exchange server is still performing SMTP relay for devices on your network, that won't stop it from being uninstalled. You will still need to inspect your transport or protocol logs to determine when the server is no longer being used for that purpose.
The last point I want to address is the data recovery scenario. This usually comes up after a cutover migration when the customer is not 100% confident that the migration successfully moved all of the mailbox contents. As a “just in case” measure, the on-premises server is turned off and kept in place for potential data restores in future. Proper removal of Exchange would conflict with this goal, so the proper removal is never performed.
I don't think this is a good long term strategy, because the server is usually forgotten about (see my earlier notes about future deployment blockers due to the legacy Exchange server still existing in AD). Perhaps for a short time it is acceptable, but I think you should always aim to remove Exchange correctly. If you want to retain just the EDB files for restores, you can do makes copies of them prior to uninstalling Exchange and then use a tool like Veeam Explorer for Exchange to extract data from them later.
For recovery from tape or other backup media, you can spin up a temporary virtual environment to perform the restore, which also isolates the restore from your production environment which is a good idea in case of operator error.
Hopefully this article helps clarify the need to correctly remove Exchange from an environment when it is no longer needed after migrating to Office 365. If you have any questions please feel free to ask in the comments below.
The post How to Decommission an Exchange Server After Office 365 Migration appeared first on Practical 365.
