Exchange Server 2013

Operations Manager用のExchange Server 2013管理パックに含まれるレポートが動作せず、レポートを開始しようとすると「レポートを初期化できません。」というエラーが出てしまう事象が発生しました。色々と調査をして原因にたどり着きとりあえず回避はできたのですが、トラブルシューティング中にかなり紆余曲折してしまったので、「わかっている今ならこうやってすんなり対処できるはず」というものを同じような問題に遭遇する人や将来の自分のためにまとめておきます。 発生した事象 SCOM上のレポートにてExchange Server 2013関連のレポートを実行しようとすると、以下のエラーが出てしまいます。 日付: 2015/02/09 17:12:33 アプリケーション: Operations Manager アプリケーションのバージョン: 7.1.10226.0 重要度: エラー メッセージ: レポートを初期化できません。 System.ArgumentNullException: 値を Null にすることはできません。 パラメーター名: GroupList 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Reporting.Parameters.Controls.Monitoring.ReportMonitoringObjectXmlEditorBase.LoadValues(ReportParameterInfoCollection reportParameters) 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Reporting.Parameters.ReportParameterBlock.LoadValues() 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ReportForm.SetReportJob(Object sender, ConsoleJobEventArgs args) レポーティングサービスのWebサイトからの確認 SCOM上でのレポート実行では情報に乏しいので、実態であるレポーティングサービスのWebからも確認します。 同様にエラーになります。「ReportRules」が選択式にも関わらず、何も値が入っていないのが直接の原因であることがわかりました。 ほぼすべてのレポートで同様の状態になっており、問題の原因はリンクされているレポートで発生していることもわかりました。 様々なレポートのリンク先となっているレポートにて問題を確認します。 ReportRulesが選択式にも関わらず値が入っていないためにエラーになっているのは同じ状況です。 レポートのプロパティより、ReportRulesはクエリベースのパラメータであることがわかります。Webからは確認できないので、レポートビルダーにてレポートを開き確認していきます。 レポートビルダーでのレポート定義の確認 実際にレポートビルダーでレポートを開いて確認していくと、以下のようにデータソースへの接続ができずに失敗してしまいます。 なので、前準備として、一時的にData Warehouse Mainの接続設定を変更します。 もともとは以下のように「資格情報は必要ありません」となっています。 これを以下のように「レポートサーバーに保存され、セキュリティで保護された資格情報」に変更します。 ※この接続設定変更部分はあまりよくわからずに実行している点があります。実際にこれでレポートビルダー上で資格情報を要求され、うまく確認可能になるのですが、もう少し深い理解が必要だと感じています。 準備ができたので、レポートを開いていきます。 レポートのURLは、「Reporting Services構成マネージャー」から確認できますので、そこを開きます。 問題となっているパラメータの設定を確認します。 「Exchange2013_Report_GetRelatedRules」というデータセットから値を取得していることがわかりました。次は「Exchange2013_Report_GetRelatedRules」データセットを確認します。 ...

Exchange Server 2013になり、TCPコネクション数をOutlookがより沢山使うようになっています。 これはOutlookプロファイル上でサーバー名部分がユーザーメールボックスのGUIDとなり、特定サーバーを指すものではなくなったため、同一サーバー上であっても過去バージョンにおける別サーバーであるかのようにTCPセッションを使うようになったからだそうです。Outlook Anywhereを常に使うようになったため、HTTPS通信が多数発生します。 特に他人の予定表を参照するような動作の時に個別のTCPセッションとなるため、1クライアントから数十のTCPセッションが発生し、かなりの数のコネクションが保持されるようなことが容易に起こります。 オンプレミスでは問題にならないケースも多いですが、特にExchange Onlineの場合にはProxy経由で外部に出て行くことが多いためアクセスがそこに集中し、TCPコネクション数の論理的な限界に達することや、そこまで行かなくてもProxy上の制限に合致し、まともにOutlookが使えない、Webが閲覧できない等の障害が発生することが多いようです。 オンプレミスであればきちんとシステムの変更に関してきちんと計画、テストがなされるのが普通だと思いますが、Exchange Onlineの場合には勝手にアップグレードされてしまい、障害が起きたから切り戻す…ということも行えないため場合によっては致命的な状況に陥る可能性があります。対処法がProxyサーバーを増やす、グローバルIPを増やす…というようなものになってしまう場合、対処するまでの時間も非常に長くなってしまいます。みなさんも気をつけて下さい。

