1. BitTitan Help Center
  2. 移行の実行
  3. Exchange

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

Exchangeの移行は、移行元と移行先のバージョンによって異なります。移行の実行に必要な手順については、お客様のシナリオに合った移行ガイドを参照してください。本記事では、Exchangeメールボックスの移行に関するよくある質問のいくつかについて、より一般的な情報と説明を提供します。

アクセス

管理者資格情報を使用して移行する 

一部のExchange IMAPシステムは、管理者ログインをサポートしています。この機能を使用する方法は、次の通りです。

  1. 各メールボックスで、次のようにユーザー名を指定します。
    • domain\adminUserName\mailboxUserName
  2. 各メールボックスで、管理者のパスワードを指定します。

お客様の構成に応じて、各メールボックスで指定するユーザー名の例をいくつか示します。

  • domain.com\admin\user1
  • domain\admin\user1
  • domain\admin@company.com\user@company.com

Intermediaのホスト型ExchangeにおけるExchangeアカウントのフルアクセス権限

Intermediaがホストするアカウントのみ
コントロールパネルに移動し、管理者アカウントを使用してログインします。
  1. 「サービス(Services)」に移動し、「Exchangeメールボックス(Exchange Mailbox)」をクリックします。
  2. フルアクセス権限を付与するメールボックスの表示名をクリックします。
  3. 「Exchange」をクリックします。「メールボックスのアクセス(Mailbox access)」領域で、「フルアクセスと代理送信(Full access & Send as)」リンクをクリックします。
  4. 新しいウィンドウで、移行に使用する管理者名を入力し、「名前を確認する(Check Name)」ボタンをクリックして、名前を確認します。アドレス帳から名前を選択することもできます。 
  5. 「追加(Add)」 をクリックして、管理者アカウントを追加します。
  6. 「フルアクセス(Full Access)」を選択し、「許可されているアクセス(Access Allowed for)」ウィンドウで、「変更を保存(Save Changes)」をクリックします。

上記の手順は一般的なガイドラインであり、変更される可能性があります。フルアクセス権限の付与で問題が発生した場合は、Intermediaにお問い合わせください。

移行できるアイテム

ルールと権限

ルールと権限は、移行元がExchange Server 2010以降(またはMicrosoft 365)の場合にのみ移行することができます。これは、Exchangeの以前のバージョンのAPI制限によるものです。また、移行先はExchange Server 2013以降(またはMicrosoft 365)である必要があります。

SP1以降が適用されているExchange Server 2010以降の場合、ルールと権限は次のように処理されます。

ルール

移行元が「Exchange Server 2003以降(Exchange Server 2003+)」に設定されている場合、ルールはオプションとして表示されますが、実際に移行できるのは、SP1以降が適用されているExchange Server 2010以降のサーバーからのみです。ユーザーインターフェース(UI)での設定が、このように少し分かりにくい仕様になっているのは、Exchange Serverのすべてのバージョンが、移行元では「Exchange Server 2003以降(Exchange Server 2003+)」という1つのオプションに統合されているためです。これは、UI内での移行元環境の選択を簡素化するための措置です。

  • サーバー側のルールは移行されます。クライアント側のルールは移行されません。
  • デフォルトでは、システムフォルダーの権限のみが移行されます。システムフォルダーには、「受信トレイ(Inbox)」、「送信済み(Sent)」、「ゴミ箱(Trash)」などのフォルダーが含まれます。すべてのフォルダーの権限を移行したい場合は、詳細オプションの「MustMigrateAllPermissions=1」を使用します。
  • MigrationWizでは、Microsoft 365 Multi-Geoテナントのルールの移行は、現時点では実行性が検証されていません。

フォルダーの権限

  • フォルダーの権限は移行されますが、委任/共有権限は移行されません。つまり、「代理送信(Send As)」および「代理送信(Send On Behalf Of)」の権限は、移行されません。
  • フォルダーの権限は、メールボックス内の個々のフォルダーレベルで付与される権限のことです。設定するには、メールボックス内でフォルダーを右クリックし、「プロパティ(Properties)」を選択して、「権限(Permissions)」タブをクリックし、権限を定義します。
  • 委任された権限は、「ツール(Tools)」 > 「オプション(Options)」 > 「代理人(Delegates)」から設定します。委任された権限は移行されないため、移行後に再設定する必要があります。

