Migrare Google Workspace spre GWS: date stricate

Scenariul pe care nimeni nu îl bănuiește

Tocmai ați finalizat migrarea unui tenant Google Workspace spre altul. O achiziție, o schimbare de domeniu, fuziunea a două entități care coexistau pe conturi G Suite separate de ani de zile. Operațiunea a mers bine, căsuțele sunt la locul lor, utilizatorii se conectează. Luni dimineața, primul tichet: "Toate emailurile mele au aceeași dată." Apoi încă unul. Apoi zece.

Instinctiv, vă gândiți că este un problemă IMAP, un instrument prost configurat, ceva exotic. Nu o migrare Google spre Google. Totuși, exact acolo se întâmplă.

Acest scenariu este probabil cel mai prost documentat din domeniu. Majoritatea administratorilor IT care îl întâlnesc pierd câteva ore căutând o explicație în clientul de mail, în Outlook, în setările contului, înainte să realizeze că problema se află chiar în antetele emailurilor.

De ce o migrare Google spre Google strică datele

Pentru a înțelege ce se întâmplă, trebuie să revenim la mecanica antetelor de email. Fiecare mesaj RFC 2822 conține un câmp Date: original, adăugat de clientul sau serverul expeditorului la momentul trimiterii. Aceasta este data "reală" a emailului, cea care corespunde momentului în care mesajul a fost redactat și trimis.

Dar există un alt mecanism: INTERNALDATE-ul IMAP. Este o metadată stocată pe server care indică momentul în care mesajul a fost depus în căsuță. Și exact aici devine interesant.

Când un instrument de migrare transferă un email dintr-un tenant Google Workspace în altul, folosește protocolul IMAP (chiar dacă ambele servere sunt la Google). Mesajul este citit din sursă, apoi reinsertat în destinație. La momentul reinserării, serverul de destinație adaugă automat un antet Received: cu marcajul temporal al operațiunii, adică data migrării.

Or, clienți de mail precum Outlook folosesc primul Received: din lanț pentru a afișa data unui mesaj, nu neapărat câmpul Date: original. Rezultat: toate emailurile afișează data zilei de migrare.

Ce instrumente declanșează problema

Aproape toate instrumentele folosite pentru migrări inter-tenant Google Workspace sunt afectate. Nicio excepție notabilă:

• GSMMO (Google Workspace Migration for Microsoft Outlook): conceput inițial pentru migrări din Exchange, dar folosit în unele fluxuri GWS spre GWS.
• CloudM Migrate: foarte răspândit la MSP-uri pentru migrări inter-Google, adaugă sistematic un Received: de migrare. Consultați analiza detaliată a CloudM.
• BitTitan MigrationWiz: același comportament, documentat în articolul despre BitTitan.
• imapsync: instrumentul open source care permite scriptarea migrărilor IMAP, inclusiv între doi tenanți Google. Vedeți și situațiile în care imapsync nu conservă datele.
• Exporturile/importurile manuale prin Takeout + reimport IMAP: mai puțin frecvente, dar produc exact același efect.

Motivul este simplu: toate aceste instrumente funcționează ca niște clienți IMAP standard. Nu au acces la o cale "nativă" Google care să păstreze metadatele. Chiar dacă ambii tenanți sunt la Google, transferul trece prin stratul IMAP, iar acel strat nu știe că vorbește cu el însuși.

Mecanica antetelor Received în detaliu

(Apropo, dacă ați încercat vreodată să citiți antetele brute ale unui email din Gmail sau Outlook, știți că nu este exact o lectură de plăcere. Dar acolo se ascunde tot adevărul.)

Un email care a călătorit normal conține un lanț de antete Received: în ordine inversă față de traseu: ultimul server care a atins mesajul se află în vârf. După o migrare, antetul de migrare ajunge deci în vârful stivei.

Iată cum arată într-un mesaj migrat prin CloudM dintr-un tenant GWS în altul:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <utilizator@domeniu-nou.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

Câmpul Date: spune 2019. Primul Received: spune octombrie 2024. Outlook citește primul Received:. Utilizatorul vede octombrie 2024 pentru un email din 2019.

Câmpul Date: original este intact. Nu s-a modificat. Aceasta este vestea bună: data corectă există, așteaptă doar să fie utilizată corespunzător.

Outlook și Gmail nu se comportă la fel

Este o precizare importantă. Utilizatorii care accesează emailurile prin interfața web Gmail văd adesea datele corecte, deoarece Gmail prioritizează câmpul Date: RFC 2822 pentru afișarea mesajelor. Problema este mai puțin vizibilă în varianta web.

În schimb, utilizatorii care configurează căsuța Google Workspace în Outlook prin IMAP (sau prin sincronizarea Exchange ActiveSync) suferă din plin data greșită, deoarece Outlook se bazează pe INTERNALDATE IMAP, care reflectă data primului Received: adăugat la migrare.

De fapt, pentru a fi precis, comportamentul Outlook variază în funcție de versiune și de modul de conexiune. Outlook 2019 și Microsoft 365 (versiunile recente) folosesc INTERNALDATE când se conectează prin IMAP. Versiunile mai vechi pot avea comportamente ușor diferite. Dar în toate cazurile observate în producție, migrarea GWS spre GWS prin IMAP produce date incorecte în Outlook.

Prin urmare, în organizațiile care au migrat spre un tenant nou și mențin utilizatori hibriți (unii pe Gmail web, alții pe Outlook), tichetele sunt inconsistente. Echipele IT pierd timp încercând să înțeleagă de ce "unii sunt afectați și alții nu", când răspunsul este simplu: clientul de mail face diferența.

