CAS 配列オブジェクトの謎を解く - パート 1

原文の記事の投稿日: 2012 年 3 月 24 日 (土曜日)

2009 年のリリース以来、Exchange 2010 は非常に強い関心を集めてきました。Exchange 2010 への移行について、その準備をする目的でお客様とともに作業し、講習を実施した際に、いくつかのよくある誤解があることに気づきました。誤解の中の 1 つの傾向は、Client Access Server 配列オブジェクト、略して CAS 配列オブジェクトに関するものです。Microsoft 内部の配布グループで、私がこの傾向についてコメントしたとき、テクニカル ライターであり熱心なブロガーでもある Scott Schnoll (英語) が、私に執筆、いえキーを叩くことを勧めました。この結果がこの投稿です。

この投稿の目的は、CAS 配列オブジェクトの技術側面のすべてを説明することではありません。それについては、以前の Nagesh Magadev の投稿「Exploring Exchange 2010 RPC Client Access service (英語)」で見事に説明されています。

以下のリストは、CAS 配列オブジェクトについて多くの顧客が気づいていない、いくつかの事実です。この投稿では、CAS 配列オブジェクトの謎を解明します。パート 1 で最初の 3 つの項目について、パート 2 で残りの 3 つの項目について説明します。

1. CAS 配列オブジェクトはトラフィックを負荷分散しません
2. CAS 配列オブジェクトは、以下に対してサービスとして機能しません。Autodiscover、OWA、ECP、EWS、IMAP、POP、あるいは SMTP
3. CAS 配列オブジェクトの fqdn は、SSL 証明書の一部である必要はありません
4. CAS 配列オブジェクトは、外部クライアントでは DNS 経由で解決できません
5. CAS 配列オブジェクトは、Exchange 2010 メールボックス データベースを作成して、データベースにメールボックスを移動した後で、構成、または変更してはなりません
6. CAS 配列オブジェクトは、たとえ単一の複数役割サーバーまたは 1 つの CAS しかない場合でも、構成する必要があります。

混乱しましたか? そうかもしれません。これから、これらを 1 つずつ説明しますので、混乱をなくしてゆきましょう。この記事では、いくつかのサーバー名が出てきます。最初に、私のラボで使用しているサーバーを示します。

さあ、詳しく見ていきましょう。

1. CAS 配列オブジェクトはトラフィックを負荷分散しません

CAS 配列オブジェクトは負荷分散を行いません。CAS 配列オブジェクトは、Exchange 内で一部の機能を自動化する Active Directory オブジェクトというだけです。Exchange 2010 ドキュメントでは、CAS トラフィックを負荷分散するにはロード バランサー (LB) の使用が推奨されると、さまざまな箇所で述べています。CAS 配列オブジェクトが負荷分散を行わないとはどういう意味でしょうか。

ロード バランサーで実際にしていることは、CAS のプール間でトラフィックを分散することです。これを CAS の配列と呼ぶこともできます。しかし、これは CAS 配列オブジェクトそのものではありません。違いは微妙ですが、はっきりしています。そもそも、私たちが混同を防げるようにはっきり区別できる名前にしなかったのが混乱の原因かもしれません。

CAS 配列オブジェクトが存在する、主な理由、そしておそらく唯一の理由、(CAS 配列オブジェクトと) 同じ Active Directory サイトで自動的に作成された新しい Exchange 2010 メールボックス データベースの RpcClientAccessServer 属性を作成することです。

RpcClientAccessServer 属性は、プロファイル作成プロセス中に、Outlook クライアントに対して、プロファイルにどのサーバー名を含めるか指定します。それだけで、それ以上の不思議なことは起きません。CAS 配列オブジェクトを作成しても、それは Active Directory のオブジェクトというだけです。この時点では、負荷分散はまったく行われていません。

あとはあなたしだいです。以下のことができます。

• DNS で "A" レコードを作成できます。これにより、クライアント コンピューターはホスト名を IP アドレスとして解決できます。この IP アドレスは、おそらく内部クライアントからのみ到達可能な LB の仮想 IP (VIP) となります。この VIP が、Outlook またはその他の MAPI/RPC 対応のアプリケーションが Exchange 2010 メールボックス リソースにアクセスする目的で接続する先となります。
• 負荷分散ソリューションを構成して、VIP 経由でトラフィックを CAS サーバーのプールに渡すことができます。

CAS 自体は、負荷分散がされていることに気づきません。

New-ClientAccessArray コマンドレットを使用して CAS 配列オブジェクトを作成した後、または Get-ClientAccessArray コマンドレットを使用して既存の CAS 配列オブジェクトを表示した後で、表示される内容について混乱されるかもしれません。

ここで、私のラボで新しい CAS 配列オブジェクトを作成する例をお見せします。名前は CASArray-A、outlook.lab.local の FQDN、Active Directory サイトは Site-A です。

図 1: クライアント アクセス配列を作成する

