• Cloud, Collaborazione, Guide, Microsoft 365, Sistemi Operativi
• 16 Ottobre 2020

La migrazione dei servizi di posta è sicuramente un argomento molto delicato ed è necessario programmare con cura tempi e modi per effettuare questa operazione per evitare di creare fastidiosi e probabilmente costosi disservizi.

Per molte realtà la dismissione di Exchange Server 2010 in questo periodo particolare diventa un obbligo, poiché abbiamo appena superato la data di fine del supporto. In un primo momento questa era stata fissata per il 14 gennaio 2020, in contemporanea con la fine del supporto di Windows 7 e Windows Server 2008 R2; Microsoft, però, visto ancora il numero elevatissimo di installazioni ancora in produzione, ne ha eccezionalmente esteso il supporto fino al 13 ottobre 2020.

Ovviamente non sottovalutiamo che, essendo stati rilasciati nello stesso periodo, i servizi Exchange Server 2010 girano su piattaforme Windows Server 2008 R2, già fuori supporto da qualche mese.

Non rimane altro quindi che rimboccarsi le maniche ed iniziare le nostre attività di migrazione. Vediamo schematicamente come procedere step by step per migrare Exchange Server 2010 ad Exchange Online.

Verifica prerequisiti migrazione

Anche se non esplicitamente indicato, consiglio di aggiornare il sistema operativo all’ultimo livello di patch disponibile, installando tutti gli aggiornamenti disponibili per il sistema operativo in uso.

Poiché Microsoft 365 è in continua evoluzione, è fondamentale assicurarsi che sia installato Exchange Server 2010 SP3 con l’ultimo rollup update disponibile. Per ottenere la versione corrente di Exchange possiamo eseguire dalla Exchange PowerShell:

Possiamo poi confrontare il ProductVersion restituito con l’elenco disponibile all’indirizzo https://docs.microsoft.com/it-it/exchange/new-features/build-numbers-and-release-dates

Per prima cosa se non è ancora installato SP3, procediamo con l’installazione del pacchetto scaricabile da https://www.microsoft.com/it-it/download/details.aspx?id=36768, e successivamente applichiamo l’ultimo rollup update disponibile.

Una volta applicato il Service Pack è possibile installare direttamente l’ultimo Rollup Update, poiché ogni update è cumulativo rispetto ai precedenti. Alla data di stesura della presente guida l’ultimo aggiornamento disponibile è il Rollup Update 30, che troviamo al seguente link https://www.microsoft.com/en-us/download/details.aspx?id=100910

Il file ha estensione .msp, ed è autoinstallante. Si occuperà di stoppare i servizi, aggiornarli, e riavviarli, ed è quindi necessario avviare l’installazione con privilegi elevati. Per fare questo è necessario aprire un prompt dei comandi come amministratore e richiamare il file msp:

Sarà avviato un wizard dove sarà semplicemente necessario seguire tutti i passi per verificare che non ci siano errori ed attendere qualche minuto.

Verifichiamo ancora con il precedente comando la versione corrente di Exchange. Nel nostro caso sarà 14.03.0496.000

Diamo uno sguardo alla Exchange Management Console, dove sono visibili le mailbox attualmente in uso

Ed eventuali gruppi di distribuzione

Verifica configurazione attuale

Per l’avvio della procedura di migrazione è necessario che il servizio autodiscovery sia configurato correttamente, così come gli URL dei vari servizi siano raggiungibili sia dall’interno che dall’esterno della rete in cui è installato il server Exchange.

I seguenti cmdlet, eseguiti sulla Exchange Management Shell ci restituiranno le configurazioni degli url essenziali:

Se non sono correttamente configurati, possiamo settare i valori necessari sempre dalla Exchange Management Console. Accertiamoci che tutti gli URL siano raggiungibili sia dall’interno che dall’esterno, eventualmente aggiungendo le relative voci nel DNS locale. In particolare, sarà necessario configurare per il servizio EWS e per l’autodiscovery i parametri internalurl ed externalurl uguali all’indirizzo esterno.

Per l’autodiscovery, ad esempio, il nome autodiscover.nomedominio.com dovrà risolvere con il server exchange, ed è consigliato creare un record di tipo CNAME che risolva con l’host con cui raggiungiamo il CAS server (in pratica l’indirizzo dell’OWA)

 