リソースの移行

本記事の情報は、移行元および移行先がExchangeまたはMicrosoft 365の場合に固有のものです。

リソースメールボックスは、通常のユーザーメールボックスと同じ方法で処理されます。

Webクライアント(Outlook Web Accessなど)を使用してリソースメールボックスにログインできる場合は、データを移行することができます。Webクライアント(OWA など)を使用してリソースメールボックスにログインすることができない場合は、データを移行することができません。

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

配布リスト

MigrationWizでは、配布リストの検出機能がないため、サーバーベースの配布リストは移行されません。個人用配布リストも、MigrationWizでは移行されません。

サーバーベースの配布リストと個人用配布リストには、大きな違いがあります。サーバーベースの配布リストは、グローバルアドレス一覧に表示されますが、個人用配布リストは、ローカルに保存されます。

現在、Microsoft 365では、個人用配布リストは「連絡先グループ」と呼ばれています。

サーバーベースの配布リストがある場合、次のオプションのいずれかを実行します。

  • Microsoft(正式にはAAD Syncとして知られるAAD Connectなど)を使用して、移行元環境と移行先環境の間で配布リストを同期します。 
  • 独自のPowerShellスクリプトを作成して、配布リストをエクスポートおよびインポートします。Microsoftのコードサンプルは、こちらを参照してください。
  • 移行先で、配布リストを手動で再作成します。
移行元がホスト型Exchangeの場合、ホストプロバイダーに依頼して、配布リストをCSVファイルにエクスポートし、そのCSVファイル内の情報をMicrosoft 365にインポートします。

他の移行元システムには、(Exchangeの)配布リストはありません。パートナーは、移行後に配布リストを作成し、移行元の対応するグループ/配布リストのメンバーシップに基づいて、必要なユーザーを配布リストに追加する必要があります。

フォルダーの変換

フォルダーサイズが移行に与える影響

以下の、該当するソフトウェアのバージョンを参照してください。

Exchange 2003

Microsoftが推奨するガイドラインを超える大きなフォルダーを移行する場合、Exchange 2003のデータのエクスポート速度が低下する可能性があります。TechNetの記事、アイテム数の多さと制限付きビューがパフォーマンスに与える影響についてで、Microsoftは、「Exchange Server 2003では、推奨されるフォルダーあたりの最大アイテム数は5,000でした。」と述べています。

サイズの大きいフォルダーの問題を回避する唯一の方法は、次のとおりです。

Exchange 2007

Microsoftが推奨するガイドラインを超える大きなフォルダーを移行する場合、Exchange 2007のデータのエクスポート速度が低下する可能性があります。

TechNetの記事、アイテム数の多さと制限付きビューがパフォーマンスに与える影響についてで、Microsoftは、「Exchange 2007では、I/Oの改善、ページサイズの増大、およびキャッシュの増加により、推奨される最大アイテム数を増やすことができるようになりました。ハードウェアが正しく設計されていれば、20,000ものアイテム数でも、ユーザーの操作性を許容範囲内に維持できます。」と述べています。

速度が低下するのは、最大アイテム数のガイドラインを超える大きなフォルダーのみであり、推奨サイズよりも小さいフォルダーは、影響を受けません。

サイズの大きいフォルダーの問題を回避する唯一の方法は、次のとおりです。

Exchange 2010、2013、2016、およびMicrosoft 365

Microsoftが推奨するガイドラインを超える大きなフォルダーを移行する場合、Exchange 2010以降のデータのエクスポート速度が低下する可能性があります。

TechNetの記事、アイテム数の多さと制限付きビューがパフォーマンスに与える影響についてで説明されているように、Exchange 2010、2013、2016では、最大フォルダーサイズは100,000アイテムです。

