Migrace GWS na GWS: poškozená data e-mailů

Scénář, který nikdo nečeká

Právě jste dokončili migraci jednoho tenanta Google Workspace na jiný. Akvizice firmy, změna domény, sloučení dvou organizací, které roky fungovaly pod oddělenými G Suite účty. Operace proběhla v pořádku, schránky jsou připraveny, uživatelé se přihlásí. V pondělí ráno přijde první ticket: "Všechny moje e-maily mají stejné datum." Pak druhý. Pak deset.

Instinktivně si řeknete: musí to být problém s IMAP, špatně nakonfigurovaný nástroj, něco exotického. Ne migrace Google na Google. A přesto se to děje přesně tady.

Tento scénář je pravděpodobně nejméně zdokumentovaný v celém oboru. Většina IT administrátorů, kteří se s ním setkají, stráví několik hodin hledáním příčiny na straně poštovního klienta, Outlooku nebo nastavení účtu, než zjistí, že problém se skrývá přímo v hlavičkách e-mailů.

Proč migrace Google na Google kazí data

Abyste pochopili, co se děje, je třeba se vrátit k mechanice e-mailových hlaviček. Každá zpráva RFC 2822 obsahuje původní pole Date:, které nastavil odesílající klient nebo server v okamžiku odeslání. To je "skutečné" datum e-mailu, tedy kdy byla zpráva napsána a odeslána.

Existuje ale ještě jiný mechanismus: INTERNALDATE IMAP. Jde o metadata uložená na straně serveru, která říkají, kdy byla zpráva vložena do schránky. A tady začíná být věc zajímavá.

Když migrační nástroj přesouvá e-mail z jednoho tenanta Google Workspace na jiný, používá protokol IMAP (i když oba servery jsou u Googlu). Zpráva se přečte ze zdrojové schránky a znovu vloží do cílové. Při tomto vkládání cílový server automaticky přidá hlavičku Received: s časovým razítkem operace, tedy s datem migrace.

Poštovní klienti jako Outlook ale používají první Received: v řetězci pro zobrazení data zprávy, ne původní pole Date:. Výsledek: všechny e-maily zobrazují datum dne migrace.

Které nástroje tento problém způsobují

Prakticky všechny nástroje používané pro migrace mezi tenants Google Workspace jsou postiženy. Bez výjimky:

• GSMMO (Google Workspace Migration for Microsoft Outlook): původně navržen pro migraci z Exchange, ale používaný v některých scénářích GWS na GWS.
• CloudM Migrate: velmi rozšířený u MSPs pro migrace mezi Google tenants, systematicky přidává migrační hlavičku Received:. Viz podrobná analýza CloudM.
• BitTitan MigrationWiz: stejné chování, podrobněji popsáno v článku o BitTitanu.
• imapsync: open source nástroj pro skriptování IMAP migrací, včetně přesunů mezi dvěma Google tenants.
• Ruční export/import přes Takeout + reimport IMAP: méně časté, ale s naprosto stejným efektem.

Důvod je prostý: všechny tyto nástroje fungují jako standardní IMAP klienti. Nemají přístup k žádné "nativní" Google cestě, která by zachovala metadata. I když oba tenanti jsou u Googlu, přenos probíhá přes vrstvu IMAP, a ta neví, že komunikuje sama se sebou.

Mechanika hlaviček Received podrobně

(Mimochodem, pokud jste někdy zkoušeli číst surové hlavičky e-mailu v Gmailu nebo Outlooku, víte, že to není zrovna lehká četba. Ale právě tam se skrývá celá pravda.)

E-mail, který prošel normální cestou, obsahuje řetězec hlaviček Received: v opačném pořadí průchodu: poslední server, který zprávu zpracoval, je nahoře. Po migraci se migrační hlavička ocitne úplně nahoře v zásobníku.

Takto to vypadá ve zprávě migrované přes CloudM z jednoho GWS tenanta na jiný:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <uzivatel@nova-domena.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Pole Date: říká 2019. První Received: říká říjen 2024. Outlook čte první Received:. Uživatel vidí říjen 2024 u e-mailu z roku 2019.

Původní pole Date: je nedotčené. Nepohnulo se. To je dobrá zpráva: správné datum tam je, jen čeká, až se s ním bude pracovat správně.

Outlook a Gmail se nechovají stejně

Tohle je důležitá nuance. Uživatelé, kteří přistupují ke svým e-mailům přes webové rozhraní Gmailu, vidí správná data, protože Gmail upřednostňuje pole Date: RFC 2822. Problém je na webu méně viditelný.

Naproti tomu uživatelé, kteří mají svou Google Workspace schránku nastavenou v Outlooku přes IMAP (nebo přes synchronizaci Exchange ActiveSync), pocítí špatná data naplno, protože Outlook spoléhá na INTERNALDATE IMAP, který odráží datum první Received: hlavičky přidané při migraci.

Upřesnění: chování Outlooku se liší podle verze a způsobu připojení. Outlook 2019 a Microsoft 365 (novější verze) používají INTERNALDATE při IMAP připojení. Starší verze se mohou chovat mírně odlišně. Ve všech případech pozorovaných v produkci ale migrace GWS na GWS přes IMAP způsobuje nesprávná data v Outlooku.

V organizacích, kde proběhla migrace na nový tenant a kde coexistují hybridní uživatelé (jedni na Gmail webu, druzí na Outlooku), jsou hlášení ticketů nesourodá. IT týmy tráví čas zjišťováním, proč "někteří jsou postiženi a jiní ne", přičemž odpověď je prostá: rozdíl dělá poštovní klient.

