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.
Is there any way to connect remotely and run the Exchange cmdlets or do you have to be logged into that server with the mgmt tools installed? That will be a deal breaker for us if so. We have provisioning software that connects to our local exchange server PS URL to run commands for newly created AD accounts (enable-remotemailbox). Thats ashame if so, really wanted to shutdown this server.
I have a rare situation: Win Defender from Hyper-V host .. delete the VM containing Exchange 2019. I undelete the VM file but was unusable. Now I’m fighting to Clean UP AD by any Exchange atributes, in order to reinstall Exchange organization from scratch and can not find any documentation. ANY but ANY advice will be warm welcomed. I’m like this since 2 weeks.
I try to install new VM and Exchange having same OLD server name but I enter to some HUGE errors. Now looking to clean Exchange Organization from AD to be able to start like very first Exchange setup. Please please advice !
Hi,
Excellent article. I have a situation where we have an environment that has Exchange 2010 installed still. The mailboxes have been migrated to Exchange Online and the requirement is to decommission the Hybrid Environment and the 3 exchange servers. To “remove” the last exchange server would we need to get Exchange 2019 in to the environment first or just update the schema to Exchange 2019?
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?
Can we use only the commands posted on microsoft doc? It seems to be limited to a few powershell commands.
I don’t see Add-MailboxPermission here:
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