Úskalí migrace z Lotus Domino do Exchange Online

Migrační proces z platformy IBM Lotus Domino je pro každou společnost velkým krokem a jeho úspěšné zvládnutí vždy vyžaduje pečlivé plánování a souhru více týmů. Nejde totiž pouze o změnu v serverové infrastruktuře, kterou koncoví uživatelé nemusí ani zaznamenat, ale o změnu celé platformy, kdy správci musí nakonec začít spravovat zcela jinak pojaté prostředí a uživatelé používat jiné klientské aplikace a to nejen na svých počítačích, ale i v mobilních zařízeních a tabletech.

Důvody ke změně v tomto článku nebudeme rozebírat. Ty mohou být skutečně různorodé. Od manažerského rozhodnutí, které přijde z vedení společnosti až po vyslyšení zaměstnanců, pro které bývá prostředí MS Exchange a Outlook povědomější a více intuitivní než poštovní klienti Lotus Notes. Neznamená to ovšem, že uživatelé by při přechodu do Office 365 Exchange Online neměli být předem informování o chystaných změnách. Podle mých zkušeností je nutné vždy alespoň krátké proškolení zaměstnanců, kterých se změna dotkne. U platformy elektronické pošty tedy můžeme počítat uživatele prakticky všechny.

Kromě potřeby připravit na velkou změnu koncové uživatele je nutné také dobře zvážit a naplánovat celý proces transformace poštovních služeb.

Na co byste se měli zaměřit:

• Počet uživatelských schránek a databází zdrojů
• Požadavky na typ dat migrovaných do Exchange Online
• Počet Lotus Domino domén
• Celkový objem dat k migraci
• Geografické rozložení uživatelů
• Aktuální způsob používání Lotus Notes klienta
• Současná serverová infrastruktura a její použití
• Způsob používání vlastních Lotus Notes aplikací a integrace s dalšími systémy

Jak vidíme, je to poměrně hodně neznámých, které je potřeba zvážit, a každá může znamenat velké změny v plánovaném procesu migrace.

Zdroj identit Exchange Online

Exchange Online používá pro své fungování infrastrukturu Microsoft Azure Active Directory (AAD), která pro běžného uživatele i mnoho správců pouze běží někde na pozadí a nijak se o ni starat vlastně nemusí. Otázkou ovšem je, jakým způsobem zde uživatele a další identity vytvořit. Obecně se do AAD mohou buď synchronizovat, nebo se zde vytvoří ručně (případně skriptem). Založení identit přímo v Office 365 se zdá být nejjednodušším řešením, ale obvykle nebývá zcela šťastné.

Většina společností využívá pro adresářové služby Active Directory, i když pro poštovní služby využívají Lotus Domino Directory. Problémem bývá ovšem jejich nesourodost zapříčiněná způsobem používání. Domino Directory nejspíš nebude obsahovat uživatele, kteří přistupují do firmy, ale nepoužívají e-mailové služby a naopak v případě Active Directory nebudou účty uživatelů, kteří nepoužívají jiné než poštovní služby nebo třeba distribuční skupiny.

Pokud tedy chcete používat Active Directory jako zdrojovou bázi identit, nezbývá než provést konsolidaci mezi těmito prostředími. Vzhledem ke komplexitě tohoto úkolu nebývá jednoduché nutné kroky zcela automatizovat, ale pomocí několika tabulek exportovaných do CSV a s administrativními možnostmi PowerShell ve spojení s Active Directory, to není úkol zcela neřešitelný i bez nákupu dalšího software. Je třeba si uvědomit, že uživatele v AD musíte nejenom vytvořit, ale musíte také nastavit veškeré atributy nutné pro správné fungování služeb.

Poslední poznámka o nutných atributech vypadá sice nenápadně a poněkud abstraktně, ale znamená jednu důležitou změnu v rámci vaší Active Directory. Ačkoli budete migrovat služby do Exchange Online, bude třeba rozšířit schéma AD o Exchange atributy. Bez tohoto kroku není prakticky možné používat Active Directory jako zdrojovou adresářovou službu. Důvod je jednoduchý. Pokud synchronizujete identity do Office 365, jsou zde atributy identit uzamčeny pro úpravu a je třeba je měnit ve vašem lokálním AD. Abyste ovšem mohli atributy měnit, musíte je nejdřív v AD schématu mít. Nejjasnějším příkladem jsou e-mailové adresy, které se ukládají do AD atributu s názvem proxyAddresses. Tento atribut (uživatelů, skupin, kontaktů… ) ovšem v základním schéma AD neexistuje a získáte jej až rozšířením AD pro MS Exchange. Bez tohoto kroku se tedy také neobejdeme.

