Migration Google Workspace σε GWS: ημερομηνίες email χαλάνε

Το σενάριο που κανείς δεν περιμένει

Μόλις ολοκληρώσατε τη μεταφορά ενός tenant Google Workspace σε άλλο. Εξαγορά εταιρείας, αλλαγή domain, συγχώνευση δύο οντοτήτων που συνυπήρχαν σε ξεχωριστούς λογαριασμούς G Suite για χρόνια. Η επέμβαση πήγε καλά, τα γραμματοκιβώτια είναι στη θέση τους, οι χρήστες συνδέονται κανονικά. Δευτέρα πρωί, πρώτο ticket: "Όλα μου τα email έχουν την ίδια ημερομηνία." Μετά ένα δεύτερο. Μετά δέκα.

Αυτόματα σκέφτεστε: σίγουρα πρόβλημα IMAP, κάποιο εργαλείο λάθος ρυθμισμένο, κάτι εξωτικό. Όχι μια μεταφορά Google σε Google. Κι όμως, ακριβώς εκεί συμβαίνει.

Αυτό το σενάριο είναι πιθανώς το λιγότερο τεκμηριωμένο στον κλάδο. Οι περισσότεροι IT admins που το αντιμετωπίζουν χάνουν αρκετές ώρες ψάχνοντας από την πλευρά του client mail, του Outlook, των ρυθμίσεων λογαριασμού, πριν συνειδητοποιήσουν ότι το πρόβλημα βρίσκεται μέσα στις κεφαλίδες (headers) των ίδιων των email.

Γιατί μια μεταφορά Google σε Google χαλάει τις ημερομηνίες

Για να καταλάβετε τι συμβαίνει, πρέπει να επιστρέψετε στη μηχανική των email headers. Κάθε μήνυμα RFC 2822 περιέχει ένα πεδίο Date: που τοποθετείται από τον client ή τον εξυπηρετητή αποστολής τη στιγμή της αποστολής. Αυτή είναι η "αληθινή" ημερομηνία του email, αυτή που αντιστοιχεί στο πότε γράφτηκε και στάλθηκε το μήνυμα.

Υπάρχει όμως και ένας άλλος μηχανισμός: το INTERNALDATE του IMAP. Είναι ένα metadata αποθηκευμένο στον εξυπηρετητή που δείχνει πότε αποτέθηκε το μήνυμα στο γραμματοκιβώτιο. Κι εδώ γίνεται ενδιαφέρον.

Όταν ένα εργαλείο μεταφοράς μεταφέρει ένα email από έναν tenant Google Workspace σε άλλον, χρησιμοποιεί το πρωτόκολλο IMAP (ακόμα και αν οι δύο εξυπηρετητές είναι στη Google). Το μήνυμα διαβάζεται από την πηγή και εισάγεται εκ νέου στον προορισμό. Κατά την εισαγωγή, ο εξυπηρετητής προορισμού προσθέτει αυτόματα μια κεφαλίδα Received: με τη χρονοσήμανση της επέμβασης, δηλαδή την ημερομηνία της μεταφοράς.

Ωστόσο, clients mail όπως το Outlook χρησιμοποιούν το πρώτο Received: της αλυσίδας για να εμφανίσουν την ημερομηνία ενός μηνύματος, όχι απαραίτητα το αρχικό πεδίο Date:. Αποτέλεσμα: όλα τα email εμφανίζουν την ημερομηνία της ημέρας μεταφοράς.

Ποια εργαλεία προκαλούν το πρόβλημα

Σχεδόν όλα τα εργαλεία που χρησιμοποιούνται για μεταφορές μεταξύ tenant Google Workspace επηρεάζονται. Καμία αξιοσημείωτη εξαίρεση:

• GSMMO (Google Workspace Migration for Microsoft Outlook): σχεδιασμένο αρχικά για μεταφορά από Exchange, αλλά χρησιμοποιείται και σε ορισμένες ροές GWS σε GWS.
• CloudM Migrate: πολύ διαδεδομένο στους MSPs για μεταφορές inter-Google, προσθέτει συστηματικά ένα Received: μεταφοράς. Δείτε την αναλυτική ανάλυση του CloudM.
• BitTitan MigrationWiz: το ίδιο, η συμπεριφορά τεκμηριώνεται σε αυτό το άρθρο για το BitTitan.
• imapsync: το open source εργαλείο που επιτρέπει scripted μεταφορές IMAP, συμπεριλαμβανομένων αυτών μεταξύ δύο tenant Google.
• Χειροκίνητες εξαγωγές/εισαγωγές μέσω Takeout + επανεισαγωγή IMAP: λιγότερο συχνές, αλλά παράγουν ακριβώς το ίδιο αποτέλεσμα.

Ο λόγος είναι απλός: όλα αυτά τα εργαλεία λειτουργούν ως τυπικοί IMAP clients. Δεν έχουν πρόσβαση σε κάποιο "native" μονοπάτι Google που θα διατηρούσε τα metadata. Ακόμα και αν οι δύο tenant είναι στη Google, η μεταφορά περνάει από το επίπεδο IMAP, και αυτό το επίπεδο δεν "ξέρει" ότι μιλάει με τον εαυτό του.

Η μηχανική των κεφαλίδων Received σε βάθος

(Αν έχετε δοκιμάσει να διαβάσετε τις raw κεφαλίδες ενός email από το Gmail ή το Outlook, ξέρετε ότι σπάνια είναι ευχάριστη ανάγνωση. Εκεί όμως κρύβεται όλη η αλήθεια.)

Ένα email που έχει ταξιδέψει κανονικά περιέχει μια αλυσίδα κεφαλίδων Received: σε αντίστροφη σειρά από τη διαδρομή: ο τελευταίος εξυπηρετητής που άγγιξε το μήνυμα είναι πρώτος. Μετά από μεταφορά, η κεφαλίδα μεταφοράς βρίσκεται στην κορυφή της στοίβας.

Δείτε πώς φαίνεται σε ένα μήνυμα που μεταφέρθηκε μέσω CloudM από έναν tenant GWS σε άλλον:

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

Το πεδίο Date: λέει 2019. Το πρώτο Received: λέει Οκτώβριο 2024. Το Outlook διαβάζει το πρώτο Received:. Ο χρήστης βλέπει Οκτώβριο 2024 για ένα email του 2019.

Το αρχικό πεδίο Date: είναι άθικτο. Δεν έχει αλλάξει. Αυτό είναι τα καλά νέα: το δεδομένο υπάρχει, απλώς περιμένει να χρησιμοποιηθεί σωστά.

Το Outlook και το Gmail δεν συμπεριφέρονται το ίδιο

Αυτή είναι μια σημαντική διευκρίνιση. Οι χρήστες που έχουν πρόσβαση στα email τους μέσω της web διεπαφής του Gmail βλέπουν συχνά τις σωστές ημερομηνίες, επειδή το Gmail δίνει προτεραιότητα στο πεδίο Date: RFC 2822 για την εμφάνιση μηνυμάτων. Το πρόβλημα είναι λιγότερο ορατό στο web.

Αντίθετα, οι χρήστες που ρυθμίζουν το Google Workspace γραμματοκιβώτιό τους στο Outlook μέσω IMAP (ή μέσω συγχρονισμού Exchange ActiveSync) υποφέρουν πλήρως από τη λανθασμένη ημερομηνία, επειδή το Outlook βασίζεται στο INTERNALDATE IMAP, το οποίο αντικατοπτρίζει την ημερομηνία του πρώτου Received: που προστέθηκε κατά τη μεταφορά.

Για να είμαστε ακριβείς: η συμπεριφορά του Outlook ποικίλει ανάλογα με την έκδοση και τον τρόπο σύνδεσης. Το Outlook 2019 και το Microsoft 365 (οι πρόσφατες εκδόσεις) χρησιμοποιούν το INTERNALDATE όταν συνδέονται μέσω IMAP. Παλαιότερες εκδόσεις μπορεί να έχουν ελαφρώς διαφορετική συμπεριφορά. Σε όλες όμως τις περιπτώσεις που έχουν παρατηρηθεί σε παραγωγικό περιβάλλον, η μεταφορά GWS σε GWS μέσω IMAP παράγει λανθασμένες ημερομηνίες στο Outlook.

Έτσι, σε οργανισμούς που έχουν μεταφερθεί σε νέο tenant και διατηρούν υβριδικούς χρήστες (μερικοί στο Gmail web, άλλοι στο Outlook), τα tickets είναι ασυνεπή. Οι IT ομάδες χάνουν χρόνο προσπαθώντας να καταλάβουν γιατί "κάποιοι επηρεάζονται και άλλοι όχι", ενώ η απάντηση είναι απλή: είναι ο mail client που κάνει τη διαφορά.

