Microsoft 365のメールボックスの移行に関するよくある質問

2024年10月07日 22:43

本記事では、Microsoft 365の移行に関する一般的な質問に加え、併用、偽装、訴訟ホールドなどの手順に関するより具体的な情報およびトラブルシューティングについて説明します。

本ガイドは、各シナリオの移行ガイドと組み合わせて使用してください。

最大ファイルサイズ

MigrationWizでは、移行可能な最大ファイルサイズは、移行タイプと環境によって異なります。ただし、60GBを超えるファイルを移行することはできません。

設定

特定の移行シナリオの設定については、各シナリオの移行ガイドを参照してください。ただし、一部の設定は、複数の移行シナリオに適用されたり、詳細な説明が必要な場合があります。

移行先メールボックスの言語

「移行先メールボックスの言語(Destination mailbox language)」オプションは、Outlook Web Access (OWA)のシステムフォルダー名の言語を設定します。ただし、これはユーザーまたは管理者がメールボックスにログインしたことがない場合に限ります。

メールボックスの言語設定の構成に、MigrationWizのこの詳細オプションは使用しないでください。移行先メールボックスの言語は、次の方法で構成する必要があります。

「msExchMailboxGuid」属性を「Null」に設定する

同期規則エディターで設定することができます。

DirSyncを使用してディレクトリ同期を実行した場合、この設定方法はサポートされていません。
ME-ID Sync、またはME-ID Connectを使用してディレクトリ同期を実行した場合は、サポートされています。

手順

1. 同期規則エディターを管理者として実行します。

2.「In from AD - User Exchange」をクリックして、インバウンドルールタイプを編集します。

3.「変換(Transformations)」を選択します。

4.「msExchMailboxGuid」属性を特定します。

5. 次のように変更します：式(Expression) － msExchMailboxGuid － NULL －「1回のみ適用(Apply Once)」のチェックボックスをオンにする。

6.「 更新(Update)」をクリックします。

7. ME-ID SyncまたはME-ID Connectを有効にして、完全同期を実行します。

これで、ユーザーにExchange Onlineライセンスを割り当て、 MigrationWizを使用して、メールボックスをMicrosoft 365に移行することができるようになります。

アクセスと資格情報

Microsoft 365の移行では、資格情報を管理する方法が複数あります。移行によっては、特定の資格情報管理オプションが必要になります。必要なオプションについては、各移行ガイドを参照してください。本セクションでは、それらのオプションの詳細について説明します。

先進認証

BitTitanは現在、メールボックス移行におけるMicrosoft 365エンドポイントの先進認証をサポートしています。先進認証は、登録されたアプリケーションがMicrosoft EntraおよびMicrosoft 365に接続する際に、より安全な認証メカニズムを提供します。先進認証の詳細については、次のMicrosoftの記事を参照してください。 OAuthを使用してEWSアプリケーションを認証する

前提条件

Microsoft Entraへのアクセス権を持つグローバル管理者アカウント。現時点では、多要素認証および二要素認証はサポートされていません。これらの認証方法が有効になっている場合、管理者アカウントをこれらのポリシーから除外する必要があります。
MigrationWizでメールボックスプロジェクトが作成されており、設定できる状態であること。
アプリケーションには、管理者の同意が必要です。
OneDriveおよびSharePointの移行：管理者アカウントは、従来のレガシー認証を使用してログインし、サイトURLを取得する必要があります。このため、管理者アカウントをベースラインセキュリティポリシーから除外するか、次の記事を参照して、条件付きアクセスを許可する必要があります。一般的な条件付きアクセスポリシー：レガシー認証をブロックする

重要
管理者アカウントを「除外(Exclude)」オプションに追加する必要があります。

登録と設定

移行元および移行先テナントの登録と設定は、ナレッジベース記事のMicrosoft 365(全製品)の移行における認証方法の「MigrationWizとExchange Onlineテナント間でEWSの先進認証を有効化する」セクションを参照してください。

MigrationWizプロジェクトを作成する際は、ここで使用した資格情報と同じ資格情報を使用してください。資格情報は、エンドポイント(移行元と移行先)を設定する際に入力が必要になります。

Destintation Settings.png

フィールドが未入力の場合や、(クライアントまたはテナントの)資格情報が間違っている場合、または資格情報がテナントに属していない場合は、プロジェクトを保存することができません。移行元および移行先エンドポイントのいずれか、または両方に資格情報が提供され、顧客が「保存して概要へ移動」をクリックすると、MigrationWizはエンドポイントの検証を実行します。

この検証では、プロジェクトに入力された管理者資格情報と先進認証の設定のみが検証されます。問題がある場合は、エンドポイント設定画面にリダイレクトされ、エラーメッセージまたはポップアップが表示されます。クリックすると、エラーに関する詳細情報を表示することができます。

エンドポイント構成時の一般的なエラー

詳細については、Exchange OnlineでのEWSの先進認証におけるMigrationWizの最も一般的なエラー(Most Common Errors Encountered in MigrationWiz while using Modern Authentication for EWS in Exchange Online)の記事の「AADSTS700016」、「AADSTS90002」、および「 ADDSTS50126」の説明を参照してください。

「アプリケーション(クライアント)ID」フィールドと「ディレクトリ(テナント)ID」フィールドは、必ず入力してください。入力しないと、以下の警告が表示され、次の手順に進むことができません。

Application and Directory ID issues.png

この問題は、移行元または移行先のエンドポイントを構成する時に発生します。

移行元の設定のアプリケーション(クライアント)IDが無効です(Invalid Application Client ID at Source Settings)

アプリケーション(クライアント)IDが設定されているか、そのIDが正しいかどうかを確認してください。詳細については、AADSTS700016を参照してください。

移行元の設定のディレクトリ(テナント)IDが無効です(Invalid Directory Tenant ID at Source Settings)

ディレクトリ(テナント)IDが設定されているか、そのIDが正しいかどうかを確認してください。詳細については、AADSTS90002を参照してください。

