Google Workspace til Google Workspace: datoer som brekker

Scenariet ingen mistenker

Du har nettopp fullført migreringen fra ett Google Workspace-tenant til et annet. Et oppkjøp, et domeneskifte, en fusjon av to selskaper som i årevis har levd side om side under separate G Suite-kontoer. Alt gikk greit, postboksene er på plass, brukerne logger inn. Mandag morgen kommer første ticket: "Alle e-postene mine har samme dato." Så en til. Så ti.

Instinktet sier: dette er sikkert et IMAP-problem, et feilkonfigurert verktøy, noe eksotisk. Ikke en Google-til-Google-migrering. Men det er akkurat der det skjer.

Dette er trolig det dårligst dokumenterte scenariet i bransjen. De fleste IT-adminer som møter det, bruker flere timer på å lete etter forklaringen i e-postklienten, i Outlook, i kontoinnstillingene, før de innser at problemet ligger i selve e-postheaderne.

Hvorfor Google-til-Google-migrering ødelegger datoer

For å forstå hva som skjer, må vi gå tilbake til mekanikken bak e-postheadere. Hver RFC 2822-melding inneholder et opprinnelig Date:-felt, satt av klienten eller avsenderserveren da meldingen ble sendt. Det er den "ekte" datoen, den som tilsvarer når e-posten faktisk ble skrevet og sendt.

Men det finnes en annen mekanisme: INTERNALDATE i IMAP. Det er en metadataverdi lagret på serversiden som angir når meldingen ble lagt inn i postboksen. Og det er her det blir interessant.

Når et migreringsverktøy overfører en e-post fra ett Google Workspace-tenant til et annet, bruker det IMAP-protokollen (selv om begge serverne er hos Google). Meldingen leses fra kilden og settes inn på nytt i destinasjonen. I det øyeblikket legger destinasjonsserveren automatisk til en Received:-header med tidsstempelet for operasjonen, altså migreringsdatoen.

Klienter som Outlook bruker den øverste Received:-headeren i kjeden for å vise datoen på en melding, ikke nødvendigvis det opprinnelige Date:-feltet. Resultatet: alle e-poster viser datoen for migreringen.

Hvilke verktøy utløser problemet

Praktisk talt alle verktøy som brukes til migrering mellom Google Workspace-tenanter er berørt. Ingen kjente unntak:

• GSMMO (Google Workspace Migration for Microsoft Outlook): opprinnelig laget for å migrere fra Exchange, men brukt i visse GWS-til-GWS-flyter.
• CloudM Migrate: svært utbredt blant MSPer for migrering mellom Google-tenanter, legger alltid til en migrerings-Received:-header. Se den detaljerte analysen av CloudM.
• BitTitan MigrationWiz: samme adferd, dokumentert i artikkelen om BitTitan.
• imapsync: det åpne verktøyet for å skripte IMAP-migreringer, inkludert mellom to Google-tenanter.
• Manuelle eksporter/importer via Takeout + IMAP-reimport: mindre vanlig, men produserer nøyaktig samme effekt.

Grunnen er enkel: alle disse verktøyene fungerer som vanlige IMAP-klienter. De har ikke tilgang til en "nativ" Google-kanal som ville bevart metadataene. Selv om begge tenantene er hos Google, går overføringen via IMAP-laget, og det laget vet ikke at det snakker med seg selv.

Mekanikken bak Received-headere i detalj

(Forresten, hvis du noen gang har prøvd å lese råheadere fra en e-post i Gmail eller Outlook, vet du at det sjelden er noen hyggelig lesning. Men det er der sannheten gjemmer seg.)

En e-post som har reist normalt inneholder en kjede av Received:-headere i omvendt rekkefølge av reisen: den siste serveren som berørte meldingen, er øverst. Etter en migrering havner migreringsinskripsjonen altså øverst i stabelen.

Slik ser det ut i en melding migrert via CloudM fra ett GWS-tenant til et annet:

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

Date:-feltet sier 2019. Den øverste Received: sier oktober 2024. Outlook leser den øverste Received:. Brukeren ser oktober 2024 for en e-post fra 2019.

Det opprinnelige Date:-feltet er intakt. Det har ikke rørt seg. Det er den gode nyheten: dataen er der, den venter bare på å bli brukt riktig.

Outlook og Gmail oppfører seg ikke likt

Dette er viktig å presisere. Brukere som åpner e-post via Gmails nettgrensesnitt ser ofte riktige datoer, fordi Gmail prioriterer Date:-feltet fra RFC 2822 for visning. Problemet er mindre synlig på nettsiden.

Brukere som kobler sin Google Workspace-postboks til Outlook via IMAP (eller via Exchange ActiveSync-synkronisering) rammes derimot fullt ut av feil dato, fordi Outlook stoler på IMAP INTERNALDATE, som igjen gjenspeiler datoen fra den øverste Received:-headeren lagt til under migreringen.

Egentlig, for å være presis: Outlooks adferd varierer avhengig av versjon og tilkoblingsmodus. Outlook 2019 og Microsoft 365 (nyere versjoner) bruker INTERNALDATE ved IMAP-tilkobling. Eldre versjoner kan oppføre seg litt annerledes. Men i alle produksjonstilfeller som er observert, produserer GWS-til-GWS-migrering via IMAP feil datoer i Outlook.

I organisasjoner som har migrert til et nytt tenant og har hybridbrukere (noen på Gmail på nettet, andre i Outlook), er ticket-meldingene derfor usammenhengende. IT-teamene bruker tid på å forstå hvorfor "noen er berørt og andre ikke", mens svaret rett og slett er: det er e-postklienten som utgjør forskjellen.

