Exchange Online (Microsoft 365)からExchange Online (Microsoft 365)への移行ガイド - 異なるドメインへの併用移行

本記事は、Microsoft 365テナントから別のMicrosoft 365テナントへのメールボックス移行で、移行元ドメインを新しい移行先テナントへ移動せずに、異なるドメインへ併用設定を使用して移行するための導入手順書です。併用戦略は、ユーザーを複数のユーザーグループに分けて数週間または数か月かけて移行するシナリオにおいて、ユーザー同士が連絡を取り合える環境を維持する必要がある場合に使用します。これは、「スローバーン」移行とも呼ばれます。

初めての移行

初めて移行を実行する際は、移行計画と戦略を参照してください。移行の計画と設定、および一般的な移行のベストプラクティスについて説明しています。移行を開始する前に、内容を確認することをお勧めします。

本移行タイプには、いくつかの前提条件とベストプラクティスがあります。本移行を開始する前に、Exchange Online (Microsoft 365)からExchange Online (Microsoft 365)へのメールボックス移行ガイドを確認することを強くお勧めします。本記事で説明するプロセスの詳細については、Microsoft 365のメールボックスの移行に関するよくある質問を参照してください。

MigrationWiz

MigrationWizは移行ツールであり、同期ツールではありません。移行完了後に移行元のアイテムに変更が加えられた場合、その変更は移行先には反映されません。同様に、移行先で加えられた変更も、移行元には反映されません。MigrationWizには、(同期エージェントのような)「ライブ」での変更のモニタリング機能はなく、ユーザーの操作なしに競合解決などを処理することはできません。

前提条件

移行プロジェクトを円滑に進めるには、次の前提条件を満たすことが重要です。

ライセンス

本移行には、「ユーザー移行バンドル(User Migration Bundle)」ライセンスが必要です。

ライセンスを購入してプロジェクト内のメールボックスに適用する方法については、こちらのドキュメントを参照してください。

制限

  • アプリパスワードの使用は、Microsoft 365エンドポイントではサポートされていません。
  • 移行元または移行先がGoDaddyの場合、GoDaddyの接続制限により、本移行タイプはサポートされていません。  移行元または移行先がGoDaddyの場合は、次のガイドに従って、移行を実行してください。Exchange Online (Microsoft 365)からExchange Online (Microsoft 365)へのメールボックス移行ガイド
  • 併用移行中に移行先に対して行われる呼び出しのタイプにより、「アイテム自動検出(Autodiscover Items)」では、IP LockDownは機能しません。
  • 単一の移行先ドメインのみがサポートされています。
  • 二要素認証または多要素認証を使用した移行は、サポートされていません。
  • MigrationWizでサポートされている1ファイルあたりの最大サイズは、60GBです。
  • 本移行タイプでは、Exchange Onlineテナントのメールボックスに対して、Exchange Webサービス(EWS)が有効になっている必要があります。

製品アップデート 

BitTitanが現在サポートしている併用製品は、Microsoft Entra Connect (ADFS、ME-ID Connect、および同期システム)です。移行を最適に設定および構成する方法については、Microsoft Entra IDシナリオの設定ガイドを参照してください。  

移行できるアイテム

移行できるアイテムと移行されないアイテムについては、下のバーをクリックして確認してください。より良い移行を提供し続けるために、リストのアイテムは今後変更される可能性があります。

本シナリオで移行できるアイテムは何ですか?
  • 日付/時刻
  • 件名
  • 本文
  • 重要度
  • 秘密度
  • サイズ
  • アイテムクラス
  • 定期的な会議の例外
  • 受信トレイ
  • フォルダー
  • メール
  • 連絡先
  • 予定表
  • タスク
  • ジャーナル
  • メモ
  • 投稿(移行先がExchangeまたはMicrosoft 365の場合)
  • サーバー側のメールボックスルール
  • Outlookクライアント側のメールボックスルール
  • 自動応答(不在通知メール) 

    重要

    自動応答(Automatic Replies)」は、ユーザーの最終移行サイクルでのみ移行することをお勧めします。
  • 個人用フォルダーおよび予定表の権限

リソースメールボックス

