Pataisykite imapsync migracijos datas Microsoft 365

Migracija i Microsoft 365 su imapsync skamba protingai. Jis nemokamas, skriptuojamas ir gerai tvarko IMAP-i-IMAP perkelimus daugelyje scenarijų. Bet Exchange Online nera "daugelis scenarijų."

Exchange Online IMAP tinklų sajas yra suderinamumo sluoksnis, pritvirtintas prie sistemos, suprojektuotos aplink EWS ir MAPI. Kai imapsync stumia pranešimą per šį tinklų saję standartiniu pašto persiuntimo protokolu, pranešimas patenka i pilną Exchange Online transporto grandine - tą pačią grandine, kuri apdoroja gaunama pašta iš interneto. Ta grandine prideda transporto antraštes, vykdo duomenu praradimo prevencijos patikras, taiko atitikties taisykles ir uždeda naują Received antrašte su tiksliu momentu, kai pranešimas pasieeke serveri. Veliavele --syncinternaldates? Exchange Online transporto grandine ja ignoruoja. INTERNALDATE perrašoma, kad atitiktu pristatymo laiko žyme.

Tai nera klaida, kurią Microsoft planuoja taisyti. Taip veikia Exchange Online architektura. Transporto grandine kiekvieną siuntimą standartiniu pašto persiuntimo protokolu traktuoja kaip naują pranešimo pristatymą, taškas. Nesvarbu, ar migruojate 500, ar 500 000 el. laišku, kiekvienas gauna tą pačią migracijos datą, ištemplituotą antraštese ir metaduomenyse.

Isivaizduokite, kaip sakote savo IT direktoriui, kad migrracija, kurią paleidote savaitgali, ka tik sulygino 6 metus el. pašto istorijos i vieną datą. Tai realybe, su kuria susiduria administratoriai po imapsync migracijos i Microsoft 365. Ir skirtingai nei Google Workspace (kur Gmail žiniatinklio klientas gali paslepssti problemą), Microsoft 365 rodo neteisingą datą visur - Outlook darbalaukyje, OWA, Outlook mobiliojoje programoje, Microsoft Search. Nera jokios išeities iš kliento puses.

Microsoft 365 žala yra visiška ir matoma. Kiekvienas klientas - Outlook Windows, Outlook Mac, OWA, Outlook mobilusis iOS ir Android - rodo migracijos laiko žymę. Naudotojai negali rušiuoti pagal datą, negali rasti el. laišku chronologiškai, negali pasitiketi paieškos rezultatais, filtruotais pagal datu intervalą. Pašto dežute su 80 000 el. laišku, kurie visi rodo "2024 m. lapkričio 12 d.", yra funkcinai sugedusi kasdieniam darbui.

Atitikties pasekmes yra blogesnes. Exchange Online Protection, Microsoft Purview ir saugojimo politikos visos indeksuoja pažeistą pristatymo laiko žymę. Saugojimo politika, nustatyta trinti el. laiškus senesnius nei 7 metu, veikia su neteisinga data - tai reiškia, kad el. laiškai iš 2018 m., kurie turetu arteti prie trynimo, dabar atrodo esą iš 2024 m. Organizacijos, kurioms taikomas BDAR, HIPAA ar SEC reguliavimas, susiduria su realiu reguliaciniu pavojumi, kai ju el. pašto saugojimas nera patikimas. O jei gaunamas teisinis sulaikymo prašymas del "visu el. laišku iš Q3 2023", pažeistos datos reiškia, kad Purview negraažina nieko - nes pagal metaduomenis iš to laikotarpio el. laišku neegzistuoja.

Redate.io jungiasi prie Microsoft 365 ir taiko savo antraščiu grandinės analizę ir datos metaduomenu rekonstrukcijos procesą kiekvienam paveiktam pranešimui. Šablonu atpažinimas pagal imapsync specifines migracijos signaturas identifikuoja, kurios Received antraštes buvo idetos migracijos metu, o kurios priklauso originaliai pristatymo grandinei. Kiekvienas pranešimas taisomas ir tikrinamas individualiai, o originalas saugomas atsargines kopijos aplanke. Enterprise planas apdoroja pašto dežutes iki 100 000 el. laišku, o administratoriai gali apdoroti kelias pašto dežutes iš vieno valdymo skydelio.