移行元の設定またはクライアントの設定で、ユーザー名またはパスワードが無効であった場合、警告が表示されます。資格情報が正しいことを確認してください。

2023-12-08_8-19-12Administration Credentials Issues.png

詳細については、ADDSTS50126を参照してください。

メールボックスへのアクセスを検証する

メールボックスへのアクセスを検証するには、次の手順を実行します。

https://login.microsoftonline.comにアクセスします。
管理者のメールアドレスでログインします。
MigrationWizで指定したパスワードを入力します。
管理ポータルに入ります。
「ユーザー(Users)」、「アクティブなユーザー(Active Users)」の順にクリックします。
MigrationWizプロジェクトに追加したユーザーを検索して、MigrationWizで指定した管理者のメールアドレスとエンドユーザーのメールアドレスのスペルが間違っていないことを確認します。
すべてのユーザーにライセンスが割り当てられていることを確認します(F1 Microsoft 365ライセンスを使用する場合は、こちらを参照してください)。移行元システム上のすべてのメールボックスは、Microsoft 365のメールユーザーとして移行先に作成されます。メールユーザーにライセンスを割り当てると、メールボックスユーザーになります。データを移行するには、移行先にメールボックスが必要です。
偽装を使用していない場合は、管理者アカウントにライセンスが割り当てられていることを確認します。このライセンスは、一時的な試用ライセンスでも構いません。
ユーザーを削除して再作成した場合は、Microsoft 365ポータルの「削除されたユーザー(Deleted Users)」タブからユーザーが完全に削除されていることを確認してください。

最初にPowerShellを使用して、完全な削除を実行する必要があります。Azure Active Directory v2 PowerShellモジュールがインストールされていない場合は、ダウンロードしてインストールします。

次のPowerShellコマンドを実行します。

Import-Module -Name MSOnline

$LiveCred = Get-Credential

Connect-MsolService -Credential $LiveCred

Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

これらのPowerShellコマンドにより、ごみ箱内の削除されたユーザーが完全に削除されます。
「Outlook」タブをクリックしてOWAを開き、エンドユーザーのメールボックスを開くことができることを確認します。
ユーザーの作成後、Microsoft 365でレプリケーション遅延が発生する場合があります。
移行プロジェクトが開始されると、MigrationWizはMicrosoft 365 PowerShellコマンドを実行して、管理者アカウントにメールボックスへのアクセス権限を(偽装を使用して)自動的に付与しようと試みます。これらのMicrosoft 365 PowerShellコマンドは、場合によっては機能しないことがあります。失敗した場合は、手動で実行することにより、問題は解決されます。偽装を有効にする方法については、Microsoft 365およびExchangeでの移行におけるMigrationWizの偽装と委任の記事を参照してください。
偽装を使用せずに10を超えるメールボックスを移行すると、スロットリングが発生する可能性があります。偽装を有効にすることをお勧めしますが、デフォルトでは、管理者アカウントにはユーザーアカウントを偽装する権限が付与されていないため、注意が必要です。MigrationWizでは、内部的に偽装権限の付与を行いますが、非常に時間がかかるため、タイムアウトになる可能性があります。次のいずれかの方法を実行します。

Microsoft 365およびExchangeでの移行におけるMigrationWizの偽装と委任
30分待って、再度移行を実行します。

共有メールボックス

共有メールボックスは、通常のメールボックス移行と同様の方法で移行します。

管理者資格情報を使用して移行する場合： MigrationWizダッシュボードで、「クイック追加(Quick Add)」ボタンをクリックし、移行元の共有メールボックスのメールアドレスと移行先の共有メールボックスのメールアドレスを入力します。移行を実行すると、プロジェクトの作成時に指定した管理者資格情報を使用して、移行が行われます。移行の実行には、管理者アカウントに共有メールボックスへのフルアクセス権限が付与されている必要があります。ユーザーの「一括追加」を行う場合は、メールボックスをMigrationWizダッシュボードにインポートする際に使用するCSVファイルに、共有メールボックスを含めてください。
管理者資格情報を使用せずに移行する場合： MigrationWizダッシュボードで、「クイック追加(Quick Add)」ボタンをクリックし、「移行元(SOURCE)」の箇所に、共有メールボックスのメールアドレスを入力し、その共有メールボックスの所有者またはフルアクセス権限を持つアカウントのログイン名とパスワードを入力します。さらに、「移行先(DESTINATION)」の箇所に、共有メールボックスのメールアドレスを入力し、その共有メールボックスの所有者またはフルアクセス権限を持つアカウントのログイン名とパスワードを入力します。

ログイン名とパスワードは、管理者資格情報を使用せずにMigrationWizプロジェクトを作成した場合にのみ入力することができます。

Microsoft 365で共有メールボックスを作成および使用する方法の詳細については、Microsoftの記事、共有メールボックスを作成するを参照してください。

通常のメールボックス移行と同様に、移行の実行には「メールボックスライセンス(Mailbox License)」または「ユーザー移行バンドル(User Migration Bundle)」ライセンスを購入する必要があります。

共有メールボックスを使用すると、特定のユーザーのグループが共通のアカウントを使用して、簡単に、メールを監視したり、「info@mining88.com」や「contact@mining88.com」というようなパブリックメールアドレスからメールを送信できるようになります。グループ内のユーザーが、共有メールボックスに送信されたメッセージに返信すると、そのメールは、ユーザー個人からではなく共有メールボックスから送信されたように見えます。

組織内の複数のユーザーが、メールボックスの監視と問い合わせへの対応の責任を共有できることから、共有メールボックスは、顧客からの問い合わせメールを処理する優れた方法です。顧客の問い合わせへの迅速な回答が可能となり、関連するすべてのメールが1つのメールボックスに保存されます。

共有メールボックスは、退職した従業員のメールボックスのコンテンツを保存するのにも最適です。

