Felaktiga e-postdatum efter Exchange Online-migrering

Det klassiska måndagsmorgon-scenariot

Du har precis slutfört IMAP-migreringen till Exchange Online. Batchen körde klart utan fel i Exchange Admin Center, postlådorna är synkroniserade, användarna kan logga in. Du stänger datorn på fredag kväll med en känsla av att jobbet är gjort.

Måndag morgon börjar ticketsen trilla in. "Alla mina e-postmeddelanden är daterade till fredag." "Min inkorghistorik är oanvändbar." "Gamla e-postmeddelanden saknas." Ingenting saknas egentligen: e-postmeddelandena finns där, men Outlook visar dem alla med migreringsdatumet istället för det ursprungliga skickningsdatumet. Ett e-postmeddelande från 2019 visas som om det kom in i fredags. Resultatet: hela postlådan ser ut att bara innehålla nyliga meddelanden.

Det här är ett av de mest frustrerande problemen vid IMAP-migrering till Exchange Online, och det är nästan systematiskt underdokumenterat av Microsoft.

Varför EAC-migrering förstör datum

När du använder Exchange Admin Center (EAC) för att konfigurera en IMAP-migrering från en lokal server (Dovecot, Courier, Cyrus, UW-IMAP eller vad det nu är) ansluter Exchange Online till källservern via IMAP, hämtar meddelandena och injicerar dem i målpostlådorna via sin interna transportpipeline.

Det är där problemet uppstår.

Varje e-postmeddelande som passerar Exchange transportpipeline får automatiskt ett tidsstämplat Received:-huvud. Det har varit standardbeteende för SMTP- och IMAP-servrar i decennier: varje server som hanterar ett meddelande lägger till sin tidssignatur. Problemet är att Outlook (särskilt Outlook för Windows i nyare versioner) använder det senaste Received:-huvudet som visningsreferens när andra metadata är tvetydiga.

Det ursprungliga Date:-huvudet (det som anger när e-postmeddelandet faktiskt skickades, enligt RFC 2822) finns fortfarande kvar i meddelandet. Det har inte tagits bort. Men det "skuggas" av det nya Received:-huvud som Exchange lägger till vid injiceringen.

Samtidigt sätts IMAP INTERNALDATE (den metadata som IMAP-servrar använder för att datera meddelanden internt, och som styr sorteringen i de flesta e-postklienter) till injiceringsdatumet, inte till e-postmeddelandets ursprungliga datum. Exchange Online har inget inbyggt sätt att bevara källserverns INTERNALDATE vid en batch-migrering via EAC.

EAC kontra tredjepartsverktyg: en viktig skillnad

Man måste skilja på två situationer. Med verktyg som BitTitan MigrationWiz eller CloudM Migrate finns problemet också, men de verktygen har ibland konfigurationsalternativ (delvis dokumenterade, ofta gömda i avancerade inställningar) som försöker bevara vissa datummetadata.

Den inbyggda migreringen via EAC erbjuder inget sådant alternativ. Microsoft exponerar ingen inställning för att styra bevarandet av INTERNALDATE i batch-migreringspipelinen. Det är en svart låda: du konfigurerar batchen, startar den, och Exchange gör vad den vill internt. Och vad den gör, systematiskt, är att datera meddelandena med injiceringsdatumet.

(Om du någon gång har försökt läsa råhuvudena på ett e-postmeddelande migrerat via EAC vet du att Received:-huvudet som Exchange lägger till är lätt att känna igen: det innehåller referenser till Microsofts interna servrar som *.protection.outlook.com eller *.prod.exchangelabs.com, med en tidsstämpel som exakt matchar migreringsfönstret.)

Varför det inte hjälper att skapa om batchen

Den instinktiva reaktionen hos många IT-administratörer är att tänka: "Om jag tar bort de migrerade postlådorna och kör om batchen från noll, kanske datumen blir rätt den här gången."

Det är förståeligt. Men det fungerar inte.

Problemet ligger inte i batchkonfigurationen. Det är inte en inställning man glömt att bocka i. Det ligger i själva arkitekturen hos Exchange transportpipeline, som är identisk vid varje migrering. Att köra om batchen ger exakt samma resultat: samma Received:-huvuden med det nya migreringsdatumet, och samma felaktiga INTERNALDATE. Du har slösat tid och stört användarna en gång till i onödan.

Vissa administratörer försöker också ändra sorteringsinställningarna i Outlook ("sortera efter skickningsdatum" istället för "mottagningsdatum"). Det är inte en lösning. Det är ett plåster. Date:-huvudet och INTERNALDATE förblir felaktiga för klienter som inte erbjuder den inställningen, för OWA, för Outlook Mobile, och för alla tredjepartsprogram som kommer åt postlådan via IMAP eller EWS.

Vad som faktiskt händer i huvudena

Här är ett förenklat exempel på vad ett e-postmeddelande innehåller efter migrering via EAC. Det ursprungliga huvudet:

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

Efter migrering får meddelandet i toppen av huvudkedjan något i stil med:

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 detta Received:-huvud först (det läggs till högst upp i huvudblocket), tolkar det som meddelandets senaste behandlingsdatum och visar det som mottagningsdatum. Det ursprungliga Date:-huvudet från 2019 finns fortfarande kvar, intakt, några rader längre ner. Men Outlook använder det inte för att visa datum i meddelandelistan.

