Gjenskape Outlook-profil: hvorfor datoer endres

Feilsøkingsgrep som ødelegger datoene

En bruker klager på at Outlook ikke lenger synkroniserer. E-poster kommer ikke inn, Sendt-mappen oppdaterer seg ikke, hjulet snurrer i det uendelige. Teknikeren diagnostiserer en korrupt profil, sletter OST-filen, gjenskaper Outlook-profilen fra scratch. Resultat: Outlook kobler til igjen, e-postene dukker opp, alt ser ut til å fungere.

Til neste morgen, når brukeren åpner postkassen og innser at 8 år med korrespondanse viser samme dato: i dag.

Dette er nøyaktig det samme symptomet som en mislykket IMAP-migrering. Og av de samme grunnene.

Det som skjer teknisk

For å forstå hvorfor det å gjenskape en profil gir dette resultatet, må vi se på en distinksjon de fleste teknikere kjenner dårlig: forskjellen mellom Date:-headeren i en e-post og dens IMAP INTERNALDATE.

Hver e-post inneholder i RFC 2822-headerne et Date:-felt som angir når meldingen ble sendt. Dette feltet skrives av avsenderens e-postklient ved sending, og transporteres uendret gjennom alle servere frem til postkassen din. Det endres aldri. En e-post sendt 14. mars 2019 kl. 09:32 vil alltid ha dette Date:-feltet intakt, uansett hva som skjer etterpå.

IMAP INTERNALDATE er noe annet. Det er en metadata administrert av e-postserveren, uavhengig av meldingsinnholdet. Den angir når meldingen ble "levert" i postkassen. Under normale forhold, når en e-post ankommer via SMTP, registrerer serveren mottakstidspunktet som INTERNALDATE. En e-post mottatt 14. mars 2019 vil altså ha en INTERNALDATE som samsvarer med sendedatoen.

Outlook sorterer og viser e-poster etter INTERNALDATE fra IMAP-serveren som standard, ikke etter meldingenes eget Date:-felt. (Forresten, hvis du noen gang har åpnet de fullstendige egenskapene til en e-post i Outlook for å se de rå headerne, vet du at det ikke akkurat er strandles­ning.)

Det OST-slettingen utløser

Når Outlook bruker en IMAP-konto, vedlikeholder den en lokal database: OST-filen (Offline Storage Table). Denne filen er et lokalt speil av e-postene lagret på serveren, med metadata, lestatus, kategorier og så videre.

Å slette OST-filen er det samme som å slette dette lokale speilet. Outlook må da laste ned alt på nytt fra IMAP-serveren.

Problemet? Når Outlook laster ned en melding via IMAP, bruker den FETCH-kommandoen for å hente innholdet. Men den bruker ikke alltid FETCH INTERNALDATE for å hente og bevare den originale IMAP-datoen. I visse konfigurasjoner og Outlook-versjoner rekonstruerer klienten sin lokale indeks ved å bruke datoen da meldingen ble lastet ned på nytt, snarere enn INTERNALDATE lagret på serveren.

Og da får alle e-postene i postkassen datoen for den dagen de ble lastet ned.

Alle Outlook-versjoner oppfører seg ikke likt

For å være presis: denne atferden rammer ikke alle Outlook-versjoner på samme måte, og det er her ting blir komplisert å diagnostisere.

Outlook 2016 og 2019 i IMAP-modus har dokumentert atferd med feil indeksrekonstruksjon etter sletting av cache. Den nye Outlook (nettbasert, gradvis utrullet siden slutten av 2023) håndterer cache på en annen måte og kan gi variable resultater. Outlook via Exchange/Microsoft 365 med en konto konfigurert i Exchange-modus er mindre utsatt for dette spesifikke problemet, fordi MAPI/Exchange-protokollen håndterer synkronisering annerledes enn IMAP.

Men hvis brukeren din er på en IMAP-konto konfigurert i klassisk Outlook, og en tekniker har slettet OST-filen eller gjenskapt profilen: risikoen er reell.

Slik skiller du dette tilfellet fra en ekte migrering

En IT-admin som mottar tickets om "datoene mine er feil" etter en profilgjenskaping, kan feilaktig tro dette er et migreringsproblem. Her er hvordan du skiller de to tilfellene.

Tilfellet med IMAP-migrering

Ved en IMAP-migrering (BitTitan, CloudM, imapsync osv.) kopierer migreringsverktøyet e-poster fra én server til en annen. For hver kopiert melding oppretter det en ny oppføring på destinasjonsserveren via IMAP APPEND-kommandoen. Hvis verktøyet ikke eksplisitt angir den opprinnelige INTERNALDATE i denne kommandoen, registrerer destinasjonsserveren gjeldende tidspunkt som INTERNALDATE. I tillegg legger noen verktøy til en Received:-header med migreringsdatoen, noe som forverrer problemet i enkelte klienter. Du kan lese detaljene om dette i artikkelen om IMAP INTERNALDATE og ødelagte datoer.

Tilfellet med profilgjenskaping

Her er e-postene fremdeles på den samme serveren, med de samme originale INTERNALDATE-verdiene. Ingenting har endret seg på serversiden. Det er kun Outlooks lokale cache som ble rekonstruert med feil datoer. Det synlige symptomet er identisk (alle e-poster viser samme nylige dato), men årsaken er en annen.

