GSMMO har aendret dine e-maildatoer? Saadan fikser du det

GSMMO og datoproblemet ingen advarer om

Google Workspace Migration for Microsoft Outlook (GSMMO) er det desktopvaerktoej Google tilbyder til at migrere PST-filer, Outlook-profiler og lokale e-mailarkiver til Gmail. Det er gratis, officielt understottet, og den migreringsvej Google anbefaler, naar du flytter et lille team eller enkelte postkasser fra Outlook til Google Workspace.

Vaerktojet virker. E-mails ankommer i Gmail, mappestrukturen omsaettes til labels, kontakter overfoeres. Men aabn Gmail bagefter og sorter efter dato. Hver eneste e-mail viser dagens dato. Det tilbud du sendte i januar 2021? April 2026. Fakturaen fra din revisor fra marts 2023? Ogsaa april 2026.

GSMMO advarer ikke om, at det vil ske. Migreringsloggen viser succes for hver besked. Googles egen dokumentation naevner det ikke som en kendt begraensning. Du opdager det foerst, naar nogen soeger efter en gammel e-mail efter datoraekke og faar nul resultater.

Hvordan GSMMO faktisk uploader dine e-mails

GSMMO laeser beskeder fra PST-filen (eller direkte fra Outlook-profilen) og uploader dem til Gmail via Googles IMAP-gateway. Det er her datoproblemet stammer fra, og det er vaerd at forstaa mekanikken, fordi det forklarer, hvorfor loesningen ikke er saa simpel som "importer igen".

Naar GSMMO uploader en besked, behandler Gmails IMAP-gateway den som en helt ny e-mail. Gmail stempler beskeden med en ny Received:-header der indeholder det aktuelle tidsstempel. INTERNALDATE, det tidsstempel Gmail bruger internt til sortering og visning, saettes til upload-tidspunktet i stedet for den originale afsendelsesdato.

Saadan ser headerkaeaden 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 originale Date:-header fra september 2019? Den er der stadig, uroert. GSMMO aendrer hverken beskedindholdet eller de originale headere. Men Gmail ignorerer den til visningsformaal og bruger INTERNALDATE i stedet, som nu siger april 2026.

GSMMO vs. administratorens migreringsvaerktojer

Her begynder forvirringen ofte. Google har flere migreringsvaerktojer, og de opfoerer sig ikke ens.

GSMMO (desktopappen) koerer paa brugerens maskine. Den laeser fra Outlook eller en PST-fil og sender e-mails via Googles IMAP-interface. Brugeren skal have en Google Workspace-konto og GSMMO-pluginet installeret i Outlook. Det er et klientside-vaerktoej, hvilket betyder at Googles servere ser indgaaende beskeder, ikke migrerede beskeder.

Google Workspace Migration Service (administrationskonsol-vaerktojet) er serverside. En administrator konfigurerer det i Google Admin-konsollen, peger det mod en Exchange-server eller en anden Google Workspace-tenant, og migreringen koerer i Googles infrastruktur. Dette vaerktoej haandterer datoer lidt bedre i visse konfigurationer, fordi det kan saette INTERNALDATE baseret paa kildemetadata. Men "lidt bedre" betyder ikke "paalideligt", og mange administratorer rapporterer det samme datoproblem ogsaa med dette vaerktoej.

Den afgoerende forskel? Med GSMMO er der ingen serverside-intelligens til datobevaring. IMAP-gatewayen behandler hver uploadet besked identisk, uanset om det er en frisk e-mail eller en 10 aar gammel arkiveret besked. Den stempler dagens dato. Punktum.

Hvorfor GSMMO's datobevaring ikke virker

Har du kigget paa GSMMO's indstillinger, har du maaske bemaerket, at der ikke findes en "bevar datoer"-mulighed. Det er ikke en forglemmelse. GSMMO er afhaengig af Gmails IMAP-gateway-adfaerd til datohaaandtering og kan ikke tilsidesaette den.

Den tekniske haendelseskaede:

1. GSMMO laeser beskeden fra PST-filen, inklusive de originale tidsstempler
2. GSMMO forbinder til Gmail via IMAP og sender en APPEND-kommando med beskeddata
3. Gmails IMAP-gateway modtager APPEND og behandler den gennem den interne transportpipeline
4. Transportpipelinen tilfojer en ny Received:-header med den aktuelle dato
5. Gmail saetter INTERNALDATE til upload-tidsstemplet
6. Beskeden lander i Gmail med dagens dato

Trin 3 er det afgoerende. Selv om IMAP APPEND-protokollen teknisk understotter indstilling af en brugerdefineret INTERNALDATE, respekterer Gmails implementering det ikke altid, saerligt via GSMMO-stien. Resultatet: alle dine historiske e-mails ser ud til at vaere ankommet i dag.

Nogle administratorer har proevet at koere GSMMO med specifikke Google Workspace-indstillinger eller justerede GSMMO-profilparametre. Intet af det paavirker datoadfaerden. Datoen stemples serverside, og ingen klientside-konfiguration aendrer det.

