Google Workspace -migraatio: rikkinäiset päivämäärät

Skenaario, jota kukaan ei osaa epäillä

Olet juuri siirtänyt Google Workspace -tenantin toiseen. Yritysosto, domainin vaihto, kahden vuosia erillisillä G Suite -tileillä toimineen organisaation yhdistäminen. Siirto meni hyvin, postilaatikot ovat paikallaan, käyttäjät kirjautuvat sisään. Maanantaiaamuna tulee ensimmäinen tiketti: "Kaikilla sähköposteillani on sama päivämäärä." Sitten toinen. Sitten kymmenen.

Ensireaktio on selvä: kyseessä täytyy olla IMAP-ongelma, väärin konfiguroitu työkalu, jokin eksoottinen erikoistapaus. Ei Google-to-Google-siirto. Silti juuri niin käy.

Tämä on todennäköisesti alan huonoiten dokumentoitu ongelma. Useimmat IT-ylläpitäjät, jotka törmäävät siihen, käyttävät tunteja etsien selitystä sähköpostiohjelmasta, Outlookista tai tilien asetuksista, ennen kuin ymmärtävät ongelman olevan itse sähköpostien otsikoissa.

Miksi Google-to-Google-siirto rikkoo päivämäärät

Ymmärtääksesi mitä tapahtuu, täytyy palata sähköpostiotsikoiden mekaniikkaan. Jokainen RFC 2822 -standardin mukainen viesti sisältää alkuperäisen Date:-kentän, jonka lähettävä asiakas tai palvelin on asettanut lähetyshetkellä. Se on sähköpostin "oikea" päivämäärä, joka vastaa viestin kirjoittamis- ja lähetysajankohtaa.

Mutta on olemassa toinen mekanismi: IMAP:n INTERNALDATE. Se on palvelinpuolen metatieto, joka kertoo milloin viesti on talletettu postilaatikkoon. Ja siinä kohtaa asiat muuttuvat mielenkiintoisiksi.

Kun migraatiotyökalu siirtää sähköpostin yhdestä Google Workspace -tenantista toiseen, se käyttää IMAP-protokollaa, vaikka molemmat palvelimet olisivat Googlella. Viesti luetaan lähteestä ja kirjoitetaan kohteeseen. Tässä uudelleenkirjoituksessa kohdepalvelin lisää automaattisesti Received:-otsikon, jonka aikaleima on migraatiohetki.

Outlook ja muut sähköpostiohjelmat käyttävät usein ketjun ensimmäistä Received:-otsikkoa viestin päivämäärän näyttämiseen, eivät alkuperäistä Date:-kenttää. Tulos: kaikki sähköpostit näyttävät migraatiopäivän päivämäärän.

Mitkä työkalut aiheuttavat ongelman

Käytännössä kaikki Google Workspace -tenant-siirroissa käytetyt työkalut ovat alttiita tälle. Merkittäviä poikkeuksia ei ole:

• GSMMO (Google Workspace Migration for Microsoft Outlook): alun perin suunniteltu Exchange-migraatioihin, mutta käytetään myös GWS-to-GWS-virroissa.
• CloudM Migrate: erittäin yleinen MSP:iden käytössä Google-välisiin siirtoihin, lisää aina migraatio-Received:-otsikon. Katso CloudM:n yksityiskohtainen analyysi.
• BitTitan MigrationWiz: sama ongelma, käyttäytyminen on dokumentoitu BitTitania käsittelevässä artikkelissa.
• imapsync: avoimen lähdekoodin työkalu, jolla voi skriptata IMAP-siirtoja myös kahden Google-tenantin välillä.
• Manuaaliset Takeout-viennit ja IMAP-tuonnit: harvinaisempia, mutta tuottavat täsmälleen saman lopputuloksen.

Syy on yksinkertainen: kaikki nämä työkalut toimivat tavallisina IMAP-asiakkaina. Niillä ei ole pääsyä mihinkään Googlen "natiiviin" siirtotapaan, joka säilyttäisi metatiedot. Vaikka molemmat tenantit olisivat Googlella, siirto kulkee IMAP-kerroksen kautta, eikä IMAP-kerros tiedä puhuvansa itsensä kanssa.

Received-otsikoiden mekaniikka tarkemmin

(Jos olet koskaan yrittänyt lukea sähköpostin raakaotsikkoja Gmailista tai Outlookista, tiedät että se ei varsinaisesti ole rantakirjallisuutta. Mutta sieltä löytyy koko totuus.)