Verifica dei certificati

Affinché la configurazione della modalità ibrida, che vedremo in seguito, vada a buon fine, è necessario che il server con il ruolo CAS sia raggiungibile in HTTPS utilizzando TLS1.2. A questo proposito effettuiamo una verifica del certificato presente su Exchange Server 2010, che deve essere valido per tutti i nomi che puntano al server on-premises. Essendo necessario verificare il certificato da parte di Microsoft 365, è necessario inserire un certificato generato da una Certification Authority pubblica e non è possibile quindi utilizzare un certificato self-signed.

Dobbiamo assicurarci quindi che il certificato sia valido per il dominio su cui risponde il server con il ruolo CAS, ad esempio mail.domain.com, oltre che per tutti i record autodiscover, come ad esempio autodiscover.domain.com, autodiscover.domain2.com, ecc.

Se stiamo migrando un server che gestisce un unico dominio è possibile utilizzare un certificato wildcard, quindi del tipo *.dominio.com

 

Configurazione domini

Iniziamo quindi a preparare l’ambiente Microsoft 365, facendo in modo che sia in grado di ospitare le nostre cassette postali al termine della migrazione. Se non lo abbiamo già fatto creiamo un account per la gestione dei nostri servizi in cloud, attraverso il quale effettueremo tutte le operazioni di configurazione necessarie.

Effettuato l’accesso al Microsoft 365 Admin Center è necessario in primo luogo configurare il tenant in modo che sia in grado di gestire gli utenti su tutti i nostri domini. In particolare, dovremmo verificare la proprietà di tutti i domini che sono presenti sul server Exchange 2010 e che vogliamo migrare in cloud. Dal portale https://admin.microsoft.com posizioniamoci su Setup – Domains

Clicchiamo quindi su Add domain e prendiamo nota del record di tipo TXT da inserire nel pannello di controllo del DNS del nostro dominio per poterne verificare la proprietà. È possibile chiudere la pagina e tornare in un secondo momento per effettuare la verifica. Il record TXT proposto rimarrà lo stesso, possiamo quindi verificarlo anche in tempi lunghi. Se abbiamo più domini possiamo aggiungerli uno alla volta e prendere nota dei record da creare, quindi configurare i vari DNS e poi tornare in questa pagina per eseguire la verifica in seguito. Sarà necessario effettuare la verifica attraverso la creazione del record TXT di tutti i domini da rendere disponibili all’interno di Microsoft 365. Attualmente è possibile aggiungere fino a 900 domini custom allo stesso tenant di Microsoft 365.

Una volta creato il record TXT necessario per la verifica del dominio è possibile cliccare su Verify per aggiungerlo definitivamente su Microsoft 365 e poter quindi aggiungere utenti ed indirizzi con il relativo suffisso.

Se non avete la possibilità di aggiungere il record immediatamente è possibile cliccare su Save and close e tornare su questa pagina in un secondo momento, il record da verificare non sarà cambiato. Nel caso ci siano da verificare molti domini quindi sarà possibile prendere nota di tutti i record, crearli nel pannello di gestione DNS, e poi tornare per verificarli.

I domini verranno visualizzati ancora con “Setup in progress” poiché non abbiamo ancora terminato la migrazione del record MX, che faremo al termine dello spostamento delle cassette postali.

 

Modalità ibrida

A questo punto possiamo creare i connettori per far “dialogare” correttamente tra loro Office 365 ed il server Exchange on-premises, in modo che il sistema possa consegnare la posta indipendentemente dal server che ha in carico la mailbox di destinazione. La modalità ibrida consentirà quindi di migrare le cassette postali a “blocchi”, o anche una per volta, prendendo tutto il tempo necessario; durante la fase in cui alcune cassette postali siano in cloud, ed alcune on-premises, i connettori creati in questa fase si occuperanno di smistare la posta in maniera corretta.

Per creare i connettori ed utilizzare quindi la modalità ibrida di Exchange esiste un tool estremamente comodo, che esegue per noi tutti i controlli necessari, e quando è tutto configurato correttamente, eseguirà le modifiche necessarie sull’infrastruttura. Il tool si chiama Hybrid Configuration Wizard, spesso abbreviato in HCW, ed è disponibile al link https://aka.ms/HybridWizard

