How To Decommission Exchange Servers
If you’ve already moved your mailboxes to Exchange Online, you might still be keeping one Exchange server around. Not for email, but just to manage recipient attributes in Active Directory. This “last server” problem has forced a lot of organizations to keep old infrastructure online that really shouldn’t be there anymore.
The cost is high. You’re patching a server that doesn’t even host mail, dealing with constant vulnerabilities, and carrying extra compliance risk for no real benefit.
The latest example is CVE-2025-53786, a flaw in hybrid Exchange setups that lets attackers use your on-prem server as a way into Microsoft 365. CISA’s Emergency Directive 25-02 shows just how serious this is, as agencies were given only days to fix or shut down their servers.
The good news? Microsoft has finally released a preview feature that solves this once and for all. You can now manage Exchange attributes directly in the cloud. That means you can safely shut down your last Exchange server and move on from the endless patch cycle.
This post walks you through how to decommission Exchange servers safely in 2025, what the risks are, what you need in place first, and the step-by-step process to get it done.
We’ll keep you up to date on the latest in Microsoft Cybersecurity.
The Exchange Vulnerability Cycle
Keeping an on-prem Exchange server has always meant one thing: you’re stuck in a loop of vulnerabilities and patches. A new CVE drops, you scramble to patch, attackers rush to exploit the gap, and the cycle repeats.
The latest case, CVE-2025-53786, makes this risk impossible to ignore. In hybrid setups, if an attacker gets admin access on your on-prem Exchange, they can use it to break into Microsoft 365. Because the attack comes from what looks like a trusted server, it’s not always picked up by cloud monitoring. In other words, your Exchange box becomes the attacker’s ticket into your tenant.
CISA stepped in fast. Their Emergency Directive 25-02 gave federal agencies just days to patch or isolate vulnerable servers. They were told to apply Microsoft’s fixes, move to the new hybrid service principal model, and disconnect any out-of-date servers. CISA also made it clear: this isn’t just a federal issue. Every organization running Exchange should treat this as urgent.
The bigger problem? Even when you patch, you’re still left running a server that attackers know how to target. The result is patch fatigue. Always waiting for the next exploit. The only real way out of this cycle is to stop depending on that on-prem Exchange server in the first place.
Microsoft’s Cloud-Based Attribute Management (Preview)
For years, the only reason to keep an Exchange server on-prem was to manage attributes like aliases, forwarding addresses, or “hide from address list” flags. Even if all your mailboxes were in Exchange Online, you still had to log into that server to make changes, because the source of authority stayed on-prem.
That’s the piece Microsoft has fixed. With the new cloud-based Exchange attribute management (in preview), you can flip a switch that makes Exchange Online the source of authority for mailbox properties. The switch is called IsExchangeCloudManaged. By default it’s off, but once you set it to True for a user, you can fully manage their Exchange attributes in the cloud.
In practice, this means you can add aliases, update mailbox policies, or hide a mailbox from the address list, all directly in Exchange Online. No more waiting for AD sync to push changes up, and no more relying on an old server that doesn’t need to exist anymore.
Microsoft is rolling this out in phases:
- Phase 1 (Preview) – You enable cloud management per mailbox. If you need to, you can roll a user back to on-prem management at any time.
- Phase 2 – Write-back support will arrive, so cloud changes also flow down into on-prem AD if you still keep one. This will require Entra Cloud Sync.
The bigger picture here: this is the start of eliminating the “last Exchange server” problem. Once all your mailboxes are cloud-managed, you can finally shut down that lingering server and know you’re still supported.
Wondering if Levacloud can solve your Microsoft Cybersecurity related challenge? Drop us a message!
How to Decommission Exchange Servers: High Level Step-by-Step
Decommissioning your last Exchange server isn’t just a shutdown. You need to walk through a sequence of checks and changes to make sure nothing breaks once it’s gone. Here’s the full process:
1. Confirm all mailboxes and public folders are in Exchange Online
Run in Exchange Management Shell:
Get-Mailbox -Server <servername>
If you see results, those mailboxes still live on-prem and need to be migrated first.
For public folders, check in Exchange Online PowerShell:
Get-PublicFolder -Recurse
All folders should appear in the cloud.
If you skip this step, shutting down the server will cut off access for any remaining users.
2. Verify directory synchronization is healthy
Check Azure AD Connect or Entra Cloud Sync status. In PowerShell:
Get-ADSyncScheduler
Confirm sync is enabled and recent runs show no errors.
Look specifically for Exchange attribute issues (like proxyAddresses) in the Microsoft 365 admin center. Sync must be clean, since the new cloud-based attribute management depends on it.
3. Check for SMTP relay or mail flow dependencies
List existing receive connectors on the last server:
Get-ReceiveConnector
This will show if any apps, scanners, or monitoring tools are routing mail through it.
If they are, reconfigure those systems to use Microsoft 365 SMTP relay instead (Microsoft setup guide).
If you overlook this, app-generated email may silently stop once the server is gone.
4. Audit compliance and integration ties
In the on-prem Exchange Admin Center, check for any journaling rules or legacy transport rules:
Get-TransportRule
Replace on-prem journaling with Exchange Online archiving or Microsoft Purview features. Make sure no security or monitoring system is still tied to the Exchange box.
5. Validate Exchange version and patch level
On the last server, run:
Get-ExchangeServer | fl Name,Edition,AdminDisplayVersion
Confirm it’s either Exchange 2016 CU23 or Exchange 2019 CU15 with the April 2025 hotfix. You can check current builds against Microsoft’s official list.
Older versions should be disconnected immediately, per CISA’s directive.
6. Enable cloud attribute management (IsExchangeCloudManaged)
Pick a pilot mailbox and enable cloud attribute management in Exchange Online PowerShell:
Set-Mailbox -Identity user@domain.com -IsExchangeCloudManaged $true
Test changes to the user’s attributes (add an alias, hide from address list) and confirm they persist after sync. If needed, roll back by setting the flag back to False.
Once validated, expand this change to batches of users, or script it org-wide with:
Get-RemoteMailbox -ResultSize Unlimited | Set-Mailbox -IsExchangeCloudManaged $true
7. Shut down the last Exchange server
When all users are cloud-managed and no dependencies remain, stop Exchange services and monitor for a few days:
Stop-Service MSExchangeISStop-Service MSExchangeTransport
If no issues appear, shut down or disconnect the server permanently. Do not uninstall it. Microsoft’s guidance is to leave the Exchange configuration in Active Directory intact. Removing it can break future management.
8. Confirm operations and update processes
- Test recipient management directly in Exchange Online (aliases, mailbox settings, forwarding).
- Update or retire any scripts that pointed to on-prem Exchange.
- Ensure helpdesk and admin teams know to use the Exchange Online Admin Center or PowerShell going forward.
- Verify audit logs in Microsoft 365 are capturing changes as expected for compliance.
Following this sequence takes you from “patch fatigue” to a clean shutdown, with confidence that mail flow, compliance, and user management continue without relying on a vulnerable server.
You have a pressing issue, but you’re not sure if Levacloud can help. We get it. Everyone has unique challenges they face in their IT environments. Schedule a free call today and talk us through it.
We’ll let you know how we can best support you.
The Bigger Picture
Shutting down your last Exchange server is more than reducing your workload, it changes your entire security posture.
With no on-prem Exchange to patch, you immediately cut out one of the most exploited attack paths of the last decade. You also reduce complexity: fewer systems to maintain, fewer emergency updates, fewer blind spots for monitoring. Instead of reacting to the next CVE, you’re positioned to focus on strengthening your cloud security stack.
This shift also brings compliance benefits. Changes to mailboxes and attributes now happen in Exchange Online, where every action is logged in Microsoft 365’s auditing framework. That makes it easier to meet audit requirements and prove control over account management.
And strategically, this is a step toward a fully cloud-first model. Microsoft has already previewed features for group and contact management in the cloud. The long-term roadmap is clear: remove the need for any on-prem Exchange footprint, and eventually, even on-prem Active Directory if you choose.
Retiring that last server is the start of moving from firefighting to forward planning. It’s about aligning your environment with where Microsoft is headed and taking Exchange vulnerabilities out of the equation for good.
Need Help With Your Exchange Server?
Our team of Microsoft-Certified security experts can help.
Ready to Retire Your Last Exchange Server?
Decommissioning Exchange isn’t just shutting a box down. You have to make sure every dependency, setting, and compliance control is handled correctly. If you’re ready to move forward but want expert guidance, Levacloud can help.
We’ve helped organizations transition from hybrid to cloud-first Exchange management without downtime, data loss, or compliance gaps. Whether you need a readiness review, step-by-step support, or help configuring Microsoft’s new cloud attribute management, our team knows the process inside out.
Don’t wait for the next emergency patch. Let’s plan your Exchange decommissioning the right way. Contact Levacloud
FAQs on How to Decommission Exchange Server
Do I need to uninstall my last Exchange server?
No. Microsoft specifically advises against uninstalling the final server. Shutting it down or removing it from the network is the supported approach. Uninstalling can remove Exchange configuration from Active Directory and cause problems later.
What if I still have mailboxes on-premises?
You’ll need to migrate them to Exchange Online first. This process is only safe once all mailboxes and public folders live in the cloud.
Can I roll back if I enable cloud attribute management and run into issues?
Yes. If you set the IsExchangeCloudManaged flag to True and something doesn’t work as expected, you can flip it back to False. That returns the source of authority to on-prem Exchange for that mailbox.
What happens if I’m running an older version of Exchange (like 2013 or 2010)?
These versions are out of support and vulnerable. CISA’s Emergency Directive 25-02 recommends disconnecting them immediately. You should migrate all workloads to Exchange Online and retire the old servers without delay.
How do I handle apps or devices that used the Exchange server for SMTP relay?
Those need to be reconfigured to use Microsoft 365 SMTP relay. Microsoft provides guidance for setting up devices and apps to send mail through Microsoft 365.
Does this mean I can get rid of Active Directory completely?
Not yet. This preview feature only shifts Exchange attributes into the cloud. Your core identity data (name, password, department, etc.) is still mastered in Active Directory if you’re running hybrid. Microsoft has signaled future plans for cloud-first object authority, but for now you still need AD or Entra Cloud Sync.
Is this preview safe to use in production?
Yes, but start with a pilot. Microsoft allows you to enable it per user and roll back if needed. This makes it low risk to test before scaling out.
This blog post was reviewed and validated by Gareth Young, a Microsoft Security and Compliance Expert with 15 years of experience in Microsoft solutions. As the founder of Levacloud, Gareth specializes in Security, Modern Work and Security Arcitecture. He holds multiple Microsoft certifications, including: AZ-500, MS-500, SC-400, MS-101, MS-100, MS-900 as well as the CISSP certification.





