Прямая миграция в Microsoft 365 с помощью PowerShell

  • Статья

Эта статья относится к Microsoft 365 корпоративный и Office 365 корпоративный.

Вы можете перенести содержимое почтовых ящиков пользователей из исходной почтовой системы в Microsoft 365 сразу с помощью прямой миграции. В этой статье описаны задачи, которые выполняются при прямой миграции электронной почты с помощью Exchange Online PowerShell.

Просмотрите раздел Что вам нужно знать о прямой миграции электронной почты в Microsoft 365, вы можете получить общие сведения о процессе миграции. Ознакомившись с содержимым этой статьи, начните переносить почтовые ящики из одной почтовой системы в другую, руководствуясь приведенными в этой статье сведениями.

Примечание.

Вы также можете использовать Центр администрирования Exchange для выполнения прямой миграции. См . раздел Выполнение прямой миграции электронной почты в Microsoft 365.

Что нужно знать перед началом работы

Предполагаемое время выполнения этой задачи: 2–5 минут для создания пакета миграции. После запуска пакета миграции продолжительность миграции будет зависеть от количества почтовых ящиков в пакете, размера каждого почтового ящика и доступной пропускной способности сети. Сведения о других факторах, влияющих на продолжительность миграции почтовых ящиков в Microsoft 365, см. в статье Производительность миграции.

Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Сведения о необходимых разрешениях см. в записи "Миграция" в таблице раздела Разрешения получателей .

Чтобы использовать командлеты Exchange Online PowerShell, вам необходимо войти в систему и импортировать командлеты в локальный сеанс Windows PowerShell. Инструкции см. в разделе Подключение к Exchange Online PowerShell.

Полный список команд миграции см. в статье Командлеты перемещения и миграции.

Шаги миграции

Шаг 1. Подготовка к прямой миграции

  • Добавьте локальную организацию Exchange в качестве принятого домена организации Microsoft 365. Служба миграции использует SMTP-адрес локальных почтовых ящиков для создания идентификатора пользователя и адреса электронной почты microsoft Online Services для новых почтовых ящиков Microsoft 365. Миграция завершится ошибкой, если домен Exchange не является принятым доменом или основным доменом вашей организации Microsoft 365. Дополнительные сведения см. в разделе Проверка домена.

  • Настройте Outlook Anywhere на локальном сервере Exchange Server. Служба миграции электронной почты использует RPC через HTTP или Outlook Anywhere для подключения к локальному серверу Exchange Server. Сведения о настройке Outlook Anywhere для Exchange 2010, Exchange 2007 и Exchange 2003 см. в следующих статьях:

  • Проверьте возможность подключения к организации Exchange с помощью мобильного Outlook. Проверьте настройки подключения с использованием следующих способов.

    • Подключитесь к локальному почтовому ящику Exchange с помощью Microsoft Outlook из-за пределов корпоративной сети.

    • Проверьте настройки подключения с помощью анализатора удаленного подключения Exchange корпорации Майкрософт. Используйте средства мобильного Outlook (RPC через HTTP) или проверки автообнаружения Outlook.

    • В Exchange Online PowerShell выполните следующие команды.

    $Credentials = Get-Credential

    Test-MigrationServerAvailability -ExchangeOutlookAnywhere -Autodiscover -EmailAddress <email address for on-premises administrator> -Credentials $credentials

  • Назначьте для локальной учетной записи необходимые разрешения на доступ к почтовым ящикам в организации Exchange. Учетная запись локального пользователя, используемая для подключения к локальной организации Exchange (также называемой администратором миграции), должна иметь необходимые разрешения для доступа к локальным почтовым ящикам, которые требуется перенести в Microsoft 365. Эта учетная запись пользователя необходима для создания конечной точки миграции в вашей локальной организации.

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

    • Администратор миграции должен быть членом группы Администраторы домена в службе каталогов Active Directory локальной организации.

      Или

    • Администратор миграции должен иметь разрешение FullAccess для всех локальных почтовых ящиков.

      Или

    • Администратор миграции должен иметь разрешение Получить как в локальной базе данных, где хранятся почтовые ящики пользователей.

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

  • Группы безопасности и делегаты Служба миграции электронной почты не может определить, являются ли группы локальная служба Active Directory группами безопасности, поэтому она не может подготавливать перенесенные группы как группы безопасности в Microsoft 365. Если вы хотите иметь группы безопасности в клиенте Microsoft 365, сначала необходимо подготовить пустую группу безопасности с поддержкой почты в клиенте Microsoft 365, прежде чем начинать прямую миграцию. Кроме того, при этом способе перемещаются только почтовые ящики, почтовые пользователи, контакты и группы с поддержкой электронной почты. Если какой-либо другой объект Active Directory, например пользователь, не перенесенный в Microsoft 365, назначен в качестве руководителя или делегата переносимому объекту, он должен быть удален из объекта перед миграцией.