Εξαγορές, συγχωνεύσεις, αλλαγές domain: τα πιο συχνά σενάρια

Αυτός ο τύπος μεταφοράς δεν είναι ασυνήθιστος. Τα σενάρια που παράγουν τα περισσότερα tickets:

Εξαγορά εταιρείας

Μια εξαγορασθείσα εταιρεία είχε τον δικό της tenant Google Workspace (domain @old-company.com). Μετά την εξαγορά, όλα πρέπει να μεταφερθούν στον tenant της μητρικής (@group.com). Τα 250 γραμματοκιβώτια, τα αρχεία, τα 8 χρόνια ιστορικού email. Το BitTitan ή το CloudM αναλαμβάνει την επέμβαση. Αποτέλεσμα: 2,4 εκατομμύρια email με την ημερομηνία του Σαββατοκύριακου της μεταφοράς.

Αλλαγή domain

Μια επιχείρηση που rebranding-άρηκε περνάει από @old-name.gr σε @new-name.gr. Ίδιο tenant Google, αλλά δημιουργία νέου tenant για να ξεκινήσει καθαρά (συνηθισμένη επιλογή για να αποφευχθούν artifacts ρύθμισης). Μεταφορά γραμματοκιβωτίων μέσω imapsync ή GSMMO. Οι ημερομηνίες χαλάνε ακριβώς με τον ίδιο τρόπο.

Ενοποίηση θυγατρικών

Ένας όμιλος με 4 θυγατρικές, η καθεμία στο δικό της ιστορικό tenant G Suite, που αποφασίζει να τα συγκεντρώσει όλα σε ένα ενιαίο tenant. Τέσσερις μεταφορές παράλληλα, τέσσερις ομάδες email με κατεστραμμένες ημερομηνίες για επεξεργασία.

Και στα τρία σενάρια, το πρόβλημα είναι πανομοιότυπο και η λύση η ίδια. Το checklist μεταφοράς email επιτρέπει να αντιμετωπίσετε αυτόν τον τύπο προβλήματος πριν ξεκινήσετε τη μεταφορά.

Γιατί ένα script από το σπίτι δεν είναι η απάντηση

Να καταλαβαίνετε το πρόβλημα είναι ένα. Να σκέφτεστε "θα γράψω ένα Python script που καθαρίζει τις κεφαλίδες" και να το εφαρμόσετε σε 30.000 email παραγωγής είναι άλλο.

Οι οριακές περιπτώσεις είναι πολλές. Ένα script που λειτουργεί σε 50 δοκιμαστικά email σε καθαρό περιβάλλον θα συναντήσει αναπόφευκτα, σε ένα γραμματοκιβώτιο παραγωγής πραγματικού μεγέθους:

• Μηνύματα με υπογραφές S/MIME ή κρυπτογραφημένο περιεχόμενο PGP, όπου κάθε τροποποίηση της δομής του μηνύματος ακυρώνει την κρυπτογραφική υπογραφή.
• Email με σύνθετες εμφωλευμένες δομές MIME (multipart/alternative μέσα σε multipart/mixed με συνημμένα αρκετών δεκάδων megabyte).
• Κεφαλίδες κωδικοποιημένες κατά RFC 2047 (χαρακτήρες non-ASCII), τις οποίες κακώς ρυθμισμένοι parsers καταπίνουν σιωπηλά.
• Σφάλματα 429 Too Many Requests από το Google API στις 2 τα ξημερώματα, στη μέση ενός batch διόρθωσης, που αφήνουν τη διαδικασία σε αδιόριστη κατάσταση.
• Email για τα οποία η αλυσίδα Received: είναι αμφίσημη: πολλά διαδοχικά εργαλεία μεταφοράς έχουν προσθέσει το δικό τους header, και δεν είναι τετριμμένο να αποφασίσετε ποιο να αφαιρέσετε.