50GBのストレージ容量を超えない限り、Microsoft 365の共有メールボックスにライセンスを割り当てる必要はありません。

共有メールボックスは、バックエンドでユーザー個人のメールボックスと同じように処理されます。共有メールボックス用のユーザーが作成され、ユーザーリストに追加されます。

ユーザーが作成したフォルダーの権限を移行する

MigrationWizは、デフォルトではシステムフォルダーのメールボックスフォルダーの権限のみを移行します。ユーザーが作成したフォルダーの権限を移行するには、プロジェクトに詳細オプションの「MustMigrateAllPermissions=1」を設定する必要があります。

権限をスキャンすると移行速度が低下するため、この設定はベストプラクティスではなく、あくまでも任意です。

デフォルトまたは匿名のユーザーアカウントの権限は、移行されません。

Microsoft 365 FI(旧キオスク)ユーザー

移行先がキオスクユーザーの場合は、偽装権限を持つ管理者アカウントを使用して、移行プロジェクトを構成する必要があります。これにより、EWS経由で直接接続することができないキオスクユーザーの制限を回避することができます。

移行プロジェクトがキオスクユーザーへの移行用に正しく構成されていることを確認するには、次の手順を実行します。

管理者資格情報を指定します。

MigrationWizアカウントにサインインします。
「マイ・プロジェクトへ」ボタンをクリックします。
変更が必要なプロジェクトを選択します。
「プロジェクトの編集」ボタンをクリックします。
ドロップダウンメニューから、「プロジェクトの編集」をクリックします。
「移行先の設定(DESTINATION SETTINGS)」を選択します。
「資格情報を提供する(Provide Credentials)」を選択して、資格情報を入力します。
「保存(Save)」ボタンをクリックします。
偽装を有効にします。

1. 「プロジェクトの編集」ボタンをクリックします。
2. ドロップダウンメニューから、「詳細オプション(Advanced Options)」をクリックします。
3. 「移行元/移行先(Source/Destination)」タブ内の「移行先(DESTINATION)：MICROSOFT 365」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
4. 「保存(Save)」ボタンをクリックします。

指定した管理者アカウントにはライセンスは必要なく、他の管理者権限を構成する必要もありません。

偽装

Microsoft 365での偽装

MigrationWizでは、委任がデフォルトで設定されており、コネクタで指定された管理者資格情報を使用して、個々のユーザーメールボックスにログインします。ただし、特定の環境においては、偽装もサポートしています。

偽装を使用する利点：

「接続に失敗しました(Connection did not succeed)」エラーが大幅に削減されます。
同時に移行できるメールボックス数が増えます。
スロットリングと接続制限の影響が軽減されます。
ライセンスが割り当てられていない管理者アカウントを使用することができます。

手順

偽装を使用して移行する方法

移行先で管理者資格情報を使用します。
MigrationWizアカウントにサインインします。
「プロジェクトの編集」をクリックし、「詳細オプション(Advanced Options)」をクリックします。
移行元がMicrosoft 365の場合は、「移行元/移行先(Source/Destination)」タブ内の「移行元(SOURCE)」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
移行先がMicrosoft 365の場合は、「移行元/移行先(Source/Destination)」タブ内の「移行先(DESTINATION)」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
「保存(Save)」をクリックします。

MigrationWizは、リモートPowerShellコマンドを自動的に実行して、管理者アカウントがユーザーのメールボックスに(ユーザーを偽装して)ログインできるようにします。

メールボックスの移行時に、MigrationWizが実行するリモートPowerShellコマンドは、次のとおりです。

Enable-OrganizationCustomization New-ManagementRoleAssignment -Role ApplicationImpersonation -User <管理者ユーザー名

これらのコマンドは、手動で実行することもできます。手動でのコマンド実行は、Microsoft環境の遅延によりPowershellコマンドが即座に実行されない場合に有用な方法です。

Exchange 2010以降

利点

偽装を使用すると、単一の管理者アカウントに関連付けられたスロットリングクォータと接続制限の共有を停止することができます。各ユーザーメールボックスへのログインには、代わりに各ユーザーのスロットリングクォータが適用されます。

偽装を使用する利点：

「接続に失敗しました(Connection did not succeed)」エラーが大幅に削減されます。
同時に移行できるメールボックス数が増えます。
スロットリングと接続制限の影響が軽減されます。

手順

移行先で管理者資格情報を使用します。
MigrationWizアカウントにサインインします。
「プロジェクトの編集」をクリックし、「詳細オプション(Advanced Options)」をクリックします。
「移行元/移行先(Source/Destination)」タブ内の「移行先(DESTINATION)」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
移行元がExchange 2010以降の場合は、「移行元/移行先(Source/Destination)」タブ内の「移行元(SOURCE)」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
移行先がExchange 2010以降の場合は、「移行元/移行先(Source/Destination)」タブ内の「移行先(DESTINATION))」セクションで、「偽装を使用して認証する(Use Impersonation to Authenticate)」のチェックボックスをオンにします。
「保存(Save)」をクリックします。

Exchangeの移行で、管理者アカウントがユーザーを偽装できるようにするには、次のPowerShellコマンドを実行します。

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <管理者ユーザー名

PowerShellコマンドの詳細については、こちらを参照してください。

Microsoft 365プランの「Business Basic」および「Business Premium」は、偽装をサポートしています。上記の「Microsoft 365での偽装」セクションの手順に従って、移行元が「Business Basic」または「Business Premium」の場合や、移行先が「Business Basic」または「Business Premium」の場合の、偽装の使用を有効にします。

プロジェクトの「詳細オプション(Advanced Options)」で偽装の使用を設定すると、その設定を保存した後に開始された移行に対してのみ、偽装が有効になります。すでに実行されている移行に対しては、この設定変更は反映されません。

Microsoft Entra IDを同期する

推奨されるアプローチは、次のとおりです。

最新情報については、次のMicrosoftの記事を参照してください。 Microsoft 365のディレクトリ同期を設定する