速度が低下するのは、最大アイテム数のガイドラインを超える大きなフォルダーのみであり、推奨サイズよりも小さいフォルダーは、影響を受けません。

サイズの大きいフォルダーの問題を回避する唯一の方法は、次のとおりです。

移行先でフォルダーの種類が異なる場合

メールボックスの移行で、メールのみを移行すると、移行先で一部のフォルダーの種類が異なる(予定表フォルダーではなくメールフォルダーになっている)場合や、一部のアイテムが消失する場合があります。これは、メールフォルダーにメール以外のサブフォルダー(予定表や連絡先など)が含まれている場合に発生します。

例：移行元環境では、「フォルダー1」はメールフォルダー、「フォルダー2」(「フォルダー1」のサブフォルダー)は予定表フォルダーです。メールのみのメールボックス移行を実行すると、「フォルダー1」とそのサブフォルダーが移行されます。ただし、「フォルダー2」は移行先でメールフォルダーに変換され、そのフォルダー内に保存されている予定表アイテムは、移行後に消失します。

この問題を回避するには、種類ごとにフォルダーを分類し、メール以外のフォルダーをルートに移動するようユーザーに指示することをお勧めします。種類ごとにフォルダーを分類することができない場合は、すべての種類のメールボックスアイテム(メール、予定表、連絡先など)の「完全移行(Full Migration)」を実行することをお勧めします。

この問題は、サポートオプションのフォルダーマッピングを使用して、移行元のメールボックスのコンテンツを移行先の単一のフォルダーにマップする場合にも、発生する可能性があります。この問題を回避する方法については、MigrationWiz － メールボックス移行(MigrationWiz - Mailbox Migrations)を参照してください。

ファイル名にフォワードスラッシュ「/」が含まれている場合

MigrationWizは、Outlookのフォルダー名のフォワードスラッシュ「/」を、移行中にアンダースコア「_」に変換します。  この要件は、基盤となる移行プロトコル(たとえば、Exchange 2007以降のサーバーからの移行に使用するExchange Webサービス(EWS)など)の制限を回避するために設けられました。

注： この変換が最もよく発生するのは、「/」を使った日付を含むフォルダー名です。

訴訟ホールドの移行

訴訟ホールドの移行は、いくつかの制限付きでサポートしています。訴訟ホールドでは、100％の証拠保全が求められるため、これらの制限を把握しておくことが重要です。

MigrationWizでは、プライマリメールボックス内のメールはすべて移行されますが、アーカイブメールボックス内の訴訟ホールドデータは移行されません。アーカイブメールボックスに訴訟ホールドデータがある場合、プライマリメールボックスまたは「回復可能なアイテム(Recoverable Items)」フォルダーのいずれかに移動する必要があります。

訴訟ホールドで作成されたフォルダーは、ほとんどが「メールフォルダー」であると考えられますが、一部そうでないものも含まれています。メール以外のすべての訴訟ホールドアイテムは、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"」をプロジェクトに追加する必要があります。

たとえば、以下のすべての詳細オプションを追加して、移行元のフォルダーを移行先の対応するフォルダーに移行します。

OverrideRecoverableItemsFolderMapping="^Calendar Logging->Calendar Logging"
OverrideRecoverableItemsFolderMapping="^Deletions->Deletions"
OverrideRecoverableItemsFolderMapping="^DiscoveryHolds->DiscoveryHolds"
OverrideRecoverableItemsFolderMapping="^Purges->Purges"
OverrideRecoverableItemsFolderMapping="^Versions->Versions"

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

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

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

MigrationWiz®では、非アクティブなユーザーの訴訟ホールドが設定されたメールボックスは、デフォルトでは移行されません。非アクティブなユーザーは、移行先システムでライセンスが付与されず、メールボックスが作成されないため、保持されているアイテムの移行場所がないからです。