リソースメールボックスは、通常のユーザーメールボックスと同じ方法で処理されます。Webクライアント(Outlook Web Accessなど)を使用してリソースメールボックスにログインできる場合は、データを移行することができます。Webクライアント(OWAなど)を使用してリソースメールボックスにログインすることができない場合は、データを移行することはできません。

ユーザーによっては、リソースメールボックスを共有予定表としてのみ所有している場合があります。このような場合、ユーザーのメールボックスが移行されると、リソースメールボックスの予定表は、ユーザーの予定表の1つとして移行されます。移行が完了したら、予定表に共有/権限を設定して、他のユーザーによるアクセスを許可することができます。​​

本シナリオで移行されないアイテムは何ですか?
以下のアイテムと設定は、移行されません。
  • 安全な送信者リスト/ブロックされた送信者リスト
  • メールフォルダー内の予定表の返信など、フォルダータイプと一致しないアイテム

    重要

    アイテムが移行先の異なるタイプのフォルダーに移行された場合、そのアイテムは表示されません。
  • コアシステムタイプを継承しないカスタムアイテム
  • InfoPathフォーム
  • 予定表の権限(移行元がExchangeの場合の例外については、以下を参照してください。)
  • 予定表の通知
  • 予定表の承認ステータスのメール
  • 定期的な会議の例外で修正された説明文と出席者リスト
  • 連絡先アイテムのユーザー定義/カスタムフィールド
  • 会議出席者の承認ステータス
  • 個人用配布リスト(Microsoft 365の「連絡先グループ」)
  • サーバーベースの配布リストと動的配布リスト
  • バウンス通知
  • RSSフィード
  • メールボックス共有設定(エイリアス、代理人、クライアント設定)
  • メールボックスのルールとフォルダーの権限の設定(Exchange Server 2010 SP1以降からExchange Server 2010 SP1以降への移行でのみサポートされています。)
  • パーソナルメッセージングリソース管理(MRM)タグ
  • Outlookのクイックステップ
  • クライアント側のルール
  • カテゴリの色分け
  • 連絡先の名刺に追加された写真
  • 予定表内の会議へのリンク:Lync、Skype、Teamsのイベントは移行できますが、リンクが移行元環境用であるため、通常は移行先では機能しません。これらのイベントは、移行先で再作成する必要があります。この規則には例外がありますが、一貫性はありません。
  • 暗号化されたメール:すべての移行元メールシステムで暗号化方式を使用して送受信されたメールは、移行されません。メールを移行する前に、暗号化を解除する必要があります。

環境を準備する

移行元および移行先の環境は、標準のMigrationWizプロジェクトと同じ方法で設定します。環境準備の詳細については、Exchange Online (Microsoft 365)からExchange Online (Microsoft 365)へのメールボックス移行ガイドを参照してください。

先進認証の要件

移行元と移行先がExchange Onlineの場合、メールボックスおよびアーカイブメールボックスではExchange Web Services (EWS)が使用されるため、移行元と移行先の両テナントで、M365メールボックスおよびアーカイブの移行 - APIのアクセス許可のみを使用した移行の記事に記載されている手順を実行する必要があります。この設定手順の実行には、グローバル管理者アカウントを使用します。

移行元環境を準備する前に、上記のドキュメントを確認してください。

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

移行に使用する管理者アカウントをMicrosoft 365で作成するか、テナントのグローバル管理者アカウントを使用します。管理者アカウントには、ユーザーのメールボックスへのフルアクセス権、必要なAPI権限、または偽装権限が付与されている必要があります。

Microsoft 365のメールボックスまたはアーカイブメールボックスのエンドポイントで使用している先進認証アプリに、必要なAPI権限を追加することをお勧めします。追加方法については、こちらのガイドを参照してください。これは、BitTitanが推奨する方法です。

BitTitanの偽装によるアプローチは引き続き使用できますが、MicrosoftがExchange OnlineでのRBACアプリケーション偽装を段階的に廃止しているため、この方法はまもなく廃止される予定です。

MigrationWizでの手順

メールボックス移行プロジェクトを作成する

移行プロジェクトを作成します。

プロジェクトの推奨事項

プロジェクトの設定を完了した後は、「テナント間移行(TENANT TO TENANT MIGRATION)」ページに戻って、ユーザーの追加や設定の変更を行うことはできません。以下で説明するように、Azure ADグループでユーザーにスコープを設定すると、ユーザーの追加が可能になります。

