imapsync migrációs dátumok javítása a Microsoft 365-ben

A Microsoft 365-be történő migráció imapsync-kel észszerűen hangzik. Ingyenes, szkriptelhető és a legtöbb forgatókönyv esetén jól kezeli az IMAP-IMAP átviteleket. De a Microsoft 365-ön egyetlen részlet dönti el, milyen dátummal végzi minden e-mail.

Az Exchange Online megtartja a dátumot, amit megkap: amikor az imapsync egy üzenetet ír át IMAP-on, minden e-mail belső dátumát is átadja vele (a --syncinternaldates alapértelmezetten be van kapcsolva), és a másolat megtartja ezt a dátumot. Az imapsync azonban azt a dátumot adja át, amelyet a FORRÁS szerver tart nyilván az adott üzenethez, nem az e-mail elküldésének dátumát. Egy egészséges postafiókon a kettő megegyezik. Egy olyan postafiókon, amelyet már egyszer áttelepítettek vagy biztonsági mentésből állítottak vissza, a forrás tarthatja a korábbi művelet dátumát, és az imapsync ezt másolja át változatlanul.

Ez nem hiba a Microsoft 365-ben vagy az imapsyncben. Minden másolat hűen megőrzi a dátumot, amelyet kapott. Ha ez a dátum már a forrásnál is rossz volt, akár 500, akár 500 000 e-mailt migrál, minden érintett e-mail a korábbi művelet dátumát mutatja a beérkezés dátuma helyett.

Képzelje el, hogy elmondja az IT igazgatójának, hogy a hétvégén futtatott migráció épp most lapította egyetlen dátumra az e-mailek 6 éves történetét. Ez az a valóság, amellyel az adminisztrátorok szembesülnek egy imapsync migráció után a Microsoft 365-be. És a Google Workspace-től eltérően (ahol a Gmail webes felülete elkentheti a problémát), a Microsoft 365 mindenhol a rossz dátumot mutatja - Outlook asztali, OWA, Outlook mobil, Microsoft Search. Nincs kliensoldali menekülés.

A Microsoft 365-ben a kár teljes és látható. Minden kliens - Outlook Windowsra, Outlook Macre, OWA, Outlook mobil iOS-re és Androidra - a migrációs időbélyeget mutatja. A felhasználók nem tudnak dátum szerint rendezni, nem tudnak e-maileket kronológikusan megtalálni, nem bízhatnak a dátumtartomány szerint szűrt keresési eredményekben. Egy 80 000 e-mailt tartalmazó postafiók, amelyek mind "2024. november 12."-t mutatnak, a mindennapi munka számára funkcionálisan használhatatlan.

A megfelelőségi következmények még rosszabbak. Az Exchange Online Protection, a Microsoft Purview és a megőrzési szabályzatok mind a sérült kézbesítési időbélyeget indexelik. Egy 7 évnél régebbi e-mailek törlésére beállított megőrzési szabályzat a rossz dátummal működik - ami azt jelenti, hogy a 2018-as e-mailek, amelyeknek közeledniük kellene a törléshez, most úgy tűnnek, mintha 2024-ből származnának. A GDPR, HIPAA vagy SEC szabályozás alá eső szervezetek valós szabályozási kitettséggel néznek szembe, ha az e-mail-megőrzésük nem megbízható. És ha érkezik egy jogi zárolási kérelem "minden e-mailre a 2023 Q3-ból", a sérült dátumok azt jelentik, hogy a Purview semmit nem ad vissza - mert a metaadatok szerint abból az időszakból nem léteznek e-mailek.

A Redate.io csatlakozik a Microsoft 365-höz és alkalmazza fejléclánc-elemzését és dátum-metaadat-rekonstrukciós folyamatát minden érintett üzenetre. Nem kell tudnia, melyik eszköz végezte a migrációt: megtalálja azokat az e-maileket, amelyek megjelenített dátuma nem egyezik az eredeti dátumukkal. Minden üzenet egyedileg kerül javításra és ellenőrzésre, az eredetit biztonsági másolat mappában megőrizve. Nincs méretkorlát: egy 500 000 e-mailt tartalmazó postafiók ugyanúgy javítható, mint egy kisebb.