Google Workspace'i migreerimine: katkised kuupäevad

Stsenaarium, mida keegi ei oska ette näha

Olete lõpetanud migreerimise ühest Google Workspace'i tenandist teise. Ettevõtte ost, domeeninime vahetus, kahe eraldi G Suite'i kontol aastaid kõrvuti eksisteerinud üksuse liitmine. Operatsioon kulges ladusalt, postkastid on paigas, kasutajad logisid sisse. Esmaspäeva hommikul saabub esimene tugipilet: "Kõigil minu kirjadel on ühesugune kuupäev." Siis teine. Siis kümme.

Instinktiivselt arvate: see on kindlasti IMAP-probleem, vale seadistusega tööriist, midagi eksootiliselt erilist. Mitte Google'ist Google'isse migreerimine. Ometigi - see on täpselt see, mis juhtub.

See stsenaarium on tõenäoliselt valdkonnas kõige halvemini dokumenteeritud. Enamik IT-administraatoreid, kes sellega kokku puutub, kulutab mitu tundi vastuse otsimisele meilikliendi, Outlooki või konto sätete poolt - enne kui mõistab, et probleem peitub e-kirjade päistes endis.

Miks Google'ist Google'isse migreerimine kuupäevad katkestab

Et mõista, mis toimub, tuleb naasta e-kirja päiste mehhanismide juurde. Iga RFC 2822 sõnum sisaldab originaalset välja Date:, mille pani paika saatja klient või server sõnumi saatmise hetkel. See on e-kirja "tõeline" kuupäev - see, mis vastab tegeliku kirjutamise ja saatmise ajale.

Kuid olemas on ka teine mehhanism: IMAP-i INTERNALDATE. See on serveri poolel talletatud metaandmevälj, mis näitab, millal sõnum postkasti laaditi. Ja siin läheb asi huvitavaks.

Kui migreerimistööriist kannab e-kirja ühest Google Workspace'i tenandist teise, kasutab see IMAP-protokolli (isegi kui mõlemad serverid asuvad Google'is). Sõnum loetakse lähtekohast ja sisestatakse uuesti sihtkohta. Sellel uuesti sisestamise hetkel lisab sihtserver automaatselt päise Received:, millele on märgitud toimingu ajatempel - st migreerimise kuupäev.

Sellised meilikliendid nagu Outlook kasutavad sõnumi kuupäeva kuvamiseks ahela esimest Received: päist, mitte alati originaalset Date: välja. Tulemus: kõik e-kirjad näitavad migreerimise päeva kuupäeva.

Millised tööriistad probleemi põhjustavad

Praktiliselt kõik Google Workspace'i vahelisteks migreerimisteks kasutatavad tööriistad on mõjutatud. Märkimisväärseid erandeid pole:

• GSMMO (Google Workspace Migration for Microsoft Outlook): algselt loodud Exchange'ist migreerimiseks, kuid kasutusel ka mõnedes GWS-i GWS-i töövoogudes.
• CloudM Migrate: MSP-de seas väga levinud Google'i vaheliste migratsioonide jaoks, lisab süstemaatiliselt migreerimise Received: päise. Vaadake CloudM'i üksikasjalikku analüüsi.
• BitTitan MigrationWiz: sama käitumine, mis on dokumenteeritud BitTitanit käsitlevas artiklis.
• imapsync: avatud lähtekoodiga tööriist IMAP-migratsioonide skriptimiseks, sealhulgas kahe Google'i tenandi vahel.
• Käsitsiekspordid/impordid Takeout + IMAP reimport kaudu: vähem levinud, kuid tekitavad täpselt sama efekti.

Põhjus on lihtne: kõik need tööriistad toimivad tavaliste IMAP-klientidena. Neil puudub juurdepääs Google'i "natiivsele" teele, mis metaandmeid säilitaks. Isegi kui mõlemad tenandid asuvad Google'is, toimub edastus IMAP-kihi kaudu - ja see kiht ei tea, et ta räägib iseendaga.

Received-päiste mehanism üksikasjalikult

(Muide, kui olete kunagi proovinud lugeda e-kirja toorpäiseid Gmail'ist või Outlookist, teate, et see pole just rannalugemine. Aga just seal peitub kogu tõde.)

Normaalselt liikunud e-kiri sisaldab Received: päiste ahelat pöördkronoloogilises järjekorras: sõnumit viimati puudutanud server on kõige ülemine. Pärast migreerimist satub migreerimispäis just virna tippu.

Näide sellest, kuidas see välja näeb CloudM'i kaudu ühest GWS-i tenandist teise migreeritud sõnumis:

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

Väli Date: ütleb 2019. Esimene Received: ütleb oktoober 2024. Outlook loeb esimese Received: väärtuse. Kasutaja näeb 2024. aasta oktoobrit 2019. aasta kirjal.

Originaalne Date: väli on puutumata. See pole kuskile kadunud. See on hea uudis: andmed on olemas, need ootavad lihtsalt õiget kasutamist.

Outlook ja Gmail käituvad erinevalt

See on oluline täpsustus. Kasutajad, kes kasutavad e-posti Gmail'i veebiliidese kaudu, näevad sageli õigeid kuupäevi, sest Gmail kasutab sõnumite kuvamiseks eelisjärjekorras RFC 2822 välja Date:. Veebipoolel on probleem vähem nähtav.

Seevastu kasutajad, kes seadistasid Google Workspace'i postkasti Outlookis IMAP kaudu (või Exchange ActiveSync sünkroonimise kaudu), saavad vale kuupäeva täie jõuga kätte - Outlook toetub IMAP-i INTERNALDATE'ile, mis peegeldab migreerimise käigus lisatud esimese Received: päise kuupäeva.

Täpsuse huvides: Outlooki käitumine varieerub versiooni ja ühendusrežiimi järgi. Outlook 2019 ja Microsoft 365 (uuemad versioonid) kasutavad IMAP-iga ühendudes INTERNALDATE'i. Vanemad versioonid võivad käituda veidi teisiti. Kuid kõigis tootmiskeskkonnas täheldatud juhtumites tekitab GWS-i GWS-i migreerimine IMAP kaudu Outlookis valed kuupäevad.

Seetõttu on organisatsioonides, kus on migreeritud uude tenanti ja kus on hübriidkasutajaid (osa kasutab Gmail'i veebis, osa Outlookis), tugipileti esitamine ebaühtlane. IT-meeskonnad veedavad aega mõistatades, miks "mõnedel on probleem, teistel mitte" - kuigi vastus on lihtne: vahe teeb meiliklient.

Ostud, ühinemised, domeeninime vahetused: kõige sagedasemad juhtumid

Seda tüüpi migratsioon pole haruldane. Kõige rohkem tugipileteid tekitavad järgmised stsenaariumid:

Ettevõtte ost

Ostetud ettevõttel oli oma Google Workspace'i tenand (domeen @vanaettevõte.com). Pärast ostu tuleb kõik migreerida emaettevõtte tenanti (@kontsern.com). 250 postkasti, arhiivid, 8 aastat e-posti ajalugu. BitTitan või CloudM saab ülesande. Tulemus: 2,4 miljonit e-kirja migreerimise nädalavahetuse kuupäevaga.

Domeeninime vahetus

Rebränditud ettevõte läheb @vananimi.ee-lt üle @uusnimi.ee-le. Sama Google'i tenand, kuid luuakse uus tenand, et alustada puhtalt lehelt (tavaline valik konfiguratsiooniartifaktide vältimiseks). Postkastide migreerimine imapsynci või GSMMO kaudu. Kuupäevad katkevad täpselt samal viisil.

Tütarettevõtete konsolideerimine

Kontsern 4 tütarettevõttega, igaüks oma ajaloolisel G Suite'i tenandil, otsustab kõik koondada ühele tenandile. Neli paralleelset migreerimist, neli partiid rikutud kuupäevadega e-kirju.

Kõigis kolmes stsenaariumis on probleem identne ja lahendus sama. E-posti migreerimise kontrollnimekiri aitab seda tüüpi probleemi enne migreerimise alustamist ette näha.

Miks kodune skript pole lahendus

Probleemist aru saada on üks asi. Otsustada kirjutada Python-skript, mis päised ära koristab, ja rakendada seda 30 000 tootmis-e-kirjal - see on hoopis teine asi.

Äärejuhte on üksjagu. Skript, mis töötab 50 testkirjal puhtas testimiskeskkonnas, jookseb tootmispostkastis paratamatult kokku järgmistega:

• Sõnumid S/MIME allkirjade või PGP-krüptitud sisuga, kus igasugune sõnumi struktuuri muutmine tühistab krüptograafilise allkirja.
• E-kirjad keeruliste pesastatud MIME-struktuuridega (multipart/alternative multipart/mixed sees koos kümneid megabaite kaaluvate manustega).
• RFC 2047 kodeeritud päised (mitte-ASCII märgid), mida valesti seadistatud parserid vaikselt "söövad".
• 429 Too Many Requests vead Google'i API-lt kell 2 öösel, parajasti korrektsioonipartiide keskel, mis jätavad protsessi määramatusse seisundisse.
• E-kirjad, kus Received: ahel on mitmetähenduslik: mitu järjestikust migreerimistööriista on igaüks lisanud oma päise, ning pole triviaalne otsustada, milline neist eemaldada.

Ja kõige olulisem küsimus: kuidas kontrollida, e-kiri e-kirja haaval, et iga parandatud sõnum on terviklik ja midagi pole kadunud või rikutud? Kodune skript seda kontrolli tavaliselt ei tee. Redate.io teeb seda automaatselt, säilitades originaalid nähtavas varunduskaustas 30 päeva jooksul.

Mida Redate.io seda tüüpi migreerimise korral teeb

Redate.io ühendub sihtkoha Google Workspace'i tenandiga (domeenidelegeerimise kaudu, ilma postkast-postkasilt käsitsi sekkumiseta) ja skannib e-kirju, et tuvastada need, mille kuupäeva metaandmed ei ühti sõnumi sisuga. See skannimisetapp on tasuta ja annab täpse ülevaate probleemi ulatusest enne korrektsiooni.

Seejärel analüüsib patenteeritud korrektsioonimotor iga sõnumi päiseahelat, rakendab muster-vastendust tuntud migreerimistööriistade allkirjadel (BitTitan, CloudM, imapsync, GSMMO ja teised vähem levinud), ning teostab sihtotstarbelise metaandmete korrektsiooni sõnumi sisu muutmata. Iga parandatud e-kiri kontrollitakse individuaalselt. Originaalid säilitatakse.

Google Workspace'i vaheliste migreerimiste puhul spetsiifiliselt haldab pipeline juhtumeid, kus on toimunud mitu migreerimisläbimist (näiteks postkast, mis migreeriti esimest korda 2021. aastal ja seejärel uuesti 2024. aastal), kus tuleb lahti harutada mitu kihti parasiitpäiseid.

Spetsiifilised korrektsioonijuhendid CloudM Google Workspace'i jaoks ja BitTitan Google Workspace'i jaoks kirjeldavad seda tüüpi konfiguratsiooni ühendamisetappe.

Probleemi avastamine enne, kui kasutajad kaebavad

Parim aeg rikutud kuupäevade avastamiseks on vahetult pärast migreerimist, enne kasutuselevõttu. Kiire kontroll mõnel pilootpostkastil IMAP-kliendi nagu Thunderbird kaudu võimaldab võrrelda kuupäevade kuvamist oodatavaga. Kui kõik imporditud e-kirjad näivad olevat sama hiljutise kuupäevaga, on see probleemi iseloomulik tunnus.

Tegelikult avastatakse probleem sageli alles mitu nädalat pärast migreerimist, kui kasutaja otsib vana lepingut ja avastab, et tema Gmail'i postkast on küll korralikult sorteeritud... migreerimiskuupäeva järgi. Tuhanded e-kirjad kuhjatud sama ajatempli alla. Kuupäeva järgi otsimine ei tööta enam. Vestluslõimed on segased. Ajalugu näib olevat kadunud.

MSP-de jaoks, kes haldavad regulaarselt Google Workspace'i vahelisi migreerimisi, väldib Redate.io skaneerimise integreerimine migratsioonijärgsesse kontrollnimekirja (enne kliendi valideerimist) seda tüüpi üllatusi.

Kas migreeerisite just kahe Google Workspace'i tenandi vahel ja e-kirjade kuupäevad on valed? Käivitage Redate.io-s tasuta skannimine, et mõõta mõju enne korrektsiooni.