ME-ID SyncまたはME-ID Connectをダウンロードしてインストールします(フェデレーションのサポートが必要な場合)。
「msExchMailbxoGuid」属性を「Null」に設定します。
フィルター処理を構成して、同期するオブジェクトを定義します。詳細については、Microsoftの記事、Microsoft Entra Connect Sync：フィルター処理を構成するを参照してください。
Microsoft AAD SyncまたはAAD Connectを使用して、オンプレミス環境からMicrosoft 365へアカウント情報を同期し、アカウントを作成します。
Microsoft 365のアカウントに、Microsoft 365ライセンスを割り当てます。
同期規則エディターを使用して、「msExchMailboxGuid」から「Null」属性を削除します。
AAD Connect(またはAAD Sync)を使用して、再度同期を実行します。
MigrationWizを使用して、移行を実行します。すでにライセンスが割り当てられている場合は、手順4の後に実行することもできます。

ローカルのActive Directory (AD)スキーマが拡張されておらず、Exchangeをサポートしていない場合、上記の「msExchGuid」属性を「Null」に設定する手順は必要ありません。同期は、通常の方法で実行することができます。

過去にローカルADがExchangeをサポートしている環境からDirSyncを使用したことがある場合、「msExchangeMailboxGuid」を「Null」に設定することはできません。DirSyncがこれをサポートしていないためです。この問題を解決するには、上記の手順に従って、AAD SyncまたはAAD Connectを使用して、同期を行うことをお勧めします。

「msExchMailboxGuid」を「Null」に設定しない場合は、ローカルADがExchangeをサポートしている環境からの同期を実行する前に、各ユーザーのすべてのオンプレミスExchange属性(「MailboxGuid」属性を含む)が同期されます。この状況下でMicrosoft 365にユーザーを作成する場合は、メールボックスレプリケーションサービス(MRS)を使用してメールボックスを移動するか、上記の手順に従って問題を修正しない限り、Exchange Onlineライセンスをアクティブ化することはできません。

Microsoft 365でユーザーが作成され、ライセンスがアクティブ化されると、通常の方法でDirSync、AAD Sync、またはAAD Connectを使用できるようになります。(ローカルADがExchangeをサポートしている環境で)発生する問題は、ユーザーの作成とライセンスの有効化に限定されます。

メールボックスがローカルADのExchange Serverにある場合、Microsoft 365アカウントの作成は、次のいずれかの方法で行います。

- ME-ID SyncまたはME-ID Connect。上記の推奨されるアプローチの手順に従ってください。
- 手動で1つずつ追加する。
- CSVファイルを使用して、一括でインポートする。

ユーザーの作成後、各ユーザーにライセンスを割り当てる必要があります。

メールルーティング

ユーザーをバッチで移行する場合

MigrationWizでは、移行先がMicrosoft 365の場合、Microsoft 365でメールボックスをプロビジョニングして、コンテンツ、メール、連絡先、予定表などを書き込めるようにする必要があります(ユーザーは、メールボックスを含むMicrosoft 365ライセンスが割り当てられた、Microsoft 365ユーザーである必要があります)。

移行を段階的またはバッチで実行する場合は、移行されたユーザーに対し、完全なメールフローが継続されるように注意する必要があります。

次の例で、詳しく説明します。

ジョンとトムをMicrosoft 365に移行する必要があります。彼らは異なるユーザーバッチに属しています。最初にバッチ1が移行されます。バッチ2は、2番目に移行されます。
ジョンは最初のバッチに属しているため、移行され、すでにMicrosoft 365メールボックスを使用しています。
トムは、2番目のバッチに属しています。トムが属しているユーザーバッチは、後日移行されます。
MigrationWizでは、上で説明したように、移行先メールボックスにデータを移行するには、そのメールボックスがアクティブである必要があるため、バッチ2のユーザーを移行する時は、移行前にMicrosoft 365でそれらのユーザーをアクティブにしておく必要があります。

移行の実行中に、新しくアクティブ化されたMicrosoft 365メールボックスにメールを送信すると、どうなりますか?

ジョンがトムにメールを送信すると、Microsoft 365は、そのメールをトムがまだ使用しているオンプレミスのメールボックスではなく、新しいメールボックスに内部的にルーティングします。メールは最終的にトムが取得するメールボックスに保存されるため、失われることはありませんが、移行が完了するまで、トムはメールにアクセスすることができません。

この問題を解決する方法は？
デフォルトのメールルーティングは、CBR(Criteria-Based Routing)と呼ばれるメカニズムを使用して、操作することができます。メールをMicrosoft 365のメールボックスに配信するのではなく、メッセージをインターセプトして、オンプレミスのメールシステムに転送し、そこで処理できるようにします。インターセプトは、特定の配布リストのメンバーシップと同様の基準で行われます。

これについて、同じシナリオの例で説明します。

ジョンは、最初のバッチでMicrosoft 365に移行されました。
トムは、「NotMigrated」という配布リストのメンバーです。
次のように定義したCBRメカニズムを設定しました。

配布リスト「NotMigrated」のメンバーのメールは、インターセプトされ、オンプレミス環境に送信されます。

これにより、ジョンがトムにメールを送信すると、メールはMicrosoft 365メールボックスには送信されず、オンプレミスのExchange 2010以降の環境に転送されます。

具体的な設定方法
設定にはPowerShellを使用します。Microsoft 365管理ポータルを使用するよりも、速く簡単に設定することができます。Microsoft 365管理ポータルを介した設定方法については、Microsoftサポートにお問い合わせください。