まず、この FQDN と Name フィールドは一致しません。この名前は表示名で、表面的なものだからです。CAS 配列オブジェクトが使用される対象が分かれば、どのような名前を付けてもかまいません。FQDN は、DNS で次に作成する必要があるレコードです。これがないと、クライアントは、IP アドレスに解決して接続することができません。Active Directory サイトごとに 1 つの CAS 配列オブジェクトのみが使えるということに注意してください。

では、なぜ、作成の直後に Members プロパティが、2 つの CAS で作成されたのでしょうか。前に、この時点では負荷分散は行われていないと書きました。私が嘘をついたように見えるでしょうか。

率直に言うと、Members プロパティには少々紛らわしいところがあります。CAS 配列オブジェクトを作成する手順をまだよく読まれていない場合は、この段階で作業は完了と思われるかもしれません。CAS 配列オブジェクトを作成して、2 つの CAS が自動的に配列に参加したことを確認できます。一息つきに飲み物を探すか、オフィスを横切ってこの男 (英語) からクッキーをおすそわけしてもらいに行くかもしれません。でも、残念ながらこれで終わりではありません。

CAS 配列オブジェクトに Active Directory サイト Site-A を関連付けたことにより、コマンドレットは、登録されたすべてのクライアント アクセス サーバーを Site-A にあるものとして、Members 列にそれらを表示します。私は、顧客には、この列を潜在的 Members 列であると説明します。ここ Microsoft で PFE である、同僚の Kamal Abburi は、これをサイト CAS Members 列と呼ぶことを提案しています。これらはすべて同じ Active Directory サイト内にあることから、これらのクライアント アクセス サーバーを負荷分散ソリューションでノードとして追加できます。しかし、ロード バランサーが構成されるまで、負荷分散は行われません。

コマンドレットは、CAS があるサイトを、どのようにして知ったのでしょうか。よくぞ聞いてくれました。みんなの最高の友だち AdsiEdit.msc に登場いただき、魔法の豆を探しに、Active Directory の構成パーティションを堀り起こしてみましょう。

図 2: Exchange 2010 サーバーの msExchServerSite 属性には、サーバーがある Active Directory サイトが含まれる

各 Exchange Server は msExchServerSite 属性を持っています。これには、Exchange Server が属している Active Directory サイトが含まれます。ご想像のとおり、Exchange Server を新しいサイトに移動した場合、これは動的に更新されます。このとき、Microsoft Exchange Active Directory トポロジ サービスが実行され、いくつかの情報を更新します。AutoDiscoverSiteScope 属性 (Get/Set-ClientAccessServer の一部) は、動的に更新されません。サイト、サーバー、およびクライアントのレイアウトによっては、これが修正されるまで、Autodiscover の結果がとんでもないことになるかもしれません。

2. CAS 配列オブジェクトは、OWA、ECP、EWS、Autodiscover、IMAP、SMTP、または POP に対してサービスとして機能しません

ひとまず、CAS 配列オブジェクトが実際になにを行うかに戻りましょう。これは、Exchange 2010 メールボックス データベースの、RpcClientAccessServer 属性を設定します。次に、この属性は、(TCP 経由で) RPC を使用するとき、Outlook に接続先を知らせます。Outlook Anywhere (HTTPS) クライアントでは、"HTTP 上の RPC" プロキシからのトラフィックが、メールボックスに到達する目的で、クライアントの代わりに接続する場所を示します。

Outlook クライアントが、RPC (over TCP) を使用するとき、どのサービスに接続しようとするでしょうか。

最初に、Outlook は RPC エンドポイント マッパーと通信する目的で、TCP/135 で CAS 配列オブジェクトに接続します。目的は、以下の 2 つのサービスがリッスン状態の TCP ポートを検出することです。

1. Microsoft Exchange RPC クライアント アクセス (別名 MSExchangeRPC)
2. Microsoft Exchange アドレス帳 (別名 MSExchangeAB)

RPC (over TCP) モードについてはこれで完了です。

Outlook Anywhere (別名 RPC over HTTP) クライアントは、CAS 上の TCP/443 で RPC over HTTP プロキシ コンポーネントに接続します。これは、Outlook Anywhere 外部ホスト名、または Outlook プロファイルがプロキシ サーバーと呼ぶものを解決することで行います。

(関心のある方へのギーク的な蛇足ですが、Outlook は、なにも通知をせず自動的に、指定されたサーバー名に /rpc/rpcproxy.dll を追加します。これが実際に接続する先です。Outlook 2003 のころのように、これを入力することをユーザーに求めた場合は、かなりの人が、忘れたり、間違えたりするでしょう。)

図 3: Outlook 2003 で RPC プロキシ URL を指定する

トラフィックは、(動的に割り当てられた TCP ポートではなく) ハードコードされた一連のポート (TCP 6001、TCP 6002、および TCP 6004) を使用して、RPC over HTTP プロキシから適切な MAPI/RPC エンドポイントに転送されます。Outlook Anywhere 外部ホスト名は、CAS 配列オブジェクトとは意図的に異なる FQDN となっており、その理由は後述します。