移行に特別な設定を行うと、これらの非アクティブなユーザーのメールボックスを移行することが可能になります。以下の手順に従ってプロジェクトを作成すると、Microsoft 365の非アクティブなユーザーの訴訟ホールドデータを
Microsoft 365テナントに移行することができます。

  1. すべての非アクティブなメールボックスを検索します。以下のPowershellコマンドを使用して、検索を実行します。
    Get-Mailbox -InactiveMailboxOnly -ResultSize Unlimited
  2. 非アクティブなユーザーを、「クイック追加(Quick Add)」で個別に、または「一括追加」でCSVファイルを使用して、MSPCompleteに追加します。 
  3. 移行先のMicrosoft 365テナントに、ターゲットメールボックスを作成します。
  4. Microsoft 365で新たに作成したメールボックスに、ライセンスを割り当てます(最低でもE3ライセンスが必要です)。
  5. 新しいメールボックスに訴訟ホールドを設定します。
  6. すべての新しいメールボックスを非アクティブに設定します。これにより、これらのメールボックスからMicrosoft 365ライセンスが削除されます。
  7. 新しいMigrationWizメールボックスプロジェクトを作成します。
  8. 「テナントからテナントへの併用設定を有効化する(Enable Tenant to Tenant Coexistence)」のチェックボックスをオフにします。
  9. 「保存」をクリックします。
  10. 非アクティブなユーザーのメールアドレスをプロジェクトに追加します。移行元のメールアドレスは、非アクティブなメールボックスのユーザープリンシパル名(UPN)と同じである必要があります。移行先のメールアドレスは、前述の手順で新たに作成したメールアドレスになります。 
  11. プロジェクトが作成されたら、「プロジェクトの編集」をクリックして、「詳細オプション(Advanced Options)」を選択します。
  12. 「移行元/移行先(Source/Destination)」タブ内の「移行元(SOURCE)」と「移行先(DESTINATION)」の両セクションで、「回復可能なアイテム」をクリックします。
  13. 「保存(Save)」をクリックします。

これで、移行を実行する準備が整いました。お客様のシナリオによっては、追加の設定が必要になる場合もありますが、非アクティブなユーザーのメールボックスを移行するための設定は、これで完了です。

この移行が失敗した場合は、「回復可能なアイテム(Recoverable Items)」の移行を再試行する前に、非アクティブなメールボックスを回復してください。Microsoftのドキュメント、 非アクティブなメールボックスを回復するの手順に従って、メールボックスを回復します。メールボックスが回復したら、移行を再実行します。

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

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

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

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

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

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

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

自動検出

Exchangeホストプロバイダーのメインの自動検出URLと証明書プリンシパル名を確認する

メインの自動検出URLは、エンドユーザーがOutlook Web Access (OWA) URLとして入力する自動検出URLとは異なります。エンドユーザーのOWA URLではなく、Exchangeホストプロバイダーのメインの自動検出URLを、DeploymentProプロジェクトに含めることが重要です。Exchangeホストプロバイダーが、DNS自動検出リダイレクトを適切に設定していない場合、エンドユーザーの自動検出URLに基づいてプロファイルを再構成する時に、問題が発生する可能性があります。このため、エンドユーザーのOWA URLではなく、メインの自動検出URLを入力することが重要です。

移行先エンドポイントがExchange 2003以降の場合、DeploymentProプロジェクトを設定する時に、DeploymentProポータルに自動検出設定のセクションが表示されます。フィールドに入力する内容については、このナレッジベース記事の最後を参照してください。

以下の手順では、移行先のExchangeホストプロバイダーの、メインの自動検出URLおよび証明書プリンシパル名の両方を確認する方法、および、それらの必要な情報を、DeploymentProプロジェクト内のどこに入力すべきかについて説明します。これらの手順は、Exchangeホストプロバイダーに、DeploymentProを使用して移行を実行する場合にのみ必要です。DeploymentProが正式にサポートしているシステムについては、DeploymentProでサポートされている移行先システムは何ですか？を参照してください。

移行先のExchangeホストプロバイダーのメインの自動検出URLを確認する方法

オプション1

  1. 移行先のExchangeホストプロバイダーからOWA URLを取得します。OWA URLをブラウザーウィンドウに入力します。ブラウザーが、Exchangeホストプロバイダーのメインの自動検出URLに自動的にリダイレクトします。 
  2. リダイレクト先のURLをDeploymentProプロジェクトに入力します。詳細については、こちらを参照してください。