PowerShellを使用して、Exchange Onlineに接続します。
配布リストを作成します。
New-DistributionGroup -Name "BtNotMigratedUsers"
すべてのユーザーをこの配布リストに追加します。
コネクタを作成します。
$result = New-OutboundConnector -Name "CBRConnector" -ConnectorType OnPremises -SmartHosts "<移行元環境のスマートホスト" -UseMXRecord $false -IsTransportRuleScoped $true
- 「-SmartHosts」のエントリは、移行元サーバーのURLまたはIPアドレスである必要があります。
- Exchange 2003、2007、および2010では、これはトランスポートサーバーのアドレスになります。
- Exchange 2013および2016では、トランスポートサーバーではなく、メールボックスサーバーのアドレスになります。
- 移行元環境がホスト型の場合は、ホストプロバイダーからこのアドレスを取得する必要があります。
- 移行元環境がGoogle Workspaceの場合は、「-SmartHosts」のエントリを次のように変更する必要があります。
  - -SmartHosts “aspmx.l.google.com”
ルールを作成します。
$result = New-TransportRule -Name "PilotInABoxRule" -SentToMemberOf "BtNotMigratedUsers" -RouteMessageOutboundConnector "CBRConnector"

移行が完了したユーザーを配布リストから削除すると、そのユーザーは、自分のMicrosoft 365メールボックスでメールを受信するようになります。

移行された各ユーザーについては、メールが有効な連絡先がオンプレミスに存在している必要があります。

併用

テナント間移行プロジェクトで併用を設定する

Microsoft 365テナント間の併用設定を使用すると、Microsoft 365から別のMicrosoft 365への移行中に、移行元と移行先を併用することができます。Microsoft 365の移行で、移行開始からカットオーバーまでの時間が長く設定されている場合、移行は通常バッチ単位で行われます。このような長い移行シナリオの場合、移行中に移行元と移行先のユーザーがシームレスに通信するためには、移行元と移行先の併用が必要になります。併用設定により、移行されたユーザーは、移行されていないユーザーの空き時間情報と連絡先の詳細を確認することができます。 

移行はバッチ単位で完了することができますが、すべてのユーザーが同じプロジェクトに属している必要があります。プロジェクトを設定した後は、移行元環境でのみユーザーの追加または削除を行うことができます。その後、MigrationWizで「テナント間の管理(Manage Tenant to Tenant)」ボタンをクリックし、「アイテムの再検出(Rediscover Items)」ボタンをクリックして、変更内容を同期します。ユーザーを移行プロジェクトに手動で追加したり、削除したりすることはできません。

重要

Microsoft 365テナント間の移行で、併用設定を使用することができるのは、移行元と移行先の間でドメイン名が変更される移行シナリオのみです。現時点では、同じドメイン名への移行には、併用設定は使用することができません。

重要

移行プロジェクトが完全に完了するまでは、Microsoft Entra Connectを使用して、移行先のユーザーアカウントに対する操作を行うことはできません。

Microsoft 365テナント間の併用を設定する

MigrationWizを起動し、メールボックスプロジェクトを作成します。新しいメールボックス移行プロジェクトの作成については、MigrationWizプロジェクトを参照してください。
移行元エンドポイントと移行先エンドポイントをMicrosoft 365に設定します。
最初のプロジェクト作成時に、「テナント間の併用を有効にする(Enable Tenant to Tenant Coexistence)」のチェックボックスをオンにします。
テナント間併用オプションを設定します。
- ドメインアドレスを設定する(Configure Domain Addresses)：「移行元ドメインアドレス(Source Domain Address)」と「移行先ドメインアドレス(Destination Domain Address)」を入力します。「移行元ドメインアドレス(Source Domain Address)」の入力は任意です。これにより、移行元テナントのすべてのドメインの併用設定が有効になります。
- グローバル管理者資格情報を設定する(Setting Global Administrator Credentials)： 移行元エンドポイントと移行先エンドポイントの両方で、グローバル管理者アカウントが必要です。
  
  重要
  移行先テナントの管理者アカウントは、MSOnlineにアクセスする必要があるため、アカウントのドメインに「.onmicrosoft.com」を使用して、正しいアクセスレベルを確保する必要があります。
- Microsoft 365ライセンスの種類(Microsoft 365 License Type)を選択する：移行先で使用するMicrosoft 365ライセンスの種類を選択します。メールが有効な連絡先が、メールボックスを持つユーザーアカウントに変換される際に、ライセンスが適用されます。
- 配布リストとグループを移行する(Migrate Distribution List and Groups)： 移行の一部として含めるグループを選択します。配布リストおよびグループに対する変更は、プロジェクト進行中に同期されます。
「保存」をクリックします。

配布リストの変更

次の手順を実行すると、移行前に配布リストへの変更を同期することができます。

移行元環境の配布リストまたはグループに変更を加えます。
「テナント間の管理(Tenant to Tenant Management)」クリックします。
「配布リストの同期(Sync Distribution List)」を選択します。

併用設定を使用したテナント間の移行

本移行シナリオには、「ユーザー移行バンドル(User Migration Bundle)」ライセンスが必要です。本移行では、特定のMicrosoft 365ライセンスのみがサポートされています。サポートされているライセンスの種類は、移行設定画面のドロップダウンメニューにリストされています。1つのプロジェクトで使用できるMicrosoft 365ライセンスは1種類のみで、プロジェクトの設定後に種類を変更することはできません。

移行はバッチ単位で完了することができますが、すべてのユーザーが同じプロジェクトに属している必要があります。

プロジェクトを設定した後は、「テナント間の管理(Manage Tenant to Tenant)」メニューの「アイテムの再検出(Rediscover Items)」オプションを使用して、プロジェクトにユーザーを追加または削除することができます。「アイテムの再検出(Rediscover Items)」を使用する前に、移行元環境にユーザーを追加または削除する必要があります。移行先にクラウドアカウントが作成されます。ユーザーパスワードは、DeploymentProのプロファイル構成の手順内で作成されます。

移行プロジェクトが完全に完了するまでは、Microsoft Entra Connectを使用して、移行先のユーザーアカウントに対する操作を行うことはできません。

テナント間の併用オプションを選択して移行プロジェクトを保存すると、その併用オプションは削除することができなくなります。事前に移行の範囲と期間を確認しておくことをお勧めします。