A pokud už máme rozšířeno schéma, proč nenainstalovat rovnou i Exchange server? Na první pohled to vypadá jako podivný nápad. Proč bychom měli instalovat Exchange server ve svém prostředí, pokud chceme migrovat do Exchange Online a využívat služby v cloudu… Věřte, že i tato konfigurace má své výhody a při dodržení jednoduchých podmínek navíc nemusíte za tento Exchange server platit licenci.

Podmínky získání licence pro Hybridní Exchange server:

• Máte aktivní předplatné Exchange Online Enterprise
• Aktuálně nemáte žádnou platnou on-premise licenci pro Exchange 2010 nebo Exchange 2013
• Nebudete na tomto serveru provozovat žádné mailboxy

Pokud jste na všechny otázky odpověděli ano, můžete zažádat o licenční klíč přes jednoduchý formulář.

Instalace hybridního Exchange serveru v organizaci vám přinese lepší možnosti, jak spravovat vaše synchronizované identity. Např. politiky e-mailových adres bez tohoto kroku nezískáte, protože v Exchange Online stále nejsou podporovány a třeba jednoduché skrytí uživatele z globálního adresáře (GAL) bez nutnosti obskurní úpravy atributů přímo v konzoli Active Directory Users and Computers (msExchHideFromAddressLists) můžete následně provádět snadno přes Exchange Admin Center (EAC).

Způsob ověřování

Způsob ověřování uživatelů proti službám Exchange Online opět vychází z vašich potřeb a existující infrastruktury. Pokud budete chtít, aby zdrojovým prostředím vašich identit bylo Active Directory, což je běžné, můžete si vybrat ze 2 základních scénářů.

• Uživatelé se ověřují ke službám v Office 365 přes servery ve vaší vlastní infrastruktuře (ADFS).
• Uživatelé mají synchronizované své účty včetně hesla a ověřování tak probíhá přímo vůči serverům v Office 365.

