Коригиране на датите от миграция с CloudM в Google Workspace
Защо миграциите с CloudM показват грешна дата в Google Workspace
CloudM Migrate е предпочитаният миграционен инструмент за организации, преминаващи към Google Workspace, особено от среди Microsoft Exchange. CloudM използва Gmail API за вмъкване на имейли в целевия акаунт на Google Workspace. Въпреки че Gmail API позволява задаване на INTERNALDATE по време на вмъкването, действителното поведение зависи от обработката на сървърната страна и миграционният хедър Received все пак се добавя към имейла.
Начинът, по който Google Workspace обработва датите, създава объркваща ситуация. Уеб интерфейсът на Gmail обикновено чете оригиналния хедър Date за показване, така че имейлите може да се показват с правилни дати в браузъра. Въпреки това всеки IMAP клиент, свързан с акаунта на Google Workspace, чете INTERNALDATE, който отразява времевия печат на миграцията. Потребителите, достъпващи чрез Outlook, Apple Mail или Thunderbird, свързани чрез IMAP, виждат датата на миграцията на всяко съобщение.
За ИТ екипите, управляващи миграции в Google Workspace с CloudM, това разделено поведение затруднява диагностицирането на проблема. Потребителите на Gmail в уеб не съобщават за проблеми, докато потребителите на десктоп клиенти съобщават, че всеки имейл има една и съща дата. Несъответствието води до времеемко отстраняване на грешки и забавено разрешаване, докато администраторите се опитват да установят дали проблемът е в клиента, миграционния инструмент или пощенския сървър.
Как това засяга Google Workspace
Средите на Google Workspace, където потребителите се свързват както чрез Gmail в уеб, така и чрез IMAP клиенти, изпитват разминаване на датите, което объркващо и за потребителите, и за администраторите. Gmail в уеб показва датите правилно, но Outlook и Apple Mail, свързани чрез IMAP, показват датата на миграцията. Това двойно поведение на датите продължава неограничено, докато не бъде коригиран основният INTERNALDATE.
Административните инструменти на Google Workspace и отчетността също препращат към INTERNALDATE. Политиките за съхранение на имейли, конфигурирани в Google Admin Console, задържанията на Google Vault за юридическо съответствие и DLP инструментите на трети страни, интегриращи се с Google Workspace чрез IMAP - всички използват времевия печат на миграцията вместо оригиналната дата. Организациите, разчитащи на Google Workspace за регулаторно съответствие, установяват, че техните политики за съхранение и задържане работят върху неправилна информация за дати, потенциално излагайки ги на юридически риск.
Често задавани въпроси
CloudM знае ли за този проблем с датите при миграция в Google Workspace?
Проблемът с датите е известен страничен ефект от IMAP-базираната миграция на имейли, а не бъг в CloudM. CloudM запазва оригиналния хедър Date, но IMAP INTERNALDATE се задава от приемащия сървър по време на качването. Това е присъщо на начина, по който пощенските сървъри обработват входящите съобщения.
Може ли Redate.io да поправи датите за цяла организация Google Workspace?
Да. С делегиране на ниво домейн, конфигурирано чрез Service Account на Google Workspace, Redate.io може да сканира и поправя пощенски кутии в целия домейн. Администраторите могат да обработят всички засегнати пощенски кутии от един контролен панел.
Поправянето на дати ще наруши ли работата на потребители, работещи в момента в Gmail?
Не. Redate.io обработва имейлите във фонов режим. Коригираното съобщение замества оригинала безпроблемно. Потребителите може да забележат, че датите се променят на правилните стойности в IMAP клиентите им, но няма прекъсване на работата в Gmail в уеб.