Forkerte e-maildatoer efter migration til Exchange Online

Den klassiske mandag morgen

Du har lige afsluttet IMAP-migrationen til Exchange Online. Batchen kørte fejlfrit i Exchange Administration Center, postkasserne er synkroniserede, brugerne kan logge ind. Du lukker din computer fredag aften med fornemmelsen af et job vel udført.

Mandag morgen ruller tickets ind. "Alle mine e-mails er dateret fredag." "Min indbakkeoversigt er ubrugelig." "Der mangler gamle e-mails." Der mangler faktisk ingenting: e-mails er der alle sammen, men Outlook viser dem med migrationsdatoen i stedet for den oprindelige afsendelsesdato. En e-mail fra 2019 ser ud til at være sendt i fredags. Resultatet er, at hele indbakken ser ud til kun at indeholde nylige beskeder.

Det er et af de mest frustrerende problemer ved IMAP-migrationer til Exchange Online, og Microsoft dokumenterer det næsten aldrig ordentligt.

Hvorfor EAC-migration ødelægger datoer

Når du bruger Exchange Administration Center (EAC) til at konfigurere en IMAP-migration fra en lokal server (Dovecot, Courier, Cyrus, UW-IMAP eller lignende), forbinder Exchange Online sig til kildeserveren via IMAP, henter beskederne og injicerer dem i destinationspostkasserne via sin egen interne transportpipeline.

Det er der, problemet opstår.

Hver e-mail, der passerer gennem Exchanges transportpipeline, får automatisk et tidsstemplet Received:-header. Det er standardadfærd for SMTP- og IMAP-servere siden årtier: hver server, der rører en besked, sætter sit tidsstempel på den. Problemet er, at Outlook (og særligt Outlook til Windows i nyere versioner) bruger det nyeste Received:-header som visningsreference, når andre metadata er tvetydige.

Det originale Date:-header (det der angiver, hvornår e-mailen faktisk blev sendt, i henhold til RFC 2822) er stadig til stede i beskeden. Det er ikke blevet slettet. Men det bliver "overskygget" af det nye Received:-header, som Exchange tilføjer under injektionen.

Samtidig sættes IMAP INTERNALDATE (den metadata, som IMAP-servere bruger til at datere beskeder internt, og som styrer sorteringen i de fleste klienter) til injektionstidspunktet og ikke til e-mailens oprindelige dato. Exchange Online har ingen native måde at bevare INTERNALDATE fra kildeserveren under en batchmigration via EAC.

EAC vs. tredjepartsværktøjer: en vigtig forskel

Man skal skelne mellem to situationer. Med værktøjer som BitTitan MigrationWiz eller CloudM Migrate eksisterer problemet også, men disse værktøjer har ind imellem konfigurationsmuligheder (delvist dokumenterede, ofte gemt i avancerede indstillinger) der forsøger at bevare visse datometadata.

Den native migration via EAC tilbyder ingen sådanne muligheder. Microsoft eksponerer ikke en parameter til at styre bevarelsen af INTERNALDATE i batchmigrationspipelinen. Det er en sort boks: du konfigurerer batchen, starter den, og Exchange gør, hvad den vil internt. Og det den gør, systematisk, er at datere beskederne til injektionstidspunktet.

(Har du nogensinde prøvet at læse de rå headers på en e-mail migreret via EAC, ved du, at Received:-headeren tilføjet af Exchange er nem at genkende: den indeholder referencer til Microsofts interne servere som *.protection.outlook.com eller *.prod.exchangelabs.com, med et tidsstempel der præcist svarer til migrationsvinduet.)

Hvorfor det ikke hjælper at oprette batchen igen

Den instinktive reaktion hos mange IT-admins er: "Hvis jeg sletter de migrerede postkasser og genstarter batchen fra bunden, er datoerne måske korrekte denne gang."

Det er forståeligt. Men det virker ikke.

Problemet ligger ikke i batchkonfigurationen. Det er ikke en indstilling, du glemte at sætte. Det ligger i selve arkitekturen i Exchanges transportpipeline, som er identisk ved hver migration. En genstart af batchen giver nøjagtigt samme resultat: de samme Received:-headers med den nye migrationsdato, og de samme forkerte INTERNALDATE-værdier. Du har spildt tid, og brugerne er blevet forstyrret endnu en gang for ingenting.

Nogle admins forsøger også at ændre sorteringsindstillingerne i Outlook ("sorter efter afsendelsesdato" i stedet for "modtagelsesdato"). Det er ikke en løsning. Det er et plaster. Date:-headeren og INTERNALDATE forbliver forkerte for klienter, der ikke understøtter den indstilling, for OWA, Outlook Mobile og alle tredjepartsapplikationer, der tilgår postkassen via IMAP eller EWS.

Hvad der faktisk sker i headerne

Her er et forenklet eksempel på, hvad en e-mail indeholder efter migration via EAC. Det originale header:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@gammeltdomæne.dk
Subject: Rapport Q1 2019

Efter migration modtager beskeden øverst i headerkæden noget som dette:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook ser dette Received:-header først (det er tilføjet øverst i headerblokken), fortolker det som den seneste behandlingsdato for beskeden og viser det som modtagelsesdato. Det originale Date:-header fra 2019 er stadig der, intakt, nogle linjer længere nede. Men Outlook bruger det ikke til visningen i beskedlisten.