ユーザーグループごとに個別のプロジェクトを作成することをお勧めします。既存のプロジェクトでユーザーの再検出を繰り返すことも可能ですが、管理を容易にし、各ユーザーグループにより多くのオプションを提供するために、ユーザーグループごとに新しいプロジェクトを作成することをご検討ください。

  1. マイ・プロジェクトへ」ボタンをクリックします。
  2. プロジェクトを作成(Create Project)」ボタンをクリックします。
  3. メールボックスプロジェクトを作成する(Create a Mailbox Project)」を選択します。

    mceclip0.png

  4. 「プロジェクト名(Project Name)」を入力し、「顧客(Customer)」の一覧から顧客を選択します。すでに顧客を作成済みの場合は、本セクションをスキップしてください。顧客をまだ作成していない場合は、「新規(New)」をクリックして、顧客の詳細情報を入力します。一度作成した顧客は、複数のプロジェクトで使用可能になるため、詳細情報の入力が必要となるのは1回のみです。
  5. 次のステップ」をクリックします。
  6. 既存のエンドポイントを選択するか、以下の手順に従って、新しいエンドポイントを作成します。
  7. 保存して概要へ移動」をクリックします。

エンドポイント

エンドポイントは、MigrationWizで作成します。ドロップダウンリストから既存のエンドポイントを選択する場合、表示されるエンドポイントは最大10までとなります。既存のエンドポイントが10を超える場合は、検索する必要があります。

エンドポイントの検索では、大文字、小文字、数字が区別されます。たとえば、「customer」を検索する際に「Cust0mer」と入力すると、検索結果には何も表示されません。作成したエンドポイントは、使用した固有のスペルや大文字が分かるように、リストにしておくことをお勧めします。

エンドポイントを作成する

次のタブを参照して、移行元および移行先エンドポイントを作成してください。

移行元エンドポイント移行先エンドポイント

次の手順に従って、移行元エンドポイントを作成します。

  1. 移行元の設定」をクリックします。
  2. 新規」をクリックします。
  3. 「エンドポイント名(Endpoint Name)」を入力します。エンドポイント名は、プロジェクトごとに異なる名前にすることをお勧めします。
  4. エンドポイントタイプ(Endpoint Type)」ドロップダウンメニューから、「Microsoft 365」を選択します。
  5. 「管理者ユーザー名(Administrator Username)」と「管理者パスワード(Administrator Password)」を入力します。この管理者は、グローバル管理者、または「移行元環境を準備する」セクションで作成した管理者である必要があります。 
  6. 追加(Add)」をクリックします。
  7. 「アプリケーション(クライアント)ID」、「ディレクトリ(テナント)ID」、「クライアントシークレット」の各フィールドに、値を入力します。

  8. 次のステップ」をクリックします。

「アプリケーション(クライアント)ID」、「ディレクトリ(テナント)ID」、「クライアントシークレット」

Microsoft 365のメールボックスおよびアーカイブの移行では、「アプリケーション(クライアント)ID」、「ディレクトリ(テナント)ID」、「クライアントシークレット」フィールドが追加表示されます。

「アプリケーション(クライアント)ID」と「ディレクトリ(テナント)ID」は入力が必須ですが、「クライアントシークレット」は任意です。これは、移行を実行するユーザーアカウントの権限によって異なります。Microsoft 365エンドポイントを作成する前に、以下の情報を確認してください。

  • 委任された権限を使用する場合、クライアントシークレット値の入力は必須ではありません。「クライアントシークレット」フィールドは、空白のままにしてください。

  • APIのアクセス許可を使用したアプリケーション偽装を使用する場合、クライアントシークレット値は必須です

  • 管理者アカウントで偽装ロールがすでに有効になっている(APIのアクセス許可を使用したアプリケーション偽装を使用していない)場合、クライアントシークレット値は必須ではありません。「クライアントシークレット」フィールドは、空白のままにしてください。

「アプリの登録」から「アプリケーション(クライアント)ID」と「ディレクトリ(テナント)ID」を取得する方法については、こちらの記事の手順3を参照してください。

移行先テナントのリージョン

