長い時間がかかる…
原文の記事の投稿日: 2012 年 2 月 20 日 (月曜日)
Exchange Server 2010 Service Pack 2 用の更新プログラムのロールアップ 1 のリリースに関する先日の発表を受けて、大量の修正プログラムがリリースされました。このブログ投稿では、特にその中の 1 つについて説明すると共に、このような問題がどうやって発生し、それをどうやって修正しているかといった背景事情も少しお話したいと思います。
その修正プログラムとは、2556113 (英語) という気の利いた名前で呼ばれているもので、「It takes a long time for a user to download an OAB in an Exchange Server 2010 organization (ユーザーが Exchange Server 2010 組織で OAB をダウンロードするのに長い時間がかかる)」という表題が付いています。
このような表題が付いていると、皆さんは私たちが単にオフライン アドレス帳 (OAB) のダウンロードを「高速化」する方法を見つけたのだと思うかもしれません。OAB から一部のユーザーを、たとえば 4 階の経理部で働いている見ず知らずの人たちをランダムに削除して高速化を図ったのだろうとか、姓、勤務先所在地や電話番号のような不必要な情報を削除して、OAB に含まれる詳細情報を減らしたのだろうと考え始めるかもしれません。もしかすると、単純にインターネットの速度を向上させた可能性もあります。それはとてもたやすいことだからです。
実際は、そのようなことはしていません (ただし、インターネットの件についてはすばらしい効果がありそうなので、どのようなことができるか検討中です)。その代わり、Outlook が一番近くのクライアント アクセス サーバー (CAS) から OAB をダウンロードするように、あるロジックを追加しました。
「なぜ?」とおたずねでしょうか。いい質問です。その質問にはこうお答えします。「サポート技術情報の記事に書かれているように、"次のようなシナリオを考えてみてください"」。
- Microsoft Exchange Server 2010 組織に、低速ネットワークで接続された 2 つの Active Directory サイトがあります。
- 一方の Active Directory サイトには、Exchange Server 2010 クライアント アクセス サーバーと Exchange Server 2010 メールボックス サーバーがあります。
- もう一方の Active Directory サイトには Exchange Server 2010 クライアント アクセス サーバーがあり、ここに Office Outlook ユーザーを追加します。
- 他方の Active Directory サイトにメールボックスを持つこのユーザーが、Exchange オフライン アドレス帳 (OAB) をダウンロードしようとします。
このシナリオでは、OAB のダウンロードに長い時間がかかります。
そうです。でたらめではありません。本当にかかるのです。巨大な OAB を使用していると、とてもとても長い時間がかかることがあります。ただ、このシナリオはもう少し詳細を付け加えた方がいいでしょう。というのも率直に言って、皆さんが知っておく必要があると思われる情報が少しあるのと、CAS 以外に何もない AD サイトを使うのは多くの人にとってあまり賢明なやり方とは思えないからです。
そこで、代わりにもっと詳しい次のシナリオを考えてみてください。
- 中央集中型の展開を使用しています。メールボックスはすべて 1 か所に集約されています。
- ユーザーが訪れて作業をする小規模な場所がたくさんあります。
- これらの場所は、低速のネットワークで中央のサイトに接続されています。衛星通信、ISDN、PSTN、対流圏散乱通信 (英語)(以前に、この種の設備をお使いのお客様がおられました。すばらしいものでした。そう、嵐が来るまでは)、低品質の通信回線などが使われています。
- OAB が巨大です。大型です。小さくありません。どれでもお好きな定義を選んでください。気にかけるほど大きなサイズであると言えば十分でしょう。
- Outlook クライアントが OAB をダウンロードすると、OAB は中央のデータセンターから送られてきます。これは、あなたの隣に座っている人の Outlook クライアントでも、向こうの隅にいる変わり者の Outlook クライアントでも同じです。全員が「同じ」 OAB をダウンロードします。同じ低品質の通信回線経由なので、とても速度が遅くなります。
うまくいけば、全員が同じ帯域幅を奪い合いながら、作業もしようとしていることがわかるでしょう。OAB のダウンロードに使われる BITS クライアント テクノロジは優れているとはいえ、これではあまり役に立ちません。
そこで、リモートの各場所に CAS を追加します。実際、https://technet.microsoft.com/ja-jp/library/bb232155.aspx に説明がある図の推奨どおりにします。クライアント コンピューターが、必要な OAB をローカルの CAS からダウンロードするという考えです。たしかに、この考えはうまくいくように思えます。しかし、これまで Exchange はそのように機能していませんでした。つまり、2010 SP2 RU1 以前はそうなっていなかったのです。
それではどのように機能していたのか。そしてなぜここで TechNet の記述が嘘だったことを明かすのか。
最初の疑問に答えると、クライアントが OAB のダウンロードに使う URL は、自動検出サービスによってクライアントに提供されます。この自動検出コードが、ダウンロードする OAB の URL を「クライアント コンピューターがある」AD サイトからではなく、常に「メールボックスがある」AD サイトから選択していました。
2 番目の疑問については、まず TechNet が決して間違ってはいないということを理解する必要があります (UE にいる私の友人たち、たとえば Scott Schnoll などは、記事が正しくないことをほのめかすとむきになります)。単に、ある観点からは正確でない場合があるというだけのことです。2007 が設計されていた当時、元の PM 仕様書の一部だったときの TechNet には、この方法が詳細に記述されています。たぶん、このことは明かすべきではなかったのでしょうが、ええい、かまいません。記述されていたのです。それが実現しませんでした。物事が常に変化しているときに、2,000 万行を超えるコードから成るソフトウェア製品ではこうしたことが起こりがちです。通常、TechNet の記述に嘘はありません。まあ、それほどたくさんは。
どのように機能しているかという話に戻ります。少し考えてみてください。ここに 1GB の OAB があります。この OAB の複製を、ユーザーがいるリモートの遠く離れた AD サイトにある CAS に追加します。ところが、ユーザーがそれを使うことは決してありません (たしかに、ユーザーのメールボックスも同じ AD サイトにあれば話は別ですが、シナリオはそうではありませんね)。まったくひどい話ではありませんか。そのとおりだという皆さんの声が聞こえます。これを図にすると次のようになります。
Outlook は、クライアントの自動検出要求のために、クライアント コンピューターから一番近い CAS を使います (使うはずです。これについてはすぐ後で説明します)。しかし、CAS から返される OAB URL は、メールボックスと同じ AD サイトにある CAS の URL になります。したがって、OAB を AD サイト B に複製したとしても、クライアントは OAB を AD サイト A から取得します。
このため、たくさんの小規模サイトと途方もない大きさの OAB を抱える大手のお客様からは、この方法が役に立たず、ダウンロードによって WAN の帯域幅が使い果たされているという声をいただいています。では、この問題にどう対処したらよいでしょうか。実は、この問題を解決する方法はいくつかあります。付け加えておくと、この種の事柄を解決するというのは、私の仕事の楽しみの 1 つです。オタク心をくすぐるからです。
- お客様に OAB のサイズを縮小してもらう、WAN の速度を上げてもらう、リモート オフィスを近くに移動してもらうなど。どれもお客様に受け入れられる解決策ではありません。それでもお願いはしました。
- 同じ内容の OAB を大量に作成する。ユーザーごと、またはデータベースごとに、ユーザーがダウンロードする OAB を指定します。そして、リモートの場所でその OAB だけを利用できるようにします。これにより、自動検出はリモートの場所で提供できる URL だけを提供するようになります。この方法はうまくいくように見えますが、問題はサイト間を移動するユーザーです。その場合、ダウンロード時の低速ネットワークのホップが倍になります。残念ながら、この方法は却下です。
- メールボックスで同じことをする。メールボックスをリモートの場所に移動します。この方法ではメールボックスがあちこち移動することに加えて、管理と高可用性がとても複雑になり、結果的にコストが増加します。
- IP アドレスから AD サイトへの何らかのリバース マッピングを行う。たしか解決策として最初に計画したのがこの方法でしたが、実際のところは少々困難です。というのも、クライアントの接続元のサブネットをすべて Active Directory サイトとサービスに追加し、ユーザーがいる AD サイトをリバース エンジニアリングし、サイト リンクのコストを調べるといった種々の作業が必要になるからです。この方法は複雑で、NAT を使用している場合や、接続される可能性のあるすべてのサブネットを管理者が Active Directory サイトとサービスに追加していない場合はうまくいきません。
- DNS または自動検出 XML に「手を加え」て、クライアントには一元化された場所に接続していると思わせながら、実際はクライアントをローカルの IIS インスタンスに接続する。やはりこの方法も困難で、実装とサポートが込み入って面倒なうえに、私に言わせれば醜悪そのものです。
- それ以外の方法。他の方法がとても困難に思えたので、これを選択しました。
ここで、少し前の段落の「Outlook は、クライアントの自動検出要求のために、クライアント コンピューターから一番近い CAS を使います」という文にもう一度目を向けてください。すぐ後で説明すると述べた部分です。わざわざこの記述を振り返るのは、AutoDiscoverServiceSiteScope と呼ばれるもののためです。
AutoDiscoverServiceSiteScope は、Outlook クライアントが AD サイトを CAS にマッピングし、自動検出要求のためにクライアントの一番近くにある CAS を見つけられるようにする CAS の設定です。Outlook クライアントはこのマッピングを行うために、サービス接続ポイント (SCP) を見つけ出します。SCP は実際には自動検出サービスへのポインターです。
動作のしくみは次のとおりです。Outlook クライアントは起動すると、別名「AD」とも呼ばれる三角形へと向かい、Exchange セットアップによって配置されたすべての SCP を探します。そして (願わくば) SCP の一群を見つけます。各 SCP には Keywords 属性があります。これは Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB, …、を使って設定/変更/ときにはめちゃくちゃにされる属性です。Keywords 属性は、自動検出要求のために、その CAS がどの AD サイトを担当するかを指定する目的で使われます。
複数の SCP が見つかると、Outlook クライアントは Keywords 属性に格納された値を自分自身の AD サイト (これは Outlook クライアントの起動時や IP アドレスの変更時に、ローカル Netlogon サービスによって動的に更新されます) と比較して、使用可能な SCP のリストを作成します。
次に、Outlook クライアントは 1 つのリストを作成します。自身の AD サイトと一致するすべての SCP のリスト (Keywords 属性 = クライアントの AD サイト) か、それが 1 つもない場合は、すべての SCP をリストに入れます。これらが、Outlook クライアントの自動検出要求に使用できるサーバーとなります。
そして、Outlook クライアントはリスト (ちなみに、このリストはインストールの日付別に、常に同じ順序になります) の先頭から順に、ServiceBindingInformation 属性内に含まれる URI への接続を試みます。この属性は、自動検出サービス自体の場所です。その後、クライアントは XML をポストし、応答を受け取るなどして、万事めでたく処理が行われます。この自動検出サービスの処理の詳細については、こちらをご覧ください。
ここで興味深いのは、管理者がサイト スコープを正しく設定していれば (その方法は私たちが管理者に教えます)、この AutoDiscoverServiceSiteScope を利用して Outlook がクライアントの場所から一番近い CAS を見つけられるという点です。したがって、要求が届いてしまえば、どの CAS がクライアントの一番近くにあるかを見極める必要はまったくなくなります。要求が CAS に届くころには、既にその見極めがついているからです。
要求が CAS に届いたら、クライアントに返される設定が算出されますが、いつも 1 つ忘れられていることがあります。それは、ユーザーが必要としている OAB は、要求の実行対象になっている CAS のローカルにある可能性があるにもかかわらず、ユーザーにはいつもはるか遠くの CAS からの URL が提供されるということです。修正が必要なのはまさにこの部分です。
したがって、この問題の解決策は理論上は非常に単純であり、クライアントから一番近い CAS を見極める新しい方法を発明する必要はないということになります。ありがたいことに、きわめてうまく働くしくみが既に用意されているからです。
管理者が AutoDiscoverServiceSiteScope を正しく設定していることを前提とするなら、クライアントが自動検出のために接続する CAS こそ、クライアントから一番近い CAS ということになります。この前提が当てはまる場合、CAS は、自動検出 XML で返す内容を判断するときに、ユーザーが使用する OAB のコピーを自分自身が保持しているかどうかを確認するだけで済みます。コピーを保持している場合は、自分自身の OAB URL をそのまま提供します。ユーザーのメールボックスがある AD サイト内の CAS の URL ではありません。当然、ユーザーが必要とする OAB のコピーを CAS が保持していない場合は、以前の動作が優先される必要があります。つまり、CAS はメールボックスがある AD サイト内の CAS の OAB URL を返します。
したがって、基本的には全体図が次のように変わります。
WAN に対する負荷が大幅に減少していることがおわかりでしょう。WAN 経由でコピーが複製された後は、その場所にあるすべてのクライアントがローカルの CAS から OAB を取得するようになります。
この新しい動作を有効にするために必要な作業は 2 つだけです。CAS に SP2 RU1 を展開することと、AutoDiscoverServiceSiteScope パラメーターを正しく設定することです。
この記事がお役に立つことを願っています。皆さんの WAN がいつまでも長太パイプ (long fat pipe) (英語) でありますように。
Greg Taylor
プリンシパル プログラム マネージャー
Exchange カスタマー エクスペリエンス
これはローカライズされたブログ投稿です。原文の記事は、「It Takes a Long Time…」をご覧ください。