Al momento è disponibile la versione 17, che necessita di .NET Framework 4.7.2, che va scaricato ed installato separatamente.

Una volta installato, Hybrid Configuration Wizard può essere avviato per procedere con la configurazione del sistema. Confermiamo ovviamente con Install il warning di sicurezza:

Clicchiamo Next

Selezioniamo il server di Exchange on-premises da migrare

Indichiamo un utente con privilegi di Exchange admin ed inseriamo le credenziali del tenant di Microsoft 365.

Confermiamo con Next

Verifichiamo che i servizi siano raggiungibili

Eventuali errori di connessione andranno analizzati leggendo i log di HCW disponibili nella cartella %appdata%\Microsoft\Exchange Hybrid Configuration\

Un esempio di errore, piuttosto ostico, che mi è capitato, era relativo ai protocolli SSL abilitati sulla macchina. Le operazioni di troubleshooting sono descritte nell’articolo https://www.virtuopia.it/2020/05/troubleshooting-connessione-exchange-hybrid-configuration-wizard/

Scegliamo poi il tipo di configurazione Ibrida da abilitare. Scegliamo Full Hybrid Configuration per mantenere attive tutte le funzionalità di Exchange, incluso Free/Busy, messaggio vacanze, eccetera.

Selezioniamo poi i domini per cui vogliamo generare un connettore ibrido

Il sistema ci propone i domini utilizzati sul server Exchange on-premises. Possiamo selezionarli tutti, ed in maniera opzionale possiamo indicare Autodiscover TRUE sul dominio che vogliamo utilizzare per ottenere automaticamente le informazioni relative agli URL utilizzati da Exchange. Questo faciliterà il riconoscimento degli URL dei servizi da parte di Microsoft 365.

Prendiamo poi nota dei record TXT necessari per l’aggiunta dei domini sul tool di configurazione. Questi record non sono legati a quelli che abbiamo aggiunto per la verifica dei domini su Microsoft 365 e vanno creati aggiungendoli a quelli presenti. Una volta completata la configurazione del DNS è possibile cliccare su verify domain ownership. Anche in questo caso è possibile annullare il wizard, effettuare la configurazione del DNS e tornare qui in un secondo momento per verificare i domini. I record TXT proposti saranno gli stessi.

Confermiamo quindi di aver creato i record TXT necessari

È capitato durante alcune configurazioni che a questo punto il tool diventasse unresponsive; in quel caso è stato sufficiente rilanciarlo e ripetere le operazioni per proseguire con la procedura.

Inseriamo quindi un account amministratore on-premises per la creazione degli endpoint di migrazione

Cicchiamo su next se non abbiamo esigenze di abilitare un servizio mail transport centralizzato. In questo caso le e-mail sarebbero inviate tutte dal nostro server on-premises. Normalmente (e nella maggior parte dei casi è la soluzione corretta), anche Office 365 è in grado di inviare posta per i nostri domini.

Selezioniamo il server con il servizio Hub Transport attivo

Inseriamo l’IP pubblico su cui è esposto il nostro Exchange Server 2010, verrà utilizzato per la verifica dei certificati

Selezioniamo il certificato da utilizzare

Inseriamo ora l’FQDN del server SMTP su cui Microsoft 365 inoltrerà le email per consegnarle alle mailbox ancora presenti sull’ Exchange Server 2010. Se abbiamo un relay antispam, ad esempio, dovremo inserire l’indirizzo pubblico di questo server. Solitamente corrisponde al valore del record MX al momento dell’inizio della migrazione dei servizi.

Clicchiamo su update ed attendiamo l’esito

Attendiamo qualche minuto

Ed abbiamo la conferma che il wizard ha effettuato le operazioni richieste, ed i nostri connettori sono creati.

Sincronizzazione utenti e gruppi di Active Directory

È arrivato il momento di sincronizzare gli utenti presenti su Active Directory locale con Azure AD, quindi con gli utenti presenti su Office 365. In primo luogo, è necessario configurare gli UPN (User Principal Name), in modo che corrispondano all’indirizzo e-mail, in modo da copiare tutti gli oggetti direttamente su Microsoft 365 e gestirli dal nostro Domain Controller, poiché verranno sincronizzati in maniera monodirezionale ad intervalli di tempo regolari.

