Исправление дат миграции CloudM в Microsoft 365
Почему миграции CloudM показывают неправильную дату в Microsoft 365
CloudM Migrate часто используется для переноса почтовых ящиков из Google Workspace, локального Exchange и других платформ в Microsoft 365. Когда CloudM загружает письма в Microsoft 365, транспортный конвейер Exchange Online обрабатывает каждое сообщение и добавляет заголовок Received с текущей меткой времени загрузки. Он становится самым последним заголовком Received в цепочке заголовков сообщения.
Microsoft 365 использует эту метку времени доставки во всей своей экосистеме. Outlook для рабочего стола, Outlook в Интернете, Outlook для мобильных устройств и даже функции искусственного интеллекта Microsoft - все ссылаются на одно и то же свойство PR_MESSAGE_DELIVERY_TIME, установленное из миграционного заголовка Received. В отличие от Google Workspace (где веб-клиент может маскировать проблему), Microsoft 365 последовательно отображает дату миграции во всех своих клиентских приложениях.
Последовательность неверной даты во всех приложениях Microsoft 365 делает проблему немедленно видимой для каждого пользователя. После миграции CloudM в Microsoft 365 вся организация видит один и тот же симптом: каждое письмо в каждом почтовом ящике выглядит как полученное в день миграции. Специфичного для клиента обходного пути не существует; повреждение дат встроено в метаданные сообщения на уровне сервера.
Как это влияет на Microsoft 365
Единая обработка дат Microsoft 365 означает, что дата миграции появляется везде одновременно. Outlook для рабочего стола, 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 индексирует правильную дату в дальнейшем.