移行元エンドポイントと移行先エンドポイントの両方で、グローバル管理者アカウントが必要です。使用できるグローバル管理者アカウントがない場合は、本移行タイプは実行することができません。

移行元のすべてのユーザーが検出され、各ユーザーは、メールが有効な連絡先として移行先に作成されます。したがって、移行元テナントから一部のユーザーのみを移行したい場合は、本移行タイプは適しません。メールが有効な連絡先は、クラウド専用のユーザーメールボックスに変換されます。AADCを使用したオンプレミスオブジェクトとの同期は、移行が完了するまでは実行することができません。

単一のターゲットドメインのみがサポートされています。

併用を設定したテナント間移行プロジェクトは、MigrationWiz独自のものです。全体的なプロセスは他の移行と変わりませんが、この特殊なタイプの移行では、移行元テナントと移行先テナント間に併用のためのリンクを確立するために、追加の設定が行われます。

上記の「Microsoft 365テナント間の併用を設定する」の手順を実行した後、MigrationWizでは、移行元と移行先の両方でいくつかのアクションがバックグラウンドで行われ、ユーザーの併用設定の準備が行われます。このプロセスは自動で行われるため、手動によるアクションは必要ありません。

プロジェクトが保存されると、MigrationWizでは、両エンドポイントが自動的に開き、Microsoft Entraに接続されて、Microsoft 365テナントの構成が始まります。このプロセスは、1000ユーザーあたり最大1時間を要する場合があります。
移行元および移行先の両テナントで、組織共有および個人共有の設定と有効化(テナント間で空き時間情報の確認ができるようになります)が行われます。
移行元テナントで検出された各ユーザーのメール連絡先が、移行先テナントのプライマリドメインの外部メールアドレスを使用して作成されます。これにより、移行先から移行元の空き時間情報を確認できるようになるだけでなく、移行先から移行元へのメールルーティングも可能になります。
自動プロセスが完了すると、ユーザーがMigrationWizプロジェクトにインポートされます。これで、ユーザーに「ユーザー移行バンドル(User Migration Bundle)」ライセンスを適用する準備が整いました。ライセンスの購入方法については、MigrationWizのライセンスおよびライセンス付与を参照してください。

訴訟ホールド

訴訟ホールドの移行は、いくつかの重要な既知の制限付きでサポートしています。

訴訟ホールドでは、当然のことながら100％の証拠保全が求められるため、これらの制限を把握しておくことが重要です。

プライマリメールボックス内のすべてのメールが移行されます。 MigrationWizでは、Exchange OnlineからExchange Onlineへの移行でのみ、アーカイブメールボックス内の「回復可能なアイテム(Recoverable Items)」フォルダーの移行もサポートしています。手順については、次の移行ガイドを参照してください。回復可能なアイテム(Microsoft 365またはExchange)移行ガイド

訴訟ホールドで作成されたフォルダーは、ほとんどが「メールフォルダー」であると考えられますが、一部そうでないものも含まれています。(メール以外の)すべての特殊な訴訟ホールドアイテムは、EWS(MigrationWizでは、移行元がExchange 2007以降の場合の移行にEWSを使用します)の既知の制限により、移行に失敗します。

これらのアイテムのいくつかは、EWSによって誤ってメールフォルダーと見なされることがあります。これらの誤って認識されたフォルダー内に、メール以外のアイテムを作成しようとすると、EWSのバグにより、「アイテムの種類がフォルダーの種類と一致しません(the item type does not match the folder type)」というエラーが表示されます。

たとえば、1件の連絡先が削除され、それが/Purgesフォルダーに格納されたとします。この連絡先を移行先のメールボックスの/Purgesフォルダーに移行しようとすると、エラーが発生します。

メールボックスの「回復可能なアイテム(Recoverable Items)」領域にある既知のフォルダーは、次のとおりです。

Versions：訴訟ホールド(またはインプレースホールド、または単一アイテムの回復)が有効になっている場合、このサブフォルダーには、削除されたアイテムの元のコピーと変更されたコピーが格納されます。注：このフォルダーは、エンドユーザーには表示されません。
Purges：訴訟ホールド(または単一アイテムの回復)が有効になっている場合、このサブフォルダーには、物理的に削除されたすべてのアイテムが格納されます。注：このフォルダーは、エンドユーザーには表示されません。
DiscoveryHold：インプレースホールドが有効になっている場合、このサブフォルダーには、ホールドのクエリパラメータに合致し、かつ物理的に削除されたすべてのアイテムが格納されます。
Audits：メールボックスのメールボックス監査ログが有効になっている場合、このサブフォルダーには、監査ログエントリが保存されます。このフォルダーは、MigrationWizでは移行されません。
Calendar Logging：このサブフォルダーには、メールボックス内で発生する予定表の変更が保存されます。ユーザーは、このフォルダーを利用することはできません。
Deletions：このサブフォルダーには、「削除済みアイテム(Deleted Items)」フォルダーから削除されたすべてのアイテムが格納されます。(Outlookでは、「Shift」キーを押しながら「Delete」キーを押すことで、アイテムを論理的に削除することができます。) このサブフォルダーは、OutlookおよびOutlook On The Webの「削除済みアイテムを復元(Recover Deleted Items)」機能を使用すると、ユーザーに表示されるようになります。

上記のフォルダーは、デフォルトで移行先のDeletionsフォルダーに移行されます。これらのフォルダー内のすべてのメールアイテムが移行されます。メール以外のアイテムは、MigrationWizポータルでエラーとして報告されますが、移行の完了を妨げることはありません。通常、訴訟ホールドの移行実行時に新たに発生するエラーはごくわずかであるため(実際、これらのフォルダー内のほとんどのアイテムがメールアイテムであるため)、エラー数のしきい値を調整する必要はありません。

移行プロセスでは、フォルダーの検索に加え、各フォルダー内のアイテムの取得が行われます。アイテムの取得に失敗しても、そのフォルダーが移行対象から除外されるため、移行は続行されます。

