テナント間でのメールボックスの移行

[アーティクル]
02/01/2024

合併または分割中に、ユーザーのExchange Onlineメールボックスを新しいテナントに移動する機能が必要になる場合があります。テナント間メールボックスの移行を使用すると、テナント管理者は、Exchange Online PowerShell や MRS などの既知のインターフェイスを使用して、ユーザーを新しいorganizationに移行できます。

管理者は、メールボックスの移動管理ロールで使用できる New-MigrationBatch コマンドレットを使用して、テナント間の移動を実行できます。

移行するユーザーは、ターゲットテナントExchange Onlineシステムに MailUser として存在し、テナント間の移動を有効にするために特定の属性でマークされている必要があります。ターゲットテナントで適切に設定されていないユーザーの移動がシステムで失敗します。

移動が完了すると、ソースユーザーメールボックスがに MailUser変換され targetAddress 、 (Exchange では ExternalEmailAddress と表示されます) に宛先テナントへのルーティングアドレスがスタンプされます。このプロセスは、移行元テナントにレガシ MailUser を残し、共存とメールルーティングを可能にします。ビジネスプロセスで許可されている場合、ソーステナントはソース MailUser を削除するか、メール連絡先に変換できます。

テナント間の Exchange メールボックスの移行は、ハイブリッドまたはクラウド内のテナント、または 2 つの組み合わせでのみサポートされます。

この記事では、テナント間メールボックス移動のプロセスについて説明し、Exchange Onlineメールボックスのコンテンツ移動に対してソーステナントとターゲットテナントを準備する方法に関するガイダンスを提供します。

重要

任意の種類の保留にされているメールボックスは移行されず、それらのメールボックスの移動はブロックされます。

この機能を使用してメールボックスをテナント間で移行すると、メールボックス内のユーザーに表示されるコンテンツ (メール、連絡先、予定表、タスク、メモ) のみがターゲット (移行先テナント) に移行されます。移行が成功すると、ソースメールボックスが削除されます。この削除は、移行後、移行後、ソーステナントで使用可能、検出可能、またはアクセス可能なソースメールボックスがないことを意味します。

ライセンス

重要

2022 年 11 月の時点で、クロステナントユーザーデータ移行は、Enterprise Agreementのお客様向けの次の Microsoft 365 サブスクリプションプランのアドオンとして利用でき、テナント間の移行に必要です。ユーザーライセンスは移行ごと (1 回限りの料金) であり、ソースまたはターゲットユーザーオブジェクトに割り当てることができます。このライセンスでは、移行OneDrive for Businessについても説明します。詳細については、Microsoft アカウントチームにお問い合わせください。

クロステナントユーザーデータ移行アドオンは、Microsoft 365 Business Basic、Standard、Premium の別の購入として利用できます。Microsoft 365 F1/F3/E3/E5/;Office 365 F3/E1/E3/E5;Exchange Online。SharePoint Online。と OneDrive for Business。

警告

次の手順に進む前に、クロステナントユーザーデータ移行ライセンスを購入または確認しておく必要があります。この手順が完了していない場合、移行は失敗します。 Microsoft では、このライセンス要件の例外を提供していません。

移行するユーザーに適切なライセンスが割り当てられない場合、移行は失敗し、次のようなエラーが表示されます。

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 組織関係でメールボックスの移動アプリケーションを構成するために必要なアクセス許可があることを確認します。

また、ソーステナント内の、メールが有効なセキュリティグループが少なくとも 1 つ必要です。これらのグループは、ソーステナント (またはリソースとも呼ばれます) からターゲットテナントに移動できるメールボックスの一覧のスコープを設定するために使用されます。このスコープを使用すると、移行元テナント管理者は移動する必要がある特定のメールボックスセットを制限またはスコープ設定できるため、意図しないユーザーが移行されるのを防ぐことができます。

10,000 人を超えるユーザーを移行する場合は、最適なパフォーマンスを得るために複数のグループを作成してユーザーリストを格納することをお勧めします。入れ子になったグループはサポートされていますが、推奨されません。

また、Microsoft 365 テナント ID を取得するには、信頼できるパートナー企業 (メールボックスを移動する相手) と通信する必要もあります。このテナント ID は、[ Organization Relationship DomainName ] フィールドで使用されます。

サブスクリプションのテナント ID を取得するには、Microsoft 365 管理センターにサインインし、に移動しますhttps://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties。 テナント ID プロパティのコピー アイコンを選択して、クリップボードにコピーします。

ソース組織とターゲット組織の両方のすべてのユーザーは、適切なExchange Online サブスクリプションでライセンスを取得する必要があります。また、ターゲット側に移行されるすべてのユーザーにクロステナントユーザーデータ移行ライセンスを適用してください。

テナント間メールボックスの移行を有効にする構成手順

注:

最初にターゲット (移行先) を構成する必要があります。これらの手順を完了するために、ソーステナントとターゲットテナントの両方のテナント管理者の資格情報を持っているか、知っている必要はありません。手順は、さまざまな管理者がテナントごとに個別に実行できます。

移行アプリケーションとシークレットを作成することでターゲット (移行先) テナントを準備する

