Klaidingos datos po migracijos į Exchange Online

Klasikinis pirmadienio ryto scenarijus

Ką tik baigėte IMAP migraciją į Exchange Online. Paketas Exchange administravimo centre (EAC) baigėsi be klaidų, pašto dėžutės sinchronizuotos, vartotojai gali prisijungti. Penktadienio vakarą užverate kompiuterį su atlikto darbo jausmu.

Pirmadienio rytą pradeda plaukti kvietimai. „Visi mano laiškai datuoti penktadieniu." „Mano pašto dėžutės istorija nebenaudojama." „Trūksta senų laiškų." Iš tikrųjų nieko netrūksta: laiškai yra, tačiau Outlook juos rodo su migracijos data vietoj tikrosios išsiuntimo datos. 2019 metų laiškas atrodo kaip praėjusio penktadienio žinutė. Rezultatas: visa dėžutė atrodo pilna tik naujausių laiškų.

Tai viena iš labiausiai varginančių IMAP migracijos į Exchange Online problemų, kurią Microsoft sistemingai pamini tik trumpai.

Kodėl EAC migracija sugadina datas

Kai naudojate Exchange administravimo centrą (EAC) IMAP migracijai konfigūruoti iš vietinio serverio (Dovecot, Courier, Cyrus, UW-IMAP ar bet kurio kito), Exchange Online prisijungia prie šaltinio serverio per IMAP, paima žinutes ir jas įterpia į paskirties dėžutes per savo vidinį transporto vamzdyną.

Čia ir kyla problema.

Kiekvienas laiškas, pereinantis per Exchange transporto vamzdyną, automatiškai gauna laiku pažymėtą Received: antraštę. Tai standartinis SMTP ir IMAP serverių elgesys jau dešimtmečius: kiekvienas serveris, liečiantis žinutę, ant jos uždeda savo laiko antspaudą. Problema ta, kad Outlook (ypač naujesni Outlook versijų Windows leidimai) naudoja paskutinę Received: antraštę kaip rodymo atskaitos tašką, kai kiti metaduomenys yra dviprasmiški.

Originali Date: antraštė (ta, kuri nurodo, kada laiškas iš tikrųjų buvo išsiųstas, pagal RFC 2822) vis dar yra laiške. Ji nebuvo ištrinta. Tačiau ją „užgožia" nauja Received: antraštė, kurią Exchange prideda įterpdamas žinutę.

Be to, IMAP INTERNALDATE (metaduomenys, kuriuos IMAP serveriai naudoja vidiniam žinučių datavimui ir kurie valdo rikiavimą daugelyje klientų) nustatoma įterpimo data, o ne originalia laiško data. Exchange Online neturi jokio natyvaus būdo išsaugoti šaltinio serverio INTERNALDATE paketinės migracijos per EAC metu.

EAC ir trečiųjų šalių įrankiai: svarbus skirtumas

Reikia skirti dvi situacijas. Su tokiais įrankiais kaip BitTitan MigrationWiz ar CloudM Migrate problema taip pat egzistuoja, tačiau šie įrankiai kartais turi konfigūracijos parinktis (iš dalies dokumentuotas, dažnai paslėptas išplėstiniuose nustatymuose), kurios bando išsaugoti tam tikrus datos metaduomenis.

Natyvios migracijos per EAC nėra tokio tipo parinkčių. Microsoft nesuteikia parametro INTERNALDATE išsaugojimui kontroliuoti paketinės migracijos vamzdyne. Tai juodoji dėžė: sukonfigūruojate paketą, paleidžiate jį, Exchange viduje daro, ką nori. O daro jis sistemingai viena: datuoja žinutes jų įterpimo data.

(Beje, jei bandėte skaityti neapdorotas migravimo per EAC laiško antraštes, žinote, kad Exchange pridėtas Received: laukas atpažįstamas iš toli: jame yra nuorodos į Microsoft vidinius serverius, pvz., *.protection.outlook.com ar *.prod.exchangelabs.com, su laiko žyma, kuri tiksliai atitinka migracijos langą.)

Kodėl iš naujo sukurtas paketas neišsprendžia problemos

Daugelio IT administratorių instinktyvi reakcija yra: „Jei ištrinsiu migravusias dėžutes ir iš naujo paleisiu paketą nuo nulio, gal šį kartą datos bus teisingos."

Tai suprantama. Bet tai neveikia.

Problema nėra paketo konfigūracijoje. Ji nėra parametro, kurį pamiršote pažymėti. Ji yra pačioje Exchange transporto vamzdyno architektūroje, kuri yra identiška kiekvienai migracijai. Pakartotinis paleidimas duos lygiai tokį patį rezultatą: tas pačias Received: antraštes su nauja migracijos data ir tas pačias neteisingas INTERNALDATE reikšmes. Prarasite laiką, o vartotojai bus trikdomi antrą kartą be jokios naudos.

Kai kurie administratoriai taip pat bando keisti rikiavimo parametrus Outlook programoje (rikiavimas „pagal išsiuntimo datą", o ne „pagal gavimo datą"). Rikiavimas pagal išsiuntimo datą nėra sprendimas. Tai tik pleistras. Date: antraštė ir INTERNALDATE išlieka neteisingi klientams, kurie neleidžia šio nustatymo, OWA, Outlook Mobile ir bet kuriai trečiosios šalies programai, pasiekiančiai dėžutę per IMAP ar EWS.

Kas iš tikrųjų vyksta antraštėse

Štai supaprastintas pavyzdys, ką laiškas turi po migracijos per EAC. Originali antraštė:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@senasisdomenas.lt
Subject: Ataskaita Q1 2019

Po migracijos žinutė grandinės pradžioje gauna kažką panašaus:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook pirmiausia pamato šią Received: antraštę (ji pridedama antraščių bloko viršuje), interpretuoja ją kaip naujausią žinutės apdorojimo datą ir rodo ją kaip gavimo datą. Originali 2019 metų Date: antraštė vis dar yra, nepakitusi, keliomis eilutėmis žemiau. Bet Outlook jos nenaudoja rodydamas žinučių sąraše.

Tiksliai kalbant: elgsena šiek tiek skiriasi priklausomai nuo Outlook versijos. Po 2021 m. versijos (ir ypač naujasis Outlook Windows sistemai, diegiamas nuo 2023 m. pabaigos) ypač jautrios šiai problemai, nes labiau remiasi Exchange Graph metaduomenimis nei neapdorota Date: antraštė. Tai reiškia, kad migracijos, kurios su Outlook 2016 nesukeldavo matomų problemų, dabar gali kelti nepatogumų su naujuoju Outlook.

Kas iš tikrųjų nukentėjo

Dažniausiai pasitaikantys IMAP šaltinio serveriai tokio tipo migracijose yra Dovecot (labai paplitęs Linux/cPanel aplinkose) ir Courier. Abu per IMAP atskleidžia INTERNALDATE reikšmes, kurių EAC neišsaugo. Jei migruojate iš Exchange on-premises į Exchange Online (hibridinė ar cutover migracija), elgesys skiriasi, nes Microsoft naudoja vidinį transporto protokolą (MAPI/EWS), kuris geriau išsaugo metaduomenis. Problema kyla būtent su generine IMAP migracija per EAC.

Labiausiai nukentėję vartotojai yra tie, kurių dėžutėse yra ilga istorija (5 metai ir daugiau) ir didelis žinučių kiekis. Vartotojas su 300 el. laiškų greitai susidoros. Tačiau komercijos direktorius su 12 000 laiškų, surikiuotų pagal datą, nuo kurių kasdien priklauso ieškodamas klientų susirašinėjimo, yra tiesiog paralyžiuotas.

Kodėl namų darbo skriptas čia yra bloga idėja

Kai kurie IT administratoriai, suprantantys techninę problemą, yra gundomi parašyti PowerShell ar Python skriptą antraštėms taisyti rankiniu būdu. Pagrindinė koncepcija gali atrodyti paprasta, kai mechanizmas jau identifikuotas. Bet korekcija gamybinėje aplinkoje yra visai kita istorija.

