Rimuovere Exchange Servers On-Premises dopo la migrazione ad Exchange Online: è possibile?

In questo articolo parleremo di un argomento molto caldo in ambienti ibridi di Messaging e Collaboration. Una volta terminata la migrazione delle mailbox da Exchange On-Premises a Exchange Online, molti clienti desiderano rimuovere definitivamente gli Exchange On-Premises.

È possibile rimuovere l’Exchange On-Premises definitivamente? La possibilità di eseguire questa operazione dipenderà da un paio di cose che vi spiegherò in questo articolo.

Quando inizio un nuovo progetto di Office 365, la prima cosa di cui mi piace discutere con un cliente è il modello di gestione di identità a lungo termine che desidera avere. Inizio sempre a parlare di identità utente come prima cosa, anche se di solito i clienti vogliono discutere da subito sulle modalità di migrazione degli item delle mailbox.

Il modello di gestione delle identità è il fattore più importante che determina il miglior metodo di migrazione.

Le possibilità di gestione delle identità del cliente sono due:

  • Il cliente desidera mantenere la foresta di Active Directory On-Premises per gestire l’autenticazione di servizi presenti in casa e desidera eseguire la sincronizzazione delle identità utente con sync degli hash delle password da foresta On-Premises a Azure AD per permettere agli utenti di utilizzare lo stesso set di credenziali sia per le risorse in casa che per quelle in cloud
  • Il cliente non desidera mantenere la foresta di Active Directory On-Premises e di conseguenza non sincronizzerà nulla a livello di identità utente

La chiave della discussione sulle identità utente in ambiente ibrido è la sincronizzazione di queste ultime. Microsoft ha pubblicato una guida passo passo per decomissionare gli Exchange On-Premises in un ambiente ibrido. Il titolo dell’articolo è un po’ fuorviante perché non è la configurazione ibrida che alla fine determina se è possibile decommissionare l’Exchange On-Premises o meno.

Quando la sincronizzazione delle identità è abilitata per un tenant e un utente è sincronizzata da foresta On-Premises, la maggior parte degli attributi delle identità non possono essere gestiti da Exchange Online ma devono essere gestiti dall’organizzazione Exchange On-Premises. Ciò non è dovuto alla configurazione ibrida, ma si verifica a causa della sincronizzazione delle identità. Inoltre, anche se sincronizziamo le identità On-Premises su Azure AD senza eseguire la procedura guidata di configurazione ibrida di Exchange non sarà ugualmente possibile eseguire la maggior parte dei task sulle identità dal cloud, sarà dunque sempre necessario eseguire le attività di management dall’infrastruttura On-Premises.

Per le organizzazioni che intendono mantenere il sync delle identità in place e continuare a gestire gli attributi delle identità dall’organizzazione On-Premises, si consiglia di non rimuovere l’ultimo Exchange server dall’organizzazione On-Premises. Se l’ultimo Exchange server viene rimosso, non sarà possibile apportare modifiche all’oggetto mailbox su Exchange Online perché il “SOA” (Source Of Authority) è definito come On-Premises. Il Source of Authority fa riferimento alla posizione in cui vengono gestiti  li oggetti del servizio directory di Active Directory, come utenti e gruppi (una source di origine che definisce le copie di un oggetto) in una distribuzione ibrida.
Nel momento in cui si andasse a decomissionare l’ultimo Exchange Server On-Premises, si renderebbe obbligatorio verificare che lo schema di Active Directory è stato esteso correttamente Con gli attributi necessari per un’Organizzazione di Exchange, inoltre si andrebbero ad utilizzare strumenti non supportati per attività su Exchange come Active Directory Service Interfaces Editor (ADSI Edit) per le attività amministrative comuni.

Per riassumere, se vogliamo sincronizzare le nostre identità su Azure AD permettendo così all’utente finale di utilizzare la stessa identità per autenticarsi su servizi On-premises e su servizi 365, si rende necessaria la presenza degli Exchange Management Tools che sono ovviamente presenti solo nelle installazioni di Exchange.

Figura 1 – Configurazione Ibrida Organizzazione Exchange

