Google Workspace į GWS migracija: datos sulaužytos

Scenarijus, kurio niekas neįtaria

Ką tik baigėte migraciją iš vieno Google Workspace tenanto į kitą. Įmonės pirkimas, domeno keitimas, dviejų padalinių, kurie kelerius metus gyvavo atskiruose G Suite paskyrose, sujungimas. Operacija pavyko, pašto dėžutės veikia, vartotojai jungiasi. Pirmadienio rytas, pirmas bilietas: „Visi mano laiškai turi tą pačią datą." Paskui antras. Paskui dešimt.

Intuityviai manote: tai kažkoks IMAP problema, blogai sukonfigūruotas įrankis, kažkas egzotiška. Tikrai ne „Google į Google" migracija. Tačiau būtent ten ir nutinka.

Šis scenarijus tikriausiai yra blogiausiai dokumentuotas visoje srityje. Dauguma IT administratorių, kurie su juo susiduria, praleidžia kelias valandas ieškodami priežasties pašto kliento pusėje, Outlook pusėje, paskyros nustatymuose, kol supranta, kad problema yra pačiuose laiškų antraštėse.

Kodėl „Google į Google" migracija sugadina datas

Norint suprasti, kas vyksta, reikia grįžti prie el. pašto antraščių mechanikos. Kiekvienas RFC 2822 pranešimas turi originalų lauką Date:, kurį užpildo siuntėjo klientas arba serveris siuntimo momentu. Tai „tikroji" laiško data, atitinkanti laiką, kada žinutė buvo parašyta ir išsiųsta.

Tačiau egzistuoja kitas mechanizmas: IMAP INTERNALDATE. Tai serverio pusėje saugoma metaduomenų reikšmė, nurodanti, kada pranešimas buvo įdėtas į dėžutę. Ir čia prasideda įdomumai.

Kai migracijos įrankis perduoda laišką iš vieno Google Workspace tenanto į kitą, jis naudoja IMAP protokolą (net jei abu serveriai yra pas Google). Pranešimas nuskaitomas iš šaltinio, o paskui įterpiamas į paskirties dėžutę. Tuo įterpimo momentu paskirties serveris automatiškai prideda Received: antraštę su operacijos laiko žyma, tai yra migracijos data.

O tokie pašto klientai kaip Outlook, norėdami rodyti laiško datą, naudoja pirmąją Received: grandinėje, o ne originalų Date: lauką. Rezultatas: visi laiškai rodo migracijos dienos datą.

Kokie įrankiai sukelia problemą

Praktiškai visi įrankiai, naudojami tarptenantinėms Google Workspace migracijoms, yra paveikti. Nėra reikšmingų išimčių:

• GSMMO (Google Workspace Migration for Microsoft Outlook): iš pradžių sukurtas migracijoms iš Exchange, bet naudojamas ir kai kuriuose GWS į GWS srautuose.
• CloudM Migrate: labai paplitęs tarp MSP vykdant tarpgooglines migracijas, sistemingai prideda migracijos Received: antraštę. Žr. išsamią CloudM analizę.
• BitTitan MigrationWiz: tas pats, elgsena aprašyta šiame straipsnyje apie BitTitan.
• imapsync: atvirojo kodo įrankis, leidžiantis skriptuoti IMAP migracijas, įskaitant tarp dviejų Google tenantų.
• Rankinis eksportas/importas naudojant Takeout + IMAP reimportą: rečiau naudojamas, tačiau duoda lygiai tą patį efektą.

Priežastis paprasta: visi šie įrankiai veikia kaip standartiniai IMAP klientai. Jie neturi prieigos prie „natyvaus" Google kelio, kuris išsaugotų metaduomenis. Net jei abu tenantai yra pas Google, perdavimas vyksta per IMAP sluoksnį, o šis sluoksnis „nežino", kad kalba pats su savimi.

Received antraščių mechanika išsamiau

(Beje, jei esate bandę skaityti neapdorotą el. laiško antraštę iš Gmail ar Outlook, žinote, kad tai retai kada malonus skaitymas. Bet būtent ten slepiasi visa tiesa.)

