☰

ADFS を使用した Exchange 2010 から Office 365 への移行

tag-icon • tag-icon exchange-2010 microsoft-office-365 adfs
ADFS を使用した Exchange 2010 から Office 365 への移行

まず最初に、私たちの環境について説明させてください。

ADドメインは1つあります - de***.co.uk

ユーザーがどの部門に所属しているかに関係なく、すべてのユーザーはドメインアカウント（user@de***.co.uk）または（de***\user）を使用してすべてのシステム（Exchangeを含む）で認証します。電子メールアドレスが[メールアドレス]（これはよくあることですよね）

私たちは、部門ごとに段階的に Office 365 E3 に移行する予定です。従業員数は約 300 名、承認済みのメール ドメインは 47 個、メールボックスは 600 個以上あります (一部はローカルの PST にアーカイブされる可能性があります)。IT 部門では、私たちが所有するドメイン de***s****.co.uk で 365 E3 をテストし、ユーザー/メールボックスを手動で設定しました。

現在、1 つの部門をトライアル 365 (20 ユーザー) に移行する準備が整っていますが、オンプレミスの AD にリンクしたいと考えています。このユーザーのサブセットには、電子メール アドレス ドメイン @le***********.com が設定されます。

私が収集した情報から判断すると、これらは私が実行する必要がある手順であると考えています（間違っていたら訂正してください）

  • ADFSを設定する
  • @le************.com ドメインを 365 アカウントに追加します ********(ユーザーをどのように獲得するかは不明です)********
  • le************.com の DNS レコードを Office 365 を指すように変更します
  • 各ユーザーの PST を 365 アカウントにインポートしますか、それとも他の方法ですか?

混乱を引き起こしているのは ADFS の部分です。これまでに、いくつかのチュートリアルで異なる方法が紹介されています (1 つは DC に ADFS をインストールするというもの、もう 1 つは 3 つの新しいサーバー (ADFS プロキシ 1 台、ADFS サーバー 1 台、DirSync サーバー 1 台) をセットアップするというものです)。どれが最適ですか?

ADFS のセットアップ中に、IIS に SSL 証明書をインストールする必要があると言われていますが、この証明書は hostname.de***.co.uk または hostname@le*********.com で、その他の承認済み電子メール ドメインにはそれぞれ独自の SSL が必要ですか?

オンプレミス Exchange に常駐する他のユーザーは、このプロセスの影響を受けますか?

よろしく

答え1

提供された情報に基づいて、次に進めるための最善のシナリオを以下に示します。

ユーザ認証ここで使用できるモデルは次の 3 つです。

  1. Office 365 のユーザー (クラウド アカウント): ユーザー管理は完全にクラウドで行われます。Office 365 ポータルを使用して、ユーザーの作成、無効化、パスワードのリセット、およびすべてのセットアップの構成を行うことができます。これにはローカル AD は必要ありません。ただし、Exchange を含むローカル AD が既に存在し、ユーザー管理を AD でローカルに制御し続けたい場合、このオプションは環境では機能しません。
  2. AD 内のユーザー、Office 365 への一方向同期 (セミフェデレーション アカウント): このモジュールを使用すると、アカウントを作成し、社内 AD サーバー上でユーザー管理全体を行うことができます。ローカル AD からクラウドにユーザーのコピーを作成するには、「DirSync」または新しいバージョンの「ADD Sync」というツールをインストールします。ツールには、ローカル AD からクラウドにユーザー アカウント パスワードを同期するオプションもあります。これにより、ユーザーは同じユーザー資格情報を使用してドメイン内のローカル リソースと Office 365 にログインできるようになり、セミ SSO エクスペリエンスが作成されます。ユーザーは、Office 365 のリソースにアクセスするときにユーザー名とパスワードを入力する必要があり、ユーザーの認証/検証はクラウド側で行われます。このモジュールの要件は、前述のツールをローカル ネットワーク内の任意のサーバーにインストールすることです。ADFS または ADFS プロキシは必要ありません。実装とサポートが最も簡単なため、このオプションを選択してください。
  3. AD 内のユーザー、Office 365 との双方向同期 (フルフェデレーション アカウント): これは 3 つのオプションの中で最も高度なオプションです。このオプションでは、前のオプション「Office 365 への一方向同期による AD のユーザー」のすべての設定が利用されるほか、ADFS および ADFS プロキシ サーバーを使用してローカル AD サーバー上でユーザー認証/検証を強制する機能が追加されます。ローカル ネットワークまたは Azure ハイブリッド ネットワークのいずれかに ADFS/ADFS プロキシと AAD Sync を展開する必要があります。このオプションを使用すると、ドメイン内のユーザーがユーザー名とパスワードを入力しなくても Office 365 にアクセスできるため、完全な SSO エクスペリエンスが得られます。このオプションのインストール、構成、サポートは IT の恐ろしい話なので、このオプションの使用はお勧めしません。

