Google Workspace tenant-migráció: elromlott email dátumok

A forgatókönyv, amelyre senki nem számít

Végrehajtotta a migrációt az egyik Google Workspace tenantból a másikba. Felvásárlás, domainnév-váltás, két különálló G Suite-fiókban évekig párhuzamosan élő cégegység összevonása. Az átköltözés sikeresen zajlott le, a postaládák a helyükön vannak, a felhasználók bejelentkeznek. Hétfő reggel jön az első ticket: „Minden emailemen ugyanaz a dátum szerepel." Majd a második. Majd tíz.

Az első reflexe valószínűleg ez: biztosan IMAP-probléma, rosszul beállított eszköz, valami egzotikus hiba. Nem egy Google-ból Google-ba történő migráció. Pedig pontosan ott csúszik el valami.

Ez a forgatókönyv valószínűleg a leghiányosabban dokumentált az iparágban. A legtöbb IT-adminisztrátor, aki találkozik vele, órákat tölt el a levelezőprogramban, az Outlookban, a fiókbeállításokban keresgélve, mielőtt rájön, hogy a probléma magukban az email fejlécekben van.

Miért rontja el a Google-ból Google-ba migráció a dátumokat

A jelenség megértéséhez vissza kell menni az email fejlécek működéséhez. Minden RFC 2822-es üzenet tartalmaz egy eredeti Date: mezőt, amelyet a küldő kliens vagy szerver az üzenet elküldésekor állít be. Ez az email „valódi" dátuma, az a pillanat, amikor az üzenetet megírták és elküldték.

De létezik egy másik mechanizmus is: az IMAP INTERNALDATE. Ez egy szerveroldali metaadat, amely azt jelzi, mikor érkezett meg az üzenet a postaládába. És itt válik érdekessé a dolog.

Amikor egy migrációs eszköz átvesz egy emailt az egyik Google Workspace tenantból a másikba, az IMAP protokollon keresztül teszi ezt (még akkor is, ha mindkét szerver a Google-nál van). Az üzenetet beolvassák a forrásból, majd beillesztik a célpostaládába. Ennél a beillesztésnél a célszerver automatikusan hozzáfűz egy Received: fejlécet az aktuális időbélyeggel, azaz a migráció dátumával.

Az olyan levelezőprogramok viszont, mint az Outlook, a lánc első Received: fejlécét használják az üzenet dátumának megjelenítéséhez, nem feltétlenül az eredeti Date: mezőt. Eredmény: minden email a migráció napjának dátumát mutatja.

Mely eszközök okozzák a problémát

Gyakorlatilag minden eszköz érintett, amelyet Google Workspace tenantok közötti migrációhoz használnak. Nincs érdemi kivétel:

• GSMMO (Google Workspace Migration for Microsoft Outlook): eredetileg Exchange-ből való migrációra tervezték, de bizonyos GWS-ből GWS-be irányuló folyamatokban is alkalmazzák.
• CloudM Migrate: az MSP-k körében elterjedt eszköz Google-tenantok közötti migrációhoz, amely szisztematikusan hozzáad egy migrációs Received: fejlécet. Részletes elemzés a CloudM hibás email dátumokról szóló cikkben.
• BitTitan MigrationWiz: ugyanez a viselkedés, a részletekről bővebben a BitTitanról szóló cikkben.
• imapsync: a nyílt forráskódú eszköz, amellyel IMAP-migrációk szkriptelhetők, beleértve a két Google-tenant közötti átvitelt is.
• Manuális Takeout + IMAP-reimport módszer: ritkábban alkalmazzák, de pontosan ugyanolyan hatással jár.

Az ok egyszerű: ezek az eszközök mindegyike normál IMAP-kliensként működik. Nincs hozzáférésük olyan „natív" Google-csatornához, amely megőrizné a metaadatokat. Még ha mindkét tenant a Google-nál is van, az átvitel az IMAP-rétegen halad át, és ez a réteg nem tudja, hogy saját magával kommunikál.

A Received fejlécek mechanizmusa részletesen

(Egyébként, ha valaha próbálta olvasni egy email nyers fejléceit a Gmailben vagy az Outlookban, tudja, hogy ez ritkán kellemes szórakozás. De a teljes igazság ott rejtőzik.)

