Устранение неполадок GWMME

Причина проблемы может заключаться в следующем:

• Сервер Exchange не запущен.
• Проблема в сети блокирует соединение между клиентским компьютером и сервером Exchange. Для проверки соединения выполните команду ping с клиентского компьютера.
• Вы указали неверное имя для сервера Exchange или администратора. Для проверки этой информации:
  1. На клиентском компьютере нажмите «Панель управления» . Отправьте письмо , чтобы создать профиль Microsoft Outlook для учетной записи администратора, которую вы хотите использовать для миграции.
  2. В GWMME на экране Шаг 1 (Сведения о сервере):
     • В поле «Имя хоста/IP-адрес» введите имя хоста Exchange из профиля.
     • В поле «Имя пользователя администратора» введите имя пользователя из профиля.

При миграции с хостинг-сервера профиль учетной записи администратора должен использовать настройки по умолчанию для подключения к серверу. Подключение будет неудачным, если вы измените какие-либо настройки в Панели управления. Почта Имя профиля Характеристики Учетные записи электронной почты Имя профиля Изменить адрес электронной почты Дополнительные настройки .

Убедитесь, что вы ввели правильное имя пользователя и пароль администратора.

Если проблема сохраняется, убедитесь, что вы ввели правильное имя для сервера Exchange:

1. На клиентском компьютере нажмите «Панель управления» . Отправьте письмо , чтобы создать профиль Outlook для учетной записи администратора, которую вы хотите использовать для миграции.
2. В GWMME на экране Шаг 1 (Сведения о сервере):
   • В поле «Имя хоста/IP-адрес» введите имя хоста Exchange из профиля.
   • В поле «Имя пользователя администратора» введите имя пользователя из профиля.

Если GWMME аварийно завершает работу вскоре после запуска, убедитесь, что вы запускаете его на клиентском компьютере, а не на сервере Exchange. Запуск утилиты на сервере может привести к сбою. Для получения более подробной информации обратитесь к документации Microsoft.

Если вы считаете, что GWMME может аварийно завершать работу из-за проблем с балансировкой нагрузки, перейдите к разделу «Подготовка клиентских машин Windows» в руководстве администратора GWMME .

Иногда дополнительные процессы, запущенные на вашем компьютере (например, антивирусное ПО, поисковая система или программное обеспечение для резервного копирования), нарушают доступ GWMME к файлу базы данных во время миграции. Следующий код ошибки в ваших лог-файлах указывает на возникновение этой проблемы:

0x80040109
Fail:While stamping the message

Несмотря на то, что сообщения были перенесены, GWMME не сохранил информацию об успешной миграции. Если миграция запускается повторно с установленным флажком «Только новые данные» , GWMME попытается перенести эти сообщения снова. Сообщения не будут дублироваться, но могут дублироваться события календаря или контакты.

Если миграция для пользователя не удалась, проверьте следующее:

• Имя пользователя или SMTP-адрес в файле пользователей отформатированы корректно.
• Пользователь не скрыт в глобальном адресном списке (GAL).
• У пользователя есть учетная запись на сервере Exchange.
• Пользователь вошел в Google Workspace, принял Условия использования и завершил создание своей учетной записи Google Workspace.

Следующие шаги по устранению неполадок должны решить все проблемы с проверкой OAuth в GWMME:

• Убедитесь, что вы правильно авторизовали программное обеспечение для своего домена, как описано в разделе «Авторизация GWMME для вашей учетной записи» .
• Убедитесь, что имена пользователей и пароли Google Workspace, указанные в вашем CSV-файле, верны. Одна-единственная ошибка в CSV-файле может привести к неудачной миграции. Подробности см. в разделе «Создание CSV-файлов для миграции» .
• На компьютере, где вы запускаете GWMME, убедитесь, что системные часы установлены на правильное время. Если часы компьютера неверны, во время проверки OAuth на серверы Google отправляется неправильная локальная метка времени, что приводит к неудачной проверке. Синхронизируйте время на компьютере с интернет-серверами времени.
• Убедитесь, что учетная запись суперадминистратора Google Workspace, используемая для аутентификации в GWMME, действительна и имя пользователя правильно введено в конфигурации GWMME.

GWMME не создает учетные записи пользователей в Google Workspace. Создайте учетные записи пользователей Google Workspace до миграции данных.

