Коригиране на датите от миграция с CloudM в Microsoft 365
Защо миграциите с CloudM показват грешна дата в Microsoft 365
CloudM Migrate се използва често за миграция на пощенски кутии от Google Workspace, локален Exchange и други платформи в Microsoft 365. Когато CloudM качва имейли в Microsoft 365, транспортният конвейер на Exchange Online обработва всяко съобщение и добавя хедър Received с текущия времеви печат на качването. Той става най-новият хедър Received във веригата от хедъри на съобщението.
Microsoft 365 използва този времеви печат на доставка в целия си екосистем. Outlook desktop, Outlook в уеб, Outlook мобилен и дори AI функциите на Microsoft - всички препращат към едно и също свойство PR_MESSAGE_DELIVERY_TIME, което се задава от миграционния хедър Received. За разлика от Google Workspace (където уеб клиентът може да прикрие проблема), Microsoft 365 показва датата на миграцията последователно във всичките си клиентски приложения.
Последователността на грешната дата във всички клиенти на Microsoft 365 прави проблема незабавно видим за всеки потребител. След миграция с CloudM в Microsoft 365 цялата организация вижда един и същ симптом: всеки имейл във всяка пощенска кутия изглежда сякаш е получен в деня на миграцията. Няма специфично за клиента решение; повредата на датите е вградена в метаданните на съобщението на ниво сървър.
Как това засяга Microsoft 365
Унифицираното обработване на дати в Microsoft 365 означава, че датата на миграцията се появява навсякъде едновременно. Outlook desktop, OWA, Outlook мобилен, интеграцията на имейл в Teams и Microsoft Search - всички показват грешна дата на получаване. Потребителите не могат да избегнат неправилните дати, като преминат към друго приложение на Microsoft 365.
За администраторите на Microsoft 365 въздействието се разпростира върху инструментите за управление и съответствие. Exchange Admin Center, Microsoft Purview (преди Compliance Center) и eDiscovery Premium индексират съобщенията по повредената дата на доставка. Търсенията на съдържание за имейли в определен диапазон от дати връщат неправилни резултати. Етикетите за съхранение, прилагани автоматично на базата на възрастта на съобщението, работят по грешна хронология, потенциално причинявайки преждевременно изтриване или неограничено съхранение на съобщения, които е трябвало да бъдат обработени различно.
Често задавани въпроси
CloudM предлага ли опция за предотвратяване на повредата на датите по време на миграция в M365?
CloudM запазва оригиналния хедър Date, но целевият сървър (Exchange Online) добавя свой собствен хедър Received по време на качването на съобщението. Това е поведение на сървърната страна, което миграционните инструменти не могат да предотвратят. Единственото решение е коригиране на датите след миграцията.
Инструментите за администриране на Microsoft 365 могат ли да поправят датите?
Не. Microsoft 365 не предоставя вградени инструменти за модифициране на хедърите Received или времето на доставка на съществуващи съобщения. Redate.io е проектиран специално за този проблем: премахва миграционния хедър и повторно вмъква имейла с правилен INTERNALDATE.
Поправката постоянна ли е в Microsoft 365?
Да. След като Redate.io коригира имейла, оригиналното съобщение (с грешна дата) се премества в етикет за резервно копие. Коригираното съобщение има правилните хедъри Received и INTERNALDATE, и Microsoft 365 индексира правилната дата занапред.