Шаг 2. Создание конечной точки миграции

Чтобы успешно перенести электронную почту, Microsoft 365 необходимо подключиться к исходной почтовой системе и связаться с ней. Для этого Microsoft 365 использует конечную точку миграции. Чтобы создать конечную точку миграции мобильного Outlook для прямой миграции, сначала подключитесь к Exchange Online.

Полный список команд миграции см. в статье Командлеты перемещения и миграции.

В Exchange Online PowerShell выполните следующие команды.

$Credentials = Get-Credential

В примере используется командлет Test-MigrationServerAvailability, который получает и проверяет параметры подключения к локальному серверу Exchange, а затем использует эти параметры для создания конечной точки миграции CutoverEndpoint.

$TSMA = Test-MigrationServerAvailability -ExchangeOutlookAnywhere -Autodiscover -EmailAddress administrator@contoso.com -Credentials $credentials

New-MigrationEndpoint -ExchangeOutlookAnywhere -Name CutoverEndpoint -ConnectionSettings $TSMA.ConnectionSettings

Примечание.

С помощью командлета New-MigrationEndpoint и параметра -TargetDatabase можно указать базу данных, которая будет использоваться службой. В противном случае база данных назначается случайным образом на сайте Службы федерации Active Directory (AD FS) 2.0, на котором расположен почтовый ящик управления.

Проверка работы

В Exchange Online PowerShell выполните следующую команду, чтобы отобразить сведения о конечной точке миграции CutoverEndpoint.

Get-MigrationEndpoint CutoverEndpoint | Format-List EndpointType,ExchangeServer,UseAutoDiscover,Max*

Шаг 3. Создание пакета прямой миграции

Чтобы создать пакет для прямой миграции, выполните командлет New-MigrationBatch в Exchange Online PowerShell. Можно создать пакет миграции и запустить его обработку автоматически, включив параметр AutoStart. Кроме того, вы можете создать пакет миграции, а затем вручную запустить его с помощью командлета Start-MigrationBatch. В этом примере создается пакет миграции CutoverBatch и используется конечная точка миграции, созданная на предыдущем шаге.

New-MigrationBatch -Name CutoverBatch -SourceEndpoint CutoverEndpoint -AutoStart

В этом примере также создается пакет миграции CutoverBatch и используется конечная точка миграции, созданная на предыдущем шаге. Так как параметр AutoStart не включен, пакет миграции необходимо запустить вручную на панели мониторинга миграции или с помощью командлета Start-MigrationBatch . Как было сказано выше, в одно и то же время может существовать только один пакет прямой миграции.

New-MigrationBatch -Name CutoverBatch -SourceEndpoint CutoverEndpoint

Проверка работы

Чтобы убедиться, что вы успешно создали пакет прямой миграции, выполните следующую команду в Exchange Online PowerShell для отображения сведений о новом пакете миграции.

Get-MigrationBatch | Format-List

Шаг 4. Запуск пакета прямой миграции

Чтобы запустить пакет миграции в Exchange Online PowerShell, выполните следующую команду. Будет создан пакет миграции CutoverBatch.

Start-MigrationBatch -Identity CutoverBatch

Проверка работы

Если пакет миграции успешно запущен, состояние пакета на панели мониторинга миграции изменится на "Синхронизация". Чтобы убедиться, вы успешно запустили пакет миграции с помощью Exchange Online PowerShell, выполните следующую команду.