Apriamo Active Directory Domains and Trust sul nostro DC e selezioniamo proprietà

Aggiungiamo i domini di posta come suffissi UPN disponibili

A questo punto assegniamo a tutti gli utenti con mailbox il corretto UPN. Se i logon name corrispondono all’indirizzo e-mail possiamo cambiare in blocco i suffissi UPN selezionando gli utenti direttamente da AD e cliccando su proprietà

Possiamo quindi assegnare il suffisso UPN corretto e confermare con ok

Altrimenti sul singolo utente possiamo cambiare il logon name in modo che corrisponda all’indirizzo e-mail. Il login “classico” con nomedominio\utente non verrà modificato quindi questa modifica non ha impatto sull’utilizzo dell’account all’interno dell’azienda.

Possiamo tranquillamente modificare l’user logon name per avere l’UPN completo che corrisponda all’indirizzo e-mail dell’utente.

Dopo aver attivato la visualizzazione avanzata della console degli utenti AD, assicuriamoci che ci siano tutti gli indirizzi e gli alias dell’utente.

L’indirizzo principale deve essere nella forma

SMTP:[email protected]

Ed eventuali alias nel formato

smtp:[email protected]

Notiamo quindi che l’indirizzo principale ha SMTP maiuscolo, mentre gli alias in minuscolo

Verifichiamo che sia stato creato un indirizzo di tipo smtp:[email protected] poiché servirà ai connettori di Exchange per scambiare le e-mail da Office 365 ad on-premises. Nel caso non sia presente una voce con queste caratteristiche è necessario crearla.

Siamo quindi pronti per sincronizzare tutti gli oggetti di Active Directory legati ad Exchange sul cloud. Per fare ciò abbiamo bisogno di un tool chiamato Azure AD Connect; il software creerà un servizio all’interno della nostra rete aziendale che si occuperà di inviare ad Azure AD tutte le eventuali modifiche agli oggetti di Active directory locale che abbiamo deciso di sincronizzare.

Scarichiamo il tool dal link https://www.microsoft.com/en-us/download/details.aspx?id=47594 ed avviamo il wizard

In condizioni normali procediamo senza aggiungere componenti opzionali

Selezioniamo Password Hash Syncronization, e se volete abilitare il single sign-on mettiamo la relativa spunta. Questo ci consentirà di abilitare il login su Office 365 dai client autenticati in dominio senza reinserire la password. Per maggiori informazioni sul funzionamento del Single Sign-on vi rimando alla lettura della guida Implementare il Single Sign-On (SSO) con Azure AD

Inseriamo le credenziali del tenant

Aggiungiamo il nostro dominio Active Directory cliccando su Add Directory ed inserendo le credenziali di un amministratore

Confermiamo di non voler aggiungere il dominio locale, ma solo quelli verificati

E selezioniamo le organiziational units da sincronizzare. Se abbiamo delle OU dedicate agli utenti con mailbox, ad esempio, sarà possibile sincronizzare solo quelle.

Confermiamo come identificare unicamente i nostri utenti.

Eventualmente settiamo un filtro per gli utenti da sincronizzare.

Selezioniamo Exchange Hybrid deployment

Se abbiamo selezionato Single Sign On inseriamo le credenziali amministrative di un amministratore di dominio.

Ed attendiamo la prima configurazione.

In caso di errori sarà possibile analizzare qui eventuali problemi.

Dopo qualche minuto nella sezione Utenti del Microsoft 365 Admin Center troveremo tutti gli oggetti AD che sono stati sincronizzati.

Nel caso vengano effettuate delle modifiche su Active Directory locale come creazione di utenti, modifica di logon name o di altri attributi, è necessario attendere i tempi di sincronizzazione da parte del servizio AD Connect, che in maniera predefinita è di 30 minuti.

Il periodo di sincronizzazione è configurabile con la guida ufficiale disponibile a questo link https://docs.microsoft.com/it-it/azure/active-directory/hybrid/how-to-connect-sync-feature-scheduler