オプション2

お客様のExchangeホストプロバイダーに、メインの自動検出URLを問い合わせます。

注：

顧客固有の自動検出URLやOWA URLではなく、メインの自動検出URLを取得してください。顧客の自動検出URLは、メインの自動検出URLに自動的にリダイレクトされます。ホストプロバイダーがDNSを適切に設定していない場合、このリダイレクトは失敗し、Outlookプロファイルが正しく再構成されません。

証明書プリンシパル名を確認する方法

オプション1

お客様のExchangeホストプロバイダーに、証明書プリンシパル名を問い合わせます。

オプション2

テストまたはアクティブな1人のメールボックスユーザーに対し、1つのOutlookプロファイルを手動で構成します。

注： このプロファイルの設定時は、自動検出の警告メッセージをバイパスして、プロファイルの構成を完了します。プロファイルを作成したら、その設定を使用して、Exchangeホストプロバイダーの証明書プリンシパル名を確認することができます。これをDeploymentProポータルに入力すると、今後のすべてのプロファイルが、各プロファイルに保存されているこの証明書プリンシパル名を使用して構成できるようになります。

  1. この手動で構成されたプロファイルを使用してOutlookを実行中に、「Ctrl」キーを押しながらシステムトレイまたは通知領域(コンピューター画面の右下隅)にあるOutlookアイコンを右クリックし、「電子メールの自動構成のテスト(Test E-mail AutoConfiguration)」を選択します。 
  2. メールアドレスとパスワードを入力します。
  3. 「Guessmartを使用(Use Guessmart)」および「セキュアGuessmart認証(Secure Guessmart Authentication)」の横のチェックボックスをオフにします。「自動検出を使用(Use Autodiscover)」が選択されていることを確認します。
  4. 「テスト(Test)」ボタンをクリックします。
  5. 次のスクリーンショットで示すように、結果ウィンドウで、証明書プリンシパル名のエントリを特定します。

1.PNG 

重要： 上のスクリーンショットは、Microsoft 365の例です。ホストプロバイダーの証明書プリンシパル名には、お客様のExchangeホストプロバイダーのURL情報が含まれます。

DeploymentPro内の、メインの自動検出URLと証明書プリンシパル名を入力する場所

顧客向けにDeploymentProを初めて起動すると、自動検出URLと証明書プリンシパル名を入力するためのフィールドがいくつか表示されます。

上記の手順で収集した情報を、これらのフィールドに入力します。

2.PNG

上のスクリーンショットは、Microsoft 365の例です。ホストプロバイダーの証明書プリンシパル名には、お客様のExchangeホストプロバイダーのURL情報が含まれます。

WebDAVを使用して、Exchange 2007をエクスポートする

移行元サーバーがExchange 2007の場合、デフォルトでは、EWSを使用してデータがエクスポートされます。

重要：1つのメールボックスの移行が開始されると、そのメールボックスを別のメールボックスに切り替えることはできなくなります。システムがそれを阻止するため、切り替えを実行しても失敗に終わります。これは、2つのメソッド間の重複を検出することができないためです。切り替えるには、以前に移行したデータを削除する必要があります。移行前に、次のオプションを設定する必要があります。

コネクタ内のすべてのメールボックスに、WebDAVの使用を強制する方法
  1. MigrationWizアカウントにサインインします。
  2. 「ダッシュボード(Dashboard)」をクリックします。
  3. 「メールボックス移行(Mailbox Migration)」セクションで、「メールボックスの移行を実行する(Perform mailbox migration)」をクリックします。
  4. 「メールボックスコネクタ(Mailbox Connector)」を選択します。
  5. 「タスク(Task)」メニューから、「コネクタを編集(Edit connector)」をクリックします。
  6. 「詳細オプションを表示(Show Advanced Options)」リンクをクリックします。
  7. 「サポートのみのオプション(Support Only Options)」フィールドに、「MustUseWebDav=1」を入力します。

