Google Workspace til GWS-migrering: datoer i stykker

Det scenarie ingen forventer

Du har netop afsluttet en migrering fra ét Google Workspace-tenant til et andet. Et opkøb, et domænenavnsskift, eller to enheder der har eksisteret under separate G Suite-konti i årevis og nu skal samles. Operationen gik fint, postkasserne er på plads, brugerne logger ind. Mandag morgen: første ticket. "Alle mine e-mails har samme dato." Så endnu en. Og ti mere.

Instinktivt tænker du: det er nok et IMAP-problem, et forkert konfigureret værktøj, noget eksotisk. Ikke en Google-til-Google-migrering. Og alligevel er det præcis her, problemet opstår.

Dette scenarie er nok det mest underdokumenterede i branchen. De fleste IT-admins der støder på det, bruger flere timer på at lede efter en forklaring i mailklienten, i Outlook, i kontoindstillingerne, før de indser at problemet sidder i selve e-mailenes headere.

Hvorfor en Google-til-Google-migrering ødelægger datoer

For at forstå hvad der sker, skal vi tilbage til mekanikken bag e-mail-headere. Hver RFC 2822-besked indeholder et originalt Date:-felt, som klienten eller afsenderserveren tilføjer på afsendelsestidspunktet. Det er e-mailens "rigtige" dato, den der svarer til hvornår beskeden blev skrevet og sendt.

Men der findes en anden mekanisme: INTERNALDATE i IMAP. Det er en serverside-metadata der angiver hvornår beskeden blev lagt i postkassen. Og det er her det bliver interessant.

Når et migreringsværktøj overfører en e-mail fra ét Google Workspace-tenant til et andet, sker det via IMAP-protokollen (selv når begge servere er hos Google). Beskeden læses fra kilden og genindsættes i destinationen. I det øjeblik tilføjer destinationsserveren automatisk en Received:-header med tidsstemplet for operationen, dvs. migrationsdatoen.

Mailklienter som Outlook bruger den første Received:-header i kæden til at vise datoen på en besked, ikke nødvendigvis det originale Date:-felt. Resultatet: alle e-mails viser migrationsdatoen.

Hvilke værktøjer udløser problemet

Næsten alle værktøjer der bruges til GWS-til-GWS-migreringer er berørt. Ingen nævneværdige undtagelser:

• GSMMO (Google Workspace Migration for Microsoft Outlook): oprindeligt designet til migrering fra Exchange, men brugt i visse GWS-til-GWS-flows.
• CloudM Migrate: meget udbredt hos MSPs til inter-Google-migreringer, tilføjer systematisk en migrations-Received:-header. Se den detaljerede analyse af CloudM.
• BitTitan MigrationWiz: samme adfærd, dokumenteret i artiklen om BitTitan.
• imapsync: det open source-værktøj der bruges til at scripte IMAP-migreringer, herunder mellem to Google-tenants.
• Manuelle eksporter/importerer via Takeout + IMAP-reimport: sjældnere, men producerer nøjagtig samme effekt.

Forklaringen er enkel: alle disse værktøjer fungerer som standard IMAP-klienter. De har ikke adgang til en "native" Google-vej der ville bevare metadataene. Selv hvis begge tenants er hos Google, går overførslen via IMAP-laget, og det lag ved ikke at det taler med sig selv.

Received-headernes mekanik i detaljer

(Har du nogensinde prøvet at læse de rå headere på en e-mail i Gmail eller Outlook, ved du at det ikke ligefrem er afslappende læsning. Men det er her hele sandheden gemmer sig.)

En e-mail der har rejst normalt indeholder en kæde af Received:-headere i omvendt rækkefølge af ruten: den server der senest rørte beskeden, står øverst. Efter en migrering havner migrations-headeren altså øverst i stakken.

Sådan ser det ud i en besked migreret via CloudM fra ét GWS-tenant til et andet:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <bruger@nyt-domæne.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 siger 2019. Den første Received: siger oktober 2024. Outlook læser den første Received:. Brugeren ser oktober 2024 på en e-mail fra 2019.

Det originale Date:-felt er intakt. Det har ikke rykket sig. Det er den gode nyhed: dataen er der, den venter bare på at blive brugt korrekt.

Outlook og Gmail opfører sig ikke ens

Det er en vigtig nuance. Brugere der tilgår deres e-mails via Gmails webgrænseflade ser ofte de rigtige datoer, fordi Gmail prioriterer Date:-feltet (RFC 2822) når beskeder vises. Problemet er mindre synligt på webbet.

Til gengæld rammes brugere der har opsat deres Google Workspace-postkasse i Outlook via IMAP (eller via Exchange ActiveSync-synkronisering) fuldt ud af den forkerte dato, fordi Outlook stoler på IMAP INTERNALDATE, som afspejler datoen fra den første Received:-header tilføjet under migreringen.

Præcis sagt varierer Outlooks adfærd afhængigt af version og forbindelsestilstand. Outlook 2019 og Microsoft 365 (nyere versioner) bruger INTERNALDATE ved IMAP-forbindelser. Ældre versioner kan opføre sig lidt anderledes. Men i alle observerede produktionstilfælde producerer GWS-til-GWS-migrering via IMAP forkerte datoer i Outlook.

I organisationer der har migreret til et nyt tenant og har hybride brugere (nogle på Gmail-web, andre på Outlook) er ticket-mønsteret inkonsistent. IT-teamet bruger tid på at forstå hvorfor "nogle er berørt og andre ikke er", mens svaret simpelthen er: det er mailklienten der gør forskellen.

Opkøb, fusioner, domænenavnsskift: de hyppigste tilfælde

Denne type migrering er ikke sjælden. Her er de scenarier der genererer flest tickets:

Virksomhedsopkøb

En opkøbt virksomhed havde sit eget Google Workspace-tenant (domænet @gammeltfirma.dk). Efter opkøbet skal alt migreres til moderselskabets tenant (@koncern.dk). De 250 postkasser, arkiverne, 8 års e-mailhistorik. BitTitan eller CloudM mandateres til opgaven. Resultat: 2,4 millioner e-mails med datoen fra migreringsweekenden.

Domænenavnsskift

En rebrandet virksomhed skifter fra @gammelnavn.dk til @nynavn.dk. Samme Google-tenant, men der oprettes et nyt tenant for at starte frisk (et almindeligt valg for at undgå konfigurationsartefakter). Postkasserne migreres via imapsync eller GSMMO. Datoerne går i stykker på nøjagtig samme måde.

Konsolidering af datterselskaber

En koncern med 4 datterselskaber, hver på deres eget historiske G Suite-tenant, beslutter sig for at samle alt på ét tenant. Fire parallelle migreringer, fire partier e-mails med korrupte datoer der skal håndteres.

I alle tre scenarier er problemet identisk og løsningen den samme. Tjeklisten til e-mailmigrering hjælper dig med at forudse denne type problem inden migreringen sættes i gang.

Hvorfor et hjemmelavet script ikke er svaret

At forstå problemet er én ting. At sige "jeg skriver et Python-script der rydder op i headerne" og køre det på 30.000 produktions-e-mails er noget helt andet.

Undtagelsestilfælde er der nok af. Et script der virker på 50 test-e-mails i et rent miljø, vil uundgåeligt støde på disse i en rigtig produktionspostkasse:

• Beskeder med S/MIME-signaturer eller PGP-krypteret indhold, hvor enhver ændring af beskedstrukturen ugyldiggør den kryptografiske signatur.
• E-mails med komplekse indlejrede MIME-strukturer (multipart/alternative inde i multipart/mixed med vedhæftede filer på adskillige titusinde megabyte).
• Headere kodet i RFC 2047 (ikke-ASCII-tegn), som forkert konfigurerede parsere spiser lydløst.
• 429 Too Many Requests-fejl fra Google API'et klokken 2 om natten, midt i et korrektionsbatch, der efterlader processen i en ubestemt tilstand.
• E-mails hvor Received:-kæden er tvetydig: flere på hinanden følgende migreringsværktøjer har hver tilføjet deres header, og det er ikke trivielt at afgøre hvilken der skal fjernes.

Og det vigtigste spørgsmål: hvordan verificerer du, e-mail for e-mail, at hver korrigeret besked er intakt og intet er gået tabt eller beskadiget? Et hjemmelavet script udfører typisk ikke denne verifikation. Redate.io gør det automatisk, med bevaring af originalerne i en synlig sikkerhedskopimappe i 30 dage.

Hvad Redate.io gør ved denne type migrering

Redate.io forbinder til destinations-Google Workspace-tenanten (via domænedelegering, uden manuel intervention postkasse for postkasse) og scanner e-mails for at identificere dem hvis datometadata er inkonsistente med beskedindholdet. Denne scanningsfase er gratis og giver et præcist billede af problemets omfang inden nogen korrektion sættes i gang.

Den proprietære korrektionsmotor analyserer derefter header-kæden for hver besked, anvender mønstergenkendelse på kendte signaturer fra migreringsværktøjer (BitTitan, CloudM, imapsync, GSMMO og andre mindre udbredte), og foretager en målrettet metadatakorrektion uden at ændre beskedindholdet. Hver korrigeret e-mail verificeres individuelt. Originalerne bevares.

Specifikt for inter-tenant Google Workspace-migreringer håndterer pipelinen tilfælde hvor der er foretaget flere migrationspas (fx en postkasse migreret første gang i 2021 og igen i 2024), med flere lag parasitære headere der skal sorteres fra hinanden.

Korrektionstjenesterne CloudM til Google Workspace og BitTitan til Google Workspace beskriver forbindelsestrinnene for denne type konfiguration.

Opdage problemet inden brugerne klager

Det bedste tidspunkt at opdage korrupte datoer er lige efter migreringen, inden go-live. En hurtig kontrol på et par pilotpostkasser via en IMAP-klient som Thunderbird giver mulighed for at sammenligne datoudvisningen med det forventede. Hvis alle importerede e-mails ser ud til at have den samme nylige dato, er det det karakteristiske tegn på problemet.

I praksis opdages problemet dog ofte flere uger efter migreringen, når en bruger leder efter en gammel kontrakt og indser at Gmail-postkassen er perfekt sorteret... efter migrationsdato. Tusindvis af e-mails stablet med samme tidsstempel. Datobaseret søgning virker ikke længere. Samtaletråde er i uorden. Historikken ser ud til at være forsvundet.

For MSPs der regelmæssigt håndterer inter-tenant Google Workspace-migreringer, undgår man denne type overraskelse ved at integrere et Redate.io-scan i post-migrerings-tjeklisten (inden kundegodkendelse).

Har du netop migreret mellem to Google Workspace-tenants og dine e-maildatoer er forkerte? Start et gratis scan på Redate.io for at måle omfanget inden nogen korrektion foretages.