Datoproblemet etter Google Workspace-migrering
Organisasjoner som migrerer til Google Workspace gjoer ofte en ubehagelig oppdagelse: alle e-poster i alle postkasser viser feil dato. I stedet for den opprinnelige sende- eller mottaksdatoen viser hver melding datoen da migreringen ble utfoert. Det spiller ingen rolle om organisasjonen migrerte fra Microsoft Exchange, Office 365, Zimbra, Lotus Notes eller en annen IMAP-server. Tusenvis av e-poster, alle stemplet med en og samme dato.
Og dette er ikke spesifikt for et bestemt migreringsverktoy. Problemet oppstaar med BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync, og alle andre verktoy som setter inn e-poster i Google Workspace via IMAP eller Gmail API. Aarsaken er knyttet til en fundamental mekanisme i hvordan e-postservere behandler meldinger.
For en spesifikk guide til GSMMO-verktoeyet (Google Workspace Migration for Microsoft Outlook), se den dedikerte GSMMO-artikkelen.
Vanlige migreringsveier til Google Workspace
Fra Microsoft Exchange (on-premises)
Organisasjoner som driver Exchange-servere paa stedet (2010, 2013, 2016 eller 2019) migrerer til Google Workspace for aa redusere infrastrukturkostnader og ta i bruk en skymodell. Disse migreringene bruker vanligvis CloudM, BitTitan MigrationWiz eller GSMMO. Migreringsverktoeyet kobler til Exchange, laster ned hver e-post og laster den opp til brukerens Google Workspace-postkasse. Hver opplastet e-post faar en ny "Received"-header med migreringstidsstempelet.
Fra Microsoft 365 (Office 365)
Migreringer fra Microsoft 365 til Google Workspace er vanlige naar organisasjoner bytter oekosystem. BitTitan MigrationWiz og CloudM er de mest populaere verktoyene for denne typen migrering. Prosessen henter e-poster fra Exchange Online og setter dem inn i Google Workspace. Det samme "Received"-headerproblemet gjelder: hver migrert e-post viser migreringsdatoen.
Fra andre IMAP-servere
Migreringer fra Zimbra, Zoho, cPanel-hosting, Dovecot, Courier og andre IMAP-servere til Google Workspace bruker verktoy som imapsync, CloudM eller egendefinerte skript. Destinasjonen (Google Workspace) legger til en "Received"-header under innsettingsoperasjonen, uavhengig av kildeplattformen. Selv migreringer fra en annen Google Workspace-tenant produserer det samme problemet.
Hvorfor datoer blir feil i Google Workspace
Gmail-webgrensesnittet vs. IMAP-klienter
Google Workspace presenterer en saeregen situasjon. Gmails webgrensesnitt bruker vanligvis e-postens "Date"-header for aa vise meldingsdatoen, noe som betyr at e-poster ofte vises med riktig dato naar de sees via webgrensesnittet. Derimot, naar den samme postkassen aksesseres via en IMAP-klient (Outlook, Apple Mail, Thunderbird), leser klienten den nyeste "Received"-headeren og viser migreringsdatoen.
Denne forskjellen skaper betydelig forvirring. En administrator som tester migreringen i Gmails webgrensesnitt ser korrekte datoer og konkluderer med at migreringen var vellykket. Men naar brukerne kobler Outlook til Google Workspace-kontoen sin, rapporterer de at hver e-post har feil dato. Problemet eksisterer paa serveren (headerne inneholder migreringstidsstempelet) men blir bare synlig i enkelte klienter. Hvor mange administratorer har avsluttet et migreringsprosjekt i troen paa at alt var bra, bare for aa bli oversvoemmet med saker mandagen etter?
IMAP INTERNALDATE-faktoren
Google Workspace lagrer en INTERNALDATE for hver e-post, satt under innsettingsprosessen. Noen migreringsverktoy setter denne verdien korrekt til den opprinnelige datoen, andre lar den staa til migreringsdatoen. Men selv naar INTERNALDATE er korrekt, viser IMAP-klienter som prioriterer "Received"-headere (som Outlook) likevel feil dato. Fullstendig korreksjon krever baade fjerning av migrerings-"Received"-headeren og verifisering av at INTERNALDATE er korrekt satt. For en detaljert teknisk forklaring, se hvorfor e-poster viser feil dato etter IMAP-migrering.
Google Workspace-administratoralternativer (som ikke fungerer)
Google administrasjonskonsoll
Google administrasjonskonsollen tilbyr omfattende kontroller for Google Workspace-administrasjon, men den inkluderer ingen funksjonalitet for aa korrigere e-postdatoer etter migrering. Ingen masseredigering av headere. Intet datokorreksonsverktoy. Ingen maate aa endre INTERNALDATE paa eksisterende e-poster via administrasjonsgrensesnittet.
Google Apps Script
Google Apps Script kan automatisere mange Gmail-operasjoner, men det kan ikke endre raa e-postheadere. GmailApp- og Gmail API-tjenestene eksponert via Apps Script gir mulighet til aa lese meldinger, endre etiketter og modifisere metadata, men de stoetter ikke erstatning av raa RFC 2822-innhold i en melding. Korreksjonen krever arbeid paa et langt dypere nivaa enn det Apps Script eksponerer.
Googles datamigrasjonstjeneste
Googles datamigrasjonstjeneste (tilgjengelig i administrasjonskonsollen) er designet for aa migrere e-poster til Google Workspace, ikke for aa korrigere headere etter migrering. Aa kjoere en ny migrering med dette verktoeyet ville legge til ytterligere en "Received"-header, noe som forverrer problemet.
Korrigere Google Workspace-datoer med Redate.io
Hvordan admindelegering fungerer
Redate.io bruker Google Workspaces domeneomfattende delegeringsfunksjon for aa faa tilgang til postkasser. Administratoren oppretter en Service Account i Google Cloud Console, tildeler de noedvendige Gmail API-omfangene og aktiverer domeneomfattende delegering. Dette gir Redate.io muligheten til aa behandle enhver postkasse i organisasjonen uten aa kreve individuelle brukerlegitimasjoner.
Delegeringsoppsettet tar omtrent 10 minutter og foelger den samme prosessen som andre Google Workspace-migrerings- og administrasjonsverktoy. Naar det er konfigurert, kan administratoren analysere og korrigere et vilkaarlig antall postkasser fra Redate.io-dashboardet.
Kom i gang
Opprette en Service Account. I Google Cloud Console oppretter du et nytt prosjekt (eller bruker et eksisterende), aktiverer Gmail API og oppretter en Service Account med domeneomfattende delegering aktivert.
Tildele API-omfang. I Google Workspace administrasjonskonsollen navigerer du til Sikkerhet, deretter API-kontroller, deretter Domeneomfattende delegering. Legg til Service Accountens klient-ID og tildel Gmail API-omfangene som kreves av Redate.io.
Koble til i Redate.io. Logg inn paa Redate.io, velg "Google Workspace" som plattform og last opp Service Accountens JSON-noekkellfil. Redate.io validerer tilkoblingen og lister tilgjengelige postkasser.
Analyser postkassene. Velg postkassene som skal analyseres (eller analyser alle). Den gratis analysen identifiserer antall e-poster med feil datoer i hver postkasse. Ingen betaling kreves for analysen.
Korriger. Gjennomgaa analyseresultatene, velg en plan og start korreksjonen. Redate.ios proprietaere korreksjonsmotor behandler hver postkasse ved aa sende hver e-post gjennom en flertrinns analysepipeline som haandterer kodingsproblemer, multipart-meldingsstrukturer, digitale signaturer og dusinvis av spesialtilfeller som et hjemmelaget skript ville korruptert. Fremdriften er synlig i sanntid. Opprinnelige meldinger bevares i en "Redate.io - Originals"-etikett i 30 dager.
Etter korreksjonen
Naar korreksjonen er fullfoert av Redate.io, viser e-postene riktig dato i alle klienter: Gmail web, Outlook, Apple Mail, Thunderbird og enhver annen IMAP-tilkoblet applikasjon. Korreksjonen er permanent. Ingen loeprende vedlikehold eller abonnement er noedvendig. Brukere kan sortere etter dato, soeke etter datointervall og bruke samsvarsverktoy med tillit til tidsstemplenes noeyaktighet. Postkassen fungerer slik den burde ha fungert fra dag en.
Verktoyspesifikke guider for Google Workspace
For detaljerte instruksjoner basert paa det spesifikke migreringsverktoeyet som ble brukt, se disse guidene:
- Fikse BitTitan MigrationWiz-datoer i Google Workspace
- Fikse CloudM-migreringsdatoer i Google Workspace
Migrering til Google Workspace og alle e-poster viser feil dato? Kjoer en gratis analyse med Redate.io for aa se hvor mange e-poster som er berort i alle postkasser, og gjenopprett korrekte datoer.