Partager via

Exchange 2013 共存環境におけるクライアント接続

  • Article

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

 

この記事は、名前空間の計画、負荷分散の原則、クライアント接続、証明書計画について説明するシリーズの第 3 弾です。

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

現在の環境

図 1: Exchange 2007 と Exchange 2010 によるマルチサイト アーキテクチャ

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

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

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

自動検出

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

メモ : スプリット ブレイン DNS の使用を前提とした場合は、2007 および 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 クライアント アクセス アレイ エンドポイントの正しい構成が重要であることに注意してください。

メールボックスが Exchange 2007 にあり、RPC/TCP 接続を使用している内部の Outlook クライアントは、メールボックスをホストする Exchange 2007 メールボックス サーバーのインスタンスに直接接続します。

Outlook Anywhere

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

Outlook Web App

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

  1. 赤 ユーザー は、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 はユーザーを認証し、サービス検出を行い、メールボックスがローカルの AD サイト内にあると判断して、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  2. 紫 ユーザー は、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 はユーザーを認証し、サービス検出を行い、メールボックスが Exchange 2007 メールボックス サーバー上のローカルの AD サイト内にあると判断します。CAS2010 は、legacy.contoso.com へのシングル サインオン リダイレクトを自動的に開始します (ソースとターゲットで FBA が有効になっていると仮定します)。その後、CAS2007 が要求を処理し、Exchange 2007 メールボックス サーバーから必要なデータを取得します。
  3. 青 ユーザー は、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断しますが、このサイトには OWA ExternalURL が含まれていません。サイト 1 の CAS2010 は、サイト 3 の CAS2010 に要求をプロキシします。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  4. オレンジ ユーザー の場合は、このユーザーが入った名前空間と環境の構成に応じて、次の 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 はユーザーを認証し、サービス検出を行い、メールボックスが Exchange 2007 メールボックス サーバー上のローカルの AD サイト内にあると判断します。CAS2010 は要求を CAS2007 にプロキシします。
  3. 青 ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断しますが、このサイトには EAS ExternalURL が含まれていません。サイト 1 の CAS2010 は、サイト 3 の CAS2010 にクロスサイト プロキシ要求を発行します。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  4. オレンジ ユーザー の場合は、次の 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 として legacy.contoso.com 名前空間を返します。サイト 1 の CAS2007 が要求を処理します。
  4. オレンジ ユーザー の場合、自動検出は、Exchange Web サービスの URL として mail-region.contoso.com 名前空間を返します。サイト 2 の CAS2010 が要求を処理します。

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

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

図 2: マルチサイト アーキテクチャで Exchange 2007 および Exchange 2010 と共存する Exchange 2013

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

自動検出

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

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

内部からの Outlook 接続

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

メールボックスが Exchange 2007 にあり、RPC/TCP 接続を使用している内部の Outlook クライアントは、引き続き、メールボックスをホストする Exchange 2007 メールボックス サーバーのインスタンスに直接接続します。

Exchange 2013 メールボックスがある場合は、企業ネットワークの内部と外部のどちらでも Outlook Anywhere を使用することになります。Exchange 2013 メールボックスでは、RPC/TCP 接続は使用されなくなりました。

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

重要 : スプリット ブレイン DNS インフラストラクチャを使用している場合は、内部 Outlook Anywhere 設定と外部 Outlook Anywhere 設定の両方で同じ認証値を使用するか、Outlook Anywhere に対して企業ネットワークの内外で名前を切り替えて使用する必要があります。Outlook は外部設定より内部設定を優先しますが、両方に同じ名前空間が使用されているため、クライアントが内部か外部かにかかわらず、内部認証設定のみを使用します。

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

外部からの Outlook 接続

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

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

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

Outlook Web App

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

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

Exchange ActiveSync

Exchange ActiveSync クライアントのユーザー エクスペリエンスは、メールボックスのバージョンと場所によって異なります。また、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 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2007 であると判断します。CAS2013 はローカルの Exchange 2013 メールボックス サーバーに要求をプロキシします。Exchange 2013 メールボックス サーバーは、メールボックスのサイト内に存在する Exchange 2007 クライアント アクセス サーバーに要求を送信し、このサーバーが Exchange 2007 メールボックス サーバーからデータを取得します。
  3. 青 ユーザーの ActiveSync クライアントは、名前空間エンドポイントとして mail.contoso.com に接続します。サイト 1 の CAS2010 は、ユーザーを認証し、サービス検出を行い、メールボックスがサイト 3 にあると判断します。サイト 1 の CAS2013 は、サイト 3 の CAS2010 にクロスサイト プロキシ要求を発行します。サイト 3 の CAS2010 は、Exchange 2010 メールボックス サーバーから必要なデータを取得します。
  4. オレンジ ユーザー の場合は、デバイスの構成に応じて、次の 2 つのシナリオが考えられます。
    1. オレンジ ユーザーの ActiveSync クライアントが名前空間エンドポイントとして mail-region.contoso.com に接続するように構成されている場合。この場合、CAS2013 はまったく関与しません。新しく構成されるデバイスはすべて、mail-region.contoso.com を使用するように自動的に構成されます。
    2. オレンジ ユーザーの ActiveSync クライアントが名前空間エンドポイントとして mail.contoso.com に接続するように構成されている場合。サイト 1 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2010 で、メールボックスが別の AD サイト内にあると判断します。CAS2013 は、同じサイト内にメールボックスとして存在する Exchange 2010 クライアント アクセス サーバーにクロスサイト プロキシ要求を発行します。