MigrationWizの「移行先の設定(DESTINATION SETTINGS)」ページでは、テナントの優先リージョンを選択するためのドロップダウンが表示されます。選択したリージョンは、プロジェクトの「詳細オプション(Advanced Options)」の、「パフォーマンス(Performance)」タブ内の「移行先テナントの優先リージョン(Preferred region of destination tenant)」フィールドに反映され、その逆も同様となります。両フィールドに表示されるリージョン名は、常に同じになります。

移行のパフォーマンスと速度を最適化するには、移行先テナントに最も近いリージョンを選択します。

警告

このフィールドが空白のままでは、プロジェクトを保存することはできず、「このフィールドは空白のままにできません。(This field cannot be left blank.)」というエラーが表示されます。 

エンドポイントの検証

移行元および移行先の両エンドポイントに資格情報が提供され、顧客が「保存して概要へ移動」をクリックすると、MigrationWizはエンドポイントの検証を実行します。

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

エンドポイント設定時の一般的なエラー

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

推奨設定

お客様のプロジェクトのシナリオに応じた推奨設定については、次のナレッジベース記事を参照してください。Microsoft Entra Connectを使用したExchange Online Microsoft 365テナント間併用の推奨設定(Recommended Settings for Exchange Online Microsoft 365 Tenant to Tenant Coexistence with Microsoft Entra Connect)

ドメインアドレスを設定する

ドメインアドレスは、作成する併用オブジェクトのサフィックスとして機能します。「移行元のドメインアドレス(Source Domain Address)」を設定すると、移行先から移行元へのメール転送で、その独自ドメインがメールの転送先として指定されます。「移行元のドメインアドレス(Source Domain Address)」が空白のままの場合、移行元テナント内の「すべての」承認済みドメインが、有効なメール転送先として使用されます。単一のドメインを設定することにより、すべてのメール転送がその単一の独自ドメインに集約されます。

「移行先のドメインアドレス(Destination Domain Address)」の入力は必須です。このドメインは、「完全移行(Full Migration)」の実行中に移行元に設定されるメール転送で必要になります。

ベストプラクティス

UPNとプライマリメールアドレスを一致させることが、一般的な移行のベストプラクティスです。これにより、混乱なく移行を管理することができます。「onmicrosoft.com」アドレスに追加したエイリアス(Microsoft 365アカウントの代替メールアドレス)をメール転送に使用すると、確実で信頼性の高いメール転送が実現します。

グローバル管理者資格情報を設定する

管理ページにアクセスして、すべてのメールフロー設定とオブジェクト作成を行うには、グローバル管理者(GA)の資格情報が必要です。この資格情報は、ライセンスの割り当てや移行前/移行後のタスクの実行にも使用されます。組織内の情報セキュリティ部門が、GAのような強力な権限は承認できないという場合は、移行元と移行先の両方で、移行するメールボックスに応じて、権限にスコープを設定することができます。Microsoft 365内で必要とされる権限は、Exchange管理者の権限とライセンス操作を実行する権限です。そのため、権限にスコープを設定した場合は、「Exchange管理者」および「ユーザー管理者」を使用することができます。

メールボックスの検出範囲を設定する

この任意入力のフィールドは、移行元テナントで自動検出されるメールボックスの範囲を指定します。空白のままにしておくと、システムは移行元のすべてのメールボックスを検出します。グループ名を入力して、メールボックスの検出範囲を設定することをお勧めします。

入力するグループのベストプラクティスは、移行元テナントのExchange管理センターの「グループ」セクションで作成する「メールが有効なセキュリティグループ」です。メールボックスをセキュリティグループに追加してから、このオプションフィールドにそのグループ名を入力して適用します。グループ名にはスペースなどを使用することができますが、実際のグループ名と完全に一致する必要があります。

Exchange管理センターの「メールが有効なセキュリティグループ」の例は、次のようになります。

MESG.png

待ち時間

メンバーシップの設定とグループの作成には最大1時間を要することがあるため、検出プロセスを実行する前に、設定を完了して確認しておくことをお勧めします。

このオプション設定にはいつでも戻ることができ、グループ名の変更やメールボックスの再検出を行うことができます。設定を変更すると、新しいメンバーのメールボックスがプロジェクトに追加されますが、グループのメンバーではなくなったユーザーが削除されることはありません。メンバーではなくなったユーザーを削除するには、プロジェクトを削除し、すべてのメールボックスを再検出します。