För att vara precis: beteendet varierar något mellan olika versioner av Outlook. Versioner från efter 2021 (och framför allt det nya Outlook för Windows som rullades ut från slutet av 2023) är särskilt känsliga för det här problemet eftersom de förlitar sig mer på Exchange Graph-metadata än på råa Date:-huvuden. Det innebär att migrationer som inte orsakade några synliga problem med Outlook 2016 nu kan orsaka problem med det nya Outlook.

Vilka drabbas egentligen

De vanligaste käll-IMAP-servrarna i den här typen av migrering är Dovecot (mycket utbrett i Linux/cPanel-miljöer) och Courier. Båda exponerar INTERNALDATE via IMAP som EAC inte bevarar. Om du migrerar från en lokal Exchange-server till Exchange Online (hybrid- eller cutover-migrering) är beteendet annorlunda, eftersom Microsoft då använder ett internt transportprotokoll (MAPI/EWS) som bättre bevarar metadata. Det är den generiska IMAP-migreringen via EAC som ställer till problem.

De mest drabbade användarna är de med postlådor som har lång historik (5 år och uppåt) och hög meddelandevolym. En användare med 300 e-postmeddelanden i inkorgen återhämtar sig snabbt. En försäljningschef med 12 000 e-postmeddelanden sorterade efter datum, som dagligen behöver hitta gamla kundkonversationer, är däremot helt handikappad.

Varför ett egenskrivet skript är en dålig idé här

Vissa IT-administratörer som förstår det tekniska problemet frestas att skriva ett PowerShell- eller Python-skript för att korrigera huvudena manuellt. Grundkonceptet kan verka enkelt när man väl har identifierat mekanismen. Men verkligheten vid en korrigering i produktion är en helt annan sak.

Börja med kantfallen. S/MIME-signerade e-postmeddelanden och PGP-krypterade meddelanden har en struktur som inte tål att huvuden ändras utan att signaturen ogiltigförklaras. Meddelanden av typen multipart/alternative med felaktigt formatterade MIME-gränser (vanligt på gamla Courier-servrar) kan skadas av ett skript som ändrar meddelandet utan att korrekt återuppbygga strukturen. Non-ASCII-huvuden kodade enligt RFC 2047 (avsändarnamn med bokstäver som å, ä, ö eller japanska tecken) är en klassisk felkälla.

Sen är det volymen. Ett skript som fungerar på 50 testmeddelanden i en utvecklingsmiljö hanterar inte Exchange Online API:s hastighetsbegränsningar i produktion. Felet 429 Too Many Requests klockan 02.00 under ett batch på 8 000 meddelanden, utan återupptagsningsmekanism, kan innebära en sömnlös natt och potentiellt dubbletter eller förlorade meddelanden.

Och framför allt: hur verifierar du att varje korrigerat e-postmeddelande är intakt? Att inga bilagor trunkerats, att inga konversationstrådar är brutna, att etiketter och mappar är bevarade? Utan en individuell valideringsmekanism hoppas man bara att allt gick bra.

Att korrigera datum efter migrering är ett problem som ser ut som ett 50-radsskript men som kräver tusentals rader för att vara tillförlitligt i produktion.

Vad Redate.io gör annorlunda

Redate.io ansluter till Exchange Online via Microsoft 365 API:er (Azure Active Directory, delegeringsbehörigheter på tenant-nivå) och skannar de berörda postlådorna för att identifiera e-postmeddelanden vars datummetadata har skadats av migreringen. Det här skanningssteget är kostnadsfritt och ger en exakt bild av problemets omfattning: antal berörda meddelanden, vilka postlådor som påverkas, vilket datumintervall som är skadat.

Redate.io:s egna korrigeringsmotor behandlar sedan varje e-postmeddelande individuellt via en pipeline med flerstegsanalys som inkluderar mönstermatchning mot hundratals kända migrationsverktygsignaturer (inklusive Exchange Online transportpipeline), RFC-efterlevnadsvalidering och kontroll av meddelandets strukturella integritet före och efter korrigering. S/MIME-signerade e-postmeddelanden, komplexa MIME-strukturer, icke-standard-kodningar: allt hanteras via specifika behandlingsvägar.

Varje korrigerat meddelande verifieras individuellt. Originalen sparas i en synlig säkerhetskopieringsmapp i 30 dagar. Om något är fel med ett specifikt meddelande ändras det inte: Redate.io rapporterar anomalin istället för att riskera en korruption.

Prissättningen är volymbaserad, med engångsbetalning per postlåda. Inget abonnemang, inga återkommande avgifter. Du åtgärdar problemet en gång, sedan är det klart.

För Exchange Online-migrationer specifikt stöder Redate.io anslutning via Azure AD-programbehörigheter (utan att behöva skapa individuella inloggningsuppgifter per postlåda), vilket gör det mycket enklare för en IT-administratör eller MSP att orkestrera behandlingen av stora postlådeflottor.

Om du hanterar flera kunder som har genomgått den här typen av migrering kan du också läsa den fullständiga guiden om datumkorrigering efter Microsoft 365-migrering för en överblick över de olika scenarier som täcks.

E-postmeddelandena finns där, och det gör de ursprungliga datumen också. Starta en kostnadsfri skanning på Redate.io för att se exakt hur många meddelanden som påverkas i dina Exchange Online-postlådor, innan du bestämmer vad du ska göra.