Achiziții, fuziuni, schimbări de domeniu: cele mai frecvente cazuri

Acest tip de migrare nu este deloc anecdotic. Iată scenariile care generează cele mai multe tichete:

Achiziția unei companii

O companie achiziționată avea propriul tenant Google Workspace (domeniu @vechea-companie.com). După achiziție, totul trebuie migrat spre tenantul companiei-mamă (@grup.com). Cele 250 de căsuțe, arhivele, 8 ani de istoric de emailuri. BitTitan sau CloudM este mandatat pentru operațiune. Rezultat: 2,4 milioane de emailuri cu data weekend-ului de migrare.

Schimbarea domeniului

O companie rebrănduit trece de la @vechi-nume.ro la @nou-nume.ro. Același tenant Google, dar se creează un tenant nou pentru a porni curat (alegere frecventă pentru a evita artefactele de configurare). Migrarea căsuțelor prin imapsync sau GSMMO. Datele se strică exact în același mod.

Consolidarea filialelor

Un grup cu 4 filiale, fiecare pe propriul tenant G Suite istoric, care decide să regrupeze totul pe un tenant unic. Patru migrări în paralel, patru loturi de emailuri cu date corupte de gestionat.

În toate trei scenariile, problema este identică și soluția este aceeași. Checklist-ul de migrare email ajută la anticiparea acestui tip de problemă înainte de lansarea migrării.

De ce un script scris de mână nu este răspunsul

Înțelegerea problemei este un lucru. A-ți spune "o să scriu un script Python care curăță antetele" și a-l aplica pe 30.000 de emailuri de producție este cu totul altceva.

Cazurile limită abundă. Un script care funcționează pe 50 de emailuri de test într-un mediu curat va întâlni inevitabil, pe o căsuță de producție de dimensiune reală:

• Mesaje cu semnături S/MIME sau conținut criptat PGP, unde orice modificare a structurii mesajului invalidează semnătura criptografică.
• Emailuri cu structuri MIME imbricate complexe (multipart/alternative într-un multipart/mixed cu atașamente de câteva zeci de megabytes).
• Antete codificate în RFC 2047 (caractere non-ASCII), pe care parserii prost configurați le consumă în tăcere.
• Erori 429 Too Many Requests de la API-ul Google la 2 dimineața, în mijlocul unui lot de corecție, care lasă procesul într-o stare nedeterminată.
• Emailuri pentru care lanțul Received: este ambiguu: mai multe instrumente de migrare succesive au adăugat fiecare propriul antet, iar identificarea celui de eliminat nu este trivială.

Și întrebarea cea mai importantă: cum verificați, email cu email, că fiecare mesaj corectat este intact și că nimic nu a fost pierdut sau corupt? Un script de casă nu face de obicei această verificare. Redate.io o face automat, cu păstrarea originalelor într-un dosar de backup vizibil timp de 30 de zile.

Ce face Redate.io pentru acest tip de migrare

Redate.io se conectează la tenantul Google Workspace de destinație (prin delegare de domeniu, fără intervenție manuală căsuță cu căsuță) și scanează emailurile pentru a identifica pe cele ale căror metadate de dată sunt inconsistente cu conținutul mesajului. Această fază de scanare este gratuită și oferă o imagine exactă a amplorii problemei înainte de orice corecție.

Motorul de corecție proprietar analizează apoi lanțul de antete al fiecărui mesaj, aplică o corespondență de tipare pe semnăturile cunoscute ale instrumentelor de migrare (BitTitan, CloudM, imapsync, GSMMO și altele mai puțin frecvente), și efectuează o corecție țintită a metadatelor fără a modifica conținutul mesajului. Fiecare email corectat este verificat individual. Originalele sunt păstrate.

Pentru migrările inter-tenant Google Workspace în mod specific, pipeline-ul gestionează cazurile în care au avut loc mai multe treceri de migrare (de exemplu, o căsuță migrată prima oară în 2021 și din nou în 2024), cu mai multe straturi de antete parazite de dezlegat.

Ghidurile de corecție specifice CloudM spre Google Workspace și BitTitan spre Google Workspace detaliază pașii de conectare pentru acest tip de configurație.

Detectarea problemei înainte ca utilizatorii să se plângă

Cel mai bun moment pentru a detecta datele corupte este imediat după migrare, înainte de go-live. O verificare rapidă pe câteva căsuțe pilot printr-un client IMAP ca Thunderbird permite compararea afișajului datelor cu ceea ce ar fi de așteptat. Dacă toate emailurile importate par să aibă aceeași dată recentă, acesta este semnul caracteristic al problemei.

Dar în practică, descoperirea problemei are loc adesea la câteva săptămâni după migrare, când un utilizator caută un contract vechi și realizează că Gmail-ul său este perfect sortat... după data migrării. Mii de emailuri îngrămădite la același marcaj temporal. Căutarea după dată nu mai funcționează. Firele de discuție sunt în dezordine. Istoricul pare să fi dispărut.

Pentru MSP-urile care gestionează regulat migrări inter-tenant Google Workspace, integrarea unui scan Redate.io în checklist-ul post-migrare (înainte de validarea clientului) evită acest tip de surpriză.

Tocmai ați migrat între doi tenanți Google Workspace și datele emailurilor sunt incorecte? Lansați un scan gratuit pe Redate.io pentru a măsura impactul înainte de orice corecție.