Oppkjøp, fusjoner, domeneskifter: de vanligste tilfellene

Denne typen migrering er ikke uvanlig. Her er scenariene som genererer flest tickets:

Oppkjøp av selskap

Et oppkjøpt selskap hadde sitt eget Google Workspace-tenant (domene @gammeltselskap.com). Etter oppkjøpet skal alt migreres til morselskapet sitt tenant (@konsern.com). De 250 postboksene, arkivene, 8 år med e-posthistorikk. BitTitan eller CloudM settes til å gjøre jobben. Resultatet: 2,4 millioner e-poster med datoen fra helgen migreringen ble gjennomført.

Domeneskifte

Et rebrandet selskap bytter fra @gammelnavn.no til @nyttnavn.no. Samme Google-tenant, men man oppretter et nytt tenant for å starte rent (et vanlig valg for å unngå konfigurasjonartefakter). Postboksene flyttes via imapsync eller GSMMO. Datoene brekker på nøyaktig samme måte.

Konsolidering av datterselskaper

Et konsern med 4 datterselskaper, hvert på sitt eget historiske G Suite-tenant, beslutter å samle alt på ett felles tenant. Fire migreringer parallelt, fire puljer med e-poster med ødelagte datoer å håndtere.

I alle tre scenariene er problemet identisk og løsningen den samme. Sjekklisten for e-postmigrering hjelper deg å forutse denne typen problem før migreringen starter.

Hvorfor et hjemmesnekret skript ikke er svaret

Å forstå problemet er én ting. Å tenke "jeg skriver et Python-skript som renser headerne" og kjøre det på 30 000 produksjons-e-poster er noe helt annet.

Kanttilfellene er mange. Et skript som fungerer på 50 test-e-poster i et rent miljø, vil uunngåelig støte på følgende i en produksjonspostboks av reell størrelse:

• Meldinger med S/MIME-signaturer eller PGP-kryptert innhold, der enhver endring i meldingsstrukturen ugyldiggjør den kryptografiske signaturen.
• E-poster med komplekse nestede MIME-strukturer (multipart/alternative inni multipart/mixed med vedlegg på flere titalls megabyte).
• Headere kodet i RFC 2047 (ikke-ASCII-tegn), som feilkonfigurerte parsere spiser stille og rolig.
• 429 Too Many Requests-feil fra Google API klokken 02:00, midt i en korreksjonsbatch, som etterlater prosessen i en ubestemt tilstand.
• E-poster der Received:-kjeden er tvetydig: flere migreringverktøy på rad har hver lagt til sin header, og det er ikke trivielt å avgjøre hvilken som skal fjernes.

Og det viktigste spørsmålet: hvordan verifiserer du, e-post for e-post, at hver korrigert melding er intakt og at ingenting er tapt eller ødelagt? Et hjemmesnekret skript gjør vanligvis ikke denne verifiseringen. Redate.io gjør det automatisk, med bevaring av originaler i en synlig sikkerhetskopieringsmappe i 30 dager.

Hva Redate.io gjør med denne typen migrering

Redate.io kobler seg til destinasjons-Google Workspace-tenanten (via domenedelegering, uten manuell behandling postboks for postboks) og skanner e-poster for å identifisere meldinger der datometadataene er usammenhengende med meldingsinnholdet. Denne skanningsfasen er gratis og gir et presist bilde av problemets omfang før noen korreksjon iverksettes.

Den proprietære korreksjonsmotor analyserer deretter header-kjeden til hver melding, bruker mønstergjenkjenning mot kjente signaturer fra migreringsverktøy (BitTitan, CloudM, imapsync, GSMMO og andre mindre vanlige), og utfører en målrettet metadatakorreksjon uten å endre meldingsinnholdet. Hver korrigert e-post verifiseres individuelt. Originalene bevares.

For migreringer mellom Google Workspace-tenanter spesifikt håndterer pipeline tilfeller der flere migreringspasser har funnet sted (for eksempel en postboks migrert første gang i 2021 og igjen i 2024), med flere lag av forstyrrende headere som må sorteres ut.

Se spesifikk veiledning for CloudM til Google Workspace og BitTitan til Google Workspace for tilkoblingstrinnene for denne konfigurasjonen.

Oppdage problemet før brukerne klager

Det beste tidspunktet for å oppdage ødelagte datoer er rett etter migreringen, før go-live. En rask sjekk på noen pilotpostbokser via en IMAP-klient som Thunderbird lar deg sammenligne datovisningen med det du forventer. Hvis alle importerte e-poster ser ut til å ha samme ferske dato, er det det karakteristiske tegnet på problemet.

I praksis oppdages problemet likevel ofte flere uker etter migreringen, når en bruker leter etter en gammel kontrakt og innser at Gmail-postboksen er perfekt sortert... etter migreringsdato. Tusenvis av e-poster stablet opp med samme tidsstempel. Søk etter dato fungerer ikke lenger. Tråder er i uorden. Historikken ser ut til å ha forsvunnet.

For MSPer som jevnlig håndterer migreringer mellom Google Workspace-tenanter: å legge inn et Redate.io-skan i sjekklisten etter migrering (før kundegodkjenning) unngår slike overraskelser.

Har du nettopp migrert mellom to Google Workspace-tenanter og e-postdatoene er feil? Start et gratis skan på Redate.io for å måle omfanget før du gjør noe mer.