Share via

Миграция почтовых ящиков между клиентами

  • Статья

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

Администраторы могут использовать командлет New-MigrationBatch , доступный с помощью роли управления Перемещение почтовых ящиков , для выполнения перемещений между клиентами.

Пользователи, переносимые, должны присутствовать в целевом клиенте Exchange Online системе как MailUser, помеченный определенными атрибутами, чтобы обеспечить перемещение между клиентами. Системе не удается переместить пользователей, которые неправильно настроены в целевом клиенте.

После завершения перемещений почтовый ящик исходного пользователя преобразуется в MailUserи targetAddress (в Exchange отображается как ExternalEmailAddress ) с адресом маршрутизации для целевого клиента. Этот процесс оставляет устаревшую версию MailUser в исходном клиенте и обеспечивает сосуществование и маршрутизацию почты. Если бизнес-процессы позволяют, исходный клиент может удалить исходный MailUser или преобразовать их в почтовый контакт.

Миграция почтовых ящиков Exchange между клиентами поддерживается только в гибридной или облачной среде или в сочетании этих двух.

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

Важно!

Почтовые ящики, которые находятся на удержании любого типа, не переносятся, и перемещение для этих почтовых ящиков блокируется.

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

Лицензирование

Важно!

С ноября 2022 г. миграция данных пользователей между клиентами доступна в качестве надстройки для следующих планов подписки Microsoft 365 для Соглашение Enterprise клиентов и требуется для миграции между клиентами. Пользовательские лицензии предоставляются за каждую миграцию (разовая плата) и могут быть назначены как исходному, так и целевому объекту пользователя. Эта лицензия также охватывает миграцию OneDrive для бизнеса. За дополнительными сведениями обратитесь в службу поддержки учетных записей Майкрософт.

Надстройка "Миграция данных пользователей между клиентами" доступна как отдельная покупка для Microsoft 365 бизнес базовый, "Стандартный" и "Премиум". Microsoft 365 F1/F3/E3/E5/; Office 365 F3/E1/E3/E5; Exchange Online; SharePoint Online; и OneDrive для бизнеса.

Предупреждение

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

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

Error: CrossTenantMigrationWithoutLicensePermanentException: No license was found for the source recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87', or the target recipient, '65c3c3ea-2b9a-44d0-a685-9bfe300f8c87'. A Cross-tenant User Data Migration license is required to move a mailbox between tenants.

Подготовка исходного и целевого клиентов

Предварительные требования для исходного и целевого клиентов

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

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

Если вы переносите более 10 000 пользователей, рекомендуется создать несколько групп, которые будут содержать список пользователей для повышения производительности. Хотя вложенные группы поддерживаются, они не рекомендуются.

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

Чтобы получить идентификатор клиента подписки, войдите в Центр администрирования Microsoft 365 и перейдите по адресу https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties. Щелкните значок копирования для свойства Идентификатор клиента , чтобы скопировать его в буфер обмена.

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

Действия по настройке для включения миграции почтовых ящиков между клиентами

Примечание.

Сначала необходимо настроить целевой объект (назначение). Для выполнения этих действий не требуется иметь или знать учетные данные администратора клиента как для исходного, так и для целевого клиента. Действия могут выполняться отдельно для каждого клиента разными администраторами.

Подготовка целевого клиента путем создания приложения миграции и секрета

  1. Войдите в Центр администрирования Microsoft Entra (https://portal.azure.com) с учетными данными администратора целевого клиента.

    Вход в Azure

  2. В разделе Управление Microsoft Entra ID выберите Вид.

    Кнопка Microsoft Entra

  3. В области навигации выберите Регистрация приложений.

  4. Выберите Новая регистрация.

    Снимок экрана: пользовательский интерфейс нового приложения.

  5. На странице Регистрация приложения в разделе Поддерживаемые типы учетных записей выберите Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — мультитенантный). Затем в разделе URI перенаправления (необязательно) выберите Интернет и введите https://office.com. Затем выберите Зарегистрировать.

    Снимок экрана: форма

    В правом верхнем углу страницы см. диалоговое окно уведомления с сообщением об успешном создании приложения.

  6. Назад на домашнюю страницу, перейдите к Microsoft Entra ID и выберите Регистрация приложений.

  7. В разделе Собственные приложения найдите созданное приложение и выберите его.

  8. В разделе Основные сведения скопируйте идентификатор приложения (клиента). Эти сведения потребуются позже, чтобы создать URL-адрес для целевого клиента.

  9. В области навигации выберите Разрешения API , чтобы просмотреть разрешения, назначенные приложению.

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

    Снимок экрана:

  11. Чтобы добавить разрешение для миграции почтовых ящиков, выберите Добавить разрешение.

  12. В окне Запрос разрешений API выберите API, которые использует моя организация, найдите Office 365 Exchange Onlineи выберите его.

    Снимок экрана:

  13. Выберите Разрешения приложения.

  14. В разделе Выбор разрешений разверните узел Почтовый ящик и выберите Mailbox.Migration, а затем выберите Добавить разрешения в нижней части экрана.

    Снимок экрана: Mailbox.Migration и его флажок в разделе

  15. Теперь выберите Сертификаты & секреты в области навигации для приложения.

  16. В разделе Секреты клиента выберите Новый секрет клиента.

    Снимок экрана:

  17. В окне Добавление секрета клиента введите описание и настройте параметры срока действия.

    Примечание.

    Пароль используется при создании конечной точки миграции. Очень важно скопировать этот пароль в буфер обмена и (или) в безопасное или секретное расположение. Этап создания секрета — это единственный момент, в течение которого вы можете увидеть этот пароль! Если вы каким-то образом потеряете его или вам нужно сбросить его, вы можете снова войти в портал Azure, перейти к Регистрация приложений, найти приложение для миграции, выбрать Секреты & сертификаты, а затем создать секрет для своего приложения.

Теперь, когда вы успешно создали приложение миграции и секрет, следующим шагом является согласие на использование приложения.

  1. На целевой странице Microsoft Entra ID выберите Корпоративные приложения в области навигации, а затем найдите созданное приложение миграции, выберите его и выберите Разрешения API.

  2. Выберите Предоставить согласие администратора для [вашего клиента]. Откроется новое окно браузера.

  3. Выберите Принять.

  4. Назад в окно портала и нажмите кнопку Обновить, чтобы подтвердить принятие.

  5. Сформулируйте URL-адрес для отправки доверенному партнеру (администратору исходного клиента), чтобы он также смог принять приложение для включения миграции почтовых ящиков.

    Ниже приведен пример URL-адреса, который необходимо предоставить им:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

    Примечание.

    Вам потребуется идентификатор приложения для миграции почтового ящика, которое вы только что создали. Вам потребуется заменить contoso.onmicrosoft.com в приведенном выше примере правильным onmicrosoft.com именем исходного клиента. Вам также потребуется заменить [application_id_of_the_app_you_just_created] идентификатором приложения для миграции почтового ящика, которое вы только что создали.

Подготовка целевого клиента путем создания конечной точки миграции Exchange Online и связи организации

  1. Подключитесь к Exchange Online PowerShell в целевом клиенте Exchange Online.

  2. Создайте конечную точку миграции для перемещения почтовых ящиков между клиентами.

    Примечание.

    Вам потребуется идентификатор приложения для миграции почтового ящика, которое вы только что создали, и пароль (секрет), настроенный в разделе Подготовка целевого клиента (назначения) путем создания приложения миграции и секрета. В зависимости от используемого облачного экземпляра Microsoft 365 конечная точка может отличаться. См. страницу конечных точек Microsoft 365; выберите правильный экземпляр для клиента; затем просмотрите адрес Exchange Online Optimize/Required и замените соответствующим образом.

    # Enable customization if tenant is dehydrated
