Ny Outlook: feil datoer etter migrering, reelle årsaker

To Outlook-versjoner, to atferdsmønstre for de samme e-postene

Du har nettopp migrert postbokser til Microsoft 365, og noen brukere klager på at alle gamle e-poster viser samme dato (migrasjonsdatoen). Kanskje har du lagt merke til noe rart: brukere på klassisk Outlook ser av og til riktig dato i leseruten, mens de som bruker ny Outlook for Windows konsekvent ser migrasjonsdatoen. Samme postboks. Samme e-poster. Ulike resultater.

Dette er ikke en feil i streng forstand. Det er en arkitekturbeslutning med direkte konsekvenser for hvordan datoer vises etter en IMAP-migrering. For å forstå hva som skjer, må du inn i detaljene om e-posthoder og IMAP-protokollen, noe som ikke akkurat er strandlesning, men som forklarer hvorfor ingen klientside-løsning er nok til å fikse problemet.

IMAP INTERNALDATE: den egentlige synderen

Når en e-post lagres på en IMAP-server, har den to typer datoer som eksisterer side om side og ikke blandes sammen.

Den første er Date:-hodet, definert av RFC 2822. Det er datoen skrevet i selve meldingen, den avsenderen satte da e-posten ble sendt. Den er en del av meldingskroppen og endres aldri, uavhengig av hvilken vei e-posten tar etterpå.

Den andre er INTERNALDATE, en metadata håndtert av IMAP-serveren, utenfor selve meldingen. Det er datoen serveren registrerte meldingen. Ved en normal migrering bevarer seriøse verktøy den originale INTERNALDATE. Men ved en feilkonfigurert migrering, eller med verktøy som ikke håndterer denne metadataen riktig, nullstilles INTERNALDATE til dagens dato under migreringen. Resultatet: alle migrerte e-poster bærer samme mottaksdato sett fra serverens side.

(Forresten, hvis du noen gang har lest loggene fra imapsync eller MigrationWiz, vet du at det finnes spesifikke valg for å forsøke å bevare INTERNALDATE. Disse fungerer ikke alltid, og noen destinasjonsservere nekter å respektere dem.)

Klassisk Outlook: slik leser den datoer

Klassisk Outlook, altså de lokalt installerte COM-versjonene (Outlook 2016, 2019, 2021 og Microsoft 365 Apps skrivebordsklienten), bruker en litt mer kompleks mekanisme for å bestemme hvilken dato som vises i meldingslisten.

For e-poster i Sendt-mappen bruker den Date:-hodet. For mottatte e-poster prioriterer den INTERNALDATE fra serveren, men i visse sammenhenger (særlig når OST-bufferen er involvert eller ved første visning i leseruten) kan den også lese kjeden av Received:-hoder for å rekonstruere en omtrentlig opprinnelsesdato.

Det er derfor man ser denne inkonsistente atferden: klassisk Outlook kan noen ganger vise riktig dato i leseruten, fordi den leser det originale Date:-hodet for detaljert forhåndsvisning, selv om selve e-postlisten bruker den korrupte INTERNALDATE. Men vær oppmerksom på at dette ikke er pålitelig og retter ingenting. Sorteringen er fortsatt ødelagt, og datobaserte søk er fortsatt feil.

Ny Outlook: en radikalt annerledes arkitektur

Ny Outlook for Windows, gradvis rullet ut siden slutten av 2023, er ikke lenger en COM-applikasjon. Det er i praksis en Progressive Web App (PWA) basert på samme kodebase som Outlook på nett (OWA). Denne ombyggingen har dyptgripende konsekvenser.

Ny Outlook delegerer all datovisning fullstendig til Microsoft 365 API-et. Den leser ikke Received:-hoder, graver ikke i hodekjeden for å finne en opprinnelsesdato, og gjør ingen forsøk på rekonstruksjon på klientsiden. Den viser rett og slett det serveren returnerer: INTERNALDATE.

Resultatet: hvis INTERNALDATE ble ødelagt under migreringen, nøler ikke ny Outlook. Den viser migrasjonsdatoen for hver berørt e-post, uten unntak, uten nyanser. Det er en mer konsistent og forutsigbar atferd enn klassisk Outlook, men den gjør migreringsproblemet umiddelbart synlig og umulig å ignorere.

En admin som migrerer 300 postbokser en fredagskveld oppdager mandag morgen at alle brukere på ny Outlook ser hele arkivet sitt datert til forrige helg. Supporthenvendelsene kommer raskt.

Hvorfor ingen klientside-løsning fungerer

Mange adminer prøver klientside-løsninger før de forstår at problemet ligger i serverdataene. Her er de vanlige forsøkene, og hvorfor de feiler.

Sortere etter "Sendedato" i stedet for "Mottaksdato"

Sortering etter sendedato i Outlook bruker meldingenes Date:-hode, som er intakt. Så ja, denne sorteringen kan fungere. Men det er et plaster, ikke en løsning. Datobaserte søk er fortsatt ødelagt. Regler basert på dato er fortsatt ubrukelige. Og viktigst av alt: brukeren må manuelt rekonfigurere hver mappe, hver postboks. Med 300 postbokser er det urealistisk. Sortering etter sendedato løser ikke problemet, og sluttbrukerne forstår ikke hvorfor de skal endre vanene sine.

Tømme Outlook-bufferen eller gjenopprette profilen