さらに参照するために、ここに大量の情報があります。https://blogs.office.com/2014/05/13/office-365 のサインイン モデルの選択/

メールの移行: ネットワークに Exchange 2010 があるため、電子メールを移行する方法としてサポートされているのは次の通りです。

  1. カットオーバーメール移行: Office 365 ポータルを使用して、移行バッチ ジョブを作成します。このジョブは、Exchange Autodiscover を使用してユーザーのメールボックスを検索し、ローカル Exchange サーバー上のユーザーのメールボックスにアクセスして、メールボックスの内容をクラウドにコピーし始めます。これは、ユーザーがローカル サーバー上のメールボックスを使用している間に発生する可能性があります。すべての電子メールがクラウドに正常にコピーされたら、移行バッチを停止し、DNS レコードを変更して、新しい電子メール/Autodiscover がローカル ネットワーク内のメール サーバーではなくクラウド メール サーバーを指すようにします。ユーザーは、新しいサーバーにアクセスするために再構成する必要があります。また、ローカル サーバーは使用されなくなったため、ユーザーのメールボックスをローカル サーバーから削除できます。個人的には、このオプションを使用することをお勧めします。
  2. ユーザーに代わって .pst ファイルを一括エクスポート/インポートする: ツールを使用してユーザーのメールボックスを .pst ファイルにエクスポートし、それらのファイルをディスクに保存して Microsoft に送信してインポートしてもらうか、.pst ファイルをローカル フォルダーに保存してから、Office 365 の移行ウィザードを使用して自分で Office 365 にインポートします。メールボックスのサイズが比較的小さい場合を除いて、このオプションは使用しないでください。
  3. ユーザーに.pstのインポート/エクスポートを実行するよう依頼します。: 理想的な状況では、ユーザーにメールボックスを .pst ファイルにエクスポートし、ファイルをユーザーのマシンにローカルに保存し、クラウド上の新しいメールボックスで動作するように Outlook を構成し、ユーザーのマシンから新しいメールボックスに .pst ファイルをインポートするように依頼できますが、エンド ユーザーのため、このオプションは絶対に避けます。

電子メールの移行に関する詳細情報は、以下をご覧ください。https://support.office.com/en-us/article/複数のメールアカウントをOffice365に移行する方法-0a4913fe-60fb-498f-9155-a86516418842

認証にオプション 2 を選択し、電子メールにオプション 1 を選択した場合、移行を完了するために ADFS または証明書は必要ありません。エンド ユーザーはカットオーバー移行の最終段階でのみ影響を受けます。

お役に立てれば。

編集:

移行手順は簡単です。次のヒントに従ってください。

  1. すべての承認済みドメインを Office 365 ポータルに追加して検証します。
  2. Microsoft IDFix ツールを使用して、ローカル アカウントのフォーマットとデータが Office 365 と互換性があることを確認します。
  3. ADFS 統合を作成します (どこにでもインストールでき、ハードウェアも必要ないため、私は依然として DirSync のみを使用します。SSO 自動ログインなしでも ADFS と同じように動作しますが、あなたのケースでは ADFS が必須のようです)
  4. ローカル メール サーバーと Office 365 の間にフェデレーション信頼を作成します。
  5. (オプション) ウイルス対策/スパム処理を強化するために、まず受信メールをクラウドにリダイレクトします。
  6. Office 365 に移行するユーザーにライセンスを割り当てます。
  7. 必要に応じて、各部門のユーザーの移動を開始します。
  8. すべてのユーザー アカウントがクラウドに移動されたら、Office 365 とローカル メール サーバー間のフェデレーション信頼を削除します。ADFS または DirSync は常に必要になりますが、そのままにしておきます。
  9. 必要に応じてローカル メール サーバーを削除し、仮想化してオフにしておくこともできます。

関連情報