ターゲットテナント管理者の資格情報を使用して、Microsoft Entra 管理センター (https://portal.azure.com) にサインインします。
[Microsoft Entra IDの管理] で、[表示] を選択します。
ナビゲーションウィンドウで、[アプリの登録] を選択します。
[新規登録] を選択します。
[アプリケーションの登録] ページの [サポートされているアカウントの種類] で、[任意の組織のディレクトリ (任意のMicrosoft Entra ディレクトリ - マルチテナント)] を選択します。次に、[ リダイレクト URI (省略可能)] で [ Web] を選択し、「」と入力します https://office.com。次に、[ 登録] を選択します。

ページの右上隅で、アプリが正常に作成されたことを示す通知ダイアログボックスを参照してください。
[ホーム] ページに戻る、[Microsoft Entra ID] に移動し、[アプリの登録] を選択します。
[ 所有アプリケーション] で、作成したアプリを見つけて選択します。
[ 要点] で、 アプリケーション (クライアント) ID をコピーします。ターゲットテナントの URL を作成するには、後でこの情報が必要になります。
ナビゲーションウィンドウで、[ API アクセス許可 ] を選択して、アプリに割り当てられているアクセス許可を表示します。
既定では、 User.Read アクセス許可は作成したアプリに割り当てられますが、メールボックスの移行にはこれらのアクセス許可は必要ありません。これらのアクセス許可は削除できます。
メールボックスの移行のアクセス許可を追加するには、[アクセス許可を追加する] を選択します。
[API のアクセス許可の要求] ウィンドウで、organizationが使用する API を選択し、をOffice 365 Exchange Online検索して選択します。
[アプリケーションのアクセス許可] を選択します。
[ アクセス許可の選択] で[ メールボックス ] を展開し、[ メールボックス.移行] を選択し、画面の下部にある [ アクセス許可の追加 ] を選択します。
次に、アプリケーションのナビゲーションウィンドウで [ 証明書 & シークレット ] を選択します。
[ クライアントシークレット] で、[ 新しいクライアントシークレット] を選択します。
[ クライアントシークレットの追加] ウィンドウで 説明を入力し、有効期限設定を構成します。

注:

パスワードは、移行エンドポイントを作成するときに使用されます。このパスワードをクリップボードや安全なパスワードの安全な場所にコピーすることが非常に重要です。シークレット作成ステージは、このパスワードを確認できる唯一の時間です。何らかの方法で紛失した場合、またはリセットする必要がある場合は、Azure portalにサインインし、アプリの登録に移動し、移行アプリを見つけ、[シークレット] & 証明書を選択して、アプリの新しいシークレットを作成できます。

移行アプリケーションとシークレットを正常に作成したので、次の手順はアプリケーションに同意することです。

Microsoft Entra IDランディングページで、ナビゲーションウィンドウで [エンタープライズアプリケーション] を選択し、作成した移行アプリを見つけて選択し、[API のアクセス許可] を選択します。
[ テナント] の [管理者の同意の付与] を選択します。新しいブラウザーウィンドウが開きます。
[同意する] を選択します。
ポータルウィンドウに戻るし、[更新] を選択して同意を確認します。
信頼されたパートナー (ソーステナント管理者) に送信する 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

注:

作成したメールボックス移行アプリのアプリケーション ID が必要です。上記の例の contoso.onmicrosoft.com を、ソーステナントの正しい onmicrosoft.com 名に置き換える必要があります。 [application_id_of_the_app_you_just_created] を、先ほど作成したメールボックス移行アプリのアプリケーション ID に置き換える必要もあります。

Exchange Online の移行エンドポイントおよび組織の関係を作成することでターゲットテナントを準備する

ターゲット Exchange Online テナントExchange Online PowerShell に接続します。
テナント間メールボックス移動用の新しい移行エンドポイントを作成します。

注:

先ほど作成したメールボックス移行アプリのアプリケーション ID と、「移行アプリケーションとシークレットを作成してターゲット (宛先) テナントを準備する」で構成したパスワード (シークレット) が必要です。使用する Microsoft 365 クラウドインスタンスによっては、エンドポイントが異なる場合があります。「Microsoft 365 エンドポイント」ページを参照してください。テナントの適切なインスタンスを選択します。次に、Exchange Onlineの最適化/必須アドレスを確認し、必要に応じて置き換えます。
```
# 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
```

新しいorganizationリレーションシップオブジェクトを作成するか、既存のorganizationリレーションシップオブジェクトをソーステナントに編集します。

$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
}

移行アプリケーションを受け入れ、organization関係を構成して、ソース (現在のメールボックスの場所) テナントを準備する

ブラウザーを使用して、信頼されたパートナーが提供する 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

注:

作成したメールボックス移行アプリのアプリケーション ID が必要です。前の例では、ソーステナントの onmicrosoft.com URL に置き換えるcontoso.onmicrosoft.com必要があります。 [application_id_of_the_app_you_just_created] を、先ほど作成したメールボックス移行アプリのアプリケーション ID に置き換える必要もあります。
ポップアップが表示されたら、アプリケーションを受け入れます。 Microsoft Entra 管理センターにサインインし、[エンタープライズアプリケーション] でアプリケーションを見つけることもできます。
ソース Exchange Online テナントExchange Online PowerShell に接続します。

新しいorganizationリレーションシップオブジェクトを作成するか、既存のorganizationリレーションシップオブジェクトを、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 として入力するテナント ID は、テナントドメイン名ではなく GUID です。テナント ID の例と、テナント ID の検索については、「Microsoft 365 テナント ID を見つける」を参照してください。

移行のためにターゲットユーザーオブジェクトを準備する

移行するユーザーは、ターゲットテナントに存在し、(MailUser として) 特定の属性でマークされたシステムExchange Onlineして、テナント間の移動を有効にする必要があります。ターゲットテナントで適切に設定されていないユーザーは、システムによって移動されません。 [ ターゲットユーザーオブジェクトの前提条件] セクションでは、ターゲットテナントの MailUser オブジェクトの要件について詳しくは、こちらをご覧ください。

ターゲットユーザーオブジェクトの前提条件

ターゲット organizationで次のオブジェクトと属性が設定されていることを確認します。