In alternativa è possibile eseguire il comando PowerShell Start-ADSyncSyncCycle per forzare la sincronizzazione delle modifiche.

Modifichiamo ad esempio l’user logon name di un utente, che non era configurato in maniera corretta per un errore

Ed eseguiamo da Powershell l’importazione del modulo per pilotare AD Connect con Import-Module ADSync e lanciamo la sincronizzazione delle modifiche con Start-AdSyncSyncCycle

Aprendo il Synchronization Service Manager dal menu programmi, sotto la cartella Azure AD Connect, verifichiamo che il servizio sta effettuando l’operazione di sincronizzazione richiesta.

Cliccando su Updates abbiamo il dettaglio dell’elemento modificato, che stiamo andando a sincronizzare.

A questo punto nella sezione utenti attivi di Microsoft 365 troveremo il dato aggiornato, ed il nostro utente ora avrà l’indirizzo e-mail corretto.

Per assegnare una cassetta postale Office 365 a questi utenti e quindi utilizzarli per la migrazione della posta sarà necessario assegnare le relative licenze. Nel nostro caso stiamo assegnando delle licenze Office 365 E3 in blocco a tutti gli utenti

Migrazione delle cassette postali

Passiamo quindi alla creazione dei job di migrazione veri e propri, che consentiranno lo spostamento della cassetta postale dai database interni di Exchange Server 2010 a quelli di Exchange Online. Dall’Exchange Admin Center di Office 365 selezioniamo Recipients e clicchiamo sul tasto + in alto a sinistra; selezioniamo quindi Migrate to Exchange online per indicare il verso dello spostamento.

Selezioniamo quindi Migrazione remota e clicchiamo su avanti per selezionare gli utenti da migrare. È possibile migrare un singolo utente o scegliere di migrare tutti in blocco. Solitamente utilizzo uno o due utenti per provare i primi spostamenti per poi migrare in blocco tutti i restanti. Questo darà il via alla copia della cassetta postale su Exchange Online; il processo verrà completato solo al momento della “finalizzazione”.

Selezioniamo l’endpoint di migrazione.

Configuriamo il batch per migrare l’eventuale archivio insieme alla mailbox principale.

E scegliamo quando avviare il processo, in particolare se avviarlo immediatamente oppure ad un orario predefinito, magari di notte oppure quando sappiamo che l’attività in rete è ridotta.

In questo step dobbiamo anche indicare se finalizzare automaticamente lo spostamento, e quindi cancellare la cassetta postale dall’Exchange on-premises, oppure tenere la cartella sincronizzata fino a quando non decidiamo di finalizzare manualmente.

Una volta avviato il processo vedremo dapprima il batch nello stato “Syncing”, ed una volta terminato noteremo nello status la dicitura “Synced”. Questo indica che abbiamo la cassetta postale sincronizzata tra il server in casa e quello in cloud, e ci verranno mostrati nei dettagli eventuali errori, con la specifica di eventuali oggetti non sincronizzati.

A questo punto il client, e la eventuale webmail sta ancora puntando al vecchio server, e non è ancora cambiato nulla per quanto riguarda lo storage ed il routing della posta. Tutto quello che abbiamo fatto è una copia, che viene aggiornata in tempo reale, della cassetta postale di uno o più utenti. Una volta analizzati gli errori quindi, ed eventualmente effettuata una copia locale degli elementi con errore, possiamo procedere alla finalizzazione, che finalmente sgancerà la cassetta postale dal nostro Exchange Server 2010 locale e lascerà gestire la posta ad Exchange Online.

Consiglio una lettura attenta della pagina https://docs.microsoft.com/it-it/exchange/mailbox-migration/manage-migration-batches dove viene mostrata la gestione dei diversi tipi di batch di migrazione.

Per averne la conferma possiamo cliccare con il tasto destro sull’icona di Outlook nel systray (vicino all’orologio) mentre premiamo il tasto CTRL, e quindi selezionare “Stato connessione” dal menu contestuale.

Verrà mostrato l’indirizzo del server a cui siamo connessi, con le specifiche del protocollo utilizzato. Nel nostro caso siamo collegati al server locale EXCHANGE2010.migrationdemo.local tramite RPC.

