Guida: come eseguire la migrazione di Exchange a Office 365 – 1° Parte

Se si pianifica una migrazione da Exchange a Office 365, può essere piuttosto complesso comprendere tutti i passaggi e sapere in quale ordine eseguirli. In questa guida vengono descritte le decisioni da prendere e i passaggi da seguire per effettuare una migrazione dal server locale ad Exchange Online.

In questa prima parte, considereremo i primi passi più importanti per:

  • decidere un approccio di migrazione
  • eseguire i passaggi principali per l’identità.

N.B!
Prima di iniziare, è necessario garantire che l’ambiente locale sia privo di errori e, se presenti, individuarli e correggerli prima di pensare alla migrazione. Infatti, se si verificano problemi giornalieri con Exchange come ad esempio problemi degli utenti che lavorano da remoto, messaggi di errore, tempi di accesso lenti alle cassette postali o, peggio ancora, danneggiamento del database, il passaggio a Office 365 sarà molto probabilmente un’altra fonte di problemi non solo per le persone che avranno accesso all’ambiente, ma anche durante la migrazione stessa.

Quale tipo di migrazione attuare?

Per spostare l’ambiente Exchange in Office 365, esistono diverse possibilità.

Microsoft offre:

  • Staged Migration
  • Cutover  Migration
  • Hybrid Migration

Inoltre, da fornitori di terze parti sono disponibili un gran numero di strumenti sul mercato che permettono di eseguire la migrazione di cassette postali e archivi di posta elettronica.

 In generale, se si dispone di una versione di Exchange Server supportata da Microsoft (Exchange Server 2010 e versioni successive) e fa parte di Active Directory, l’opzione predefinita dovrebbe essere una migrazione ibrida di Exchange (Hybrid Migration).

Una migrazione ibrida di Exchange può essere minima (Minimal) o completa (Full) e crea una relazione tra il server Exchange locale e quello Online.

 Ciò consente spostamenti nativi delle cassette postali, simili a quelli che avvengono tra server Exchange locali, con i client Outlook che cambiano in modo nativo senza nemmeno dover scaricare nuovamente le copie offline della posta elettronica. Con l’ibrido completo, questo si estende anche alla protezione del flusso di posta tra i due ambienti e alle funzionalità di coesistenza come la condivisione della disponibilità (libero/impegnato) e del calendario.

Azure AD – sincronizzare l’identità locale con il cloud

Il prerequisito chiave per la migrazione a Exchange è garantire che il modello di identità corretto sia in atto. Nella scelta di un’identità sono disponibili diverse opzioni, ma lo scenario più comune sarà l’utilizzo di Azure AD Connect con identità e password sincronizzate.

Azure AD Connect integra Exchange Hybrid ed è consigliato utilizzare questa modalità se si prevede di sincronizzare l’ identità on-premise con il cloud. AD Connect sincronizza il dominio di Active Directory locale con Office 365, creando una copia degli account dell’ Active Directory locale in Azure Active Directory che rimandano alle copie master stesse. Azure AD Connect è anche la parte del puzzle che mantiene un elenco di indirizzi globale coerente tra locale e cloud.

Poiché AD e Azure AD Connect comprendono quando è presente un’organizzazione di Exchange esistente, le cassette postali locali già presenti non verrano ricreate in Office 365; utilizzeremo Exchange Hybrid per spostarle nel cloud.

Con una migrazione basata su strumenti di terze parti, non si applicano le stesse regole. Una migrazione ibrida di Exchange, completamente supportata da Microsoft, offre un’esperienza completa. Tuttavia, soprattutto in ambienti con più foreste può essere complessa da configurare correttamente poichè gli ambienti ospitati spesso non consentono la configurazione di Azure AD Connect o Exchange Hybrid; inoltre, se si dispone di versioni legacy di Exchange, sarà necessaria l’installazione di un server addizionale che esegue Exchange 2010 o una versione successiva (deve includere i componenti ibridi).

Pertanto, esistono ulteriori strumenti di migrazione validi, ma in questo articolo presumiamo che tu abbia preso la decisione di usare Exchange Hybrid.

Preparazione della migrazione da Exchange a Office 365