Pirma, kraštutiniai atvejai. S/MIME pasirašyti el. laiškai ir PGP užšifruotos žinutės turi struktūrą, kuri netoleruoja antraščių keitimo nepanaikinant parašo. Multipart/alternative žinutės su neteisingai suformuotomis MIME ribomis (dažnos senuose Courier serveriuose) gali būti sugadintos skripto, kuris keičia žinutę netinkamai rekonstruodamas struktūrą. RFC 2047 koduotos ne-ASCII antraštės (siuntėjų vardai su kirčiuotais simboliais ar japonų rašmenimis) yra klasikinė klaidų šaltinis.

Antra, apimtis. Skriptas, veikiantis su 50 bandomųjų laiškų kūrimo aplinkoje, nesusitvarko su Exchange Online API greičio apribojimais gamyboje. Klaida 429 Too Many Requests 2 valandą nakties per 8 000 žinučių paketą, be atstatymo mechanizmo, reiškia nemiegotą naktį ir galimus dvigubus ar prarastus laiškus.

Ir svarbiausia: kaip patikrinti, kad kiekvienas pataisytas laiškas yra nepažeistas? Kad nė vienas priedas nebuvo sutrumpintas, kad nė vienas diskusijų srautas nėra nutrauktas, kad etiketės ir aplankai išsaugoti? Be individualaus tikrinimo mechanizmo tenka tik tikėtis, kad viskas praėjo gerai.

Datų taisymas po migracijos atrodo kaip 50 eilučių skriptas, bet reikia tūkstančių eilučių, kad būtų patikimas gamybinėje aplinkoje.

Ką Redate.io daro kitaip

Redate.io prisijungia prie Exchange Online per Microsoft 365 API (Azure Active Directory, tenantu lygio delegavimo teisės) ir nuskaito atitinkamas dėžutes, kad identifikuotų el. laiškus, kurių datos metaduomenys buvo sugadinti migracijos metu. Ši nuskaitymo etapa yra nemokama ir suteikia tikslų vaizdą apie problemos mastą: paveiktų žinučių skaičius, atitinkamos dėžutės, sugadintų datų diapazonas.

Redate.io nuosavybinis korekcijos variklis vėliau apdoroja kiekvieną el. laišką atskirai per daugiapakopį analizės vamzdyną, apimantį šablonų atitikimą su žinomų migracijos įrankių parašais (įskaitant Exchange Online transporto vamzdyną), RFC atitikties tikrinimą ir žinutės struktūros vientisumo patikrinimą prieš korekciją ir po jos. S/MIME pasirašyti laiškai, sudėtingos MIME struktūros, nestandartiniai koduojimai - visi jie tvarkomi specialiais apdorojimo keliais.

Kiekviena pataisyta žinutė tikrinama atskirai. Originalai saugomi matomame atsarginių kopijų aplanke 30 dienų. Jei su konkrečia žinute kažkas negerai, ji nekeičiama: Redate.io praneša apie anomaliją vietoj to, kad rizikuotų sugadinimu.

Kainodara grindžiama apimtimi, vienkartiniu mokėjimu už dėžutę. Jokio prenumeratos, jokių pasikartojančių mokesčių. Problemą ištaisote vieną kartą - ir viskas.

Konkrečiai Exchange Online migracijoms Redate.io palaiko prisijungimą per Azure AD programos teises (nereikia kurti atskirų kredencialų kiekvienai dėžutei), todėl didelių dėžučių flotų apdorojimas IT administratoriui ar MSP yra daug paprasčiau organizuojamas.

Jei valdote kelis klientus, patyrusius tokio tipo migraciją, perskaitykite ir išsamų vadovą apie datų taisymą po Microsoft 365 migracijos - jame rasite visų skirtingų scenarijų apžvalgą.

Laiškai yra, originalios datos irgi. Paleiskite nemokamą nuskaitymą Redate.io, kad sužinotumėte tiksliai, kiek žinučių yra paveikta jūsų Exchange Online dėžutėse, prieš nuspręsdami, ką daryti.