複数バージョンの Exchange との共存環境における Exchange 2016 のクライアント接続

  • Article

(この記事は 2015 年 10 月 30 日に Exchange Team Blog に投稿された記事 Client Connectivity in an Exchange 2016 Coexistence Environment with Mixed Exchange Versions の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

この記事では、Exchange 2016 の設計中に対応を迫られる可能性があるさまざまな接続シナリオをご紹介します。はじめに、マルチサイト アーキテクチャの Exchange 2013 および Exchange 2010 で構成される展開についてひととおり説明し、その後、Exchange 2016 の導入によって接続性がどのように変化するかを説明します。

現在の環境

上の図からわかるように、この環境には、次の 3 つの Active Directory (AD) サイトが含まれています。

  • インターネット用 AD サイト (サイト 1) - この環境内のメインの AD サイトで、インターネットに接続しています。このサイトには Exchange 2013 および Exchange 2010 サーバーがあります。このサイトには 2 つの名前空間 mail.contoso.com および autodiscover.contoso.com が関連付けられており、CAS2013 インフラストラクチャに解決されています。
  • 地域インターネット用 AD サイト (サイト 2) - インターネットに接続している AD サイトです。このサイトには Exchange 2013 サーバーがあります。プライマリ名前空間は mail-region.contoso.com で、この AD サイト内に置かれた CAS2013 インフラストラクチャに解決されています。
  • 非インターネット用 AD サイト (サイト 3) - インターネットに接続していない AD サイトです。このサイトには Exchange 2010 インフラストラクチャがあります。
注意: インターネット用 AD サイトとは、単純に、この Active Directory サイトに含まれる Exchange サーバーの仮想ディレクトリに ExternalURL プロパティが設定されていることを意味します。同様に、非インターネット用 AD サイトとは、単純に、この Active Directory サイトに含まれる Exchange サーバーの仮想ディレクトリに ExternalURL プロパティが設定されていないことを意味します。

この環境に実際に Exchange 2016 を導入する前のクライアント接続を理解するために、図中の 4 人のユーザーそれぞれに対して各プロトコルがどのように機能するかを考えてみましょう。

自動検出

自動検出の名前空間 autodiscover.contoso.com とすべてのクライアント アクセス サーバーの内部 SCP レコードはどちらも、サイト 1 にある CAS2013 インフラストラクチャに解決されています。Outlook クライアント、ActiveSync クライアント (初期構成では)、および EWS クライアントは、自動検出要求を CAS2013 インフラストラクチャに送信しますが、メールボックスのバージョンによって動作は異なります。

  1. メールボックスが Exchange 2010 にある場合、CAS2013 は、メールボックスのローカル サイト内にある Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。したがって、赤ユーザーの場合は、サイト 1 の CAS2010 へのローカル プロキシになります。青ユーザーとオレンジ ユーザーの場合は、それぞれのユーザーのサイトにある CAS2010 へのクロスサイト プロキシになります。その後、CAS2010 が自動検出応答を生成します。
  2. メールボックスが Exchange 2013 にある場合 (紫ユーザー)、CAS2013 は、ユーザーのメールボックスのアクティブ コピーをホストする Exchange 2013 メールボックス サーバーに要求をプロキシし、ユーザーのメールボックスが自動検出応答を生成します。
注意: スプリット ブレイン DNS の使用を前提とした場合は、クライアント アクセス サーバーの AutoDiscoverServiceInternalUri 値 (SCP レコードの設定に使用するプロパティ値) が autodiscover.contoso.com を指すように構成することをお勧めします。スプリット ブレイン DNS が構成されていない場合、AutoDiscoverServiceInternalUri には、環境内の 2013 クライアント アクセス サーバーの内部負荷分散 VIP に解決される値を設定してください。

自動検出要求がどのように行われるかについては、ホワイト ペーパー『Exchange 2010 の自動検出サービスについて (英語)』を参照してください。

Outlook Anywhere クライアントおよび MAPI/HTTP クライアント

メールボックスが Exchange 2010 にあり、RPC/TCP 接続を使用している内部の Outlook クライアントは、引き続き、Exchange 2010 RPC クライアント アクセス アレイ エンドポイントに接続します。

Exchange 2013 以降のメールボックスがある場合は、企業ネットワークの内部か外部のいずれかの Outlook Anywhere (RPC/HTTP) または MAPI/HTTP を使用することになります。Exchange 2013 以降のメールボックスでは、RPC/TCP 接続は使用されなくなりました。

Exchange 2010 では、名前空間を 1 つだけ構成できるように Outlook Anywhere が実装されていました。Exchange 2013 (および Exchange 2016) では、内部ホスト名と外部ホスト名があります。これは、企業ドメインへの接続用とそれ以外の接続用に、2 つの Outlook Anywhere 設定を持つと考えることができます。これが、ExHTTP として自動検出応答で Outlook クライアントに返される内容です。ExHTTP は新しいプロバイダーのように見えますが、実際のプロバイダーではなく、EXCH (内部 Outlook Anywhere) 設定と EXPR (外部 Outlook Anywhere) 設定から計算された値のセットです。これらの設定を正しく使用するには、Outlook クライアントに適切な修正プログラムが適用されている必要があります (詳細については、Outlook の更新 (英語) を参照してください)。Outlook は ExHTTP を内部設定、外部設定の順に処理します。

重要: スプリット ブレイン DNS インフラストラクチャを使用している場合は、Outlook Anywhere に対して企業ネットワークの内外で名前を切り替えて使用する必要があります。Outlook では、外部の設定よりも内部の設定が優先されます。クライアントが内部か外部かに関係なく、どちらにも同じ名前空間が使用されるため、内部認証の設定のみ が使用されます。2 つの名前空間を使用すると、Kerberos 認証を使用して内部クライアントから確実に接続できます。

Exchange 2013 (Exchange 2016) の既定の内部 Outlook Anywhere 設定は、HTTPS を必要としません。SSL がなくてもクライアントは接続でき、メールやディレクトリへの接続のために証明書ポップアップが表示されることはありません。ただし、Exchange Web サービスや OAB ダウンロードを利用するには、引き続き、クライアント マシンに信頼されている証明書を展開する必要があります。

Outlook Anywhere クライアントの場合、Exchange 2013 クライアント アクセス サーバーはユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。その後、クライアント アクセス サーバーは、要求を次のようにプロキシします。

MAPI/HTTP クライアントの場合、Exchange 2013 クライアント アクセス サーバーはユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2013 であることと、メールボックスの場所を判断します。その後、クライアント アクセス サーバーは、ユーザーのメールボックスのアクティブ コピーをホストする Exchange 2013 メールボックス サーバーに要求をプロキシし、このサーバーが HTTP プロトコルに埋め込まれた MAPI ROP を処理してデータを取得します。

  1. 赤ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 は、メールボックスのバージョンが 2010 で、ユーザーのメールボックスをホストするメールボックス データベースがローカル サイトにあると判断します。CAS2013 は、要求をサイト 1 の CAS2010 にプロキシします。CAS2010 は、HTTP パケットから RPC のカプセル化を解除し、Exchange 2010 メールボックス サーバーからデータを取得します。
  2. 紫ユーザーは RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 青ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 3 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  4. オレンジ ユーザーは、引き続き、Exchange 2013 の地域名前空間 mail-region.contoso.com を使用してメールボックスにアクセスします。サイト 2 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
注意: Outlook Anywhere クライアントは、メール接続、ディレクトリ接続に加えて、Exchange Web サービスとオフライン アドレス帳も利用できますが、これらの URL は自動検出応答によって提供されます。

Outlook Web App

Outlook Web App クライアントの場合、Exchange 2013 クライアント アクセス サーバーはユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。そして、メールボックス サイトの OWA 仮想ディレクトリ構成に合わせてプロキシまたはリダイレクトを実行します。

  1. 赤ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスがローカルの AD サイト内にあると判断します。CAS2013 は要求を Exchange 2010 クライアント アクセス サーバーにプロキシし、このサーバーが Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫ユーザーは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 青ユーザーは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 は、メールボックスがサイト 3 にあると判断しますが、このサイトには OWA ExternalURLs が含まれていません。サイト 1 の CAS2013 は、HTTP セッションを、データベースのアクティブ コピーをサイト 3 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  4. オレンジ ユーザーの場合は、このユーザーが入った名前空間と環境の構成に応じて、次の 3 つのシナリオが考えられます。
    1. オレンジ ユーザーは、名前空間エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    2. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断しますが、このサイトには OWA ExternalURL が含まれています。サイト 1 の CAS2013 は、クロスサイト リダイレクト (既定の動作) を自動的に実行するように構成されています。そのため、CAS2013 は、mail-region.contoso.com へのシングル サインオン リダイレクトを自動的に開始します (ソースとターゲットで FBA が有効になっていると仮定します)。サイト 2 の CAS2013 は要求を実行し、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    3. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断しますが、このサイトには OWA ExternalURL が含まれています。サイト 1 の CAS2013 は、クロスサイト リダイレクトを自動的に実行するように構成されていません。そのため、ユーザーは、正しい URL を使用してメールボックス データにアクセスするように求められます。

Exchange ActiveSync

Exchange ActiveSync クライアントの場合、Exchange 2013 クライアント アクセス サーバーはユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。その後、クライアント アクセス サーバーは、要求を次のようにプロキシします。

注意: Exchange 2013 以降のバージョンでは、451 リダイレクト応答はサポートされません。Exchange 2013 以降は ActiveSync 要求を常にプロキシします (リダイレクトが可能なハイブリッド シナリオ (英語) では例外です)。

  1. 赤ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスがローカルの AD サイト内にあると判断します。CAS2013 は要求を Exchange 2010 クライアント アクセス サーバーにプロキシし、このサーバーが Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫ユーザーの ActiveSync クライアントは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 青ユーザーの ActiveSync クライアントは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 3 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  4. オレンジ ユーザーの場合は、次の 2 つのシナリオが考えられます。
    1. オレンジ ユーザーは、名前空間エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    2. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断します。サイト 1 の CAS2013 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。

Exchange Web サービス

Exchange Web サービスのクライアントの場合、Exchange 2013 クライアント アクセス サーバーはユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。その後、クライアント アクセス サーバーは、要求を次のようにプロキシします。

  1. 赤ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。次に CAS2013 は、ローカル サイト内の Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。
  2. 紫ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 青ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2013 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 3 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  4. オレンジ ユーザーの場合、自動検出は Exchange Web サービスの URL として mail-region.contoso.com 名前空間を返します。サイト 2 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。

Exchange 2016 を導入したサイト 1 へのクライアント接続

以下の図では、Exchange Server 展開アシスタントで提供されているガイドに従って、サイト 1 に Exchange 2016 が展開されています。Exchange 2013 クライアント アクセス サーバーおよび Exchange 2016 メールボックス サーバーはいずれも、負荷分散された名前空間 mail.contoso.com および autodiscover.contoso.com に参加しています。

この環境に Exchange 2016 を導入した後のクライアント接続を理解するために、5 人のユーザーのシナリオについて考えてみましょう。

自動検出

サイト 1 にある CAS2013 または MBX2016 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。CAS2013 または MBX2016 は、要求を次のようにプロキシします。

  1. メールボックスが Exchange 2010 にある場合、CAS2013 または MBX2016 は、メールボックスのローカル サイト内にある Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。したがって、赤ユーザーの場合は、サイト 1 の CAS2010 へのローカル プロキシになります。青ユーザーとオレンジ ユーザーの場合は、それぞれのユーザーのサイトにある CAS2010 へのクロスサイト プロキシになります。その後、CAS2010 が自動検出応答を生成します。
  2. メールボックスが Exchange 2013 にある場合 (紫ユーザー)、CAS2013 または MBX2016 は、ユーザーのメールボックスのアクティブ コピーをホストする Exchange 2013 メールボックス サーバーに要求をプロキシし、ユーザーのメールボックスが自動検出応答を生成します。
  3. メールボックスが Exchange 2013 にある場合 (黄ユーザー)、CAS2013 または MBX2016 は、ユーザーのメールボックスのアクティブ コピーをホストする Exchange 2016 メールボックス サーバーに要求をプロキシし、ユーザーのメールボックスが自動検出応答を生成します。

Outlook Anywhere 接続および MAPI/HTTP 接続

Outlook Anywhere 接続の場合、Exchange 2013 クライアント アクセス サーバーまたは Exchange 2016 メールボックス サーバーの RPC プロキシ コンポーネントは、着信接続を確認すると認証を行い、要求をルーティングするサーバーを (バージョンに関係なく) 選択して、HTTP セッションをエンドポイント (Exchange 2010 クライアント アクセス サーバー、Exchange 2013 メールボックス サーバー、または Exchange 2016 メールボックス サーバー) にプロキシします。

MAPI/HTTP 接続の場合、Exchange 2013 クライアント アクセス サーバーまたは Exchange 2016 メールボックス サーバーの MAPI 仮想ディレクトリ プロキシ コンポーネントは、着信接続を確認すると認証を行い、要求をルーティングするサーバーを (バージョンに関係なく) 選択して、HTTP セッションをエンドポイント (Exchange 2013 メールボックス サーバーまたは Exchange 2016 メールボックス サーバー) にプロキシします。

  1. 赤ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、メールボックスのバージョンが 2010 で、ユーザーのメールボックスをホストするメールボックス データベースがローカル サイトにあると判断します。CAS2013 または MBX2016 は、要求をサイト 1 の CAS2010 にプロキシします。CAS2010 は、HTTP パケットから RPC のカプセル化を解除し、Exchange 2010 メールボックス サーバーからデータを取得します。
  2. 紫ユーザーは、RPC プロキシ エンドポイントまたは MAPI/HTT エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 黄ユーザーは、RPC プロキシ エンドポイントまたは MAPI/HTT エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2016 メールボックス サーバーにプロキシします。
  4. 青ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、メールボックスのバージョンが 2010 で、ユーザーのメールボックスをホストするメールボックス データベースがサイト 3 にあると判断します。CAS2013 または MBX2016 は、要求をサイト 3 の CAS2010 にプロキシします。CAS2010 は、HTTP パケットから RPC のカプセル化を解除し、Exchange 2010 メールボックス サーバーからデータを取得します。
  1. オレンジ ユーザーは、引き続き、Exchange 2013 の地域名前空間 mail-region.contoso.com を使用してメールボックスにアクセスします。サイト 2 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。

 

Outlook on the web

Outlook on the web クライアントの場合、Exchange 2013 クライアント アクセス サーバーまたは Exchange 2016 メールボックス サーバーがユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。そして、メールボックスのサイト内の OWA 仮想ディレクトリ構成に合わせてプロキシまたはリダイレクトを実行します。

  1. 赤ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスがローカルの AD サイト内にあると判断します。MBX2016 は要求を Exchange 2010 クライアント アクセス サーバーにプロキシし、このサーバーが Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫ユーザーは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 黄ユーザーは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2016 メールボックス サーバーにプロキシします。
  4. 青ユーザーは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、メールボックスがサイト 3 にあると判断しますが、このサイトには OWA ExternalURLs が含まれていません。サイト 1 の CAS2013 または MBX2016 は、サイト 3 の CAS2010 に要求をプロキシします。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  5. オレンジ ユーザーの場合は、このユーザーが入った名前空間と環境の構成に応じて、次の 3 つのシナリオが考えられます。
    1. オレンジ ユーザーは、名前空間エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    2. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断しますが、このサイトには OWA ExternalURL が含まれています。サイト 1 の CAS2013 または MBX2016 は、クロスサイト リダイレクト (既定の動作) を自動的に実行するように構成されています。そのため、CAS2013 または MBX2016 は、mail-region.contoso.com へのシングル サインオン リダイレクトを自動的に開始します (ソースとターゲットで FBA が有効になっていると仮定します)。サイト 2 の CAS2013 は要求を実行し、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    3. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断しますが、このサイトには OWA ExternalURL が含まれています。サイト 1 の CAS2013 または MBX2016 は、クロスサイト リダイレクトを自動的に実行するように構成されていません。そのため、ユーザーは、正しい URL を使用してメールボックス データにアクセスするように求められます。

Exchange ActiveSync

Exchange 2013 クライアント アクセス サーバーまたは Exchange 2016 メールボックス サーバーは、着信接続を確認すると認証を行い、要求をルーティングするサーバーを (バージョンに関係なく) 選択して、HTTP セッションをエンドポイント (Exchange 2010 クライアント アクセス サーバー、Exchange 2013 メールボックス サーバー、または Exchange 2016 メールボックス サーバー) にプロキシします。

  1. 赤ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスがローカルの AD サイト内にあると判断します。CAS2013 または MBX2016 は要求を Exchange 2010 クライアント アクセス サーバーにプロキシし、このサーバーが Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫ユーザーの ActiveSync クライアントは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 黄ユーザーの ActiveSync クライアントは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2016 メールボックス サーバーにプロキシします。
  4. 青ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断します。サイト 1 の CAS2013 または MBX2016 は、サイト 3 の CAS2010 にクロスサイト プロキシ要求を発行します。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  5. オレンジ ユーザーの場合は、次の 2 つのシナリオが考えられます。
    1. オレンジ ユーザーは、名前空間エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーに対してローカル プロキシを実行します。
    2. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2013 または MBX2016 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断します。サイト 1 の CAS2013 または MBX2016 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。

Exchange Web サービス

Exchange Web サービスも、他のプロトコルのときと同じプロセスをたどります。Exchange 2013 クライアント アクセス サーバーまたは Exchange 2016 メールボックス サーバーは、ユーザーを認証し、サービス検出を行い、メールボックスのバージョンおよびメールボックスの場所を判断します。次に、サーバーは、ユーザーのメールボックスのアクティブ コピーをホストするメールボックス サーバーに要求をプロキシし、ユーザーのメールボックスがデータを取得します。

  1. 赤ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。次に CAS2013 または MBX2016 は、ローカル サイト内の Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。
  2. 紫ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  3. 黄ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2013 または MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Exchange 2016 メールボックス サーバーにプロキシします。
  4. 青ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2013 または MBX2016 はクロスサイト プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 3 でホストする Exchange 2013 メールボックス サーバーにプロキシします。
  5. オレンジ ユーザーの場合、自動検出は Exchange Web サービスの URL として mail-region.contoso.com 名前空間を返します。サイト 2 の CAS2013 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 2 でホストする Exchange 2013 メールボックス サーバーにプロキシします。

オフライン アドレス帳

Exchange Web サービスの場合と同じく、自動検出はオフライン アドレス帳の URL を返します。

  1. 赤ユーザーの場合、自動検出はオフライン アドレス帳の URL として mail.contoso.com 名前空間を返します。CAS2013 または MBX2016 は、その後、このオフライン アドレス帳の Web 配布ポイントであるローカル サイト内のクライアント アクセス サーバーに要求をプロキシします。
  2. 黄ユーザーおよび 紫ユーザーの場合、自動検出はオフライン アドレス帳の URL として mail.contoso.com 名前空間を返します。次に CAS2013 または MBX2016 は、OABGEN メールボックスのアクティブ コピーをホストする Exchange 2013 または Exchange 2016 のメールボックス サーバーに要求をプロキシします。OABGEN メールボックスには、ユーザーのメールボックスに最も近い OAB のコピーが含まれます。
  3. 青ユーザーの場合、自動検出はオフライン アドレス帳の URL として mail.contoso.com 名前空間を返します。CAS2013 または MBX2016 は、その後、このオフライン アドレス帳の Web 配布ポイントであるローカル サイト内のクライアント アクセス サーバーに要求をプロキシします。
  4. オレンジ ユーザーの場合、自動検出はオフライン アドレス帳の URL として mail-region.contoso.com 名前空間を返します。

 

まとめ

この記事で、Exchange 2010 および Exchange 2013 と共存している Exchange 2016 について、プロキシとリダイレクトのロジックにまつわる誤解を少しでも払拭していただくことができれば幸いです。ご質問があればお知らせください。

Ross Smith IV
主任プログラム マネージャー
Office 365 カスタマー エクスペリエンス担当