iCloud Office 365 migratsiooni katkised kuupäevad

Migratsioonistsenaarium, mis lõhub kuupäevad iga kord

Olete just lõpetanud iCloud Maili ülekande Office 365-i. E-kirjad on olemas, kaustad on paigas, kõik näib täiuslik. Esmaspäeva hommikul tuleb esimene kaebus: "Kõik minu vanad kirjad näitavad tänast kuupäeva." Siis teine. Siis kümme.

See ei ole üksikviga. iCloud Maili migreerimine Office 365-i on üks enim dokumenteeritud e-kirjade kuupäevakorruptsiooni stsenaariume, ja seda väga konkreetsete tehniliste põhjuste tõttu, mis tulenevad nii Apple Maili käitumisest, IMAP-protokollist kui ka sellest, kuidas Microsoft 365 sissetulevaid sõnumeid töötleb.

Miks iCloud Office 365-i migratsioon kuupäevad lõhub

Probleemi mõistmiseks tuleb eristada kolme asja, mida paljud inimesed (sealhulgas kogenud IT-administraatorid) omavahel segamini ajavad: päis Date:, IMAP INTERNALDATE ja faili loomise kuupäev.

Päis Date: (RFC 2822)

Iga e-kiri sisaldab päist Date:, mis näitab, millal sõnum saadeti. See päis on osa sõnumi töötlemata sisust ja ei muutu kunagi, vähemalt teoreetiliselt. See on "algne" kuupäev sõna otseses tähenduses.

IMAP INTERNALDATE

IMAP-protokoll (määratletud RFC 3501-s) seob iga sõnumiga eraldi metaandme nimega INTERNALDATE. Enamik meiliklientidest kasutab just seda väärtust postkastis sõnumite sortimiseks ja kuvamiseks, mitte päist Date:. Outlook toetub eriti tugevalt INTERNALDATE-ile nii kuvamisel kui sortimisel.

Probleem? Kui migratsioonitööriist kopeerib e-kirja ühelt IMAP-serverilt teisele, peaks see ideaaljuhul säilitama INTERNALDATE-i. Praktikas ei juhtu see alati nii.

Apple Maili eriline käitumine

Apple Mail kasutab iCloudist sõnumeid sünkroonides mõnikord serveri poolel faili loomise kuupäeva INTERNALDATE-i alusena. See ei ole otseselt viga, vaid IMAP-spetsifikatsiooni tõlgendus, mis erineb teiste klientide lähenemisest. (Muide, kui olete kunagi püüdnud INTERNALDATE-i probleemi siluda töötlemata IMAP RFC-sid lugedes, teate et spetsifikatsioon jätab selles küsimuses tõlgendamiseks üsna laia ruumi.)

Tulemus: kui ekspordite või migreerite iCloudist Apple Maili kaudu, võivad sõnumite INTERNALDATE-id olla juba valed enne, kui need Office 365-i jõuavad.

Kolm iCloudi migratsioonimeetodit ja nende lõksud

Otsene IMAP-migratsioon

Kõige levinum meetod on seadistada iCloud IMAP-allikaks ja Office 365 sihtkohaks, seejärel kasutada migratsioonitööriista (imapsync, MigrationWiz või mõni oma lahendus). Tööriist ühendub mõlema serveriga ja kopeerib sõnumid.

Probleem on kahekordne. Esiteks on Apple IMAP-serveritel läbilaskepiirangud, mis sunnivad tööriistu pause tegema, luues ajaaknad, kus ühendused sulguvad ja avanevad uuesti, mis võib tekitada võõraid INTERNALDATE-väärtusi. Teiseks saab iga Exchange Online'i kaudu IMAP APPEND käsuga kopeeritud sõnum vaikimisi lisamishetke kuupäeva, välja arvatud juhul, kui tööriist edastab sisestuskäsus sõnaselgelt algse INTERNALDATE-i.

Mõned tööriistad teevad seda korralikult. Teised mitte järjepidevalt. Ja 40 000 sõnumiga postkastis tähendab isegi 2-protsendiline veamäär 800 valet kuupäeva.