Akvizice, fúze, změny domén: nejčastější scénáře

Tento typ migrace není ničím výjimečným. Scénáře, které generují nejvíce ticketů:

Akvizice firmy

Akvírovaná společnost měla vlastní tenant Google Workspace (doména @stara-firma.com). Po akvizici musí vše přejít na tenant mateřské společnosti (@skupina.com). Všech 250 schránek, archivy, 8 let e-mailové historie. BitTitan nebo CloudM je pověřen operací. Výsledek: 2,4 milionu e-mailů s datem víkendu migrace.

Změna domény

Přejmenovaná firma přechází z @stary-nazev.cz na @novy-nazev.cz. Stejný tenant Google, ale volba vytvořit nový tenant a začít čistě (běžné rozhodnutí pro odstranění konfiguračních artefaktů). Migrace schránek přes imapsync nebo GSMMO. Data se rozbijí úplně stejně.

Konsolidace dceřiných společností

Skupina se 4 dceřinými firmami, každá na svém historickém G Suite tenantu, se rozhodne vše sloučit do jednoho tenanta. Čtyři migrace paralelně, čtyři dávky e-mailů s poškozenými daty ke zpracování.

Ve všech třech scénářích je problém identický a řešení je stejné. Checklist pro e-mailové migrace umožňuje tento typ problému předvídat ještě před spuštěním migrace.

Proč domácí skript není řešením

Pochopit problém je jedna věc. Říct si "napíšu Python skript, který pročistí hlavičky" a pustit ho na 30 000 produkčních e-mailů je věc úplně jiná.

Hraničních případů je celá řada. Skript, který funguje na 50 testovacích e-mailech v čistém prostředí, nevyhnutelně narazí v produkční schránce reálné velikosti na:

• Zprávy se S/MIME podpisy nebo PGP šifrovaným obsahem, kde jakákoli úprava struktury zprávy zneplatní kryptografický podpis.
• E-maily s komplexními vnořenými MIME strukturami (multipart/alternative uvnitř multipart/mixed s přílohami o desítkách megabajtů).
• Hlavičky kódované dle RFC 2047 (non-ASCII znaky), které špatně nakonfigurované parsery tiše spolykají.
• Chyby 429 Too Many Requests z Google API ve dvě ráno, uprostřed opravné dávky, které nechají proces ve neurčitém stavu.
• E-maily, kde je řetězec Received: nejednoznačný: několik migračních nástrojů postupně přidalo každý svou vlastní hlavičku a není jednoduché určit, kterou odstranit.

A nejdůležitější otázka: jak ověřit, e-mail po e-mailu, že každá opravená zpráva je neporušená a nic se neztratilo nebo nepoškodilo? Domácí skript toto ověření obvykle neprovádí. Redate.io to dělá automaticky, s uchováním originálů v záložní složce viditelné 30 dní.

Co Redate.io dělá u tohoto typu migrace

Redate.io se připojí k cílovému tenantovi Google Workspace (přes doménovou delegaci, bez ručního zasahování do každé schránky) a prohledá e-maily, aby identifikoval ty, jejichž datová metadata neodpovídají obsahu zprávy. Tato fáze skenování je zdarma a poskytuje přesný přehled o rozsahu problému před jakoukoli opravou.

Proprietární opravný engine poté analyzuje řetězec hlaviček každé zprávy, aplikuje porovnávání vzorů oproti známým signaturám migračních nástrojů (BitTitan, CloudM, imapsync, GSMMO a dalších méně běžných) a provede cílenou opravu datových metadat bez změny obsahu zprávy. Každý opravený e-mail je ověřen individuálně. Originály jsou zachovány.

U migrací mezi tenants Google Workspace konkrétně pipeline zpracovává případy, kdy proběhlo více průchodů migrace (například schránka migrovaná poprvé v roce 2021 a podruhé v roce 2024), s několika vrstvami parazitních hlaviček k rozplétání.

Podrobné průvodce opravou pro CloudM do Google Workspace a BitTitan do Google Workspace popisují kroky připojení pro tento typ konfigurace.

Odhalit problém dříve, než si uživatelé začnou stěžovat

Nejlepší okamžik pro detekci poškozených dat je hned po migraci, před go-live. Rychlá kontrola na několika pilotních schránkách přes IMAP klienta jako Thunderbird umožní porovnat zobrazená data s očekávanými hodnotami. Pokud se zdá, že všechny importované e-maily mají stejné nedávné datum, jde o charakteristický příznak problému.

V praxi se ale problém odhalí nejčastěji několik týdnů po migraci, když uživatel hledá starou smlouvu a zjistí, že jeho Gmail schránka je perfektně seřazena... podle data migrace. Tisíce e-mailů naskládaných se stejným časovým razítkem. Vyhledávání podle data nefunguje. Vlákna konverzací jsou v nepořádku. Zdá se, jako by celá historie zmizela.

Pro MSPs, kteří pravidelně řeší migrace mezi tenants Google Workspace, zařazení skenování Redate.io do checklistu po migraci (před odevzdáním klientovi) podobným překvapením zabrání.

Právě jste migrovali mezi dvěma tenants Google Workspace a data Vašich e-mailů jsou nesprávná? Spusťte bezplatný sken na Redate.io a zjistěte rozsah problému před jakoukoli opravou.