Partager via

Exchange 2010 との共存環境における Exchange 2016 のクライアント接続

  • Article

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

 

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

現在の環境

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

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

この環境に Exchange 2016 を導入する前のクライアント接続を理解するために、3 人のユーザーそれぞれに対する各プロトコルのしくみについて考えてみましょう。

 

自動検出

自動検出の名前空間 autodiscover.contoso.com と内部の SCP レコードはどちらも、サイト 1 にある CAS2010 インフラストラクチャに解決されています。Outlook クライアントと ActiveSync クライアントは (初期構成では) 自動検出要求を CAS2010 インフラストラクチャに送信し、メールボックスの場所に基づいて構成設定を取得します。

注意: スプリット ブレイン DNS の使用を前提とした場合は、2010 のクライアント アクセス サーバーの AutoDiscoverServiceInternalUri 値 (SCP レコードの設定に使用するプロパティ値) が autodiscover.contoso.com を指すように構成することをお勧めします。スプリット ブレイン DNS が構成されていない場合、AutoDiscoverServiceInternalUri には、環境内の 2010 クライアント アクセス サーバーの負荷分散 VIP に解決される値を設定してください。

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

 

内部からの Outlook 接続

メールボックスが Exchange 2010 にあり、RPC/TCP 接続を使用している内部の Outlook クライアントは、Exchange 2010 RPC クライアント アクセス アレイ エンドポイント (存在すると仮定して) に接続します。ブログ記事 Exchange 2010 から Exchange 2013 への移行に与えるあいまいな URL の影響 (英語) で説明されているように、RPC クライアント アクセス アレイ エンドポイントの正しい構成が重要であることに注意してください。

Outlook Anywhere

  1. 赤ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、HTTP パケット内に埋め込まれた RPC データのカプセル化を解除し、ターゲットのメールボックス データベースがローカル サイトにあるため、必要なデータをローカルの Exchange 2010 メールボックス サーバーから取得します。
  2. 青ユーザーは、RPC プロキシ エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、HTTP パケット内に埋め込まれた RPC データのカプセル化を解除し、メールボックスをホストするメールボックス サーバーが別の AD サイト (この例ではサイト 3) にあると判断して、Outlook の RPC データをターゲットの Exchange 2010 クライアント アクセス サーバーにプロキシします。
  3. オレンジ ユーザーは、RPC プロキシ エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2010 は、HTTP パケット内に埋め込まれた RPC データのカプセル化を解除し、ターゲットのメールボックス データベースがローカル サイトにあるため、必要なデータをローカルの Exchange 2010 メールボックス サーバーから取得します。
注意: Outlook Anywhere クライアントは、メール接続、ディレクトリ接続に加えて、Exchange Web サービスとオフライン アドレス帳も利用できますが、これらの URL は自動検出応答によって提供されます。

Outlook Web App

詳細については、ブログ記事 Outlook Web App の Exchange 2010 へのアップグレード (英語) を参照してください。

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

Exchange ActiveSync

詳細については、ブログ記事 Exchange ActiveSync の Exchange 2010 へのアップグレード (英語) を参照してください。

  1. 赤ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 青ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断しますが、このサイトには ESA ExternalURL が含まれていません。サイト 1 の CAS2010 は、サイト 3 の CAS2010 にクロスサイト プロキシ要求を発行します。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  3. オレンジ ユーザーの場合は、次の 2 つのシナリオが考えられます。
    1. オレンジ ユーザーは、名前空間エンドポイントとして mail-region.contoso.com に接続します。サイト 2 の CAS2010 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
    2. オレンジ ユーザーは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 2 にあると判断しますが、このサイトには EAS ExternalURL が含まれています。デバイスが自動検出機能をサポートしており、かつ 451 リダイレクト応答をサポートするデバイスのリストにある場合、CAS2010 はデバイスに 451 応答を発行して、新しい名前空間 mail-region.contoso.com を使用する必要があることを通知します。その後、サイト 2 の CAS2010 が要求を処理し、Exchange 2007 メールボックス サーバーから必要なデータを取得します。デバイスがサポート リストにない場合、サイト 1 の CAS2010 はサイト 2 の CAS2010 に要求をプロキシします。

 