Obě varianty mají svá pro a proti a opět záleží pouze na vašich potřebách a požadavcích. Pokud chcete mít pod kontrolou každé přihlášení uživatele a nechcete z jakéhokoli důvodu synchronizovat identity do Office 365 včetně hesla, je možné vybudovat lokální infrastrukturu pro Active Directory Federation Services (ADFS). Ta zajistí, že uživatel hlásící se ke službám v Exchange Online je pro ověření přesměrován na tyto servery, které zprostředkují jeho autentizační proces, a následně ho přesměruje zpět tam, kam se původně hlásil (např. https://mail.office365.com). Ačkoli to vypadá složitě, pro koncového uživatele je to postup velice jednoduchý a transparentní. Pokud se například jedná o uživatele z vaší AD domény, nemusí ani znovu zadávat své přihlašovací údaje.

Jestliže nemáte problém se synchronizováním hesla z Active Directory, je možné tuto vlastnost povolit při konfiguraci synchronizačního nástroje (DirSync nebo nově AADSync) a uživatelé se následně hlásí stejným jménem a heslem do počítače i do Exchange Online.

Pokud byste uvažovali, že vaším zdrojovým prostředím bude i nadále Domino Directory, kterou chcete synchronizovat do Office 365 (Windows Azure Active Directory), i to je samozřejmě možné. Stále zde sice chybí podpora synchronizace hesla, ale pokud z jakéhokoli důvodu potřebujete zachovat zdrojovou Domino Directory, můžete pro synchronizaci implementovat nástroj Microsoft Forefront Identity Manager (FIM). Je třeba pouze počítat s vyššími náklady z důvodu nutnosti zakoupení licence tohoto nástroje a vyšší časovou náročností při konfiguraci synchronizace.

Zdrojová data v Lotus Domino

Obecně platí, že všechna data, která chcete migrovat do Exchange Online je potřeba nejdříve dostat na Lotus Domino server v nešifrované podobě a teprve poté je možné je začít migrovat na cílovou infrastrukturu v Office 365. Zní to jako jednoduchý úkol, který ovšem bývá poměrně zapeklitý. Pokud je ve vaší společnosti zvykem šifrovat e-maily v uživatelských databázích, je potřeba aby k dešifrování opět došlo ze strany klienta. Je možné sice pomocí Lotus Notes agenta zakázat další šifrování nových zpráv, ale na data již zašifrovaná to nebude mít žádný vliv. Záleží potom, jaký migrační nástroj zvolíte, ale technicky není možné tato data kvalitně přenést. Tento krok tedy vždy vyžaduje interakci s uživatelem, který data zašifroval svým certifikátem, a to bývá organizačně náročné.

Další úskalí může nastat při migraci kontaktů, které standardně nejsou ukládány na Domino serveru. Je sice opět možné vytvořit Lotus Notes agenta, který bude synchronizovat kontakty na server, ale ani to vždy nebývá bezproblémové.

Zdrojový a cílový poštovní klient – IBM Notes vs. MS Outlook

Konfigurace domén pro Office 365

Konfigurace domén, které chcete používat v Office 365 je poměrně jednoduchá a přímočará. Po přidání domény je třeba nejprve potvrdit, že doména je pod vaší správou. Tento krok je ovšem automatizovaný a faktický pouze znamená přidání jednoduchého TXT záznamu. Jeho tvar vám Microsoft náhodně vygeneruje a ve chvíli, kdy se objeví ve veřejné DNS zóně vaší domény, je doména ověřena a můžete ji začít používat. Získáte také kompletní přehled záznamů, které je třeba nastavit pro správné fungování služeb Exchange Online a po jejich úpravě již vše funguje, jak má. Pokud si navíc nejste jisti tím, zda máte záznamy konfigurovány správně, v administraci není problém si stav ověřit.

Pokud vaši uživatelé ze všech vašich SMTP domén používají před migrací výhradně Lotus Notes klienta, není problém ještě před samotnou migrací nastavit na doméně všechny zobrazené záznamy kromě MX. Pouze MX (Mail eXchange) záznam, který určuje, kam mají být zprávy pro konkrétní doménu směrovány z internetu, je třeba upravovat obvykle až na konci migračního procesu.

Náhled do administrace domén v Office 365

Migrace dat

Průběh samotné migrace dat závisí na zvoleném migračním nástroji, který si zvolíte. Office 365 nebo přímo společnost Microsoft v tuto chvíli nenabízí žádný nativní migrační nástroj. Jedinou možností migrace dat bez investice do migračního software by mohla být migrace migrátorempřímo v Exchange Online, který nabízí možnost migrace z libovolného IMAP zdroje. Problém ovšem je, že tímto způsobem je možné migrovat pouze data pošty – a navíc ne všechny složky schránek. Migrace kontaktů, úkolů, kalendáře a dalších typů dat není možné.

Jestliže se již začnete poohlížet po migračním nástroji, kterým byste přenesli všechna vaše data, budete volit ze základních 2 typů nástrojů:

1. Cloudové migrační nástroje

2. On-premise migrační nástroje

Záleží tak na vás, jaká filozofie je vám bližší. Pokud se nechcete starat o migrační infrastrukturu a nemáte problém s tím, že vaše data jsou přenášena přes službu, nad kterou nemáte plnou kontrolu, je pro vás některé z cloudových řešení jasnou volbou. Dobrým příkladem je například nástroj s názvem MigrationWiz, který podporuje migraci z dlouhé řady platforem a deklaruje velmi slušnou úspěšnost. Pokud je vám bližší migrace přes nástroje instalované ve vaší infrastruktuře, je možné použít například nástroj Cloud Migrator 365, který podle svého jména evokuje spíše prvně popisovaný typ software, ale je možné jej instalovat přímo na vaše servery.

Přiklad migračního nástroje Cloud Migrator 365

Počet migrovaných schránek a jejich objem obvykle sám o sobě definuje rámec migračního plánu. Ačkoli to nemusí platit vždy, tak menší počet větších schránek znamená rychlejší proces migrace než velký počet schránek malých. Stejná rovnice platní i pro počet a velikost položek v migrovaných schránkách.

Ceny obou typů řešení jsou velmi podobné. Pohybují se okolo 10€ za migrovanou schránku. Cena může klesnout při nákupu přes některého lokálního partnera a při využití jeho konzultantských služeb nebo v případě nákupu většího počtu licencí.

Způsob používání databází zdrojů a potřeby na jejich migraci jsou také důležitou otázkou pro úspěšnou změnu. Nejjednodušší způsob je samozřejmě začít v novém prostředí s čistým štítem, což u schránek zdrojů nebývá nepřekonatelný problém, vzhledem ke způsobu jejich použití. Další možností je jejich jednorázová migrace do cílového prostředí. Pokud sáhnete po některém migračním nástroji třetí strany, získáte navíc možnost migrace zdrojů obvykle zdarma. Tato varianta tak bývá nejpoužívanější vzhledem k časové (ne)náročnosti při dodržení předepsaných postupů. Pokud ovšem budete vyžadovat koexistenci schránek zdrojů v rámci obou prostředí (tj. Lotus Domino a Exchange Online), připravte se na skutečnou výzvu, která není vždy řešitelná.

Mým záměrem nebylo v žádném případě obsáhnout celou problematiku migrace z IBM Lotus Notes, ale pouze jakési nahlédnutí do této problematiky. Pokud o tomto kroku uvažujete, je vždy lepší mít po ruce systémového integrátora, který má s realizací praktické zkušenosti a může od začátku směřovat migraci správným směrem.

Jan Bartoš, 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.