Normaalisti kulkenut sähköposti sisältää Received:-otsikkoketjun käänteisessä järjestyksessä: viimeksi viestiä käsitellyt palvelin on ylimpänä. Migraation jälkeen migraatio-otsikko päätyy siis pinon kärkeen.

Näin se näyttää CloudM:n avulla yhdestä GWS-tenantista toiseen siirretyssä viestissä:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <kayttaja@uusi-domain.fi>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Date:-kenttä sanoo 2019. Ensimmäinen Received: sanoo lokakuu 2024. Outlook lukee ensimmäisen Received:-otsikon. Käyttäjä näkee lokakuun 2024 vuoden 2019 sähköpostissa.

Alkuperäinen Date:-kenttä on koskematon. Se ei ole muuttunut. Tämä on hyvä uutinen: tieto on tallessa, se vain odottaa oikeaa käyttöä.

Outlook ja Gmail käyttäytyvät eri tavalla

Tämä on tärkeä tarkennus. Käyttäjät, jotka avaavat sähköpostinsa Gmailin selainkäyttöliittymässä, näkevät usein oikeat päivämäärät, koska Gmail priorisoi RFC 2822 -standardin Date:-kenttää viestejä näyttäessään. Ongelma ei näy siellä yhtä selvästi.

Sen sijaan käyttäjät, jotka ovat konfiguroineet Google Workspace -postilaatikkonsa Outlookiin IMAP-yhteydellä (tai Exchange ActiveSync -synkronoinnilla), kärsivät väärästä päivämäärästä täysimittaisesti, koska Outlook luottaa IMAP:n INTERNALDATE-arvoon, joka heijastelee migraatiossa lisätyn ensimmäisen Received:-otsikon päivämäärää.

Oikaistaan vielä: Outlookin käyttäytyminen vaihtelee version ja yhteystavan mukaan. Outlook 2019 ja Microsoft 365 (uudet versiot) käyttävät IMAP-yhteyksillä INTERNALDATE-arvoa. Vanhemmissa versioissa saattaa olla hieman erilaisia käyttäytymismalleja. Mutta kaikissa tuotannossa havaituissa tapauksissa GWS-to-GWS-siirto IMAP:n kautta tuottaa virheellisiä päivämääriä Outlookissa.

Organisaatioissa, jotka ovat siirtyneet uuteen tenantiin ja joilla on hybridikäyttäjiä (osa käyttää Gmail-selainkäyttöliittymää, osa Outlookia), tikettejä tulee satunnaisesti ja epäjohdonmukaisesti. IT-tiimit käyttävät aikaa selvittäessään miksi "jotkut ovat kärsineet ongelmasta ja toiset eivät", vaikka vastaus on yksinkertainen: kyse on sähköpostiohjelmasta.

Yritysostot, fuusiot, domainin vaihdot: yleisimmät tilanteet

Tämä migraatiotyyppi ei ole harvinainen. Eniten tikettejä tuottavat seuraavat skenaariot:

Yritysosto

Ostetulla yrityksellä oli oma Google Workspace -tenantti (domain @vanha-yritys.fi). Oston jälkeen kaikki pitää siirtää emoyhtiön tenantiin (@konserni.fi). 250 postilaatikkoa, arkistot, 8 vuoden sähköpostihistoria. BitTitan tai CloudM hoitaa operaation. Lopputulos: 2,4 miljoonaa sähköpostia migraatioviikonlopun päivämäärällä.

Domainin vaihto

Uudelleenbrändiä tekevä yritys siirtyy osoitteesta @vanha-nimi.fi osoitteeseen @uusi-nimi.fi. Sama Google-tenantti, mutta uuden tenantin luominen puhtaalta pöydältä on yleinen valinta konfiguraatioartefaktien välttämiseksi. Postilaatikot siirretään imapsyncillä tai GSMMO:lla. Päivämäärät hajoavat täsmälleen samalla tavalla.

Tytäryhtiöiden yhdistäminen

Konsernilla on 4 tytäryhtiötä, joilla kullakin on oma historiallinen G Suite -tenanttinsa, ja ne päätetään yhdistää yhteen tenantiin. Neljä samanaikaista migraatiota, neljä erää sähköposteja joiden päivämäärät ovat pielessä.

Kaikissa kolmessa skenaariossa ongelma on identtinen ja ratkaisu sama. Sähköpostimigraation tarkistuslistasta löydät ohjeet tämäntyyppisten ongelmien ennakoimiseen ennen migraation käynnistämistä.

Miksi oma skripti ei ole vastaus

Ongelman ymmärtäminen on yksi asia. Se, että kirjoittaa Python-skriptin, joka "siivoaa otsikot", ja ajaa sen 30 000 tuotantosähköpostin päällä, on aivan toinen juttu.