ヒント

Microsoft では、多くの属性を設定する安全な自動メソッドを提供する機能を開発しています (このセクションでは、以下で指定します)。クロステナント ID マッピングという名前のこの機能は、現在、小規模なプライベートプレビューに参加する顧客を探しています。このプレリリース機能と、クロステナント移行プロセスを簡略化する方法の詳細については、「テナント間 ID マッピング」を参照してください。

ソース organizationから移動するすべてのメールボックスの場合は、ターゲット organizationで MailUser オブジェクトをプロビジョニングする必要があります。

Target MailUser には、ソースメールボックスからこれらの属性を持っているか、新しい User オブジェクトを使用して割り当てられている必要があります。

ExchangeGUID (ソースからターゲットへの直接フロー): メールボックス GUID が一致する必要があります。この属性がターゲットオブジェクトに存在しない場合、移動プロセスは続行されません。
ArchiveGUID (ソースからターゲットへの直接フロー): アーカイブ GUID が一致する必要があります。この属性がターゲットオブジェクトに存在しない場合、移動プロセスは続行されません。 (この属性は、ソースメールボックスがアーカイブが有効になっている場合にのみ必要です)。
LegacyExchangeDN (flow as proxyAddress, "x500:<LegacyExchangeDN>"): LegacyExchangeDN は、ターゲット MailUser に x500: proxyAddress として存在する必要があります。 さらに、ソースメールボックスからターゲットメールユーザーにすべての x500 アドレスをコピーする必要もあります。 これらの x500 アドレスがターゲットオブジェクトに存在しない場合、移動プロセスは続行されません。また、移行前に送信されたメールの返信機能を有効にするには、この手順が重要です。各メールアイテムの送信者/受信者アドレスと、Microsoft Outlook と Microsoft Outlook Web App (OWA) の自動完了キャッシュでは、LegacyExchangeDN 属性の値が使用されます。 LegacyExchangeDN 値を使用してユーザーを配置できない場合、電子メールメッセージの配信が 5.1.1 NDR で失敗する可能性があります。
UserPrincipalName: UPN は、ユーザーの新しい ID またはターゲット企業 (たとえば) user@northwindtraders.onmicrosoft.comに合わせて調整されます。
プライマリ SMTPAddress: プライマリ SMTP アドレスは、ユーザーの新しい会社 (たとえば) user@northwindtraders.comに合わせて調整されます。
TargetAddress/ExternalEmailAddress: MailUser は、ソーステナントでホストされているユーザーの現在のメールボックス (たとえば user@contoso.onmicrosoft.com) を参照します。この値が割り当てられている場合は、PrimarySMTPAddress も割り当てられている/割り当て中であることを確認します。それ以外の場合、この値によって PrimarySMTPAddress が設定され、移動エラーが発生します。

ソースメールボックスからターゲット MailUser にレガシ smtp プロキシアドレスを追加することはできません。たとえば、NORTHWINDTRADERS.ONMICROSOFT.COM テナントオブジェクトの MEU で contoso.com を維持することはできません。ドメインは、1 つのMicrosoft Entra IDまたはExchange Onlineテナントにのみ関連付けられます。

ターゲット MailUser オブジェクトの例:

属性	値
Alias	LaraN
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 管理グループ (FYDIBOHF23SPDLT)/cn=Recipients/cn=74e5385fce4b46d19006876949855035-Lara
EmailAddresses	x500:/o=First Organization/ou=Exchange 管理グループ (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
	Smtp：LaraN@northwindtraders.onmicrosoft.com
	Smtp：Lara.Newton@northwindtraders.com
	X500:/o=ExchangeLabs/ou=Exchange 管理グループ (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

ソース メールボックスオブジェクトの例:

属性	値
Alias	LaraN
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 管理グループ (FYDIBOHF23SPDLT)/cn=Recipients/cn=d11ec1a2cacd4f81858c81907273f1f9-Lara
EmailAddresses	Smtp：LaraN@contoso.onmicrosoft.com
	Smtp：Lara.Newton@contoso.com
	X500:/o=ExchangeLabs/ou=Exchange 管理グループ (FYDIBOHF23SPDLT)/cn=Recipients/cn=f161af74128f460fba5c0c23984b3d6c-Lara

その他の属性は、既に Exchange ハイブリッドライトバックに含まれている可能性があります。含まれていない場合は、含める必要があります。
1. msExchBlockedSendersHash– クライアントからオンラインでブロックされた送信者データをオンプレミスの Active Directoryに書き戻します。
2. msExchSafeRecipientsHash– クライアントからオンラインの安全な受信者データをオンプレミスの Active Directoryに書き戻します。
3. msExchSafeSendersHash– クライアントからオンプレミスの Active Directoryにオンラインの差出人データを書き戻します。
ターゲット組織のユーザーは、組織に適用される適切な Exchange Online サブスクリプションを使用してライセンスを取得する必要があります。メールボックスの移動の前にライセンスを適用できますが、対象の MailUser が ExchangeGUID とプロキシアドレスで適切に設定された場合にのみ適用できます。 ExchangeGUID を適用する前にライセンスを適用すると、ターゲット organizationに新しいメールボックスがプロビジョニングされます。クロステナントユーザーデータ移行ライセンスも適用する必要があります。それ以外の場合は、一時的なエラーの読み取りには 承認が必要です。これにより、移動レポートに、ライセンスがターゲットユーザーに適用されていないことを示す警告が報告されます。

注:

Mailbox または MailUser オブジェクトにライセンスを適用すると、すべての SMTP 型 proxyAddresses がスクラブされ、検証済みのドメインのみが Exchange EmailAddresses 配列に含まれていることが確認されます。
ターゲット 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 を更新する

メールボックスがソースからターゲットに移動したら、ソースとターゲットの両方でオンプレミスのメールユーザーが新しい targetAddress で更新されるようにする必要があります。この例では、移動で使用される targetDeliveryDomain が northwindtraders.onmicrosoft.com されています。この targetAddress を使用してメールユーザーを更新します。

移行後にエンドポイントとorganization関係を削除する

Remove-MigrationEndpoint コマンドレットを使用して、移行が完了した後で、移行元または移行先サーバーの既存の移行エンドポイントを削除します。

Remove-OrganizationRelationship コマンドレットを使用して、移行が完了した後にソースサーバーまたは移行先サーバーの既存のorganizationリレーションシップを削除します。

よく寄せられる質問

移動後に、ソースオンプレミステナントの RemoteMailboxes を更新する必要がありますか?

ソース Exchange 組織

ソーステナントメールボックスがターゲットテナントに移動したときに、各ソースオンプレミスユーザーの targetAddress (RemoteRoutingAddress/ExternalEmailAddress) を更新する必要があります。メールルーティングは、異なる targetAddresses を持つ複数のメールユーザー間の紹介に従うことができますが、メールユーザーの空き時間情報の参照はメールボックスユーザーの場所をターゲットにする 必要があります 。

ターゲット Exchange 組織

ハイブリッド organizationで移行が完了したら、ユーザーにリモートメールボックスをオンプレミスにしたい場合は、次の PowerShell コマンドを実行します。

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

Teams 会議はテナント間を移行しますか?

Teams 会議が移動されている間、アイテムがテナント間を移行しても、会議 URL は更新されません。ターゲットテナントでは URL が無効になるため、Teams 会議を削除して再作成する必要があります。

テナント間で移行されるコンテンツは何ですか?

この機能を使用してメールボックスがテナント間で移行されると、メールボックス内のユーザーが表示できるコンテンツ (情報ストアのトップ (電子メール、連絡先、予定表、タスク、メモ) と呼ばれる) のみが移行され、[回復可能なアイテム] フォルダーの削除、バージョン、消去が移行されます。

Outbox 内のアイテムはクロステナントに移行されますか?

このフォルダーは Outlook クライアントに固有のクライアントベースのフォルダーであるため、Outbox 内のアイテムはテナント間で移行されません。 Outbox 内の項目はローカルに保存され、クラウドに同期されません。

Teams チャットフォルダーのコンテンツはテナント間で移行されますか?

いいえ。Teams チャットフォルダーのコンテンツはテナント間を移行しません。ただし、メールボックスがテナント間で移行されると、Teams チャットフォルダーのコンテンツは、ソーステナント管理者がコンテンツ検索を使用して検索およびエクスポートできるようになります。

オンボードとオフボーディングの移動ではなく、テナント間の移動である移動だけを確認するにはどうすればよいですか?

Flags パラメーターを使用します。

Get-MoveRequest -Flags "CrossTenant"

テストで使用される属性をコピーするためのスクリプトの例を指定できますか?

注:

SAMPLE – AS IS, NO WARRANTY このスクリプトは、ソースメールボックス (ソース値を取得する) とターゲットオンプレミスの Active Directory Domain Services (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

ユーザーメールボックスを移動した後、1 日目に Outlook にアクセスするにはどうすればよいですか?

ドメインを所有できるテナントは 1 つだけであるため、メールボックスの移動が完了しても、以前のプライマリ SMTPAddress はターゲットテナント内のユーザーに関連付けられません。新しいテナントに関連付けられているドメインのみ。 Outlook では、ユーザーの新しい UPN を使用してサービスに対する認証を行い、Outlook プロファイルは、ターゲットシステム内のメールボックスと一致する従来のプライマリ SMTPAddress を見つけることを想定しています。レガシアドレスはターゲットシステムに存在しないため、Outlook プロファイルは接続せず、新しく移動されたメールボックスを見つけます。

この初期デプロイでは、ユーザーは新しい UPN、プライマリ SMTP アドレスでプロファイルを再構築し、OST コンテンツを再同期する必要があります。

注:

完了のためにユーザーをバッチ処理する際に、それに応じて計画します。 Outlook クライアントプロファイルが作成され、後続の OST ファイルと OAB ファイルがクライアントにダウンロードされるときに、ネットワーク使用率と容量を考慮する必要があります。

テナント間の移動を設定または完了するには、どの Exchange RBAC ロールのメンバーである必要がありますか?

メールボックスの移動を実行するときの委任された職務の前提に基づいて、ロールのマトリックスがあります。現時点では、次の 2 つのロールが必要です。

最初のロールは、テナント/組織の境界との間でコンテンツを移動する承認を確立する 1 回限りのセットアップタスクです。組織の管理からデータを移動することは、すべての企業にとって重要な懸念事項であるため、 組織管理者の最も割り当てられた最高の役割を選択しました。このロールは、リモート organizationで設定を定義する新しい OrganizationRelationship を-MailboxMoveCapability変更または設定する必要があります。 organization管理者のみが設定を-MailboxMoveCapability変更できますが、OrganizationRelationship の他の属性はフェデレーション共有管理者によって管理できます。
実際の移動コマンドを実行するロールは、下位レベルの関数に委任できます。 メールボックスの移動の役割は、メールボックスをorganization内または外に移動する機能に割り当てられます。

変換されたメールボックス (MailUser への変換) で targetAddress (TargetDeliveryDomain) に選択されている SMTP アドレスをターゲットにする方法

Exchange メールボックスは、MRS を使用して移動します。ターゲットオブジェクトのメールアドレス (proxyAddress) を照合して MailUser に変換するときに、元のソースメールボックスの targetAddress を作成します。このプロセスは、コマンドに渡された値を受け取 -TargetDeliveryDomain り、ターゲット側でそのドメインの一致するプロキシをチェックします。一致するものが見つかると、一致する proxyAddress を使用して、変換されたメールボックス (現在は MailUser) オブジェクトの ExternalEmailAddress (targetAddress) を設定します。

移行後のメールフローのしくみ

移行後のテナント間メールフローは、Exchange ハイブリッドメールフローと同様に機能します。移行された各メールボックスでは、ソーステナントからターゲットテナント内のメールボックスに受信メールを転送するために、正しいターゲットアドレスを持つソース MailUser が必要です。トランスポートルール、セキュリティ、コンプライアンス機能は、メールが流れる各テナントで構成されたとおりに実行されます。そのため、受信メールの場合、スパム対策、マルウェア対策、検疫、トランスポートルール、ジャーナリングルールなどの機能は、最初にソーステナントで実行され、次にターゲットテナントで実行されます。

メールボックスのアクセス許可はどのように切り替えますか?

メールボックスのアクセス許可には、代理送信とメールボックスアクセスが含まれます。

Send On Behalf Of (AD:publicDelegates) は、ユーザーのメールボックスへのアクセス権を持つ受信者の DN を代理人として格納します。この値は Active Directory に格納され、現在、メールボックスの移行の一部として移動されません。ソースメールボックスに publicDelegates が設定されている場合は、を実行 Set-Mailbox <principle> -GrantSendOnBehalfTo <delegate>してターゲット環境で MEU からメールボックスへの変換が完了したら、ターゲットメールボックスの publicDelegates を再サンプリングする必要があります。
メールボックスに格納されているメールボックスのアクセス許可は、プリンシパルと代理人の両方がターゲットシステムに移動されると、メールボックスと共に移動します。たとえば、ユーザー TestUser7 には、テナント SourceCompany.onmicrosoft.com 内のメールボックス TestUser_8への FullAccess が付与されます。メールボックスが完全に TargetCompany.onmicrosoft.com に移動すると、ターゲットディレクトリに同じアクセス許可が設定されます。ソーステナントとターゲットテナントの両方でTestUser_7に _Get-MailboxPermission を使用する例を次に示します。 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

注:

テナント間メールボックスと予定表のアクセス許可はサポートされていません。これらの接続されたメールボックスがソーステナントから同時に移行されるように、プリンシパルとデリゲートを統合された移動バッチに整理する必要があります。

移行を有効にするために、ターゲットの MailUser プロキシアドレスに追加する必要がある X500 プロキシは何ですか?

テナント間メールボックスの移行では、ソースメールボックスオブジェクトの LegacyExchangeDN 値を、ターゲット MailUser オブジェクトの x500 メールアドレスとしてスタンプする必要があります。

例:

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 のターゲットドメイン)。

共有メールボックスは移動しても引き続き機能しますか?

はい。ただし、ストアのアクセス許可は、この記事の説明に従ってのみ保持されます。

Exchange Onlineで受信者のアクセス許可を管理する

バッチに関する推奨事項はありますか?

バッチあたり 2,000 個のメールボックスを超えないでください。同期中にエンドユーザーに影響がないため、カットオーバー日の 2 週間前にバッチを送信することを強くお勧めします。 50,000 を超えるメールボックスの数量に関するガイダンスが必要な場合は、のエンジニアリングフィードバック配布リスト crosstenantmigrationpreview@service.microsoft.comにアクセスできます。

Microsoft Purview カスタマーキーでサービス暗号化を使用する場合はどうすればよいですか?

メールボックスは移動前に暗号化解除されます。引き続き必要な場合は、ターゲットテナントで Customer Key が構成されていることを確認します。詳細については、「こちら」をご覧ください。

移行の推定時間は何ですか?

移行の計画を立てるのに役立つ、一括メールボックスの移行または個々の移行が完了するタイミングに関するガイドラインを次の表に示します。これらの見積もりは、以前の顧客移行のデータ分析に基づいています。すべての環境が一意であるため、正確な移行速度は異なる場合があります。

移行元テナントのドキュメントを、移行先テナントのユーザーによって保護します。**

テナント間移行では、メールボックスデータのみが移行され、それ以外は移行されません。他にも複数のオプションがあります。これは、次のブログ投稿に記載されています。

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

移行元テナントと同じラベルを移行先テナントに含めることができます。これは、組織間の配置に応じて、移行されたユーザーのラベルの唯一のセットまたは追加のラベルセットとして使用できます。**

テナント間の移行ではラベルがエクスポートされないため、テナント間でラベルを共有する方法がないため、この目的を達成できるのは、移行先テナントでラベルを再作成することだけです。

Microsoft 365 グループの移動をサポートしていますか?

現在、テナント間メールボックスの移行機能では、Microsoft 365 グループの移行はサポートされていません。

メールボックスが新しい/ターゲットテナントに移行された後、ソーステナント管理者はメールボックスに対して電子情報開示検索を実行できますか?

いいえ。テナント間メールボックスの移行後、移行されたユーザーのメールボックスに対する電子情報開示はソースで機能しません。この電子情報開示エラーは、メールボックスがターゲットテナントに移行され、ターゲットテナントに属しているため、検索するメールボックスがソースに存在しなくなったためです。メールボックス移行後の電子情報開示は、ターゲットテナント (メールボックスが存在する場所) でのみ実行できます。移行後にソースメールボックスのコピーをソーステナントに保持する必要がある場合、ソーステナントの管理者は、データに対する将来の電子情報開示操作のために、移行前の代替メールボックスにコンテンツをコピーできます。

どの時点で、宛先 MailUser は宛先メールボックスに変換され、ソースメールボックスはソース MailUser に変換されますか?

これらの変換は、移行プロセス中に自動的に行われます。手動の手順は必要ありません。

移行先の MailUsers にExchange Online ライセンスを割り当てる手順はどれですか?

このライセンスの割り当ては、移行が完了する前に行うことができますが、 ExchangeGUID 属性をスタンプする前にライセンスを割り当ててはいけません。それ以外の場合、MailUser オブジェクトからメールボックスへの変換は失敗し、代わりに新しいメールボックスが作成されます。このリスクを軽減するには、移行が完了するまで待ち、30 日間の猶予期間にライセンスを割り当てることをお勧めします。

オンプレミスの Active Directoryを維持している場合、Microsoft Entra Connect を使用してユーザーを新しいテナントに同期することはできますか?

はい。 Microsoft Entra Connect の 2 つのインスタンスを異なるテナントに同期させることが可能です。ただし、次の点に注意する必要があります。

この記事で提供されているスクリプトを使用してユーザーのアカウントを事前プロビジョニングしないでください。代わりに、移行のスコープ内のユーザーの選択的 OU 同期を実行して、ターゲットテナントを設定できます。 Microsoft Entra接続構成中に UPN が一致しないことに関する警告が表示されます。
ハイブリッド Exchange の現在の状態に応じて、別のテナントとの同期を試みる前に、オンプレミスのディレクトリオブジェクトに必要な属性 (msExchMailboxGUID や proxyAddresses など) が正しく設定されていることを確認する必要があります。それ以外の場合は、二重メールボックスと移行エラーに関する問題が発生します。
カットオーバー移行中にカスタムドメインを移動する場合を除き、ユーザーの移行が完了したら、UPN 移行をオンプレミスで変更するための追加の手順を実行する必要があります。

クォータに近い、またはクォータ超過のメールボックスを処理する方法。

移行前にクォータに近づくメールボックスは、実際の移行の前または実行中にクォータを超える可能性があります。この場合、これらのメールボックスは移行に失敗し、修復して再起動する必要があります。これを軽減するには、移行前にソーステナント管理者がクォータ付近のメールボックスを特定し、メールボックスのサイズを小さくするか、プライマリアーカイブをプロビジョニングするか、場合によってはユーザーのメールボックスのアーカイブの自動拡張を有効にするための必要な手順を実行することをお勧めします。

注:

ユーザーのアーカイブまたは自動展開アーカイブを有効にしたら、適切なアーカイブポリシーがユーザーに適用され、メールボックスデータを新しい場所に移動して空き領域を増やすためにプロセスが実行されていることを確認します。

自動展開されたアーカイブメールボックスは移動しますか?

問題: 自動拡張アーカイブを移行できません。 はい。ソースのユーザーが自動拡張アーカイブを有効にしており、追加の補助アーカイブがある場合は、テナント間メールボックスの移行が機能します。 12 個以下の補助アーカイブメールボックスを持つユーザーの移動をサポートします。さらに、大規模なプライマリ、大きなメインアーカイブ、および大規模な補助アーカイブメールボックスを持つユーザーは、同期に余分な時間が必要であり、カットオーバー日の前に送信する必要があります。メールボックスの移行プロセス中にソースメールボックスが展開された場合、移行は失敗します。新しい補助アーカイブはソースに作成されますが、ターゲットには作成されません。この場合は、ユーザーをバッチから削除して再送信する必要があります。

クロスクラウドテナントからテナントへの移行を実行できますか?

クラウドテナント間の移行はサポートされていません。シナリオの例としては、Office 365 Worldwide から Office 365 Government Cloud に移行します。

ボイスメールはテナント間で移行されますか?

はい。ボイスメールはテナント間で移行されます。

添付ファイルとしてメールで受信したボイスメールは、ターゲットメールボックスで使用できます。
受信したボイスメールは、ボイスメールを呼び出して保存されたメッセージをリッスンする場合、Teams で使用できます。 (ソースで受信した VM は、保存されたメッセージとして使用できます)
受信したボイスメールは、移行後のターゲットの Teams クライアント UI では使用できません。
ボイスメールグリーティングもターゲットに移行されます。

メールボックス署名はテナント間で移行されますか?

メールボックス署名はテナント間で移行されないため、再作成する必要があります。

既知の問題

移行後のソーステナントの Teams 機能は制限されます。メールボックスがターゲットテナントに移行されると、ソーステナント内の Teams はユーザーのメールボックスにアクセスできなくなります。ユーザーがソーステナント資格情報を使用して Teams にサインインした場合、プロファイル画像を更新できない、予定表アプリケーションがない、パブリックチームを検索して参加できないなどの機能が失われます。
所有されていない smtp proxyAddress ブロック MRS を持つ Cloud MailUsers の移動。ターゲットテナント MailUser オブジェクトを作成するときは、すべての SMTP プロキシアドレスがターゲットテナント organizationに属していることを確認する必要があります。ローカルテナントに属していないターゲットメールユーザーに SMTP proxyAddress が存在する場合、MailUser からメールボックスへの変換は禁止されます。この防止は、メールボックスオブジェクトがテナントが権限を持つドメイン (テナントによって要求されたドメイン) からのみメールを送信できることを保証しているためです。
ターゲットテナントで Microsoft Entra Connect を使用してオンプレミスからユーザーを同期する場合は、メールボックスが存在するソーステナントを指す ExternalEmailAddress を使用してオンプレミスの MailUser オブジェクトをプロビジョニングし (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 配列に存在しません。
"外部" プライマリ SMTP アドレスを持つ MailUser オブジェクトは、会社が要求した "内部" ドメインに変更またはリセットされます。

MailUser オブジェクトは、ローカル以外のメールボックスへのポインターです。テナント間メールボックスの移行の場合、MailUser オブジェクトを使用して、ソースメールボックス (ターゲット organizationの観点から) またはターゲットメールボックス (ソース organizationの観点から) を表します。 MailUsers には、ディレクトリ内のメールボックスユーザーの表示される SMTP アドレスを表す実際のメールボックス () と primarySMTP アドレスの smtp アドレスを指す ExternalEmailAddress (ProxyTest@northwindtraders.onmicrosoft.comtargetAddress) があります。一部の組織では、プライマリ SMTP アドレスを外部 SMTP アドレスとして表示することを選択します。ローカルテナントによって所有または検証されたアドレスとして (たとえば、contoso.com ではなく、northwindtraders.com として) として表示されます。ただし、ライセンス操作を使用して Exchange サービスプランオブジェクトが MailUser に適用されると、プライマリ SMTP アドレスがローカル organization (contoso.com によって検証されたドメインとして表示されるように変更されます。次の 2 つの考えられる理由があります。
Exchange サービスプランが MailUser に適用されると、Microsoft Entra ID プロセスはプロキシスクラブを適用し、ローカル organizationが別のテナントからメール、なりすまし、またはメールを送信できないようにします。これらのサービスプランを持つ受信者オブジェクトの SMTP アドレスは、アドレスがローカル organizationによって検証されていない場合、削除されます。例の場合と同様に、northwindtraders.com ドメインは contoso.onmicrosoft.com テナントによって検証されません。したがって、スクラブによって、その northwindtraders.com ドメインが削除されます。移行の前後にこれらの外部ドメインを MailUser に保持する場合は、移行が完了した後、または移動前にライセンスを削除するように移行プロセスを変更して、ユーザーに想定される外部ブランドが適用されるようにする必要があります。メールサービスに影響を与えないように、メールボックスオブジェクトが適切にライセンスされていることを確認する必要があります。 contoso.onmicrosoft.com テナントの MailUser のサービスプランを削除するスクリプトの例を次に示します。

注:

次のスクリプトでは、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

が 8 (DeprovisionMailbox) に設定されている場合、ターゲットテナントに移行されるオンプレミスの MailUsers の場合 msExchRemoteRecipientType 、Azure のプロキシスクラブロジックは、所有されていないドメインを削除し、primarySMTP を所有ドメインにリセットします。オンプレミスの MailUser の msExchRemoteRecipientType がクリアされると、プロキシスクラブロジックは適用されなくなります。

Exchange Onlineを含む現在のサービスプランの完全なセットを次に示します。

名前
電子情報開示 (Premium) ストレージ (500 GB)
顧客ロックボックス
データ損失防止
Exchange Enterprise CAL Services (EOP、DLP)
Exchange Essentials
Exchange Foundation
Exchange Online (P1)
Exchange Online (プラン 1)
Exchange Online (プラン 2)
Exchange Online 用の Exchange Online Archiving
Exchange Server 用の Exchange Online Archiving
非アクティブなユーザーアドオンのExchange Online
Exchange Online Kiosk
Exchange Online Multi-Geo
Exchange Online プラン 1
Exchange Online POP
Exchange Online Protection
インデックスを使用したグラフコネクタのSearch
Information Barriers
Information Protection for Office 365 - Premium
Information Protection for Office 365 - Standard
MyAnalytics による分析情報
Microsoft 情報ガバナンス
Microsoft Purview 監査 (Premium)
Microsoft Bookings
Microsoft Business Center
Microsoft データ調査
Microsoft MyAnalytics (フル機能)
Microsoft Communications Compliance
Microsoft Communications DLP
Microsoft カスタマーキー
Microsoft 365 Advanced Auditing
Microsoft Records Management
Office 365電子情報開示 (Premium)
Office 365 Advanced eDiscovery
Microsoft Defender for Office 365 (プラン 1)
Microsoft Defender for Office 365 (プラン 2)
Office 365 Privileged Access Management
Office 365の Premium Encryption

移行エラー

MailboxNotInCrossTenantMigrationScopeException

移行スコープがソーステナントで正しく設定されていること、および MailboxMovesPublishedScopes がターゲットテナントとのorganization関係に設定されていることを確認します。
移行するメールボックスがソーステナントのセキュリティグループに追加されていることを確認します。
ユーザーを正しいセキュリティグループに追加した後、移行バッチを再開します。
AuxArchiveNotFoundInTargetRecipientException

このエラーは、バッチの開始時にユーザーが移行スコープに含まれず、ユーザーがソースに AuxArchive を持っているためです。
ソースターゲットの適切なセキュリティグループにユーザーを追加します。
移行ユーザーをバッチから削除します。
次のコマンドを使用してユーザーを削除します。
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
新しいバッチにユーザーを追加します。
MailboxIsNotInExpectedDBException

このエラーは、Microsoft の内部メンテナンスが原因です。
移行ユーザーをバッチから削除します。
次のコマンドを使用してユーザーを削除します。
```
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

ソースメールボックスには、既存の移動要求が既に存在します。既存の移動を調査して削除します。これは Microsoft の内部移動であり、移動が完了するまで待つ必要がある可能性があります。
移行ユーザーをバッチから削除します。
次のコマンドを使用してユーザーを削除します。
```
Get-MigrationUser -Identity LaraN@contoso.onmicrosoft.com -IncludeAssociatedUsers | Remove-MigrationUser  
```
元の移動が削除または完了した後、新しいバッチにユーザーを追加します。
UserAlreadyHasDemotedArchiveException

ユーザーは、以前に無効にされたアーカイブメールボックスを持っていました。この問題を解決するには、次の 2 つのオプションのいずれかを選択します。
無効になっているアーカイブメールボックスを完全に削除します。これは復元できません。 Set-Mailbox -RemoveDisabledArchive LaraN@contoso.onmicrosoft.com
次のコマンドを使用して、無効になっているアーカイブメールボックスを再度有効にします。
```
Enable-Mailbox -Archive mailbox@contoso.onmicrosoft.com.
```
無効になっているアーカイブメールボックスを再度有効にする場合は、ターゲット mailuser オブジェクトのアーカイブ guid を更新する必要があります。
移行バッチを再開します。

テナント間でのメールボックスの移行

ライセンス

ソースとターゲットのテナントの準備

ソース テナントとターゲット テナントの前提条件

テナント間メールボックスの移行を有効にする構成手順

移行アプリケーションとシークレットを作成することでターゲット (移行先) テナントを準備する

アプリケーションに同意を付与する

Exchange Online の移行エンドポイントおよび組織の関係を作成することでターゲット テナントを準備する

移行アプリケーションを受け入れ、organization関係を構成して、ソース (現在のメールボックスの場所) テナントを準備する

移行のためにターゲット ユーザー オブジェクトを準備する

ターゲット ユーザー オブジェクトの前提条件

設定が適用されたことを確認する方法

メールボックスを元のソースに戻す

メールボックスの移行を実行する

移行バッチを作成する

オンプレミスの MailUsers を更新する

移行後にエンドポイントとorganization関係を削除する

よく寄せられる質問

移動後に、ソースオンプレミステナントの RemoteMailboxes を更新する必要がありますか?

ソース Exchange 組織

ターゲット Exchange 組織

Teams 会議はテナント間を移行しますか?

テナント間で移行されるコンテンツは何ですか?

Outbox 内のアイテムはクロステナントに移行されますか?

Teams チャット フォルダーのコンテンツはテナント間で移行されますか?

オンボードとオフボーディングの移動ではなく、テナント間の移動である移動だけを確認するにはどうすればよいですか?

テストで使用される属性をコピーするためのスクリプトの例を指定できますか?

ユーザー メールボックスを移動した後、1 日目に Outlook にアクセスするにはどうすればよいですか?

テナント間の移動を設定または完了するには、どの Exchange RBAC ロールのメンバーである必要がありますか?

変換されたメールボックス (MailUser への変換) で targetAddress (TargetDeliveryDomain) に選択されている SMTP アドレスをターゲットにする方法

移行後のメール フローのしくみ

メールボックスのアクセス許可はどのように切り替えますか?

移行を有効にするために、ターゲットの MailUser プロキシ アドレスに追加する必要がある X500 プロキシは何ですか?

ソーステナントとターゲット テナントで同じドメイン名を使用できますか?

共有メールボックスは移動しても引き続き機能しますか?

バッチに関する推奨事項はありますか?

Microsoft Purview カスタマー キーでサービス暗号化を使用する場合はどうすればよいですか?

移行の推定時間は何ですか?

移行元テナントのドキュメントを、移行先テナントのユーザーによって保護します。**

移行元テナントと同じラベルを移行先テナントに含めることができます。これは、組織間の配置に応じて、移行されたユーザーのラベルの唯一のセットまたは追加のラベル セットとして使用できます。**

Microsoft 365 グループの移動をサポートしていますか?

メールボックスが新しい/ターゲット テナントに移行された後、ソース テナント管理者はメールボックスに対して電子情報開示検索を実行できますか?

どの時点で、宛先 MailUser は宛先メールボックスに変換され、ソース メールボックスはソース MailUser に変換されますか?

移行先の MailUsers にExchange Online ライセンスを割り当てる手順はどれですか?

オンプレミスの Active Directoryを維持している場合、Microsoft Entra Connect を使用してユーザーを新しいテナントに同期することはできますか?

クォータに近い、またはクォータ超過のメールボックスを処理する方法。

自動展開されたアーカイブ メールボックスは移動しますか?

クロスクラウド テナントからテナントへの移行を実行できますか?

ボイスメールはテナント間で移行されますか?

メールボックス署名はテナント間で移行されますか?

既知の問題

移行エラー

関連項目

フィードバック

フィードバック

その他のリソース

ソーステナントとターゲットテナントの前提条件

Exchange Online の移行エンドポイントおよび組織の関係を作成することでターゲットテナントを準備する

移行のためにターゲットユーザーオブジェクトを準備する

ターゲットユーザーオブジェクトの前提条件

Teams チャットフォルダーのコンテンツはテナント間で移行されますか?

ユーザーメールボックスを移動した後、1 日目に Outlook にアクセスするにはどうすればよいですか?

移行後のメールフローのしくみ

移行を有効にするために、ターゲットの MailUser プロキシアドレスに追加する必要がある X500 プロキシは何ですか?

ソーステナントとターゲットテナントで同じドメイン名を使用できますか?

Microsoft Purview カスタマーキーでサービス暗号化を使用する場合はどうすればよいですか?

移行元テナントと同じラベルを移行先テナントに含めることができます。これは、組織間の配置に応じて、移行されたユーザーのラベルの唯一のセットまたは追加のラベルセットとして使用できます。**

メールボックスが新しい/ターゲットテナントに移行された後、ソーステナント管理者はメールボックスに対して電子情報開示検索を実行できますか?

どの時点で、宛先 MailUser は宛先メールボックスに変換され、ソースメールボックスはソース MailUser に変換されますか?

自動展開されたアーカイブメールボックスは移動しますか?

クロスクラウドテナントからテナントへの移行を実行できますか?