Google Workspace till GWS-migrering: datum går sönder

Scenariot ingen misstänker

Du har precis slutfört en migrering från en Google Workspace-tenant till en annan. Ett företagsförvärv, ett domänbyte, en sammanslagning av två enheter som levt i separata G Suite-konton i flera år. Allt gick bra, postlådorna är på plats, användarna loggar in. Måndag morgon, första ärendet: "Alla mina e-postmeddelanden har samma datum." Sedan ett till. Sedan tio.

Instinktivt tänker du: det är ett IMAP-problem, ett felkonfigurerat verktyg, något ovanligt. Inte en Google-till-Google-migrering. Men det är precis där det händer.

Det här scenariot är förmodligen det sämst dokumenterade i branschen. De flesta IT-administratörer som stöter på det lägger flera timmar på att leta efter en förklaring i e-postklienten, i Outlook, i kontoinställningarna, innan de inser att problemet sitter i e-postmeddelandenas egna huvuden.

Varför en Google-till-Google-migrering bryter datum

För att förstå vad som händer behöver vi gå tillbaka till grunderna för e-posthuvuden. Varje RFC 2822-meddelande innehåller ett ursprungligt Date:-fält, satt av avsändarens klient eller server vid sändningstillfället. Det är e-postmeddelandets "riktiga" datum, det som återspeglar när meddelandet skrevs och skickades.

Men det finns ett annat mekanisn: INTERNALDATE i IMAP. Det är en metadata lagrad på servern som anger när meddelandet lades in i postlådan. Och det är här det blir intressant.

När ett migreringsverktyg flyttar ett e-postmeddelande från en Google Workspace-tenant till en annan sker det via IMAP (även om båda servrarna är hos Google). Meddelandet läses från källan och infogas sedan i destinationen. Vid den infogningen lägger destinationsservern automatiskt till ett Received:-huvud med tidsstämpeln för åtgärden, alltså migreringsdatumet.

E-postklienter som Outlook använder det översta Received:-huvudet i kedjan för att visa ett meddelandets datum, inte nödvändigtvis det ursprungliga Date:-fältet. Resultatet: alla e-postmeddelanden visar datumet för migreringsdagen.

Vilka verktyg utlöser problemet

Praktiskt taget alla verktyg som används för GWS-till-GWS-migreringar berörs. Inga kända undantag:

• GSMMO (Google Workspace Migration for Microsoft Outlook): ursprungligen avsett för migrering från Exchange, men används i vissa GWS-till-GWS-flöden.
• CloudM Migrate: mycket vanligt hos MSP:er för Google-till-Google-migreringar, lägger systematiskt till ett Received:-huvud vid migrering. Se den detaljerade analysen av CloudM.
• BitTitan MigrationWiz: samma beteende, se artikeln om BitTitan.
• imapsync: det öppna källkodsverktyget för att scrippa IMAP-migreringar, inklusive mellan två Google-tenanter.
• Manuella exporter/importer via Takeout + IMAP-reimport: mindre vanliga, men ger exakt samma effekt.

Anledningen är enkel: alla dessa verktyg fungerar som vanliga IMAP-klienter. De har inte tillgång till någon "native" Google-väg som skulle bevara metadata. Även om båda tenanterna är hos Google sker överföringen via IMAP-lagret, och det lagret vet inte om att det pratar med sig självt.

Received-huvudenas mekanik i detalj

(Förresten, om du någonsin försökt läsa råa e-posthuvuden i Gmail eller Outlook vet du att det sällan är njutningsläsning. Men det är där hela sanningen döljer sig.)

Ett e-postmeddelande som färdats normalt innehåller en kedja av Received:-huvuden i omvänd ordning mot resan: den sista servern som rörde meddelandet hamnar överst. Efter en migrering hamnar migreringshuvudet alltså högst upp i stacken.

Så här ser det ut i ett meddelande migrerat via CloudM från en GWS-tenant till en annan:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.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:-fältet säger 2019. Det översta Received:-fältet säger oktober 2024. Outlook läser det översta Received:-fältet. Användaren ser oktober 2024 för ett e-postmeddelande från 2019.

Det ursprungliga Date:-fältet är intakt. Det har inte rörts. Det är den goda nyheten: informationen finns där, den väntar bara på att användas på rätt sätt.

Outlook och Gmail beter sig inte likadant

Det här är en viktig detalj. Användare som öppnar sin e-post via Gmails webbgränssnitt ser ofta rätt datum, eftersom Gmail prioriterar Date:-fältet enligt RFC 2822 vid visning. Problemet är mindre synligt på webben.

Däremot drabbas användare som konfigurerar sin Google Workspace-postlåda i Outlook via IMAP (eller via Exchange ActiveSync-synkronisering) fullt ut av fel datum, eftersom Outlook förlitar sig på INTERNALDATE i IMAP, som återspeglar datumet för det översta Received:-huvud som lades till vid migreringen.

En notering: för att vara precis varierar Outlooks beteende beroende på version och anslutningsläge. Outlook 2019 och Microsoft 365 (nyare versioner) använder INTERNALDATE vid IMAP-anslutning. Äldre versioner kan bete sig något annorlunda. Men i alla produktionsfall som observerats ger GWS-till-GWS-migrering via IMAP felaktiga datum i Outlook.

I organisationer som migrerat till en ny tenant och har hybridanvändare (vissa på Gmail-webben, andra i Outlook) blir ärendena svårtolkade. IT-teamen lägger tid på att förstå varför "vissa påverkas och andra inte", när svaret egentligen är enkelt: det är e-postklienten som avgör.

Förvärv, fusioner, domänbyten: de vanligaste fallen

Den här typen av migrering är inte ovanlig. Här är de scenarier som genererar flest ärenden:

Företagsförvärv

Ett förvärvat bolag hade sin egen Google Workspace-tenant (domän @gammaltforetag.se). Efter förvärvet ska allt migreras till moderbolagets tenant (@koncern.se). De 250 postlådorna, arkiven, 8 års e-posthistorik. BitTitan eller CloudM anlitas för operationen. Resultatet: 2,4 miljoner e-postmeddelanden med datumet för migreringhelgen.

Domänbyte

Ett omprofilerat företag byter från @gammaltnavn.se till @nyttnamn.se. Samma Google-tenant, men man skapar en ny tenant för att starta rent (ett vanligt val för att undvika konfigurationsartefakter). Postlådorna migreras via imapsync eller GSMMO. Datumen går sönder på exakt samma sätt.

Konsolidering av dotterbolag

En koncern med 4 dotterbolag, vardera på sin historiska G Suite-tenant, beslutar att samla allt i en gemensam tenant. Fyra parallella migreringar, fyra batchar med korrupta datum att hantera.

I alla tre scenarierna är problemet identiskt och lösningen densamma. Checklistan för e-postmigrering hjälper dig att förebygga den här typen av problem innan migreringen påbörjas.

Varför ett egenskrivet script inte är svaret

Att förstå problemet är en sak. Att bestämma sig för att "skriva ett Python-script som rensar huvudena" och köra det på 30 000 e-postmeddelanden i produktion är en helt annan.

Kantfall finns det gott om. Ett script som fungerar på 50 testmeddelanden i en ren miljö kommer oundvikligen att stöta på följande i en produktionspostlåda av verklig storlek:

• Meddelanden med S/MIME-signaturer eller PGP-krypterat innehåll, där en ändring av meddelandestrukturen ogiltigförklarar den kryptografiska signaturen.
• E-postmeddelanden med komplexa nästlade MIME-strukturer (multipart/alternative i ett multipart/mixed med bilagor på flera tiotals megabyte).
• Huvuden kodade med RFC 2047 (icke-ASCII-tecken), som dåligt konfigurerade parsers äter upp utan ett ljud.
• 429 Too Many Requests-fel från Google API:et klockan 02:00, mitt i en korrigeringsbatch, vilket lämnar processen i ett obestämt tillstånd.
• E-postmeddelanden där Received:-kedjan är tvetydig: flera migreringsverktyg i följd har var och en lagt till sitt huvud, och det är inte självklart vilket som ska tas bort.

Den viktigaste frågan: hur verifierar du, meddelande för meddelande, att varje korrigerat meddelande är intakt och att inget har försvunnit eller skadats? Ett egenskrivet script gör vanligtvis inte den kontrollen. Redate.io gör det automatiskt, med bevarande av originalen i en synlig säkerhetskopieringsmapp i 30 dagar.

Vad Redate.io gör med den här typen av migrering

Redate.io ansluter till destinationens Google Workspace-tenant (via domändelegering, utan manuell åtgärd postlåda för postlåda) och söker igenom e-postmeddelanden för att identifiera dem vars datummetadata är inkonsekvent med meddelandeinnehållet. Den här skanningsfasen är gratis och ger en exakt bild av problemets omfattning innan någon korrigering sker.

Den proprietära korrigeringsmotorn analyserar sedan varje meddelandets huvudkedja, tillämpar mönstermatchning mot kända signaturer från migreringsverktyg (BitTitan, CloudM, imapsync, GSMMO och andra mindre vanliga), och utför en riktad metadatakorrigering utan att ändra meddelandets innehåll. Varje korrigerat e-postmeddelande verifieras individuellt. Originalen bevaras.

För GWS-till-GWS-migreringar specifikt hanterar pipeline:n fall där flera migreringsomgångar har skett (till exempel en postlåda som migrerades en första gång 2021 och sedan igen 2024), med flera lager av störande huvuden att reda ut.

Specifika korrigueringsguider för CloudM till Google Workspace och BitTitan till Google Workspace beskriver anslutningsstegen för den här typen av konfiguration.

Upptäck problemet innan användarna klagar

Det bästa tillfället att upptäcka korrupta datum är direkt efter migreringen, innan go-live. En snabb kontroll på några pilotpostlådor via en IMAP-klient som Thunderbird låter dig jämföra datumvisningen med det förväntade resultatet. Om alla importerade e-postmeddelanden verkar ha samma aktuella datum är det det karakteristiska tecknet på problemet.

Men i praktiken upptäcks problemet ofta flera veckor efter migreringen, när en användare letar efter ett gammalt kontrakt och inser att Gmail-postlådan är perfekt sorterad... efter migreringsdatum. Tusentals e-postmeddelanden staplade med samma tidsstämpel. Sökning efter datum fungerar inte längre. Konversationstrådar är i oordning. Historiken verkar ha försvunnit.

För MSP:er som regelbundet hanterar GWS-till-GWS-migreringar är det smart att lägga in en Redate.io-skanning i checklistan efter migrering (innan kundvalidering) för att undvika den här typen av överraskning.

Har du precis migrerat mellan två Google Workspace-tenanter och e-postdatumen är felaktiga? Starta en gratis skanning på Redate.io för att mäta problemets omfattning innan någon korrigering görs.