Quindi che tipo di migrazione scegliere? Di seguito alcuni scenari di migrazione da considerare:

  • Di seguito i metodi di migrazione:
    • Cutover Migration
    • Staged Migration
    • Hybrid configuration
    • IMAP Migration
    • Third party migration tools
  • Se avete necessità di avere le identità sincronizzate, una Cutover Migration non è una buona scelta. Personalmente non sono fan delle migrazioni cutover;
    https://www.ictpower.it/blogs in particolare in scenari con identità sincronizzate una volta completata la Cutover migration è molto complicato riuscire ad aggiornare la sincronizzazione delle directory, in questo caso è importante scegliere un tipo di migrazione che ti permetta di aggiornare la sincronizzazione delle directory prima di aver completato la migrazione.
  • Se avete necessità di avere le identità sincronizzate, è fortemente consigliato utilizzare l’Hybrid configuration come metodo di migrazione per facilitare il processo e il successivo management delle mailbox online. L’Hybrid richiede un po’ di lavoro in più per la configurazione, ma offre un’esperienza migliore agli amministratori e agli utenti finali in fase di migrazione.

E se volessimo assolutamente rimuovere l’Exchange On-Premises ma mantenere comunque la sincronizzazione delle identità utente? Per questo tipo di scenario probabilmente avrete già visto dei tool di terze parti o avrete parlato con qualcuno che vi consiglia di farlo perché potrete comunque continuare a gestire gli attributi utilizzando l’ADSIEdit. Da un punto di vista puramente tecnico è assolutamente possibile farlo, gli strumenti di management di Exchange in questo caso non fanno altro che andare a modificare degli attributi che andremmo in alternativa a modificare a mano. Microsoft però non supporta le modifiche degli attributi di Active Directory con nulla di diverso che non siano strumenti di management di Exchange.

In tutto questo non siamo entrati nel dettaglio di scenari complessi e non abbiamo nemmeno menzionato l’ADFS. Per i clienti con molta complessità infrastrutturale o con necessità di federare la propria organizzazione con Azure, la soluzione NON SUPPORTATA dalla casa di Redmond descritta sotto può essere dunque utilizzata da piccole realtà da dieci postazioni, ad esempio, personalmente una volta allargato lo schema di AD consiglierei sempre di mantenere un CAS di MGMT in ambiente con identità sincronizzate.

Di seguito un paio di esempi di task di MGMT che non è possibile effettuare dall’ECP dell’Exchange Online su identità sincronizzate:

  • Classica necessità di modificare Primary SMTP Address, o aggiungere nuovi smtp Address, riceverete il messaggio di errore illustrato nell’immagine sottostate.

Figura 2 – Errore Modifica Proxy Addresses da ECP Exchange Online

  • Necessità di nascondere ad esempio dall’elenco di indirizzi una mailbox, riceverete il messaggio di errore illustrato nell’immagine sottostante.

Figura 3 – Errore “Nascondi dall’elenco degli indirizzi” ECP Exchange Online

Microsoft ha dichiarato che ha in cantiere un progetto che permetterà di poter gestire gli oggetti sincronizzati dalla directory locale anche utilizzando gli strumenti di Office 365. Questo progetto fa riferimento ad un connettore ibrido che funziona in modo simile all’Azure App Proxy e all’AD Connect Passthrough Authentication. Andrà dunque installato in tutti i casi un agente nell’infrstruttura On-Premises; per le piccole realtà sicuramente preferibile all’avere un Exchange Server in più solo per il MGMT degli attributi estesi delle identità sincronizzate.

Conclusioni

Microsoft 365 ci offre la possibilità di avere un’esperienza utente trasparente, permettendo così ai nostri utenti usufruire delle risorse Online in egual modo alle risorse On-Premises. Quando consideriamo una migrazione dei nostri servizi in cloud, dobbiamo sempre decidere che tipo di impatto vogliamo avere sull’utente finale e che tipo di gestione delle identità vogliamo avere noi come amministratori di sistema, meglio quindi chiarirsi le idee prima di iniziare un percorso di questo tipo.