Migrácia GWS na GWS: poškodené dátumy emailov

Scenár, ktorý nikto nečaká

Práve ste dokončili migráciu z jedného tenanta Google Workspace do druhého. Akvizícia firmy, zmena domény, zlúčenie dvoch entít, ktoré roky fungovali na samostatných G Suite účtoch. Operácia prebehla dobre, schránky sú na mieste, používatelia sa prihlasujú. Pondelok ráno, prvý ticket: "Všetky moje emaily majú rovnaký dátum." Potom druhý. Potom desať.

Inštinktívne si poviete: určite problém s IMAP, zle nakonfigurovaný nástroj, niečo exotické. Nie migrácia Google na Google. A predsa, presne tu sa to deje.

Tento scenár je pravdepodobne najhoršie zdokumentovaný v celom odvetví. Väčšina IT adminov, ktorí sa s ním stretnú, strávi niekoľko hodín hľadaním príčiny na strane e-mailového klienta, Outlooku či nastavení účtu, než si uvedomia, že problém je priamo v hlavičkách správ.

Prečo migrácia Google na Google kazí dátumy

Aby sme pochopili, čo sa deje, musíme sa vrátiť k mechanike e-mailových hlavičiek. Každá správa podľa RFC 2822 obsahuje originálne pole Date:, ktoré nastavil klient alebo odosielací server v momente odoslania. To je "skutočný" dátum emailu, zodpovedajúci tomu, kedy bol napísaný a odoslaný.

Existuje však ešte iný mechanizmus: INTERNALDATE protokolu IMAP. Je to metadáta uložené na strane servera, ktoré udáva, kedy bola správa uložená do schránky. A práve tu sa to stáva zaujímavým.

Keď migračný nástroj prenesie email z jedného tenanta Google Workspace do druhého, použije protokol IMAP (aj keď oba servery sú u Google). Správa sa načíta zo zdroja a vloží sa do cieľa. Pri tomto vkladaní cieľový server automaticky pridá hlavičku Received: s časovou pečiatkou operácie, teda s dátumom migrácie.

Klienti ako Outlook pritom používajú prvú Received: v reťazci na zobrazenie dátumu správy, nie nevyhnutne originálne pole Date:. Výsledok: všetky emaily zobrazujú dátum dňa migrácie.

Ktoré nástroje spôsobujú problém

Prakticky všetky nástroje používané pri migráciách medzi tenantmi Google Workspace sú postihnuté. Bez výnimiek:

• GSMMO (Google Workspace Migration for Microsoft Outlook): navrhnutý pôvodne na migráciu z Exchange, ale používaný aj v niektorých tokoch GWS na GWS.
• CloudM Migrate: veľmi rozšírený u MSP pri inter-Google migráciách, systematicky pridáva Received: migrácie. Pozrite si podrobnú analýzu CloudM.
• BitTitan MigrationWiz: rovnako, správanie je popísané v článku o BitTitane.
• imapsync: open source nástroj umožňujúci skriptovanie IMAP migrácií, vrátane dvoch tenantov Google.
• Manuálne exporty a importy cez Takeout + reimport IMAP: menej časté, ale produkujú presne rovnaký efekt.

Dôvod je jednoduchý: všetky tieto nástroje fungujú ako štandardné IMAP klienty. Nemajú prístup k "natívnej" Google ceste, ktorá by zachovala metadáta. Aj keď oba tenanti sú u Google, prenos prechádza cez vrstvu IMAP, a tá nevie, že komunikuje sama so sebou.

Mechanika hlavičiek Received podrobne

(Mimochodom, ak ste niekedy skúšali čítať surové hlavičky emailu z Gmailu alebo Outlooku, viete, že to nie je práve oddychová literatúra. Ale práve tam sa skrýva celá pravda.)