Και η πιο σημαντική ερώτηση: πώς επαληθεύετε, email ανά email, ότι κάθε διορθωμένο μήνυμα είναι άθικτο και ότι τίποτα δεν χάθηκε ή καταστράφηκε; Ένα self-made script συνήθως δεν κάνει αυτή την επαλήθευση. Το Redate.io τη διεκπεραιώνει αυτόματα, με διατήρηση των πρωτότυπων σε ένα ορατό φάκελο backup για 30 ημέρες.

Τι κάνει το Redate.io σε αυτόν τον τύπο μεταφοράς

Το Redate.io συνδέεται στον tenant Google Workspace προορισμού (μέσω domain delegation, χωρίς χειροκίνητη επέμβαση γραμματοκιβώτιο ανά γραμματοκιβώτιο) και σαρώνει τα email για να εντοπίσει αυτά των οποίων τα metadata ημερομηνίας είναι ασύμβατα με το περιεχόμενο του μηνύματος. Αυτή η φάση σάρωσης είναι δωρεάν και δίνει ακριβή εικόνα της έκτασης του προβλήματος πριν από οποιαδήποτε διόρθωση.

Ο proprietary κινητήρας διόρθωσης αναλύει στη συνέχεια την αλυσίδα κεφαλίδων κάθε μηνύματος, εφαρμόζει αντιπαραβολή προτύπων με τις γνωστές υπογραφές εργαλείων μεταφοράς (BitTitan, CloudM, imapsync, GSMMO, και άλλα λιγότερο συνηθισμένα), και πραγματοποιεί στοχευμένη διόρθωση των metadata χωρίς αλλοίωση του περιεχομένου του μηνύματος. Κάθε διορθωμένο email επαληθεύεται μεμονωμένα. Τα πρωτότυπα διατηρούνται.

Για μεταφορές μεταξύ tenant Google Workspace ειδικότερα, το pipeline διαχειρίζεται περιπτώσεις όπου έχουν πραγματοποιηθεί πολλαπλά πάσα μεταφοράς (για παράδειγμα, ένα γραμματοκιβώτιο που μεταφέρθηκε πρώτα το 2021 και ξανά το 2024), με πολλαπλά επίπεδα παρασιτικών κεφαλίδων να ξεδιαλύνονται.

Ο οδηγός διόρθωσης CloudM σε Google Workspace και BitTitan σε Google Workspace αναλύουν τα βήματα σύνδεσης για αυτόν τον τύπο διαμόρφωσης.

Να εντοπίσετε το πρόβλημα πριν το αναφέρουν οι χρήστες

Η καλύτερη στιγμή για να εντοπίσετε κατεστραμμένες ημερομηνίες είναι αμέσως μετά τη μεταφορά, πριν το go-live. Μια γρήγορη επαλήθευση σε μερικά pilot γραμματοκιβώτια μέσω ενός IMAP client όπως το Thunderbird επιτρέπει να συγκρίνετε την εμφάνιση των ημερομηνιών με αυτό που θα περιμένατε. Αν όλα τα εισαγόμενα email φαίνεται να έχουν την ίδια πρόσφατη ημερομηνία, αυτό είναι το χαρακτηριστικό σύμπτωμα του προβλήματος.

Στην πράξη, όμως, η ανακάλυψη του προβλήματος γίνεται συχνά αρκετές εβδομάδες μετά τη μεταφορά, όταν ένας χρήστης ψάχνει ένα παλιό συμβόλαιο και συνειδητοποιεί ότι το γραμματοκιβώτιό του στο Gmail είναι τέλεια ταξινομημένο... κατά ημερομηνία μεταφοράς. Χιλιάδες email σωριασμένα στην ίδια χρονοσήμανση. Η αναζήτηση κατά ημερομηνία δεν λειτουργεί πια. Τα νήματα συζήτησης είναι ανακατωμένα. Το ιστορικό φαίνεται να έχει εξαφανιστεί.

Για τους MSPs που διαχειρίζονται τακτικά μεταφορές μεταξύ tenant Google Workspace, η ενσωμάτωση ενός scan του Redate.io στο checklist post-migration (πριν από την αποδοχή από τον πελάτη) αποτρέπει τέτοιου είδους εκπλήξεις.

Μόλις μεταφέρατε δεδομένα μεταξύ δύο tenant Google Workspace και οι ημερομηνίες των email σας είναι λανθασμένες; Εκκινήστε ένα δωρεάν scan στο Redate.io για να μετρήσετε την έκταση του προβλήματος πριν από οποιαδήποτε διόρθωση.