Hey Checkyourlogs Fans,
Organizations that have moved most or all their mailboxes to Exchange Online will often reach a point where their on-premises Exchange servers are primarily serving as the “last Exchange server” (LES). That means they are still needed for directory-synchronized users to manage Exchange attributes via on-prem AD, running Exchange cmdlets, etc. Eventually, many want to fully decommission (“de-hybridize”) the last Exchange server. But doing so has trade-offs, and Microsoft has recently introduced a feature to ease the process.
This post walks through:
- What “de-hybridizing” means, especially around the Last Exchange Server
- The difference between simply shutting off vs uninstalling the last Exchange server
- The new cloud SOA (Source of Authority) for Exchange attributes (e.g. IsExchangeCloudManaged) — what it enables
- Pros, cons, risks, and workarounds/strategies
What’s the purpose of the “Last Exchange Server”?
In a hybrid deployment between on-prem Exchange + Exchange Online:
- Some attributes of mailboxes/users (proxyAddresses, customAttributes, recipient type, etc.) are managed only via the on-premises Exchange server (via on-prem AD), synced to the cloud.
- Even if all mailboxes are in Exchange Online, you still often need the LES to run Exchange Management Shell / GUI to change hybrid-related attributes, perform mailbox moves, etc.
So “de-hybridizing” in practical terms means removing that dependency on an on-prem Exchange server.
Two Paths: Shutting Off vs Uninstalling
Here are two common paths people consider when retiring their last Exchange server:
| Approach | What It Means / What You Do | Pros | Cons / Risks |
|---|---|---|---|
| Shut off the last Exchange server (power down, disable, stop using it, leave it as-is) | You leave the server in place but generally stop using it. You may disable services, block access, but don’t uninstall or remove Exchange from AD. | + Minimal effort / risk. + You retain the capability to fall back: if something breaks in the cloud or some attribute needs on-prem change, you still have the tool. + Less chance of breaking hybrid directory sync or attribute dependencies. | − You still carry server maintenance: hardware/software updates, patching, backups (maybe). − You might leave some liabilities: security risk if forgotten, unsupported OS or Exchange version. − This doesn’t free up licensing / support cost (if applicable). − Some tooling or automation may depend on Exchange being present; with it “off,” scripts may fail. |
| Uninstall / Remove Exchange entirely | You decommission the server properly: uninstall Exchange roles, remove hybrid connectors, ensure all dependencies are moved, remove routing / mail flow, etc., delete hybrid objects as needed, remove the server from AD, etc. | + Fully removes maintenance overhead. + Cleaner environment. + Removes potential attack surface; simplifies your infrastructure. + No costs (support, licensing) ongoing (if those were in place). | − Riskier: if something breaks / you realize you need something only possible via on-prem Exchange (attribute, mailbox move, some hybrid setting), it’s harder to fall back. − Certain integrations or legacy dependencies may break. − Some attributes in on-prem AD may be in a bad state, or you may lose functionality. − Might require effort / time to verify everything that currently relies on it, and to adjust to cloud-only. |
So, the decision often hinges on risk tolerance, cost, and readiness to transition to cloud management entirely.
Microsoft’s “Cloud Management of Exchange Attributes” (Preview) — What It Enables
Microsoft has introduced a feature that aims to make part of the de-hybridization process much smoother by allowing Exchange attributes for directory-synchronized users with mailboxes in the cloud to be managed in Exchange Online instead of requiring the “Last Exchange Server.”
Key points:
- There is a new parameter/attribute IsExchangeCloudManaged. By default, this is false. Setting it to true for a mailbox means that Exchange-specific attributes (but not identity/authentication/other core AD attributes) can be managed via EXO (Exchange Online) PowerShell / EAC / Microsoft 365 Admin Center.
- The identity attributes (first/last name, UPN, etc.) remain managed in on-prem AD and are still synced via Entra Connect. You’re not moving the complete SOA of the user, just the Exchange-relevant parts.
- Some attributes support “write-back” (so that changes in cloud are mirrored back to on-prem AD) or will in future phases. Currently, not everything supports write-back.
- Prerequisites like having a recent version of Entra Connect are required. Also, proper permissions (roles such as Hybrid Identity Administrator or Global Admin) must be in place.
This lets you gradually reduce dependency on LES: you can set IsExchangeCloudManaged = true mailbox by mailbox (or for groups), test whether all needed attributes are editable in the cloud without problems and then plan to remove the server.
Pros & Cons of Using IsExchangeCloudManaged / Cloud-Attribute Management
| Advantages | Limitations / Cautions |
|---|---|
| + Allows for phased de-hybridization. No need to flip a big switch and risk breaking manageability. | − Not all Exchange attributes are supported yet for cloud management / write-back. |
| + Reduces dependency on the last Exchange server: fewer reasons to keep it running merely for attribute edits. | − If you have legacy scripts / tools that expect the Exchange server to be present, those may fail or need rework. |
| + More agility: administrators can use cloud tools, PowerShell in EXO, etc., without always falling back to on-prem LES. | − Role / permission changes required: administrators will need the right Azure/Entra/EXO roles. |
| + Less infrastructure to maintain fewer patching and OS updates. | − Write-back to on-prem AD isn’t fully available for all attributes yet. |
| + Helps in license / hardware cost savings over time. | − Some hybrid related features (e.g. certain migration paths, connectors, routing) may still require the last Exchange server. |
Workarounds / Strategies for De-Hybridization
Here are some practices and planning steps to de-hybridize more safely:
- Install a Minimal Management Server (LES proxy)
Stand up a minimal server just for management operations (Exchange Management Shell, modifying AD attributes), but with everything else (mail flow, mailbox hosting) in the cloud. - Use IsExchangeCloudManaged = true Gradually
Start testing with non-critical users. Verify that the attributes you need are supported. Ensure AD sync and cloud directory tools behave as expected. Roll back if you find missing functionality. - Inventory / Dependency Mapping
Audit what workflows depend on on-prem Exchange: scripts, connectors, applications, compliance tools, mail routing, and hybrid sync. - Validate Permissions / Roles
Ensure the correct roles in Entra / Azure AD / Exchange Online are assigned. Without correct permissions, setting up or using that property may fail. - Staging & Backup
Backup current configurations. Document custom attributes. Perhaps keep the LES around, but offline until after a stabilization period in the cloud. - Ensure Entra Connect / Sync Tools Are Up to Date
Upgrade Entra Connect to supported versions ahead of time to avoid surprises. - Monitor & Report
Once mailboxes are cloud-managed for Exchange attributes, monitor for sync issues and missing functionality.
When “Shut Off” vs “Uninstall” Makes Sense
- If you have a large, complex hybrid environment with many legacy dependencies, you may want to keep the LES in some form until you’re confident everything is migrated.
- If you’re small, with limited dependencies, and you’ve tested the IsExchangeCloudManaged path, uninstalling may make sense sooner.
- If compliance or legal policy requires that specific mail routing or journaling be handled in-premises, shutting off may cause non-compliance unless you replicate or migrate those tools.
Suggested Roadmap
- Assessment phase
Identify all features and dependencies on LES. Check the version of Entra Connect, and validate cloud attribute feature availability. - Pilot / Testing
Select a small set of non-critical mailboxes and enable IsExchangeCloudManaged = true. Test all attribute edits and writeback if needed. - Gradual Rollout
Roll out to increasingly more mailboxes. Update scripts and automation to use cloud tools. - Fallback / Safety Period
Maintain the LES in a ready state (perhaps powered off but not uninstalled) for a period to catch anything unexpected. - Final Decommission
Once satisfied, nothing depends on LES: uninstall Exchange, remove hybrid connectors, routing, and references. - Post-Decommission Monitoring
Ongoing monitoring of attribute writes and mail routing.
Summary
De-hybridizing Exchange can significantly simplify your environment and reduce costs. But doing so without careful planning can lead to broken workflows or lost functionality.
Microsoft’s new “cloud-management of Exchange attributes” capability is a significant step forward. It enables organizations to shift SOA for Exchange attributes to the cloud, reducing dependency on the LES while retaining on-prem identity management. It doesn’t fully replace all on-prem functionality yet, but for many environments, it may be all you need.
Dave Kawula – MVP