Egy normálisan kézbesített email a szállítási útvonalon megfordított sorrendben tartalmaz Received: fejléceket: az utoljára érintett szerver kerül legfelülre. Migráció után a migrációs fejléc kerül a sor elejére.

Így néz ki egy CloudM segítségével, egyik GWS tenantból a másikba migrált üzenetben:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <felhasznalo@ujdomaine.com>
        ; 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

A Date: mező 2019-et mutat. Az első Received: 2024 októberét. Az Outlook az első Received: fejlécet olvassa. A felhasználó 2024 októberét lát egy 2019-es emailnél.

Az eredeti Date: mező érintetlen. Nem mozdult. Ez a jó hír: az adat ott van, csak arra vár, hogy helyesen használják.

Az Outlook és a Gmail nem ugyanúgy viselkedik

Ez fontos különbség. Azok a felhasználók, akik a Gmail webes felületén érik el leveleiket, általában a helyes dátumokat látják, mert a Gmail az RFC 2822-es Date: mezőt részesíti előnyben az üzenetek megjelenítésekor. A webes felületen a probléma kevésbé szembetűnő.

Ezzel szemben azok a felhasználók, akik a Google Workspace postaládájukat IMAP-on keresztül az Outlookban (vagy Exchange ActiveSync-szinkronizációval) konfigurálták, teljes egészében a rossz dátumot látják, mert az Outlook az IMAP INTERNALDATE-re támaszkodik, amely a migráció során hozzáadott első Received: fejléc dátumát tükrözi.

Pontosítás: az Outlook viselkedése a verziótól és a kapcsolódási módtól függ. Az Outlook 2019 és a Microsoft 365 (újabb verziók) az IMAP-kapcsolat esetén az INTERNALDATE-et használja. A régebbi verziók kissé eltérően viselkedhetnek. De minden éles rendszerben megfigyelt esetben a GWS-ből GWS-be IMAP-on keresztül végzett migráció helytelen dátumokat eredményez az Outlookban.

Ennek következtében azoknál a szervezeteknél, amelyek új tenantba migráltak és vegyes felhasználói bázist tartanak fenn (egyesek Gmail-weben, mások Outlookban), a beérkező ticketek következetlenek. Az IT-csapatok időt töltenek azzal, hogy megértsék, „miért érinti egyeseket és másokat nem", miközben a válasz egyszerű: a különbség a levelezőprogramban van.

Felvásárlások, fúziók, domainnév-váltások: a leggyakoribb esetek

Ez a migrációtípus korántsem ritka. A legtöbb ticketet ezek a forgatókönyvek generálják:

Vállalati felvásárlás

A felvásárolt cégnek saját Google Workspace tenantja volt (@regiVallalatNev.com domainnel). A felvásárlás után mindent át kell vinni az anyavállalat tenantjába (@csoport.com). A 250 postaláda, az archívumok, a 8 évnyi email-előzmény. A BitTitant vagy a CloudM-et bízzák meg a feladattal. Eredmény: 2,4 millió email a migrációs hétvége dátumával.

Domainnév-váltás

Egy rebranding során a vállalat @reginevu.hu-ról @ujnevu.hu-ra vált. Ugyanaz a Google-tenant, de a tiszta kezdés érdekében új tenantot hoznak létre (ez egy bevett megközelítés a konfigurációs örökség elkerülésére). A postaládák migrálása imapsync-kel vagy GSMMO-val történik. A dátumok pontosan ugyanúgy romlanak el.

Leányvállalatok konszolidációja

Egy csoport 4 leányvállalattal, mindegyik a saját, régi G Suite tenantján, úgy dönt, hogy mindent egyetlen tenantba von össze. Négy párhuzamos migráció, négy adag megsérült dátumú email, amelyeket kezelni kell.

Mindhárom esetben a probléma azonos, és a megoldás is ugyanaz. Az email-migrációs ellenőrzőlista segít megelőzni az ilyen jellegű problémákat a migráció indítása előtt.

Miért nem megoldás egy saját szkript

A probléma megértése egy dolog. Azt mondani magunknak, hogy „írok egy Python-szkriptet, amely megtisztítja a fejléceket", majd alkalmazni azt 30 000 éles emailre, az egészen más.

