Genskab Outlook-profil: derfor ændres dine datoer

Fejlsøgningen der ødelægger datoerne

En bruger klager over, at Outlook ikke synkroniserer. E-mails ankommer ikke, Sendt-mappen opdateres ikke, og hjulet spinner i det uendelige. Teknikeren diagnosticerer en korrupt profil, sletter OST-filen og genskaber Outlook-profilen fra bunden. Resultatet: Outlook genopretter forbindelsen, e-mails dukker op igen, alt ser ud til at virke.

Indtil næste morgen, da brugeren åbner sin postkasse og opdager, at 8 års korrespondance viser samme dato: i dag.

Det er præcis det samme symptom som efter en mislykket IMAP-migrering. Og af de samme årsager.

Hvad der sker teknisk set

For at forstå, hvorfor genskabelse af en profil giver dette resultat, er man nødt til at kende en distinktion, som de fleste teknikere ikke kender særlig godt: forskellen på en e-mails Date:-header og dens IMAP INTERNALDATE.

Hver e-mail indeholder i sine RFC 2822-headere et Date:-felt, som angiver, hvornår beskeden blev sendt. Dette felt skrives af afsenderens e-mailklient på afsendelsestidspunktet og transporteres derefter uændret gennem alle servere frem til din postkasse. Det ændres aldrig. En e-mail sendt den 14. marts 2019 kl. 09:32 vil altid have det Date:-felt intakt, uanset hvad der sker bagefter.

IMAP INTERNALDATE er noget helt andet. Det er en metadata administreret af mailserveren, uafhængig af beskedens indhold. Den angiver, hvornår beskeden blev "afleveret" i postkassen. Under normale omstændigheder, når en e-mail ankommer via SMTP, registrerer serveren modtagelsestidspunktet som INTERNALDATE. En e-mail modtaget den 14. marts 2019 vil altså have en INTERNALDATE, der stemmer overens med afsendelsesdatoen.

Outlook sorterer og viser som standard e-mails efter den INTERNALDATE, IMAP-serveren leverer, ikke efter beskedens eget Date:-felt. (Hvis du nogensinde har åbnet en e-mails fulde egenskaber i Outlook for at se de rå headere, ved du, at det ikke er ligefrem strandlæsning.)

Hvad sletning af OST-filen udløser

Når Outlook bruger en IMAP-konto, vedligeholder det en lokal database: OST-filen (Offline Storage Table). Denne fil er et lokalt spejl af de e-mails, der er gemt på serveren, med deres metadata, læsestatus, kategorier osv.

At slette OST-filen svarer til at slette dette lokale spejl. Outlook skal altså downloade alt igen fra IMAP-serveren.

Problemet? Når Outlook gendownloader en besked via IMAP, bruger det FETCH-kommandoen til at hente indholdet. Men det bruger ikke systematisk FETCH INTERNALDATE til at hente og bevare den originale IMAP-dato. I visse konfigurationer og versioner af Outlook genopbygger klienten sit lokale indeks ved at bruge den dato, beskeden blev gendownloadet, frem for den INTERNALDATE, der er gemt på serveren.

Og så ender alle e-mails i postkassen med at have datoen for genindlæsningsdagen.

Ikke alle versioner af Outlook opfører sig ens

Faktisk rammer denne adfærd ikke alle versioner af Outlook på samme måde, og det er her, tingene bliver svære at diagnosticere.

Outlook 2016 og 2019 i IMAP-tilstand har dokumenteret adfærd med forkert indeksgenopbygning efter sletning af cache. Det nye Outlook (webbaseret, udrullet gradvist siden slutningen af 2023) håndterer cache anderledes og kan give variable resultater. Outlook via Exchange/Microsoft 365 med en konto konfigureret i Exchange-tilstand er mindre udsat for dette specifikke problem, da MAPI/Exchange-protokollen håndterer synkronisering anderledes end IMAP.

Men hvis din bruger har en IMAP-konto konfigureret i klassisk Outlook, og en tekniker har slettet OST-filen eller genskabt profilen, er risikoen reel.

Sådan skelner du dette fra en egentlig migrering

En IT-admin, der modtager tickets om "mine datoer er forkerte" efter en profilgenskabelse, kan fejlagtigt tro, det drejer sig om et migreringsproblem. Her er, hvordan du skelner de to tilfælde.

Tilfældet med IMAP-migrering

Ved en IMAP-migrering (BitTitan, CloudM, imapsync osv.) kopierer migreringsværktøjet e-mails fra en server til en anden. For hver kopieret besked oprettes en ny post på destinationsserveren via IMAP APPEND-kommandoen. Hvis værktøjet ikke eksplicit angiver den originale INTERNALDATE i denne kommando, registrerer destinationsserveren det aktuelle tidspunkt som INTERNALDATE. Desuden tilføjer visse værktøjer en Received:-header med migreringsdatoen, hvilket forværrer problemet i visse klienter. Du kan læse en detaljeret gennemgang af mekanismen i artiklen om IMAP INTERNALDATE og forkerte e-maildatoer.

Tilfældet med profilgenskabelse

Her befinder e-mails sig stadig på den samme server med de samme originale INTERNALDATE-værdier. Intet er rykket på serversiden. Det er udelukkende Outlooks lokale cache, der er blevet genopbygget med forkerte datoer. Symptomerne er identiske (alle e-mails viser den samme nylige dato), men årsagen er anderledes.