$dehydrated=Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$AppId = "[Guid copied from the migrations app]"
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AppId, (ConvertTo-SecureString -String "[this is your secret password you saved in the 
previous steps]" -AsPlainText -Force)
New-MigrationEndpoint -RemoteServer outlook.office.com -RemoteTenant "contoso.onmicrosoft.com" -Credentials $Credential -ExchangeRemoteMove:$true -Name "[the name of your migration endpoint]" -ApplicationId $AppId

  3. Создайте новый объект отношений организации или измените существующий объект отношений организации в исходном клиенте.

    $sourceTenantId="[tenant id of your trusted partner, where the source mailboxes are]"
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $sourceTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship "[name of the new organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability Inbound -DomainNames $sourceTenantId
}

Подготовьте клиент источника (текущее расположение почтового ящика), приняв приложение миграции и настроив отношение организации.

  1. В браузере перейдите по ссылке URL-адреса, предоставленной доверенным партнером, чтобы дать согласие на перенос почтового ящика. URL-адрес должен выглядеть следующим образом:

    https://login.microsoftonline.com/contoso.onmicrosoft.com/adminconsent?client_id=[application_id_of_the_app_you_just_created]&redirect_uri=https://office.com

    Примечание.

    Вам потребуется идентификатор приложения для миграции почтового ящика, которое вы только что создали. В предыдущем примере необходимо заменить contoso.onmicrosoft.com URL-адресом исходного onmicrosoft.com клиента. Вам также потребуется заменить [application_id_of_the_app_you_just_created] идентификатором приложения для миграции почтового ящика, которое вы только что создали.

  2. Примите приложение при появлении всплывающего окна. Вы также можете войти в Центр администрирования Microsoft Entra и найти приложение в разделе Корпоративные приложения.

  3. Подключитесь к Exchange Online PowerShell в исходном клиенте Exchange Online.

  4. Создайте новый объект отношений организации или измените существующий объект отношений организации в целевом (целевом) клиенте Exchange Online PowerShell:

    # Enable customization if tenant is dehydrated
$dehydrated=Get-OrganizationConfig | select isdehydrated
if ($dehydrated.isdehydrated -eq $true) {Enable-OrganizationCustomization}
$targetTenantId="[tenant id of your trusted partner, where the mailboxes are being moved to]"
$appId="[application id of the mailbox migration app you consented to]"
$scope="[name of the mail enabled security group that contains the list of users who are allowed to migrate]"
New-DistributionGroup -Type Security -Name $scope
$orgrels=Get-OrganizationRelationship
$existingOrgRel = $orgrels | ?{$_.DomainNames -like $targetTenantId}
If ($null -ne $existingOrgRel)
{
    Set-OrganizationRelationship $existingOrgRel.Name -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}
If ($null -eq $existingOrgRel)
{
    New-OrganizationRelationship "[name of your organization relationship]" -Enabled:$true -MailboxMoveEnabled:$true -MailboxMoveCapability RemoteOutbound -DomainNames $targetTenantId 
-OAuthApplicationId $appId -MailboxMovePublishedScopes $scope
}

    Примечание.

    Идентификатор клиента, который вы вводите в качестве $sourceTenantId и $targetTenantId, является идентификатором GUID, а не доменным именем клиента. Пример идентификатора клиента и сведения о поиске идентификатора клиента см. в разделе Поиск идентификатора клиента Microsoft 365.

Подготовка целевых объектов пользователей к миграции

Пользователи, переносимые, должны присутствовать в целевом клиенте и Exchange Online системе (как MailUser), помеченные определенными атрибутами, чтобы включить перемещение между клиентами. Системе не удастся переместить пользователей, которые неправильно настроены в целевом клиенте. В разделе Предварительные требования для объектов целевого пользователя подробно описаны требования к объекту MailUser для целевого клиента.

Предварительные требования для целевых объектов пользователей

Убедитесь, что в целевой организации заданы следующие объекты и атрибуты:

Совет

Корпорация Майкрософт разрабатывает функцию для предоставления безопасного автоматизированного метода для задания многих атрибутов (указанных ниже, в этом разделе). Эта функция, которая называется сопоставлением удостоверений между клиентами, в настоящее время ищет клиентов, желающих принять участие в небольшой закрытой предварительной версии. Дополнительные сведения об этой функции предварительной версии и о том, как она может упростить процессы миграции между клиентами, см. в разделе Сопоставление удостоверений между клиентами.