メールボックスの「回復可能なアイテム(Recoverable Items)」領域にあるフォルダーを、Deletionsフォルダーではなく移行先の対応する各フォルダーに移行したい場合は、移行を実行する前に、プロジェクトの「サポート(SUPPORT)」セクションで、詳細オプションの「OverrideRecoverableItemsFolderMapping="^SourceFolder-DestinationFolder"」を追加する必要があります。

訴訟ホールドが設定されたメールボックスを含む移行を実行するための、推奨される手順を以下に示します。

通常のメールボックスプロジェクトを作成し、詳細オプションを設定して、メールボックスの移行を実行します。お客様のシナリオに合った移行ガイドの指示に従ってください。すべての移行ガイドが、BitTitanヘルプセンターのサイトに掲載されています。
メールボックスの移行が完了したら、訴訟ホールド専用の新しいメールボックスプロジェクトを作成します。
この訴訟ホールドプロジェクトに、詳細オプションを設定します。「移行元/移行先(Source/Destination)」タブで、「移行元(SOURCE)」セクションの「移行元(Migrate from)」のパラメータを、「回復可能なアイテム」に設定します。これにより、自動的に「移行先(DESTINATION)」セクションの「移行先(Migrate to)」のパラメータが、「回復可能なアイテム」に設定されます。
通常のメールボックスプロジェクトのダッシュボードに戻り、移行が完了したアイテムを選択して、それらを訴訟ホールドプロジェクトに移動します。
訴訟ホールドプロジェクトで、アイテムの移行を実行します。これにより、移行元の「回復可能なアイテム(Recoverable Items)」フォルダーのすべてのアイテムが、移行先の「回復可能なアイテム(Recoverable Items)」フォルダーに移行されます。
移行が完了したら、アイテムを通常のメールボックスプロジェクトに戻します。
すべてのメールが移行されます。
ユーザーに表示されないアイテムは、移行後も非表示のままとなります。
メールボックス移行では、メールボックスごとに最大10サイクルの移行が可能です。したがって、訴訟ホールドプロジェクトでのメールボックスの移行は、アイテムをプロジェクト間で移動させた場合は、追加のライセンスを消費することはありません。
訴訟ホールドプロジェクトには、新しいメールボックスを追加しないでください。追加するのではなく、他のプロジェクトから訴訟ホールドプロジェクトにアイテムを移動します。これにより、すべてのプロジェクトの統計情報とライセンス履歴が、変更されずに維持されます。
「回復可能なアイテム(Recoverable Items)」領域へ移行する場合は、「削除済みアイテム(Deleted Items)」フォルダーの保持期間を長くすることをお勧めします。デフォルトの保持期間は14日間です。この保持期間を最大の30日間に増やすことをお勧めします。手順については、TechNetの記事、Exchange Onlineメールボックスの完全に削除したアイテムの保持期間を変更するを参照してください。

非アクティブなユーザーの訴訟ホールドデータを移行する

MigrationWizは、非アクティブなメールボックスをサポートしていません。移行するには、ユーザーをアクティブ化して、通常の移行を実行します。移行前にメールボックスをアクティブな状態に復元するには、次のMicrosoftドキュメントの手順に従ってください。非アクティブなメールボックスを復元する

訴訟ホールドとインプレースホールド

訴訟ホールドの移行は、法的な審査に備えるために、ユーザーのメールボックス全体を保持します。

インプレースホールドの移行は、ユーザーのメールボックス全体のサブセットを保持して、特定の種類のメールのみを保持します。

これらの2種類の移行の唯一の違いは、クエリです。訴訟ホールドを有効にすると、削除または変更されたアイテムをすべて保持することができます。インプレースホールドの設定は、訴訟ホールドの設定とほぼ同じですが、フィルタークエリを追加して、特定の種類のメールのみを保持するようにします。

訴訟ホールドは、次のように機能します。

通常の削除済みアイテムのワークフローでは、ユーザーがメールボックスアイテムを完全に削除するか、「削除済みアイテム(Deleted Items)」フォルダーから削除すると、そのメールボックスアイテムは、「回復可能なアイテム(Recoverable Items)」フォルダー内のDeletionsサブフォルダーに移動します。削除ポリシー(削除アクションが設定された保持タグ)を適用した場合も、保持期間が終了すると、アイテムはDeletionsサブフォルダーに移動します。ユーザーが「回復可能なアイテム(Recoverable Items)」フォルダー内のアイテムをパージするか、削除済みアイテムの保持期間が終了すると、そのアイテムは「回復可能なアイテム(Recoverable Items)」フォルダー内のPurgesサブフォルダーに移動し、完全削除のマークが付けられます。そのアイテムは、次にメールボックスが管理フォルダーアシスタント(MFA)によって処理される時に、Exchangeから消去されます。

メールボックスが訴訟ホールドの対象になると、Purgesサブフォルダー内のアイテムは、訴訟ホールドで指定された保持期間の間、保持されます。保持期間は、アイテムが最初に受信または作成された日から起算され、アイテムがPurgesサブフォルダー内にどのくらいの期間保持されるかを定義するものです。Purgesサブフォルダー内のアイテムの保持期間が終了すると、そのアイテムには完全削除のマークが付けられ、次にメールボックスがMFAによって処理される時に、Exchangeから消去されます。メールボックスに無期限の保持が設定されている場合、アイテムはPurgesサブフォルダーから消去されることはありません。

トラブルシューティング

大きいアイテムを移行する

本記事の手順を実行するには、Windows PowerShellを使用して、Microsoft 365に接続する必要があります。Windows PowerShellを使用してMicrosoft 365に接続する手順の詳細については、Microsoftの記事、Exchange Online PowerShellに接続するを参照してください。

EWSの既定値よりも大きいアイテムをMicrosoft 365に移行するには、以下のPowerShellスクリプトを実行する必要があります。