For at bekræfte: log ind på postkassen via webmail (Gmail, Outlook.com eller din udbyders webmail-interface). Hvis datoerne i webmail er korrekte, er problemet rent lokalt i Outlook. Hvis datoerne også er forkerte i webmail, er problemet på serversiden (migrering eller ændring af INTERNALDATE på selve serveren).

Hvorfor de originale datoer stadig kan genvindes

Den gode nyhed: i begge tilfælde (migrering eller profilgenskabelse) er de originale datoer ikke tabt.

RFC 2822 Date:-headeren er en integreret del af beskeden. Den er ligeså uforanderlig som brødteksten eller vedhæftede filer. En e-mail sendt i 2017 indeholder i sin rå tekst noget i stil med:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Denne linje er til stede i beskeden på serveren. Den er ikke blevet ændret. Det, Outlook viser (forkert), er metadata uden for beskedens indhold.

Det er det, der gør rettelsen mulig. Redate.io's motor analyserer header-kæden i hver enkelt besked for at udtrække den reelle originale dato og udfører derefter en målrettet metadatarettelse uden at ændre beskedens indhold. Den INTERNALDATE, Outlook ser, rekonstrueres ud fra denne autentiske information, der altid er til stede i beskeden.

Fælden ved den "rene" genskabelse

Du har netop løst et synkroniseringsproblem for en bruger. Outlook virker igen, nye e-mails ankommer. Du lukker ticketen.

Tre dage senere ringer brugeren igen: han leder efter en e-mail fra en leverandør fra sidste år, men i Outlook fremstår alle hans e-mails fra 2023 som modtaget "i går". Han finder ingenting. Den automatiske arkivering kan have sorteret nylige e-mails som gamle. Og hans chef efterlyser en e-mailkorrespondance fra september 2022 til brug i en tvist.

Dette scenarie sker med jævne mellemrum. Ikke fordi teknikeren har gjort noget forkert, men fordi denne Outlook-adfærd ikke er synligt dokumenteret i standard fejlsøgningsguider.

De falske løsninger der ikke virker

At sortere e-mails efter "Afsendelsesdato" i stedet for "Modtagelsesdato" i Outlook er det første, brugerne prøver. Og det ser ud til at virke... indtil de opdager, at sortering efter afsendelsesdato kun er tilgængelig for visse mapper, at den forsvinder, når man skifter visning, og at andre programmer (mobilapp, webmail, automatiske sorteringsregler) fortsat bruger den forkerte INTERNALDATE.

Sortering efter afsendelsesdato er ikke en løsning. Det er et plaster, der skjuler symptomet uden at røre ved det egentlige problem. Vi forklarer det i detaljer i artiklen Sortering efter afsendelsesdato er ikke en løsning.

Genskabe profilen endnu en gang? Det ændrer ingenting, hvis Outlooks adfærd er at genopbygge cachen med den aktuelle dato.

Eksportere og reimportere som PST? Vær forsigtig. En PST-eksport fra et Outlook med korrupte datoer eksporterer de korrupte metadata. PST-filen vil indeholde de forkerte datoer. At reimportere filen retter ingenting og kan endda forværre situationen ved at skabe dubletter med inkonsistente datoer. Dette emne behandles separat i artiklen om PST-import i Outlook og datoer der hopper til i dag.

Hvad Redate.io gør i dette konkrete tilfælde

Uanset om problemet stammer fra en IMAP-migrering eller en genskabelse af Outlook-profilen, er resultatet på serversiden det samme: e-mails med datometadata, der ikke stemmer overens med det faktiske indhold.

Redate.io forbinder sig direkte til postkassen (Google Workspace, Microsoft 365 eller direkte IMAP), scanner alle beskeder for at identificere dem med forkerte metadata, og anvender derefter sin flertrinspipeline til at rette hver enkelt e-mail individuelt. Hver rettelse verificeres. De originale beskeder bevares i en synlig backupmappe, indtil du selv sletter dem.

Processen håndterer de edge cases, som hjemmelavede scripts konsekvent fejler på: S/MIME-signerede beskeder, e-mails med ikke-ASCII-kodning i headere (RFC 2047), komplekse multipart-strukturer, Date:-headere med ikke-standard eller misdannede tidszoner. Et script, der fungerer korrekt på 50 test-e-mails i en udviklingspostkasse, kan uopretteligt korruptere 2.000 beskeder i produktion. Der er ingen native rollback i IMAP, når en besked er erstattet uden forudgående backup.

For tilfælde relateret specifikt til Outlook, kan du læse mere på siden Ret manuelle IMAP-kopieringsdatoer i Outlook, der beskriver, hvordan du forbinder din postkasse og starter analysen.

Forebyg problemet ved fremtidige indgreb

Hvis du er tekniker eller IT-admin og jævnligt arbejder med Outlook-profiler, er der et par gode vaner, der kan forhindre denne situation.

Inden du sletter en OST-fil eller genskaber en profil, skal du tjekke datoerne i webmail. Hvis de er korrekte, notér det i din ticket. Efter genskabelsen logger du ind i webmail igen og sammenligner de viste datoer med dem i Outlook. Hvis der er en forskel, er problemet identificeret med det samme, inden brugeren klager tre dage senere.

Ved planlagte migreringer har tjeklisten til e-mailmigrering en oversigt over de tjek, du bør lave før og efter for at opdage denne type problem, straks operationen er afsluttet.

Har du genskabt en Outlook-profil, og er alle datoer i din postkasse nu forkerte? Start en gratis scanning på Redate.io for at identificere de berørte e-mails og rette metadata uden at røre ved dine beskeder.