Cloud-managed Remote Mailboxes: What It Means for Your Business (and What You Can Do This Week)

Carrying out the last exchange server

What changed (in plain English)

You can now flip a per-mailbox switch so Exchange attributes (aliases, GAL visibility, custom/extension attributes, and many mailbox flags) for directory-synced users are owned and edited in Exchange Online. Identity fields (name, title, department, UPN, etc.) remain mastered in on-prem AD. The property is IsExchangeCloudManaged.

Rollout is in two phases:

  • Phase 1 (preview, live now): enable/disable per mailbox; an org-level default for new synced users is coming.
  • Phase 2: writeback of selected attributes to on-prem AD via Entra Cloud Sync.

Why this matters (business impact & use cases)

  1. Retire the “last Exchange server” for recipient admin
    If you only kept Exchange on-prem (or EMT “management tools only”) to tweak aliases, hide-from-GAL, or custom attributes, you can move these changes to EXO and plan decommissioning sooner.
  2. Faster, safer delegation
    Let service desk adjust aliases or hide a mailbox directly in EAC/EXO—no RDP to on-prem, less privilege sprawl, cleaner audit.
  3. Cleaner onboarding
    Create the AD user → sync → assign EXO license → set IsExchangeCloudManaged=$true. No more “you must run New-RemoteMailbox first” muscle memory.
  4. Cloud automation unlocks
    Automate updates to extension/custom attributes for apps and workflows using EXO PowerShell/EAC—no on-prem scripts or jump servers. In Phase 2, selected fields (e.g., proxyAddresses) write back automatically.
  5. Hybrid simplicity during M&A / multi-forest
    Standardize Exchange-side management in the cloud while identity workstreams catch up.
  6. Bridge to full cloud governance
    Complements Group SOA for cloud-owned distribution/security groups.

New things you can do now

  • Edit aliases and many mailbox flags for synced users in EXO without on-prem overwriting them.
  • Adopt a cloud-first recipient workflow immediately; add writeback later once Phase 2 ships.

When not to flip it (yet)

  • Offboarding back on-prem? Set IsExchangeCloudManaged=$false before you migrate a mailbox to on-prem, or you’ll break the sync flow.
  • Still using on-prem Exchange workloads (SMTP relay, public folders, etc.)? Move those first, then decommission per Microsoft’s hybrid guidance.

A 7-step pilot you can run this week

  1. Prereqs: Ensure Entra Connect Sync ≥ 2.5.76.0.
  2. Pick 5–20 test mailboxes (include 1–2 shared/room). Confirm they’re dir-synced in EXO.
  3. Stabilize recent on-prem changes: If you just ran Set-RemoteMailbox on-prem, wait one sync cycle + 24h before flipping the switch.
  4. Enable per mailbox (EXO): Set-Mailbox -Identity user@domain.com -IsExchangeCloudManaged $true Get-Mailbox -Identity user@domain.com | fl Identity,IsExchangeCloudManaged
  5. Validate cloud ownership: Change an alias or hide-from-GAL in EXO/EAC; verify it isn’t overwritten by on-prem.
  6. Tighten RBAC: Limit who can toggle IsExchangeCloudManaged (custom roles if needed).
  7. Plan the next wave: When the org-level default lands, make new synced users cloud-managed from day one.

Handy commands

# Enable cloud management per mailbox
Set-Mailbox -Identity user@domain.com -IsExchangeCloudManaged $true

# Roll back to on-prem management
Set-Mailbox -Identity user@domain.com -IsExchangeCloudManaged $false

# Find all cloud-managed (dir-synced) mailboxes
Get-Mailbox |
  Where-Object { $_.IsDirSynced -eq $true -and $_.IsExchangeCloudManaged -eq $true }

These are straight from Microsoft’s guidance for the preview.

Path to retiring the last Exchange server

If recipient management was your only blocker, this feature + a short pilot lets you move toward no server (and likely no EMT, either). Follow Microsoft’s decommission playbook for hybrid so you don’t lose coexistence or leave artifacts behind.


Further reading

Leave a Reply

Your email address will not be published. Required fields are marked *