Rett CloudM-migreringsdatoer i Microsoft 365
Hvorfor CloudM-migreringer viser forkert dato i Microsoft 365
CloudM Migrate bruges almindeligt til at migrere postkasser fra Google Workspace, on-premises Exchange og andre platforme til Microsoft 365. Når CloudM uploader e-poster til Microsoft 365, behandler Exchange Onlines transportpipeline hver melding og legger til en Received-header med det aktuelle uploadtidsstempel. Denne bliver den nyeste Received-header i meldingens header-kæde.
Microsoft 365 bruker dette leveringstidsstempel på tværs af hele sit økosystem. Outlook desktop, Outlook på nettet, Outlook mobil og endda Microsofts AI-drevne funksjoner refererer alle til den samme PR_MESSAGE_DELIVERY_TIME-egenskab, som sættes fra migrerings-Received-headeren. I modsætning til Google Workspace (hvor webklienten kan maskere problemet) viser Microsoft 365 migreringsdatoen konsekvent på tværs af alle sine klientapplikasjoner.
Konsistensen af den forkerte dato på tværs af alle Microsoft 365-klienter gør problemet umiddelbart synligt for hver bruker. Etter en CloudM-migrering til Microsoft 365 ser hele organisasjonen det samme symptom: hver e-post i hver postkasse ser ud til at være mottatt på migreringsdatoen. Der er ingen klientspecifik løsning; datokorrupsjonen er indlejret i meldingens metadata på serverniveau.
Hvordan dette påvirker Microsoft 365
Microsoft 365's ensartede datohåndtering betyder, at migreringsdatoen vises overalt samtidigt. Outlook desktop, OWA, Outlook mobil, Teams e-postintegration og Microsoft Search viser alle den forkerte mottakdato. Brukere kan ikke undgå de forkerte datoer ved at skifte til en anden Microsoft 365-applikasjon.
For Microsoft 365-administratorer strækker virkningen sig til administrasjons- og compliance-værktøjer. Exchange Admin Center, Microsoft Purview (tidligere Compliance Center) og eDiscovery Premium indekserer alle meldinger etter den beskadigede leveringsdato. Indholdssøgninger etter e-poster inden for et bestemt datointerval returnerer forkerte resultater. Opbevaringslabels der automatisk anvendes baseret på meldingens alder opererer på den forkerte tidslinje, hvilket potentielt forårsager for tidlig sletning eller ubegrænset opbevaring af meldinger der burde have været håndteret anderledes.
Ofte stilte spørsmål
Tilbyder CloudM en mulighed for at forhindre datokorrupsjon under M365-migrering?
CloudM bevarer den originale Date-header, men destinationsserveren (Exchange Online) legger til sin egen Received-header under meldingupload. Dette er serversidig adfærd som migreringsværktøjer ikke kan forhindre. Den eneste løsning er at rette datoerne etter migreringen.
Kan Microsoft 365-administrasjonsværktøjer rette datoerne?
Nej. Microsoft 365 leverer ikke indbyggede værktøjer til at endre Received-headers eller leveringstiden for eksisterende meldinger. Redate.io er designet specifikt til dette problem: det fjerner migrerings-headeren og genindsætter e-posten med den korrekte INTERNALDATE.
Er rettelsen permanent i Microsoft 365?
Ja. Når Redate.io retter e-posten, flyttes den originale melding (med den forkerte dato) til et backup-label. Den rettede melding har de korrekte Received-headers og INTERNALDATE, og Microsoft 365 indekserer den korrekte dato fremover.