Dopo aver deciso che la migrazione a Office 365 tramite Exchange Hybrid è adatta all’organizzazione e si dispone di un ambiente integro di cui eseguire la migrazione, è necessario assicurarsi di aver completato le attività di pianificazione necessarie.

Prima di procedere con la migrazione vera e propria sarà necessario completare alcuni prerequisiti:

  • Aggiungere nuovo dominio al portale di Microsoft 365 e verificarlo attraverso nel proprio DNS con un record txt
  • Aggiungere un suffisso UPN all’Active Directory locale se necessario e modificarlo per tutti gli utenti che verranno sincronizzati sul cloud
  • Scaricare Microsoft IDFix ed eseguirlo sul domain controller per scongiurare la presenza di problemi rilevanti all’interno di Active Directory per la sincronizzazione del dominio
  • Installare Azure AD Connect per sincronizzare la directory locale con quella cloud

Aggiungere nuovo dominio al portale di microsoft 365

Innanzitutto, ci assicureremo di aver aggiunto tutti i domini personalizzati al tenant di Office 365. Questi dovranno corrispondere ai domini di posta elettronica che utilizziamo in locale.

Per aggiungere un nuovo dominio, scegliere <Path> e Add domain. È necessario eseguire la procedura e verificare ogni dominio utilizzando un record TXT, simile a quello illustrato di seguito:

Utilizzare il pannello di controllo del vostro provider DNS per aggiungere il record TXT corrispondente a ogni dominio, quindi continuare il processo di verifica.

Una volta aggiunto il record DNS, è importante scegliere di ignorare l’ aggiunta di record come l’individuazione automatica o le modifiche ai record MX.

 Questo è fondamentale perché a questo punto del processo la posta elettronica viene ancora esaminata dai sistemi locali e non si desidera reindirizzare i client a Office 365. La relazione ibrida che andremo a creare lo gestirà per noi.

Aggiungere un suffisso UPN

Per accedere a Office 365 viene utilizzato un ID di accesso nello stesso formato di un indirizzo di posta elettronica, nel nostro caso è username@cloudsurferstest.it. In una relazione ibrida di Exchange, si prevede che per ogni utente corrisponda l’ UPN (UserPrincipalName) dell’ Active Directory locale. Tuttavia, in molte organizzazioni, gli ID di accesso non sono in un formato adatto ad esempio se il dominio locale è .local o .lan. Il risultato di una mancata corrispondenza sarà un ID di accesso a office 365 contenente onmicrosoft.com:

ID di accesso localeUserPrincipalName localeIndirizzo SMTP primarioID di accesso a Office 365 risultante
TEST\usernameusername@test.lanusername@cloudsurferstest.itusername@cloudsurferstest. onmicrosoft.com

Nella tabella precedente, il problema riguarda il suffisso UPN, che in genere corrisponde al nome completo della foresta di Active Directory locale, nel nostro caso test.lan. Per risolvere il problema, aggiungeremo un suffisso UPN per abbinare i domini di posta elettronica registrati con Office 365. Apriamo Active Directory Domains and Trusts accessibile dalla sezione Tools del Server Manager:

Clicchiamo con il tasto destro su Active Directory Domains and Trusts sopra la freccia indicata dall’immagine e poi clicchiamo su Proprietà. Aggiungiamo il suffisso UPN alternativo cliccando su Add e poi confermiamo con Ok. Dopo aver aggiunto il suffisso UPN, sarà necessario modificarlo nel logon di tutti gli utenti che desideriamo sincronizzare. E’ possibile modificarlo manualmente tramite Server Manager>Tools>Active Directory Users and Computers.

Se gli utenti sono tanti, anzichè modificare singolarmente il suffisso come mostrato sopra, è possibile utilizzare il seguente comando powershell

N.B.: -SearchBase “…” specifica le Unità Organizzative per le quali si intende applicare la modifica, personalizzarlo con il nome della propria OU o rimuoverlo se si intende modificare il suffisso per tutti gli utenti pre senti in AD.