最近は知識はあっても実際に自分で手を動かすことはめっきり少なくなってしまったのですが、やっとExchange Server 2013の環境を構築してみました。特につまるところもなく構成出来たのですが、ECPで操作をしているとすぐにIEがクラッシュしてしまうという現象に見まわれました。環境は以下のとおりです。 - Windows Server 2013 - Exchange Server 2013 CU2 - Internet Explorer 10 おそらくこの組み合わせでは、何をしようとしてもすぐにクラッシュすると思います。 「Internet Explorer は動作を停止しました」と無慈悲なメッセージが…。 回避策を探したところ、以下のIEの累積パッチを適用することで現象が改善されることを確認しました。 - [http://download.microsoft.com/download/F/B/2/FB217F16-026B-499F-8F44-7D7ECFAA3B53/Windows8-RT-KB2761465-x64.msu](http://download.microsoft.com/download/F/B/2/FB217F16-026B-499F-8F44-7D7ECFAA3B53/Windows8-RT-KB2761465-x64.msu) - [[MS12-077] Internet Explorer 用の累積的なセキュリティ更新プログラム (2012 年 12 月 11 日)](http://support.microsoft.com/kb/2761465/ja) 具体的にどのhotfixがこの問題の修正なのかまでは確認していませんが、きちんと稼働するようになったので深くは追わないことにしました。

Exchange Team BlogにてExchangeのDAGのWitnessのみをWindows Azure上に配置するという話題が有りました。結論は「まだサポートされない」ということで残念ですが、将来的にサポートされるようになりそうな感じですね。 - [Database Availability Groups and Windows Azure - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx) DAGにかぎらずですが、きちんとスプリットブレイン状態を防ぎ、稼働しているマシンで稼働させ続けるためにはどうしても3拠点が必要になります。本文中では以下のように書かれています。 You need two well-connected datacenters, in which Exchange is deployed You need a third location that is connected via the network to the other two datacenters The third location needs to be isolated from network failures that affect the other two datacenters 過半数が稼働し通信できていないといけないので、例えば2拠点でDAGを組もうと思っても、結局Witnessをどちらに置くか、という話になり、Witnessが配置された方の拠点がだめになればDAGとしては停止してしまうわけです。で3拠点目があればその問題は解決するのですが、ネットワーク的に完全に分離されていて、安定しているような拠点でできれば地理的にも離れている…というような都合の良い拠点をすぐに用意するのは難しいわけです。そこでAzure上に配置可能ならかなりメリットが出てくる…という話なのですが、まだ無理なようですね。 今後に期待したい所です。

TMGが新規に購入できなくなり、マイクロソフトソリューションで固めていた顧客が今後のリバースプロキシに何を使うべきなのか迷っている現状がありますが、どうやらMS的にはIISを一つの選択肢に持ってくるようです。 - [Part 1: Reverse Proxy for Exchange Server 2013 using IIS ARR - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx) IISのARR(Application Request Routing)でリバースプロキシができますよ、ということだそうです。 ドメインに参加させる必要も無いということですし、Windows Server 2008以降のOSがあれば構成できるようですから、あまりコストをかけたくない場合や検証用途であればこれで十分にいけそうに思います。

Released: Exchange Server 2013 RTM Cumulative Update 2 - Exchange Team Blog - Site Home - TechNet Blogs 早速スキーマ拡張も含まれています。3ヶ月毎ってやっぱりサイクル早いですね。

前回の記事で見たように、Hyper-VクラスタのCSVに配置した仮想マシンはHA構成にするしか(サポートされる)選択肢がありません。 - [Hyper-Vクラスタの高可用性のオンオフと仮想ディスクの配置先の話。(高可用性にしないとCSVにディスクを配置できない) | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/06/12/hyper-v%e3%82%af%e3%83%a9%e3%82%b9%e3%82%bf%e3%81%ae%e9%ab%98%e5%8f%af%e7%94%a8%e6%80%a7%e3%81%ae%e3%82%aa%e3%83%b3%e3%82%aa%e3%83%95%e3%81%a8%e4%bb%ae%e6%83%b3%e3%83%87%e3%82%a3%e3%82%b9%e3%82%af/) きちんとCSVで共有するディスク領域と、個別のノードに配置するためのディスク領域を計算し、割り当ててあげればよいわけですが、個別に割り当てる…という話になるとどうしても容量に偏りが出たり、構成が複雑になったりなど少々気乗りしない感じです。全部HAにして良いのであればこういう苦労はしなくていいわけで、そういう構成が現実的に取れるのかどうか確認してみます。 まず、気になるのは製品自体でクラスタ構成を組むようなものです。 Hyper-VのHAとExchange Server 2010以降のDAGの組み合わせはExchange Server 2010 SP1以降ではサポートされるとのこと。 - [http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx](http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx) Exchange Server 2013もOKです。 Exchange サーバーの仮想マシン (データベース可用性グループつまり DAG の一部となっている Exchange メールボックス仮想マシンなど) は、移動されたりオフラインになったりしたときにディスクの状態を保存または復元しないように仮想マシンが構成されている限り、ホストベースのフェールオーバー クラスター化および移行テクノロジと組み合わせることが可能です。ハイパーバイザー レベルで発生するフェールオーバー動作はすべて、フェールオーバー先のノードで仮想マシンがアクティブになったときに、コールド ブートする必要があります。計画されたすべての移行は、シャットダウンしてコールド ブートするか、Hyper-V ライブ移行のような技術を利用したオンライン移行になる必要があります。仮想マシンのハイパーバイザー移行はハイパーバイザー ベンダーがサポートするため、ハイパーバイザー ベンダーが Exchange 仮想マシンの移行をテストしており、サポートすることを確認する必要があります。Microsoft は、これらの仮想マシンの Hyper-V ライブ移行をサポートしています。 Exchange 2013 の仮想化: Exchange 2013 Help http://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.150).aspx その他は、できるけれどもやる必要ある？やらないほうが良くない？という情報が見つかります。 - Hyper-V2.0のホストクラスタとゲストクラスタの共存は可能でしょうか [http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/](http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/) 今回改めて調べるまでは私も上記のような認識だったのですが、そこよりはサポートする方向に年月がたって傾いてきている印象です。 NLBはどうでしょうか？…と思って結構頑張って調べたのですが、ズバリ言及している情報を見つけることができませんでした。私は30分ほど検索して見つからない場合には「無い」ものとして扱うことにしており、それ以上探すことはしません。Googleさんのインデックス能力はそれだけ高いと思っています。 一応以下の記事では高可用性のVMにNBLを追加で構成することのメリットに言及しているので、「あり」ということのように受け取れます。 NLB の機能によってフェールオーバー クラスターのノードになっている VM では、VM のメンテナンス中でもワークロードで高可用性が実現されます。VM で更新やなんらかのメンテナンスが必要な場合は、その VM のワークロードを同じホストの別の VM に転送したり、すべてを別のホストに転送したりすることができます。 仮想化: Hyper-V と高可用性 http://technet.microsoft.com/ja-jp/magazine/hh127064.aspx 動作しない理由も特にないので、普通に動作するものと思われます。テストして確認してみようと思います。 ...

Exchange Server 2013を監視するためのSystem Center Operations Manager用の管理パックが公開されています。 - Released: Exchange Server 2013 Management Pack - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/15/released-exchange-server-2013-management-pack.aspx - MP Blog: Exchange 2013 Management Pack released - System Center: Operations Manager Engineering Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/momteam/archive/2013/05/14/exchange-2013-management-pack-released.aspx ダウンロードはこちらから行えます。 - Download Microsoft Exchange Server 2013 Management Pack from Official Microsoft Download Center http://www.microsoft.com/en-us/download/details.aspx?id=39039 今回の管理パックは監視コンセプトが以前とは変更され「ユーザーに対してどのような影響があるのか」という視点がより強くなるそうです。 - Lessons from the Datacenter: Managed Availability - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2012/09/21/lessons-from-the-datacenter-managed-availability.aspx ...

System Center Operations Manager用のExchange Server 2013 Management Packが公開されています。Exchange Server Blogの方にリンク先等載せておきました。 - [SCOM用のExchange Server 2013 Management Packが公開されています | Exchange Server Blog](http://ebi.dyndns.biz/exchange/2013/06/scom%e7%94%a8%e3%81%aeexchange-server-2013-management-pack%e3%81%8c%e5%85%ac%e9%96%8b%e3%81%95%e3%82%8c%e3%81%a6%e3%81%84%e3%81%be%e3%81%99/)

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCOM用のExchange Server 2013 Management Packが公開されています。 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/06/03/scom%E7%94%A8%E3%81%AEexchange-server-2013-management-pack%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82/)

以前からExchange guysの間では使うのが常識になっているExchangeのサイジングツールですが、そのExchange Server 2013版が出ています。しかもメールボックスサーバーに限定されていない、全ロール向けのものになっています。助かりますね。 - Released: Exchange 2013 Server Role Requirements Calculator - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/14/released-exchange-2013-server-role-requirements-calculator.aspx サイジングは適当に行ってしまうと後で困るわけですが、きちんとやろうと思ってもアーキテクチャを理解していないと出来ない難しいものです。 例えばメールボックスを格納するディスクのサイズを計算しようと思っても単純にユーザーが使う領域を人数分掛け算すれば良いわけではなく、削除済みアイテムの領域も必要だし、削除されたメールボックスが完全に消されるまでの領域も必要だし、検索のためのインデックスを格納する領域も必要だし、トランザクションログ領域も必要だし、バックアップに失敗してトランザクションログがクリアされない時のための余裕も必要だし、DAGのメンバが長期間停止した時の考慮も必要だし……と、言い出したらきりもなければ抜け漏れも出やすいわけです。それが開発チームからガイドラインが出て、必要なパラメータを入れると参考値を出してくれるわけですから使わない手はないですね。 最もこれがあればあとは何もいらないわけでは全くありませんけれどもね。 リンクはリンク集にも追加しておきました。

Load Generatorと並んでExchange Serverのパフォーマンステスト時にお世話になる定番ツールのJetstressのExchange Server 2013用が公開されています。 - [Download Jetstress 2013 from Official Microsoft Download Center](http://www.microsoft.com/en-us/download/details.aspx?id=36849) Load Generatorはクライアントの動きをシミュレートして結果的にCAS経由で負荷をかけるのに対して、Jetstressはデータベース(ESE、別名Jet)に対して直接負荷をかけることができるツールです。 パフォーマンステスト時にはLoad GeneratorおよびJetstressで負荷をかけつつ、パフォーマンスカウンターを取得しておき、それぞれのツールの結果レポートと合わせてパフォーマンスカウンターの値からシステムを評価します。結局パフォーマンスカウンタの意味や、システムとしての特性を理解しておかないと数値の判断が下せないので、このあたりはかなり経験や知識が必要になってきます。 さらに、パフォーマンステストは本番環境に実施することが推奨されていないため、テスト用に環境を組み、そこでストレスをかけて評価し、それを持って本番環境の構成の妥当性を証明する…あるいは必要があれば構成を変更するという形になる……のですが、実際にはレポートの値が変だったり、きちんと負荷がかけられなかったりで色々と苦労することになります。この辺りはかなり現場での実践的なノウハウ(あるいはバッドノウハウ)になってくるのであまり細かいことは書けないのですが「ツールがあるからそれを実行すればいいんだな。ふむふむ。」と思っていると痛い目をみることは間違いないでしょう…。 とはいえ、新バージョン。すんなりと動作して、きちんとパフォーマンス測定ができるといいなぁと期待します。期待はずれになりませんように…。

telnetport25.comにてExchange Server 2013テスト環境をWindows Server 2012上に構築する手順が順次公開されています。 - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 1: Active Directory Domain Controller O/S Install… — www.telnetport25.com](http://www.telnetport25.com/2013/01/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-1-active-directory-domain-controller-os-install/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 2: Active Directory Domain Controller: AD Installation… — www.telnetport25.com](http://www.telnetport25.com/2013/01/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-2-active-directory-domain-controller-ad-installation/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 3: Active Directory Domain Controller: CA Installation… — www.telnetport25.com](http://www.telnetport25.com/2013/01/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-3-active-directory-domain-controller-ca-installation/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 4: Provisioning your Exchange Servers… — www.telnetport25.com](http://www.telnetport25.com/2013/02/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-4-provisioning-your-exchange-servers/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 5: Installing your first Exchange 2013 Server… — www.telnetport25.com](http://www.telnetport25.com/2013/02/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-5-installing-your-first-exchange-2013-server/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 6: Configuring a DAG… — www.telnetport25.com](http://www.telnetport25.com/2013/03/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-6-configuring-a-dag/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 7: Setting up DAG Databases and SSL… — www.telnetport25.com](http://www.telnetport25.com/2013/03/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-7-setting-up-dag-databases-and-ssl/) - [Building an Exchange 2013 LAB Environment using Windows Server 2012 from scratch – Part 8: Users, Mailboxes, Distribution lists and Public Folders… — www.telnetport25.com](http://www.telnetport25.com/2013/03/building-an-exchange-2013-lab-environment-using-windows-server-2012-from-scratch-part-8-users-mailboxes-distribution-lists-and-public-folders/) かなり詳しく手順を記述してくれているので、テスト環境構築の際の参考になると思います。 ...

Exchange Server 2013のマルチテナント構成についての情報が以下で公開されています。 Exchange Server 2013 hosting solutions and guidance マルチテナントというのは1つのExchange組織のなかに複数の独立したグループを作成し、それぞれが独立して管理されるようにする方法のことです。テナント1つが1組織。それが複数入ってくるような構成ですね。テナント同士はインフラは共有するものの、利用上は別テナントが存在していることが全く意識されないようになります。例えばOffice 365のExcahnge Server Onlineは典型的なマルチテナント構成です。 「別にホスティング業者じゃないからマルチテナント構成のやり方なんて知ってても意味ないでしょ?」という感想を持たれるかもしれませんが、実はちょっと大きな組織になってくるとグループ会社同士でお互いの存在をある部分隠したい、という要望はよく出てきます。アドレス帳を分離したい、予定表の共有はあそことあそこは許可するけど、あそこには許可したくない…。 基本的にExchange Serverはフォレストに対して1つの組織ということでずっとやってきているのでマルチテナント構成にはできない時代も長く、むりやりやろうと思うとかなり変態的な設定になり、副作用も大きく、そもそもできないことも多かったのですが、Microsoft自身がマルチテナント構成のサービスを提供するようにもなっており、最近はかなりきちんとマルチテナント構成が組めるようになってきているようです。 お客さんからちょっと特殊な要望が出てきた時には、マルチテナント構成にするような方法が適用できる事があるかもしれません。頭の片隅にとめておくと良いと思います。

下記Exchange Teamブログで述べられている通り、Exchange Server 2013ではこれまでの不定期のSP, RUの提供ではなく定期的に年4回のCUの提供が行われるようになるそうです。 - [Servicing Exchange 2013 - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/02/08/servicing-exchange-2013.aspx) CUはcumulative updatesの略で、累積アップデートですね。主にExchange Onlineとオンプレミスとの同期を取るための戦略変更となるようです。バグフィックスと同時に機能アップがなされることになります。Office365では気がついたら機能追加されていたり、変更点がわからなかったり、オンプレミスとの機能差異が多すぎて混乱したり…などかなりひどい感じだったのでこの辺りが整理されてくるとありがたいです。 また、はっきり言ってここのところのExchange ServerのRUの品質は悪いものが多く、RU自体の適用に失敗したり、RUを当てると大きなトラブルが発生したり、RUが出てからもしっかりと様子を見てからでないといけない感じでした。その辺りが今回の変更で改善されることを期待します。 ただ、それにしても、CUのサポート期間は短すぎる気がします。リリースからたったの半年しかサポートされません。 Q: How long is a CU supported? A: A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1. しかも場合によってはADのスキーマ変更まで含まれるとのこと。 Q: Will AD schema changes be included in CU’s? ...

無くなる、無くなると言われながら何時までたっても無くならない(無くせない？)Exchange Serverのパブリックフォルダですが、Exchange Server 2013になって、今までのパブリックフォルダ専用のデータベースがなくなり、パブリックフォルダ用メールボックスにデータが格納されるようにデザイン変更されました。それにともなってパブリックフォルダの移行方法も今までのように「複製」設定をするわけではなくなっています。 具体的にはNew-PublicFolderMigrationRequestコマンドレットを使うわけですが、それ以前、以後に色々と手順が必要になります。 以下のTechnetの記事にその辺りの詳細があるので、移行の際には熟読の上、テストを十分にしてからの移行する必要があります。 - [Migrate Public Folders to Exchange 2013 From Exchange 2010 SP3: Exchange 2013 Help](http://technet.microsoft.com/en-us/library/jj150486.aspx) 以前からパブリックフォルダ周りはバグが多かったですが、今回はさらに大きなデザインチェンジも入ってますのでかなり注意して移行作業を進める必要があるだろうと思います。

Exchange Team BlogでExchange Server 2013のトランスポートサービスの構造と、トランスポートエージェントについての解説およびサンプルプログラムが公開されています。 - [How to write an Exchange 2013 transport agent - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/01/21/how-to-write-an-exchange-2013-transport-agent.aspx). トランスポートエージェントを書けばかなりのことがコントロールできるので、この拡張性の高さは魅力です。実質的にExchange Server 2010の時と同じことができるようですし、サンプルプログラムが公開されているのでかなりお手軽に実装できそうです。 ただし、どうしてもトランスポートエージェントを自作するとパフォーマンスの問題や「本当に全部のメールで大丈夫なのか」といった懸念が出てきてしまいその部分のテストをどのようにするか、ということが問題になってしまいます。私自身まだ確立したものは無いのですが、動作に関しては別途様々なパターン、文字コード、トランスファーエンコーディングのメールを送りつけてテストできるスクリプトを書いて問題の有無を確認するのが有効なように感じています。 ちょっと話題がそれてしまいましたが、トランスポートエージェントはある意味、お客の要望を叶える最後の砦ですので、しっかりと抑えておく必要があります。

以下の場所からExchange Server 2013のヘルプファイル(.chm)がダウンロード出来ます。残念ながら英語版ではありますが、手元にヘルプファイルがあると現場のエンジニアの皆さんは何かと便利だと思います。 Download Microsoft Exchange Server 2013 Help from Official Microsoft Download Center

Microsoft純正のExchange 2013のステンシルが公開されており、ダウンロード可能です。資料作成に便利ですね。 - [Office Visio Stencil for Exchange 2013](http://www.microsoft.com/en-us/download/details.aspx?id=36448)

MSExchange.orgにてExchange Server 2013の負荷分散についての記事が公開されていました。 Introducing Load Balancing in Exchange Server 2013 (Part 1) :: High Availability & Recovery :: Exchange 2013 Articles :: Articles & Tutorials :: MSExchange.org 要点は以下です。 - 2013のCASはただのReverse Proxyでありユーザーの存在するMailboxにトラフィックを届ける - OWAのレンダリングもCASではなくMBXで行う - OutlookからもMAPIではなくRPC over HTTPS - CASへのHTTPSだけ考えればいい - どのCASにパケットが到達しても問題無い。フォームベース認証の問題はHTTPのクッキーではなくSSLのセッションIDで解決されており、CAS毎に再認証は必要ない。 - CASはすべて同じ証明書を利用する。 - ハードウェアロードバランサーを使わず、DNSラウンドロビンでも冗長化が行える。 - ただし、DNSラウンドロビンには欠点もある。 きれいに負荷分散されず負荷は偏る。 - 何かCASにエラーが起きていてもアクセスし続ける。(これはNLBも同じ) - ハードウェアロードバランサーを使う場合でもExchange2010のようにレイヤー7ではなく、レイヤー4で負荷分散できれば十分。 - 1つのVIPでは特定のサービスだけの障害時でも全部のサービスの切り替えになってしまう。手間を掛けるならサービス毎にVIPを作成しサービス毎に振り分けることも考えられる。 Exchange Server2013は2010までに比べて随分とシンプルになりましたね。冗長化さえできてしまえば良い…というケースではDNSラウンドロビンでもそれを実現できるというのはなるべくコストを掛けたくないお客様にとっては随分と素敵な事に思えます。ハードウェアロードバランサーは安いものもあるとはいえ、やはり構成し、トラブルを解決し…というあたりでかなり手間がかかりますからね。