配布リストとグループを移行する

これは、先ほど定義したメールボックスのスコープとは別のスコープです。これを設定すると、移行元テナントにあるアイテムと、それに関連付けられているメンバーシップのコピーが作成されます。プロジェクトのスコープを特定の「メールが有効なセキュリティグループ」に設定し、このダイアログセクションでオプションを選択すると、スコープ設定したグループのメンバーシップに関係なく、選択したオブジェクトが移行先テナントに作成されます。

選択可能なリストおよびグループは、次の通りです。

  • 配布リスト(Distribution Lists)
  • メールが有効なセキュリティグループ(Mail-enabled Security Groups)
  • セキュリティグループ(Security Groups)
  • 動的配布グループ(Dynamic Distribution Groups)

これらはプロジェクトの設定プロセス中に移行され、再検出プロセスで削除されることはありません。このオプションを設定する際は、これらのオブジェクトをシステムが自動で作成するのか、それとも手動で作成するのかについて、慎重に検討してください。

移行先テナントでのメールユーザーオブジェクトの作成

このセクションには、2つのオプションがあります。

  • 移行先テナントでメールユーザーオブジェクトを作成する(Create Mail User Objects in the Target Tenant)
    メールユーザーオブジェクトは、移行元オブジェクトと一致するように移行先テナントに作成されます。移行先でSMTPアドレスがすでに使用されている場合は、そのアドレスに数値が割り当てられます。最終的なカットオーバーの前に、SMTP転送機能が移行先オブジェクトに適用され、移行元メールボックスにメールが転送されるようになります。
  • メールユーザーオブジェクトを作成しない(Do not create Mail User Objects)
    このオプションを選択すると、移行先テナントにメールユーザーオブジェクトは作成されません。このオプションは、メールボックスがすでに移行先テナントでプロビジョニングされている場合に使用します。

重要

マッチングは、SMTPアドレス(@の左側部分)に対して実行されます。重複する名前がある場合は、移行を開始する前に、プロジェクトビューでそれらの重複を確認する必要があります。

また、移行元と一致するアイテムを移行先に作成するかどうか、その移行先アイテムに移行元オブジェクトへのメール転送を設定するかどうかを判断する必要があります。 

前段階移行プロセス中にメールユーザーオブジェクトを変換する(Convert Mail User objects during Pre-Stage Process)

このオプションを使用すると、「前段階移行(Pre-Stage Migration)」プロセスの実行中に、移行先テナントのメールユーザーオブジェクトがメールボックスユーザーオブジェクトに変換されます。これにより、データの移行が可能になります。このタスクを手動で実行する場合は、「前段階移行(Pre-Stage Migration)」プロセスを開始する前に、このオプションの選択を解除してください。

前段階移行プロセス中に移行先メールボックスにライセンスを適用する(Apply Licenses to Target Mailboxes during Pre-Stage Process)

「前段階移行(Pre-Stage Migration)」プロセスの実行中にライセンスを適用するかどうかを選択することができます。ライセンスタイプの選択では、お客様の移行先テナントの初期スキャンに基づいて、利用可能なライセンスが一覧表示されます。メールボックスのライセンスを個別に管理する場合は、このオプションの選択を解除してください。

重要

本移行では、特定のMicrosoft 365ライセンスのみがサポートされています。サポートされているライセンスタイプは、移行設定のドロップダウンメニューに一覧表示されます。1つのプロジェクトで使用できるMicrosoft 365のライセンスタイプは1つのみで、プロジェクトの設定後に変更することはできません。

重要

このオプション、または上記のメールユーザーオブジェクト変換オプションの選択を解除して、データを受信するメールボックスがない状態で「前段階移行(Pre-Stage Migration)」を開始すると、システムエラーが発生します。このオプションは、プロジェクトの設定にプロビジョニングシステムが導入されており、お客様が手動でライセンスの個別適用を行うことが難しい場合に最適です。

移行後のオプション