Normaliai keliavęs el. laiškas turi Received: antraščių grandinę atvirkštine maršruto tvarka: paskutinis serveris, liečęs pranešimą, yra viršuje. Po migracijos migracijos antraštė atsiduria pačioje steko viršūnėje.

Štai kaip tai atrodo pranešime, migruotame per CloudM iš vieno GWS tenanto į kitą:

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

Laukas Date: rodo 2019-uosius. Pirmoji Received: rodo 2024 m. spalį. Outlook skaito pirmąją Received:. Vartotojas mato 2024 m. spalį 2019 m. laiškui.

Originalus Date: laukas yra nepažeistas. Jis nepasikeitė. Tai gera žinia: duomuo yra ten, jis tiesiog laukia, kol bus naudojamas teisingai.

Outlook ir Gmail elgiasi skirtingai

Tai svarbus patikslinimas. Vartotojai, kurie naudoja Gmail žiniatinklio sąsają, dažnai mato teisingas datas, nes Gmail pirmenybę teikia RFC 2822 laukui Date: rodyti pranešimus. Problema mažiau matoma žiniatinklyje.

Tačiau vartotojai, kurie sukonfigūravo savo Google Workspace dėžutę Outlook per IMAP (arba per Exchange ActiveSync sinchronizaciją), visiškai jaučia neteisingą datą, nes Outlook pasitiki IMAP INTERNALDATE, kuris atspindi pirmosios migracijos metu pridėtos Received: antraštės datą.

Tiksliau sakant, Outlook elgsena skiriasi priklausomai nuo versijos ir ryšio būdo. Outlook 2019 ir Microsoft 365 (naujausios versijos) naudoja INTERNALDATE jungiantis per IMAP. Senesnės versijos gali elgtis šiek tiek kitaip. Tačiau visais stebėtais gamybiniais atvejais GWS į GWS migracija per IMAP sukuria neteisingas datas Outlook programoje.

Taigi organizacijose, kurios migravo į naują tenantą ir turi hibridinių vartotojų (vieni naudoja Gmail žiniatinklį, kiti Outlook), bilietų srautas būna nenuoseklus. IT komandos praleidžia laiką bandydamos suprasti, kodėl „vieni paveikti, kiti ne", nors atsakymas paprastas: skirtumas - pašto klientas.

Įsigijimai, susijungimai, domenų keitimai: dažniausi atvejai

Tokio tipo migracija nėra retenybė. Štai scenarijai, generuojantys daugiausiai bilietų:

Įmonės įsigijimas

Įsigyta įmonė turėjo savo Google Workspace tenantą (domenas @senaįmonė.lt). Po įsigijimo viskas turi migruoti į patronuojančios įmonės tenantą (@grupe.lt). 250 dėžučių, archyvai, 8 metų el. pašto istorija. BitTitan ar CloudM pasitelkiamas operacijai. Rezultatas: 2,4 milijono laiškų su migracijos savaitgalio data.

Domeno keitimas

Perkurtas prekės ženklas pereina nuo @senaspavadinimas.lt prie @naujaspavadinimas.lt. Tas pats Google tenantas, tačiau kuriamas naujas tenantas, norint pradėti švariai (dažnas pasirinkimas vengiant konfigūracijos artefaktų). Dėžučių migracija per imapsync ar GSMMO. Datos sugenda lygiai taip pat.

Filialų konsolidacija

Grupė su 4 filialais, kiekvienas turintis savo istorinį G Suite tenantą, nusprendžia viską sujungti į vieną tenantą. Keturios lygiagrečios migracijos, keturi sugadintų datų el. laiškų rinkiniai apdorojimui.

Visuose trijuose scenarijuose problema yra identiška ir sprendimas tas pats. El. pašto migracijos kontrolinis sąrašas padeda numatyti tokio tipo problemas prieš pradedant migraciją.

Kodėl rankinis skriptas nėra atsakymas

Suprasti problemą - viena. Nuspręsti „parašysiu Python skriptą, kuris išvalys antraštes" ir pritaikyti jį 30 000 gamybinių laiškų - visai kas kita.

Kraštutinių atvejų yra daugybė. Skriptas, veikiantis su 50 bandomųjų laiškų švariai aplinkoje, neišvengiamai tikroje gamybinėje dėžutėje susidurs su:

