March 8, 2019•390 words
I've seen a lot of customers over the years assume that once they've moved to G Suite or Office 365 it's safe to just turn off Exchange and forget about it. While it is possible to manually remove an Exchange server from Active Directory, it's a.) not supported and b.) still leaves remnants of schema on user objects that are difficult to manage without an Exchange server. It's also really difficult to install an Exchange server in the future if you ever need it (as many Office 365 customers do for directory sync management).
I've made it common practice to require customers I deploy on G Suite or Office 365 to retain an Exchange server for management of the Exchange schema in Active Directory. In Office 365's case, Microsoft acknowledges this is necessary and provides a Hybrid Exchange key free of charge for Enterprise subscriptions. I generally configure this Hybrid edition for a customer on whatever the newest version of Exchange is - recently 2016 (2019 is still in RTM). This leaves the need to decommission the old Exchange server (generally 2010). Nearly every Exchange server is stubborn to decommission to some degree, so I wanted to compile a few tips.
1.) Migrate all mailboxes - including audit and arbitration - from the server you're decommissioning
Get-Mailbox -Server [Source Server]
Get-Mailbox -Arbitration -Server [Source Server]
Get-Mailbox -Audit -Server [Source Server]
2.) Manually stop AND disable Exchange services and IIS on the server you're decommissioning
This is one of the most common issues I see when going through the uninstall process. For whatever reason, Exchange services fail to stop and leaves the Exchange install in a corrupted state.
3.) If the uninstaller does fail, it will leave the registry in a "watermarked" state that doesn't allow proceeding with uninstall. You can fix this in two ways:
- on each role, there may be an "Uninstall" key set - delete this
- each role should have an "UnpackedVersion" and "ConfiguredVersion" key set - if "ConfiguredVersion" is missing, the installer assumes it can't proceed. If the installer fails late enough (i.e. at "Step 9: Stopping services" then the "ConfiguredVersion" key will have been cleared from all roles and you'll have to go in and re-add it manually. Just add the key as a Binary String and set the value to match the "UnpackedVersion".