最後に、移行後の機能を決定する必要があります。通常、「完全移行(Full Migration)」が完了すると、移行先テナントのメールボックスからメール転送が削除され、新しいメール転送が移行元のメールボックスに設定されます。移行の設定時は、デフォルトで「移行元メールボックスにメール転送を設定する(Place Forwarder on Source Mailbox)」のラジオボタンが選択されています。移行プロセス中に移行先に設定されていたメール転送を残して、移行先から移行元へのメール転送を継続したい場合は、「移行先メールボックスにメール転送を残す(Leave Forwarder on Target Mailbox)」のラジオボタンを選択します。

さまざまな移行シナリオで役立つもう1つのオプションとして、「MIGWIZ-」プレフィックスを追加して、「移行元メールボックスの名前を変更する(Rename Source Mailbox)」オプションがあります。移行元の元の名前のメールボックスには、メール連絡先レコードが追加されます。ユーザーは移行元を使用できなくなるため、新しい移行先テナントにログインする必要があります。移行元を削除せずに名前を変更することで、必要に応じて回復して再利用することができます。連絡先レコードを保持することで、併用機能が維持されます。移行後の3つのオプションについては、以下のスクリーンショットを参照してください。

mceclip1.png

検出プロセスを開始する

プロジェクトを保存して次に進むと、システムによって移行元環境の初期スキャンが実行されます。また、移行先環境にオブジェクトを作成するオプションが選択されている場合は、そのタスクも実行されます。この動作が行われている間は、ページに「処理中(Processing)」と表示されます。準備が整うと、通常のプロジェクトウィンドウのメインビューにジャンプします。検出のステータスは、次のようになります。

mceclip6.png

併用プロジェクトでは、「前段階移行(Pre-Stage Migration)」プロセス中に適用されるライセンス(選択した場合)が、右側の通知セクションに追加表示されます。

重要

併用設定が正常に完了すると、以下の例のように、検出されたユーザーのリストが移行プロジェクトビューに表示されます。

「前段階移行(Pre-Stage Migration)」または「完全移行(Full Migration)」サイクルを実行する前に、プロジェクトの「詳細オプション(Advanced Options)」に、移行元および移行先テナントのクライアントIDとテナントIDのサポートオプションを追加する必要があります。これらのオプションは、本ガイド前半の「先進認証の要件」セクションで必要な手順を実行していれば、すでに作成されているはずです。 MigrationWizプロジェクトにサポートオプションを追加する手順については、次のナレッジベース記事の「サポートオプションの設定」セクションを参照してください。MigrationWizのサポートオプション

mceclip8.png

アイテムを再検出する

「アイテム再検出(Rediscover Items)」メニューをクリックすると、いつでもアイテムを再検出することができます。これは、Azure ADのスコープグループに新しいメールボックスが追加された場合に、非常に便利です。「アイテム再検出(Rediscover Items)」を実行すると、プロジェクトに新しいメールボックスが追加されますが、既存のメールボックスには影響しません。

mceclip7.png

「前段階移行(Pre-Stage Migration)」を実行する

メールボックスの「前段階移行(Pre-Stage Migration)」を実行すると、プロジェクトの設定で選択したオプションに応じて、次のタスクが開始されます。

  • 「前段階移行プロセス中にメールユーザーオブジェクトを変換する(Convert Mail User objects during Pre-Stage Process)」オプションを選択した場合、移行プロセス中にメールユーザーオブジェクトがユーザーメールボックスに変換され、Microsoft 365のバックエンドでメールボックスがプロビジョニングされて、移行元からのデータを受け入れることができるようになります。
  • 「前段階移行プロセス中に移行先メールボックスにライセンスを適用する(Apply Licenses to Target Mailboxes during Pre-Stage Process)」オプションを選択した場合、選択したライセンスがユーザーメールボックスに適用されます。これにより、移行先のメールボックスがアクティブになり、アカウントによるログインが可能になります。つまり、システム上でこのメールボックスがアクティブなメールボックスとなります。
  • メールボックスへの変換が行われた後も、メールユーザーオブジェクトに設定されていたメール転送は、引き続き有効です。

「前段階移行(Pre-Stage Migration)」の手順

重要

上記のタスクを実行するオプションを選択しなかった場合は、「前段階移行(Pre-Stage Migration)」の手順を開始する前に、必ず移行先のメールボックスをプロビジョニングして、ライセンスを適用してください。これを実行しないと、メールボックスでエラーが発生します。