Dette berører ikke INTERNALDATE på serversiden. Etter gjenopprettelse av profilen synkroniserer Outlook e-postene på nytt fra serveren og henter nøyaktig de samme korrupte metadataene. Bufferen er ikke problemet.

Bruke OWA i stedet

OWA og ny Outlook deler samme database. Hvis INTERNALDATE er ødelagt på Exchange Online-serveren, viser OWA nøyaktig den samme feil datoen. Å bytte klient endrer ikke dataene.

Problemet ligger på serveren, i metadataene til hver enkelt melding. Ingen handling på klientsiden kan rette data som er lagret på serversiden.

Fellen med Received-hoder: hvorfor de kompliserer alt

Når et migreringsverktøy kopierer en e-post fra en server til en annen via IMAP, legger destinasjonsserveren automatisk til et Received:-hode øverst i kjeden, med dato og tidspunkt for innsettingen. Dette er normal atferd for RFC-konforme SMTP- og IMAP-servere.

Disse hodene akkumuleres i omvendt rekkefølge av e-postens reiserute. Det nyeste er øverst. Noen e-postklienter leser den første Received:-oppføringen for å estimere mottaksdatoen, noe som gir migrasjonsdatoen i stedet for den originale datoen.

Dette er ikke spesifikt for ett enkelt verktøy. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, og til og med en manuell IMAP-kopi mellom to Thunderbird-klienter gir alle dette resultatet. Det originale Date:-hodet forblir intakt i meldingen. Det er nettopp dette som gjør korreksjon teknisk mulig. Men INTERNALDATE er en separat metadata håndtert av serveren, og kan ikke rettes ved å manipulere meldingshodene på klientsiden.

For mer om denne mekanismen, se artikkelen om IMAP INTERNALDATE og ødelagte datoer, som forklarer i detalj hvordan denne metadataen håndteres på ulike servere.

Hvilke migreringsverktøy forårsaker dette problemet på Microsoft 365

Spørsmålet dukker ofte opp: forårsaker alle migreringsverktøy dette problemet?

Det korte svaret er at det avhenger av konfigurasjonen og destinasjonsplattformen. På Exchange Online / Microsoft 365 er serveren særlig streng i håndteringen av INTERNALDATE. Selv verktøy som forsøker å bevare den feiler noen ganger, fordi Graph API og EWS (Exchange Web Services) oppfører seg forskjellig avhengig av innsettingsveien som brukes.

BitTitan MigrationWiz er ett av de mest utbredte verktøyene for migrering til Microsoft 365, og også ett av dem med best dokumenterte datoproblemer. Se rett BitTitan-migreringsdatoer i Microsoft 365 for de spesifikke konfigurasjonene du bør følge med på. CloudM og imapsync har sine egne særegenheter, dokumentert på henholdsvis rett CloudM-migreringsdatoer i Microsoft 365 og rett imapsync-migreringsdatoer i Microsoft 365.

Felles for alle disse verktøyene: det originale Date:-hodet overlever migreringen. Det er grunnlaget for at korreksjon er mulig.

Hvorfor et hjemmelaget skript er en dårlig idé her

Å forstå problemet gir noen ganger illusjonen om at løsningen er enkel. Det er den ikke, ikke i produksjonsskala.

Å endre metadata på e-poster lagret på Exchange Online er ikke trivielt. Microsofts Graph API pålegger strenge ratebegrensninger (429 Too Many Requests-feilen under en nattlig batch kommer fort). Håndtering av S/MIME-signerte eller PGP-krypterte e-poster krever særlig oppmerksomhet for å ikke ugyldiggjøre signaturer. Multipart-strukturer med store vedlegg legger til begrensninger på nettverks-timeouts. Og viktigst av alt: hvordan verifiserer du, e-post for e-post, at korreksjonen faktisk fungerte uten å endre innhold eller vedlegg?

Et skript som kjører fint på 50 teste-poster oppfører seg ikke likt på en postboks med 40 000 meldinger og 8 års historikk. Sannsynligheten for at et kanttilfelle ødelegger noe øker med hvert tusen ekstra meldinger. Og uten en rollback-mekanisme etterlater en feil midt i prosessen postboksen i en inkonsistent tilstand.

Se også: rett e-postdatoer etter Microsoft 365-migrering for en fullstendig oversikt over tilgjengelige alternativer.

Hva Redate.io gjør konkret

Redate.io logger deg inn med din egen Microsoft-konto og åpner nettopp den postboksen, uten portal og uten noen applikasjon å registrere. Deretter skanner Redate.io e-poster med feil datoer gratis, og kjører en proprietær korreksjonsmotor på de identifiserte meldingene. Den flertrinns analysepipelinen utfører mønstergjenkjenning mot hundrevis av kjente migreringsverktøysignaturer, RFC-samsvarvalidering og hodekjedeanalyse for å rekonstruere korrekte datometadata.

Hver korrigert e-post verifiseres individuelt. Redate.io sletter aldri originalene. De ligger i en synlig mappe i postboksen din til du selv sletter dem. Prismodellen er en engangsbetaling per postboks, uten abonnement.

Ny Outlook viser da de riktige datoene, fordi serverdataene er rettet, ikke skjult.

Har du berørte postbokser på ny Outlook? Start en gratis skanning på Redate.io for å finne ut nøyaktig hvor mange e-poster som er berørt, før du bestemmer deg for hva du vil gjøre.