Ny Outlook: forkerte datoer efter migrering

To Outlook-versioner, to helt forskellige oplevelser

Du har netop migreret postkasser til Microsoft 365, og nu strømmer klagerne ind: alle gamle mails viser migrationsdatoen i stedet for den rigtige dato. Men her er det mærkelige: brugere på klassisk Outlook ser nogle gange den korrekte dato i læsepanelet, mens brugere på den nye Outlook til Windows konsekvent ser migrationsdatoen. Samme postkasse. Samme mails. Forskelligt resultat.

Det er ikke en fejl i traditionel forstand. Det er en arkitektonisk beslutning med direkte konsekvenser for, hvordan datoer vises efter en IMAP-migrering. For at forstå hvad der sker, skal vi ind i detaljerne om e-mailheadere og IMAP-protokollen. Det er ikke ligefrem strandlæsning, men det forklarer præcis hvorfor ingen klient-side-løsning kan rette problemet.

IMAP INTERNALDATE: den egentlige synder

Når en e-mail lagres på en IMAP-server, har den to typer datoer, der eksisterer side om side uden at forveksles.

Den første er Date:-headeren, defineret af RFC 2822. Det er den dato, der er skrevet ind i selve beskeden, altså den dato afsenderen satte da mailen blev sendt. Den er en del af beskedens indhold og ændres aldrig, uanset hvilken vej mailen rejser efterfølgende.

Den anden er INTERNALDATE, en metadata-værdi styret af IMAP-serveren og uafhængig af selve beskeden. Det er den dato, serveren registrerede beskeden. Ved en veltilrettelagt migrering bevarer seriøse værktøjer den originale INTERNALDATE. Men ved en dårligt konfigureret migrering, eller med værktøjer der ikke håndterer denne metadata korrekt, nulstilles INTERNALDATE til migrationsdagens dato. Resultatet: alle migrerede mails bærer samme modtagelsesdato set fra serverens perspektiv.

(Har du nogensinde kigget i imapsync- eller MigrationWiz-logs, ved du, at der findes specifikke flag til at forsøge at bevare INTERNALDATE. De virker ikke altid, og visse destinationsservere nægter at respektere dem.)

Klassisk Outlook: hvordan den læser datoer

Klassisk Outlook, dvs. de COM-baserede versioner installeret lokalt (Outlook 2016, 2019, 2021 og Microsoft 365 Apps-skrivebordsklienten), bruger en lidt mere kompleks mekanisme til at bestemme, hvilken dato der skal vises i beskedlisten.

For mails i Sendt-mappen trækker den på Date:-headeren. For modtagne mails bruger den primært serverens INTERNALDATE, men i visse sammenhænge (særligt når OST-cachen er involveret, eller ved første visning i læsepanelet) kan den også læse kæden af Received:-headere for at rekonstruere en omtrentlig originaldato.

Derfor opstår den inkonsistente adfærd: klassisk Outlook kan til tider vise den rigtige dato i læsepanelet, fordi den læser den originale Date:-header i beskeden ved detaljeret forhåndsvisning, selvom selve beskedlisten bruger den korrupte INTERNALDATE. Men det er ikke pålideligt, og det retter ingenting. Sorteringen er stadig i stykker, og datobaserede søgninger er stadig forkerte.

Den nye Outlook: en fundamentalt anderledes arkitektur

Den nye Outlook til Windows, som er blevet udrullet gradvist siden slutningen af 2023, er ikke længere en COM-applikation. Den er i bund og grund en Progressive Web App (PWA) bygget på samme kodebase som Outlook på web (OWA). Den ombygning har dybe konsekvenser.

Den nye Outlook delegerer al datohåndtering fuldstændigt til Microsoft 365 API'en. Den læser ikke Received:-headere, graver ikke ned i headerkæden for at finde en originaldato, og forsøger ikke på nogen måde at rekonstruere data på klientsiden. Den viser simpelthen det, serveren returnerer: INTERNALDATE.

Resultatet: er INTERNALDATE blevet korrupt under migreringen, tøver den nye Outlook ikke. Den viser migrationsdatoen for hver berørt mail, uden undtagelse. Det er en mere konsistent og forudsigelig adfærd end klassisk Outlook, men det gør migreringsproblemet øjeblikkeligt synligt og umuligt at ignorere.

En administrator, der migrerer 300 postkasser en fredag aften, opdager mandag morgen at alle brugere på den nye Outlook ser hele deres arkiv dateret til den forgangne weekend. Supportticketsne kommer hurtigt.

Hvorfor klient-side-løsninger ikke virker

Mange administratorer prøver klient-baserede løsninger, inden de indser at problemet sidder i serverdataene. Her er de klassiske forsøg, og hvorfor de fejler.

Sortering efter "Afsendelsesdato" i stedet for "Modtagelsesdato"

Sortering efter afsendelsesdato i Outlook trækker på Date:-headeren, som er intakt. Så ja, den sortering kan fungere. Men det er et plaster, ikke en løsning. Datobaserede søgninger er stadig i stykker. Regler baseret på dato virker stadig ikke. Og frem for alt: brugeren skal manuelt rekonfigurere hvert mappe, hver postkasse. På 300 postkasser er det urealistisk. Sortering efter afsendelsesdato er ikke en løsning, og slutbrugerne forstår ikke, hvorfor de skal ændre deres arbejdsvaner.

Rydde Outlook-cachen eller gendanne profilen