$LocalUsers = Get-ADUser -Filter "UserPrincipalName -like '*test.lan'" -SearchBase "OU=test_users,DC=test,DC=lan" -Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@test.lan","@cloudsurferstest.it"); $_ | Set-ADUser -UserPrincipalName $newUpn}

Dopo aver apportate queste modifiche, gli utenti che appartengono alla OU test_users potranno loggarsi alle loro macchine sia con il formato Pre-Windows 2000 TEST\username che con nomeutente@cloudsurferstest.it. I formati per gli ID di accesso ora risulteranno simili ai seguenti:

ID di accesso localeUserPrincipalName localeIndirizzo SMTP primarioID di accesso a Office 365 risultante
TEST\usernameusername@test.lan
username@cloudsurferstest.it
username@cloudsurferstest.itusername@cloudsurferstest.it

Eseguire IDFix

Verrà ora eseguito lo strumento Microsoft IDFix sul dominio. Questo passaggio evidenzierà eventuali problemi rilevanti all’interno di Active Directory per la sincronizzazione del dominio. IDFix identifica errori, ad esempio indirizzi di posta elettronica non validi (noti come indirizzi proxy), caratteri non validi nei nomi utente e in altri dati e problemi comuni, ad esempio proprio l’utilizzo di un suffisso UPN non valido.

Nell’immagine infatti vediamo un errore riferito ad un indirizzo che ha mantenuto il dominio test.lan poiché non si trovava all’interno dell’OU filtrata nel comando powershell per la sostituzione dell’UPN eseguito in precedenza. Se avessimo eseguito IDfix prima di lanciare quel comando, o prima ancora di aggiungere il suffisso UPN, sarebbe stato mostrato un errore simile per ogni utente presente nell’Active Directory locale. Dopo aver verificato che non ci siano errori significativi è possibile installare Azure AD Connect.

Installare e configurare Azure AD Connect

Prima di installare AD Connect assicurati di rispettare i prerequisiti QUI. Procedere con l’installazione, al termine della quale sarà richiesto di accettare termini e condizioni, confermare cliccando sul pulsante Continue.
Anziché eseguire l’opzione predefinita Express Settings che utilizza le impostazioni rapide, in questa guida eseguiremo un’ installazione personalizzata per configurare AD Connect in base alle nostre esigenze. Nella pagina successiva clicchiamo quindi su Customize.

Nella pagina seguente è possibile personalizzare il processo di installazione dei componenti necessari, ad esempio è possibile specificare un percorso di installazione diverso da quello predefinito, utilizzare un istanza di SQL Server esistente o importare il file .json contenente le impostazioni di una configurazione eseguita in precedenza. Lasceremo deselezionate tutte le opzioni, Azure AD Connect configura tutti gli elementi automaticamente. Viene configurata un’istanza di SQL Server Express locale , vengono creati i gruppi appropriati e vengono assegnate le autorizzazioni necessarie. Clicchiamo su Install.

Ci verrà chiesto di selezionare il metodo di Sign On degli utenti. Utilizzeremo il classico Password Hash Syncronization per fare in modo che gli utenti possano accedere ai servizi di Microsoft 365, usando la stessa password della rete locale. Quando si modifica una password nell’AD locale, la password aggiornata viene sincronizzata, di solito in pochi minuti. Inoltre, abilitando il seamless single sign-on, gli utenti potranno accedere facilmente alle applicazioni basate sul cloud di Microsoft senza digitare le proprie credenziali. Affinchè questo sia possibile, verrà creato un computer account ( AZUREADSSOACC ) all’interno dell’ Active Directory locale in ogni foresta di Active Directory sincronizzata con Azure AD. Clicchiamo su Next.

Seguiremo quindi i passaggi della procedura guidata per connetterci sia al tenant di Azure AD/Office 365 con le credenziali di un account Amministratore Globale che all’Active Directory locale con un utente membro del gruppo Enterprise Admin.

Nello specifico, per connettere l’active directory locale clicchiamo su Add directory, inseriamo le credenziali e selezioniamo Create new AD account. Questa operazione farà si che vengano creati tutti gli account necessari per la sincronizzazione delle directory. Clicchiamo Next.