imapsync-migratsioonide kohta vaata ka: imapsync kuupäevade parandamine Microsoft 365-s.

.mbox või .eml eksport ja seejärel import

Mõned kasutajad ekspordivad oma iCloudi kirjad Apple Maili kaudu .mbox-vormingus, seejärel proovivad neid Outlooki importida. See on käsitsi meetod, mis annab ebaühtlaseid tulemusi.

Vorming .mbox kodeerib e-kirjad tekstsõnumite jadana. Kuupäevad on olemas üksikutes päistes Date:, kuid sõnumite vaheline eraldajarea ("From ") sisaldab kuupäeva, mida mõned importijad tõlgendavad loomise kuupäevana. Outlook kasutab .mbox-faili .pst-i teisendades importimisel mõnikord seda eraldajareas olevat kuupäeva, mitte sõnumi enda päist Date:.

Lohistamine Outlooki kaudu

See on meetod, mis tekitab kõige rohkem kahju. Kasutaja seadistab mõlemad kontod Outlookis (iCloud ja Office 365), seejärel lohistab sõnumid ühest kaustast teise. Tundub lihtne. Kuupäevade jaoks on see katastroof.

Kui Outlook lohistab kahe IMAP-konto vahel sõnumi, loob see tegelikult uue .EML-faili, lisab selle sihtkontas olevasse kontosse ja kustutab originaali. See uus fail pärib Windows-faili loomise kuupäeva, mis on täpselt lohistamise hetk. Algne päis Date: on sõnumi sisus endiselt olemas, kuid Exchange Online'i serverisse salvestatud INTERNALDATE vastab manipulatsiooni kuupäevale. Outlook kuvab seejärel kõikide teisaldatud sõnumite jaoks selle migratsioonikuupäeva.

Täpsuse huvides olgu öeldud, et see käitumine varieerub Outlooki versiooni järgi. Alates 2023. aasta sügise Outlooki uuendusest on käitumine teatud stsenaariumide puhul veidi paranenud, kuid kontode vaheline lohistamine on jätkuvalt dokumenteeritud kuupäevakorruptsiooni allikas.

Mida Office 365 ja Outlook lõpuks kuvavad

Exchange Online salvestab e-kirjad koos nende INTERNALDATE-iga. Outlook Desktop loeb seda INTERNALDATE-i, et kuvada kuupäev veerus "Vastu võetud" ja sortida postkasti. Kui INTERNALDATE kirjutati migratsiooni käigus üle, kuvab Outlook migratsioonikuupäeva, punkt.

Outlook Web App (OWA) teeb sama. Puudub "alternatiivne vaade", mis näitaks algset päise Date: kuupäeva. See, mida näete kuupäevaveerus, on INTERNALDATE.

Algne päis Date: on endiselt olemas, täiuslik ja loetav, kui kuvate sõnumi töötlemata päised. Kuid ükski tavaline kuvamine seda ei näita. See ongi selle probleemi põhiline frustratsioon: õige informatsioon on olemas, see on lihtsalt tehnilise paranduseta kättesaamatu.

Mida Microsofti tugi ei lahenda

Kui avate selle probleemi tõttu Microsofti toe juures pileti, saate tõenäoliselt järgmist: kinnituse, et kuvatud kuupäevad vastavad salvestatud INTERNALDATE-idele, soovituse kontrollida Outlooki sortimissätteid ja vajaduse korral suunamise teie kasutatud migratsioonitööriista juurde.

See ei ole pahatahtlikkus. Microsoftil lihtsalt ei ole natiivset tööriista Exchange Online'i juba sisestatud tuhandete sõnumite INTERNALDATE-ide tagasiulatuvaks parandamiseks. Parandamiseks on vaja pääseda igale sõnumile eraldi ligi, analüüsida nende päiseid ja rekonstrueerida kuupäeva metaandmed, mis jääb väljapoole standardse toe toimingute piiri.

iCloudi tugi omalt poolt leiab, et sõnumid eksporditi korrektselt ja probleem on sihtkoha poolel. Mõlemad tugitiimid veeretavad vastutust teisele ja kasutaja jääb 12 000 migratsioonikuupäevaga kirjaga.

