Migrace několika forestů do Office 365

  • Article

V tomto článku se budeme zabývat migrací Exchange z několika forestů do jednoho tenant v Office 365.

2 Teoretický přehled

Office 365 tenant si z pohledu zákazníka představíme, jako jeden forest, který má po úspěšné migraci obsahovat informace o všech příjemcích z on premise forestů. Identity v on premise forestech jsou reprezentovány pomocí SMTP adres (Simple Mail Transfer Protocol), UPN (User Principal Name) a dalších atributů, které však již z pohledu Exchange nejsou nejdůležitější. Za účelem migrace / hybridního nasazení několika forestů s Office 365 je potřeba splnit požadavky, které vycházejí i z obecných principů přenosu zpráv přes SMTP:

  • Identity musí být unikátní (UPN a smtp adresy se nesmějí shodovat u synchronizovaných identit z více forestů. Vždy platí, že k jedné identitě náleží právě jeden mailbox. Nelze tedy z pohledu Exchange kombinovat atributy identit z několika forestů do jedné identity v Office 365)
  • Pokud použijeme k synchronizaci identit AADSync (Azure Active Directory Synchronization Service), je potřeba, aby ze serveru, na kterém běží AADSync, bylo možné přistoupit do AD (Active Directory) jednotlivých forestů.
  • Pokud používáme k synchronizaci starší nástroj DirSync (Directory Synchronization Tool), doporučujeme provést upgrade na AADSync. Není-li to z jakéhokoliv důvodu možné, můžeme použít jeden DirSync server pro každý forest, určený k migraci do Office 365.
  • Při migraci několika forestů se může stát, že budeme potřebovat přidat akceptovanou doménu do našeho tenanta v Office 365. Před migrací je tedy dobré zjistit, zda je vůbec možné MSOL doménu (AD Doména v Office 365) přidat, případně MSOL doménu odstranit z tenanta, ve kterém není potřeba.
  • Autentizace pomocí ADFS (Active Directory Federation Services) je podporovaná, chceme-li použít jenom jednu ADFS farmu pro více MSOL domén z několika forestů, je potřeba foresty protrustovat a správně nastavit Relaying Party Trust na ADFS farmě.

Příklady infrastruktury pro synchronizaci identit do Office 365 tenanta jsou uvedeny v obrázcích

image
Obrázek 1: Synchronizace pomocí DirSync

image
Obrázek 2: Synchronizace pomocí AADSync

2.1 Unikátní identifikátory synchronizovaných objektů

Podíváme-li se na identity z on premise řešení a identity v Office 365, je potřeba je „párovat“, abychom docílili propojení jedné identity on premise s jednou identitou v Office 365. V naprosté většině případů, kdy migrujeme pouze jeden on premise forest do jednoho tenanta v Office 365, si vystačíme s mapováním, kdy ObjectGUID (SourceAnchor) on premise je zakódován do base 64 a následně zapsán do Office 365 jako ImmutableID.

ImmutableID nemusí být dostačující v případě migrace několika on premise forestů do Office 365. ImmutableID se při přesunu objektu mezi lolálními foresty mění. Důsledkem změny ImmutableID může být rozpojení mailboxu v Office 365 a další nepříjemnosti.

Před migrací několika forestů do Office 365 zvažte, zda budete potřebovat přesouvat synchronizované objekty mezi foresty. Pokud ano, změňte unikátní identifikátor jednotlivých synchronizovaných identit dle článku: https://technet.microsoft.com/en-us/library/dn510975.aspx

2.1.1 Volba správných objektů k synchronizaci do Office 365

Migrujeme-li do Office 365 pouze jeden forest, omezujeme volbu objektů k synchronizaci například jednoduchým filtrem na organizační jednotky. Tento filtr nastavíme při konfiguraci AADSync nebo DirSync.

Při migraci několika forestů je ale situace složitější. Uživatelský mailbox ve forestu A například může být zároveň kontaktem ve Forestu B a tím pádem se jeden nebo druhý objekt nebude synchronizovat a nahlásí chybu (duplikované SMTP adresy). Problém však má relativně jednoduché řešení. Při nastavování AADSync si můžeme zvolit způsob, jakým odlišit objekty k synchronizaci za pomocí filtru některých AD atributů.

image
Obrázek 3: Příklad filtrování kontaktů přes AADSync

Filtry objektů konfigurujeme přes „Synchronization Service (pro filtrování na bázi organizačních jednotek)“ a „Synchronization Rules Editor (pro filtr přes atributy)“. Více v článku https://msdn.microsoft.com/en-us/library/azure/dn801051.aspx.

