Různá emailová řešení a možnosti jejich migrace do Exchange Online

Všechna tato řešení a případně i jiná další mohou stát na vstupu pro migraci do Exchange Online. My si zde projdeme možná úskalí při výběru migrační metody či případné rozdíly, kdy mnohé položky ani být migrovány nemohou.

Jak už to v Microsoft světě bývá, pro migrací lze využít nativní migraci (aktuálně je dostupná pro migraci z Exchange serverů 2003-2019, Google Workspace, IMAP či migrace mezi Office 365 tenanty, která je zatím stále v preview po ohlášení na loňském Ignite). Případně můžeme migrovat pomocí pst souborů či nástrojů třetích stran, kde bych vyzvedl nástroje jako CloudMigrator, BitTitan MigrationWiz, Transend Migrator, Cloudiway Mailbox Migration Tool a další, případně nástroje specializované na zdrojové prostředí jako je například Migrator for Notes to Exchange.

Výběr migrační metody musí podléhat důkladné analýze zdrojových dat a možností jejich přenesení do Exchange Online či dalších služeb v Office 365. Je nutné zvážit rozdíly mezi platformami a případně posoudit, která zdrojová data jsme schopni obětovat, pokud ve světě Office 365 nemají přímou náhradu.

Lokální Exchange

Mezi „nejjednodušší“ migrace patří migrace z lokálních Exchange serverů, kde je většina nastavení a obsahu migrována a koncový uživatel pocítí pouze drobné změny funkčnosti (samozřejmě i tyto změny mohou být pro některé méně IT znalé uživatele zásadní a je vhodné použít uživatelskou adopci). Migrace z Exchange serverů se dělí na tři základní typy:

Vzdálená migrace (Remote move migration – podporovaná Exchange Server 2010 a novějšími).

• Tento typ je nejrozšířenější pro enterprise zákazníky, kdy po zprovoznění hybridního prostředí mohou uživatele plnohodnotně spolupracovat mezi lokálním a cloudovým Exchange, mailboxy mohou být migrovány oběma směry

Fázová migrace (Staged migration – pouze Exchange Server 2003 a Exchange Server 2007)

• Pokud je v prostředí více než 2.000 poštovních schránek
• Identity jsou synchronizovány z lokálního AD do Azure AD
• Není migrováno nastavení Out-of-Office. Pokud si uživatel toto před migrací nastavil, tak je sice migrováno jako zapnuté, ale OOF zpráva je prázdná.

Přímá migrace (Cutover migration – podporovaná Exchange Server 2003 a novějšími)

• Omezen na maximálně 2.000 poštovních schránek
• Uživatelské identity nejsou synchronizovány a konečná správa uživatelů probíhá v Office 365
• Při migraci z Exchange 2003 musí být otevřeny porty tcp/6001, tcp/6002, tcp/6004
• Outlook Anywhere musí být nakonfigurovaný a dostupný směrem na lokální Exchange server
• Účet pro migrace musí mít plný přístup ke všem poštovním schránkám

Všechny zmíněné Exchange migrace můžeme kombinovat s importem pst souborů, a to jak do vlastních poštovních schránek, tak i do online archívů. Pro migraci veřejných složek je nutné vybrat podporovanou metodu, či použít nástroje třetích stran.

Migrace mezi Office 365 tenanty

Vyčerpávající popis možností všech služeb Office 365 je možné nalézt v článku Microsoft 365 tenant-to-tenant migrations. Vlastní možnost migrace nejen poštovních schránek byla oznámena na konferenci Ignite v září 2020, bohužel je stále v preview verzi, ale i tak jde o vhodnou alternativu k nástrojům třetích stran. Podrobnosti o možnostech této nativní migrace naleznete ve článku Cross-tenant mailbox migration (preview).

• V cílovém tenantu musí být pořízena Azure subskripce, aby bylo možno pracovat s těmito objekty (Azure Resource Group, Key Vault)
• Samotné zprovoznění možnosti migrace se provádí pomoci scriptů pro zdrojový a cílový tenant a případně i verifikační script.

Pokud je pro vás nativní implementace migrace příliš komplikovaná a migrovaných mailboxů není mnoho, pak můžeme použít nástroje třetích stran. Některé nástroje byly zmíněny v úvodu a lze postupovat dle článku How to migrate mailboxes from one Microsoft 365 or Office 365 organization to another.

