Feil e-postdatoer etter migrering til Exchange Online

Den klassiske mandag morgen-scenarioen

Du har akkurat fullført IMAP-migreringen til Exchange Online. Batchen ble ferdig uten feil i Exchange-administrasjonssenteret, postboksene er synkronisert, brukerne kan logge inn. Du lukker PC-en fredag kveld med en god følelse av å ha gjort jobben.

Mandag morgen strømmer supporthenvendelsene inn. "Alle e-postene mine er datert til fredag." "Innboksen min er ubrukelig." "Jeg mangler gamle e-poster." Det mangler ingenting, egentlig: e-postene er der, men Outlook viser dem alle med migreringsdatoen i stedet for den opprinnelige avsenderdatoen. En e-post fra 2019 ser ut til å være sendt forrige fredag. Resultatet: hele postboksen ser ut til å inneholde bare ferske meldinger.

Dette er et av de mest frustrerende problemene ved IMAP-migrering til Exchange Online, og det er nesten systematisk underdokumentert av Microsoft.

Hvorfor migrering via EAC ødelegger datoene

Når du bruker Exchange-administrasjonssenteret (EAC) til å konfigurere en IMAP-migrering fra en lokal server (Dovecot, Courier, Cyrus, UW-IMAP eller annet), kobler Exchange Online seg til kildeserveren via IMAP, henter meldingene og injiserer dem i destinasjonspostboksene via sin egen interne transportpipeline.

Det er her problemet oppstår.

Hver e-post som passerer gjennom Exchanges transportpipeline, får automatisk en tidsstemplet Received:-header. Dette er standardatferd for SMTP- og IMAP-servere siden tidenes morgen: hver server som berører en melding, setter på sin temporale signatur. Problemet er at Outlook (særlig Outlook for Windows i nyere versjoner) bruker den nyeste Received:-headeren som visningsreferanse når andre metadata er tvetydige.

Den opprinnelige Date:-headeren (den som angir når e-posten faktisk ble sendt, i henhold til RFC 2822) er alltid til stede i meldingen. Den er ikke slettet. Men den blir "overskygget" av den nye Received:-headeren som Exchange legger til under injeksjonen.

I tillegg settes IMAP INTERNALDATE (metadataen som IMAP-servere bruker til å datere meldinger internt, og som styrer sorteringen i de fleste e-postklienter) til injeksjonsdatoen, ikke den opprinnelige datoen for e-posten. Exchange Online har ingen innebygd måte å bevare INTERNALDATE fra kildeserveren under en batch-migrering via EAC.

EAC vs. tredjepartsverktøy: en viktig forskjell

Det er viktig å skille mellom to situasjoner. Med verktøy som BitTitan MigrationWiz eller CloudM Migrate finnes problemet også, men disse verktøyene har noen ganger konfigurasjonsalternativer (delvis dokumentert, ofte gjemt i avanserte innstillinger) som forsøker å bevare visse datometadata.

Den innebygde migreringen via EAC tilbyr ingen slike alternativer. Microsoft eksponerer ingen parameter for å kontrollere INTERNALDATE-bevaring i batch-migrasjonspipelinen. Det er en svart boks: du konfigurerer batchen, starter den, og Exchange gjør som det vil internt. Og det den gjør, systematisk, er å datere meldinger til injeksjonstidspunktet.

(Hvis du noen gang har prøvd å lese råe e-postheadere fra en melding migrert via EAC, vet du at Received:-headeren Exchange legger til er lett gjenkjennelig: den inneholder referanser til Microsofts interne servere som *.protection.outlook.com eller *.prod.exchangelabs.com, med et tidsstempel som nøyaktig tilsvarer migreringsvindaet.)

Hvorfor det ikke hjelper å kjøre batchen på nytt

Den instinktive reaksjonen hos mange IT-administratorer er å tenke: "Hvis jeg sletter de migrerte postboksene og starter batchen på nytt fra scratch, kanskje datoene blir riktige denne gangen."

Det er forståelig. Men det fungerer ikke.

Problemet ligger ikke i batchkonfigurasjonen. Det handler ikke om en innstilling man glemte å krysse av. Det ligger i selve arkitekturen til Exchanges transportpipeline, som er identisk ved hver migrering. Å kjøre batchen på nytt gir nøyaktig samme resultat: de samme Received:-headerne med den nye migreringsdatoen, og de samme feilaktige INTERNALDATE-verdiene. Du har kastet bort tid, og brukerne har blitt forstyrret en gang til uten grunn.

Noen administratorer forsøker også å endre sorteringsinnstillingene i Outlook ("sorter etter avsendtdato" i stedet for "mottatt dato"). Det er ikke en løsning. Det er et plaster. Date:-headeren og INTERNALDATE forblir feil for klienter som ikke tillater denne innstillingen, for OWA, for Outlook Mobile og for alle tredjepartsapplikasjoner som får tilgang til postboksen via IMAP eller EWS.

Hva som faktisk skjer i headerne

Her er et forenklet eksempel på hva en e-post inneholder etter migrering via EAC. Den opprinnelige headeren:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@gammeltdomene.no
Subject: Rapport Q1 2019

Etter migrering får meldingen øverst i headerkjeden noe 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 denne Received:-headeren først (den er lagt til øverst i headerblokken), tolker den som den nyeste behandlingsdatoen for meldingen, og viser den som mottaksdato. Den opprinnelige Date:-headeren fra 2019 er fortsatt der, intakt, noen linjer lenger ned. Men Outlook bruker den ikke for visning i meldingslisten.

