Table of Contents
A word of warning first
With what’s almost a passing mention in the announcements for the latest Exchange Server 2019 “H1” cumulative updates on 04/20/22, there were some significant updates from Microsoft.
Yes, removing the last Exchange Server from a Hybrid environment is now possible.
It is important to note though: You must NOT uninstall it – though you remove it permanently using Microsoft’s instructions, and for many folks, you might need to keep the Exchange Server around for some time longer.
You will find a list of caveats, and a specific process documented in detail by Microsoft. Having been part of the preview program for this new feature, the requirements and steps to remove Exchange all make sense.
What to Expect Removing the Last Hybrid Exchange 2019
If you migrated all your mailboxes to the cloud some time ago, then you’ve probably dreamed about the day when you can finally (perhaps with some ceremony), remove that last Exchange 2019 Server. To be clear, you will be slightly underwhelmed, and that is absolutely fine.
What you can expect: A subset of Exchange recipient management cmdlets targeting AD objects representing cloud recipients and their supporting configuration like domains and email address policies. You’ll also receive instructions and scripts to allow you to gently remove the supporting configuration for the server and various hybrid components – after shutting down the last Exchange Server.

You will still need to manage recipient configuration on-premises for AD-mastered objects with the same boundaries you’re used to. For example, updating Email Addresses for an on-premises user, and updating mailbox settings such as recipient permissions in Exchange Online.