For at være præcis: adfærden varierer lidt afhængigt af Outlook-versionen. Versioner fra efter 2021 (og særligt den nye Outlook til Windows udrullet siden slutningen af 2023) er særligt følsomme over for dette problem, fordi de i højere grad baserer sig på Exchange Graph-metadata end på det rå Date:-header. Det betyder, at migrationer, der ikke gav synlige problemer med Outlook 2016, nu kan give problemer med den nye Outlook.

Hvem er egentlig berørt

De mest udbredte IMAP-kildeservere i denne type migration er Dovecot (meget udbredt i Linux/cPanel-miljøer) og Courier. Begge eksponerer INTERNALDATE via IMAP, som EAC ikke bevarer. Hvis du migrerer fra en on-premises Exchange-server til Exchange Online (hybrid- eller cutover-migration), er adfærden anderledes, fordi Microsoft bruger en intern transportprotokol (MAPI/EWS), der bevarer metadata bedre. Det er den generiske IMAP-migration via EAC, der er problemet.

De mest ramte brugere er dem med postkasser med lang historik (5 år og mere) og højt beskedvolumen. En bruger med 300 e-mails i indbakken klarer sig hurtigt. En salgsdirektør med 12.000 e-mails sorteret efter dato, som dagligt er afhængig af at finde frem til kundekommunikation, er derimod lammet.

Hvorfor et hjemmestrikket script er en dårlig idé her

Nogle IT-admins, der forstår det tekniske problem, fristes til at skrive et PowerShell- eller Python-script til at rette headerne manuelt. Grundkonceptet kan virke simpelt, når man først har identificeret mekanismen. Men virkeligheden ved en korrektion i produktion er en anden sag.

Først kantsagerne. S/MIME-signerede e-mails og PGP-krypterede beskeder har en struktur, der ikke tåler ændringer i headerne uden at gøre signaturen ugyldig. Multipart/alternative-beskeder med dårligt formede MIME-grænser (hyppige på gamle Courier-servere) kan blive ødelagt af et script, der ændrer beskeden uden korrekt at rekonstruere strukturen. Non-ASCII-headers kodet efter RFC 2047 (afsendernavne med betonede tegn eller japanske tegn, for eksempel) er en klassisk fejlkilde.

Dernæst volumenet. Et script, der virker på 50 test-e-mails i et udviklingsmiljø, håndterer ikke Exchange Online API's rategrænser i produktion. En 429 Too Many Requests-fejl klokken 2 om natten under en batch med 8.000 beskeder, uden genoptagelsesmekanisme, er en hvid nat og potentielt dobbeltkopier eller tabte beskeder.

Og frem for alt: hvordan verificerer man, at hver rettet e-mail er intakt? At ingen vedhæftninger er blevet afskåret, at ingen tråde er brudt, at labels og mapper er bevaret? Uden en individuel valideringsmekanisme håber man bare, at alt gik godt.

Korrektion af datoer efter migration er et problem, der ligner et script på 50 linjer, men som kræver tusindvis for at være pålideligt i produktion.

Hvad Redate.io gør anderledes

Redate.io forbinder sig til Exchange Online via Microsoft 365 API'er (Azure Active Directory, delegeringspermissioner på tenant-niveau) og scanner de berørte postkasser for at identificere e-mails, hvis datometadata er blevet ødelagt af migrationen. Dette scanningstrin er gratis og giver et præcist billede af problemets omfang: antal berørte beskeder, berørte postkasser, interval af ødelagte datoer.

Redate.io's proprietære korrektionsmotor behandler derefter hver e-mail individuelt via en multi-trins analysepipeline, der inkluderer mønstergenkendelse på signaturer fra kendte migreringsværktøjer (herunder Exchange Online-transportpipelinen), RFC-overholdelsesvalidering og kontrol af beskedernes strukturelle integritet før og efter korrektion. S/MIME-signerede e-mails, komplekse MIME-strukturer, ikke-standard-enkodninger: alle håndteres via specifikke behandlingspaths.

Hver rettet besked verificeres individuelt. Originalerne bevares i en synlig backupmappe i 30 dage. Hvis noget er galt med en bestemt besked, ændres den ikke: Redate.io rapporterer anomalien i stedet for at risikere en fejl.

Priserne er baseret på volumen, som et engangsbetaling pr. postkasse. Intet abonnement, ingen løbende gebyrer. Du retter problemet én gang, og så er det slut.

Specifikt for Exchange Online-migrationer understøtter Redate.io forbindelsen via Azure AD-applikationspermissioner (uden at skulle oprette individuelle credentials pr. postkasse), hvilket gør behandlingen af store postkasseflåder meget nemmere at orkestrere for en IT-admin eller MSP.

Hvis du administrerer flere kunder, der har gennemgået denne type migration, kan du også se den komplette guide til korrektion af datoer efter Microsoft 365-migration for et overblik over de forskellige scenarier.

E-mails er der. De originale datoer er der også. Start en gratis scanning på Redate.io for at se præcis, hvor mange beskeder der er berørt i dine Exchange Online-postkasser, inden du beslutter dig for, hvad du vil gøre.