Exchange Server 2010を複数サイトに展開するときに把握しておくべき挙動について

最近はメールシステムが大容量化、重要化したり、Exchange Serverがソフトレベルで標準でDR(Disaster Recovery = 災害対策)の仕組みを備えているなどの事情があり、DRサイトを構築する機会が増えてきました。また、やはり震災の影響も大きいですね、本格的にDRサイトを構築するのが当たり前の時代になってきたように思います。

Exchange Server 2003のころは標準でDRの仕組みを持たなかったり、Exchange Serverが存在するサイトのGCをOutlookが使いだしてしまうこともあってExchange Server専用のサイトを作成し、その中にExchangeとExchange用のGC(DC)を配置することが多かったのですが、ずいぶんと時代は変わったものです。

さて、Exchange Server 2010でDRサイトを構築するとなるとたいていの場合Exchange ServerをActive Directoryの複数サイトにまたがって構築することになります。そうするとシングルサイトで構成していたときにはあまり考えなくても良かった考慮点が色々と出てきます。

その中から今回は2点取り上げて記録しておきたいと思います。(最近質問されて調べたのでまとめておきます)

サイトをまたいだCAS ArrayとDAGの接続について

CASはMBXを配置するサイト内に必ず1つは必要です。またCAS Arrayはサイト内に1つしか作成できません。なので本番サイトとDRサイトにそれぞれ1つずつCAS Arrayが作成されるのはほぼ自動的に決まります。

一方、DAGに関しては、素直に設計するなら本番サイトとDRサイトにまたがって構築されることが多いだろうと思います。データもコピーしたいし、フェールオーバーしたいですし。

この時、Outlookの接続しているCASのサイトと、DAGのアクティブノードが別サイトになったときにどのような挙動になるでしょうか?DAGのみ問題が起きてフェールオーバーした場合やクライアントが意図せず別サイトにアクセスしているケース、本番サイトからDRサイトへの切り替え、切り戻しの際の一時的な状況等で発生する可能性がある状況です。

調べたところ以下の事が分かりました。Exchange 2010 SP2 RU3で挙動が変更になっています。

  • Exchange 2010 SP2RU2及びそれ以前
    • CASは自分の存在するサイト、DAGのアクティブサーバーの存在するサイトを意識しません。
    • クライアントはちゃんとアクセスできていれば、Autodiscoverの値が変わってても無視します。
    • 結果、CASとMBXの間がサイトまたぎのアクセスになってもそのままつながります。(つながっちゃいますの方が表現として正確かもしれません。)
  •  Exchange 2010 SP2RU3以降
    • DAGのプロパティーのAllowCrossSiteRPCClientAccessが使えるようになります。規定の値は$falseです。
    • AllowCrossSiteRPCClientAccessが$trueの場合(あえて設定変更した場合)以前のバージョンと同じ動きになります。
    • AllowCrossSiteRPCClientAccessが$falseの場合、CASは違うサイトのMBXへのアクセスに関してはクライアントに「サイト間違ってるよ。正しいCASArrayはあっち」と教えます。
    • クライアントは教えられたらきちんとプロファイルを更新します。

このことやこの周辺のことは以下のブログで解説されています。

RPC Client Access Cross-Site Connectivity Changes – Exchange Team Blog – Site Home – TechNet Blogs

サイトをまたいだOWAのアクセスについて

OWAとMBXの関係についても同様に考慮が必要です。OWAの場合にはユーザーがサイトをまたいでメールボックスを移動したとき等に一番効率的なOWAを伝える必要等も発生するのでその点からも確認が必要です。

こちらもSP2で挙動が変化できるようになっています。

OWAに関してはExchangeのバージョンまたぎの問題や、External URLが指定されている、されていない、IISの仮想ディレクトリの認証モードによって挙動が異なるなど様々な要因によって挙動が変化します。詳細は以下のブログで解説されているので確認してみてください。

OWA Cross-Site Silent Redirection in Exchange 2010 SP2 – Exchange Team Blog – Site Home – TechNet Blogs
私は単純化して以下のように理解しました。(はしょり過ぎかもしれませんが……)

  • CASは接続をProxyしてあげることも、リダイレクトしたうえでSSOを実現してあげることも、お気に入りを更新してほしいので手動で正しいリンク先にアクセスするように表示することもできる。(けっこう何でもできる)
  • 異なるサイトのCASに接続に来てしまっていたら同じサイトのCASに接続するように促してあげる。
  • 異なるサイトのCASの場合には手動で接続先を変更するのが面倒なひともいるのでリダイレクト+SSOを実現することがSP2からできるようになった。

 

いずれのケースもきちんとサイトまたぎの構成が考慮されていていい感じです。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

コメントを残す

メールアドレスが公開されることはありません。