For å være presis: atferden varierer litt mellom Outlook-versjoner. Versjoner fra etter 2021 (og særlig den nye Outlook for Windows som har blitt rullet ut siden slutten av 2023) er spesielt utsatt for dette problemet fordi de i større grad støtter seg på Exchange Graph-metadata enn på den rå Date:-headeren. Det betyr at migreringer som ikke forårsaket synlige problemer med Outlook 2016, nå kan skape trøbbel med den nye Outlook.

Hvem er egentlig berørt

De vanligste IMAP-kildeserverne i denne typen migrering er Dovecot (svært utbredt i Linux/cPanel-miljøer) og Courier. Begge eksponerer INTERNALDATE via IMAP som EAC ikke bevarer. Migrerer du fra en lokal Exchange-server til Exchange Online (hybrid- eller cutover-migrering), er situasjonen annerledes fordi Microsoft da bruker en intern transportprotokoll (MAPI/EWS) som bedre bevarer metadata. Det er den generiske IMAP-migreringen via EAC som skaper problemer.

De mest berørte brukerne er de med postbokser som har lang historikk (5 år og mer) og høyt meldingsvolum. En bruker med 300 e-poster i innboksen kommer seg raskt. En salgssjef med 12 000 e-poster sortert etter dato, som daglig er avhengig av dem for å finne kundekommunikasjon, er lammet.

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

Noen IT-administratorer som forstår det tekniske problemet er fristet til å skrive et PowerShell- eller Python-skript for å korrigere headerne manuelt. Grunnkonseptet kan virke enkelt når man har identifisert mekanismen. Men realiteten ved en korreksjon i produksjon er en helt annen sak.

Først: kanttilfellene. S/MIME-signerte e-poster og PGP-krypterte meldinger har en struktur som ikke tåler headermodifikasjoner uten å ugyldiggjøre signaturen. Meldinger med multipart/alternative-struktur og feilformede MIME-grenser (vanlig på gamle Courier-servere) kan bli ødelagt av et skript som modifiserer meldingen uten å rekonstruere strukturen riktig. Ikke-ASCII-headere kodet etter RFC 2047 (avsendernavn med aksenter eller japanske tegn, for eksempel) er en klassisk feilkilde.

Så er det volumet. Et skript som fungerer på 50 test-e-poster i et utviklingsmiljø, håndterer ikke hastighetsbegrensningene til Exchange Online API i produksjon. En 429 Too Many Requests-feil klokken 02.00 under en batch med 8000 meldinger, uten gjenopprettingsmekanisme, betyr en søvnløs natt og potensielt dobbelte eller tapte meldinger.

Og viktigst av alt: hvordan verifiserer du at hver korrigert e-post er intakt? At ingen vedlegg er avkuttet, at ingen tråder er ødelagt, at mapper og etiketter er bevart? Uten en individuell valideringsmekanisme håper man bare at alt gikk bra.

Korreksjon av datoer etter migrering er et problem som ser ut som et 50-linjers skript, men som krever tusenvis av linjer for å være pålitelig i produksjon.

Hva Redate.io gjør annerledes

Redate.io kobler seg til Exchange Online via Microsoft 365 API-er (Azure Active Directory, delegeringstillatelser på tenant-nivå) og skanner de berørte postboksene for å identifisere e-poster der datometadata ble ødelagt av migreringen. Dette skannetrinnet er gratis og gir et nøyaktig bilde av problemets omfang: antall berørte meldinger, hvilke postbokser som er rammet, og hvilken datointervall som er korrumpert.

Redate.ios proprietære korreksjonsmotor behandler deretter hver e-post individuelt via en flertrinnspipeline som inkluderer mønstergjenkjenning mot signaturer fra kjente migreringverktøy (inkludert Exchange Online-transportpipelinen), RFC-samsvarvalidering og kontroll av meldingsstrukturen før og etter korreksjon. S/MIME-signerte e-poster, komplekse MIME-strukturer, ikke-standardkodinger: alle håndteres av spesifikke behandlingsstier.

Hver korrigert melding verifiseres individuelt. Originalene bevares i en synlig sikkerhetskopieringsmappe i 30 dager. Hvis noe er galt med en bestemt melding, endres den ikke: Redate.io rapporterer anomalien i stedet for å risikere korrupsjon.

Prissettingen er volumbasert, med engangsbetalng per postboks. Ingen abonnement, ingen løpende kostnader. Du fikser problemet én gang, og det er det.

For Exchange Online-migreringer spesifikt støtter Redate.io tilkobling via Azure AD-apptillatelser (uten å måtte opprette individuelle påloggingsdetaljer per postboks), noe som gjør behandling av store postboksflåter mye enklere å orkestrere for en IT-administrator eller MSP.

Administrerer du flere kunder som har gjennomgått denne typen migrering, bør du også se den komplette guiden om datokorreksjoner etter Microsoft 365-migrering for en oversikt over de ulike scenariene som dekkes.

E-postene er der, og de opprinnelige datoene likeså. Start et gratis skann på Redate.io for å se nøyaktig hvor mange meldinger som er berørt i Exchange Online-postboksene dine, før du bestemmer deg for hva du vil gjøre.