• Pranešimais su S/MIME parašais arba PGP šifravimu, kur bet koks pranešimo struktūros pakeitimas panaikina kriptografinį parašą.
• El. laiškais su sudėtingomis įterptomis MIME struktūromis (multipart/alternative viduje multipart/mixed su kelių dešimčių megabaitų priedais).
• RFC 2047 koduotomis antraštėmis (ne ASCII simboliai), kurias blogai sukonfigūruoti analizatoriai tyliai „suvalgo".
• Klaidomis 429 Too Many Requests iš Google API 2 val. nakties, tiesiai taisymo partijos viduryje, paliekant procesą neapibrėžtoje būsenoje.
• Laiškais, kurių Received: grandinė yra dviprasmiška: keli iš eilės naudoti migracijos įrankiai kiekvienas pridėjo savo antraštę, ir nėra trivialus klausimas, kurią reikia šalinti.

Ir svarbiausia: kaip patikrinti, laiškas po laiško, kad kiekvienas pataisytas pranešimas yra sveikas ir nieko neprarandama ar nesugadinama? Rankinis skriptas paprastai šio patikrinimo nedaro. Redate.io tai atlieka automatiškai, saugodamas originalus matomame atsarginių kopijų aplanke 30 dienų.

Ką Redate.io daro su tokio tipo migracijomis

Redate.io jungiasi prie paskirties Google Workspace tenanto (per domeno delegavimą, be rankinio įsikišimo dėžutė po dėžutės) ir nuskaito laiškus, identifikuodamas tuos, kurių datos metaduomenys neatitinka pranešimo turinio. Ši nuskaitymo fazė yra nemokama ir suteikia tikslų problemos masto vaizdą prieš bet kokią taisymą.

Patentuotas taisymo variklis analizuoja kiekvieno pranešimo antraščių grandinę, taiko šablonų atitikimą žinomoms migracijos įrankių parašams (BitTitan, CloudM, imapsync, GSMMO ir kitiems mažiau paplitusiems), ir atlieka tikslinę metaduomenų korekciją nekeičiant pranešimo turinio. Kiekvienas pataisytas laiškas tikrinamas atskirai. Originalai išsaugomi.

Konkrečiai tarptenaninėms Google Workspace migracijoms, apdorojimo pipeline'as tvarko atvejus, kai migracija buvo atlikta kelis kartus (pavyzdžiui, dėžutė migruota pirmą kartą 2021 m., o paskui dar kartą 2024 m.), su keliais sluoksniais parazitinių antraščių, kurias reikia išnarploti.

Specialūs taisymo vadovai CloudM į Google Workspace ir BitTitan į Google Workspace aprašo prisijungimo žingsnius šio tipo konfigūracijai.

Aptikti problemą prieš vartotojams paskundžiant

Geriausias laikas aptikti sugadintas datas - iš karto po migracijos, prieš paleidžiant sistemą gamybai. Greitas patikrinimas keliose bandomosiose dėžutėse per IMAP klientą kaip Thunderbird leidžia palyginti datų rodymą su tuo, ko tikėtasi. Jei visi importuoti laiškai atrodo turintys tą pačią naują datą, tai yra charakteringas problemos požymis.

Tačiau praktiškai problema dažnai aptinkama kelios savaitės po migracijos, kai vartotojas ieško senos sutarties ir supranta, kad jo Gmail dėžutė yra puikiai surūšiuota... pagal migracijos datą. Tūkstančiai laiškų sugrūsti į tą patį laiko žymeklį. Paieška pagal datą nebėveikia. Diskusijų gijos sumaišytos. Istorija tarsi dingo.

MSP, kurie reguliariai valdo tarptenantines Google Workspace migracijas, Redate.io nuskaitymo įtraukimas į migracijos po baigimo kontrolinį sąrašą (prieš kliento patvirtinimą) išvengia tokio tipo nemalonumų.

Ką tik migravote tarp dviejų Google Workspace tenantų ir el. laiškų datos yra neteisingos? Paleiskite nemokamą nuskaitymą Redate.io, kad įvertintumėte poveikį prieš bet kokį taisymą.