В данном случае год в текущей дате машины был изменен на 2022, из-за чего сертификат кажется устаревшим. Текущую дату можно увидеть в начале каждой строки журнала, а даты « Valid from » и « Valid until » сертификата не совпадают с текущей датой. Флаг ошибки WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED указывает на то, что проверка отзыва сертификата прошла неудачно.

Также вы можете просмотреть целевой IP-адрес и разрешенное имя хоста после строки " Network connection destination details " в последней строке журнала. Это 1e100.net address , что означает, что это Google.

2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2025 ()> Secure connection failure. Status: 0x00010000. Info 0x00000009
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2030 ()> Failure details:
WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable.
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA: The function is unfamiliar with the Certificate Authority that generated the server's certificate.
Certificate details:
---Validity--
Valid from: 2016-09-20T04:08:45.000Z
Valid until: 2022-09-20T04:08:45.000Z
---Subject---
Created by http://www.fiddler2.com
DO_NOT_TRUST
*.google.com
---Issuer----
Created by http://www.fiddler2.com
DO_NOT_TRUST
DO_NOT_TRUST_FiddlerRoot
-------------
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2071 ()> Error result 5, hr = 0x80072f8f. Setting event 0000000000001638.
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2076 ()> Network connection destination details: 127.0.0.1:8888 (COMPUTERNAME)

В данном случае Fiddler был установлен и настроен на расшифровку HTTPS (то есть использовал собственный сертификат), но его сертификат был удален из списка доверенных сертификатов Windows , поэтому он считается недоверенным. Обратите внимание, что, поскольку Fiddler является прокси-сервером, он подключался к 127.0.0.1, а не к Google. В списке ошибок присутствует флаг WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA , что означает, что система не доверяет центру сертификации (CA). Также обратите внимание, что Google не выдавал этот сертификат.

На экране вывода или в файле журнала трассировки появляется сообщение об ошибке, аналогичное этому:

E:Generic ExchangeMigration!SetPropertyGuid @ 641 (user@example.com)> Failed with 0x80070005, last successful line = 637.

Эта проблема обычно возникает из-за учетных записей пользователей, не имеющих необходимых разрешений. Для ее решения убедитесь, что вы предоставили учетным записям разрешение «Получать от имени» в Exchange.

Если у учетных записей есть разрешение «Получить от имени» , и ошибка сохраняется, возможно, в вашей среде Exchange требуется, чтобы у учетных записей пользователей также было разрешение «Отправить от имени» .

Некоторые пользователи не могут выполнить миграцию с Exchange 2010, и в файле журнала трассировки появляются ошибки "Сбой с кодом 0x80004005". В журналах также присутствуют следующие записи:

• Случайные вызовы MAPI к Exchange 2010.
• В журнале доступа клиентов к удаленным вызовам процедур ( RPC ) на сервере клиентского доступа Exchange Server 2010 появляются ошибки " BufferTooSmall ".

Это известная проблема Exchange 2010, Outlook 2007 и Outlook 2010. Возможно, вам потребуется обновить Exchange до SP2 RU3. Для получения дополнительной информации обратитесь к документации Microsoft по ошибкам сбоя вызова MAPI.

Если в журналах часто встречаются ошибки HTTP с кодами 500, 502 и 503, а сообщения не загружаются с кодом ошибки 0x8004106a , возможно, проблема связана с целевым почтовым ящиком. Обычно это происходит из-за высокой нагрузки.

Для решения проблемы убедитесь, что целевой почтовый ящик не используется интенсивно. Вы можете:

• Отключите все клиенты синхронизации (например, IMAP, POP, мобильные устройства и почтовые клиенты).
• Переносите сообщения только из одного источника за раз.

Следующие проблемы указывают на то, что ваши пользователи были зарегистрированы некорректно:

• Изменения в событии календаря не сообщаются участникам.
• Уведомления и обновления календаря не отображаются в календарях участников.

Перед миграцией учетных записей обязательно создайте учетные записи всех пользователей в Google Workspace — даже если вы планируете частичную миграцию. Убедитесь, что добавлены все псевдонимы и никнеймы доменов. Затем, чтобы решить проблему, удалите и создайте заново все события, в которых пользователь выступает в роли организатора или гостя.

