-
はじめに
本記事は、Office 365からオンプレミスのExchangeサーバー(2007, 2010, 2013, 2016)へメールボックスを移行する導入手順書です。
表記の順序に従い、各ステップを完了してください。
MigrationWizは同期ソリューションではなく、移行ソリューションであるため、以前に実行された移行サイクルで移行されたアイテムの更新、削除、または移動を追跡しません。これは、MigrationWizには(同期エージェントのように)「ライブ」での変更のモニタリング機能はなく、ユーザーの操作なしに競合解決などを処理することができないためです。
MigrationWizは、ワークグループをまたがって、移行プロジェクトを共有する機能をサポートしています。プロジェクト共有機能をオンにすると、非アクティブなエージェント以外のすべてのエージェントに、全ての移行プロジェクトが表示されます。詳細については、MigrationWizの「プロジェクト共有 (Project Sharing)」をご覧ください。
移行元環境を準備する
- 移行に使用する管理者アカウントをOffice 365で作成するか、テナントのグローバル管理者アカウントを使用します。
- ユーザーリストをCSVファイルにエクスポートします。このファイルはMigrationWizプロジェクトにユーザーを一括追加するときに使用できます。ユーザーリストをコピーして、MigrationWizプロジェクトダッシュボード内の 「追加(Add)」 > 「一括追加 (Bulk Add)」 の [移行元メール (Source Email) ] の列に貼り付けます。手順:Office 365管理ポータルから > ユーザー (Users) > アクティブユーザー (Active Users) > エクスポート (Export) > 続行します (Continue) 。
移行先環境を準備する
- ユーザーアカウントを設定します。
- すべてのメールボックスへのフルアクセス許可を持つ移行用の管理者アカウントを作成します。
- 上記のPowerShellスクリプトで、移行用にセットアップされた管理者アカウント名と一致するように「-User」のアカウント名を合わせて変更します。
- ドメイン管理者、スキーマ管理者、またはエンタープライズ管理者のグループに属しているユーザーアカウントには、許可されているアクセス数に関わらず、メールボックスに対する管理者権限はありません。Exchange Serverのセキュリティ標準設定では、これらのグループメンバーであるユーザーは明示的に拒否されます。そのため、移行専用の新しいユーザーアカウントを作成することをお勧めします。
- Exchange 2010以降のバージョンでリモートPowerShellセッションをセットアップします。
- 移行のための管理アクセスを手動で許可するには、Exchange PowerShellコンソールで以下のPowerShellコマンドを実行します。
Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWiz注:
- 管理者アカウントに対するスロットリング(throttling) を無効にします。
注: これは、移行先サーバーがExchange 2010以降のバージョンの場合にのみ必要となります。 - EWSを使用してメールボックスのアクセシビリティを確認します。
- 添付ファイルが10 MBを超えるメッセージを移行できるようにするには、以下の制限設定を変更する必要があります。
- メッセージのサイズ制限を増やします。
- 受け入れられるコンテンツの最大長を増やします。
- 最大受信メッセージサイズを増やします。
- 受け入れられるリクエストの最大長を増やします。これは、移行先サーバーがExchange 2007の場合にのみ有効です。
MigrationWizの手順
- メールボックス移行プロジェクトを作成します(Create a Mailbox Project)。
- プロジェクトに移行するアカウント(「アイテム」とも呼称します)を追加します。
- プロジェクトの詳細オプション(Advanced Options)を設定します。
- 移行元で偽装(impersonation)を使用するように設定します。「移行元で偽装を使用する(Use Impersonation at Source)」チェックボックスにチェックを入れます。
- 大規模な移行プロジェクトの場合、「パフォーマンス(Performance)」の枠内にある「最大同時移行数」(Maximum concurrent migrations)を1000などの非常に高い値に設定できます。
注: 移行元で偽装(Impersonation)を使用するように設定されている場合、かつ、移行先のExchangeサーバーに使用可能なリソースが十分にある場合、この値は高い値に設定できます。 - この移行シナリオでは、次のオプションが最も有用です。
- 資格情報の検証(Verify Credentials)を実行します。
- 移行が行われることをユーザーに通知します。すべてのユーザーにメールを送信し、移行の日時を知らせます。
- 前段階移行(Pre-Stage)サイクル:ユーザーを選択し、上部の「開始(Start)」ボタンをクリックし、「前段階移行(Pre-Stage Migration)」を選択します。「移行のスケジューリング」セクションのドロップダウンリストから、「90日前(90 Days Ago)」を選択し、「移行を開始」をクリックします。
- MXレコードカットオーバー。DNSプロバイダーのポータルでMXレコードを切り替えます。また、AutoDiscover(CName)設定を含めます。
- エンドユーザーにメールを送信し、Outlookプロファイルの再構成に関してユーザ側にて操作があることを知らせます。
- 完全移行(デルタ)サイクル:ユーザーを選択し、上部の「開始(Start)」ボタンをクリックして、「完全移行(Full Migration)」を選択し、「移行を開始」をクリックします。
- エラーの再試行(Retry Errors)を実行します。
- ユーザーリストを確認し、赤い「移行に失敗しました」エラーをクリックします。表示された情報に従って操作してください。
- 問題が解決しない場合は、サポートにお問い合わせください。
- DeploymentProを使用しない場合、ユーザーは新しいOutlookプロファイルを作成し、再度署名を設定し、以前のプロファイルに添付されていたPSTファイルを再添付する必要があります。
- MigrationWizダッシュボードの「円グラフアイコン」をクリックすると、プロジェクトから全ての移行統計情報をメールで受信できます。