タスクを実行するメールボックスを選択して、「前段階移行(Pre-Stage Migration)」プロセスを開始します。

  1. 上部の「移行を開始」ボタンをクリックします。
  2. 前段階移行(Pre-Stage Migration)」を選択します。
  3. 自動応答(Automatic Replies)」のボックスのチェックを外します(今後、このオプションは「前段階移行(Pre-Stage Migration)」サイクルから削除される予定です)。
  4. 「移行のスケジューリング」セクションのドロップダウンリストから、「90日前(90 Days Ago)」を選択します。
  5. 移行を開始」をクリックします。

mceclip9.png

mceclip10.png

「90日前(90 Days Ago)」を推奨しますが、他のオプションを選択することもできます。「前段階移行(Pre-Stage Migration)」では、古いアイテムのみが移行されます。期間を区切ってデータを小さく分割し、複数回に分けて移行することができます。

ウィンドウの下部では、事前に設定した日時に開始するように、移行をスケジュールすることができます。

blobid0.png

重要な注意点

移行プロセスは指定された日時に開始されますが、移行前のタスクは即座に実行されます。つまり、メールボックスの作成、ライセンスの割り当て、および移行先から移行元へのメール転送の設定に関するすべてのタスクが、すぐに実行されます。

完全移行(Full Migration)

特定のユーザーグループに対してカットオーバーを実行するタイミングになった時は、該当するユーザーを選択して、「完全移行(Full Migration)」を実行します。これにより、移行元に新しいメール転送が設定され、プロジェクトの設定時に選択したオプションに応じて、移行先メールボックスのメール転送が削除されるか、そのまま残ります。

  1. ユーザーを選択します。
  2. 上部の「移行を開始」ボタンをクリックします。
  3. 完全移行(Full Migration)」を選択します。

    重要

    自動応答(Automatic Replies)」は、ユーザーの最終移行サイクルでのみ移行することをお勧めします。
  4. 移行を開始」をクリックします。ほとんどのデータが「前段階移行(Pre-Stage Migration)」で移行されているため、この差分移行はすぐに完了します。Microsoft 365からMicrosoft 365への移行では、高帯域幅を利用することができます。

移行は、事前に設定した日時に開始するようにスケジュールすることができます。最初に「前段階移行(Pre-Stage Migration)」を実行せずに、「完全移行(Full Migration)」プロセスを実行すると、プロジェクトの設定で選択したオプション(メールボックスライセンスの割り当てやメール転送に関する設定など)が即座にに実行されます。指定した日時まで保留される処理は、データ移行のみです。

mceclip11.png

mceclip1.png

エラーレポート

「前段階移行(Pre-Stage Migration)」または「完全移行(Full Migration)」で実行されたタスクのいずれかが失敗した場合、現在では、ラインアイテムの移行概要ビューに詳細なログが表示されます。エラーの詳細を確認するには、コンソールでユーザーのメールアドレスをクリックします。右側の「移行エラー(MIGRATION ERRORS)」セクションに、エラーレポートが表示されます。以下に例を示します。

mceclip0.png

この例では、移行先テナントのラインアイテムの数が、利用可能なMicrosoft 365ライセンスの数を超えているため、エラーが発生しました。

エラーを解決した後、「前段階移行(Pre-Stage Migration)」を再度実行すると、前回停止した所から移行が再開されます。

MXレコード

すべてのユーザーが正常に移行されたら、DNSプロバイダーのポータルで、MXレコードを切り替えます。その際に、自動検出(CNAME)レコードの設定も行います。

ユーザーリストを確認し、「移行に失敗しました(Failed)」という赤いエラー表示をクリックします。表示された情報に従って、操作を行ってください。

アイテム再検出(Rediscover Items)

移行サイクルでエラーが発生した場合、推奨される最初の解決策は、プロジェクト全体で「アイテム再検出(Rediscover Items)」サイクルを実行することです。これを実行すると、使用している移行元または移行先UPNの変更が整理され、多くの場合、問題解決へと大きく前進することができます。

「前段階移行(Pre-Stage Migration)」サイクルを再実行することで、これらの問題が解決できる場合もあります。 問題が解決しない場合は、サポートにお問い合わせください。

関連トピック

 

この記事は役に立ちましたか?
3人中0人がこの記事が役に立ったと言っています