Per anni, molte organizzazioni con identità in Active Directory (AD) sincronizzate verso Microsoft Entra ID, per essere supportate, hanno dovuto mantenere un server Exchange on-premises esclusivamente per modificare gli attributi Exchange (alias/proxyAddresses, visibilità in GAL, custom/extension attributes, forwarding, ecc.) di utenti la cui cassetta postale era già in Exchange Online (EXO). Dal 20 agosto 2025, Microsoft ha introdotto, in anteprima (Preview), la gestione nel cloud degli attributi Exchange per utenti sincronizzati, spostando nel cloud la source of authority (SOA) di tali attributi e lasciando ad Active Directory quella degli attributi identitari. È il primo passo concreto per eliminare la dipendenza operativa dall’ultimo server Exchange on-premises.
Cosa Cambia
La novità ruota attorno alla nuova proprietà IsExchangeCloudManaged sulle mailbox di EXO per utenti dir-synced. Quando impostata a True, la SOA degli attributi Exchange per quell’utente si sposta nel cloud: da quel momento quegli attributi si potranno gestire in EXO (PowerShell/EAC/Microsoft 365 Admin Center), mentre gli attributi identitari (nome, reparto, titolo, UPN, telefono, ecc.) restano modificabili solo in AD on-prem. Il valore predefinito è False. La funzionalità si applica a utenti, shared, room ed equipment mailbox.
La roadmap prevede due fasi:
- Fase 1 (Preview): controllo per-mailbox tramite
IsExchangeCloudManaged. Possibile anche il rollback a gestione on-prem rimettendo il flag aFalse. In questa fase non c’è write-back automatico in AD: le modifiche fatte nel cloud non ritornano in AD ed i valori potrebbero divergere. - Fase 2: abilitazione del write-back selettivo verso AD per attributi chiave (ad es.
proxyAddresses, CustomAttribute1-15, ExtensionCustomAttribute1-5, ecc.) ed integrazione con Microsoft Entra Cloud Sync; le modifiche fatte in EXO verranno sincronizzate in AD. Per usare il write-back sarà richiesto Cloud Sync.
Prerequisiti e Ruoli
Per utilizzare la Fase 1, con ambienti che usano Entra Connect Sync, è necessario Connect ≥ 2.5.76.0: versioni precedenti continueranno a tentare di aggiornare in cloud attributi “mastered” on-prem causando errori. I dettagli, e gli esempi di verifica e aggiornamento versione, sono riportati nella documentazione. I ruoli necessari sono i classici RBAC di Exchange (es. Recipient/Organization Management) o il ruolo Entra Exchange Administrator.
Attributi: cosa si edita dal cloud e cosa resta in AD
Dopo il passaggio della SOA degli attributi Exchange al cloud:
- In EXO si potranno modificare, tra gli altri,
HiddenFromAddressListsEnabled, CustomAttribute1-15, ExtensionCustomAttribute1-5, impostazioni di auditing/hold, proprietà delle risorse e, in generale, vari flag di mailbox; la documentazione include una tabella completa con l’indicazione “Editabile in EXO” e “Write-back in AD” per ciascun attributo. - Gli attributi identitari (nome, titolo, reparto, UPN, telefono, ecc.) non diventano editabili in cloud e restano gestiti in AD anche dopo la transizione.
Operatività (esempi)
Nota: per evitare condizioni di conflitto, dopo aver aggiornato attributi on-prem con Set-RemoteMailbox su un utente dir-synced, la documentazione ufficiale raccomanda di attendere il consueto ciclo di sync + 24 ore prima di portare IsExchangeCloudManaged a True
Abilitazione per singola mailbox:
1 2 3 4 | # Abilita la gestione cloud degli attributi ExchangeSet-Mailbox -Identity utente@contoso.com -IsExchangeCloudManaged $true# Verifica statoGet-Mailbox utente@contoso.com | fl Identity,IsDirSynced,IsExchangeCloudManaged |
Modifica di attributi Exchange direttamente da EXO:
1 2 3 4 5 6 | # Esempi tipiciSet-Mailbox utente@contoso.com -CustomAttribute1 "Sales-North"Set-Mailbox utente@contoso.com -HiddenFromAddressListsEnabled $true# Alias/primario (mail addresses)Set-Mailbox utente@contoso.com -EmailAddresses @{add="smtp:alias2@contoso.com"}Set-Mailbox utente@contoso.com -WindowsEmailAddress primary@contoso.com |
Rollback (ritorno alla gestione on-prem):
1 2 | Set-Mailbox -Identity utente@contoso.com -IsExchangeCloudManaged $false# Al successivo ciclo di sincronizzazione, i valori cloud vengono riallineati a quelli on-prem |
Le procedure e i caveat del rollback (backup valori da conservare, comandi consigliati Get-Mailbox/Get-User) sono documentati al seguente articolo – https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management.
Relazione con i Management Tools “server-less”
Dal 2022, con Exchange Server 2019 CU12+, Microsoft supporta la gestione “server-less” dei destinatari in scenari ibridi tramite i Management Tools installabili su una macchina joinata al dominio, senza un server Exchange in esecuzione. È importante sottolineare che non va disinstallato l’ultimo server: si può spegnere e poi eseguire la pulizia di AD seguendo la guida ufficiale (cleanup hybrid, rimozione trust/certificati OAuth/Hybrid Agent, ecc.). La pagina ufficiale elenca prerequisiti, cmdlet supportati e warning (“DO NOT uninstall”).
La domanda chiave: con la nuova configurazione si può rimuovere l’ultimo Exchange on-prem?
Sintesi: sì, nella maggior parte degli ambienti—con alcune cautele tecniche e operative.
- Già oggi (senza la novità) era possibile spegnere l’ultimo server mantenendo la gestione dei destinatari con i Management Tools (Exchange 2019 CU12+), a condizione di non avere dipendenze on-prem (SMTP relay, public folder locali, DDL basate su OU, EAP on-prem, ecc.). La documentazione spiega quando e come effettuare il decommission dell’hybrid e i passaggi di cleanup, ribadendo perché storicamente serviva mantenere un server in presenza di dir-sync.
- Con la Fase 1 (Preview) della nuova funzionalità, per ogni utente dir-synced con mailbox in EXO è possibile spostare nel cloud la SOA degli attributi Exchange e gestirli interamente da EXO, eliminando la dipendenza operativa da Exchange on-prem per le modifiche quotidiane. In questo scenario molte organizzazioni possono spegnere l’ultimo server (e, volendo, ridurre al minimo l’uso dei Management Tools), purché non esistano altre dipendenze on-prem e si accetti che non vi sia ancora write-back automatico in AD: in caso di modifiche parallele in AD, i valori possono divergere.
- Con la Fase 2 (quando disponibile) + Entra Cloud Sync, il write-back degli attributi Exchange cloud-managed verso AD chiude il cerchio e rende l’esperienza pienamente cloud-first pur mantenendo AD come SOA identitaria. Questo riduce ulteriormente (o azzera) le motivazioni tecniche per mantenere Exchange on-prem anche per la coerenza con AD.
Limitazioni e dipendenze
Prima del decommission del “last server” è necessario verificare e, se serve, re-ingegnerizzare:
- SMTP relay o applicazioni che inviano via Exchange on-prem.
- Dynamic Distribution Lists basate su OU (non supportato in EXO; si utilizzano attributi alternativi, es. custom attributes).
- Email Address Policies definite on-prem (non equivalenti 1:1 in EXO).
- Public Folder on-prem ancora in uso.
Le linee guida ufficiali per il decommission ibrido e per i Management Tools evidenziano questi aspetti e i relativi step di pulizia, disponibili al seguente link – https://learn.microsoft.com/en-us/exchange/decommission-on-premises-exchange.
Checklist essenziale per un’uscita “safe”
- Adottare progressivamente le funzionalità di object-level SOA per gruppi/utenti/contatti man mano che maturano.
- Aggiornare Microsoft Entra Connect Sync ad almeno 2.5.76.0 (o predisporre Cloud Sync se si intende usare il write-back in Fase 2).
- Portare
IsExchangeCloudManagedaTruesu un gruppo pilota di mailbox dir-synced e verificare che le modifiche in EXO non vengano sovrascritte. - Eliminare dipendenze dal server on-prem (relay, PF, DDL su OU, EAP). Quindi seguire la procedura di decommission (connettori, organization relationship, OAuth/Hybrid Agent, Autodiscover SCP e DNS).
- In scenari “server-less”, mantenere i Management Tools per gli oggetti non ancora cloud-managed (o adottare progressivamente le funzionalità di object-level SOA per gruppi/utenti/contatti man mano che maturano).
Conclusioni
L’introduzione di IsExchangeCloudManaged consente, già nella Fase 1, di spostare nel cloud la gestione degli attributi Exchange delle mailbox di utenti sincronizzati, riducendo drasticamente la necessità di mantenere un server Exchange on-prem solo per la gestione dei destinatari. Con Fase 2 e Cloud Sync (write-back verso AD) l’approccio diventerà pienamente cloud-first, lasciando ad AD la sola autorità identitaria. In parallelo, continuerà ad esistere la via “server-less” con i Management Tools, per chi vuole spegnere da subito l’ultimo server seguendo le procedure ufficiali di cleanup. Per la grande maggioranza degli ambienti senza dipendenze on-prem specifiche, questo significa che sì, è finalmente possibile rimuovere (spegnere) l’ultimo Exchange on-prem in sicurezza, e gestire gli attributi Exchange direttamente in EXO.
Nessun commento:
Posta un commento