Rett CloudM-migreringsdatoer i Google Workspace

CloudM Migrate er et av de mest populære verktøyene for å flytte postbokser til Google Workspace, spesielt fra Exchange-miljøer. Under migreringen laster CloudM opp hver melding gjennom Gmail API. Problemet? Googles e-postinfrastruktur legger til sin egen Received-header på hver opplastede melding, stemplet med det nøyaktige øyeblikket migreringen skjedde - ikke datoen e-posten opprinnelig ble sendt eller mottatt.

Her blir det merkelig. Gmails nettgrensesnitt leser den opprinnelige Date-headeren for visningsformål, så e-poster ser helt fine ut i nettleseren. Men hver IMAP-klient - Outlook, Apple Mail, Thunderbird - leser INTERNALDATE-verdien i stedet. Den verdien gjenspeiler migreringstidsstempelet. Så du ender opp med en delt virkelighet: halvparten av brukerne rapporterer ingen problemer, mens den andre halvparten insisterer på at hver e-post viser den samme datoen.

Tenk på hva det gjør med en IT-henvendelse. Administratoren åpner Gmail i en nettleser, ser riktige datoer og lukker saken som "kan ikke gjenskape". I mellomtiden stirrer Outlook-brukeren på 47 000 e-poster som alle er datert 15. mars. Dette avviket mellom Gmail på nett og IMAP-klienter gjør CloudM-migreringsproblemet spesielt vanskelig å diagnostisere og forklare til ledelsen.

Todelt datovisning rammer hardest i organisasjoner med blandet klientbruk. Gmail på nett ser normalt ut. Outlook viser feil datoer. Apple Mail viser feil datoer. Mobilapper viser feil datoer. Bare nettgrensesnittet skjuler problemet, noe som gjør feilsøking forvirrende og tidkrevende.

Men det strekker seg lenger enn visning. Google Vault - verktøyet organisasjoner bruker for juridisk hold og eDiscovery - oppfører seg uforutsigbart med ødelagte datoer. Noen Vault-søk refererer til Date-headeren, andre bruker INTERNALDATE. En juridisk forespørsel om "alle e-poster mellom januar og mars 2024" kan gi ufullstendige resultater fordi INTERNALDATE sier at meldingene ble levert i 2025. For organisasjoner i regulerte bransjer (helse, finans, jus) er dette ikke en ulempe. Det er en risiko.

Redate.io kobler seg til Google Workspace gjennom domenedelegering og kjører sin proprietære korreksjonsmotor på berørte postbokser. Motoren utfører flertrinns headeranalyse for å identifisere CloudM-migreringssignaturer, deretter korrigerer den datometadata uten å endre selve meldingsinnholdet. Hver korrigert e-post verifiseres individuelt før originalen flyttes til en sikkerhetskopietikett.