Для любого почтового ящика, перемещаемого из исходной организации, необходимо подготовить объект MailUser в целевой организации:

  1. Target MailUser должен иметь следующие атрибуты из исходного почтового ящика или назначить новый объект User:

    1. ExchangeGUID (прямой поток из источника в целевой): идентификатор GUID почтового ящика должен совпадать. Процесс перемещения не будет продолжаться, если этот атрибут отсутствует в целевом объекте.

    2. ArchiveGUID (прямой поток из источника в целевой): идентификатор GUID архива должен совпадать. Процесс перемещения не будет продолжаться, если этот атрибут отсутствует в целевом объекте. (Этот атрибут является обязательным только в том случае, если исходный почтовый ящик включен для архивации.

    3. LegacyExchangeDN (flow as proxyAddress, "x500:<LegacyExchangeDN"): LegacyExchangeDN> должно присутствовать в целевом mailUser как x500: proxyAddress. Кроме того, необходимо скопировать все адреса x500 из исходного почтового ящика целевому почтовому пользователю. Процессы перемещения не будут продолжаться, если эти адреса x500 отсутствуют в целевом объекте. Кроме того, этот шаг важен для включения возможности ответа для сообщений электронной почты, отправляемых до миграции. Адрес отправителя или получателя в каждом элементе электронной почты и кэше автоматического завершения в Microsoft Outlook и в Microsoft Outlook Web App (OWA) используют значение атрибута LegacyExchangeDN. Если пользователь не может быть найден с помощью значения LegacyExchangeDN, доставка сообщений электронной почты может завершиться ошибкой с NDR 5.1.1.

    4. UserPrincipalName: имя участника-пользователя будет соответствовать новому удостоверению пользователя или целевой компании (например, user@northwindtraders.onmicrosoft.com).

    5. Primary SMTPAddress: основной SMTP-адрес будет соответствовать новой компании пользователя (например, user@northwindtraders.com).

    6. TargetAddress/ExternalEmailAddress: MailUser будет ссылаться на текущий почтовый ящик пользователя, размещенный в исходном клиенте (например user@contoso.onmicrosoft.com, ). При назначении этого значения убедитесь, что у вас есть или также назначено Значение PrimarySMTPAddress; В противном случае это значение задаст значение PrimarySMTPAddress, что приведет к сбоям перемещения.

    7. Вы не можете добавить устаревшие прокси-адреса SMTP из исходного почтового ящика в целевой mailUser. Например, вы не можете поддерживать contoso.com в MEU в northwindtraders.onmicrosoft.com объектов клиента. Домены связаны только с одним Microsoft Entra ID или Exchange Online клиентом.

      Пример целевого объекта MailUser:

      Атрибут Значение
      Alias (Псевдоним) ЛараН
      RecipientType MailUser
      RecipientTypeDetails MailUser
      UserPrincipalName LaraN@northwintraders.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@northwindtraders.com
      ExternalEmailAddress SMTP:LaraN@contoso.onmicrosoft.com
      ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara
      EmailAddresses x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
      Smtp:LaraN@northwindtraders.onmicrosoft.com
      SMTP:Lara.Newton@northwindtraders.com
      X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c0c23984b3d6c-Lara

      Пример исходного объекта Mailbox:

      Атрибут Значение
      Alias (Псевдоним) ЛараН
      RecipientType UserMailbox
      RecipientTypeDetails UserMailbox
      UserPrincipalName LaraN@contoso.onmicrosoft.com
      PrimarySmtpAddress Lara.Newton@contoso.com
      ExchangeGUID 1ec059c7-8396-4d0b-af4e-d6bd4c12a8d8
      LegacyExchangeDN /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
      EmailAddresses Smtp:LaraN@contoso.onmicrosoft.com
      SMTP:Lara.Newton@contoso.com
      X500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c0c23984b3d6c-Lara

  2. Другие атрибуты уже могут быть включены в гибридную запись Exchange. Если нет, они должны быть включены.

    1. msExchBlockedSendersHash— записывает данные заблокированных отправителей из клиентов в локальная служба Active Directory.
    2. msExchSafeRecipientsHash— записывает в локальная служба Active Directory данные надежных получателей в сети от клиентов.
    3. msExchSafeSendersHash— записывает данные надежных отправителей в сети от клиентов в локальная служба Active Directory.

    Пользователи в целевой организации должны иметь соответствующие подписки на Exchange Online, применимые к организации. Вы можете применить лицензию перед перемещением почтового ящика, но только после правильной настройки целевого пользователя MailUser с ExchangeGUID и прокси-адресами. Применение лицензии до применения ExchangeGUID приведет к созданию нового почтового ящика, подготовленного в целевой организации. Кроме того, необходимо применить лицензию на миграцию данных пользователей между клиентами. В противном случае может возникнуть временная ошибка, при которой при чтении требуется утверждение, в отчете о перемещении появится предупреждение о том, что лицензия не была применена к целевому пользователю.

    Примечание.

    Когда вы применяете лицензию к объекту Mailbox или MailUser, все прокси-адреса SMTP-типа очищаются, чтобы в массив Exchange EmailAddresses включались только проверенные домены.

  3. Необходимо убедиться, что у целевого пользователя MailUser нет предыдущего идентификатора ExchangeGUID, который не соответствует исходному идентификатору ExchangeGUID. Это несоответствие может возникнуть, если целевой MEU ранее был лицензирован для Exchange Online и подготовлен почтовый ящик. Если целевой mailUser ранее был лицензирован или имел идентификатор ExchangeGUID, который не соответствует исходному ExchangeGUID, необходимо выполнить очистку облачного MEU. Для этих облачных MEU можно запустить Set-User <identity> -PermanentlyClearPreviousMailboxInfo.

Предостережение

Этот процесс необратим. Если у объекта есть почтовый ящик softDeleted, после этого его нельзя будет восстановить. Однако после очистки можно синхронизировать правильный Идентификатор ExchangeGUID с целевым объектом, и MRS подключит исходный почтовый ящик к созданному целевому почтовому ящику. (См. блог EHLO о новом параметре.)

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

Get-User <identity> | select Name, *recipient* | Format-Table -AutoSize

Пример:

Get-User John@northwindtraders.com |select name, *recipient*| Format-Table -AutoSize

Name       PreviousRecipientTypeDetails     RecipientType RecipientTypeDetails
----       ---------------------------- ------------- --------------------
John       UserMailbox                  MailUser      MailUser

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

Set-User <identity> -PermanentlyClearPreviousMailboxInfo

Пример:

Set-User John@northwindtraders.com -PermanentlyClearPreviousMailboxInfo -Confirm

Are you sure you want to perform this action?
Delete all existing information about user "John@northwindtraders.com"?. This operation will clear existing values from Previous home MDB and Previous Mailbox GUID of the user. After deletion, reconnecting to the previous mailbox that existed in the cloud will not be possible and any content it had will be unrecoverable PERMANENTLY.
Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y

Как проверить, что это работает?

Вы можете проверить конфигурацию миграции почтовых ящиков между клиентами, выполнив командлет Test-MigrationServerAvailability для конечной точки миграции между клиентами, созданной в целевом клиенте. Выполните следующий командлет из целевого клиента:

Test-MigrationServerAvailability -EndPoint "[the name of your migration endpoint]" -TestMailbox "[Primary SMTP of MailUser object in target tenant]"

Примечание.

Кроме того, вы можете воспользоваться преимуществами скрипта проверки миграции почтовых ящиков между клиентами, который позволит проверить правильность настройки организаций между ними и объекты, которые планируется перенести из одного клиента в другой. Скрипт поможет выявить все несоответствия, которые могут присутствовать во всех объектах одновременно, и, как следствие, сократит время, затрачиваемое на начальном этапе.

Перемещение почтовых ящиков обратно в исходный источник

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

Не запускайте примеры скриптов, предоставленные для создания Объекта OrganizationRelationship.

Обновите следующие значения в существующем объекте OrganizationRelationship, созданном в каждом клиенте:

  • MailboxMovesCapability должен иметь входящие и RemoteOutbound в качестве возможностей в исходном и целевом клиентах.
  • В новом исходном клиенте обновите значение OAuthApplicationId значением из только что созданного приложения в новом исходном клиенте.
  • В новом исходном клиенте обновите значение MailboxMovePublishedScopes, указав только что созданную группу безопасности в новом исходном клиенте.

Выполнение миграции почтовых ящиков

Миграция почтовых ящиков Exchange между клиентами инициируется из целевого клиента в виде пакетов миграции. Этот процесс аналогичен работе пакетов миграции при миграции из локальной среды Exchange в Microsoft 365.

Создание пакетов миграции

Ниже приведен пример команды для инициации пакетной миграции:

New-MigrationBatch -Name T2Tbatch -SourceEndpoint target_source_7977 -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com

Identity                   Status  Type               TotalCount
--------                   ------  ----               ----------
T2Tbatch                   Syncing ExchangeRemoteMove 1

Примечание.

Адрес электронной почты в CSV-файле должен быть указан в целевом клиенте (например, userA@northwindtraders.onmicrosoft.com), а не в исходном клиенте. Дополнительные сведения о командлете см. здесь. Для примера сведений о CSV-файле щелкните здесь.

Минимальный пример CSV-файла:

EmailAddress
userA@northwindtraders.onmicrosoft.com
userB@northwindtraders.onmicrosoft.com
userC@northwindtraders.onmicrosoft.com

Пакетная отправка миграции также поддерживается в новом Центре администрирования Exchange при выборе параметра между клиентами.

Обновление локальных mailUsers

После перемещения почтового ящика из источника в целевой следует убедиться, что локальные почтовые пользователи, как в исходном, так и в целевом объектах, обновлены новым целевым адресомAddress. В примерах параметр targetDeliveryDomain, используемый при перемещении, northwindtraders.onmicrosoft.com. Обновите почтовых пользователей с помощью этого целевогоадреса.

Удаление конечных точек и организационных связей после миграции

Используйте командлет Remove-MigrationEndpoint , чтобы удалить существующие конечные точки миграции для исходного или целевого серверов после завершения миграции.

Используйте командлет Remove-OrganizationRelationship , чтобы удалить существующие организационные связи для исходных или целевых серверов после завершения миграции.

Вопросы и ответы

Нужно ли обновлять RemoteMailboxes в исходном локальном клиенте после перемещения?

Исходная организация Exchange

Необходимо обновить targetAddress (RemoteRoutingAddress/ExternalEmailAddress) каждого исходного локального пользователя при перемещении почтового ящика исходного клиента в целевой клиент. Хотя маршрутизация почты может следовать рекомендациям для нескольких пользователей почты с разными целевыми значениямиAddresses, поиск по доступности для пользователей почты должен быть ориентирован на расположение пользователя почтового ящика.

Целевая организация Exchange

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

Get-MailUser -Identity <Migrate Mail User> | Enable-RemoteMailbox

Переносятся ли собрания Teams между клиентами?

Хотя собрания Teams перемещаются, URL-адрес собрания не обновляется при переносе элементов между клиентами. Так как URL-адрес будет недопустимым в целевом клиенте, необходимо удалить и повторно создать собрания Teams.

Какое содержимое переносится между арендаторами?

При переносе почтового ящика в нескольких клиентах с помощью этой функции переносятся только содержимое, видимое пользователем, в почтовом ящике, также известном как Top of Information Store (электронная почта, контакты, календарь, задачи и заметки), а также папки "Элементы с возможностью восстановления", "Удаление", "Версии" и "Очистки".

Переносятся ли элементы в папке "Исходящие" между клиентами?

Элементы в папке "Исходящие" не переносятся между арендаторами, так как эта папка является клиентской папкой, относяющейся к клиенту Outlook. Элементы в папке "Исходящие" хранятся локально и не синхронизируются с облаком.

Переносится ли содержимое папки чата Teams между клиентами?

Нет, содержимое папки чата Teams не переносится между арендаторами. Однако после переноса почтового ящика между клиентами содержимое папки чата Teams будет доступно администратору исходного клиента для поиска и экспорта с помощью поиска контента.

Как я могу видеть только перемещения, которые являются перемещением между арендаторами, а не переходы по подключению и отключению?

Используйте параметр Flags :

Get-MoveRequest -Flags "CrossTenant"

Можно ли предоставить примеры скриптов для копирования атрибутов, используемых при тестировании?

Примечание.

SAMPLE — AS IS, NO WARRANTY. Сценарий предполагает подключение как к исходному почтовому ящику (для получения исходных значений), так и к целевому локальная служба Active Directory Доменные службы (для пометки объекта ADUser).

# This will export users from the source tenant with the CustomAttribute1 = "Cross-Tenant-Project"
# These are the 'target' users to be moved to the northwindtraders tenant
$outFileUsers = "$home\desktop\UsersToMigrate.txt"
$outFileUsersXML = "$home\desktop\UsersToMigrate.xml"
Get-Mailbox -Filter "CustomAttribute1 -like 'Cross-Tenant-Project'" -ResultSize Unlimited | Select-Object -ExpandProperty  Alias | Out-File $outFileUsers
$mailboxes = Get-Content $outFileUsers
$mailboxes | ForEach-Object {Get-Mailbox $_} | Select-Object PrimarySMTPAddress,Alias,SamAccountName,FirstName,LastName,DisplayName,Name,ExchangeGuid,ArchiveGuid,LegacyExchangeDn,EmailAddresses | Export-Clixml $outFileUsersXML

# Copy the file $outfile to the desktop of the target on-premises then run the below to create MEU in Target
$symbols = '!@#$%^&*'.ToCharArray()
$characterList = @([char[]]([char]'a'..[char]'z'), [char[]]([char]'A'..[char]'Z'), [char[]]([char]'0'..[char]'9') + $symbols)

function GeneratePassword {
    param(
        [ValidateRange(12, 256)]
        [int]
        $length = 16
    )

    do {
        $password = -join (0..$length | ForEach-Object { $characterList | Get-Random })
        [int]$hasLowerChar = $password -cmatch '[a-z]'
        [int]$hasUpperChar = $password -cmatch '[A-Z]'
        [int]$hasDigit = $password -match '[0-9]'
        [int]$hasSymbol = $password.IndexOfAny($symbols) -ne -1

    }
    until (($hasLowerChar + $hasUpperChar + $hasDigit + $hasSymbol) -ge 3)

    $password | ConvertTo-SecureString -AsPlainText
}

$mailboxes = Import-Clixml $home\desktop\UsersToMigrate.xml
foreach ($m in $mailboxes) {
    $organization = "@contoso.onmicrosoft.com"
    $mosi = $m.Alias + $organization
    $Password = GeneratePassword
    $x500 = "x500:" + $m.LegacyExchangeDn
    $tmpUser = New-MailUser -MicrosoftOnlineServicesID $mosi -PrimarySmtpAddress $mosi -ExternalEmailAddress $m.PrimarySmtpAddress -FirstName $m.FirstName -LastName $m.LastName -Name $m.Name -DisplayName $m.DisplayName -Alias $m.Alias -Password $Password
    $tmpUser | Set-MailUser -EmailAddresses @{add = $x500 } -ExchangeGuid $m.ExchangeGuid -ArchiveGuid $m.ArchiveGuid -CustomAttribute1 "Cross-Tenant-Project"
    $tmpx500 = $m.EmailAddresses | Where-Object { $_ -match "x500" }
    $tmpx500 | ForEach-Object { Set-MailUser $m.Alias -EmailAddresses @{add = "$_" } }
}

# Now synchronize the changes from On-Premises to Azure and Exchange Online in the target tenant
# This action should create the target mail enabled users (MEUs) in the Target tenant
Start-ADSyncSyncCycle

Как получить доступ к Outlook в день 1 после перемещения почтового ящика пользователя?

Так как только один клиент может владеть доменом, бывший основной SMTPAddress не будет связан с пользователем в целевом клиенте по завершении перемещения почтового ящика. только те домены, которые связаны с новым клиентом. Outlook использует новое имя участника-пользователя для проверки подлинности в службе, а профиль Outlook ожидает найти устаревший основной SMTPAddress, соответствующий почтовому ящику в целевой системе. Так как устаревший адрес отсутствует в целевой системе, профиль Outlook не подключается для поиска только что перемещенного почтового ящика.

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

Примечание.

Планируйте соответствующим образом по мере пакетной обработки пользователей для завершения. Необходимо учитывать использование сети и емкость при создании профилей клиентов Outlook и загрузке на клиенты последующих ost- и OAB-файлов.

Какие роли Exchange RBAC необходимо принять, чтобы настроить или завершить перемещение между клиентами?

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

  • Первая роль — для однократной задачи настройки, которая устанавливает авторизацию перемещения содержимого в границу клиента или организации или за ее пределы. Поскольку перемещение данных из-под контроля организации является критически важной проблемой для всех компаний, мы выбрали наивысшую назначенную роль администратора организации. Эта роль должна изменить или настроить новую организацию OrganizationRelationship, которая определяет -MailboxMoveCapability параметр с удаленной организацией. Изменить параметр может -MailboxMoveCapability только администратор организации, в то время как администратор федеративного общего доступа может управлять другими атрибутами в OrganizationRelationship.
  • Роль выполнения фактических команд перемещения может быть делегирована функции более низкого уровня. Роль перемещения почтовых ящиков назначается возможности перемещения почтовых ящиков в организацию или из нее.

Как определить, какой SMTP-адрес выбран для targetAddress (TargetDeliveryDomain) в преобразованном почтовом ящике (преобразование MailUser)?

Почтовый ящик Exchange перемещается с помощью MRS, создайте targetAddress в исходном почтовом ящике источника при преобразовании в MailUser путем сопоставления адреса электронной почты (proxyAddress) в целевом объекте. Процесс принимает значение, -TargetDeliveryDomain переданное в команду, а затем проверяет наличие соответствующего прокси-сервера для этого домена на целевой стороне. При поиске совпадения соответствующий proxyAddress используется для задания объекта ExternalEmailAddress (targetAddress) для преобразованного почтового ящика (теперь MailUser).

Как работает поток обработки почты после миграции?

Поток обработки почты между клиентами после миграции работает аналогично гибридному потоку почты Exchange. Для каждого перенесенного почтового ящика требуется исходный mailUser с правильным целевым адресом для пересылки входящей почты из исходного клиента в почтовые ящики в целевом клиенте. Правила транспорта, функции безопасности и соответствия требованиям будут работать в соответствии с настройками в каждом клиенте, через который проходит почта. Таким образом, для входящей почты такие функции, как защита от нежелательной почты, защита от вредоносных программ, карантин, правила транспорта и правила ведении журнала, будут выполняться сначала в исходном клиенте, а затем в целевом клиенте.

Как переносить разрешения почтового ящика?

Разрешения почтового ящика включают отправку от имени и доступ к почтовому ящику:

  • Send On Behalf Of (AD:publicDelegates) сохраняет DN получателей с доступом к почтовому ящику пользователя в качестве делегата. Это значение хранится в Active Directory и в настоящее время не перемещается при переходе почтового ящика. Если в исходном почтовом ящике задано значение publicDelegates, вам потребуется переуказать publicDelegates в целевом почтовом ящике после завершения преобразования MEU в почтовый ящик в целевой среде путем запуска Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>.
  • Разрешения почтового ящика, хранящиеся в почтовом ящике, будут перемещаться вместе с почтовым ящиком при перемещении субъекта и делегата в целевую систему. Например, пользователю TestUser7 предоставляется полный доступ для почтового ящика TestUser_8 в SourceCompany.onmicrosoft.com клиента. После завершения перемещения почтового ящика в TargetCompany.onmicrosoft.com в целевом каталоге будут настроены те же разрешения. Ниже приведены примеры использования _Get-MailboxPermission для TestUser_7 в исходном и целевом клиентах. Командлеты Exchange префиксируются соответствующим образом с исходным и целевым адресом.

Ниже приведен пример выходных данных разрешения почтового ящика перед перемещением со стороны источника:

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, is Inherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@contoso.onmicrosoft.com               {FullAccess}                         False       False

Ниже приведен пример выходных данных разрешения почтового ящика после перемещения с целевой стороны:

Get-MailboxPermission TestUser_7 | Format-Table -AutoSize User, AccessRights, IsInherited, Deny

User                                             AccessRights                         IsInherited Deny
----                                             ------------                         ----------- ----
NT AUTHORITY\SELF                                {FullAccess, ReadPermission}         False       False
TestUser_8@northwindtraders.onmicrosoft.com      {FullAccess}                         False       False

Примечание.

Разрешения на межтенантный почтовый ящик и календарь не поддерживаются. Необходимо упорядочить субъекты и делегаты в консолидированные пакеты перемещения, чтобы эти подключенные почтовые ящики одновременно переносились из исходного клиента.

Какой прокси-сервер X500 следует добавить к целевым прокси-адресам MailUser, чтобы включить миграцию?

Для миграции почтовых ящиков между клиентами требуется, чтобы значение LegacyExchangeDN исходного объекта почтового ящика было помечено как адрес электронной почты x500 в целевом объекте MailUser.

Пример:

LegacyExchangeDN value on source mailbox is:
/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9Lara

so, the x500 email address to be added to target MailUser object would be:
x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara

Примечание.

В дополнение к этому прокси-серверу X500 необходимо будет скопировать все прокси-серверы X500 из почтового ящика в источнике в почтовый ящик в целевом. Хотя это редко, вы также можете выполняться через адрес прокси-сервера X400 в почтовом ящике, хотя это не является требованием для завершения перемещения, рекомендуется также пометить этот адрес в целевом объекте пользователя почты.

Могут ли исходные и целевые клиенты использовать одно и то же доменное имя?

Нет, имена доменов исходного клиента и целевого клиента должны быть уникальными, например исходный домен contoso.com и целевой домен northwindtraders.com.

Будут ли общие почтовые ящики перемещаться и работать?

Да. Однако мы оставим только разрешения на хранение, как описано в этой статье:

Есть ли у вас рекомендации по пакетам?

Не превышает 2000 почтовых ящиков на пакет. Мы настоятельно рекомендуем отправлять пакеты за две недели до даты сокращения, так как это не влияет на конечных пользователей во время синхронизации. Если вам нужны рекомендации для почтовых ящиков свыше 50 000, вы можете обратиться к списку рассылки инженерных отзывов по адресу crosstenantmigrationpreview@service.microsoft.com.

Что делать, если я использую шифрование службы с ключом клиента Microsoft Purview?

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

Каково предполагаемое время миграции?

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

Защита документов в исходном клиенте, потребляемых пользователями в целевом клиенте.**

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

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/mergers-and-spinoffs/ba-p/910455

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

Так как при миграции между клиентами метки не экспортируются и нет способа совместного использования меток между клиентами, эту цель можно достичь только путем повторного создания меток в целевом клиенте.

Поддерживаете ли вы перемещение Группы Microsoft 365?

В настоящее время функция миграции почтовых ящиков между клиентами не поддерживает миграцию Группы Microsoft 365.

Может ли администратор исходного клиента выполнить поиск электронных данных в почтовом ящике после переноса почтового ящика в новый или целевой клиент?

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

В какой момент конечный mailUser будет преобразован в целевой почтовый ящик, а исходный почтовый ящик — в исходный MailUser?

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

На каком этапе следует назначить лицензию на Exchange Online конечным получателям MailUsers?

Это назначение лицензии можно выполнить до завершения миграции, но не следует назначать лицензию до добавления метки атрибута ExchangeGUID . В противном случае преобразование объекта MailUser в почтовый ящик завершится ошибкой, и вместо этого будет создан новый почтовый ящик. Чтобы снизить этот риск, лучше подождать, пока миграция завершится, и назначить лицензии в течение 30-дневного льготного периода.

Можно ли использовать Microsoft Entra Connect для синхронизации пользователей с новым клиентом, если я сохраняю локальная служба Active Directory?

Да. Можно синхронизировать два экземпляра Microsoft Entra Connect с разными клиентами. Однако необходимо знать о некоторых вещах:

  • Предварительная подготовка учетных записей пользователя с помощью скрипта, указанного в этой статье, не должна выполняться. Вместо этого для заполнения целевого клиента можно выполнить выборочную синхронизацию подразделений пользователей в область для миграции. Вы получите предупреждение о том, что имя участника-пользователя не совпадает во время настройки Microsoft Entra Connect.
  • В зависимости от текущего состояния гибридной среды Exchange необходимо убедиться, что объекты локального каталога имеют необходимые атрибуты (например, msExchMailboxGUID и proxyAddresses) заполнены правильно, прежде чем пытаться выполнить синхронизацию с другим клиентом. в противном случае вы столкнуться с проблемами с двойными почтовыми ящиками и сбоями миграции.
  • Необходимо предпринять некоторые дополнительные действия для управления переходом имени участника-пользователя, изменив его локально после завершения миграции для пользователя, если вы также не перемещаете личный домен во время переключения.

Как обрабатывать почтовые ящики, близкие к квоте или превышенные.

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

Примечание.

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

Перемещаются ли автоматически развернутые архивные почтовые ящики?

Проблема. Автоматически развернутые архивы не могут быть перенесены. Да, если у пользователя в источнике включено автоматическое расширение архивов и есть дополнительные вспомогательные архивы, миграция почтовых ящиков между клиентами будет работать. Мы поддерживаем перемещение пользователей, имеющих не более 12 вспомогательных архивных почтовых ящиков. Кроме того, пользователям с большими основными архивами, большими main и большими вспомогательными архивными почтовыми ящиками потребуется дополнительное время для синхронизации, и их следует отправлять задолго до даты сокращения. Если исходный почтовый ящик развернут во время миграции почтового ящика, миграция завершится ошибкой, так как новый вспомогательный архив будет создан в источнике, но не в целевом объекте. В этом случае необходимо удалить пользователя из пакета и повторно отправить его.

Можно ли выполнить миграцию между облачными клиентами в клиент?

Миграция между клиентами в облако не поддерживается. Примером сценария является переход от Office 365 Worldwide к Office 365 для государственных организаций cloud.

Перенос голосовой почты между клиентами?

Да, голосовая почта переносится между клиентами.

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

Перенос подписей почтовых ящиков между клиентами?

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

Известные проблемы

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

  • Cloud MailUsers с не принадлежащим smtp proxyAddress блоком MRS перемещается. При создании целевых объектов MailUser клиента необходимо убедиться, что все прокси-адреса SMTP принадлежат целевой организации клиента. Если smtp proxyAddress существует в целевом почтовом пользователе, который не принадлежит локальному клиенту, преобразование MailUser в почтовый ящик предотвращается. Это связано с нашей гарантией того, что объекты почтовых ящиков могут отправлять почту только из доменов, для которых клиент является полномочным (домены, запрашиваемые клиентом).

  • Если вы синхронизируете пользователей из локальной среды с помощью Microsoft Entra Connect в целевом клиенте, вы можете подготовить локальные объекты MailUser с помощью ExternalEmailAddress, указывающего на исходный клиент, в котором существует почтовый ящик (LaraN@contoso.onmicrosoft.com), и пометить PrimarySMTPAddress как домен, который находится в целевом клиенте (Lara.Newton@northwindtraders.com). Эти значения синхронизируются с клиентом, и соответствующий почтовый пользователь подготовлен и готов к миграции. Здесь показан пример объекта .

    Get-MailUser LaraN | select ExternalEmailAddress, EmailAddresses

ExternalEmailAddress               EmailAddresses
--------------------               --------------
SMTP:LaraN@contoso.onmicrosoft.com {SMTP:lara.newton@northwindtraders.com}

    Примечание.

    Адрес contoso.onmicrosoft.comотсутствует в массиве EmailAddresses/proxyAddresses.

  • Объекты MailUser с "внешними" основными SMTP-адресами изменяются или сбрасываются на "внутренние" домены, заявленные компанией.

    Объекты MailUser являются указателями на почтовые ящики, не являющиеся локальными. В случае миграции почтовых ящиков между клиентами объекты MailUser используются для представления исходного почтового ящика (с точки зрения целевой организации) или целевого почтового ящика (с точки зрения исходной организации). MailUsers будет иметь externalEmailAddress (targetAddress), который указывает на SMTP-адрес фактического почтового ящика (ProxyTest@northwindtraders.onmicrosoft.com), и основной адресSMTP, представляющий отображаемый SMTP-адрес пользователя почтового ящика в каталоге. Некоторые организации предпочитают отображать основной SMTP-адрес как внешний SMTP-адрес, а не как адрес, принадлежащий или проверенный локальным клиентом (например, как northwindtraders.com, а не как contoso.com). Однако после применения объекта плана службы Exchange к MailUser с помощью операций лицензирования основной SMTP-адрес изменяется для отображения в качестве домена, проверенного локальной организацией (contoso.com). Существует две потенциальные причины:

  • Когда к MailUser применяется какой-либо план службы Exchange, процесс Microsoft Entra ID начинает принудительно выполнять очистку прокси-сервера, чтобы убедиться, что локальная организация не может отправлять почту, подделывание или почту из другого клиента. Любой SMTP-адрес объекта получателя с этими планами обслуживания будет удален, если адрес не проверен локальной организацией. Как и в примере, northwindtraders.com домен не проверяется клиентом contoso.onmicrosoft.com. Таким образом, очистка удаляет, что northwindtraders.com домен. Если вы хотите сохранить эти внешние домены в MailUser до или после миграции, необходимо изменить процессы миграции, чтобы удалить лицензии после завершения перемещения или перед перемещением, чтобы убедиться, что у пользователей будет применена ожидаемая внешняя фирменная символика. Необходимо убедиться, что объект почтового ящика имеет правильную лицензию, чтобы не влиять на службу почты. Пример сценария для удаления планов обслуживания в MailUser в клиенте contoso.onmicrosoft.com показан здесь.

Примечание.

В следующем сценарии используется Microsoft Graph PowerShell. Дополнительные сведения см. в статье Обзор Microsoft Graph PowerShell.

Сведения об использовании различных методов проверки подлинности Connect-Graph в автоматическом скрипте см. в статье Командлеты модуля проверки подлинности в Microsoft Graph PowerShell.

# Connect to Microsoft Graph
Connect-Graph -Scopes User.ReadWrite.All, Organization.Read.All

# Get licensing plans and include disabled plans
$EmsSku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'ENTERPRISEPREMIUM'
$User = Get-MgUser -UserId LaraN@contoso.onmicrosoft.com
$userLicense = Get-MgUserLicenseDetail -UserId $User.Id

$userDisabledPlans = $userLicense.ServicePlans |
  Where ProvisioningStatus -eq "Disabled" |
  Select -ExpandProperty ServicePlanId

$newDisabledPlans = $EmsSku.ServicePlans |
  Where ServicePlanName -in ("LOCKBOX_ENTERPRISE","EXCHANGE_S_ENTERPRISE","INFORMATION_BARRIERS","MIP_S_CLP2","MIP_S_CLP1","MYANALYTICS_P2","EXCHANGE_ANALYTICS","EQUIVIO_ANALYTICS","THREAT_INTELLIGENCE","PAM_ENTERPRISE","PREMIUM_ENCRYPTION") |
  Select -ExpandProperty ServicePlanId

$disabledPlans = $userDisabledPlans + $newDisabledPlans | Select -Unique

$addLicenses = @(
  @{SkuId = $EmsSku.SkuId
  DisabledPlans = $disabledPlans
  }
  )

Set-MgUserLicense -UserId '38955658-c844-4f59-9430-6519430ac89b' -AddLicenses $addLicenses -RemoveLicenses @()

Id                                   DisplayName   Mail UserPrincipalName                     UserType
--                                   -----------   ---- -----------------                     --------
38955658-c844-4f59-9430-6519430ac89b Bianca Pisani      BiancaP@contoso.onmicrosoft.com       Member

Результаты в наборе назначенных ServicePlans показаны ниже:

$order = @(
  @{ Expression = 'ProvisioningStatus'; Ascending = $true }
)
Get-MgUserLicenseDetail -UserId '38955658-c844-4f59-9430-6519430ac89b' | Select-Object -ExpandProperty ServicePlans | sort ProvisioningStatus $order

AppliesTo ProvisioningStatus  ServicePlanId                        ServicePlanName
--------- ------------------  -------------                        ---------------
User      Success             2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2 ADALLOM_S_STANDALONE
User      Success             6c6042f5-6f01-4d67-b8c1-eb99d36eed3e STREAM_O365_E5
User      Success             e212cbc7-0961-4c40-9825-01117710dcb1 FORMS_PLAN_E5
User      Success             07699545-9485-468e-95b6-2fca3738be01 FLOW_O365_P3
User      Success             9c0dab89-a30c-4117-86e7-97bda240acd2 POWERAPPS_O365_P3
User      Success             871d91ec-ec1a-452b-a83f-bd76c7d770ef WINDEFATP
User      Success             21b439ba-a0ca-424f-a6cc-52f954a5b111 WIN10_PRO_ENT_SUB
User      Success             57ff2da0-773e-42df-b2af-ffb7a2317929 TEAMS1
User      Success             8c7d2df8-86f0-4902-b2ed-a0458298f3b3 Deskless
User      Success             8e0c0a52-6a6c-4d40-8370-dd62790dcd70 THREAT_INTELLIGENCE
User      Success             4a51bca5-1eff-43f5-878c-177680f191af WHITEBOARD_PLAN3
User      Success             efb0351d-3b08-4503-993d-383af8de41e3 MIP_S_CLP2
User      Success             617b097b-4b93-4ede-83de-5f075bb5fb2f PREMIUM_ENCRYPTION
User      Success             8c098270-9dd4-4350-9b30-ba4703f3b36b ADALLOM_S_O365
Company   Success             94065c59-bc8e-4e8b-89e5-5138d471eaff MICROSOFT_SEARCH
User      Success             14ab5db5-e6c4-4b20-b4bc-13e36fd2227f ATA
User      Success             3fb82609-8c27-4f7b-bd51-30634711ee67 BPOS_S_TODO_3
User      Success             b1188c4c-1b36-4018-b48b-ee07604f6feb PAM_ENTERPRISE
User      Success             5136a095-5cf0-4aff-bec3-e84448b38ea5 MIP_S_CLP1
User      Success             33c4f319-9bdd-48d6-9c4d-410b750a4a5a MYANALYTICS_P2
User      Success             5689bec4-755d-4753-8b61-40975025187c RMS_S_PREMIUM2
User      Success             4828c8ec-dc2e-4779-b502-87ac9ce28ab7 MCOEV
User      Success             9f431833-0334-42de-a7dc-70aa40db46db LOCKBOX_ENTERPRISE
User      Success             3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40 MCOMEETADV
User      Success             43de0ff5-c92c-492b-9116-175376d08c38 OFFICESUBSCRIPTION
User      Success             0feaeb32-d00e-4d66-bd5a-43b5b83db82c MCOSTANDARD
User      Success             70d33638-9c74-4d01-bfd3-562de28bd4ba BI_AZURE_P2
Company   Success             f20fedf3-f3c3-43c3-8267-2bfdd51c0939 ATP_ENTERPRISE
User      Success             4de31727-a228-4ec3-a5bf-8e45b5ca48cc EQUIVIO_ANALYTICS
User      Success             efb87545-963c-4e0d-99df-69c6916d9eb0 EXCHANGE_S_ENTERPRISE
User      Success             34c0d7a0-a70f-4668-9238-47f9fc208882 EXCHANGE_ANALYTICS
User      Success             8a256a2b-b617-496d-b51b-e76466e88db0 MFA_PREMIUM
User      Success             41781fb2-bc02-4b7c-bd55-b576c07bb09d AAD_PREMIUM
User      Success             bea4c11e-220a-4e6d-8eb8-8ea15d019f90 RMS_S_ENTERPRISE
User      Success             eec0eb4f-6444-4f95-aba0-50c24d67f998 AAD_PREMIUM_P2
User      Success             6c57d4b6-3b23-47a5-9bc9-69f17b4947b3 RMS_S_PREMIUM
User      Success             5dbe027f-2339-4123-9542-606e4d348a72 SHAREPOINTENTERPRISE
User      Success             b737dad2-2f6c-4c65-90e3-ca563267e8b9 PROJECTWORKMANAGEMENT
User      Success             e95bec33-7c88-4a70-8e19-b10bd9d0c014 SHAREPOINTWAC
User      Success             7547a3fe-08ee-4ccb-b430-5077c5041653 YAMMER_ENTERPRISE
User      Success             a23b959c-7ce8-4e57-9140-b90eb88a9e97 SWAY
User      Success             c4801e8a-cb58-4c35-aca6-f2dcc106f287 INFORMATION_BARRIERS
User      Success             b76fb638-6ba6-402a-b9f9-83d28acb3d86 VIVA_LEARNING_SEEDED
Company   Success             db4d623d-b514-490b-b7ef-8885eee514de Nucleus
Company   Success             6f23d6a9-adbf-481c-8538-b4c095654487 M365_LIGHTHOUSE_CUSTOMER_PLAN1
User      Success             a82fbf69-b4d7-49f4-83a6-915b2cf354f4 VIVAENGAGE_CORE
User      Success             9a6eeb79-0b4b-4bf0-9808-39d99a2cd5a3 Windows_Autopatch
User      Success             cd31b152-6326-4d1b-ae1b-997b625182e6 MIP_S_Exchange
User      Success             a413a9ff-720c-4822-98ef-2f37c2a21f4c MICROSOFT_COMMUNICATION_COMPLIANCE
User      Success             795f6fe0-cc4d-4773-b050-5dde4dc704c9 UNIVERSAL_PRINT_01
Company   Success             2b815d45-56e4-4e3a-b65c-66cb9175b560 ContentExplorer_Standard
User      Success             7bf960f6-2cd9-443a-8046-5dbff9558365 WINDOWSUPDATEFORBUSINESS_DEPLOYMENTSERVICE
User      Success             3ec18638-bd4c-4d3b-8905-479ed636b83e CustomerLockboxA_Enterprise
User      Success             3efbd4ed-8958-4824-8389-1321f8730af8 MESH_AVATARS_ADDITIONAL_FOR_TEAMS
User      Success             99cd49a9-0e54-4e07-aea1-d8d9f5f704f5 Defender_for_Iot_Enterprise
User      Success             0898bdbb-73b0-471a-81e5-20f1fe4dd66e KAIZALA_STANDALONE
User      Success             c948ea65-2053-4a5a-8a62-9eaaaf11b522 PURVIEW_DISCOVERY
User      Success             a1ace008-72f3-4ea0-8dac-33b3a23a2472 CLIPCHAMP
User      Success             f6de4823-28fa-440b-b886-4783fa86ddba M365_AUDIT_PLATFORM
User      Success             0d0c0d31-fae7-41f2-b909-eaf4d7f26dba Bing_Chat_Enterprise
User      Success             dcf9d2f4-772e-4434-b757-77a453cfbc02 MESH_AVATARS_FOR_TEAMS
User      Success             c4b8c31a-fb44-4c65-9837-a21f55fcabda MICROSOFT_LOOP
User      Success             a6520331-d7d4-4276-95f5-15c0933bc757 GRAPH_CONNECTORS_SEARCH_INDEX
User      Success             e26c2fcc-ab91-4a61-b35c-03cdc8dddf66 INFO_GOVERNANCE
User      Success             46129a58-a698-46f0-aa5b-17f6586297d9 DATA_INVESTIGATIONS
User      Success             9d0c4ee5-e4a1-4625-ab39-d82b619b1a34 INSIDER_RISK_MANAGEMENT
User      Success             65cc641f-cccd-4643-97e0-a17e3045e541 RECORDS_MANAGEMENT
User      Success             d2d51368-76c9-4317-ada2-a12c004c432f ML_CLASSIFICATION
User      Success             bf6f5520-59e3-4f82-974b-7dbbc4fd27c7 SAFEDOCS
User      Success             2f442157-a11c-46b9-ae5b-6e39ff4e5849 M365_ADVANCED_AUDITING
User      Success             41fcdd7d-4733-4863-9cf4-c65b83ce2df4 COMMUNICATIONS_COMPLIANCE
User      Success             6db1f1db-2b46-403f-be40-e39395f08dbb CUSTOMER_KEY
User      Success             6dc145d6-95dd-4191-b9c3-185575ee6f6b COMMUNICATIONS_DLP
User      Success             199a5c09-e0ca-4e37-8f7c-b05d533e1ea2 MICROSOFTBOOKINGS
User      Success             ded3d325-1bdc-453e-8432-5bac26d7a014 POWER_VIRTUAL_AGENTS_O365_P3
Company   Success             d9fa6af4-e046-4c89-9226-729a0786685d Content_Explorer
User      Success             afa73018-811e-46e9-988f-f75d2b1b8430 CDS_O365_P3
User      Success             b21a6b06-1988-436e-a07b-51ec6d9f52ad PROJECT_O365_P3
User      Success             64bfac92-2b17-4482-b5e5-a0304429de3e MICROSOFTENDPOINTDLP
User      Success             bf28f719-7844-4079-9c78-c1307898e192 MTP
User      Success             28b0fa46-c39a-4188-89e2-58e979a6b014 DYN365_CDS_O365_P3
User      Success             d587c7a3-bda9-4f99-8776-9bcf59c84f75 INSIDER_RISK
User      Success             531ee2f8-b1cb-453b-9c21-d2180d014ca5 EXCEL_PREMIUM
User      PendingProvisioning f0ff6ac6-297d-49cd-be34-6dfef97f0c28 MESH_IMMERSIVE_FOR_TEAMS
User      PendingInput        c1ec4a95-1f05-45b3-a911-aa3fa01094f5 INTUNE_A
Company   PendingActivation   882e1d05-acd1-4ccb-8708-6ee03664b117 INTUNE_O365

Объект PrimarySMTPAddress пользователя больше не очищается. Домен northwindtraders.com не принадлежит клиенту contoso.onmicrosoft.com и сохраняется в качестве основного SMTP-адреса, показанного в каталоге.

Пример:

Get-Recipient ProxyTest | Format-Table -AutoSize UserPrincipalName, PrimarySmtpAddress, ExternalEmailAddress, ExternalDirectoryObjectId
UserPrincipalName               PrimarySmtpAddress              ExternalEmailAddress                 ExternalDirectoryObjectId
-----------------               ------------------              --------------------                 -------------------------
ProxyTest@contoso.com          ProxyTest@contoso.com          SMTP:ProxyTest@contoso.com          e2513482-1d5b-4066-936a-cbc7f8f6f817

Если msExchRemoteRecipientType задано значение 8 (DeprovisionMailbox), для локальных пользователей MailUsers, которые переносятся в целевой клиент, логика очистки прокси-сервера в Azure удаляет не принадлежащие домены и сбрасывает основной доменSMTP в принадлежащий домен. После очистки msExchRemoteRecipientType в локальной службе MailUser логика scrub прокси-сервера больше не применяется.

Ниже приведен полный набор текущих планов обслуживания, включающих Exchange Online:

Имя
Хранилище eDiscovery (премиум) (500 ГБ)
Защищенное хранилище пользователя
Защита от потери данных
Exchange Enterprise CAL Services (EOP, DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (план 1)
Exchange Online (план 2)
Exchange Online Archiving для Exchange Online
Exchange Online Archiving для Exchange Server
надстройка "Неактивный пользователь" Exchange Online
Базовая подписка на Exchange Online
Exchange Online с поддержкой нескольких регионов
Exchange Online (план 1)
Exchange Online POP
Exchange Online Protection
Соединители Graph Поиск с индексом
Информационные барьеры
Защита данных для Office 365 — Premium
Защита данных для Office 365 — Standard
Аналитика MyAnalytics
Управление информацией (Майкрософт)
Аудит Microsoft Purview (Премиум)
Microsoft Bookings
Microsoft Business Center
Исследования данных Майкрософт
Microsoft MyAnalytics (полнофункциональная версия)
Соответствие требованиям к коммуникациям Майкрософт
Защита от потери данных о коммуникациях Майкрософт
Ключ клиента Майкрософт
Расширенный аудит Microsoft 365
Управление записями Майкрософт
Office 365 обнаружение электронных данных (премиум)
Office 365 Advanced eDiscovery
Microsoft Defender для Office 365 (план 1)
Microsoft Defender для Office 365 (план 2)
Office 365 Privileged Access Management
Шифрование уровня "Премиум" в Office 365

Сбои миграции

  • MailboxNotInCrossTenantMigrationScopeException

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

  • AuxArchiveNotFoundInTargetRecipientException

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

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Добавление пользователя в новый пакет.

  • MailboxIsNotInExpectedDBException

    Этот сбой связан с внутренним обслуживанием Майкрософт.
    Удалите пользователя миграции из пакета.
    Удалите пользователей с помощью следующей команды:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Добавление пользователя в новый пакет.

  • NotAcceptedDomainException

    Для целевого пользователя указан недопустимый прокси-адрес. Например, у пользователя в contoso.onmicrosoft.com был прокси-адрес fabrikam.onmicrosoft.com, который является исходным клиентом.
    Удалите недопустимый прокси-адрес с помощью следующей команды:

    Set-MailUser LaraN@contoso.onmicrosoft.com -EmailAddress @{remove="smtp:LaraN@northwindtraders.onmicrosoft.com"}

    Возобновление выполнения пакета миграции.

  • SourceAuxArchiveIsProvisionedDuringCrossTenantMovePermanentException

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

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Добавление пользователя в новый пакет.

  • UserDuplicateInOtherBatchException

    Пользователь уже существует в другом пакете.
    Удалите пользователя миграции из пакета.
    Удалите пользователей с помощью следующей команды:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Добавление пользователя в новый пакет.

  • MissingExchangeGuidException

    В целевом объекте mailuser отсутствует правильное значение ExchangeGuid.
    Обновите ExchangeGuid с помощью следующей команды:

    Set-MailUser LaraN@contoso.onmicrosoft.com -ExchangeGuid 4e3188c6-39f5-4387-adc7-b355b6b852c8

    Возобновление выполнения пакета миграции.

  • SourceMailboxAlreadyBeingMovedPermanentException

    Исходный почтовый ящик уже имеет существующий запрос на перемещение. Изучите и удалите существующее перемещение. Возможно, что это внутренний шаг Майкрософт, и вам потребуется дождаться завершения перемещения.
    Удалите пользователя миграции из пакета.
    Удалите пользователей с помощью следующей команды:

    Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser

    Добавление пользователя в новый пакет после удаления или завершения исходного перемещения.

  • UserAlreadyHasDemotedArchiveException

    Ранее у пользователя был архивный почтовый ящик, который был отключен. Выберите один из следующих вариантов, чтобы устранить эту проблему.
    Окончательно удалите отключенный архивный почтовый ящик, это невозможно. Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
    Повторно включите отключенный архивный почтовый ящик с помощью следующей команды:

    Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.

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

См. также