Google Workspace naar GWS migratie: datums kapot

Het scenario dat niemand verwacht

U heeft zojuist de migratie afgerond van een Google Workspace-tenant naar een andere. Een overname, een naamswijziging, de samenvoeging van twee entiteiten die al jaren op aparte G Suite-accounts werkten. De operatie verliep vlot, de mailboxen staan klaar, gebruikers kunnen inloggen. Maandagochtend, eerste ticket: "Al mijn e-mails hebben dezelfde datum." Dan een tweede. Dan tien.

Instinctief denkt u: dit is vast een IMAP-probleem, een verkeerd geconfigureerde tool, iets uitzonderlijks. Geen Google naar Google-migratie. Toch is dat precies waar het misgaat.

Dit scenario is waarschijnlijk het slechtst gedocumenteerde in de sector. De meeste IT-beheerders die het tegenkomen zoeken urenlang naar een verklaring aan de kant van de mailclient, in Outlook, in accountinstellingen, voor ze beseffen dat het probleem in de e-mailheaders zelf zit.

Waarom een Google-naar-Google-migratie datums kapotmaakt

Om te begrijpen wat er gebeurt, moet u terug naar de mechaniek van e-mailheaders. Elk RFC 2822-bericht bevat een origineel Date:-veld, geplaatst door de verzendende client of server op het moment van verzending. Dat is de "echte" datum van de e-mail, die overeenkomt met wanneer het bericht is opgesteld en verstuurd.

Maar er is nog een ander mechanisme: de INTERNALDATE in IMAP. Dat is een metadata die server-side wordt opgeslagen en aangeeft wanneer het bericht in de mailbox is geplaatst. En daar wordt het interessant.

Wanneer een migratietool een e-mail van de ene Google Workspace-tenant naar de andere overzet, verloopt dat via het IMAP-protocol (ook al zitten beide servers bij Google). Het bericht wordt van de bron gelezen en opnieuw in de bestemming ingevoegd. Op het moment van die herplaatsing voegt de doelserver automatisch een Received:-header toe met het tijdstip van de operatie, de migratiedatum dus.

Mailclients zoals Outlook gebruiken de eerste Received: uit de keten om de datum van een bericht te tonen, niet noodzakelijk het originele Date:-veld. Resultaat: alle e-mails tonen de datum van de migratiedag.

Welke tools het probleem veroorzaken

Vrijwel alle tools die worden gebruikt voor inter-tenant Google Workspace-migraties zijn getroffen. Geen noemenswaardige uitzondering:

• GSMMO (Google Workspace Migration for Microsoft Outlook): oorspronkelijk ontworpen voor migratie vanuit Exchange, maar ook gebruikt in bepaalde GWS-naar-GWS-stromen.
• CloudM Migrate: veelgebruikt bij MSPs voor inter-Google-migraties, voegt systematisch een migratie-Received:-header toe. Zie de gedetailleerde analyse van CloudM.
• BitTitan MigrationWiz: idem, het gedrag wordt besproken in dit artikel over BitTitan.
• imapsync: de open-source tool waarmee IMAP-migraties te scripten zijn, ook tussen twee Google-tenants.
• Handmatige exports/imports via Takeout + herimporten via IMAP: minder gebruikelijk, maar produceren exact hetzelfde effect.

De reden is simpel: al deze tools werken als standaard IMAP-clients. Ze hebben geen toegang tot een "native" Google-pad dat metadata zou bewaren. Ook al zitten beide tenants bij Google, de overdracht verloopt via de IMAP-laag, en die laag weet niet dat hij met zichzelf praat.

De mechaniek van Received-headers in detail

(Als u ooit de ruwe headers van een e-mail heeft geprobeerd te lezen vanuit Gmail of Outlook, weet u dat dat zelden plezierlijk leeswerk is. Maar daar zit de hele waarheid verborgen.)

Een e-mail die normaal heeft gereisd bevat een keten van Received:-headers in omgekeerde volgorde van de route: de laatste server die het bericht heeft aangeraakt staat bovenaan. Na een migratie staat de migratieheader dus helemaal bovenaan de stapel.