Mahu probleem

Mõista, miks kuupäevad on katki, on üks asi. Neid käsitsi tootmispostkastis parandada on hoopis teine asi.

Mõned IT-administraatorid üritavad parandust skriptida. Põhiidee pole keeruline kontseptualiseerida, kuid teostus reaalsetel mahtudel tekitab probleeme, millega kodutehtud skriptid halvasti toime tulevad:

• S/MIME-allkirjastatud või PGP-ga krüpteeritud e-kirju ei saa muuta ilma krüptograafilist allkirja kehtetuks muutmata
• Keeruliste multipart/alternative struktuuridega sõnumid (HTML + lihttekst + pesastatud manused) on manipuleerimiseks haprad
• Mitte-ASCII-s kodeeritud päised (RFC 2047, eriti jaapani, araabia või kirillitsa tähtede puhul) võivad rikkuda tööriistad, mis neid kodeeringuid korralikult ei käsitle
• Microsoft Graph API kvoodid ja Exchange Online'i läbilaskepiirangud (viga 429 Too Many Requests) peatavad skriptid, mis pole loodud eksponentsiaalse tagasiootamise haldamiseks
• Skript, mis töötab korralikult 500 testkirjaga, peatub kell 3 öösel 8000. sõnumi juures päris postkastis, ilma taastamismehhanismita

Ja küsimus, mis tapab: kuidas kontrollida, et iga parandatud e-kiri on pärast parandust terviklik? Et manus on ikka olemas? Et arutelulõng ei ole katki? Kodutehtud skript seda kontrolli üldjuhul ei tee.

Kuidas Redate.io töötleb iCloudi migratsioone Office 365-i

Redate.io ühendub Office 365-iga otse Microsoft 365 (Azure AD) õiguste kaudu, ilma iCloudi serveritele ligipääsu vajamata. E-kirjad on juba Exchange Online'is, kui Redate tööle hakkab.

Redate'i parandusmootoril on mitmeastmeline analüüsijada, mis töötleb iga sõnumi päiseahelat, et tuvastada algne kuupäev. See eristab migratsiooni käigus lisatud päiseid Received: õigustatud kuupäeva metaandmetest. Analüüs hõlmab mustrite sobitamist sadade teadaolevate migratsioonitööriistade signatuuridega, mis võimaldab tuvastada võõrad päised ka siis, kui need pole kohe ilmsed.

Iga parandatud e-kiri kontrollitakse pärast töötlemist eraldi. Originaalid säilitatakse nähtavas varunduskaustas 30 päeva jooksul, mida ükski kodutehtud skript vaikimisi ei tee. Esialgne skannimine on tasuta ja võimaldab täpselt kvantifitseerida mõjutatud kirjade arvu enne parandamise otsust.

Redate toetab ka Google Workspace'ist Office 365-i migratsioone ning cPaneli migratsioonijärgseid parandusi. Vaata näiteks: e-kirjade kuupäevade parandamine pärast Microsoft 365 migratsiooni või valed kuupäevad pärast Exchange Online'i migratsiooni.

Esmalt skannimine, siis parandamine

Soovitatav lähtepunkt iga iCloudist Office 365-i migratsiooni puhul, mis on tekitanud valesid kuupäevi: käivitage Redate.io tasuta skann mõjutatud postkastidel. Skann tuvastab täpselt, kui paljudel e-kirjadel on kahtlane INTERNALDATE ja millistest kaustadest need leitud on.

See võtab mahust sõltuvalt 12 kuni 45 minutit ning annab selge pildi probleemi ulatusest enne mis tahes sekkumist. MSP-de jaoks, kes haldavad pärast migratsiooni korraga mitut postkasti, välistab see partiiskann vajaduse parandada postkaste, mis seda ei vaja.

Kui teie e-kirjade kuupäevad on pärast iCloudist migratsiooni valed, alustage Redate.io tasuta skannimisega, et mõõta probleemi ulatust oma Office 365 postkastides.