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.
For further advice, check out Email Migration to Office 365 – a comprehensive white paper exploring hidden challenges and how to overcome them.
We are about to decomission our on-premises Exchange server after moving all our mailboxes to Office 365.
We have quite lot of devices and applications are configured with smtp.mydomain.com relay address.
So how do i keep the same name and relay emails without changing?
Use DNS alias and open correct firewall ports to M365EXo SMTP.office365.com over TCP port 587
Can you please share your thoughts on a scenario where we want to keep some of the exchange servers on premise.
I mean if we have 2 or 3 exchange servers in a DAG configuration and we want to keep only one exchange server and get rid of other servers databases etc. what would be the configuration sequence for that scenario. Thanks.
You started this thread with a situation where you are not using Directory Sync. According to Microsoft, any form of migration “MUST” use directory sync. I do know that I was able to migrate a few test users in a staged migration from an on-prem 2007 Exchange server and not use directory sync, but Microsoft demanded I use directory sync.
This caused more issues than it solved and basically has allowed Microsoft to hijack my AD and has made it impossible to viably remove the old Exchange server which was the entire goal in the first place. Why, in the name of all that is holy, would I want to migrate from an old Exchange server to Office 365 and be forced to keep the old server. What is the purpose of that? This just reinforces my feeling that Microsoft is just the most despicable company in the world. None of the documentation I read in preparing for this migration ever mentioned that migrations could be completed without DirSync not that using DirSync would lock the old server into existing in perpetuity. It appears that to properly decommission and remove the legacy Exchange server DirSync will need to be removed and that opens a whole ‘nother can o’ worms.
Thanks for sharing this article!
From what I have understood, we can only decommission Exchange if AD Connect is also uninstalled.
In my case, the customer has Exchange 2010 SP3, and my only challenge is answering their question, “What was the purpose or point of moving to cloud if I still keep my legacy exchange?”
It would have been okay if they have Exchange 2013 or later versions.
Ted (Pardon me for being noob)
I am looking for an answer to a scenario/question that your doc’s dont address. Removing the one and only Exchange 2003 server after users migrated to O365 without any directory integration whatsoever. No migration to newer Exchange onsite first, just went direct to O365 without any AD integration.
I am assuming I can just de-install the Exchange software off the server and it will remove any Exchange based directory integration information (directory still at 2003- dont ask why), HOWEVER, after the mailboxes were removed from the users, I have repopulated the EMAIL field (general tab of user AD properties) with the O365 email address in hopes that this info will remain after Exchange removal and LDAP will still return the info from this field once Exchange is out of the picture.
Can you confirm – without laughing at an Exch 2003 environment with 2003 AD in 2019 🙂
I have a question that is not completely covered here: If I have migrated everything to O365 and want to decommission on prem exchange AND use DirSync AFTER decommissioning Exchange on prem, would that work? Local AD would be devoid of all exchange attributes as if exchange never existed, right? Would that be supported? or would it at least work? Wouldn’t O365 just sync non-exchange attributes then, and I would be able to manage the exchange aspects online?
Same question for me. We’ve got an Exchange 2010 on-prem that’s basically doing nothing (if I turn it off, everything O365-to-Outlook-client works fine inbound and outbound). And we don’t have an AD-Azure hybrid, with logons still happening on-prem. If I remove Exchange 2010 from the Org and then implement dirsync to get logon processing happening in the cloud, won’t the O365 attributes suffice to have everything gel, or are we still in trouble at that point for not leaving our on-prem 2010 box in situ?
I have two hybrid server (Exchnage 2013). I want to remove one server from hybrid configuration. Can you help me with the steps ?
Regards, Sajil K M
What about Autodiscover? We have a customer who have moved all their mailboxes to 365 but still need Directory Sync and Federation. Is it OK to now move autodiscover to point to 365? They do have Skype for Business on Prem but I guess that shouldn’t matter providing autodiscover works?
Same question as Ian, I’m OK with keeping 1 or 2 on-prem 2016 Exchange boxes for management purposes but I’d like to get rid of the Autodiscover and SCP legacy settings. We had a certificate expire on one of the old on-prem boxes and Outlook went into a tailspin. Can we simply move Autodiscover to O365 as long as no mailboxes are hosted on-prem?
When, when, when are Microsoft going to supply a solution that will allow those of us who have migrated all their mailboxes to O365 and use Dir Sync and DON’T want to keep Exchange servers on premise for management and SMTP relay? It’s VERY frustrating having to maintain on prem Exchange servers when we don’t have any mailboxes on prem!!!!
See the end of this article: https://www.practical365.com/exchange-server/removing-premises-exchange-servers-migrating-office-365/
If I decommission my exchange server, does that mean I’ll lose my single sign on? How will I synchronize my users and their passwords?
That question is already answered in the article.
I used the hybid migration because of the size of the mailboxes and to minimize downtime during migration. The customer use SSO and DirSync. Right now all the mailboxes are migrated, no public folders and only a single exchange server is remaining. I’m getting mix information in regards to having to keep the last exchange box or removing it. MS Support gave me instructions on how to remove the hybrid configuration and remove the server.
I’ve been reading many post that say you have to keep it around so not sure what will happen if the server is kept and the customer would like it removed.
In your article you mention DirSync so I’m assuming that’s the Go no Go reasoning.
Here is an article for you to read:
Could you please direct me how to join two intranets and keep the MX record OK so e-mail keeps coming?
a) Our office in NZL is on 2016 Active Directory in ONE-Domain & ONE-MX record.
They are using pure Office 365 and eXchange 2016 with AADconnect. Mobile users for e-mail are using their Android phone and Outlook, desktop users in the office Outlook Desktop version. All if fine and LG life is good.
b) Our office in VIC is on 2016 AD Another-Domain using Another-MX record.
Users are on G-Suite with a plan to asap migrate to Office 365, as there are Collaboration issues: nobody can share calendar invites, one using Excel which doesn’t work on G-suite…
How to Migrate the e-MAIL for VIC users from G-Suite to O365 and keep mail synced until we modify the MX record (which one? introduce a third MX record, then remove the old ones?)
There is 4 scenario: I use directory synchronization and I want cleanup my on-premise AD, where I actually have couple of version Exchange servers: Exchange 2007, 2010 and hybrid config with Exchange 2013. Some time ago we rebuild part of Exchange infrastructure (such as ipm public folder tree and OAB) from forest domain to child domain, where still exists mailboxes (ex2007).
I want to be sure that my on-premise AD is clean and after that I still want on-premise Exchange 2016 management role and directory synchronization. Can I use your scenario to decommission all version of Exchange servers and install last fresh version 2016 without change in AAD Connect?
Thanks for the great article.
Lucky for me, I purchased this great book titled “Office 365 for IT Pros”.
It made me aware that there was a proper procedure to remove Exchange from a system.
Check out this book and keep up the great work.
This is interesting! I had a situation with a customer that required Exchange schema to be re-installed simply to amend an Exchange attribute (mailNickName). This was the only approach that Microsoft Support said was possible.
Will be interesting to see what others do in this scenario.