2.1.2 AADSync a DirSync pro Office 365

Rozdíly v produktech určených pro synchronizaci identit do Office 365 jsou dobře popsány v následujícím článku https://technet.microsoft.com/en-us/library/dn510976.aspx. Pro naše potřeby bude stačit výčet rozdílů, ať můžeme zvolit správnou verzi synchronizačního nástroje. S ohledem na možnosti AADSync je použití DirSync spojeno spíše s výjimečnými případy. Další možností je využití plné verze FIM, která bohužel zatím nepodporuje synchronizaci hesel.

2.1.2.1 AADSync
  • AADSync je software, který obsahuje FIM (Forefront Identity Management) verze 2010 R2 (FIM 2010 R2 hotfix 4.1.3496.0 nebo pozdější) s předkonfigurovaným konektorem
  • AADSync podporuje synchronizaci více on premise AD forestů do Office 365
  • AADSync podporuje synchronizaci hesel z více on premise AD forestů do Office 365365 (ve formě hashe – jde o hash hashe hesla, který se provede pomocí algoritmu SHA265 před synchronizací do Office 365)
  • AADSync podporuje synchronizaci on premise řešení bez MS AD.
  • AADSync v kombinaci s Exchange 2013 SP1+ podporuje hybridní prostředí s více on premise AD foresty
2.1.2.2 DirSync
  • Je software, který v sobě obsahuje FIM konektor verze 2010
  • DirSync je primárně určen k synchronizaci identit z jednoho on premise AD forestu do Office 365.
  • DirSync použijeme v případě, že budeme potřebovat synchronizovat pouze jeden on premise AD forest do Office 365.
  • DirSync podporuje také synchronizaci hesel do Office 365 (ve formě hashe – jde o hash hashe hesla, který se provede pomocí algoritmu SHA265 před synchronizací do Office 365)
  • DirSync nepodporuje synchronizaci on premise řešení, která nejsou založená na MS AD.

3 Postup

Office 365 tenant si z pohledu zákazníka představíme jako single forest. Přípravné práce pro migraci nových identit provedeme v následujícím sledu:

  • Přidáme a ověříme MSOL domény do cílového tenanta (vyřešíme odebrání MSOL domén, pokud je máme v jiném tenantu). Dejte si pozor na testovací tenanty. Dost často se stává, že si společnosti založí testovací tenant s produkční doménou, tenant za 3 měsíce vyprší a problém je na světě, protože doménu je problematické smazat a použít.
  • Připravíme si jednotlivé foresty pro migraci do Office 365. Opět stačí dodržet obecné postupy pro přípravu on premise prostředí (zejména health check, OnRAMP, dodání patřičných DNS záznamů, otevření portů na firewallu …)
  • Zkontrolujeme, zda jsou identity unikátní napříč foresty. Nejzákladnější ověření provedeme kontrolou
  • Z pohledu Azure AD zajistíme, aby každý uživatel napříč foresty měl unikátní ID. ObjectGUID není v tomto případě příliš vhodný, protože se může měnit při přesunu objektu mezi foresty. Vhodné je třeba použít ID zaměstnance. (vice zde: https://technet.microsoft.com/en-us/library/dn510975.aspx )
  • UPN, SMTP aliasy – zajistíme, aby jednotliví uživatele použili unikátní UPN. Identity s nesprávným nebo s již existujícím UPN nebudou synchronizovány. Totéž platí pro zdvojené SMTP adresy.
  • V případě potřeby změníme unikátní identifikátor z implicitních atributů na jiný (Týká se hlavně situací, kdy víme, nebo počítáme s možností migrovat objekty mezi foresty on premise)
  • Zvolíme postup identifikace objektů pro synchronizaci, pokud se nacházejí ve více forestech.

3.1 Migrace forestů s hybridem

Microsoft během roku 2014 výrazně propracoval a vylepšil možnosti propojit Exchange v několika forestech do jednoho tenanta v Office 365 (https://technet.microsoft.com/en-us/library/jj873754(v=exchg.150).aspx). K propojení je potřeba splnit několik požadavků:

  • Zajistíme přístup do všech forestů z Office 365 na: port 443 (webové služby jako Autodiscover, Outlook Anywhere, MRS Proxy, ADFS a další) port 25 pro SMTP.
  • Zajistíme přístup na porty 25,443,80 směrem do cloudu
  • Důvěryhodné certifikáty pro všechny endpointy, dostupné z internetu
  • Pokud plánujeme použít autentizaci přes ADFS, zajistíme buď jednu ADFS farmu pro každý forest, nebo trust mezi foresty s tím, že je potřeba patřičně nastavit ADFS servery
  • Nainstalujeme alespoň jeden Exchange 2013 SP1+ hybridní server (CAS i MAILBOX roli) pro každý on premise AD forest. EDGE role není povinná, i když hybridní mailový provoz skrze EDGE server je podporovaná varianta.
  • Zajistíme, aby každý forest měl alespoň jeden autoritativní SMTP namespace. V případě, že některé SMTP domény jsou použity ve více forestech, je potřeba korektně nastavit a otestovat, že funguje správně autodiscover. V praxi to znamená mít nastavené domény na internal relay a správně vytvořit mail usery pro recipienty, jejichž mailbox se nachází v dalších forestech, sdílejících jeden namespace. Autodiscover pro každý forest bude unikátní. Dále musíme zohlednit filtrování objektů dle předchozích kapitol.
  • Nainstalujeme server s AADSync (nemusí být v doméně) a nakonfigurujeme všechny foresty tak, aby AADSync server byl schopen se k nim připojit.
  • Spustíme HCW (Hybrid Configuration Wizard) a nastavíme dle doporučení pro primární forest (použijeme primární SMTP namespace pro první forest). HCW mimo jiné vytvoří trust mezi Exchange v on premise a Microsoft Federation Gateway, který je nedílnou součástí jakéhokoliv hybridního nasazení Exchange, nebo vytváření trustu mezi Exchange organizacemi.
  • Následně spouštíme HCW pro sekundární forest, kdy zvolíme primární SMTP namespace sekundárního forestu.
  • Při hybridním nasazení Exchange a Exchange Online je možné migrovat mailboxy v dávkách a je umožněn také Offboarding mailboxu (zpětná migrace do on premise)
  • Pro zajištění co nejlepší koexistence mezi Office 365 a Exchange on premise doporučujeme migraci on premise řešení na Exchange 2013 s posledním CU ( Cumulative Update - k datu vydání CU7, na cestě CU8)

3.2 Migrace forestů Cutover migrací

Při migraci několika forestů do tenantu v Office 365 pomocí Cutover migrace, migrujeme jednotlivé on premise foresty sériově, tedy za sebou. Migrace probíhá standardním způsobem dle článku https://technet.microsoft.com/en-us/library/jj874016(v=exchg.150).aspx:

  • Synchronizujeme identity
  • Vytvoříme migrační endpoint
  • Zajistíme, aby veškeré objekty, které potřebujeme migrovat do Office 365, byly viditelné v GALu (objekty, které Exchange Online neuvidí v GALu, nebudou migrovány)
  • Vytvoříme migrační dávku, necháme synchronizovat do Office 365
  • Přenastavíme MX záznamy do Office 365
  • Smažeme migrační dávku (rozdílová synchronizace schránek)
  • Provedeme post-migrační kroky, jejichž cílem je úplné odstranění Exchange on premise
  • Opakujeme postup pro další foresty

4 Závěr

Hybridní prostředí s Office 365 jsou obecně více propracovaná řešení. Konsolidace a migrace pomocí hybridních řešení, jsou z pohledu konfigurace a testů časově mírně náročnější varianty. Investice do těchto řešení se však vyplatí hlavně uživatelským a administrátorským komfortem při samotných migracích, ale i správě řešení. Oproti tomu migrace metodou CutOver je vyloženě určená pro nízkorozpočtové a menší konsolidace, kde by instalace a konfigurace hybridních serverů, byly nerentabilní. Typickým příkladem jsou společnosti do několika stovek uživatelů bez vlastní infrastruktury, postavené na produktech třetích stran.

Věříme, že Vám článek přinesl inspiraci a přejeme hodně úspěchů při migracích do Office 365.

Zbyněk Saloň, KPCS CZ

KPCS CZ je přední českou firmou specializující se na nasazení, správu a podporu informačních technologií, primárně zaměřenou na produkty společnosti Microsoft. Jako systémový integrátor poskytuje kvalitní podniková řešení na této platformě, která jsou v pravidelných intervalech hodnocena prvními příčkami v soutěžích Microsoft Awards. KPCS CZ disponuje předními odborníky na problematiku veřejného cloudu, tedy služeb Office 365 a Azure, ale i technologií privátního cloudu Windows Server, Hyper-V a produktů rodiny System Center.