GSMMO har aendret dine e-maildatoer? Sådan fikser du det

GSMMO og datoproblemet ingen advarer om

Google Workspace Migration for Microsoft Outlook (GSMMO) er det desktopværktøj, Google tilbyder til at migrere PST-filer, Outlook-profiler og lokale e-mailarkiver til Gmail. Det er gratis, det er officielt understøttet, og det er den migreringsvej, Google anbefaler, når du flytter et lille team eller nogle enkelte postkasser fra Outlook til Google Workspace.

Værktøjet virker. E-mails ankommer i Gmail, mappestrukturen bliver til labels, kontakter kommer med. Men åbn Gmail bagefter, og sorter efter dato. Hver e-mail viser dagens dato. Det tilbud du sendte i januar 2021? April 2026. Fakturaen fra din revisor fra marts 2023? Også april 2026.

GSMMO advarer dig ikke om, at det vil ske. Migreringsloggen viser succes for hver besked. Googles egen dokumentation nævner det ikke som en kendt begrænsning. Du opdager det først, når nogen søger efter en gammel e-mail efter datoperiode og får nul resultater.

Sådan uploader GSMMO faktisk din e-mail

GSMMO læser beskeder fra PST-filen (eller direkte fra Outlook-profilen) og uploader dem til Gmail via Gmail API'en (det siger Googles egne udgivelsesnoter for værktøjet). Det er her datoproblemet stammer fra, og det er værd at forstå mekanikken, fordi det forklarer, hvorfor rettelsen ikke er så simpel som "importer bare igen".

Når GSMMO uploader en besked via Gmail API'en, tilføjer Gmail en ny Received:-header dateret til uploadtidspunktet. Og når den oprindelige dato ikke følger med beskeden, sættes INTERNALDATE, det tidsstempel Gmail bruger internt til sortering og visning, til uploadtidspunktet i stedet for den oprindelige afsendelsesdato.

Sådan ser headerkæden ud efter en GSMMO-migrering:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Ser du den oprindelige Date:-header fra september 2019? Den er der stadig, urørt. GSMMO ændrer ikke beskedens indhold eller de oprindelige headere. Men Gmail ignorerer den ved visning og bruger INTERNALDATE i stedet, som nu siger april 2026.

GSMMO vs. administratorens migreringsværktøjer

Her begynder forvirringen ofte. Google har flere migreringsværktøjer, og de opfører sig ikke ens.

GSMMO (desktopprogrammet) kører på brugerens maskine. Det læser fra Outlook eller en PST-fil og uploader e-mails via Gmail API'en. Brugeren skal have en Google Workspace-konto og GSMMO-pluginet installeret i Outlook. Det er et klientside-værktøj.

Google Workspace Migration Service (administrationskonsol-værktøjet) er serverside. En administrator konfigurerer det i Google Admin-konsollen, peger det mod en Exchange-server eller en anden Google Workspace-lejer, og migreringen kører i Googles infrastruktur. Dette værktøj håndterer datoer en smule bedre i visse konfigurationer, fordi det kan sætte INTERNALDATE baseret på kildens metadata. Men "en smule bedre" betyder ikke "pålideligt", og mange administratorer rapporterer det samme datoproblem med dette værktøj også.

Den afgørende forskel? Med GSMMO er der ingen serverside-intelligens, der tager stilling til datobevaring. Hver besked, det uploader, får samme behandling, uanset om det er en frisk e-mail eller en 10 år gammel arkiveret besked: en Received:-header dateret til uploaddagen. Punktum.

Hvorfor GSMMOs datobevaring ikke virker

Har du kigget på GSMMOs indstillinger, har du måske bemærket, at der faktisk ikke findes en "bevar datoer"-mulighed. Det er ikke en forglemmelse. GSMMO er afhængig af, hvordan Gmail behandler beskeder, der uploades via dens API, og det kan ikke ændre på det.

Her er den tekniske hændelseskæde:

1. GSMMO læser beskeden fra PST-filen, inklusive dens oprindelige tidsstempler
2. GSMMO uploader beskeddata via Gmail API'en
3. Gmail modtager uploaden og lagrer beskeden i postkassen
4. Gmail tilføjer en ny Received:-header dateret til uploadtidspunktet (linjen med gmailapi.google.com i eksemplet ovenfor)
5. Når den oprindelige dato ikke følger med, sætter Gmail INTERNALDATE til uploadtidsstemplet
6. Beskeden lander i Gmail med dagens dato

Trin 4 og 5 er de afgørende. Gmail tilføjer den header til hver besked, der uploades via dens API, uanset hvad værktøjet sender, og GSMMO har ingen indstilling til at sende eller bevare den oprindelige dato. Resultatet er, at alle dine historiske e-mails ser ud, som om de ankom i dag.

Nogle administratorer har prøvet at køre GSMMO med bestemte Google Workspace-indstillinger aktiveret eller justere GSMMO-profilindstillingerne. Ingen af disse påvirker datoadfærden. Received:-headeren tilføjes på Googles side, og ingen klientside-konfiguration ændrer det.

Specifikke GSMMO-scenarier, der giver forkerte datoer

Ikke alle GSMMO-migreringer ender i datokaos, men de fleste gør. Her er hvor det gør en forskel:

• PST-fil til Gmail: Datoerne bliver forkerte. Det er det mest almindelige GSMMO-scenarie og det mest ramte.
• Outlook-profil til Gmail: Datoerne bliver forkerte. Samme Gmail API-upload som ved PST-importen.
• Exchange Online (Microsoft 365) til Gmail via GSMMO: Datoerne bliver forkerte. GSMMO læser fra Exchange-serveren og uploader via Gmail API'en.
• Lokal Exchange til Gmail via GSMMO: Datoerne bliver forkerte. Samme mekanisme.
• Gmail til Gmail (genimport af PST-eksport): Datoerne bliver forkerte. Selv om de oprindelige e-mails havde korrekte datoer i PST-filen, stempler genimporten dem på ny.

Mønstret er klart. Hver besked, der uploades via Gmail API'en, får en Received:-header dateret til uploaddagen. GSMMO bruger altid denne vej.

Det, der gør det særligt frustrerende, er, at GSMMO-migreringsrapporten viser alt som en succes. Ingen advarsler om datoer, ingen fejl, ingen markeringer. Man skal manuelt sammenligne tidsstempler før og efter migreringen for at opdage det, og de fleste administratorer gør ikke det, før en bruger klager.

Konsekvenserne rækker langt ud over sortering

Forkerte datoer efter en GSMMO-migrering skaber reelle problemer, der går ud over en rodet postkasse.

Forestil dig, at du er revisor og lige er flyttet til Google Workspace. Du skal finde al klientkorrespondance fra Q3 2024 til en skatteindberetning. Du søger i Gmail efter en datoperiode: juli til september 2024. Nul resultater. Hver e-mail fra den periode viser nu migreringsdatoen, så Gmails datofilter kan ikke finde dem. Du sidder fast med at scrolle gennem tusinder af beskeder eller søge på nøgleord og håbe, du husker de rigtige.

For regulerede brancher er det værre end besværligt. E-mailtidsstempler fungerer som juridisk bevis. En finansiel rådgiver, der skal bevise at have sendt en oplysning før en transaktionsdato, kan ikke gøre det, når e-mailen viser april 2026 i stedet for februar 2023. Compliance-audits under SOX eller HIPAA afhænger af nøjagtige kommunikationstidsstempler, og forkerte datoer betyder fejlede audits.

Og så er der threadingproblemet. Gmail grupperer samtaler efter dato og emne. Når hver besked i en tråd viser samme dato, bliver samtalevisningen kaotisk. Svar vises før den oprindelige besked. Hele trådstrukturen kollapser til en bunke identisk daterede e-mails.

Ret GSMMO-datoer med Redate.io

Den gode nyhed: den oprindelige Date:-header er stadig intakt i hver migreret e-mail. GSMMO ændrer ikke beskedens indhold. Den korrekte dato er der, den bliver bare ignoreret af Gmails visningslogik, fordi INTERNALDATE og den øverste Received-header peger på migreringsdatoen.

Redate.io forbinder til Google Workspace-postkassen, gennemgår e-mails ramt af GSMMO-migreringen, og retter datometadataene med en egenudviklet motor til headerkædeanalyse og datorekonstruktion. Redate behøver ikke vide, hvilket værktøj der stod for migreringen: den finder de e-mails, hvis viste dato ikke stemmer med deres oprindelige dato, og retter dem uden at ændre beskedindhold, vedhæftninger eller threading.

Hver rettet e-mail gennemgår individuel verifikation: beskedintegritet, bevarelse af vedhæftninger, labeltilknytning og trådkonsistens. Originalerne forbliver i en synlig Redate.io - Originals-mappe i din egen postkasse, indtil du selv sletter dem.

Kunne du selv rette det med et script? At forstå problemet er en ting. At rette 12.000 e-mails uden at ødelægge S/MIME-signaturer, beskadige indlejrede MIME-dele eller smadre RFC 2047-kodede headere i en produktionspostkasse er noget helt andet. Hvordan håndterer du e-mailen med en vedhæftning på 38 MB og en beskadiget MIME-grænse, som GSMMO importerede, men næsten ikke kunne holde sammen? Hvordan verificerer du, at hver enkelt besked kom helskindet igennem? Et script, der virker på 20 testbeskeder i et lab, overlever ikke en rigtig postkasse med 8 års korrespondance.

Platformspecifikke vejledninger til GSMMO

Da GSMMO migrerer specifikt til Google Workspace, sker rettelsen på Gmail-niveau. Men de ramte e-mails er synlige i alle klienter, der er forbundet til den Gmail-konto:

• Ret GSMMO-migreringsdatoer i Gmail
• Ret GSMMO-migreringsdatoer i Outlook (forbundet med Google Workspace)
• Ret GSMMO-migreringsdatoer i Apple Mail

Allerede migreret for måneder siden? Den oprindelige Date-header nedbrydes ikke over tid. Redate.io kan rette GSMMO-ramte e-mails, uanset om migreringen skete for en uge siden eller tre år siden.

Har en GSMMO-migrering efterladt dine e-mails med forkerte datoer? Kør en gratis analyse for at se det nøjagtige antal ramte e-mails og prisen for at rette dem, før du forpligter dig til noget.