まず、Microsoft 365環境に対して次のスクリプトを実行して、現在の設定を確認する必要があります。

Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize

ユーザーは、Microsoft 365の標準ユーザーであり、メールボックスライセンスを含むMicrosoft 365ライセンスが割り当てられている必要があります。また、以前に設定の変更が行われていないユーザーである必要があります。

結果の例：

MailboxPlan:ExchangeOnlineEnterprise-4b910ff9-8b91-4f2e-960c-302a90c95668 MaxSendSize:35 MB (36,700,160 bytes) MaxReceiveSize:36 MB (37,748,736 bytes)

次に、Microsoft 365環境に対して次のスクリプトを実行して、メールボックスプラン、最大送信サイズ、および最大受信サイズを設定します。

Get-MailboxPlan | Set-MailboxPlan -MaxSendSize 150MB -MaxReceiveSize 150MB

メールボックスプランの変更後に作成した新しいユーザーについては、最大送信サイズと最大受信サイズがそれぞれ150MBになります。ただし、現在のユーザーについては、35MBの設定のままになります。すべてのユーザーのサイズ制限を増やすには、次のコマンドを実行します。

Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB

次の例は、新しい制限が適用されていることを検証するためのコマンドを示しています。

PS C:\Windows\system32 Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize MailboxPlan:ExchangeOnlineEnterprise-4e910ff9-8b91-4f2e-960c-302a90c65668 MaxSendSize:150 MB (157,286,400 bytes) MaxReceiveSize:150 MB (157,286,400 bytes)

100GBを超えるメールボックスを移行する

Microsoft 365に100GBを超えるメールボックスを移行するには、次の手順に従います。

MigrationWizを開き、メールボックス移行プロジェクトを作成します。
移行元および移行先エンドポイントを設定します。
ユーザーをプロジェクトに追加します。
「詳細オプション(Advanced Options)」の「移行先(DESTINATION)」セクションで、ユーザーのアーカイブメールボックスに移行するための設定を構成します。詳細については、MigrationWiz －詳細オプション(Advanced Options)と一般オプション(General Options)を参照してください。
プロジェクトで日付範囲フィルターを設定して、特定の日付よりも古いアイテムを移行します。たとえば、1年以上前のすべてのアイテムをアーカイブメールボックスに移行します。詳細については、移行戦略－種類とベストプラクティスを参照してください。
メールアイテムのみを移行する「完全移行(Full Migration)」サイクルを実行します。移行が成功するまで監視します。
アーカイブメールボックスへの移行が完了したら、「詳細オプション(Advanced Options)」で、アーカイブメールボックスではなくプライマリメールボックスに移行するように設定を変更します。
日付範囲フィルターを削除します。
「前段階移行(Pre-Stage Migration)」または「完全移行(Full Migration)」サイクルを実行して、プライマリメールボックスへの移行を行います。

予定表アシスタントを無効にする

Microsoft 365の予定表アシスタントにより、OutlookやOWAでの会議および定期的な会議が中断される場合があります。移行の開始時に、予定表アシスタントを無効にすることをお勧めします。予定表アシスタントは、移行の完了後に再び有効にすることができます。予定表アシスタントが無効になっていても、悪影響はありません。

PowerShellを使用して、Microsoft 365へのリモートセッションを作成し、次のコマンドを実行します。

$LiveCred = Get-Credential

Install-Module -Name ExchangeOnlineManagement Import-Module -Name ExchangeOnlineManagement Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $true

Microsoft 365テナント内のすべてのメールボックスで、予定表アシスタントが無効になりました。次のPowerShellコマンドを使用すると、再度有効にすることができます。

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $false

管理者アカウントを作成する

最も簡単な方法は、グローバル管理者アカウントを使用することです。グローバル管理者アカウントは、テナント作成時に設定したアカウントです。

移行にグローバル管理者アカウントを使用しない場合は、代わりに新しい管理者アカウントを作成することができます。新しい管理者アカウントには、各メールボックスユーザーのデータにアクセスするためのフルアクセス権を付与する必要があります。

手順

Microsoft 365でユーザーを作成します。 Exchange Onlineにユーザーのメールボックスを作成します。
リモートPowerShellを使用して、Exchange Onlineに接続します。詳細については、次のMicrosoftのWebサイトを参照してください。 Exchange Online PowerShellに接続する
次のコマンドを入力して、「Enter」キーを押します。
Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User AdministratorAccount@mydomain.com -AccessRights fullaccess -InheritanceType all

上記の手順を実行すると、指定したユーザーが、Microsoft 365のすべてのユーザーメールボックスにアクセスできるようになります。このユーザーは、OutlookまたはOutlook Web Appから、メールボックスの内容を表示できるようになります。

中国のMicrosoft 365へ移行する

最初に、中国のどのバージョンのMicrosoft 365に移行するのかを正確に決定します。

ここで重要なのは、Microsoft 365がどこに存在するのか、たとえば、Microsoft 365が中国のファイアウォールの外側にあるのか内側にあるのかということです。

中国政府は、中国全土でグレートファイアウォールの運用と維持を行っています。「インターナショナル側」(ファイアウォールの外側)と「メインランド側」(ファイアウォールの内側)があります。

MigrationWizの「Microsoft 365 (China)」エンドポイントは、「Micrsoft 365 (China)インターナショナル」を指しています。中国のMicrosoft 365のインターナショナルバージョン(ファイアウォールの外側にあるバージョン)にユーザーを移行する場合は、このエンドポイントを使用します。

中国のファイアウォールの内側にあるMicrosoft 365に移行する場合は、21 Vianetと連携して行う必要があります。BitTitanは21 Vianetと提携しているため、パートナーは、中国のファイアウォール内のMicrosoft 365への移行を行うことができます。パートナーシップの詳細については、こちらのブログをご覧ください。

プロセスを開始するには、bluecloudsolutions@oe.21vianet.comにメールを送信して、21 Vianetの営業部門にご連絡ください。