IMAP

Tento typ migrace je použitelný ze všech zdrojových systémů, které IMAP podporují. Více se dočtete v článku What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365. Mezi největší nevýhody patří možnost migrace pouze emailových zpráv, tudíž pokud potřebujeme migrovat ze zdrojových poštovních schránek i další data (kontakty, kalendáře), tak je nutné využít nástroje třetích stran, jež toto umožňují skrze CalDev a CardDev. Jestliže je to umožněno, lze využít možnost exportu z prostředí, a následný import v Outlooku. Pokud se vydáte touto cestou, tak zejména zvažte tyto oblasti:

• Pokud je na cílovém mailboxu uplatněna retenční či archivační politika, tak zprávy podléhajícím těmto politikám v průběhu migrace jsou označeny jako chybějící
• Jak již bylo zmíněno, migrovat lze pouze poštovní položky a ne položky jako kontakty, kalendář či úkoly
• Lze migrovat maximálně 500.000 zpráv (zprávy jsou migrovány od nejnovějších)
• Maximální velikost zprávy je 35 MB
• K migrovaným schránkám je nutný přístup přes administrátorský účet a pokud to zdrojový systém neumožňuje, je nutné resetovat hesla uživatelům. Pro tento typ migrace je nutností hesla znát (bohužel mnoho systémů má tyto údaje uložena v čisté textové podobě, ale pro potřeby této migrace je to výhodou)
• Poštovní schránka existuje na obou systémech (před vlastní migrací se musí vytvořit v Exchange Online) a je nutné vyřešit případný tok pošty

Google Workspace

Migrace z Google Workspace (dříve známo jako G Suite) je poslední nativní možností, jež byla ohlášena na konferenci Ignite 2019. Tento typ migrace se příliš neliší od IMAP migrace a podrobnosti naleznete v článcích Migrate consumer Google Workspace (formerly G Suite) mailboxes to Microsoft 365 or Office 365 či Perform a Google Workspace (formerly G Suite) migration. Mezi největší rozdíl mezi IMAP a Google migrací je použití aplikačního hesla, kde při IMAP je použito uživatelské heslo a v případě Google migrace aplikační.

Migrace je limitována rozdíly mezi platformami, a to zejména těmito:

• Pošta – Nastavení dovolené, nastavení automatických odpovědí, filtry a pravidla nejsou migrovány
• Konferenční místnosti – Rezervace místností nejsou migrovány
• Kalendář – Sdílené kalendáře, přílohy v cloudu, odkazy na Google Hangout či barvy událostí nejsou migrovány
• Kontakty – Pro jeden kontakt jsou migrovány maximálně tři emailové adresy
• Kontakty – Gmail i vlastní tagy či URL adresy kontaktu nejsou migrovány

Lotus Notes

Tato migrace není možná nativním způsobem (maximálně IMAP migrací jež by vedla ke ztrátě mnoha informací) a provádí se hlavně pomocí nástrojů třetích stran. Samotný Microsoft odkazuje pouze na nástroj MONTI, který v prostředí Lotus Notes pouze sesbírá informace o schránce z Domino directory, včetně souhrnné velikosti či dalších informací o velikostech kontaktů, kalendáře a jiných.

Při výběru vhodného migračního nástroje či dalších podpůrných nástrojů musíme zvážit zejména vlastnosti zpráv v Notes databázích a rozdíly mezi platformami

• Šifrované zprávy – zda budeme migrovat a jak
• Automatický podpis – v Lotus Notes řízen uživatelem či centrálně – zda použijeme nástroj třetí strany
• Stejný email ve více složkách – budou zprávy migrovány do všech složek či jen do jedné
• Kontakty uložené v lokálních databázích – pokud chceme migrovat, tak je uživatelé musí nahrát na server
• LN Stationary – neexistuje ekvivalent, tudíž nelze migrovat
• Pravidla – nástroj musí umět migrovat, jinak musí uživatelé manuálně vytvořit znovu
• Žurnalování – tato možnost je i v Office 365, jen nelze použít cílový mailbox v Exchange Online

Toto byl jen letmý vhled do světa migrací poštovních schránek do Exchange Online. Do budoucna lze předpokládat další zlepšení, a to zejména při migracích mezi tenanty, které budou plně podporovány a doufejme schopné náhrady současných migračních nástrojů.