Email, ktorý cestoval normálne, obsahuje reťazec hlavičiek Received: v opačnom poradí trasy: server, ktorý sa správy dotkol ako posledný, je hore. Po migrácii sa migračná hlavička ocitne úplne na vrchole zásobníka.

Takto to vyzerá v správe migrovanej cez CloudM z jedného GWS tenanta do druhého:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <pouzivatel@nova-domena.sk>
        ; 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: hovorí 2019. Prvý Received: hovorí október 2024. Outlook číta prvý Received:. Používateľ vidí október 2024 pre email z roku 2019.

Originálne pole Date: je neporušené. Nezmenilo sa. To je dobrá správa: dáta sú tam, čakajú len na správne použitie.

Outlook a Gmail sa správajú odlišne

Toto je dôležitá poznámka. Používatelia, ktorí pristupujú k emailom cez webové rozhranie Gmailu, zvyčajne vidia správne dátumy, pretože Gmail uprednostňuje pole Date: podľa RFC 2822 na zobrazenie správ. Na webe je problém menej viditeľný.

Naopak, používatelia, ktorí si nastavia schránku Google Workspace v Outlooku cez IMAP (alebo cez synchronizáciu Exchange ActiveSync), pocítia nesprávny dátum naplno, pretože Outlook sa spolieha na INTERNALDATE IMAP, ktorý odráža dátum prvého Received: pridaného počas migrácie.

Vlastne, aby som bol presný: správanie Outlooku sa líši podľa verzie a spôsobu pripojenia. Outlook 2019 a Microsoft 365 (novšie verzie) používajú INTERNALDATE pri IMAP pripojení. Staršie verzie sa môžu správať trochu inak. Ale vo všetkých prípadoch pozorovaných v produkcii migrácia GWS na GWS cez IMAP produkuje nesprávne dátumy v Outlooku.

V organizáciách, ktoré migrovali na nový tenant a prevádzkujú hybridných používateľov (niektorí na Gmail webe, iní na Outlooku), sú hlásenia ticketov nekonzistentné. IT tímy trávia čas zisťovaním, prečo "niektorí sú postihnutí a iní nie", hoci odpoveď je jednoduchá: záleží na e-mailovom klientovi.

Akvizície, fúzie, zmeny domény: najčastejšie prípady

Tento typ migrácie nie je výnimočný. Tu sú scenáre, ktoré generujú najviac ticketov:

Akvizícia firmy

Kupovaná spoločnosť mala vlastný tenant Google Workspace (doména @stara-firma.sk). Po akvizícii musí všetko migrovať na tenant materskej spoločnosti (@skupina.sk). 250 schránok, archívy, 8 rokov e-mailovej histórie. BitTitan alebo CloudM je poverený operáciou. Výsledok: 2,4 milióna emailov s dátumom víkendu migrácie.

Zmena domény

Rebrandovaná firma prechádza z @staremeno.sk na @novemeno.sk. Rovnaký tenant Google, ale vytvorenie nového tenanta pre čistý štart (bežná voľba, aby sa predišlo konfiguračným artefaktom). Migrácia schránok cez imapsync alebo GSMMO. Dátumy sa pokazia presne rovnakým spôsobom.

Konsolidácia dcérskych spoločností

Skupina so 4 dcérskymi spoločnosťami, každá na vlastnom historickom G Suite tenante, sa rozhodne všetko zlúčiť na jediný tenant. Štyri paralelné migrácie, štyri dávky emailov s poškodenými dátumami na riešenie.

V týchto troch scenároch je problém identický a riešenie rovnaké. Checklist migrácie emailov umožňuje tento typ problému predvídať ešte pred spustením migrácie.

Prečo vlastný skript nie je odpoveď

Pochopiť problém je jedna vec. Povedať si "napíšem Python skript, ktorý vyčistí hlavičky" a aplikovať ho na 30 000 produkčných emailov je vec iná.

Hraničných prípadov je neúrekom. Skript, ktorý funguje na 50 testovacích emailoch v čistom prostredí, nevyhnutne narazí na produkčnej schránke reálnej veľkosti na:

• Správy s podpismi S/MIME alebo PGP šifrovaným obsahom, kde akákoľvek zmena štruktúry správy invaliduje kryptografický podpis.
• Emaily s komplexnými vnoreným MIME štruktúrami (multipart/alternative vnorený v multipart/mixed s prílohami veľkými desiatky megabajtov).
• Hlavičky zakódované podľa RFC 2047 (non-ASCII znaky), ktoré zle nakonfigurované parsery ticho pohltia.
• Chyby 429 Too Many Requests z Google API o 2:00 ráno, uprostred dávky opráv, ktoré nechajú proces v neurčitom stave.
• Emaily, pre ktoré je reťazec Received: nejednoznačný: viac po sebe idúcich migračných nástrojov pridalo každý svoju hlavičku, a nie je triviálne určiť, ktorú odstrániť.

A najdôležitejšia otázka: ako overiť, email po emaile, že každá opravená správa je neporušená a nič sa nestratilo ani nepoškodilo? Vlastný skript túto verifikáciu zvyčajne nerobí. Redate.io ju robí automaticky, s uchovaním originálov vo viditeľnom záložnom priečinku počas 30 dní.

Čo Redate.io robí pri tomto type migrácie

Redate.io sa pripojí k cieľovému tenantovi Google Workspace (cez delegovanie domény, bez manuálnej intervencie schránku po schránke) a prehľadá emaily na identifikáciu tých, ktorých metadáta dátumu sú nezlučiteľné s obsahom správy. Táto fáza skenu je bezplatná a poskytuje presný prehľad o rozsahu problému ešte pred akoukoľvek opravou.

Proprietárny opravný engine potom analyzuje reťazec hlavičiek každej správy, aplikuje porovnávanie vzorov na známe signatúry migračných nástrojov (BitTitan, CloudM, imapsync, GSMMO a ďalšie menej rozšírené) a vykoná cielenú opravu metadát bez zmeny obsahu správy. Každý opravený email je overený individuálne. Originály sú zachované.

Pre migrácie medzi tenantmi Google Workspace konkrétne pipeline spracúva prípady, kde prebehlo viacero migračných behov (napríklad schránka migrovaná prvýkrát v roku 2021 a znovu v roku 2024), s viacerými vrstvami parazitných hlavičiek, ktoré treba rozpliesť.

Sprievodcovia opravou CloudM do Google Workspace a BitTitan do Google Workspace podrobne popisujú kroky pripojenia pre tento typ konfigurácie.

Detekovať problém skôr, ako sa naň sťažujú používatelia

Najlepší moment na odhalenie poškodených dátumov je hneď po migrácii, pred go-live. Rýchla kontrola na niekoľkých pilotných schránkach cez IMAP klient ako Thunderbird umožňuje porovnať zobrazenie dátumov s tým, čo by sme očakávali. Ak všetky importované emaily zdanlivo nesú rovnaký nedávny dátum, je to charakteristický príznak problému.

V praxi sa však problém objaví často niekoľko týždňov po migrácii, keď používateľ hľadá starú zmluvu a zistí, že jeho Gmail schránka je perfektne zoradená... podľa dátumu migrácie. Tisíce emailov nakopené s rovnakou časovou pečiatkou. Vyhľadávanie podľa dátumu nefunguje. Konverzačné vlákna sú v neporiadku. História sa zdá byť preč.

Pre MSP, ktoré pravidelne spravujú migrácie medzi tenantmi Google Workspace, zaradenie skenu Redate.io do post-migračného checklistu (pred odovzdaním klientovi) predchádza takýmto prekvapeniam.

Práve ste migrovali medzi dvoma tenantmi Google Workspace a dátumy emailov sú nesprávne? Spustite bezplatný sken na Redate.io a zistite rozsah problému ešte pred opravou.