また、クライアントは、Autodiscover、OAB ダウンロード、EWS、POP、または IMAP のようなサービスに HTTPS 接続を行うこともできます。しかし、これらのサービスは、仮想ディレクトリ URL または AutoDiscoverServiceInternalUri 値のような完全に異なる方法で定義されます。接続するサーバーと同じである可能性は高いですが、これらのいずれも RPC を使用していないことから、これらの追加のサービスは CAS 配列オブジェクトからはサービスとして機能しません。CAS 配列オブジェクトの FQDN は、その他のサービスの URL と同じ VIP を共有することがあります。しかし、分割 DNS が使用されている場合、CAS 配列オブジェクト FQDN を、その他のサービスの URL と別にすることを強く推奨します。このことについてはさらに後述します。

3. CAS 配列オブジェクトの FQDN は SSL 証明書名前リストの一部である必要はありません

これは、通常、直前の項の事柄が原因の、非常によくある誤解です。この記事の領域の SSL 証明書は、SSL 保護 HTTP セッションを確率するような場合にのみ使用されます。RPC (over TCP) は HTTP セッションではないことから、SSL では保護されません。したがって、CAS 配列オブジェクトの FQDN を SSL 証明書の件名リストに含める必要はありません。このことについて見てみましょう。

以下は、Exchange 2010 CAS 配列オブジェクトに接続された MAPI/RPC モードの Outlook 2010 です。

図 4: Exchange 2010 CAS への Outlook 2010 RPC (over TCP) 接続

1 つのディレクトリ、2 つのメール接続をしたことが確認できます。netstat 出力 (スクリーン ショットの手前のウィンドウ) では、コンピューターが CAS 配列オブジェクトに 1 つのエンドポイント マッパー接続 (TCP 135) をしたことを確認できます。また、このラボでそれぞれ MSExchangRPC および MSExchangeAB サービスに静的に割り当てられた TCP ポートを表す TCP 59531 と TCP 59532 への接続もされています。

サーバー側から、netstat –n –b コマンドを使用してリッスン中のサービスを表示できます。

図 5: RPC (over TCP) を使用するとき Outlook が接続する必要があるサービス

想定どおりに、どのサービスも (TCP 443 への) HTTP から接続されていないことが示されています。これが SSL 証明書上で CAS 配列オブジェクト FQDN を必要としない理由です。

SSL 証明書に CAS 配列 FQDN が必要という誤解は、以下のように HTTPS モードで Outlook が接続を表示する方法が原因となることがあります。

図 6: Outlook Anywhere の接続

今回は、スクリーン ショットが取得されたとき、Outlook 2010 が 2 つのメール接続と 1 つのパブリック フォルダー接続を行い、また HTTPS を使用していることを確認できます。Outlook 内からは、outlook.lab.local と E2K10-MLT-01.lab.local に接続されているかのように見えます。これはある意味で正しいのですが、しかし、また netstat を使用することで、実際には、TCP/443 (HTTPS) で webmail.lab.local にある RPC over HTTP プロキシに接続されていることを確認できます。Outlook は、常にそれ自体または RPC over HTTP プロキシ経由で、データについて、サーバーが最終的に接続されている先を表示します。netstat 経由で、3 つではなくなぜ 6 つの接続が表示されているか疑問にお思いでしょうか。これは、HTTP が半二重プロトコルであり、したがって Outlook 内部の各接続について RPC_DATA_IN および RPC_DATA_OUT チャンネルが確立されていることによります。

また、以下のようにお考えでしょうか。"ちょっと待って。Outlook 2007 および 2010 は、既定で RPC セッションを暗号化するはず。証明書に名前が必要なのでは?" 残念ながら違います。以下の暗号化設定は RPC 暗号を使用しており、SSL はまったく関係ありません。通信は、HTTPS 上ではなく、RPC 上で行われています。

図 7: RPC (over TCP) を使用するとき、Outlook は RPC 暗号化を使用して接続する

簡単ですね。CAS 配列オブジェクトが証明機関 (CA) に出会って、CA がこう言ったとします。 "おい、俺のこと必要としてるだろ! なあ、上等のワイルドカード証明書を安くしとくよ!" CAS 配列オブジェクトはただこう返事します。"ほっといてくれよ" そして、CA は、ピスタチオをたたき割るのにでも使います。これは、もちろん、私たちの推奨事項に従って、CAS 配列オブジェクトで、その他のサービス FQDN で使用しているものとは異なる FQDN を使用した場合です。これが理由でした。

この記事のパート 1 が、CAS 配列オブジェクトについてよくある誤解を解消する目的で、これまでのところお役に立てたでしょうか。CAS 配列オブジェクトの残りの 3 つのよくある誤解について説明する、パート 2 もご覧いただければ幸いです。

Brian Day
プレミア フィールド エンジニア、メッセージング

これはローカライズされたブログ投稿です。原文の記事は、「Demystifying the CAS Array Object - Part 1」をご覧ください。