You won’t have the ability to change the source of authority for those objects, which is something Microsoft alluded to in the past. You also won’t have the ability to update user attributes cloud-side in Exchange Online with the AD object updated using a mechanism (similar to password change flow or HR-based provisioning from Azure AD to on-premises) which was another method shared by Microsoft as a possibility several years ago.
The solution is focused on the recipient management aspect as well. However, Microsoft isn’t specifically suggesting this is the panacea to solve the “last Exchange Server” problem for all.
Mail Relay remains the elephant in the room and while Microsoft announced that Exchange Server 2019 gets free Hybrid licenses, and that you can deploy Exchange onto Windows Server 2022 – that only applies to the core Mailbox role on a domain-joined server not an Edge Transport Server deployment.
Edge Transport as a standalone SMTP relay has the potential to be a great drop-in replacement placed into a DMZ allowing mail relay from older application servers using Receive Connector rules imported from the last Exchange Hybrid Servers you maintain. For now, at least, you’ll need to keep that last Exchange Server up to date, use a different MTA, or work on configuring your application servers to deliver to Exchange Online.
Microsoft 365’s Evolving Capabilities are Culprit
If you were expecting the perfect solution after all this time, then you shouldn’t have. In the last few years, the reality is that an increased number of organizations are actually removing their dependency on Active Directory. By the time a perfected write-back or change of authority solution arrived, you would most likely be considering going towards cloud-only identities anyway with potentially Azure AD DS being the legacy directory after you move some of those legacy servers into a Landing Zone in Azure.
Without write-back capabilities, a stale set of attributes in AD for customers that don’t have a cloud-first strategy (but extensively use Microsoft 365) is dangerous enough that any advocates for simply cutting the link between an AD attribute for Exchange and the equivalent Azure AD attributes have thankfully not experienced the pain that causes.
Many Google migrations obviously result in buyer’s remorse (and staff mutiny) and when customers come back, the mess made by whoever helped them migrate usually includes switched-off Exchange Servers, and attributes that haven’t been maintained and don’t reflect the current state for mail flow. A great deal of effort needs to be expended on remediation, and for Microsoft to enable its own customers to end in that situation would have been inexcusable.
If you truly don’t want Exchange attributes managed in a local AD, even by a set of Exchange recipient management tools, then – begin thinking about how you remove AD. It’s easily achieved by smaller organizations and regularly achieved by mid-size and smaller enterprise organizations. Any larger than a few thousand employees and yes – there will be enough reliance on commercial off-the-shelf apps that it will be more difficult and a 2–3-year journey. In such orgs, the footprint of running a couple of Exchange Servers in Azure or the datacenter is negligible though; and with the ability to upgrade to Exchange 2019; use Windows Server 2022 and perform in-place OS upgrades in the future too – it’s not a bad situation.
Widening the niche
The solution to removing the last Exchange Server is undoubtably a niche solution, for those that:
- Have no need for mail relay using Exchange
- Had only a single server remaining
- Had thankfully not tried to do it themselves already in an unsupported way, leaving attributes in an unknown state
- Are quite happy using PowerShell for ongoing management
- Are small enough to fit the above criteria, competent enough with PowerShell to use that for daily management and have no plans to get rid of AD any time soon.
The first three points are a wide cross-section of businesses – the fourth is an order of magnitude slimmer niche; a niche within a niche, if you will.
To help solve that, stay tuned for my latest open-source script, which I’ll release for Practical 365 readers in the new few weeks for removing the last Exchange server.
Know if there is any dependencies on the Exchange namespaces and the RecipientManagement Snapin once the Exchange Server is retired?
Would like to just standup an IIS server as a mail relay and repoint DNS but not sure if this would cause any issues with the RecipientManagement Snapin.
What’s pretty amazing is that these tools will not work in PowerShell 7 since, for some reason, they packaged them as a snap-in instead of a module. PowerShell 7 does not support snap-ins.
I’d like to thank Microsoft for making this more complicated than it needs to be.
Hi.
As talked about in the comments here it seems like it is possible to install 2019 CU12 managements tools on a server even if you are on Exchange 2016.
Has anyone done this?
Does it do any harm to the Exchange 2016 server or is it still operational after doing all the schema updates and installing the management tools?
Thank for any reply.
Posted my q under wrong comment, so feel free to remove the other one.
Can we use only the commands posted on microsoft doc? It seems the management tool is limited to a few powershell commands.
I don’t see Add-MailboxPermission in the command list that MS posted on the article.
We’re fully moved to online mailboxes for several years now, just using HCW for the recipient management and Relay. Looks like we’ll have to spin up a new Exch 2019 with HCW so we can retire the old Exch 2016 with HCW as we are stuck with the requirement for Relay for at least another year (legacy devices and stuff). But knowing we can then move to just a feature install of Exch 2019 on some other server is very welcome news going forward to maintain our recipient management.
Any items to cleanup once we get the Exch 2019 with HCW up and the process thru the uninstall/decom of Exch 2016?
what about brend new AD forest ?
promote DC, update schema and install tools only, right ?
i understand there is no need to install exchange
Yes, you’ll need to install this, along with the configuration needed to support managing Exchange attributes. Previously in a new forest, you’d install and configure a minimal Hybrid Server
Am I right in assuming this functionality is only for Exchange 2019 instance, so we would need to upgrade from 2016 to 2019 to get the feature set to turn off the server?
Hello,
Good point Do you get an answer for this ?
Indeed a good point. In a hybrid scenario we get a free licenses for the last remaining Exchange 2016 server, but not for an Exchange 2019. If this feature is for 2019 only, how is this to be implemented? Can you simply rollout another 2019 next to the existing 2016 machine and demote the oldest one, then simply shutdown (with the correct procedure) the 2019 machine? What about licensing that machine for the short period of time necessary to shut it down permanently?
I will reply to my own comment. It has been answered by MS that an installation op Exchange 2019 is not necessary if you are using Exchange 2016. A simple extend of the schema for Exchange 2019 will be necessary, but a co-existence scenario is not.
After the schema extend the management tools can simply be installed.
Answered by Nino Billic on Apr 25 2022 09:13 AM on the MS blog post.
Hi.
This is very interesting, do you know if the Exchange 2016 will still work after doing the installation of the 2019 management tools on a new server.
Nino is (of course) right – it’s a schema update; so if you run Exchange 2013 and add the 2019 schema it limits options on installation of 2016 – but apart from that, it’s schema *only*
Wonderful article that sums all this up really well
Great article Steve
Thanks Andy! To think it is several years since we discussed this and hoped that the Exchange Servers installed in the new AD forest would be soon replaced – but at least, now there the option..
Steve