Zo ziet dat eruit in een bericht dat via CloudM werd gemigreerd van de ene GWS-tenant naar de andere:

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

Het Date:-veld zegt 2019. De eerste Received: zegt oktober 2024. Outlook leest de eerste Received:. De gebruiker ziet oktober 2024 voor een e-mail uit 2019.

Het originele Date:-veld is intact. Het heeft zich niet verplaatst. Dat is het goede nieuws: de data is er, die wacht alleen op correcte verwerking.

Outlook en Gmail gedragen zich anders

Dit is een belangrijke nuance. Gebruikers die hun e-mails via de Gmail-webinterface bekijken, zien vaak de juiste datums, omdat Gmail bij voorkeur het RFC 2822 Date:-veld gebruikt om berichten te tonen. Het probleem is minder zichtbaar via het web.

Gebruikers die hun Google Workspace-mailbox configureren in Outlook via IMAP (of via Exchange ActiveSync-synchronisatie) worden echter vol geraakt door de verkeerde datum, omdat Outlook vertrouwt op de IMAP INTERNALDATE, die de datum van de eerste Received:-header uit de migratie weerspiegelt.

Correctie: om precies te zijn varieert het gedrag van Outlook per versie en verbindingsmodus. Outlook 2019 en Microsoft 365 (recente versies) gebruiken de INTERNALDATE bij een IMAP-verbinding. Oudere versies kunnen licht afwijkend gedrag vertonen. Maar in alle gevallen die in productie zijn waargenomen, produceert een GWS-naar-GWS-migratie via IMAP verkeerde datums in Outlook.

In organisaties die naar een nieuwe tenant zijn gemigreerd en hybride gebruikers hebben (sommigen op Gmail web, anderen op Outlook) zijn de binnenkomende tickets daardoor tegenstrijdig. IT-teams besteden tijd aan de vraag waarom "sommigen getroffen zijn en anderen niet", terwijl het antwoord simpelweg is: het is de mailclient die het verschil maakt.

Overnames, fusies, domeinwijzigingen: de meest voorkomende situaties

Dit type migratie is niet uitzonderlijk. Dit zijn de scenario's die de meeste tickets genereren:

Overname van een bedrijf

Een overgenomen bedrijf had zijn eigen Google Workspace-tenant (domein @oudebedrijfsnaam.com). Na de overname moet alles migreren naar de tenant van de moedermaatschappij (@groep.com). De 250 mailboxen, de archieven, de 8 jaar e-mailgeschiedenis. BitTitan of CloudM wordt ingeschakeld voor de operatie. Resultaat: 2,4 miljoen e-mails met de datum van het migratieweekend.

Domeinwijziging

Een bedrijf dat rebrandt gaat van @oudnaam.nl naar @nieuwenaam.nl. Zelfde Google-tenant, maar aanmaak van een nieuwe tenant om schoon te beginnen (een gebruikelijke keuze om configuratie-artefacten te vermijden). Migratie van mailboxen via imapsync of GSMMO. De datums breken op precies dezelfde manier.

Consolidatie van dochterondernemingen

Een groep met 4 dochterondernemingen, elk op hun eigen historische G Suite-tenant, die besluit alles samen te brengen op één tenant. Vier migraties tegelijkertijd, vier batches e-mails met beschadigde datums om te verwerken.

In deze drie scenario's is het probleem identiek en de oplossing dezelfde. De checklist voor e-mailmigratie helpt dit soort problemen te anticiperen voor u de migratie start.

Waarom een zelfgemaakt script geen oplossing is

Het probleem begrijpen is één ding. Vervolgens denken "ik schrijf wel een Python-script dat de headers opruimt" en dat toepassen op 30.000 productie-e-mails, dat is iets heel anders.

Randgevallen zijn er in overvloed. Een script dat werkt op 50 teste-mails in een schone omgeving zal in een productie-mailbox van echte omvang onvermijdelijk stuiten op:

• Berichten met S/MIME-handtekeningen of PGP-versleutelde inhoud, waarbij elke wijziging in de berichtstructuur de cryptografische handtekening ongeldig maakt.
• E-mails met complexe geneste MIME-structuren (multipart/alternative in een multipart/mixed met bijlagen van tientallen megabytes).
• Headers gecodeerd in RFC 2047 (niet-ASCII-tekens), die slecht geconfigureerde parsers stilletjes verwerken.
• 429 Too Many Requests-fouten van de Google API om 2 uur 's nachts, midden in een correctiebatch, waardoor het proces in een onbepaalde toestand achterblijft.
• E-mails waarbij de Received:-keten ambigu is: meerdere opeenvolgende migratietools hebben elk hun eigen header toegevoegd, en het is niet triviaal om te bepalen welke er moet worden aangepakt.

En de belangrijkste vraag: hoe verifieert u, e-mail voor e-mail, dat elk gecorrigeerd bericht intact is en dat er niets verloren of beschadigd is gegaan? Een zelfgemaakt script doet deze verificatie doorgaans niet. Redate.io doet dat automatisch, met behoud van de originelen in een zichtbare back-upmap gedurende 30 dagen.

Wat Redate.io doet bij dit type migratie

Redate.io maakt verbinding met de Google Workspace-doeltenant (via domeindelegatie, zonder handmatige interventie per mailbox) en scant e-mails om berichten te identificeren waarvan de datumsmetadata niet consistent is met de berichtinhoud. Deze scanfase is gratis en geeft een exact beeld van de omvang van het probleem voor er enige correctie plaatsvindt.

De eigen correctie-engine analyseert vervolgens de headerketen van elk bericht, past patroonherkenning toe op bekende signaturen van migratietools (BitTitan, CloudM, imapsync, GSMMO, en minder gangbare tools), en voert een gerichte correctie van de datumsmetadata uit zonder de berichtinhoud te wijzigen. Elk gecorrigeerd e-mailbericht wordt afzonderlijk geverifieerd. De originelen worden bewaard.

Voor inter-tenant Google Workspace-migraties specifiek verwerkt de pipeline gevallen waarbij meerdere migratierondes hebben plaatsgevonden (bijvoorbeeld een mailbox die in 2021 voor het eerst en in 2024 opnieuw werd gemigreerd), met meerdere lagen parasitaire headers om uit te ontwarren.

De specifieke herstelgidsen CloudM naar Google Workspace en BitTitan naar Google Workspace beschrijven de verbindingsstappen voor dit type configuratie.

Het probleem detecteren voor gebruikers erover klagen

Het beste moment om beschadigde datums te ontdekken is direct na de migratie, voor de go-live. Een snelle controle op een paar pilootmailboxen via een IMAP-client zoals Thunderbird laat toe de datumsweergave te vergelijken met wat verwacht wordt. Als alle geïmporteerde e-mails dezelfde recente datum lijken te hebben, is dat het kenmerkende teken van het probleem.

Maar in de praktijk wordt het probleem vaak pas weken na de migratie ontdekt, wanneer een gebruiker een oud contract zoekt en merkt dat zijn Gmail-inbox perfect gesorteerd is... op migratiedatum. Duizenden e-mails op hetzelfde tijdstempel. Zoeken op datum werkt niet meer. De gespreksthreads staan door elkaar. De geschiedenis lijkt verdwenen.

Voor MSPs die regelmatig inter-tenant Google Workspace-migraties uitvoeren, voorkomt het opnemen van een Redate.io-scan in de post-migratiechecklist (voor de klantvalidatie) dit soort verrassingen. Zie ook hoe e-maildatums na migratie worden beschadigd voor meer achtergrond.

U heeft zojuist gemigreerd tussen twee Google Workspace-tenants en de datums van uw e-mails kloppen niet? Start een gratis scan op Redate.io om de omvang in kaart te brengen voor u iets corrigeert.