Reunatapauksia on loputtomasti. Skripti, joka toimii 50 testisähköpostilla puhtaassa testiympäristössä, kohtaa todellisessa tuotantopostilaatikossa väistämättä:

• Viestejä, joissa on S/MIME-allekirjoituksia tai PGP-salattua sisältöä, joissa mikä tahansa viestin rakenteeseen tehtävä muutos mitätöi kryptografisen allekirjoituksen.
• Sähköposteja, joissa on monimutkaisia sisäkkäisiä MIME-rakenteita (multipart/alternative multipart/mixed-sisällä, kymmeniä megatavuja liitetiedostoja).
• RFC 2047 -koodattuja otsikoita (ei-ASCII-merkit), joita huonosti konfiguroidut jäsentimet nielevät hiljaa.
• 429 Too Many Requests -virheitä Google-rajapinnasta kello kahden aikaan yöllä korjauserän keskellä, jolloin prosessi jää määrittelemättömään tilaan.
• Sähköposteja, joissa Received:-ketju on monitulkintainen: useampi peräkkäinen migraatiotyökalu on lisännyt oman otsikkonsa, eikä ole selvää, mikä niistä pitää poistaa.

Ja kaikkein tärkein kysymys: miten varmistat sähköposti kerrallaan, että jokainen korjattu viesti on ehjä eikä mitään ole kadonnut tai vioittunut? Oma skripti ei yleensä tee tätä tarkistusta. Redate.io tekee sen automaattisesti ja säilyttää alkuperäiset viestit näkyvässä varmuuskopiointikansiossa 30 päivän ajan.

Mitä Redate.io tekee tämäntyyppisille migraatioille

Redate.io yhdistää kohde-Google Workspace -tenantiin (domainin delegoinnin kautta, ilman manuaalista postilaatikko kerrallaan -työtä) ja skannaa sähköpostit tunnistaakseen ne, joiden päivämäärän metatiedot ovat ristiriidassa viestin sisällön kanssa. Tämä skannasvaihe on ilmainen ja antaa tarkan kuvan ongelman laajuudesta ennen korjausta.

Patentoitu korjausmoottori analysoi sen jälkeen jokaisen viestin otsikkoketjun, sovittaa tunnettujen migraatiotyökalujen allekirjoitusmalleja (BitTitan, CloudM, imapsync, GSMMO ja harvinaisemmat), ja tekee kohdennetun metatieto-oikaisun muuttamatta viestin sisältöä. Jokainen korjattu sähköposti tarkistetaan yksitellen. Alkuperäiset säilyvät.

Google Workspace -tenantien välisiä siirtoja varten pipeline käsittelee tapaukset, joissa useampi migraatiopassi on tehty (esimerkiksi postilaatikko siirretty ensin 2021 ja uudelleen 2024), jolloin purettavia ylimääräisiä otsikkokerroksia on useita.

Korjausohjeet löydät täältä: CloudM Google Workspace -siirron päivämäärät ja BitTitan Google Workspace -siirron päivämäärät.

Ongelman havaitseminen ennen kuin käyttäjät huomaavat

Paras hetki havaita rikkinäiset päivämäärät on heti migraation jälkeen, ennen tuotantoon siirtymistä. Nopea tarkistus muutamalla pilottipostilaatikolla IMAP-ohjelmalla kuten Thunderbirdillä riittää vertaamaan päivämäärien näyttämistä odotettuun. Jos kaikki tuodut sähköpostit näyttävät saman tuoreen päivämäärän, se on varma merkki ongelmasta.

Käytännössä ongelma löydetään kuitenkin usein vasta viikkoja migraation jälkeen, kun käyttäjä etsii vanhaa sopimusta ja huomaa Gmail-postilaatikkonsa olevan täydellisesti järjestetty... migraatiopäivän mukaan. Tuhansia sähköposteja samalla aikaleimauksella. Päivämäärähaku ei toimi. Keskusteluketjut ovat epäjärjestyksessä. Historia näyttää hävinneen.

MSP:ille, jotka hallitsevat säännöllisesti Google Workspace -tenant-siirtoja: Redate.io-skannauksen lisääminen migraation jälkeiseen tarkistuslistaan (ennen asiakkaan hyväksyntää) ehkäisee tämäntyyppiset yllätykset.

Siirsitkö juuri kahden Google Workspace -tenantin välillä ja sähköpostien päivämäärät ovat pielessä? Käynnistä ilmainen skannaus Redate.io:ssa ja mittaa vaikutus ennen korjausta.