A szélső esetek száma nagy. Egy szkript, amely 50 tesztemailnél jól működik egy tiszta környezetben, éles méretű postaládán szükségszerűen találkozni fog a következőkkel:

• S/MIME aláírással ellátott vagy PGP-vel titkosított üzenetek, ahol az üzenetstruktúra bármilyen módosítása érvényteleníti a kriptográfiai aláírást.
• Komplex beágyazott MIME-struktúrájú emailek (multipart/alternative egy multipart/mixed elemen belül, több tízmegabájtos mellékletekkel).
• RFC 2047 szerint kódolt fejlécek (nem ASCII karakterek), amelyeket a rosszul konfigurált parserek csendben elrontanak.
• 429 Too Many Requests hibák a Google API-tól hajnali 2-kor, egy javítási batch közepén, amelyek meghatározatlan állapotban hagyják a folyamatot.
• Emailek, amelyekben a Received:-lánc kétértelmű: egymást követő migrációs eszközök mindegyike hozzáadta a saját fejlécét, és nem triviális eldönteni, melyiket kell eltávolítani.

A legfontosabb kérdés: hogyan ellenőrizzük emailenként, hogy minden javított üzenet érintetlen, és semmi sem veszett el vagy sérült meg? Egy saját szkript általában nem végzi el ezt az ellenőrzést. A Redate.io automatikusan elvégzi, az eredeti üzenetek megőrzésével egy 30 napig látható biztonsági mentési mappában.

Mit csinál a Redate.io ilyen jellegű migráció esetén

A Redate.io csatlakozik a Google Workspace céltenanthoz (domain-delegáción keresztül, postaládánkénti manuális beavatkozás nélkül), és megvizsgálja az emaileket, hogy azonosítsa azokat, amelyek dátum-metaadatai nem egyeznek az üzenet tartalmával. Ez a szkennelési fázis ingyenes, és pontos képet ad a probléma mértékéről bármilyen javítás előtt.

A szabadalmaztatott korrekciós motor ezután elemzi az egyes üzenetek fejléc-láncát, mintaegyeztetést végez az ismert migrációs eszközök aláírásaival (BitTitan, CloudM, imapsync, GSMMO és más, kevésbé elterjedt eszközök), majd célzott metaadat-korrekciót hajt végre az üzenet tartalmának módosítása nélkül. Minden javított emailt egyenként ellenőriz. Az eredeti üzenetek megmaradnak.

A Google Workspace-tenantok közötti migrációknál a rendszer kezeli azokat az eseteket is, amikor több migrációs menet zajlott le (például egy postaládát először 2021-ben, majd ismét 2024-ben migráltak), ahol több parazita fejlécréteget kell kibogozni.

A konkrét javítási útmutatók: CloudM a Google Workspace-ben és BitTitan a Google Workspace-ben tartalmazzák a csatlakoztatási lépéseket ehhez a konfigurációhoz.

A probléma észlelése, mielőtt a felhasználók szólnának

A megsérült dátumok felderítésének legjobb pillanata közvetlenül a migráció után van, az éles indítás előtt. Néhány pilot postaládán végzett gyors ellenőrzés egy olyan IMAP-klienssel, mint a Thunderbird, lehetővé teszi a megjelenített dátumok összehasonlítását az elvárásokkal. Ha minden importált email ugyanazt a friss dátumot mutatja, ez a probléma jellegzetes tünete.

A valóságban azonban a probléma felfedezése gyakran hetekkel a migráció után történik, amikor egy felhasználó egy régi szerződést keres, és rájön, hogy Gmail-fiókja tökéletesen rendezett... a migráció dátuma szerint. Ezernyi email torlódik ugyanazon az időbélyegen. A dátum szerinti keresés nem működik. A levelezési szálak összekeverednek. Az előzmények mintha eltűntek volna.

Az MSP-k számára, amelyek rendszeresen kezelnek Google Workspace tenantok közötti migrációkat, a Redate.io-szkennelés beillesztése a migrációt követő ellenőrzőlistába (az ügyfél-jóváhagyás előtt) elkerülhetővé teszi az ilyen meglepetéseket.

Két Google Workspace tenant között migrált, és az emailek dátuma helytelen? Indítson ingyenes szkennelést a Redate.io-n, és mérje fel a probléma mértékét bármilyen javítás előtt.