Si ricorderà che in precedenza è stato aggiunto un suffisso UPN alternativo all’active directory locale perché test.lan non era un dominio valido da usare con Office 365. Questo verrà evidenziato durante l’installazione guidata, tuttavia, poichè abbiamo già affrontato questo problema sarà possibile continuare:

Per impostazione predefinita, tutti i domini e le unità organizzative (OU) sono sincronizzati. Se non si desidera sincronizzare alcuni domini o unità organizzative per Azure AD, è possibile deselezionarli. Come accennato in precedenza a noi interessa che vengano sincronizzati solo gli utenti che fanno parte dell’OU “test_Users”. Clicchiamo quindi su Next.

E’ possibile definire il modo in cui gli utenti sono identificati nell’AD locale e in Azure AD. Un utente locale può essere rappresentato solo una volta in tutte le foreste come nel nostro caso o potrebbe avere una combinazione di account abilitati e disabilitati in altre foreste o directory.

N:B: Se ad esempio sono già presenti utenti nel tenant di Azure occorrerà fare in modo che il match tra utente locale avvenga tramite un attributo come ad esempio Mail Attribute.

Selezionare poi l’attributo sourceAnchor, ossia la chiave primaria che identifica in modo univoco un oggetto come lo stesso oggetto sia in locale che in Azure AD. L’attributo sourceAnchor può essere configurato solo durante l’installazione iniziale e non può essere modificato (chiamato anche immutableId). Noi lasceremo che Azure AD selezioni automaticamente l’attributo da utilizzare che per le versioni recenti di AD Connect corrisponde a ConsistencyGuid. Clicchiamo Next.

E’ possibile sincronizzare solo un piccolo subset di oggetti. Tutti gli oggetti che si desidera sincronizzare devono essere membri diretti del gruppo. Nel nostro caso ci è sufficiente il filtro utilizzato in precedenza in base alle OU. Sincronizziamo tutti gli utenti e i dispositivi e clicchiamo Next.

Il prossimo passo sarà quello di selezionare le funzionalità aggiuntive. Sarà necessario garantire che l’opzione relativa alla distribuzione ibrida di Exchange sia selezionata prima di iniziare l’installazione. In questo modo azure AD Connect scriverà gli attributi correlati a Exchange nell’ad locale. Abiliteremo anche il writeback delle password per assicurarci che le modifiche apportate alle password in Azure AD vengano riportate anche nella directory locale. Clicchiamo Next.

L’ultima cosa da fare è quella di inserire le nostre credenziali di amministratore di dominio per utilizzare il single sign on abilitato in precedenza. Cliccare su Enter credenziale, inserire le credenziali e proseguire con Next.

Terminare la procedura di configurazione e avviare la prima sincronizzazione cliccando Install.

Terminata l’installazione avrà inizio la prima sincronizzazione. Le sincronizzazioni avvengono ogni 30 minuti ed è possibile controllarle avviando il programma Syncronization Service che risulterà installato insieme ad AD Connect.

Una volta completata la sincronizzazione iniziale, è necessario essere in grado di accedere a Microsoft 365 Admin Center e passare a Utenti>Utenti attivi per visualizzare gli account sincronizzati. Vedrai gli utenti di Active Directory nello stato sincronizzato con Active Directory. E’ possibile effettuare la verifica anche tramite il portale di azure su Azure Active Directory>Utenti.

Riepilogo

In questa guida sono stati descritti i passaggi per configurare i prerequisiti necessari per preparare l’ambiente alla migrazione. Nel prossimo appuntamento implementaremo Exchange Hybrid e migreremo le cassette postali in Office 365.

Nel frattempo se ha qualche domanda, non esitare a contattarci! Potremo valutare insieme la soluzione ideale per il tuo ambiente e guidarti nel processo di migrazione nel migliore dei modi.

CLICCA QUI per leggere la seconda parte!

Link Utili & Credits

https://docs.microsoft.com/it-it/azure/active-directory/hybrid/how-to-connect-install-custom

1 commento su “Guida: come eseguire la migrazione di Exchange a Office 365 – 1° Parte

  1. Pingback: Guida: come eseguire la migrazione di Exchange a Office 365 - 2° Parte | Fontana Marco IT Consulting

I commenti sono chiusi.