はじめに
本記事では、ホスト型およびオンプレミスのExchangeサーバー(バージョン2007以降)からMicrosoft 365に、メールボックスを移行する手順について説明します。
移行を開始する前に、本ガイドを最後まで読んで、移行のプロセス、タイムライン、および前提条件を理解しておくことをお勧めします。本ガイドには、移行の失敗を防ぐための注意事項が記載されているので、注意してお読みください。
本ガイドでは、移行の実行に必要な手順について説明しています。移行の準備には、多くの手順を実行する必要があります。初めて移行を実行する際は、移行計画と戦略を参照してください。移行の計画と設定、および一般的な移行のベストプラクティスについて説明しています。
移行元および移行先で使用する管理者アカウントでは、アプリのパスワードおよび多要素認証(MFA)/二要素認証(2FA)ポリシーは、サポートされていません。
移行元および移行先では、Exchange Webサービス(EWS)を有効にし、アクセス可能にしておく必要があります。
MigrationWiz
MigrationWizは移行ツールであり、同期ツールではありません。移行完了後に移行元のアイテムに変更が加えられた場合、その変更は移行先には反映されません。同様に、移行先で加えられた変更も、移行元には反映されません。MigrationWizには、(同期エージェントのような)「ライブ」での変更のモニタリング機能はなく、ユーザーの操作なしに競合解決などを処理することはできません。
二要素認証あるいは多要素認証を使用した移行は、サポートしていません。
MigrationWizでは、移行可能な1ファイルの最大サイズは、移行タイプと環境によって異なります。ただし、60GBを超えるファイルを移行することはできません。
移行できるアイテム
- 受信トレイ
- フォルダー
- メール
- 連絡先
- 予定表
- タスク
- ジャーナル
- メモ
- BCC受信者
- 投稿(移行先がExchangeまたはMicrosoft 365の場合)
移行されないアイテム
- メールテンプレート
- メールフラグ(移行先がGoogle Workspaceの場合)
- 安全な送信者リスト/ブロックされた送信者リスト
- メール設定
- メールボックスフォルダーまたはパブリックフォルダーに保存されているスタンドアロンドキュメント(例:IPM.Documentアイテムタイプ)
- システムパブリックフォルダー
- 付箋フォルダー
- パブリックフォルダーの権限
Exchangeに関する質問とトラブルシューティング
Exchangeメールボックスの移行に関するよくある質問、Exchange移行の設定と計画に関するよくある質問(Exchange Migration Setup & Planning FAQ)、およびExchangeメールボックス移行のトラブルシューティング(Exchange Mailbox Migration Troubleshooting)の各ガイドには、多くの一般的な質問や懸念事項の他、スロットリングなどの問題を解決するための詳細情報、ガイダンス、手順が記載されています。
DeploymentProとデバイス管理エージェント(DMA)
BitTitan DeploymentProは、デバイス管理およびデバイス管理エージェント(DMA)のモジュールで、Microsoft 365へのメールボックス移行の実行後に、Outlookメールプロファイルをリモートで構成します。Exchange環境では、UPNとSMTPアドレスが一致しない場合に、複雑な自動検出を設定できます。そのような環境に対してDeploymentProを動作させる時は、事前にトラブルシューティングと再構成が必要になる場合があります。本シナリオでは、DeploymentProを使用することをお勧めします。
DeploymentProライセンスは、「ユーザー移行バンドル(User Migration Bundle)」ライセンスに含まれています。DeploymentProライセンスは、スタンドアロンサービスライセンスとして購入することはできず、一回のみ使用可能なメールボックス移行ライセンスに追加することもできません。移行後にDeploymentProを使用してOutlookメールプロファイルをリモートで構成する場合は、「ユーザー移行バンドル(User Migration Bundle)」ライセンスを購入してください。
DeploymentProは現在、Microsoft 365を移行先とする移行プロジェクトのみをサポートしています。移行先がExchange(オンプレミスまたはホスト型)の場合は、DeploymentProを使用する前に、概念実証を行う必要があります。 概念実証やその他のDeploymentProに関する質問については、DeploymentProガイド(DeploymentPro Guide)およびDeploymentProに関するよくある質問(DeploymentPro FAQ)の記事を参照してください。DMAリソースやその他のDMAの詳細については、デバイス管理エージェントのインストール(Device Management Agent Installation)およびデバイス管理エージェントについて(Introduction to Device Management Agent)をご覧ください。
移行元環境を準備する
移行元環境を準備するには、次の手順を完了する必要があります。
- 権限を作成して構成します。
- アクセスを確認します。
- メールボックスへのアクセスをテストします。
- スロットリング制限を無効にします。
詳細な手順については、以下のアコーディオンを参照してください。
移行元がホスト型Exchangeの場合、移行用のアカウント(たとえば、アカウント名「MigrationWiz」など)の作成をプロバイダーに依頼し、さらに、そのアカウントに対して下記のPowerShellスクリプトを実行して、各メールボックスへのフルアクセス権を付与するよう依頼します。
Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz
- 一部のExchangeホストプロバイダーは、Webポータルを介したアクセス権の付与を許可しています。その場合は、ポータル経由で各メールボックスにログインし、移行用のアカウント(アカウント名「MigrationWiz」など)に、各メールボックスへの読み取り/書き込みアクセス権を付与します。この作業には多くの時間と労力が必要なため、特にユーザーが多数いる場合は、上記のPowerShellスクリプトの実行をExchangeホストプロバイダーに依頼することをお勧めします。
- Exchangeホストプロバイダーによっては、ポータル経由でのアクセス権の付与を許可していない場合があります。その場合は、移行中にエンドユーザーに資格情報の提供をリクエストすることができます。具体的な手順については、ナレッジベースの記事、MigrationWiz - 資格情報と認証(MigrationWiz - Credentials & Authentication)内の「管理者アクセスなしで移行を実行する(Running a Migration without Administrative Access)」セクションを参照してください。
非常に大規模なプロジェクトの場合、移行元で偽装を使用するようにプロジェクトを設定すると、効率を最大化することができます。
移行元がホスト型ExchangeおよびオンプレミスExchange 2007以降の場合、MigrationWizでは委任がデフォルト設定されており、コネクタで指定された管理者資格情報を使用して、個々のユーザーメールボックスにログインします。MigrationWizでは、偽装と呼ばれる別の昇格アクセスモードもサポートしています。
利点
偽装を使用すると、単一の管理者アカウントに関連付けられたスロットリングクォータと接続制限の共有を停止することができます。各ユーザーメールボックスへのログインには、代わりに各ユーザーのスロットリングクォータが適用されます。
偽装使用の効果
- 「接続に失敗しました(Connection did not succeed)」というエラーが大幅に削減されます。
- 同時に移行できるメールボックス数が増えます。
- スロットリングと接続制限の影響が軽減されます。
管理者アカウントがユーザーを偽装できるようにするには、次のPowerShellコマンドを実行します。
New-ManagementRoleAssignment -Role ApplicationImpersonation -User <管理者ユーザー名
PowerShellコマンドの詳細については、こちらを参照してください。
次のセクションでは、OWA URLを特定して、お客様の環境のEWSアクセスをテストする方法について説明します。この情報は、移行プロジェクトが適切に構成されていることを確認し、移行実行時の失敗を防ぐのに役立ちます。
OWA URLを特定する
- エンドポイントにExchangeを設定する場合は、OWA URLまたはEWS URLのいずれかを入力します。
- ログイン後に別のサーバーにリダイレクトされることがあるため、OWAのログインページは、メールボックスの実際のOWA URLと異なる場合があります。正しいOWA URLを確認するには、次の手順を実行します。
- すべてのブラウザーインスタンスを閉じます。これにより、セッション状態のすべてのブラウザーのキャッシュがフラッシュされます。
- 新しいブラウザーインスタンスを開きます。
- OWAログインページに移動します。
- OWAにログインします。
- 受信トレイが表示されたら、ブラウザーのナビゲーションバーからURLをコピーします。これが、MigrationWizに入力する正確なOWA URLになります。
- OWA URLの例
- https://www.mining88.com
- https://www.mining88.com/owa
- https://www.mining88.com:443
- https://50.249.230.12/owa
OWA URLを特定するもう1つの方法は、「whatismyipaddress」Webサイトを使用して、会社のパブリックIPアドレスを特定し、その末尾に「/owa」を追加する方法です。
OWA URLが特定できたら、ユーザー名とパスワードの組み合わせが機能することを確認する必要があります。OWAへのログインに使用するユーザー名およびパスワードは、MigrationWizに入力するユーザー名およびパスワードと完全に同じものになります。ユーザー名とパスワードが機能していることを確認するには、次の手順を実行します。
- すべてのブラウザーインスタンスを閉じます。これにより、セッション状態のすべてのブラウザーのキャッシュがフラッシュされます。
- 新しいブラウザーインスタンスを開きます。
- 上の手順5と同じOWAログインページに移動します。
- OWAにログインします。ログイン名には特に注意を払い、「,」や「:」」が含まれないようにしてください。
- 「メールアドレス(Email address)」は、「user@example.com」形式で入力します。
- 「ドメイン\ユーザー名(Domain\user name)」は、「example\user」形式で入力します。
- 「ユーザー名(User name)」は、「user」形式で入力します。
- 受信トレイが表示されたら、OWAへのログインが成功したことになります。 MigrationWizで使用するユーザー名およびパスワードと完全に同じものを入力します。
最初に権限の付与が必要になる場合があります。
- https://testconnectivity.microsoft.comにアクセスします。これは、Microsoftのツールです。
- Microsoft 365を使用している場合は、「Office 365」タブをクリックします。
- 「サービスアカウントアクセス(開発者)(Service Account Access (Developers))」を選択し、「次へ(Next)」をクリックします。
- 対象のメールボックスのメールアドレスを指定します。
- サービスアカウントのユーザー名を指定します(コネクタで管理者資格情報を使用している場合は、同じユーザー名を入力します)。
- サービスアカウントのパスワードを指定します(コネクタで管理者資格情報を使用している場合は、同じパスワードを入力します)。
- 「Exchange WebサービスのURLを指定する(Specify Exchange Web Services URL)」にチェックを入れて、URLを指定します(例:https://server/EWS/Exchange.asmx)。
- Exchange Serverを使用している場合は、「Exchangeで偽装を使用する(Use Exchange Impersonation)」にチェックを入れないでください。Microsoft 365で偽装を使用している場合は、チェックを入れてください。
- 「SSLの信頼を無視する(Ignore Trust for SSL)」にチェックを入れます。
- 「テストの実行(Perform Test)」クリックします。
- 結果が表示されたら、全体の結果を確認し、「すべてを展開する(Expand All)」をクリックします。
スロットリング
次のセクションでは、Exchange環境内でスロットリングポリシーを削除する方法について説明します。スロットリングポリシーを削除すると、移行のパフォーマンスが向上します。
- Exchangeホストプロバイダーによっては、お客様によるスロットリングポリシーの変更ができない場合があります。
- スロットリングポリシーを削除すると、データ移行のスループットは向上しますが、サーバーリソースに影響を与える可能性があります。移行を実行する際は、サーバーリソースに細心の注意を払い、健全なサーバーリソースレベルを維持するために、スロットリングポリシーを変更する必要があるかどうかを判断してください。
スロットリングパラメータを無効にする
- Exchange管理シェルを開きます。
- 次のコマンドを入力して、「Enter」キーを押します。
New-ThrottlingPolicy MigrationWizPolicy
- 次のコマンドを入力して、「Enter」キーを押します。
Set-ThrottlingPolicy MigrationWizPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null -CPAMaxConcurrency $null -CPAPercentTimeInCAS $null -CPAPercentTimeInMailboxRPC $null -CPUStartPercent $null
- 次のコマンドを入力して、「Enter」キーを押します。
Set-Mailbox "MigrationWiz" -ThrottlingPolicy MigrationWizPolicy
- 上記の手順により、移行元のすべてのユーザーアカウントに対するスロットリングポリシーが削除されます。MigrationWizプロジェクト内で、偽装を有効にする必要があります。これにより、移行中に管理者アカウントがユーザーアカウントを偽装でき、移行に管理者アカウント用の帯域幅だけでなく、個々のユーザーアカウント用の帯域幅を使用することが可能になります。偽装を有効にするには、ヘルプセンターの記事、Microsoft 365およびExchangeでの移行におけるMigrationWizの偽装と委任の手順に従ってください。
移行先環境を準備する
移行先の環境を準備するには、次の手順を完了する必要があります。
- EWSの認証要件を構成します。
- 管理者アカウントを作成します。
- 偽装を設定します。
- フルアクセス権を設定します。
詳細な手順については、以下のアコーディオンを参照してください。
次の手順は、移行元と移行先のいずれか、または両方がExchange Onlineの場合のメールボックス、アーカイブメールボックス、およびパブリックフォルダープロジェクトで、Exchange Webサービス(EWS)を使用する場合に、移行元および移行先の両テナントに適用されます。グローバル管理者アカウントを使用して、以下の設定手順を実行します。
画像付きの設定手順については、次のナレッジベース記事の「先進認証を有効にする」セクションを参照してください。Microsoft 365(全製品)の移行における認証方法
重要:Microsoft 365エンドポイントで必要な手順を実行しないと、プロジェクトで次の401エラーが表示され、ジョブが失敗する可能性があります。Http POST request to 'autodiscover-s.outlook.com' failed (「autodiscover-s.outlook.com」へのHttp POSTリクエストが失敗しました) - 401 Unauthorized
プロジェクトで使用している管理者アカウントは、管理者アカウントのアクセスがブロックされる可能性がある多要素認証(MFA)/二要素認証(2FA)ポリシーまたは条件付きアクセスポリシーから除外する必要があります。プロジェクトで移行されるアイテムまたはユーザーについては、除外の必要はありません。
MicrosoftがExchange Onlineでの基本認証のサポートを終了した2022年12月以降、 Exchange Onlineのメールボックス、アーカイブメールボックス、およびパブリックフォルダープロジェクトでは、MigrationWizとの連携のために先進認証を設定することがデフォルトの方法になりました。認証方法の変更の詳細については、次のMicrosoftのドキュメントを参照してください。この変更がテナントに与える影響についての追加の情報は、Microsoftにお問い合わせください。Exchange Onlineでの基本認証の廃止
テナントでAzureセキュリティの既定値群を無効にする必要があります。(すべての新しいExchange Onlineテナントでは、この既定値群はデフォルトで有効になっており、 この要件を回避する方法はありません。) Azureセキュリティの既定値群を有効/無効にする手順については、次のMicrosoftのドキュメント内の「セキュリティの既定値群の有効化」セクションを参照してください 。無効にするには、「セキュリティの既定値群の有効化(Enable Security defaults)」を「いいえ(No)」に設定します。Azure ADのセキュリティの既定値群
先進認証の手順- Azure Active Directory管理センターに、グローバル管理者としてログインします。
- 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)」を選択します。
- Microsoft Graphに「User.Read」という名前の既存のAPIアクセス許可がある場合は、削除します。Microsoft Graph APIは、本プロジェクトタイプには適用できないため、使用しません。
- 「アクセス許可の追加(Add a permission)」 を選択します。
-
「所属する組織で使用しているAPI(APIs my organization uses)」を選択します。
-
下にスクロールして、「Officec 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 365コントロールパネルに管理者としてアクセスして、ユーザー管理を行うことができるアカウントであっても、移行するすべてのメールボックスへのアクセス権があるとは限りません。
- アカウントに管理者アクセス権を委任することは、十分なアクセス権を付与することとは異なります。
管理者アカウントがMicrosoft 365のユーザーメールボックスにアクセスできるようにするには、偽装の役割またはフルアクセスのメールボックス権限を追加します。 偽装とフルアクセスの権限を設定する手順について、以下に説明します。
管理者アカウントがユーザーを偽装できるようにするには、次のPowerShellコマンドを実行します。
$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $session
Enable-OrganizationCustomization
New-ManagementRoleAssignment -Role ApplicationImpersonation -User <管理者ユーザー名
Remove-PSSession $session
PowerShellコマンドの詳細については、こちらを参照してください。
- Microsoft 365は、スモールビジネスプランでの偽装を許可していません。
- MigrationWizでは、委任がデフォルト設定されており、コネクタで指定された管理者資格情報を使用して、個々のユーザーメールボックスにログインします。
Microsoft 365を移行元または移行先とする移行では、偽装を使用することを強くお勧めします。
利点
偽装を使用すると、単一の管理者アカウントに紐づけられたスロットリングクォータと接続制限の共有を停止することができます。各ユーザーメールボックスへのログインには、代わりに各ユーザーのスロットリングクォータが適用されます。
偽装使用の効果
- 「接続に失敗しました(Connection did not succeed)」というエラーが大幅に削減されます。
- 同時に移行できるメールボックス数が増えます。
- スロットリングと接続制限の影響が軽減されます。
- ライセンスが割り当てられていない管理者アカウントを使用することができます。
移行のための管理者アクセス権を手動で付与するには、以下のリモートPowerShellコマンドを実行します。
$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $session
Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWiz
Remove-PSSession $session
- 権限は、メールボックスごとに直接設定します。新しいメールボックスを作成するたびに、上記のコマンドを実行する必要があります。権限の設定が完了すると、管理者アカウントにアクセス権が付与されます。
- 本ナレッジベース記事の指示に従って、上記スクリプトのユーザー名「MigrationWiz」を、設定した管理者アカウントの名前に置き換えます。
- このユーザー名は、MigrationWizプロジェクトの「移行元の設定」または「移行先の設定(DESTINATION SETTINGS)」で、「資格情報を提供する(Provide Credentials)」を選択した時に指定した管理者ユーザー名です。
ユーザーアカウントを作成してライセンスを割り当てる
Microsoft 365でアカウントを設定し、ライセンスを割り当てます。これにはいくつかの方法があります。
- 手動で1つずつ追加する。詳細については、Microsoftの記事、ユーザーを追加して同時にライセンスを割り当てるを参照してください。
- CSVファイルを使用して、一括でインポートする。詳細については、Microsoftの記事、Microsoft 365に複数のユーザーを同時に追加するを参照してください。
- PowerShellスクリプトを使用する。詳細については、Microsoftの記事、PowerShellを使用してMicrosoft 365ユーザーアカウントを作成するを参照してください。
ライセンス
本移行シナリオでは、「ユーザー移行バンドル(User Migration Bundle)」ライセンスを購入することをお勧めします。「ユーザー移行バンドル(User Migration Bundle)」ライセンスを使用すると、1つのライセンスで複数の種類の移行を実行することができます。また、DeploymentProを使用して、Outlookのメールプロファイルを構成することもできます。
-
- BitTitanアカウントにサインインします。
- 上部のナビゲーションバーで、「購入(Purchase)」をクリックします。
- 必要なライセンスタイプの「選択(Select)」ボタンをクリックします。
- 購入するライセンスの数を入力します。「今すぐ購入(Buy Now)」をクリックします。
- 必要に応じて、「請求先住所(Billing Address)」を入力します。
- 「次へ(Next)」をクリックします。
- 「注文内容(Order Summary)」を確認し、「支払い方法(Payment Method)」を入力します。
- 「購入する(Place Your Order)」をクリックします。
ライセンスを適用する
-
- 左のナビゲーションウィンドウの上部で、ワークグループを選択します。顧客と移行プロジェクトを作成したワークグループを選択してください。プロジェクトがログインアカウントで作成したものではない場合は、ログインアカウントをワークグループに紐づける必要があります。
- 左のナビゲーションウィンドウで、「顧客(Customers)」をクリックします。
- 「ユーザー移行バンドル(User Migration Bundle)」ライセンスを適用するユーザーを含む顧客をクリックします。
- ページ上部の「ユーザー(Users)」タブをクリックします。
- ライセンスを適用するユーザーのメールアドレスの左にあるチェックボックスをオンにします。
- ページ上部の「ユーザー移行バンドルライセンスを適用する(Apply User Migration Bundle License)」ボタンをクリックします。独自ドメインでユーザーを顧客ページに追加することをお勧めします。「.onmicrosoft」ドメインを移行に使用する場合は、ユーザー名の表示を「.onmicrosoft」ドメインに変更する前に、「ユーザー移行バンドル(User Migration Bundle)」ライセンスを適用します。
- 選択したユーザーの中に、「ユーザー移行バンドル(User Migration Bundle)」ライセンスを割り当てられていないユーザーが1人でもいる場合は、「確認(Confirm)」をクリックします。重要: 割り当て可能な「ユーザー移行バンドル(User Migration Bundle)」ライセンスが不足している場合、ワークグループのマネージャー(Manager)以上の役割のアカウントに対し、必要な情報がすべて記載されたフォームが表示され、手順に従って「ユーザー移行バンドル(User Migration Bundle)」ライセンスを購入することができるようになっています。
MigrationWizでの手順
メールボックス移行プロジェクトを作成する
- 「マイ・プロジェクトへ」をクリックします。
- 「プロジェクトを作成(Create Project)」をクリックします。
- 「メールボックスプロジェクトを作成(Create a Mailbox Project)」を選択します。 メールボックスプロジェクトでは、プライマリユーザーのメールボックスのコンテンツを古い環境から新しい環境に移行します。ほとんどのメールボックス移行で、メール、予定表、および連絡先を移行することができます。
- 「次のステップ」をクリックします。
- 「プロジェクト名(Project Name)」を入力し、「顧客(Customer)」を選択します。
- 「次のステップ」をクリックします。
- 「エンドポイント(Endpoint)」ドロップダウンメニューから、移行元エンドポイントを選択します。「エンドポイント(Endpoint)」が作成されていない場合は、「新規」をクリックし、「新しいエンドポイント(New Endpoint)」ポップアップウィンドウに必要な情報を入力します。
- 「エンドポイント(Endpoint)」ドロップダウンメニューから、移行先エンドポイントを選択します。「エンドポイント(Endpoint)」が作成されていない場合は、「新規」をクリックし、「新しいエンドポイント(New Endpoint)」ポップアップウィンドウに必要な情報を入力します。
- 「保存して概要へ移動」をクリックします。
アカウント(アイテム)を追加する
次のいずれかのオプションを使用して、移行するアカウント(アイテム)をプロジェクトに追加します。
- クイック追加(Quick Add): このオプションを使用すると、ユーザーを1人ずつ追加することができます。プロジェクトの設定時に管理者資格情報を入力しなかった場合は、各ユーザーの「メールアドレス(Email Address)」、「ユーザー名(Username)」、および「パスワード(Password)」を入力する必要があります。プロジェクトの設定時に管理者資格情報を入力した場合は、「メールアドレス(Email Address)」のみを入力します。
- アイテム自動検出(Autodiscover Items): 「アイテム自動検出(Autodiscover Items)」オプションを使用すると、移行元のメールボックスを直接検出することができます。詳細については、「移行のためのアイテムの追加と管理」を参照してください。
- メールボックス移行プロジェクトでは、移行元がExchange 2007以降の場合にのみ、この機能がサポートされています。
- 移行元がExchange 2007以降であっても、インプレースアーカイブ移行プロジェクトでは、この機能はサポートされていません。
- 一括追加: このオプションを使用すると、スプレッドシートからコピーして貼り付けたり、CSVファイルをインポートすることにより、複数のアイテムを一度に追加することができます。移行元と移行先のドメイン名が一致しない場合があります。プロジェクトには正しい情報の入力が必要です。ドメイン名が異なる場合は、CSVファイルで修正後、「一括追加」オプションを使用して、ユーザーをダッシュボードにインポートすることをお勧めします。
- 「一括追加」を実行するプロジェクトを選択します。
- 「新しいアイテムを追加(Add New Items)」をクリックします。
- 「一括追加」をクリックします。
- ページの指示に従って、操作を続けてください。
詳細オプションとサポートオプションを設定する
「詳細オプション(Advanced Options)」では、通知、フィルタリング、メンテナンス、ライセンス、パフォーマンス、構成に関する様々なオプションを選択することができます。
サポートオプションを使用すると、Powershellやコードブロックを使用して、移行プロジェクトに追加のオプションやリソースを提供することができ、より高度な構成が可能となります。
次のオプションは、本移行シナリオで最も有用なオプションです。
推奨オプション
次のオプションは、ExchangeからMicrosoft 365への移行シナリオで最も有用なオプションです。
- 移行元で偽装を使用するように設定します。「移行元 / 移行先(Source/Destination)」タブの「移行元(SOURCE)」セクションで、「認証に偽装を使用する(Use Impersonation to Authenticate)」のチェックボックスにチェックを入れます。
- 移行先で偽装を使用するように設定します。「移行先(DESTINATION)」セクションで、「認証に偽装を使用する(Use Impersonation to Authenticate)」のチェックボックスにチェックを入れます。
- 「最大同時移行数(Maximum number of concurrent migrations)」を設定します。 確実性を重視し、最初は「5」に設定することをお勧めします。すべてのメールボックスを選択して移行を開始すると、まずリストの最初の5つのメールボックスのみが(並列処理で)移行され、これら5つのメールボックスの移行が完了すると、リストの次のメールボックスの移行が始まります。このようにしてリストの最後まで進み、すべてのメールボックスの移行が完了します。移行元のサーバーに十分なリソースがある場合は、「1Mbpsあたり3つのメールボックス」という帯域幅のガイドラインに従って、このパラメータを設定します。たとえば、回線容量が10Mbpsの場合、最大同時移行数を「30」に設定することをお勧めします。
移行を実行する
次のセクションでは、移行の設定および開始方法について説明します。各見出しは1つの手順を示しており、その下に具体的な手順を記しています。以下の手順を順番に実行してください。依存関係やベストプラクティスに関する重要な情報については、「注」を参照してください。
「資格情報の検証(Verify Credentials)」を実行する
- 検証するアイテムを含むプロジェクトを開きます。
- 検証するアイテムを選択します。
- ダッシュボードの「移行を開始」ボタンをクリックします。
- ドロップダウンリストから、「資格情報の検証(Verify Credentials)」を選択します。
- 検証が完了すると、検証結果が「ステータス(Status)」セクションに表示されます。
ユーザーに通知する
移行の開始を知らせる最終通知メールを送信します。通知メールには、移行の開始時期、移行にかかる時間(期間)、移行中の取り扱い方法、移行後に必要な手順やその他の通知事項を記載します。
DeploymentProを使用している場合は、DeploymentProガイド(DeploymentPro Guide)の「サンプルメール(Sample Email)」セクションを参照してください。通知メール用のサンプルテキストとスクリーンショットが記載されています。
前段階移行(Pre-Stage Migration)サイクル
- ユーザーを選択します。
- 上部の「移行を開始」ボタンをクリックし、「前段階移行(Pre-Stage Migration)」を選択します。
- 「移行のスケジューリング」セクションのドロップダウンリストから、「90日前(90 Days Ago)」を選択します。
- 「移行を開始」をクリックします。
MXレコードカットオーバー
DNSプロバイダーのポータルで、MXレコードを切り替えます。その際に、「AutoDiscover (CName)」の設定も行います。プロジェクトの規模によって、この設定にはいくつかのオプションがあります。
小規模から中規模のプロジェクト
移行中、管理ポータルからユーザーごとに手動で転送を設定します。転送は、ユーザーをバッチで移行している時に、一部のユーザーを他のユーザーよりも先に新しい移行先に切り替えたい場合に便利です。転送では、メールの併用は可能ですが、予定表の空き時間情報の併用はできません。
コピーをローカルに保存すると、移行先にメールボックスを移行した時に重複が生じてしまうため、保存しないことをお勧めします。
注:転送/併用の設定は、手動の設定オプションであり、MigrationWizを使用した移行での要件ではありません。このオプションを使用する場合は、移行を開始する前に、まずお客様の環境でテストを行ってください。
大規模プロジェクト
バッチ移行の実行中に併用が必要な場合は、最後のバッチの移行が終了するまでMXレコードをカットオーバーせず、次の2つの追加手順を実行する必要があります。
注:転送/併用の設定は、手動の設定オプションであり、MigrationWizを使用した移行での要件ではありません。このオプションを使用する場合は、移行を開始する前に、まずお客様の環境でテストを行ってください。
併用のための転送
MXレコードの変更によるドメイン/組織全体のカットオーバーを一度に行わない場合は、移行を段階的に実行し、移行するメールボックスに転送を設定して、併用を可能にします。
次のいずれかの方法で設定します。
注:Exchangeのメール連絡先と内部DNSリレーを設定することはお勧めしません。これらを設定すると、メールボックスが存在しなくなるため、後続の差分移行サイクルを実行できなくなります。
PowerShell経由
PowerShellを介して転送を設定する方法は、次のとおりです。
メールを内部受信者に転送し、ローカルにコピーを保存しないでください。
PowerShellのコマンド構文
Set-Mailbox -Identity <ID -ForwardingAddress <Microsoft 365ユーザーのメールアドレス -DeliverToMailboxAndForward $False
- 例:Set-Mailbox -Identity John -ForwardingAddress Suzan@o365info.com -DeliverToMailboxAndForward $False
- 「DeliverToMailboxAndForward」が「偽(false)」に設定されているため、メールのコピーはオンプレミスのメールボックスに保存されません。転送を設定する時は、ローカルにコピーを保存しない設定になっていることを、転送前に確認するようにしてください。ローカルにコピーを保存すると、MigrationWizで差分サイクルを実行した時に、以前に移行されなかったアイテム(および、ウォーターマークが付いていないアイテム)が移行されます。これにより、移行先で重複が発生します。
- 「ForwardingAddress」パラメータで指定されたメールアドレスは、メール連絡先として存在する必要があります。
Exchange管理コンソール経由
最初の手順として、ローカルActive Directoryに転送オブジェクトを作成します。これらの転送オブジェクトはアドレス帳には表示されず、移行するメールボックスのメールを転送するためにのみ使用されます。作成したオブジェクトは、転送を設定するまで使用されません。
次に、移行前にメールボックスの転送を設定します。メールボックスの移行を開始する前に、次の手順を実行して、転送を設定します。
- 「スタート(Start)」メニューから、Exchange管理コンソールを起動します。
- ナビゲーションツリーから、「受信者の構成(Recipient Configuration)」を展開します。
- ナビゲーションツリーから、「メールボックス(Mailbox)」をクリックします。
- 転送を設定するメールボックスを右クリックし、「プロパティ(Properties)」をクリックします。
- 「メールボックスフロ���の設定」タブをクリックします。
- 「配信オプション(Delivery Options)」を選択し、「プロパティ(Properties)」をクリックします。「メッセージを転送先アドレスとメールボックスの両方に配信する(Deliver message to both forwarding address and mailbox)」オプションを選択しないでください。これは、差分サイクルで重複が発生しないようにするために重要です。ローカルにコピーを保存すると、MigrationWizで差分サイクルを実行した時に、以前に移行されなかったアイテム(および、ウォーターマークが付いていないアイテム)が移行されます。これにより、移行先で重複が発生します。
- 「転送先(Forward to)」のチェックボックスにチェックを入れ、「参照(Browse)」をクリックします。
- 表示名にプレフィックス(外部転送)を含むユーザー名を選択します。これは、以前に作成した転送オブジェクトです。
- 「OK」をクリックします。
- 「OK」をクリックします。
Microsoft 365でメールルーティングを設定する
設定には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メールボックスでメールを受信するようになります。
- 移行された各ユーザーについては、メールが有効になっている連絡先が、オンプレミスに存在している必要があります。
- エンドユーザーにメールを送信し、Outlookプロファイルの再構成で必要となる、ユーザー側の操作について案内します。DeploymentProを使用している場合は、DeploymentProガイド(DeploymentPro Guide)の「サンプルメール(Sample Email)」セクションを参照してください。通知メール用のサンプルテキストとスクリーンショットが記載されているので、Outlookプロファイルの再構成前に、ユーザーにメールを送信してください。
「完全移行(Full Migration)」サイクルを実行する
- ユーザーを選択します - ユーザーを個別に選択するか、上部の「移行元メールアドレス」の左にあるチェックボックスをクリックして、プロジェクト内のすべてのユーザーを選択します。
- 上部の「移行を開始」ボタンをクリックします。
- 「完全移行(Full Migration)」を選択します。移行を後日開始するように設定する場合は、「移行のスケジューリング」セクションで、「移行の自動開始スケジュール(Automatically start the migration at)」のチェックボックスをオンにして、移行を開始する日時を入力します。移行をすぐに開始する場合は、スケジュールを設定する必要はありません。
- 「移行を開始」をクリックします。
「エラーの再試行(Retry Errors)」を実行する
移行されなかったアイテムは、エラーとしてログに記録されています。MigrationWizには、移行に失敗したアイテムを再移行する「エラーの再試行(Retry Errors)」モードが実装されています。このモードは、無料で使用することができます。メールボックス移行で「エラーの再試行(Retry Errors)」モードを使用するには、次の条件をすべて満たす必要があります。
- 直前の移行が正常に完了した。
- メールボックスに1つ以上のエラーが含まれている。
メールボックスが上記の条件を満たさない場合は、「エラーの再試行(Retry Errors)」モードで移行を実行しようとすると、警告が表示され、移行を実行することはできません。
1つまたは複数のメールボックスを「エラーの再試行(Retry Errors)」モードで移行するには、次の手順を実行します。
- 「マイ・プロジェクトへ」ボタンをクリックします。
- 再試行するメールボックスを含むプロジェクトを選択します。
- 移行エラーがあるメールボックスを選択します。
- 「移行を開始」ボタンをクリックします。
- メニューから、「エラーの再試行(Retry Errors)」を選択します。
- 「エラーを再試行する」ボタンをクリックします。
エラーは、修復されるとエラーログから消去されます。移行元アイテムが(フィルターなどにより)再処理されなかった場合や、削除または移動された場合、あるいは再び移行に失敗した場合は、エラーが消去されないことがあります。
最終ステップ
DeploymentProを使用していない場合、ユーザーは新しいOutlookプロファイルを作成し、署名を再設定して、以前のプロファイルに添付されていたPSTファイルを再添付する必要があります。
MigrationWizダッシュボードの 「棒グラフアイコン」 「円グラフアイコン」 をクリックすると、プロジェクトのすべての移行統計情報をメールで受信することができます。