切り替えを行う前に、移行先メールボックスがクリーンアップ(または再作成)されていることを確認してください。クリーンアップされていない場合、移行によって重複が発生します。

移行の開始後にエクスポートメソッドを切り替えた場合、移行は失敗し、エラーが表示されます。エクスポートメソッドを切り替えたい場合は、サポートチームにお問い合わせください。

Azure Active Directory (AAD) Connectを使用して、オブジェクトをフィルター処理する

本セクションでは、AAD Connectを使用して、フィルターを設定する(「msExchMailboxGuid」を削除して、環境間でオブジェクトを同期する)手順について説明します。

注：

  • AAD Syncを使用する場合の手順は、以下で説明する手順と非常に似ています。
  • DirSyncを使用する場合の手順は、一部異なる箇所があります。DirSyncから、AAD SyncまたはAAD Connectにアップグレードすることをお勧めします。

以下は、同期によってオブジェクトをフィルター処理することが利点となるユースケースの例です。

  • 一部のユーザーは、すでにMicrosoft 365を運用プラットフォームとして使用しています。すでにMicrosoft 365を使用しているユーザーのオブジェクトを除いた、他のすべてのオブジェクトをフィルターで除外する必要があるとします。すでにMicrosoft 365を使用しているユーザーのオブジェクトのみを同期の対象にします。
  • Microsoft 365へのバッチ移行を計画しています。移行するバッチ(または以前のバッチ)に含まれるユーザーオブジェクトを除いた、他のすべてのオブジェクトをフィルターで除外する必要があります。バッチに含まれるユーザーオブジェクトのみを同期の対象にします。
  • すべてのユーザーに割り当てるのに充分なExchange Onlineライセンスがありません。この方法は、同期されたすべてのアカウントにライセンスを割り当てることができるため、有用です。
  • Exchange Onlineライセンスを有効にすると、エラーが発生します。

重要：上記のすべてのシナリオで、Microsoft 365に完全なグローバルアドレス一覧(GAL)を作成するには、AAD Connectを使用して、すべてのオブジェクトを同期する必要があります。Microsoft 365でメールルーティングが有効になった後、ユーザーはオンプレミスユーザーにメールを送信できるようになります。

概要説明

選択したフィルターにより、同期されたオブジェクトの 「msExchMailboxGuid」が削除されるため、すでにMicrosoft 365を使用しているユーザーに対するサービスの中断が回避されます。

以下の手順に従うと、AAD Connectで新しいルールを作成して、1つの「extensionAttribute」(Exchangeでは「customAttribute」、Active Directoryスキーマでは「extensionAttribute」と呼ばれます)に基づいて、オブジェクトをフィルター処理することができます。

  • 開始する前に、AAD ConnectとPowerShellの構文を理解しておくことが重要です。
  • 本ガイドのスクリーンショットは、Microsoft Azure Active Directory Connect バージョン 1.1.189.0 の例です。他のバージョンを使用している場合は、スクリーンショットが異なる場合があります。

移行前のタスク

  1. 「extensionAttribute」を1つ選択し、カスタマイズしたタグを設定します。例では、「extensionAttribute 5」とタグ「BT - User Migrated」を使用しています。
  2. Exchange Onlineライセンスを割り当てるユーザーの「extensionAttribute」に、選択したタグを設定します。次のいずれかの方法で行います。

a. Exchange管理コンソール(EMC)を使用します。
3.jpg

b. Exchange管理シェル(EMS)を使用して、次のスクリプトを実行します。

Set-Mailbox <user_UPN> -customAttribute5 "BT - User Migrated"

c. EMSを使用して、一括編集します。

  • Exchange Onlineを有効にするユーザーのUPNを含むusers.CSVファイルを作成します。このファイルは、次のようになります。
​UPN
​UserA@mydomain.com
​​​​UserB@mydomain.com
​​​UserC@mydomain.com
​...
​​​UserZ@mydomain.com

d. 次のPowerShellスクリプトを実行します。