Exchange Web サービス

  1. 赤ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。サイト 1 の CAS2010 が要求を処理します。
  2. 青ユーザーの場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。次に CAS2010 は、サイト 3 にある Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。
  3. オレンジ ユーザーの場合、自動検出は Exchange Web サービスの URL として mail-region.contoso.com 名前空間を返します。サイト 2 の CAS2010 が要求を処理します。

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

以下の図では、Exchange Server 展開アシスタントで提供されているガイドに従って、サイト 1 に Exchange 2016 が展開されています。この結果、Outlook Anywhere は、このインフラストラクチャ内のすべてのクライアント アクセス サーバーで有効になっており、mail.contoso.com および autodiscover.contoso.com の名前空間は、Exchange 2016 クライアント アクセスのコンポーネント インフラストラクチャに解決されるように移動されています。

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

自動検出

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

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

内部からの Outlook 接続

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

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

重要: Exchange 2010 のネイティブ環境に Exchange 2016 を導入すると、MAPI/HTTP が既定で有効になります。Exchange 2016 にメールボックスを移動する前に、TCP443 経由で /mapi/* へのトラフィックが許可されるように、ロード バランサーまたはファイアウォール ルール、あるいはこれら両方を必ず設定してください。

 

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

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

 

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

Exchange 2010 のネイティブ環境で Exchange 2016 を導入すると、既定で MAPI/HTTP が有効になります。プロトコルがクライアントにサポートされていれば、Exchange 2016 にメールボックスを移動した後に、MAPI/HTTP が使用されるようにクライアントが再構成されます。クライアントが次回再起動されると、MAPI/HTTP が使用できるようになります。メールボックスを移動する前に、ファイアウォールおよびロード バランサーが正しく設定されていることを必ず確認してください。正しく設定されていないと接続できません。

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

メールボックスがレガシ バージョンの Exchange にある Outlook Anywhere クライアントからのアクセスをサポートするには、Exchange Server 展開アシスタントで説明されている手順に従って、環境にいくつかの変更を行う必要があります。具体的には、レガシ クライアント アクセス サーバーで Outlook Anywhere を有効にし、IIS 認証方法として基本認証に加えて NTLM も有効にする必要があります。

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

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

Outlook on the web

Outlook on the web のユーザー エクスペリエンスは、メールボックスのバージョンと場所によって異なります。

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

Exchange ActiveSync

Exchange ActiveSync クライアントのユーザー エクスペリエンスは、メールボックスのバージョンと場所によって異なります。また、Exchange 2016 では、451 リダイレクト応答をサポートしません。Exchange 2016 は ActiveSync 要求を常にプロキシします (リダイレクトが可能なハイブリッド シナリオ (英語) では例外です)。

  1. 赤ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の MBX2016 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスがローカルの AD サイト内にあると判断します。MBX2016 は要求を Exchange 2010 クライアント アクセス サーバーにプロキシし、このサーバーが Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫ユーザーの ActiveSync クライアントは、エンドポイントとして mail.contoso.com に接続します。サイト 1 の MBX2016 はローカル プロキシ要求を実行し、HTTP セッションを、データベースのアクティブ コピーをサイト 1 でホストする Mailbox 2016 サーバーにプロキシします。
  3. 青ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の MBX2016 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断します。サイト 1 の MBX2016 は、サイト 3 の CAS2010 にクロスサイト プロキシ要求を発行します。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  4. オレンジ ユーザーの場合は、デバイスの構成に応じて、次の 2 つのシナリオが考えられます。
    1. オレンジ ユーザーの ActiveSync クライアントが名前空間エンドポイントとして mail-region.contoso.com に接続するように構成されている場合。この場合、MBX2016 はまったく関与しません。新しく構成されるデバイスはすべて、mail-region.contoso.com を使用するように自動的に構成されます。
    2. オレンジ ユーザーの ActiveSync クライアントが名前空間エンドポイントとして mail.contoso.com に接続するように構成されている場合。サイト 1 の MBX2016 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスが別の AD サイト内にあると判断します。MBX2016 は、同じサイト内にメールボックスとして存在する Exchange 2010 クライアント アクセス サーバーにクロスサイト プロキシ要求を発行します。

Exchange Web サービス

Exchange Web サービスとの共存は比較的シンプルです。

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

オフライン アドレス帳

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

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

MBX2016 がターゲットのレガシ Exchange Server を選択する方法

MBX2016 がレガシ Exchange クライアント アクセス サーバーにプロキシする際、負荷分散された名前空間や InternalURL 値ではなく、サーバーの FQDN に基づいて URL を構築していることを理解するのは重要です。では MBX2016 は、接続をプロキシする先のレガシ クライアント アクセス サーバーをどのように選択しているのでしょうか。

MBX2016 は、起動すると Active Directory に接続し、トポロジ マップを列挙して、環境内に存在するすべてのクライアント アクセス サーバーを把握します。MBX2016 は、50 秒ごとに各プロトコル エンドポイントに対する簡易な要求をトポロジ マップ内のすべてのクライアント アクセス サーバーに送信します。この要求には、HttpProxy.ClientAccessServer2010Ping というユーザー エージェント文字列が含まれます。MBX2016 は応答を待ちます。一連の 200/300/400 応答は、ターゲット サーバーがそのプロトコルをサポートしていることを示し、502、503、504 応答はエラーを示します。エラー応答が発生した場合、MBX2016 は、直ちに再試行によってこれが一時的なエラーかどうかを判定します。2 回目の試行も失敗した場合、MBX2016 はターゲットの CAS をダウン状態とマークし、この CAS をプロキシ ターゲットから除外します。次の機会 (50 秒後) に、MBX2016 はダウン状態の CAS の正常性を判断して、使用可能かどうかを判定します。

レガシ クライアント アクセス サーバーの IIS ログには、これらの Ping イベントが含まれます。たとえば次のような場合です。

2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 302 0 0 277 170 02015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 309 177 152015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 245 170 02015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 301 0 0 213 169 1712015-08-11 14:00:01 W3SVC1 DF-C14-02 192.168.1.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 293 194 312015-08-11 14:00:04 W3SVC1 DF-C14-02 192.168.1.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 261 170 171

 

何らかの理由で、特定の CAS2010 をプロキシ エンドポイントから除外したい場合 (たとえば、メンテナンスのために除外する場合) は、次のコマンドレットを Exchange 2010 で実行します。

Set-ClientAccessServer <server> -IsOutofService $True

 

IMAP および POP の共存

ここまでは、HTTP ベースのクライアントについて説明してきましたが、このセクションでは POP クライアントと IMAP クライアントについて触れたいと思います。HTTP ベースのクライアント製品と同様に、IMAP クライアントと POP クライアントもまた、Exchange 2016 クライアント アクセス コンポーネントからターゲット サーバー (Exchange 2016 メールボックス サーバーまたはレガシ クライアント アクセス サーバー) にプロキシされます。ただし、ターゲットの IMAP/POP サービスには、正常性チェック機能がないという大きな違いがあります。

Exchange 2016 クライアント アクセス コンポーネントは、POP 要求または IMAP 要求を受け取ると、ユーザーの認証を行い、サービス検出を実行します。

ターゲットのメールボックスが Exchange 2010 の場合、MBX2016 は、メールボックスのサイト内の各 Exchange 2010 クライアント アクセス サーバーの POP または IMAP の InternalConnectionSettings プロパティ値を列挙します。そのため、InternalConnectionSettings は、サーバーの FQDN にマッピングし、負荷分散された名前空間にマッピングしないようにすることが重要です。

MBX2016 は、着信接続の構成に基づいてサーバーを選択し、要求をプロキシします。着信接続が暗号化チャネルに優先される場合、MBX2016 は、まず SSL プロキシ ターゲットを検索し、次に TLS を検索し、最後にプレーンテキストを検索します。着信接続がプレーンテキスト チャネルに優先される場合、MBX2016 は、まずプレーンテキスト プロキシ ターゲットを検索し、次に SSL を検索し、最後に TLS を検索します。

重要: Exchange 2016 メールボックス サーバーは、POP サービスまたは IMAP サービスが実際にターゲットのクライアント アクセス サーバー上で実行されているかどうかは検証しません。そのため、POP クライアントまたは IMAP クライアントが環境内にある場合、POP サービスまたは IMAP サービスが、すべてのレガシ クライアント アクセス サーバー上で実行されているようにすることが重要になります。

 

まとめ

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

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