Kas yra „Exchange" administravimo centro IMAP importas?
„Microsoft" teikia integruotą IMAP migracijos funkciją „Exchange" administravimo centre (EAC), leidžiančią administratoriams importuoti el. laiškus iš bet kurio IMAP serverio į „Exchange Online" („Microsoft 365"). Šis vietinis įrankis skirtas organizacijoms, migruojančioms iš ne „Microsoft" platformų: „Gmail", „Zimbra", Dovecot, Courier, cPanel prieglobos ir bet kurio kito serverio, palaikančio IMAP.
„Exchange" administravimo centro IMAP importas dažnai yra pirmas įrankis, kurį administratoriai išbando. Jokios trečiųjų šalių programinės įrangos. Jokių papildomų licencijos kaštų. Tiesiogiai integruotas į „Microsoft 365" administravimo sąsają. Tai atrodo kaip akivaizdus pasirinkimas.
Tačiau šis „Microsoft" vietinis įrankis sukelia tą pačią datų problemą kaip ir trečiųjų šalių migracijos įrankiai. Po IMAP importo per „Exchange" administravimo centrą kiekvienas migruotas el. laiškas rodo migracijos datą vietoj originalios gavimo datos. Naudotojai atidaro „Outlook" ir aptinka, kad metų el. pašto istorija atrodo atėjusi tą pačią dieną. Tai „Microsoft" įrankis, kuris sugadina datas „Microsoft" el. pašto kliente.
Kaip „Exchange" IMAP importas sukelia datų problemas
Importo procesas
„Exchange" administravimo centro IMAP importas veikia prisijungdamas prie šaltinio IMAP serverio, atsisiųsdamas kiekvieną el. laišką ir įterpdamas jį į tikslinę „Exchange Online" pašto dėžutę. Šio įterpimo metu „Exchange Online" traktuoja kiekvieną importuotą el. laišką kaip naują pristatymą ir prideda transporto antraštes, įskaitant „Received" antraštę su esama laiko žyma - importo data.
„Exchange Online" pridėta „Received" antraštė
Kai „Exchange Online" gauna pranešimą (tiek per įprastą pristatymą, tiek per IMAP importą), jis prideda „Received" antraštes, dokumentuojančias pranešimo kelionę per „Microsoft" transporto infrastruktūrą. Šios antraštės turi laiko žymas, atspindinčias momentą, kai „Exchange Online" apdorojo pranešimą. Importuotiems el. laiškams šios laiko žymos atitinka importo operacijos datą ir laiką, o ne originalią pristatymo datą.
Tipinė „Exchange" pridėta „Received" antraštė IMAP importo metu atrodo taip:
Received: from BN6PR01MB1234.prod.exchangelabs.com
by BN6PR01MB5678.prod.exchangelabs.com with HTTPS;
Mon, 15 Jan 2024 08:30:45 +0000Ši antraštė patenka į antraščių grandinės viršų, todėl tampa naujausia „Received". „Outlook" skaito šią antraštę gavimo datai nustatyti ir rodo importo datą kiekvienam migruotam el. laiškui.
Kodėl „Microsoft" įrankis turi šią problemą
Atrodo absurdiškai, kad „Microsoft" migracijos įrankis sukelia datos rodymo problemą „Microsoft" el. pašto kliente. Tačiau paaiškinimas iš tikrųjų logiškas: IMAP importas teisingai fiksuoja pranešimo apdorojimo momentą (el. pašto transporto standartų reikalavimas), ir „Outlook" teisingai skaito naujausią „Received" antraštę gavimo datai nustatyti (standartinis el. pašto kliento elgesys). Šių dviejų teisingų elgesių kombinacija sukuria neteisingą rezultatą migruotiems el. laiškams. Du teisingi dalykai, kurie sukuria klaidą. Techniniam paaiškinimui žr. kodėl el. laiškai rodo klaidingas datas po IMAP migracijos.
IMAP importo konfigūravimas (neužkerta kelio problemai)
„Exchange" administravimo centro nustatymai
„Exchange" administravimo centro IMAP importas siūlo konfigūracijos parinktis aplankų susiejimui, elementų filtravimui ir migracijos paketų planavimui. Tačiau nė viena iš šių parinkčių nekontroliuoja, kaip „Exchange Online" tvarko „Received" antraštes importo metu. Jokio žymimojo langelio „išsaugoti originalias datas" ir jokio nustatymo, neleidžiančio „Exchange" pridėti transporto antraščių. Datų problema yra el. pašto transporto architektūros pasekmė, o ne trūkstama konfigūracijos parinktis.
PowerShell migracijos cmdlet
Administratoriai, naudojantys PowerShell cmdlet (New-MigrationBatch, New-MoveRequest) IMAP migracijai, turi priėjimą prie papildomų parametrų, tačiau nė vienas iš jų neužkerta kelio „Received" antraštės pridėjimui. Start-MigrationBatch cmdlet ir susijusios komandos kontroliuoja migracijos procesą, o ne „Exchange Online" el. pašto transporto elgesį.
Poveikis „Outlook" ir OWA
„Outlook" darbalaukio versija
Darbalaukio „Outlook" yra labiausiai paveiktas klientas. Numatytasis rodinys rūšiuoja el. laiškus pagal „Gavimo" datą, kuri rodo importo laiko žymą kiekvienam migruotam pranešimui. Naudotojai, besiremiantys paieška, rūšiavimu ir filtravimu pagal datą, praranda darbo eigą. Gautieji, apimantys penkerių metų korespondenciją, atrodo tarsi viskas būtų atėję tą pačią dieną. Kaip rasti tą svarbų 2021 m. el. laišką, kai kiekvienas pranešimas teigia atėjęs 2024 m. sausį?
„Outlook" žiniatinklyje (OWA)
OWA rodo tas pačias klaidingas datas kaip ir darbalaukio „Outlook". Skirtingai nei „Gmail" žiniatinklio sąsaja (kuri kartais skaito „Date" antraštę), OWA nuosekliai naudoja „Exchange" pristatymo laiko žymą. Joks OWA nustatymas ar rodymo parinktis nerodo originalios datos vietoj importo datos.
Mobilusis „Outlook"
Mobilusis „Outlook" („iOS" ir „Android") taip pat rodo importo datą. Problema nuosekli visose „Outlook" platformose, nes visos skaito tą pačią datos reikšmę iš „Exchange Online". Išsamiam vadovui apie „Outlook" specifines datų problemas žr. klaidingos „Outlook" datos po migracijos taisymas.
Dažni apėjimai (ir kodėl jie nepasiteisina)
Rūšiavimas pagal „Išsiųsta" datą
Dažniausiai siūlomas apėjimas - pakeisti „Outlook" rodinį rūšiuoti pagal „Išsiųsta" datą vietoj „Gauta" datos. Nors tai pakeičia rodymo tvarką, tai netaiso pagrindinių duomenų. „Gavimo" data lieka klaidinga paieškos rezultatuose, taisyklėse, atitikties įrankiuose ir bet kurioje kitoje funkcijoje, nurodančioje gavimo laiko žymą. Šis apėjimas reikalauja, kad kiekvienas naudotojas pakeistų savo nustatymus kiekviename įrenginyje.
IMAP importo pakartojimas
El. laiškų pakartotinis importas nepataisys datų problemos. Antras importas prideda kitą „Received" antraščių rinkinį su nauja laiko žyma, dar labiau komplikuodamas antraščių grandinę nepataisdamas rodomos datos.
Kito migracijos įrankio naudojimas
Perėjimas prie trečiosios šalies įrankio (BitTitan MigrationWiz, CloudM ar imapsync) neišsprendžia datų problemos. Bet kuris įrankis, įterpiantis el. laiškus į „Exchange Online", sukelia tą patį transporto antraštės elgesį. Problema kyla iš to, kaip „Exchange Online" tvarko gaunamus pranešimus, o ne iš paties migracijos įrankio. Visų taisymo variantų palyginimui žr. ar galima pataisyti el. laiškų datas po migracijos.
„Exchange" IMAP importo datų taisymas su Redate.io
Kaip Redate.io identifikuoja „Exchange" importo antraštes
Redate.io prisijungia prie „Exchange Online" ir praleidžia kiekvieną el. laišką per savo nuosavybinį daugiapakopį analizės konvejerį. „Exchange" IMAP importams Redate.io taiko migracijos parašų atitikimą šimtams žinomų parašų, įskaitant „Exchange Online" transporto infrastruktūros šablonus (pvz., „prod.exchangelabs.com"), kad tiksliai identifikuotų, kurios „Received" antraštės buvo pridėtos importo metu, o kurios yra originalios pristatymo grandinės dalis.
Ką suteikia Redate.io
Po apdorojimo kiekvienas pataisytas el. laiškas rodo originalią gavimo datą „Outlook", OWA ir visuose prijungtuose klientuose. Chronologinė tvarka atkurta. Kiekviena korekcija praeina vientisumo patikrą prieš užbaigimą, o originalai saugomi aplanke „Redate.io - Originals" 30 dienų. Taisymo variklis tvarko specialius atvejus, kurie daro rankiškus metodus pavojingais: S/MIME pasirašytus pranešimus, PGP šifruotą turinį, daugiadales MIME struktūras su įdėtomis ribomis, kodavimo variacijas ir sugadintas MIME ribas.
Prisijungimas prie „Exchange Online"
Redate.io prisijungia prie „Exchange Online" per „Azure AD" (Entra ID) programos registraciją su OAuth2 autentifikacija. Administratorius sukuria programos registraciją, suteikia Mail.ReadWrite leidimus ir pateikia administratoriaus sutikimą. Jokių naudotojų slaptažodžių nereikia. Konfigūracijos procesas užtrunka maždaug 15 minučių ir seka tuos pačius šablonus, naudojamus kitų „Microsoft" sertifikuotų programų.
Platformai skirti vadovai
Dažnai užduodami klausimai
Ar tai žinoma „Microsoft" problema?
„Microsoft" oficialiai nedokumentuoja šios problemos kaip žinomo „Exchange" administravimo centro IMAP importo defekto. Palaikymo užklausos dėl šios datų problemos paprastai gauna apėjimo pasiūlymus (rūšiuoti pagal „Išsiųsta" datą), o ne taisymą. Problema yra standartinio „Exchange" transporto elgesio pasekmė, o ne importo funkcijos klaida.
Ar PowerShell gali pataisyti datas po importo?
Ne. „Exchange Online PowerShell" nepateikia cmdlet esamų pranešimų neapdorotam turiniui modifikuoti. Set-Mailbox ir susijusios cmdlet kontroliuoja dėžutės konfigūraciją, o ne individualių pranešimų antraštes. Taisymas reikalauja darbo lygiu, kurio PowerShell tiesiog neatskleidžia „Exchange Online".
Ar Redate.io veikia su hibridinėmis „Exchange" aplinkomis?
Taip. Redate.io veikia su bet kuria „Exchange Online" talpinta pašto dėžute, nepriklausomai nuo to, ar organizacija naudoja hibridinę „Exchange" konfigūraciją, ar ne. Taisymas taikomas „Exchange Online" pašto dėžutei ir nereikalauja prieigos prie vietinių „Exchange" serverių.
„Exchange" IMAP importas sugadino visų el. laiškų datas? Paleiskite nemokamą analizę su Redate.io ir identifikuokite paveiktus el. laiškus kiekvienoje dėžutėje bei atkurkite teisingas datas „Outlook", OWA ir visuose prijungtuose klientuose.