$UserList = Import-CSV '<Path Name>\Users.csv'
foreach( $user in $UserList )
{
     Set-Mailbox $user.UPN -customAttribute5 "BT - User Migrated"
}

3. ルールを検索して選択します。

  • Windowsで、Synchronization Rules Editorを検索して開きます。 デフォルトの場所は、「C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe」です。
    4.jpeg
  • 「In from AD - User Exchange」という名前のルールを検索して選択し、「エクスポート(Export)」をクリックします。最も低い優先順位の番号を書き留めておきます。この番号は、後で必要になります。この例では、最も低い優先順位は80です。
    5.jpg

システムのデフォルトのテキストエディター(メモ帳など)が、ランダムな名前と.tmp拡張子で開きます。このファイルを安全な場所に保存します。このファイルを使用すると、何か問題が発生した場合に、カスタマイズなしのデフォルトのルールを再作成できます。

6.jpg

4.  ファイルを保存した後、複製を作成し、拡張子を.ps1に変更して、ファイルを編集します。
7.jpg

.ps1ファイルを次のように編集します。

    • カスタマイズされたルールであることが分かるように、Nameを変更します。
    • Precedenceを、手順3で書き留めた数値よりも小さい数値に変更します。
    • IdentifierとImmutableTagの行を削除します。

上記の変更を行うと、ファイルは次のようになります。

8.jpeg
 

5. 昇格した権限でPowerShellを開き、.ps1ファイルを保存したフォルダーに移動して、スクリプトを実行します。完了したら、上にスクロールして、エラーを確認します。 
9.jpg

6. ファイルを閉じて再度開き、Synchronization Rules Editorに、新しい行が作成されたことを確認します。
10.jpeg

7. 次に、ルールを編集します。

    • カスタマイズされた同期ルールから始めます。
    • ルールを強調表示して、「編集(Edit)」をクリックします。
      11.jpg
    • 「スコープフィルター(Scoping filter)」を選択し、「条項を追加(Add clause)」ボタンをクリックします。これにより、新しい行が作成されます。以前と同じ「extensionAttribute」を選択します。「演算子(Operator)」で、「等価(EQUAL)」を選択し、「値(Value)」に「BT - User Migrated」を入力して、「変換(Transformations)」を選択します。
      12.jpg

    • 「msExchMailboxGuid」属性が見つかるまで下にスクロールし、次のように変更します。

      フロータイプ： Expression
      ターゲット属性：msExchMailboxGuid
      ソース： NULL

      結合タイプ： Update
      13.jpg

    • 「保存(Save)」をクリックします。ウィンドウが自動的に閉じます。
    • 次に、元の同期ルールを編集します。「スコープフィルター(Scoping filter)」で、「条項を追加(Add clause)」をクリックし、「extensionAttribute」、「NOTEQUAL」、「BT - User Migrated」を追加します。
      • 次のようになります。
        14.jpg

8. 完全同期を実行します。差分同期では、必要な変更が行われません。 

この完全同期を実行する簡単な方法は、AAD Connectが実行されているコンピューターでPowerShellを開き、次のスクリプトを実行することです。

​Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

9. 必要なユーザーに対して、Exchange Onlineライセンスを有効にします。

10. EMC、AD、またはPowerShellを使用して、ユーザーから「BT - User Migrated」タグを削除します。PowerShellを使用している場合は、「BT -User Migrated」を「$null」に置き換えます。

11. 差分同期を実行します。

この差分同期を実行する簡単な方法は、AAD Connectが実行されているコンピューターでPowerShellを開き、次のスクリプトを実行することです。

​Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

移行後のタスク

Microsoft 365で必要なExchangeライセンスをすべて有効にすると、AAD Connectで行われたすべての変更を元に戻すことができます。

  1. カスタマイズされた同期ルールを強調表示して、削除します。
    15.jpg
    16.jpg
  2. 元のルールの「スコープフィルター(Scoping filter)」から、条項を削除します。
    17.jpg

    このファイルは、次のようになります。
    18.jpg
この記事は役に立ちましたか？
0人中0人がこの記事が役に立ったと言っています

このセクションの記事