Det rører ikke INTERNALDATE på serveren. Efter en profilgendannelse synkroniserer Outlook e-mails på ny fra serveren og henter nøjagtigt de samme korrupte metadata. Cachen er ikke problemet.

Bruge OWA i stedet

OWA og den nye Outlook deler den samme database. Er INTERNALDATE korrupt på Exchange Online-serveren, viser OWA nøjagtigt den samme forkerte dato. At skifte klient ændrer ikke dataene.

Problemet sidder på serveren, i metadataene for hver enkelt besked. Ingen handling på klientsiden kan rette data, der er lagret på serversiden.

Received-headerfælden: hvorfor det komplicerer alt

Når et migreringsværktøj kopierer en e-mail fra en server til en anden via IMAP, tilføjer destinationsserveren automatisk en Received:-header øverst i kæden med indsætningsdato og -tidspunkt. Det er den normale adfærd for RFC-konforme SMTP- og IMAP-servere.

Disse headere ophobes i omvendt rækkefølge af den vej, e-mailen har rejst. Den nyeste er øverst. Visse e-mailklienter læser den første Received:-header for at estimere modtagelsesdatoen, hvilket giver migrationsdatoen i stedet for den originale dato.

En vigtig præcisering: denne adfærd er ikke unik for ét enkelt værktøj. BitTitan MigrationWiz, CloudM, imapsync, GSMMO og selv en manuel IMAP-kopi mellem to Thunderbird-klienter producerer alle dette resultat. Den originale Date:-header forbliver intakt i beskeden. Det er præcis det, der gør teknisk rettelse mulig. Men INTERNALDATE er en separat metadata styret af serveren og kan ikke rettes ved blot at manipulere beskedheadere på klientsiden.

Artiklen om IMAP INTERNALDATE og forkerte datoer gennemgår i detaljer, hvordan denne metadata håndteres på tværs af forskellige servere.

Hvilke migreringsværktøjer skaber dette problem på Microsoft 365

Spørgsmålet dukker hele tiden op: skaber alle migreringsværktøjer dette problem?

Det korte svar er, at det afhænger af konfigurationen og destinationsplatformen. På Exchange Online / Microsoft 365 er serveren særlig streng i sin håndtering af INTERNALDATE. Selv værktøjer, der forsøger at bevare den, fejler ind imellem, fordi Graph API og EWS (Exchange Web Services) opfører sig forskelligt afhængigt af den brugte indsætningsmetode.

BitTitan MigrationWiz er et af de mest udbredte værktøjer til migrering til Microsoft 365, og det er også et af de værktøjer, hvis dateringsproblemer er bedst dokumenteret. Siden Ret BitTitan-migreringsdatoer i Microsoft 365 dækker de specifikke konfigurationer, man skal holde øje med. CloudM og imapsync har deres egne særpræg, dokumenteret henholdsvis på Ret CloudM-migreringsdatoer i Microsoft 365 og Ret imapsync-migreringsdatoer i Microsoft 365.

Fælles for alle disse værktøjer: den originale Date:-header overlever migreringen. Det er grundlaget for, at en rettelse er mulig.

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

At forstå problemet giver nogle gange en illusion om, at løsningen er enkel. Det er den ikke, ikke i et produktionsmiljø.

At ændre metadata på e-mails lagret på Exchange Online er ikke trivielt. Microsofts Graph API pålægger strenge hastighedsgrænser (429 Too Many Requests på en natlig batch sker hurtigt). Håndtering af S/MIME-signerede eller PGP-krypterede mails kræver særlig omhu for ikke at ugyldiggøre signaturerne. Multipart-strukturer med store vedhæftede filer tilføjer begrænsninger på netværkstimeouts. Og frem for alt: hvordan verificerer man mail for mail, at rettelsen har virket uden at ændre indhold eller vedhæftede filer?

Et script, der kører fint på 50 testmails, opfører sig ikke på samme måde på en postkasse med 40.000 beskeder og 8 års historik. Sandsynligheden for at et hjørnetilfælde ødelægger noget stiger med hver yderligere tusinde beskeder. Og uden en rollback-mekanisme efterlader en fejl midt i processen postkassen i en inkonsistent tilstand.

Artiklen om e-maildatoer efter migrering til Microsoft 365 giver et samlet overblik over de tilgængelige muligheder.

Hvad Redate.io gør i praksis

Du logger ind med din egen Microsoft-konto (ingen portal, ingen app der skal registreres), og Redate.io åbner postkassen med den adgang, login'et giver. Redate.io gennemgår derefter mails med forkerte datoer gratis og anvender en proprietær korrektionsmotor på de identificerede beskeder. Den flertrinsprægede analysepipeline udfører mønstermatching på tværs af hundredvis af kendte migreringsværktøjssignaturer, RFC-overholdelsesvalidering og headerkædeanalyse for at rekonstruere de korrekte dato-metadata.

Hver rettet e-mail verificeres individuelt. De originale beskeder gemmes i en synlig backup-mappe i din egen postkasse, indtil du selv sletter dem. Prismodellen er en engangsbetaling pr. postkasse, ingen abonnement.

Den nye Outlook viser derefter de korrekte datoer, fordi serverdataene er rettet, ikke maskeret.

Har du postkasser, der er påvirket i den nye Outlook? Start en gratis scanning på Redate.io for at se præcis, hvor mange mails der er berørt, inden du beslutter dig for næste skridt.