CAS 配列オブジェクトの謎を解く - パート 2
原文の記事の投稿日: 2012 年 3 月 29 日 (木曜日)
またお会いできましたね! 「CAS 配列オブジェクトの謎を解く - パート 1」 では、Exchange Server 2010 の CAS 配列オブジェクトの謎を解く目的で、3 つの項目について説明しました。
- CAS 配列オブジェクトはトラフィックを負荷分散しません
- CAS 配列オブジェクトは、OWA、ECP、EWS、Autodiscover、IMAP、SMTP、または POP に対してサービスとして機能しません
- CAS 配列オブジェクトは SSL 証明書の一部である必要はありません
このパート 2 では、以下の 3 つの項目について説明します。CAS 配列オブジェクトのもやもやをきれいさっぱり解消して、既存の展開を修正し、将来の展開をより戦略的に計画するお手伝いをします。
- CAS 配列オブジェクトは、外部クライアントによる DNS 経由では解決できません
- CAS 配列オブジェクトは、Exchange Server 2010 メールボックス データベースを作成して、データベースにメールボックスを移動した後で、構成、または変更してはなりません
- CAS 配列オブジェクトは、たとえ単一の複数役割サーバーまたは 1 つの CAS サーバーしかない場合でも、構成する必要があります。
4. CAS 配列オブジェクトは、外部クライアントによる DNS 経由では解決できません
パート 1 で述べたとおり (少なくとも 2 回は述べました。それ以上は数えていません)、CAS アレイ オブジェクトの FQDN に、OWA、ECP、EWS、EAS、Autodiscover、Outlook Anywhere の外部ホスト名など、他のサービスで使用する FQDN と同じものを指定することはできません。
この主な理由は、Outlook Anywhere クライアントは、まず DNS 経由で CAS 配列オブジェクト FQDN を解決しようとするからです。こうすれば、わざわざ RPC (over TCP) 接続を行う必要があるか、または直接、HTTPS を試みるべきか確認できます。インターネットからイントラネットへの直接の RPC (over TCP) 接続を許可していますか? そうしていないことを願いますが、もしそうなら、「Exchange Risk and Health Assessment Program (英語)」レポートをご覧になるとお分かりのように重大な危険があります。クライアントが CAS 配列オブジェクト FQDN を問題なく解決できることにより、RPC (over TCP) 経由での最初の接続試行をした場合、クライアントが Outlook Anywhere プロキシ URL に対して HTTPS 接続を行うまで、長い時間がかかります。エンド ユーザーが、この時間を、サービスのパフォーマンス低下、あるいは停止と考えると、ヘルプ デスクへの連絡が増えることになります。
この状況を避けるには、内部 CAS 配列オブジェクト FQDN を、outlook.corp.contoso.com のような、内部 DNS に固有のものにするだけで済みます。その他の非 RPC (over TCP) のサービス URL は、分割 DNS 経由で、内部および外部的に mail.contoso.com のような名前を使用できます。
分割 DNS を使用されたことはおありでしょうか。一組の内部および外部 DNS サーバーが、たとえば contoso.com のような、同じ前方参照ゾーンの要求を処理することです。2 つの DNS インフラストラクチャは、相互から完全に分離されます。ゾーン転送はなく、相互を DNS フォワーダーとして使用することもありません。この構成により、内部ユーザーがホスト mail.contoso.com を、ロード バランサー VIP への内部 IP アドレス (たとえば、192.168.1.10) に解決するとき、内部 DNS インフラストラクチャを使用できます。一方で、外部ユーザーはそれを、たとえば境界ネットワークでインターネットに面する Forefront TMG/UAG インフラストラクチャを示すパブリック IP アドレスに解決できます。CAS 配列オブジェクト IP アドレスと、非 RPC (over TCP) のサービス URL (たとえば OWA、ECP、EWS) の内部 IP アドレスが同じロード バランサー VIP であることは非常によくあります。しかしこれらは、適切なサービス状態検知を行う目的で、異なる is alive チェックを使用できます。
DNS はワイルドカード応答に対してサービスしますか?
これまでに少なくとも 1 社の顧客で、実在しないホスト名に対して受信したすべてのクエリに対して、ワイルドカード レコードを使用している外部 DNS サーバーを見たことがあります。これは、実在しない SomeFunkyNameThatDoesNotExist.contoso.com への DNS 要求を送信したとき、DNS サーバーが常にその企業 Web サイトの IP アドレスを戻すということです。編者注: (ワイルドカード レコード自体は、インターネット標準規格の観点からはまったく問題ありません。詳細は、「RFC 1034 (英語)」の 4.3.3 項を参照してください。)
これにより、この企業の Outlook Anywhere クライアントは、常に CAS 配列オブジェクト FQDN を解決することができ、HTTPS に切り替える前に、まず RPC (over TCP) 接続を試行します。もしご自身の環境で、外部 DNS サーバー特定の前方参照ゾーンに対してワイルドカード応答を使用している場合、その前方参照ゾーンを Outlook Anywhere プロキシ URL に使わないようにすることを推奨します。
ここでちょっと寄り道です。負荷分散ソリューションで適切なサービス ヘルス モニターを構成することを忘れないでください。最良のサービス モニター結果を得るには、負荷分散ソリューションのベンダーにお問い合わせください。Exchange 2010 ソリューション テストに合格したロード バランサー ベンダーのリストと (Exchange 2010 に関する) 彼らの Web ページへのリンクについては、「Exchange Server 2010 Load Balancer Deployment (英語)」 を参照してください。これは、サポートされる負荷分散ベンダーの最終的なリストではありません。これは、単に、ソリューションのテストと支援について、Microsoft と、直接、関与したベンダーのリストです。
簡単で大ざっぱな例は、HTTPS サービスに基づく FQDN に、TCP/443 応答に対する is alive テストを実行することです。負荷分散ソリューションは、クライアント アクセス サーバーに対して新しいクライアント トラフィックを送信しなくなり、TCP/443 への応答が停止します。CAS 配列オブジェクト RPC (over TCP) サービス FQDN は、TCP/135 で RPC エンドポイント マッパーに is alive テストを行うことができます。また RPC クライアント アクセス サービスおよびアドレス帳サービス用に選択した 2 つの静的な TCP ポート (英語) も対象になります。これらの 3 つのポートのいずれかが特定のクライアント アクセス サーバーに対して応答しなくなった場合、負荷分散ソリューションは、すべてのポートが応答を再開するまで、RPC (over TCP) の CAS に新しいクライアント トラフィックを送信しません。静的な TCP ポートを構成していない場合 Exchange は起動時に各サービスの動的 TCP ポートを選択します。これにより、一部の負荷分散ソリューションでは、is alive テストを不可能でないとしても困難にします。
5. Exchange Server 2010 データベースの作成後に、CAS 配列オブジェクトを構成しないでください
皆さんは、しばしば、大急ぎで、メールボックス サーバーをインストールして、メールボックス データベースを作成し、Jetstress (英語) で記憶域ソリューション検証テストを開始しているかもしれません。少しスピードを緩めて、後でトラブルが起きないようにしてみましょう。メールボックス サーバーはしばしば最も重要なサーバーの役割とみなされていますが、玄関がくぎ付けして閉じられていれば、クライアント アクセス サーバーにより到達できず、役に立ちません。
CAS 配列オブジェクトが配置する前に、メールボックス データベースの作成を開始した場合、同じ Active Directory サイト内に任意のクライアント アクセス サーバーを確認できます。各データベースには、RpcClientAccessServer 属性が付けられています。
これは、正しい方法、つまり CAS 配列オブジェクトの FQDN を使用するという方法ではありません。
図 1: CAS 配列オブジェクトが作成された場合、メールボックス データベースの RpcClientAccessServer プロパティは CAS 配列オブジェクトの FQDN で設定されます。
これは以下のようになります。
図 2: CAS 配列オブジェクトが作成されていない場合、メールボックス データベースの RpcClientAccessServer プロパティは、クライアント アクセス サーバー FQDN で設定されます。
クライアント プロファイルは、以下のようになります。
図 3: CAS 配列オブジェクトが作成されていない場合、Outlook クライアントはクライアント アクセス サーバーの fqdn で構成されます。
クライアントは、以下のように接続します。
図 4: クライアントはクライアント アクセス サーバーの fqdn に接続する
これは一見、まったく問題ないように思われ、すべてがうまくいっているように見えますが、後述するトラブルの元となります。この構成で Exchange Server 2010 にメールボックスを移動した場合は、Outlook はユーザー プロファイルの "Server" フィールドで CAS 名を使用します。これは機能しますが、そのクライアント アクセス サーバーが使用できる間だけです。後日、使用中止して、別の名前のサーバーに交換されることもあります。それまでに、クライアント アクセス サーバーの負荷分散したプールを使用したくはないでしょうか。そう思うはずです!
もしかして、こう思われるかもしれません。"なるほどね。でもそんな日が来たら、CAS 配列オブジェクトを作成して、データベースで RpcClientAccessServer を修正しさえすれば問題ないんじゃないの。" それは、Exchange 2010 に移動したメールボックスについてのみ当てはまります。CAS 配列オブジェクトではなく、CAS 名を示すよう構成された既存の Outlook プロファイルを持つすべてのユーザーは引き続き CAS 名に接続します。CAS 配列オブジェクト FQDN を使用するようには自己更新されません。
プロファイルが自己更新されないのは、クライアントが CAS から ecWrongServer 応答を受信しないからです。この応答を受信しない理由は、すべての CAS が RPC (over TCP) 経由のすべてのメールボックス データベースの有効な接続ポイントであるからです。これにより、データ センター スイッチオーバー/フェールオーバー イベントの後も、クライアントは再構成されません。管理者がすべきことは、CAS 配列オブジェクト DNS レコードを CAS の残ったプールを指すように変えることだけです。現在、メールボックス プロファイルを修正する唯一の方法は、Outlook 内で、手動でプロファイルを修復することです。これは、GPO 経由で Office PRF ファイルを発行することにより行います (非ドメイン参加のコンピューターには使えません)。または、ユーザーのプロファイルで指定された CAS サーバーを使用中止して、エンドポイントを使用できないようにします。この最後の方法は、Outlook 2007 または Outlook 2010 で Autodiscover による完全なプロファイル修復を開始します。Outlook 2003 は、プロファイル修復または PRF ファイルでのみ修復できます。この記事の執筆時点では、Autodiscover は通常の Autodiscover プロセスの一部としてプロファイルを新しいサーバー名に更新しません。通常のプロセスでは、Outlook Anywhere 構成を更新して、OOF 管理、空き時間/取り込み中、受信トレイ ルール管理のようなその他の機能の EWS URL を検出します。
Boston-CASArray という名前の CAS 配列オブジェクトを使用する AD Site-A 内のデータベースから、Redmond-CASArray という名前の CAS 配列オブジェクトを使用する AD Site-B 内のデータベースにメールボックスを移動した場合を考えてみましょう。プロファイルは更新されず、サーバー名フィールドは Boston-CASArray FQDN のままになります。ソリューション ライフサイクル中に、配置換えにより別のサイトに移行するユーザー集団があるか、別のサイトに大規模な内部メールボックスの移動を行う場合、このことは覚えておいたほうがよいでしょう。CAS 配列オブジェクトを作成する前に、Exchange 2010 データベースを作成する場合、データベースにメールボックスを移動する前に、CAS 配列オブジェクトを使用するように、データベースの RpcClientAccessServer 属性を必ず修正する必要があります。
6. CAS 配列オブジェクトは、たとえ単一の複数役割サーバーまたは 1 つの CAS サーバーしかない場合でも、構成する必要があります。
前項目での説明について、ちょっと考えてみてください。クライアントは、後で追加した CAS 配列オブジェクトを使用するようには自己更新しません。CAS が 1 つしかない場合はどうでしょうか。それは関係ないと思われるかもしれません。その時点では確かに関係ないともいえますが、後で時間を節約し、いらいらしないように、今から準備しておきましょう。今から 1 年後に、その CAS を交換する必要がでてきたらどうでしょうか。クライアント プロファイルがすべて CAS 名を指していたら、何らかの停止や手作業なしにすっきり移行する方法はありません。新しい CAS を追加した後で、すでに説明した手段の 1 つで、そのプロファイルを修復する必要があります。既存の CAS の使用を止めて、同じホスト名で新しい CAS を導入する必要があります。これにはダウンタイムが必要となります。私はこれらの方法のどれも許容できません。
後でビジネス要件が変更され、クライアント アクセスで高可用性が必要になったらどうでしょうか。これは、2 番目の CAS と負荷分散ソリューションを追加することによってのみ実現できます。結局、すでに説明した手段の 1 つにより、全員のプロファイルを修復する必要があり、立ち往生することになります。繰り返しますが、私にはこれらの方法はどれも許容外です。
ここでご提案することは、最初から CAS 配列オブジェクトを作成することです。ロード バランサーがなく、1 つの CAS しかない場合は、どのようにするといいでしょうか。簡単です。通常と同じように、CAS 配列オブジェクトを構成します。名前、AD サイト、FQDN を指定して、次に DNS "A" レコードが、その時点で持っている多役割サーバー、または唯一の既存の CAS としての IP を示すようにします。これで将来の備えができました。単一の CAS または多役割サーバーを交換するときは、新しいサーバーを構築し、次に、DNS レコード IP アドレスを変更するだけです。中断なしにすべてが機能し続けます。後で高可用性を追加するとしましょう。負荷分散ソリューションを運用可能にして、負荷分散ソリューションの VIP を指すように CAS 配列オブジェクト DNS レコード IP アドレスを変更するだけです。簡単ですね。
この記事が、CAS 配列オブジェクトについての誤解を解き、最終的に、多くの人が適切に Exchange Server 2010 に移行できるようになることに役立てれば幸いです。
Brian Day
プレミア フィールド エンジニア、メッセージング
これはローカライズされたブログ投稿です。原文の記事は、「Demystifying the CAS Array Object - Part 2」をご覧ください。