For å bekrefte: logg inn på postkassen via webmail (Gmail, Outlook.com, eller vertens webmail-grensesnitt). Hvis datoene som vises i webmail er korrekte, er problemet rent lokalt i Outlook. Hvis datoene også er feil i webmail, er problemet på serversiden (migrering eller endring av INTERNALDATE på serveren).

Hvorfor de originale datoene kan gjenopprettes

Gode nyheter: i begge tilfeller (migrering eller profilgjenskaping) er de originale datoene ikke tapt.

RFC 2822 Date:-headeren er en integrert del av meldingen. Den er like uforanderlig som brødteksten eller vedleggene. En e-post sendt i 2017 inneholder i sin råtekst noe slikt:

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

Denne linjen er til stede i meldingen lagret på serveren. Den er ikke blitt endret. Det Outlook viser (feil) er en metadata ekstern til meldingsinnholdet.

Det er dette som gjør korreksjon mulig. Redate.ios motor analyserer header-kjeden i hver melding for å trekke ut den faktiske opprinnelige datoen, og utfører deretter en målrettet metadatakorreksjon uten å endre meldingsinnholdet. INTERNALDATE som Outlook ser, rekonstrueres fra denne autentiske informasjonen som alltid er til stede i meldingen.

Fellen ved den "rene" gjenskapingen

Du har nettopp løst et synkroniseringsproblem for en bruker. Outlook fungerer igjen, nye e-poster kommer inn. Du lukker ticketen.

Tre dager senere ringer brukeren tilbake: han leter etter en e-post fra en leverandør fra i fjor, men i Outlook vises alle e-postene hans fra 2023 som mottatt "i går". Han finner ingenting. Den automatiske arkiveringen kan ha sortert nylige e-poster som om de var gamle. Og sjefen hans ber om en e-postsamtale fra september 2022 til bruk i en tvist.

Dette scenarioet skjer regelmessig. Ikke fordi teknikeren har gjort en dårlig jobb, men fordi denne Outlook-atferden ikke er godt dokumentert i standard feilsøkingsguider.

Falske løsninger som ikke hjelper

Å sortere e-poster etter "Sendedato" i stedet for "Mottaksdato" i Outlook er det første brukerne prøver. Og det ser ut til å fungere... helt til de innser at sortering etter sendedato bare er tilgjengelig for visse mapper, at den forsvinner når du bytter visning, og at andre programmer (mobil, webmail, automatiske sorteringsregler) fortsatt bruker den feil INTERNALDATE.

Sortering etter sendedato er ikke en løsning. Det er et plaster som skjuler symptomet uten å røre det reelle problemet. Vi forklarer dette i detalj i artikkelen Sortering etter sendedato løser ikke problemet.

Gjenskape profilen en gang til? Det endrer ingenting hvis Outlook rekonstruerer cachen med gjeldende dato.

Eksportere og reimportere som PST? Vær forsiktig. En PST-eksport fra en Outlook med korrupte datoer eksporterer de korrupte metadataene. PST-filen vil inneholde de feil datoene. Å reimportere den filen retter ikke noe, og kan til og med forverre situasjonen ved å opprette duplikater med inkonsekvente datoer. Dette emnet behandles separat i artikkelen om PST-import i Outlook og feil datoer.

Hva Redate.io gjør i dette tilfellet

Enten problemet stammer fra en IMAP-migrering eller en Outlook-profilgjenskaping, er resultatet på serversiden likt: e-poster der datometadataene er inkonsistente med det faktiske innholdet.

Redate.io kobler seg direkte til postkassen (Google Workspace, Microsoft 365 eller IMAP direkte), skanner alle meldinger for å identifisere de med feil metadata, og kjører deretter sin flertrinns analysepipeline for å korrigere hver enkelt e-post individuelt. Hver korreksjon verifiseres. Originalmeldingene bevares i en synlig sikkerhetskopimappe i din egen postkasse, og slettes aldri av Redate.io.

Prosessen håndterer kanttilfellene som hjemmelagde skript systematisk mislykkes på: S/MIME-signerte meldinger, e-poster med ikke-ASCII-enkodinger i headerne (RFC 2047), komplekse multipart-strukturer, Date:-headere med ikke-standard eller malformerte tidssoner. Et skript som kjører korrekt på 50 teste-poster i en utviklingspostkasse, kan uopprettelig ødelegge 2000 meldinger i produksjon. Det finnes ingen innebygd rollback i IMAP når en melding er erstattet uten forhåndssikkerhetskopi.

For tilfeller knyttet til Outlook spesifikt, detaljerer korrigeringssiden Rett manuelle IMAP-kopieringsdatoer i Outlook trinnene for å koble til postkassen og starte analysen.

Forebygge problemet ved fremtidige intervensjoner

Hvis du er tekniker eller IT-admin og jevnlig jobber med Outlook-profiler, er det noen enkle vaner som unngår denne situasjonen.

Før du sletter en OST-fil eller gjenskaper en profil, sjekk datoene som vises i webmail. Hvis de er korrekte, noter det i ticketen. Etter gjenskapingen, logg inn via webmail igjen og sammenlign datoene med det Outlook viser. Hvis det er et avvik, er problemet identifisert umiddelbart, før brukeren klager tre dager senere.

For planlagte migreringer lister sjekklisten for e-postmigrering de kontrollene du bør gjøre før og etter for å oppdage denne typen problem allerede ved avslutningen av operasjonen.

Har du gjenskapt en Outlook-profil og alle datoene i postkassen er nå feil? Start en gratis skanning på Redate.io for å identifisere berørte e-poster og korrigere metadataene uten å røre innholdet i meldingene dine.