Get-MigrationBatch -Identity CutoverBatch |  Format-List Status

Шаг 5. Маршрутизация электронной почты в Microsoft 365

Почтовые системы используют запись DNS, которая называется записью MX, чтобы определять, куда нужно доставить электронную почту. В процессе миграции электронной почты запись MX указывала на вашу исходную систему электронной почты. Теперь, когда миграция электронной почты в Microsoft 365 завершена, пришло время указать запись MX на Microsoft 365. Это помогает убедиться, что электронная почта доставлена в почтовые ящики Microsoft 365. Перемещая запись MX, вы также сможете отключить старую систему электронной почты, когда будете готовы сделать это.

Для многих поставщиков DNS предоставляются отдельные инструкции по изменению записей MX. Если вашего поставщика DNS нет в списке или вы хотите в целом понять, как выполнять этот процесс, также существуют общие инструкции по настройке записей MX.

Для того чтобы почтовые системы ваших клиентов и партнеров начали распознавать измененную запись MX, может потребоваться до 72 часов. Подождите по крайней мере 72 часа, прежде чем перейти к следующей задаче: Шаг 6. Удаление пакета прямой миграции.

Шаг 6. Удаление пакета прямой миграции

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

  • Все пользователи используют почтовые ящики Microsoft 365. После удаления пакета почта, отправленная в почтовые ящики в локальной Exchange Server, не копируется в соответствующие почтовые ящики Microsoft 365.

  • Почтовые ящики Microsoft 365 были синхронизированы по крайней мере один раз после отправки почты непосредственно в них. Для этого убедитесь, что значение в поле Время последней синхронизации для пакета миграции является более поздним, чем при начале маршрутизации почты непосредственно в почтовые ящики Microsoft 365.

Чтобы удалить пакет миграции CutoverBatch в Exchange Online PowerShell, выполните следующую команду.

Remove-MigrationBatch -Identity CutoverBatch

Шаг 7. Назначение пользователям лицензий

Активируйте учетные записи пользователей Microsoft 365 для перенесенных учетных записей, назначив лицензии. Если не назначить лицензию, почтовый ящик будет отключен по истечении льготного периода (30 дней). Сведения о назначении лицензии в Центр администрирования Microsoft 365 см. в статье Назначение или отмена назначения лицензий.

Шаг 8. Необходимые действия после миграции

  • Создайте DNS-запись автообнаружения, чтобы пользователи смогли с легкостью получить доступ к своим почтовым ящикам. После переноса всех локальных почтовых ящиков в Microsoft 365 можно настроить запись DNS автообнаружения для организации Microsoft 365, чтобы пользователи могли легко подключаться к новым почтовым ящикам Microsoft 365 с помощью Outlook и мобильных клиентов. Эта новая запись DNS автообнаружения должна использовать то же пространство имен, что и для организации Microsoft 365. Например, если пространство имен облачной службы имеет значение cloud.contoso.com, необходимо создать запись DNS автообнаружения autodiscover.cloud.contoso.com.

    Если вы сохраните Exchange Server, необходимо также убедиться, что запись CNAME DNS автообнаружения должна указывать на Microsoft 365 как во внутренней, так и во внешней DNS после миграции, чтобы клиент Outlook подключился к правильному почтовому ящику.

    Примечание.

    В Exchange 2007, Exchange 2010 и Exchange 2013 для параметра Set-ClientAccessServer AutodiscoverInternalConnectionURI необходимо задать значение Null.

    Microsoft 365 использует запись CNAME для реализации службы автообнаружения для Outlook и мобильных клиентов. Запись CNAME автообнаружения должна содержать следующие сведения:

  • Спишите локальные сервера Exchange. Убедившись, что вся электронная почта направляется непосредственно в почтовые ящики Microsoft 365 и вам больше не нужно поддерживать локальную организацию электронной почты или вы не планируете реализовывать решение единого входа (SSO), вы можете удалить Exchange с серверов и удалить локальную организацию Exchange.

    Дополнительные сведения см. в следующих статьях: