V první a druhé části částech tohoto seriálu, jsme se podívali na důležité aspekty přípravy před migrací a také na jednotlivé typy migrací. V této poslední části se zaměříme na důležité oblasti samotné migrace.
Migrace dat a nastavení ⚙
Konečně se dostáváme k migraci samotné, ale dříve, než začneme, musíme si ujasnit, jaká data a metadata budeme přenášet. Opět záleží, z jakého systému plánujeme data přesouvat, a hlavně – jakým způsobem.
Pokud se bavíme o datech, měla by nás zajímat data spojená se schránkou, která mohou být různého druhu. Můžeme disponovat daty typu:
- e-mail,
- kalendář,
- kontakt,
- poznámka,
- úkol nebo
- archiv.
Dále jsou pro nás důležitá metadata, což jsou data k samotným datům, kde si můžeme představit například nastavení jazyka i času schránky, kategorie položek, šifrované zprávy, podpisy a mnoho dalšího.
V případě migrace z lokálního prostředí Exchange 2010 a výše přes Exchange hybrid si musíme pohlídat jen specifické záležitosti, například zásady místností nebo nastavení přeposílání u schránek. Vše ostatní, včetně vztahů oprávnění mezi schránkami, je přenášeno automaticky. Jestli je plán migrovat data z jiného systému než lokálního Exchange, bývá situace rozdílná a je potřeba zvážit řadů věcí:
- Co se vše ve zdroji využívá (pravidla, šablony, podpisy, Out of Office, doplňky)
- Zda existuje možnost přenosu
- Co to konkrétně bude znamenat pro migraci i uživatele
Situace může dopadnou tak, že se bude exportovat nastavení schránek, pravidel, příznaků s cílem jejich manuálního nebo polo-automatizovaného přenosu. Změna poštovního systému může reflektovat konfiguraci a nastavení zdrojového prostředí vůči prostředí cílovému, třeba pro zásady webového nebo mobilní přístupu, politiky sdílení, retenční značky, pravidla na transportní vrstvě i přídavné konfigurace v anti-spam a anti-virus řešení.
Za klíčovou oblast považuji uživatelské profily, kde lze říci, že bez funkcí Exchange hybrid nebo nástroje třetí strany budou uživatelé po migraci nuceni tvořit nový profil v desktopovém a mobilním klientovi, takže popis změn, plán migrace a nastavení cílové služby jsou základními kameny pro adopci.
Koexistence 🔗
Při migraci může být vyžadována koexistence mezi oběma systémy. Koexistencí je myšleno provoz schránek ve stejný čas v obou systémech, která může být dostupná například pouze pro vybrané pilotní uživatele. Migrační projekt by měl určit rozsah krátkodobé nebo dlouhodobé koexistence. V případě cutover migrace a překlopení všech uživatelů najednou není koexistence klíčovou oblastí, pokud nejsou v cílově EXO službě již aktivní uživatelé.
Základní koexistenční scénář bývá uplatňován převážně pro tok zpráv, který jde zajistit konfigurací akceptované domény (internal relay) nebo pomocnými doménami a nastavením přeposílání per schránka, ale vždy je potřeba brát v úvahu ucelenou adresní knihu napříč prostředími. Dalšími koexistenčním požadavkem může být sdílení free/busy, což už může být složitější úloha, pokud se nejedná o Exchange hybrid, ale i tak proveditelný například pro GSuite, Lotus/Domino (Quest) a další. Pro určení přidané hodnoty koexistence bývá vhodné myslet na délku migrace, rychlost překlopení a uživatelský komfort.
Adopce 🙋
Při adopci by se mělo myslet na uživatele, který by měl vědět, co se chystá, co migrace jeho schránky znamená, co může očekávat a jak bude schopný v novém prostředí pracovat. Obzvlášť při přechodu z jiného systému než Exchange bývá vhodné uživateli poskytnout základní informace o tom, jak systém funguje a co nabízí. Školení, návody, rozcestníky a další způsoby kampaně by měly být součástí migrace v míře potřebné vůči změně.
Změna systému není pouze pro uživatele, ale i administrátory a procesy, na ně bych rozhodně nezapomínal. EXO je součástí cloudové služby, která se nepřetržitě vyvíjí, omezuje zastaralé způsoby ověření, technologie a přináší stále více funkcí i integrací. Administrátor nepotřebuje službu udržovat aktualizovanou nebo se starat o její provozní zdroje, ale naopak potřebuje reflektovat změny v kontextu konfigurace ke klientům nebo lokální systémům. Příchodem cloudových služeb se zpravidla mění i firemní procesy okolo poštovní služby, například záloha, obnova dat, kontrola auditních stop, proces nástupu, procesy bezpečnostních událostí či správa uživatelských účtů a schránek.
Veřejné složky a PST archivy 🔔
Při každém projektu vyžadují pozornost určitě dvě oblasti. Těmi jsou:
- veřejné složky a
- osobní archivy v podobě PST souborů připojených v profilech nebo uloženy na discích.
V obou případech se jedná o situaci, která vyžaduje speciální přístup. Například veřejné složky musí být v rámci Exchange hybridu pouze na jednom místě, takže většinou zůstávají on-premises do chvíle, než jsou všichni uživatelé v EXO, protože on-prem schránka nedokáže přistupovat k EXO veřejným složkám. V případě veřejných složek v EXO nelze poskytovat EXO uživatelům on-prem veřejné složky. Migrace veřejných složek v rámci Exchange hybridu je v podobě cutover migrace s možností předmigrace dat. Přepnutí vyžaduje down-time a musí být dobře naplánován, protože roll-back může znamenat ztrátu dat. U PST souborů se jedná o odlišnou problematiku, protože jde o fakticky překonanou technologii pro uchovávání e-mailových dat, na které mohou být závislí klienti a která je problematickou oblasti z pohledu GDPR a centrální kontroly nad daty. PST soubory mohou být třeba koordinovaně migrovány uživateli nebo centrálně, ať už přes Office 365 PST import službu nebo nástrojem třetí strany. Z osobní zkušenosti vím, že problematická bývá detekce PST souborů, shromáždění souborů od uživatelů, chráněné PST soubory heslem nebo soudržnost s Outlook profilem. Pro řešení PST problematiky v podnikových systémech je celá řada produktů, ve kterých dominuje Quadrotech.
Recipient management a synchronizace identit 💡
V případě synchronizovaných identit je zatím stále doporučeno mít k dispozici Exchange server v lokálním AD. Server nemusí disponovat hybridní konfigurací a může sloužit čistě pro správu Exchange atributů v lokálním AD, které jsou synchronizovány do EXO. Technicky je možné server neprovozovat a spravovat atributy přes ADSI Edit, ale o to více si musí být administrátor vědom toho co dělá, aby nedošlo například k chybné konfiguraci objektů nebo duplikaci adres. Dokonce lze provozovat EXO i pro synchronizované objekty bez Exchange atributů viz MOERA model, ale opět je důležité zvážit všechny dopady této konfigurace. Zatím doporučený scénář s Exchange recipient serverem je ulehčen možností free licencí dostupných pro Exchange 2016 a využitelných i pro více serverů za předpokladu, že nejsou žádné schránky provozovány v lokálním prostředí.
Bohužel management server znamená plnou instalaci Exchange serveru včetně všech sounáležitosti s AD a následně povinností udržovat server aktualizovaný (podpora pouze pro dvě poslední verze systému), což platí i pro servery v Exchange hybridu. Samotný model synchronizovaných identit lze v průběhu času přehodnotit a změnit na čistě cloudový typ (Are You Ready for Cloud Only?), pokud to dovolují okolnosti, a pak není nutné provozovat systémy lokálně.
Aplikační závislosti 💻
Migrací schránek do EXO se mění cíl, kde budou konzumenti do služby přistupovat. V organizaci mohou existovat nejen uživatelé, ale i aplikace nebo zařízení, které přistupují pod určitými protokoly do schránky. Typickými protokoly jsou IMAP, POP nebo EWS, například aplikace načítající a zpracovávající příchozí zprávy. Mohou ale existovat aplikace závislé na zdrojovém poštovním systému nebo schránkách v kontextu odesílání zpráv.
Aplikačně závislé mohou být tedy systémy využívající zdrojové prostředí jako SMTP relay službu nebo službu pro hromadné odesílání (mass-mailing). EXO není službou podporující mass-mailing, legacy přístup, neautentizovaný relay nebo nešifrovanou komunikaci. Migrace by se měla zabývat aplikačními závislostmi se snahou zmírnit dopad při jejím přenosu. Aplikace nebo zařízení mohou pak vyžadovat přenastavení konfigurace, přístup do internetu, přídavné licence, přeprogramování nebo dokonce samotné nahrazení.
Shrnutí 🚦
Migrace do EXO může být snadnou i obtížnou disciplínou hned v několika oblastech, ať už jsou to identity, licencování, způsob migrace, koexistence, aplikační závislosti, či uživatelská adopce. Doporučoval bych komplexní přístup a zohlednění technických i netechnických záležitostí. Při migraci bývá obrovskou výhodou zkušenost. Pokud vám zkušenosti chybí a potřebujete poradit nebo si přejete migraci na klíč, KPCS je tady pro vás.