Provando ad accedere alla webmail di Office365, essendo la mailbox ancora su Exchange 2010, otterremo il link per utilizzare il vecchio OWA

Seguendo il link arriveremo quindi sulla nostra webmail.

Procediamo velocemente creando un batch per migrare tutti gli altri utenti.

Attendiamo lo stato passi su “Synced”. Ovviamente potrebbero essere necessarie ore o giorni per il completamento dell’operazione, a seconda delle dimensioni delle cassette postali.

Sulla Exchange Management Console del server locale vedremo le migrazioni in corso indicate con un’icona con una freccia verde.

Una volta sincronizzate le mailbox, se abbiamo scelto la finalizzazione manuale andiamo a selezionare “Complete this migration batch”, e confermiamo la scelta, per finalizzare la migrazione delle mailbox.

Dopo pochi minuti, le mailbox saranno disponibili su Office365, ed i client Outlook riceveranno una richiesta di reinserimento della password.

Una volta effettuato il login il client sarà connesso ad Exchange Online, senza la necessità di dover riscaricare la mailbox completa, poiché il client continuerà ad utilizzare sempre lo stesso file .OST di cache locale.

Noteremo che nell’Exchange Admin Center sarà visualizzata la mailbox migrata.

E che la stessa sarà ovviamente stata eliminata dall’Exchange Server 2010 locale.

È doveroso un test per assicurarci che il routing tra i due server funzioni correttamente e consiglio vivamente di effettuare le seguenti verifiche, assicurandoci di ottenere esito positivo prima di procedere con la migrazione di tutti gli account:

• Effettuare un invio e-mail da un dominio esterno ad una mailbox su Exchange locale
• Effettuare un invio e-mail da un dominio esterno ad una mailbox su Exchange Online
• Effettuare un invio e-mail sul dominio interno da Exchange locale ad Exchange Online
• Effettuare un invio e-mail sul dominio interno da Exchange Online ad Exchange Locale
• Effettuare in invio da Exchange locale verso l’esterno
• Effettuare in invio da Exchange online verso l’esterno

Una volta appurato che il traffico e-mail sia esente da problemi e che la posta venga consegnata correttamente in tutti i casi, possiamo procedere con il completamento della configurazione dei domini su Microsoft 365, inserendo nella configurazione del DNS i record necessari alla consegna della posta direttamente ad Exchange Online ed alla configurazione automatica dei client. Verificare il corretto funzionamento del routing tra Exchange Server locale ed Exchange Online, inoltre, ci assicura che l’operazione di cambio del record MX può essere effettuata in qualsiasi momento, poiché abbiamo la sicurezza che, quando viene consegnato un messaggio, questo arrivi a destinazione sia se viene ricevuto dai server locali, sia da quelli in cloud, indipendentemente dal posizionamento della mailbox di destinazione.

Selezioniamo quindi Setup – Domains dal Microsoft 365 Admin Center e procediamo con la configurazione dei record MX e CNAME per l’autodiscover

Microsoft 365 admin center ci confermerà che i domini sono configurati correttamente.

Se necessario è possibile aggiungere il server Exchange in cloud sulla console locale del nostro Exchange Server 2010; per fare questo una volta avviata la console locale fare click su Microsoft Exchange scegliere Add Exchange forest

Vedremo così l’ambiente Office 365 direttamente nella console, ormai legacy, di Exchange 2010

Decommissioning di Exchange Server 2010

Ora abbiamo tutto il necessario per procedere alla migrazione e dire addio al tanto amato Exchange Server 2010; un addio un po’ strano a dire il vero poiché Microsoft consiglia vivamente di non dismettere il vecchio server, seppure non sia presente alcuna mailbox da gestire, poiché disinstallando i servizi di posta locali si perderebbe la gestione di alcune caratteristiche di Active Directory. Prendiamo quindi per buono questo suggerimento, ed il nostro lavoro finisce qui.

Per un approfondimento sulla dismissione di Exchange Server 2010 vi rimando ad un recente articolo di Albano Lala, in cui sono analizzati diversi scenari https://www.ictpower.it/microsoft-365/rimuovere-exchange-servers-on-premises-dopo-la-migrazione-ad-exchange-online-e-possibile.htm