メモ : サイト 3 に Exchange 2007 サーバーも置かれている場合を考えてみましょう。このシナリオでは、サイト 1 の CAS2013 はユーザーを認証し、サービス検出を行い、メールボックスのバージョンが 2007 で、メールボックスがサイト 3 にあると判断します。CAS2013 はローカルの Exchange 2013 メールボックス サーバーに要求をプロキシします。Exchange 2013 メールボックス サーバーは、メールボックスのサイト内に存在する Exchange 2007 クライアント アクセス サーバーに要求を送信し、このサーバーが Exchange 2007 メールボックス サーバーからデータを取得します。

Exchange Web サービス

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

  1. 赤 ユーザー の場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。次に CAS2013 は、ローカル サイト内の Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。
  2. 紫 ユーザー の場合、自動検出は、Exchange Web サービスの URL として legacy.contoso.com 名前空間を返します。
  3. 青 ユーザー の場合、自動検出は Exchange Web サービスの URL として mail.contoso.com 名前空間を返します。次に CAS2013 は、サイト 3 にある Exchange 2010 クライアント アクセス サーバーに要求をプロキシします。
  4. オレンジ ユーザー の場合、自動検出は、Exchange Web サービスの URL として mail-region.contoso.com 名前空間を返します。
メモ : サイト 3 に Exchange 2007 サーバーも置かれている場合を考えてみましょう。このシナリオでは、自動検出応答は Exchange サービスの URL に対して legacy.contoso.com 名前空間を返します。サイト 1 の CAS2007 は、メールボックスのサイト内に存在する Exchange 2007 クライアント アクセス サーバーに要求をプロキシし、このサーバーが Exchange 2007 メールボックス サーバーからデータを取得します。このため、Exchange 2007 が非インターネット用 Active Directory サイトに存在する限り、インターネット用 Active Directory サイトから Exchange 2007 を削除することはできません。

オフライン アドレス帳

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

  1. 赤 ユーザー の場合、自動検出は、オフライン アドレス帳の URL として mail.contoso.com 名前空間を返します。CAS2013 は、その後、このオフライン アドレス帳の Web 配布ポイントであるローカル サイト内のクライアント アクセス サーバーに要求をプロキシします。
  2. 紫 ユーザー の場合、自動検出は、オフライン アドレス帳の URL として legacy.contoso.com 名前空間を返します。
  3. 青 ユーザー の場合、自動検出は、オフライン アドレス帳の URL として mail.contoso.com 名前空間を返します。CAS2013 は、その後、このオフライン アドレス帳の Web 配布ポイントであるローカル サイト内のクライアント アクセス サーバーに要求をプロキシします。
  4. オレンジ ユーザー の場合、自動検出は、オフライン アドレス帳の URL として mail-region.contoso.com 名前空間を返します。

メモ : サイト 3 に Exchange 2007 サーバーも置かれている場合を考えてみましょう。このシナリオでは、自動検出応答はオフライン アドレス帳の URL に対して legacy.contoso.com 名前空間を返します。このため、Exchange 2007 が非インターネット用 Active Directory サイトに存在する限り、インターネット用 Active Directory サイトから Exchange 2007 を削除することはできません。

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

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

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

レガシ クライアント アクセス サーバーの IIS ログには、これらの Ping イベントが含まれます。以下に具体例を示します。

2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 302 0 0 277 170 02014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 309 177 152014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 245 170 02014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 301 0 0 213 169 1712014-03-11 14:00:01 W3SVC1 DF-C14-02 157.54.7.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 293 194 312014-03-11 14:00:04 W3SVC1 DF-C14-02 157.54.7.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 261 170 171

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

Set-ClientAccessServer <server> -IsOutofService $True

IMAP および POP の共存

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

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

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

  ターゲットのメールボックスが Exchange 2007 の場合、CAS2013 は、メールボックスのサイト内の各 Exchange 2007 クライアント アクセス サーバーのサーバー FQDN を列挙します。

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

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

まとめ

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

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

更新情報
       2014 年 3 月 14 日 : 「IMAP および POP の共存」セクションを追加