По умолчанию GWMME переносит данные со скоростью 25 пользователей в секунду. Эта скорость превышает количество запросов в секунду (QPS) по умолчанию как для API контактов, так и для API календаря.

Для решения проблемы выполните миграцию контактов и календарей:

• Отдельно от миграции электронной почты.
• При более низкой скорости 4–8 пользователей в секунду.

Если некоторые сообщения не переносятся, это может означать, что они превышают лимит размера, установленный Gmail. Или же они могут содержать типы вложений, заблокированные Gmail. Подробнее см. раздел «Типы файлов, заблокированные в Gmail» .

Возможно, вам также потребуется снять ограничения на размер папок и убедиться, что папки отображаются в режиме IMAP. Подробности см. в разделе «Включение и выключение POP и IMAP для пользователей» .

Google Workspace оценивает количество сообщений в вашем почтовом ящике после миграции. Точное количество не указывается. Число сообщений, отображаемое в вашем почтовом ящике Gmail, может отличаться от числа сообщений в вашем старом почтовом ящике.

Если вы считаете, что некоторые сообщения отсутствуют, проверьте следующее:

• Размер сообщения, включая вложения, не должен превышать 25 МБ. Перенести сообщения размером более 25 МБ невозможно. Подробности см. в разделе «Отправка вложений вместе с сообщением Gmail» .
• Gmail не блокирует вложения к сообщению. Gmail блокирует определенные типы вложений, например, исполняемые файлы. Подробнее см. раздел «Типы файлов, заблокированные в Gmail» .
• Сообщение находится в папке или в диапазоне дат, относящихся к процессу миграции.

При миграции файлов Exchange или PST могут возникать ситуации, когда отсутствуют сообщения или сообщения перенесены с некорректным отправителем или получателем. SMTP-адрес отправителя или получателя сообщения может отсутствовать, и вместо него используется адрес Exchange X.500. Это может произойти, если не создан профиль глобального адресного списка (GAL) или пользователь был удален из GAL.

Что происходит, когда GWMME обнаруживает адрес X.500?

Когда GWMME обнаруживает адрес X.500, он ищет зарегистрированный на сервере миграции почтовый профиль MAPI, соответствующий имени организации X.500 Exchange. Если такой профиль найден, GWMME определяет адрес X.500, используя данные из адресной книги, зарегистрированные в почтовом профиле MAPI.

Если GWMME не находит эту информацию в адресной книге Exchange, он пытается преобразовать адрес X.500 в адрес SMTP. Для этого он учитывает последнее значение CN адреса X.500 и использует его в качестве имени пользователя для адреса электронной почты. Например, адрес X.500 /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS приводит к получению адреса электронной почты SMTP ex_alias@example.com.

Как использовать адресную книгу Exchange для разрешения адреса X.500

1. Создайте почтовый профиль MAPI (без кэширования) на сервере, выполняющем миграцию.
2. Убедитесь, что почтовый профиль MAPI настроен на сервере, используемом для миграции PST-файлов.
3. Для корректного определения получателей с помощью глобального списка адресов (GAL) почтовый профиль MAPI должен быть подключен к исходному серверу Exchange.
4. Настройте почтовый профиль MAPI, используя учетную запись пользователя или службы, которая в данный момент авторизована, чтобы избежать ошибок аутентификации.

Важное примечание

Проверьте и убедитесь, что миграция настроена правильно. Если проблема сохраняется, повторная миграция не обновит данные, уже перенесенные в ваши учетные записи Google. Удалите данные электронной почты, переместите их в корзину, а затем выполните повторную миграцию.

В перенесенных сообщениях может отображаться дата и время миграции , а не время и дата исходного сообщения.

Вероятнее всего, это происходит потому, что заголовок даты исходного сообщения не соответствует стандарту RFC 5322. Если заголовок даты в сообщении отформатирован неправильно, Gmail применяет к сообщению время и дату миграции.

Это происходит при импорте событий для пользователей, которые не являются первоначальными организаторами или участниками мероприятия.

Несмотря на предупреждение, событие успешно переносится в Google Workspace, и целевой пользователь Google Workspace отображается как участник события в календаре Google. Это необходимо, поскольку Календарь не поддерживает отображение событий календаря для пользователя, который не является организатором или участником.