このガイドでは、Microsoft 365インスタンスから別のMicrosoft 365インスタンスにメールデータを移行する際に必要な手順について説明しています。
このガイドには、移行中に環境を併用使用する場合の手順は含まれていません 。併用を使用する場合の移行戦略ガイドについては、「Microsoft 365からMicrosoft 365への移行ガイド: 併用設定を使用して、異なるドメインへ移行する場合」を参照してください。
エンドポイントで使用する管理者アカウントでは、アプリのパスワードの使用および多要素認証(MFA)/二要素認証(2FA)はサポートされていません。
初めての移行
初めて移行を実行する際は、移行計画と戦略を参照してください。移行の計画と設定、および一般的な移行のベストプラクティスについて説明しています。移行を開始する前に、内容を確認することをお勧めします。
制限
MigrationWizは同期ツールではありません。移行中に移行元で更新された移行済みアイテムは、移行先では更新されません。
MigrationWizは、ワークグループ全体に対し、移行プロジェクトを共有する機能をサポートしています。プロジェクト共有機能が有効になっている場合、すべてのアクティブなエージェントは全移行プロジェクトを表示できます。
ユーザーへの影響を最小限にするには、MigrationWizの手順で説明されているように、この移行を複数回の移行サイクルで完了することをお勧めします。
MigrationWizでは、移行可能な最大ファイルサイズは、移行タイプと環境によって異なります。ただし、60GBを超えるファイルを移行することはできません。
移行できるアイテム
- 受信トレイ
- フォルダー
- メール
- 連絡先
- 予定表
- タスク
- ジャーナル
- メモ
- サーバー側のルール
- フォルダー権限
- 投稿(移行先がExchangeまたはMicrosoft 365の場合)
- 予定表の承認ステータスのメール
リソースメールボックス
リソースメールボックスは、通常のユーザーメールボックスと同じ方法で処理します。Webクライアント (Outlook Web Accessなど) を使用してリソースメールボックスにログインできる場合は、ログインしてデータを移行することも可能です。Webクライアント (OWA など)を使用してリソースメールボックスにログインする方法がない場合、ログインしてデータを移行することはできません。
ユーザーは、リソースメールボックスを共有予定表としてのみ所有している場合があります。このような場合、ユーザーのメールボックスが移行されると、リソースメールボックスの予定表をユーザーの予定表の1つとして移行できます。移行が完了したら、予定表に共有/権限を設定して、他のユーザーがアクセスできるようにすることができます。
移行されないアイテム
- 安全な送信者リスト/ブロックされた送信者リスト
先進認証要件
次のオプションは、メールボックス、アーカイブメールボックス、およびパブリックフォルダープロジェクトのExchange Webサービス (EWS)で、Exchange Onlineの移行元および移行先テナントの両方に適用されます。グローバル管理者アカウントを使用して、以下の設定手順を実行します。
重要:Microsoft 365エンドポイントで必要なオプションを設定しない場合、プロジェクトで次の401エラーが表示され、ジョブが失敗する可能性があります。Http POST request to 'autodiscover-s.outlook.com' failed (「autodiscover-s.outlook.com」へのHttp POSTリクエストが失敗しました) - 401 Unauthorized
プロジェクトで使用している管理者アカウントは、管理者アカウントのアクセスをブロックすることが可能な多要素認証(MFA)/二要素認証(2FA)ポリシーまたは条件付きアクセスポリシーから除外する必要があります。この要件は、プロジェクトで移行されるアイテムまたはユーザーには適用されません。
MicrosoftがExchange Onlinでの基本認証のサポートを終了した2022年12月以降は、 Exchange Onlineのメールボックス、アーカイブメールボックス、およびパブリックフォルダープロジェクトでは、MigrationWizと連携するために先進認証を設定するのがデフォルトの方法になりました。認証方法の変更の詳細については、次のMicrosoftのドキュメントを参照してください。この変更がテナントに与える影響についての追加の情報は、Microsoftにお問い合わせください。Exchange Onlineでの基本認証の廃止
テナントでは、Azureセキュリティの既定値群もテナントで無効にする必要があります。(すべての新しいExchange Onlineテナントでは、この既定値群はデフォルトで有効になっていることが多く、 この要件を回避する方法はありません。) Azureセキュリティの既定値群を有効/無効にする手順については、次のMicrosoftのドキュメント内の「セキュリティの既定値群の有効化」セクションを参照してください 。無効にするには、「セキュリティの既定値群の有効化(Enable Security defaults)」を「いいえ(No)」に設定します:Azure ADのセキュリティの既定値群
先進認証での手順- Azure Active Directory管理センター(Azure AD admin console)に、グローバル管理者としてログインします。
- Azure Active Directory管理センターで、「Azure Active Directory」を選択します。
- 「管理(Manage)」メニューから、「アプリの登録(App registrations)」を選択します。
- 画面上部の「新規登録(New registration)」を選択します。
- アプリに固有の名前を付けます。名前は、必要に応じていつでも変更することができます。
- 「任意の組織ディレクトリ内のアカウント(Accounts in any organizational directory)」を選択します。
- 「リダイレクトURI(Redirect URI)」で、「パブリッククライアント/ネイティブ(モバイルとデスクトップ) (Public client (mobile & desktop))」を選択し、フィールドに「urn:ietf:wg:oauth:2.0:oob」を入力します。
- 「登録(Register)」をクリックします。
- 「アプリの登録(App registrations)」に戻ります。
- 上記の手順で作成したアプリを選択します。
- 「概要(Overview)」ページに「アプリケーション(クライアント)ID (Application (client) ID)」と「ディレクトリ(テナント)ID (Directory (tenant) ID)」が表示されます。
- この2つのIDは、後のプロセスで使用するため、メモ帳などの他のアプリケーションにコピーしておきます。
- 「管理(Manage)」メニューから、「認証(Authentication)」を選択します。
- 「パブリッククライアントフローを許可する(Allow public client flows)」オプションで、「はい(Yes)」を選択します。
- 「保存(Save)」をクリックします。
- 「管理(Manage)」メニューから、「APIのアクセス許可(API permissions)」を選択します。
- 「アクセス許可の追加(Add a permission)」 を選択します。
-
「所属する組織で使用しているAPI(APIs my organization uses)」を選択します。
-
下にスクロールして、「Office 365 Exchange Online」を選択します。
-
「委任されたアクセス許可(Delegated permissions)」を選択します。
-
「EWS」を選択します。
- 「EWS」の下にある「EWS.AccessAsUser.All」のチェックボックスをオンにします。
- 「アクセス許可の追加(Add permissions)」 をクリックします。この権限は、OAuthアプリケーション(MigrationWiz)をEWSに関連付けるためだけに使用されます。
-
- 重要:この権限は、すべてのメールボックスデータへのアクセスを許可するものではありません。
-
- 「管理者の同意を与えます(Grant admin consent)」 をクリックします。
- 「はい(Yes)」をクリックして、設定を確定します。
- MigrationWizで、先進認証を設定する必要があるプロジェクトを選択します。
- 「プロジェクトの編集」メニューをクリックします。
- 「詳細オプション(Advanced Options)」を選択します。
- 「サポートオプション(Support Options)」 で、上記の手順で保存したクライアントIDとテナントIDの情報を、次の形式で入力します。
- 移行元で先進認証を有効にする場合:
ModernAuthClientIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ModernAuthTenantIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- 移行先で先進認証を有効にする場合:
ModernAuthClientIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ModernAuthTenantIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxの部分には、ユーザーのテナントのクライアントIDとテナントIDを入力します。
- これらのオプションは、テナントの設定に応じて、移行元または移行先のいずれか、あるいはその両方で入力することができます。
- これらのオプションは、先進認証の有効化が必要なMigrationWizプロジェクトごとに設定する必要があります。
- 移行元で先進認証を有効にする場合:
- 「資格情報の検証(Verify Credentials)」を実行して、MigrationWizが先進認証を使用して接続できることを確認します。
- 検証済みのアイテムをクリックします。MigrationWizの移行情報ページに、「先進認証を使用してテナントに接続中(Connecting to tenant using modern authentication)」というメッセージが表示されます。このメッセージは、「移行エラー(MIGRATION ERRORS)」ボックスに表示されますが、エラーではありません。これは、先進認証が有効になり、接続に使用されていることを証明するメッセージです。
移行元の準備
管理者アカウントを作成する
移行に使用する管理者アカウントをMicrosoft 365で作成するか、テナントのグローバル管理者アカウントを使用します。管理者アカウントには、ユーザーのメールボックスへのフルアクセス権、または偽装権限が付与されている必要があります。Microsoftによって移行がスロットリングされる可能性を減らすには、偽装を使用することをお勧めします。
手動で偽装を設定するには:
- 移行先で管理者資格情報を使用します。
- MigrationWizアカウントにサインインします。
- 「プロジェクトの編集」をクリックし、「詳細オプション(Advanced Options)」をクリックします。
- Microsoft 365から移行する場合は、「移行元(SOURCE)」の「偽装を使用する(Use impersonation to authenticate)」をオンにします。
- Microsoft 365に移行する場合は、「移行先(DESTINATION)」の「偽装を使用して認証する(Use impersonation to authenticate)」をオンにします。
- 「保存(Save)」をクリックします。
重要:偽装が有効な状態で、プロジェクトでジョブの実行が要求されると、MigrationWizはテナントでリモート PowerShell コマンドを実行して、プロジェクトで使用されている管理者アカウントにアプリケーション偽装(Application Impersonation)ロールの付与を試みます。これを成功させるには、プロジェクトの管理者アカウントがグローバル管理者で、必要な権限を持っている必要があります。
Microsoft 365は、このプロセスに対して随時応答するとは限らず、プロジェクトでジョブが失敗し、移行中のユーザーを偽装する権限がないというエラーが発生する場合があります。
エラーが発生したり、プロジェクトで使用されている管理者アカウントがグローバル管理者ではない場合は、以下の「アプリケーションの偽装( Application Impersonation)を手動で許可する」で説明されている手順に従って、テナントでこのタスクを手動で実行します (この手順をMigrationWizに実行させる代わりに、事前に実行しておくことができます)。
注:次のリモート PowerShell コマンドは、完了するまでに数分かかる場合があります。
- 手順を実行する際は、グローバル管理者アカウントを使用していることを確認してください
- Windows の 「スタート」ボタンをクリックします。
- 「Windows PowerShell」 を検索します (PowerShellは既にインストールされています)。
- 管理者コンテキストでPowerShellを開始します (右クリック ->「管理者として実行する」)。
- 次のPowerShell コマンドを1つずつ実行します。
Set-ExecutionPolicy Unrestricted
$LiveCred = Get-Credential
Install-Module -Name ExchangeOnlineManagement
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred
Enableコマンドの実行には時間がかかり、エラーが発生する場合があります。その場合は、数分待ってから再度実行してください。Enable-OrganizationCustomization
New-ManagementRoleAssignment -Role "ApplicationImpersonation" -User admin@domain.com
- 上記のPowerShellコマンドの「admin@domain.com」の部分は、移行に使用する管理者アカウントに置き換えてください。
- 「この操作は現在のサービス オファーでは使用できません。(This operation is not available in current service offer.」などのエラーは無視します。
- 「管理ロール 'ApplicationImpersonation' [...] の割り当ては、ユーザーが移行されるまで有効になりません。(The assignment of the management role 'ApplicationImpersonation' [...] won't take effect until user is migrated.)」などのエラーは無視してください。
- Powershell で GCC High に接続する場合は、Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -ExchangeEnvironmentName O365USGovGCCHighを使用します。
ユーザーリストをCSVファイルにエクスポートする
これは、MigrationWizプロジェクトにユーザーを一括追加するときに使用できます。ユーザーリストをコピーし、MigrationWizプロジェクト ダッシュボード内の 「新しいアイテムを追加(Add New Items)」 > 「一括追加」 の移行元および移行先メールアドレスの列に貼り付けます。
ユーザーリストをエクスポートするには:
- Microsoft 365管理ポータルに移動します。
- 「ユーザー(Users)」をクリックします。
- 「アクティブなユーザー(Active Users)」をクリックします。
- 「ユーザーのエクスポート(Export)」をクリックします。
- 「続ける(Continue)」をクリックします。
今後の移行でアップロードする際に使用するため、アクセスできる場所にcsvを保存してください。
移行先の準備
ユーザーアカウントを設定する
移行先のMicrosoft 365テナントでユーザーアカウントを設定し、ライセンスを割り当てます。設定および割り当てを行う方法はいくつかあります。(以下のリンクをクリックすると、外部サイトの記事が開きます。)
- 手動で1つずつ追加する。
- CSVファイルを使用して一括でインポートする。
- PowerShellスクリプトを使用する。
管理者アカウントを作成する
移行に使用する管理者アカウントをMicrosoft 365で作成するか、テナントのグローバル管理者アカウントを使用します。管理者アカウントには、ユーザーのメールボックスへのフルアクセス権、または偽装権限が付与されている必要があります。Microsoftによって移行がスロットリングされる可能性を減らすには、偽装を使用することをお勧めします。偽装を手動で設定する手順については、このガイドの「移行元の準備」セクションの「アプリケーションの偽装( Application Impersonation)を手動で許可する 」を参照し、移行先テナントに適用します。
管理者アクセスをテストする
管理者がユーザーのメールボックスにアクセスできることをテストします。独自ドメイン「domainname.com」アドレスではなく、「tenantname.onmicrosoft.com」アドレスへのアクセスをテストします。「tenantname.onmicrosoft.com」アカウントがMicrosoft 365の各メールボックスに紐づいていることを確認してください。デフォルトでは紐づいていますが、紐づいていない場合は、各アカウントにエイリアスとして追加する必要があります。Microsoft 365管理ポータルまたはPowerShellスクリプトを介して追加することができます。
MigrationWizでの手順
メールボックス移行プロジェクトを作成する
- 「マイ・プロジェクトへ」ボタンをクリックします。
- 「プロジェクトを作成(Create Project)」 ボタンをクリックします。
- メールボックスプロジェクトを作成します(Create a Mailbox Project)。メールボックスの移行では、管理者の資格情報を使用してメールボックスにアクセスします。ほとんどの移行シナリオで、移行元メールボックスへのフルアクセス権を持つ管理者アカウントが必要です。
- 「次のステップ」をクリックします。
- 「プロジェクト名(Project Name)」を入力し、「顧客(Customer)」を選択します。
- 「次のステップ」をクリックします。
- 「エンドポイント(Endpoint)」ドロップダウンメニューから移行元エンドポイントを選択するか、次の手順に従って新しいエンドポイントを作成します。
- 「エンドポイント(Endpoint)」ドロップダウンメニューから移行先エンドポイントを選択するか、次の手順に従って新しいエンドポイントを作成します。
- 「保存して概要へ移動」をクリックします。
メールボックスの移行設定:プロジェクトのすべての設定は、そのプロジェクトに関連付けられているすべてのメールボックスに適用されます。チェックボックスで設定する場合、選択した設定のみがプロジェクトに適用されます。プロジェクトから継承されている選択済みの設定は、チェックボックスを選択しなくても、無効になることはありません。
エンドポイント
エンドポイントは、MSPCompleteではなくMigrationWizで作成します。次の手順に従って、MigrationWizでエンドポイントを作成してください。
既存のエンドポイントを選択する場合、ドロップダウンリストには、エンドポイントが最大10までしか表示されないため、注意が必要です。既存のエンドポイントが10を超える場合は、検索する必要があります。エンドポイントの検索では、大文字、小文字、数字が区別されます。たとえば、「customer」を検索する場合、「Cust0mer」と入力すると、検索結果は表示されません。作成したエンドポイントのリストを作り、固有のスペルや大文字の使用について記録しておくことをお勧めします。
既存のエンドポイント (この移行シナリオ用のエンドポイントが既にある場合) を使用するか、新しいエンドポイントを作成することができます。
新しいエンドポイントを作成するには:(移行元エンドポイントと移行先エンドポイントの両方に次の手順を実行します)
- 「新規」をクリックします。
- エンドポイントの名前を入力します。(移行元エンドポイントと移行先エンドポイントに一意の名前を作成することをお勧めします。)
- 「エンドポイントの種類(Endpoint Type)」で、以下のオプションから、使用しているMicrosoft 365テナントの種類に対応するエンドポイントを選択します。
- Microsoft 365 - (ホストされているGoDaddy O365およびGCC 商用テナントにも使用されます)
- Microsoft 365(中国)
- Microsoft 365(ドイツ)
- Microsoft 365 (米国政府) - (GCC High テナントのみに使用)
- フィールドに管理者のユーザー名とパスワードを入力します。これは、グローバル管理者、または移行元環境を準備する際に作成した管理者です。
- 「追加(Add)」をクリックします。
- 「次のステップ(Next Step)」をクリックします。
ユーザーを追加する
重要
新しい移行先テナントにドメイン名を移行する場合、移行プロジェクト内のユーザーは、移行元と移行先の両方で、独自ドメインではなく .onmicrosoft.com ドメインを使用して移行することをお勧めします。
これを設定するには、独自ドメインを使用してプロジェクトにユーザーを追加した後にすべてのユーザーを選択し、メニューの「ドメインアドレスを変更(Change domain addresses)」オプションをクリックして、 .onmicrosoft.com ドメインを使用するようにユーザーを一括変更します。
移行するユーザーアカウントをプロジェクトに追加します。プロジェクトの規模に応じて、いくつかの方法があります。手順の詳細については、各オプションをクリックし、表示される説明に従ってください。
小規模な移行:
小規模な移行の場合、「クイック追加(Quick Add)」を使用して、ユーザーを1人ずつ簡単に追加することができます。手順は以下の通りです。
大規模な移行:
大規模な移行では、「アイテム自動検出(Autodiscover Items)」または「一括追加」オプションを使用することをお勧めします。
「アイテム自動検出(Autodiscover Items)」を使用すると、移行元テナントで検出されたすべてのユーザーがプロジェクトに追加されます。移行しないユーザーは、その後の編集でプロジェクトから削除することができます。すべてのユーザーは、移行元メールアドレスと移行先メールアドレスの両方に、移行元メールアドレスが指定された状態で追加されます。メールアドレスのドメインは、プロジェクトページ上部の「ドメインアドレスを変更(Change domain addresses)」ボタンで変更することができます。移行元から移行先へユーザー名を変更して移行する場合は、「一括追加」オプションの使用をお勧めします。MigrationWizで先進認証を使用するように設定されている場合、移行元の「自動検出(Autodiscover)」を使用してプロジェクトにユーザーを追加するオプションが機能しません。
「一括追加」では、ユーザーの移行元と移行先のメールアドレスが記載されたCSVファイルを使用して、ユーザーをプロジェクトに一括追加します。テナントから特定のグループのみを移行する場合は、「一括追加」オプションを使用することをお勧めします。
MigrationWizでは、メールボックスをシステムに一括でインポートすることができます。
1つ以上のメールボックスをインポートする方法:
- MigrationWizアカウントにサインインします。
- 「一括追加」を実行するプロジェクトを選択します。
- 「新しいアイテムを追加(Add New Items)」をクリックします。
- 「一括追加」をクリックします。
- ページの指示に従って、操作を続けてください。
MigrationWizのアイテム自動検出(Autodiscover Items)を使用すると、移行元環境からアイテムを検出し、プロジェクトにインポートすることができます。
この機能を使用するには、いくつかの要件があります。
- 移行元は、Exchange 2007以降、Microsoft 365、またはGoogle Workspace(G Suite)である必要があります。Google Workspaceで「アイテム自動検出(Autodiscover Items)」を使用する場合は、すべてのGoogle Workspaceドメインを、エンドポイントのドメインリストに追加する必要があります。
- メールボックスのアドレスがMigrationWizのラインアイテムにインポートされている場合、Google Workspaceは自動検出をサポートしません。
- 移行元エンドポイントは、管理者資格情報を使用して設定する必要があります。
- メールボックス移行プロジェクトでは、移行元エンドポイントの設定時に指定した管理者アカウントに、メールボックスが関連付けられている必要があります。
- 管理者のメールボックスは、公開されているグローバルアドレス一覧(GAL)に表示されている必要があります。
- 移行プロジェクトの種類は、メールボックス移行プロジェクトである必要があります。移行の詳細な手順については、該当する移行ガイドを参照してください。すべての移行ガイドは、ヘルプセンターのサイトに掲載されています。
- MigrationWizで先進認証を使用するように設定されている場合、移行元の「自動検出(Autodiscover)」を使用してプロジェクトにユーザーを追加するオプションが機能しません。
注:接続元のIPアドレスを制限する方法はありません。 IPロックダウンガイド(IP Lockdown guide)で説明されている手順は、ここでは適用されません。 IPアドレスをホワイトリストに登録する必要がある場合は、利用可能な他のオプションを使用して、アイテムをプロジェクトに追加することをお勧めします。
先進認証を使用している場合、「アイテム自動検出(Autodiscover Items)」は使用することができません。
「アイテム自動検出(Autodiscover Items)」では、次のアイテムを検出します。
- メールボックスの移行では、「アイテム自動検出(Autodiscover Items)」で検出された移行元のすべてのメールボックスが一覧表示されます。
「アイテム自動検出(Autodiscover Items)」を実行する手順
-
ユーザーをインポートするプロジェクトのページにアクセスします。
-
プロジェクトの移行元エンドポイントが作成されていることを確認します。
-
ページ上部のナビゲーションバーで、「新しいアイテムを追加(Add New Items)」をクリックし、ドロップダウンメニューから、「アイテム自動検出(Autodiscover Items)」を選択します。 「自動検出を開始」ボタンをクリックします。
-
検出が完了したら、「アイテムをインポート」ボタンをクリックして、アイテムをMigrationWizプロジェクトにインポートします。
プロジェクトの「詳細オプション(Advanced Options)」を設定する
次のオプションは、移行シナリオで最も有用なオプションです。
移行元で偽装(impersonation)を使用するように設定します。「移行元で偽装を使用する(Use Impersonation at Source)」チェックボックスにチェックを入れます。
移行先で偽装を使用するように設定します。「移行先で偽装を使用する(Use impersonation at Destination)」チェックボックスにチェックを入れます。
「サポート(Support)」タブ内の「サポートオプション(Support Options)」フィールドで、次の設定を追加します。
RecipientMapping="@sourcetenantname.onmicrosoft.com->@destinationdomainname.com"
上記の「RecipientMapping(受信者アドレスマッピング)」は一例です。そのままコピーしないでください。顧客のドメイン名に合わせて、移行元、移行先のドメイン名をそれぞれ「sourcetenantname.onmicrosoft.com」「destinationdomainname.com」の代わりに記述してください。
Microsoft 365からMicrosoft 365への移行では、受信者アドレスマッピングは非常に重要な手順です。これにより、旧アカウント名「sourcetenantname.onmicrosoft.com」(テナントが削除されて利用不可)を使用せずに、新しい移行先ドメイン名にマッピングされるため、「完全(差分)移行(Full (Delta) Migration)」の完了後も、移行先のメールが返信可能になります。
受信者アドレスマッピングは、以下の点で有用です。
- 同じドメイン名のまま、またはドメイン名を変更して、移行元テナントから移行先テナントへ移行する場合、「完全(差分)移行(Full (Delta) Migration)」の実行後であっても、すべてのメールが返信可能な状態を維持します。
- 同じドメイン名のまま、またはドメイン名を変更して、移行元テナントから移行先テナントへ移行すると、カレンダーの所有権と表示名が、移行先で一致します。
1つの移行元ドメインから複数の移行先ドメインへ移行する際に受信者アドレスマッピングを行う場合は、移行先ドメインごとにプロジェクトを作成する必要があります。
ドメイン名が変更される場合は、RecipientMappingで移行元の独自ドメインを次の例のように使用できます。RecipientMapping="@sourcedomainname->@destinationdomainname"
RecipientMappingでは、移行先ドメインが同じであれば複数のマッピング式(mapping expression)を使用できます。
ユーザー プレフィックスを変更する場合は、次の手順を参照してください。 ユーザー プレフィックスの変更
「資格情報の検証(Verify Credentials)」を実行する
データの移行やライセンスの消費をすることなく、MigrationWizのユーザー資格情報を検証することができます。
- 検証するユーザーを含むプロジェクトを開きます。
- 検証するアイテムを選択します。
- ダッシュボードの「移行を開始」ボタンをクリックします。
- ドロップダウンリストから「資格情報の検証(Verify Credentials)」を選択します。
検証が完了すると、検証結果が「ステータス(Status)」セクションに表示されます。
ライセンス
移行するすべてのユーザーに、「ユーザー移行バンドル(User Migration Bundle)」ライセンスを購入して適用します。この移行タイプには、ユーザー「ユーザー移行バンドル(User Migration Bundle)」をお勧めします。
- UMB(ユーザー移行バンドル)ライセンスでは、1ライセンスあたりの移行可能データ量に制限はありません。
- 「ユーザー移行バンドル(User Migration Bundle)」ライセンスは、顧客のユーザーに適用され、購入日から12か月間有効です。
- 「ユーザー移行バンドル(User Migration Bundle)」ライセンスを使用した移行には、ドキュメント、個人用アーカイブ、およびDeploymentProプロジェクトがすべて含まれます。
- 「ユーザー移行バンドル(User Migration Bundle)」ライセンスは、手動で適用する必要があります。
ライセンスの購入
- BitTitanアカウントにサインインします。
- 上部のナビゲーションバーで、「購入(Purchase)」をクリックします。
- 必要なライセンスタイプの「選択(Select)」ボタンをクリックします。
- 購入するライセンス数を入力します。「今すぐ購入(Buy Now)」をクリックします。
- 必要に応じて「請求先住所(Billing Address)」を入力します。
- 「次へ(Next)」をクリックします。
- 「注文内容(Order Summary)」を確認し、支払い方法を入力します。
- 「購入する(Place Your Order)」をクリックします。
「ユーザー移行バンドル(User Migration Bundle)」ライセンスの適用
- https://migrationwiz.bittitan.comで、MigrationWizにサインインします。
- サインイン後、「メール」フィールドの上にある「MigrationWiz」ボタンをクリックするか、MSPCompleteページにサインイン後、「すべての製品(All Products)」ボタンをクリックし、「MigrationWiz」を選択します。
- 左のナビゲーションウィンドウの上部で、ワークグループを選択します。
注: これは顧客と移行プロジェクトを作成したワークグループです。プロジェクトがログインアカウント内に作成されていない場合は、ログインアカウントをワークグループに紐づけ、プロジェクトの共有を有効にする必要があります。詳細については、ワークグループの追加と編集(Add and Edit Workgroups)およびMigrationWizにおけるプロジェクトの共有(Project Sharing in MigrationWiz)を参照してください。 - ライセンスを適用するプロジェクトをクリックします。
- UMBライセンスが、独自ドメインに基づくUPN/SMTPに適用されていることを確認します。続いて、「ドメインアドレスを変更(Change domain addresses) 」を使用して、ラインアイテムを .onmicrosoft.com ドメインのアドレスに変更します。
- UMB(ユーザー移行バンドル)ライセンスを適用するユーザーのメールアドレスの左にあるチェックボックスをオンにします。
- プロジェクトページの上部にある「詳細(More)」メニュー(3本ラインのアイコン)をクリックします。
- 「UMBライセンスの適用(Apply User Migration Bundle License)」をクリックします。
ライセンス(クーポンの利用やカテゴリの変更などを含む)の詳細については、MigrationWizのライセンスを参照してください。
前段階移行(Pre-Stage Migration)の実行
- ユーザーを選択します。
- 上部の「移行を開始」ボタンをクリックします。
- 「前段階移行(Pre-Stage Migration)」を選択します。
- 「移行のスケジューリング(Migration Scheduling)」セクションのドロップダウンリストから、「90日前(90 days ago)」を選択します。
- 「移行を開始」をクリックします。
推奨値は90日ですが、他のオプションを選択することもできます。前段階移行(Pre-Stage Migration)では、古いメールアイテムのみが移行されます。期間を指定する事で、データをより小さく分割し、移行を複数回に分けて実行することができます。
移行元からドメインを削除する
ドメインの削除は、「前段階移行(Pre-Stage Migration)」サイクルが完了した後に行います。通常、金曜日の夜遅い時間に行われます。ドメインを削除する手順については、Microsoftのドキュメントを参照してください。ドメインを削除する
移行元テナントに複数のドメインがある場合、新しいテナントに移行する前にそれらすべてのドメインを削除する必要があります。
管理者ポータルで、管理者アカウントのUPNを該当するonmicrosoft.comアドレスに変更します。
ドメインを削除すると、ユーザーはtenantname.onmicrosoft.comのメールアドレスを知っていて、当該アドレスにログインしない限り、メールにアクセスできなくなります。
削除後、ドメイン削除のレプリケーション処理が完了するまで30分待ちます。
ユーザーに通知する
エンドユーザーにメールを送信し、Outlookプロファイルの再構成に関する操作を依頼します。DeploymentProを使用している場合は、「DeploymentProガイド」を使用して、Outlookプロファイルを再構成する移行先ユーザーを設定できます。
移行先でドメインを検証する
これらの操作は、テナント2(移行先)の管理ポータルから行います。
- 移行先のMicrosoft 365アカウントのドメインを確認します。検証するには、Microsoft 365のウィザードを使用することをお勧めします。ドメインがTextレコードで検証されると、すべてのユーザーを新しいデフォルトドメインに変更することができます。ドメインは既にアカウントに追加されているので、「確認(Verify)」ボタンをクリックしてください。ドメインが検証できず、ドメインが別のアカウントに既に存在するというエラーが発生した場合は、Microsoftサポート(1-800-642-7676)に連絡し(米国のフリーダイヤル、他の番号も利用可能)、サポートにForefront(またはExchange Online Protection(EOP))から手動でドメインをデプロビジョニング(解除)する必要がある(The domain needs to be manually deprovisioned from Forefront)ことを伝えください。
- すべてのユーザーのメールボックスに「Destinationdomain.com」ドメイン名が追加されていることを確認します。
- 確認して、ドメインを追加するには、PowerShellスクリプト add_new_domain.ps1 をダウンロードしてください。ユーザーのアカウントに新しいデフォルトドメインが追加されていない場合にのみ、ドメインの追加が必要です。
MXレコードカットオーバー
DNSプロバイダーのポータルで、新しいMicrosoft 365組織のDNS設定を反映するように、プライマリMXレコードを変更します。DNSの設定では、Autodiscover、MX、およびSPFレコードを変更します。また、テナント1の古い設定を削除します。これらの設定は、Microsoft 365管理ポータルで次の手順に従って実行します。
- Microsoft 365で、ヘッダーの「管理(Admin)」をクリックします。
- 管理ページで、左ペインの「ドメイン(Domains)」をクリックします。
- セットアップするドメイン名をクリックし、「DNS設定(DNS Settings)」 をクリックします。Microsoft 365サービスを使用するために設定する必要があるDNSレコードが一覧表示されます。
「完全(差分)移行(Full (Delta) Migration)」サイクル
- ユーザーを選択します。
- 上部の「移行を開始」ボタンをクリックします。
- 「完全移行(Full Migration)」を選択します。
- 「移行を開始」をクリックします。ほとんどのデータは「前段階移行(Pre-Stage Migration)」で移行されているため、この移行サイクルはすぐに完了します。 Microsoft 365からMicrosoft 365への移行には高速帯域幅が利用できます。
- ユーザーリストを確認し、「移行に失敗しました(Failed)」という赤いエラー表示をクリックします。表示された情報に従って操作してください。
「エラーの再試行(Retry Errors)」を実行する
移行されなかったアイテムは、エラーとしてログに記録されています。MigrationWizには、移行に失敗したアイテムを再移行する「エラーの再試行(Retry Errors)」モードが実装されています。このモードは、無料で使用することができます。メールボックス移行で「エラーの再試行(Retry Errors)」モードを使用するには、次の条件をすべて満たす必要があります。
- 直前回の移行が正常に完了した。
- メールボックスに1つ以上のエラーが含まれている。
メールボックスが上記の条件を満たさない場合は、「エラーの再試行(Retry Errors)」モードで移行を実行しようとすると、警告が表示され、移行を実行することはできません。
1つまたは複数のメールボックスを「エラーの再試行(Retry Errors)」モードで移行するには、次の手順を実行します。
- 「マイ・プロジェクトへ」ボタンをクリックします。
- 再試行するメールボックスを含むプロジェクトを選択します。
- 移行エラーがあるメールボックスを選択します。
- 「移行を開始」ボタンをクリックします。
- メニューから、「エラーの再試行(Retry Errors)」を選択します。
- 「エラーの再試行(Retry Errors)」をクリックします。
修復されると、エラーはエラーログから消去されます。移行元アイテムが(フィルターなどにより)再処理されなかった場合や、削除または移動された場合、あるいはアイテムが再び移行に失敗した場合は、エラーが消去されない可能性があります。
問題が解決しない場合は、サポートにお問い合わせください。
移行後
DeploymentProを使用していない場合、ユーザーは新しいOutlookプロファイルを作成し、署名を再設定し、以前のプロファイルに添付されていたPSTファイルを再添付する必要があります。
MigrationWizダッシュボードの「棒グラフアイコン」をクリックすると、プロジェクトのすべての移行統計情報をメールで受信することができます。