GSMMO-scenarier der oedelaegger datoer

Ikke alle GSMMO-migreringer ender i datokaos, men de fleste goer. Her er de ramte tilfaelde:

• PST-fil til Gmail: Datoer oedelaegges. Det er det mest almindelige GSMMO-brugsscenario og det mest ramte.
• Outlook-profil til Gmail: Datoer oedelaegges. Samme IMAP-gateway-adfaerd som PST-import.
• Exchange Online (Microsoft 365) til Gmail via GSMMO: Datoer oedelaegges. GSMMO laeser fra Exchange-serveren og uploader via Gmails IMAP-gateway.
• On-premises Exchange til Gmail via GSMMO: Datoer oedelaegges. Samme mekanisme.
• Gmail til Gmail (genimport af PST-eksport): Datoer oedelaegges. Selv om de originale e-mails havde korrekte datoer i PST'en, stemples de paany ved genimport.

Moentstret er klart. Enhver sti der gaar via Gmails IMAP-gateway under upload, overskriver datoerne. GSMMO bruger altid denne sti.

Det der goer det saerligt frustrerende er, at GSMMO-migreringsrapporten viser alt som succesfuldt. Ingen advarsler om datoer, ingen fejl, ingen flag. Man ville vaere noedt til manuelt at sammenligne tidsstempler foer og efter migreringen for at opdage det, og de fleste administratorer goer ikke det, foer en bruger klager.

Konsekvenserne raekker langt ud over sortering

Forkerte datoer efter en GSMMO-migrering skaber reelle problemer der gaar ud over en rodet indbakke.

Forestil dig at du er revisor og lige er migreret til Google Workspace. Du skal finde al klientkorrespondance fra Q3 2024 til en skatteindberetning. Du soeger i Gmail efter datoraekke: juli til september 2024. Nul resultater. Hver e-mail fra den periode viser nu migreringsdatoen, saa Gmails datofilter kan ikke finde dem. Du sidder fast med at scrolle gennem tusindvis af beskeder eller soege paa sogeord og haabe paa at huske de rigtige termer.

For regulerede brancher er det vaerre end irriterende. E-mailtidsstempler fungerer som juridisk bevis. En finansiel raadgiver der skal bevise at have sendt en oplysning foer en transaktionsdato, kan ikke goere det, naar e-mailen viser april 2026 i stedet for februar 2023. Compliance-audits under GDPR stoetter sig paa praecise kommunikationstidsstempler, og forkerte datoer betyder fejlede audits.

Og saa er der threadingproblemet. Gmail grupperer samtaler efter dato og emne. Naar hver besked i en traad viser samme dato, bliver samtalevisningen kaotisk. Svar vises foer den originale besked. Hele traadstrukturen kollapser til en bunke identisk daterede e-mails.

Ret GSMMO-datoer med Redate.io

Den gode nyhed: den originale Date:-header er stadig intakt i hver migreret e-mail. GSMMO aendrer ikke beskedindholdet. Den korrekte dato er der, den ignoreres bare af Gmails visningslogik fordi INTERNALDATE og den oeverste Received-header peger paa migreringsdatoen.

Redate.io forbinder til Google Workspace-postkassen, scanner for e-mails ramt af GSMMO-migreringen og retter datometadata via en proprietaer motor til headerkaedeanalyse og datorekonstruktion. Korrektionen identificerer GSMMO-specifikke moenstre i Received-headerkaeaden (signaturen gmailapi.google.com og lokale IMAP-gateway-identifikatorer) og udforer maalrettet metadatakorrektion uden at aendre beskedindhold, vedhaeftninger eller threading.

Hver korrigeret e-mail gennemgaar individuel verifikation: beskedintegritet, bevarelse af vedhaeftninger, labeltilknytning og traadkonsistens. Originaler forbliver i en synlig mappe Redate.io - Originals i 30 dage.

Kunne du fikse det selv med et script? Nu skal du hoere: at forstaa problemet er en ting. At rette 12.000 e-mails uden at brekke S/MIME-signaturer, oedelaegge indlejrede MIME-dele eller oedelaegge RFC 2047-kodede headere i en produktionspostkasse er noget helt andet. Hvordan haandterer du e-mailen med en 38 MB vedhaeftning og en beskadiget MIME-graense som GSMMO importerede men knap nok holdt sammen? Et script der virker paa 20 testbeskeder i et lab overlever ikke en rigtig postkasse med 8 aars korrespondance.

Platformspecifikke vejledninger for GSMMO

Da GSMMO migrerer specifikt til Google Workspace, sker rettelsen paa Gmail-niveau. Men de ramte e-mails er synlige i enhver klient 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

Migrerede for maaneder siden? Den originale Date-header nedbrydes ikke over tid. Redate.io kan rette GSMMO-ramte e-mails uanset om migreringen skete i sidste uge eller for tre aar siden.

GSMMO-migrering efterlod dine e-mails med forkerte datoer? Koer en gratis scanning for at se det praecise antal ramte e-mails og prisen for rettelse, foer du forpligter dig.