Exchange Server 2010

Exchange Server 2010のDAGのトランザクションログがDPM 2012でバックアップを実施しても消えない…という話を受けて、調査してみました。 調べた所以下のブログに非常に良い情報がありました。 - [Exchange 2010: Log Truncation and Checkpoint At Log Creation in a Database Availability Group - Tim McMichael - Site Home - TechNet Blogs](http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx) Exchange Server 2010 SP1以降挙動が変わっており、要点は以下とのことです。 - ログファイルを消しているのはバックアップソフトウェアではなくて、ExchangeのReplicationサービス - トランザクションログが作成されたタイミングのチェックポイントがログファイルに埋め込まれている - DAGのコピーノード毎にどこまでログの切り詰めをしていいか報告される - 一番わかい番号までログのきりつめを行えると判断されるが、実際には”checkpoint depth”の分だけは消さずに残しておく - 切り詰めされるのはきちんと増分バックアップされているファイルのみ - “Checkpoint at log creation time”はeseutil /ml <ログファイル名>”で確認できる 要は、きちんとバックアップが成功していても、チェックポイントとして100程度、実際のファイル数としてはそれ以上のログファイルが残っているのが正常だ、ということです。 今回の検証環境では200ファイル程度ログファイルが残っており、確かに最新のログと最古のログとでチェックポイントとして100の違いがありました。

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上に配置可能ならかなりメリットが出てくる…という話なのですが、まだ無理なようですね。 今後に期待したい所です。

前回の記事で見たように、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ブログJapanでSCOMへExchange Server 2010の管理パック導入後にOutlook Anywhere関連のアラートが出る場合のその除外方法が紹介されています。 Exchange 2010 管理パックで発生する HTTP 接続関連のアラートについて - Exchange ブログ JAPAN - Site Home - TechNet Blogs もちろん本当にOutlook Anywhereが構成されている環境でアラートが出てしまうならそれは本当に障害なのですが、Outlook Anywhereを意図的に構成していない場合には誤検知ということになります。なので、不必要なルールを無効化することになるのですが・・・。量が多いですね。 無効化するモニタの一覧 KHI: 自動検出による HTTP 接続 - RPC over HTTP エラー (ログオン) KHI: 自動検出による HTTP 接続 - アドレス帳エラー (NSPI) KHI: 自動検出による HTTP 接続 - アドレス帳エラー (ABREF) KHI: 自動検出による HTTP 接続 - 自動検出エラー KHI: 自動検出による HTTP 接続 - RPC クライアント アクセス エラー (接続) KHI: 自動検出による HTTP 接続 - RPC クライアント アクセス エラー (ログオン) KHI: 自動検出による HTTP 接続 - 予期しない例外 KHI: ローカル サーバーへの HTTP 接続 - RPC over HTTP が失敗しました (RpcProxy) KHI: ローカル サーバーへの HTTP 接続 - アドレス帳エラー (NSPI) KHI: ローカル サーバーへの HTTP 接続 - アドレス帳エラー (ABREF) KHI: ローカル サーバーへの HTTP 接続 - 予期しない例外 KHI: ローカル サーバーへの HTTP 接続 - RPC クライアント アクセス エラー (接続) KHI: ローカル サーバーへの HTTP 接続 - RPC クライアント アクセス エラー (ログオン) KHI: ローカル サーバーへの HTTP 接続 - 予期しない例外 KHI: Test-OutlookConnectivity (内部) コマンドレットを実行できませんでした。 KHI: ローカル サーバー上の Outlook のパフォーマンス障害 (RpcProxy) - RPC-over-HTTP を経由した Outlook 接続で接続問題が発生している可能性があります。 ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [Excahnge Server 2010管理パック導入後に不必要なHTTP接続関連アラートが出ないように構成する | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/11/excahnge-server-2010%E7%AE%A1%E7%90%86%E3%83%91%E3%83%83%E3%82%AF%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AB%E4%B8%8D%E5%BF%85%E8%A6%81%E3%81%AAhttp%E6%8E%A5%E7%B6%9A%E9%96%A2%E9%80%A3%E3%82%A2%E3%83%A9/)

待望のExchange Server 2010 SP3がリリースされています。 - [Download: Microsoft Exchange Server 2010 SP3 - Microsoft Download Center - Download Details](http://www.microsoft.com/ja-jp/download/details.aspx?id=36768) トピックは色々ありますが、目玉はなんといっても以下2点です。 - Exchange Server 2013との混在をサポート - Windows Server 2012上へのインストールをサポート これでやっと既存のExchange Server 2010組織に2013を追加して移行できる…！と思ったら、今度はExchange Server 2010との共存には2013側にCU1を適用しないと共存はサポートされず、2013のCU1は2013年の第1クオーターに出る予定…との事です。移行はまだお預けですね。 もうすぐExchange Server 2013に移行できるようになるわけですが、このように新しいOSをサポートしたり、新しいバージョンと共存できるようになったりと大きな変更が加わっていますので何らかの大きな問題が埋まっている可能性も高いと思われます。先行者として利益を得られるメリットもありますが、地雷を踏んで痛い目を見るリスクもありますので、その辺りは慎重に判断すべきと思います。個人的にはまだラボでのテストに留め、本番環境への適用は情報、事例が出揃うのを待つべきとおもいます。 Exchangeチームブログでも情報が出てますので確認してみて下さい。 - [Released: Exchange Server 2010 SP3 - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx)

MSExchange.orgにExchange Server 2010のテスト環境をWindows Azure上に構築する方法が公開されています。 - [Installing an Exchange 2010 Test Environment on Windows Azure (Part 1) :: Migration & Deployment :: Exchange 2010 Articles :: Articles & Tutorials :: MSExchange.org](http://www.msexchange.org/articles-tutorials/exchange-server-2010/migration-deployment/installing-exchange-2010-test-environment-windows-azure-part1.html) とは言っても、まだサポートされていないので、あくまでも自己責任でテスト用の環境を構築する形になります。 私自身はまだWindows Azureは試していないのですが、このStep by Stepを見る限りいくつかAzureの特徴を抑えておく必要があるようですね。とはいえ、かなり扱いやすそうにも思います。 最近はリソースをバカ食いするソフトウェアばかりになってしまってテスト環境を用意するだけでも大変です。メモリ4GB程度しか積んでいないPCなんかもう殆ど役に立ちませんしね。その点ではクラウドはかなり魅力的です。とは言え自腹で環境を借りるのも中々…。Azureには90日の無料期間があるようなのでどこかのタイミングで試そうとは思っています。

Exchange 2010を仮想化し役割を統合することについて以下で書かれています。(英語) - [Exchange Server and Active Directory Blog: Exchange 2010 Virtualization and Combining Server Roles ?](http://smtp25.blogspot.jp/2013/01/exchange-2010-virtualization-and.html) 要約は以下です。 - 仮想化によって様々な利益が得られる - HUB, CASを1台に、MBXを1台にというのがよく見られる構成だが、HUB, CAS, MBXを1台にまとめることができれば台数は半分に減らせる。**この構成はMicrosoftにサポートされている**。 [Announcing Enhanced Hardware Virtualization Support for Exchange 2010 - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx) ただし、この構成ではDAGはFailOverClusterを使っており、Fail Over Clusterが機能している状態でのNLBはサポート外なので、ハードウェアロードバランサーは必須になります。実際に私の知っているある程度大規模な顧客でも３つのロールを共存させた構成で正常に稼働しており、悪くない構成であると思います。 以下のExchange Teamのブログエントリではかなりこの構成をおすすめしています。 - [Robert’s Rules of Exchange: Multi-Role Servers - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx) HUB, CASが同居、MBXは別サーバーという構成はExchange Server 2007の時にはMBXを冗長化した上で他のロールと共存できなかったのでよくありましたが、2010以降では３ロール共存をまず検討してよさそうです。 ...

ExchangeブログJAPANにてExchange Server 2010のメール検索についての記事が公開されています。 Exchange 2010 でのメールの検索について - Exchange ブログ JAPAN - Site Home - TechNet Blogs 要は「日本語は扱いが難しいからちゃんと検索できないよ」という事ですね。Exchange Server 2003の時代にはインデックスを作成するかどうかを設定で決めることができました。当時の設計ガイドラインとしては - インデックスを作成すると検索が早い！でも、きちんとキーワードで検索できないケースも出てきてしまう。さらにインデックスを保持するためのディスク領域も必要になる。 - インデックスを作成しないと、検索に時間はかかるものの、文字列が存在すれが検索できないということはない。必ず検索できるようにするためにはインデックスは無効の方が良い。 というような感じでした。多くの顧客で「検索でヒットしないなんて許されないでしょ」ということでインデックスを作成していなかったものです。 ですが、Excahnge Server 2007以降では「インデックスを作成しない」という選択肢自体が存在しなくなってしまいました。英語など、単語の間にスペースが入る言語であれば「ヒットしない」ということは起きないので大容量化するメールボックスサイズを前にしてインデックスを作成しないなんていうのはありえない選択肢だったのでしょうけれども、日本人には厳しいところですね。 また、記事では「Outlook オンラインモード、および OWA でのメッセージの検索」となっており、Outlookキャッシュモードについての言及がありませんが、Outlookキャッシュモードではクライアントのローカル上で動作するWindows Searchを使って検索します。 Exchange キャッシュ モードでは、Outlook は Windows Search、Windows 7 に組み込まれたコンポーネントおよび Windows Vista を使用します。Windows Search は、コンテンツのインデックス処理を実行して、Outlook に検索機能を提供します。ローカル コンテンツのインデックス処理と検索サービスは、Exchange キャッシュ モードで実行している Outlook ユーザーに、より効率的に彼らのメールボックスを検索する方法を提供します。オフライン ストアで電子メールをインデックス処理することに加えて、Windows Search は、ファイル システムに存在する他のデータもインデックス処理します。Windows Search の詳細については、「Windows Search」を参照してください (このサイトは英語の場合があります)。 Exchange Search について: Exchange 2010 のヘルプ http://technet.microsoft.com/ja-jp/library/bb232132(EXCHG.141).aspx そして、もちろんWindows Searchであっても、きちんと検索できない問題があります。 IWordBreaker とファイル検索 - NyaRuRuが地球にいたころ ...

Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。

今回はExchange Server 2010の高負荷時の挙動についてです。特にシステム導入前にLoadGeneratorで実際にパフォーマンス試験を行うような場合に規定値のままでは問題が発生してしまいますので注意してください。 規定値から設定変更すべき項目 現時点(2012/03/05)ではExchange Server 2010 SP1導入時にはSet-TransportServerコマンド及びEdgeTransport.exe.configの値を変更すべきです。規定値のままで動作させた際に、制限値に到達し、問題が発生するケースが多数報告されています。具体的な設定変更すべき項目等をここに書きたいのですが、残念ながら業務上得た知識なので、公開されているもの以外はここに書けません。(他の皆さんはどうされているのでしょうかね・・・) ネット上に情報があるものとしては以下のものが確認できました。 - [Exchange 2010 SP1 Store Driver throttling | Thoughtsofanidlemind's Blog](http://thoughtsofanidlemind.wordpress.com/2010/12/07/exchange-2010-sp1-store-driver-throttling/) The new keys and their values are: - [メッセージ調整について](http://technet.microsoft.com/ja-jp/library/bb232205.aspx) Set-TransportServer MaxConcurrentMailboxDeliveries このパラメーターには、メッセージをメールボックスに配信するためにハブ トランスポート サーバーが同時に開くことができる配信スレッドの最大数を指定します。ハブ トランスポート サーバーのストア ドライバーは、メールボックス サーバーへのメッセージの配信とメールボックス サーバーからのメッセージの受け付けを行います。この制限は、Exchange 組織内のすべてのメールボックスへのメッセージの配信に適用されます。MaxConcurrentMailboxDeliveries パラメーターの既定値は 20 です。 Set-TransportServer MaxConcurrentMailboxSubmissions このパラメーターには、メールボックスからメッセージを受け付けるためにハブ トランスポート サーバーが同時に開くことができる配信スレッドの最大数を指定します。ハブ トランスポート サーバーのストア ドライバーは、メールボックス サーバーへのメッセージの配信とメールボックス サーバーからのメッセージの受け付けを行います。この制限は、Exchange 組織内のすべてのメールボックスからの新しいメッセージの受け付けに適用されます。MaxConcurrentMailboxSubmissions パラメーターの既定値は 20 です。 Set-TransportServer MaxConnectionRatePerMinute このパラメーターには、ハブ トランスポート サーバーまたはエッジ トランスポート サーバーに対して開くことができる新しい受信接続の最大数を指定します。これらの接続は、サーバーに存在する任意の受信コネクタに対して開かれます。MaxConnectionRatePerMinute パラメーターの既定値は 1 分あたり 1200 接続です。 ...

Exchange Serverでは過去のバージョンから最新のバージョンまで一貫して「存在しないユーザー宛てのメールでも一度受け入れる。その後、ユーザーが存在しなければNDRを生成し送信する」という動きになっています。ユーザーが存在しなければSMTPセッション中に「User Unknown」というような応答を返し、そもそもメールを受け入れない場合に比べるとExchange Serverのリソースを多く消費することになります。 もちろんこの挙動にも、どのアドレスでも受け入れることによって「存在するアドレスをspam業者に収集されない」という良い面がありますので、一概に悪いわけではありません。ただ、このあたりに関してもExchange Server 2010にはtarpit機能があり、連続してSMTP送信を行ってくるホストに対しては遅延させることができますし、セッション中に拒否したい…というシチュエーションも少なからずあるものと思います。 これをHUB上でどのようにできるのか、ということを調べてみました。以下手順です。 AntiSpam機能のインストール c d % s y s t e m d r i v e % / P r o g r a m F i l e s \ M i c r o s o f t \ E x c h a n g e S e r v e r \ V 1 4 \ S c r i p t s / i n s t a l l - A n t i s p a m A g e n t s . p s 1 R e s t a r t - S e r v i c e M S E x c h a n g e T r a n s p o r t ※必要な全サーバーで実行する ...

Exchange Server 2010におけるメッセージサイズ制限について調べる機会があったので、結果をまとめてブログに書いておこうと思います。 結論 最初に結論を書いておきます。 - グローバル設定で送信制限サイズと受信制限サイズを指定できるが、異なる値にしても事実上意味が無く小さい方の値で制限される。 - 受信サイズ制限と送信サイズ制限を違う値にしたければグローバル設定では大きな方の値を設定しておき、ユーザー個別のサイズ制限設定を行う必要がある。 - Outlook(MAPI)を使用したExchange組織内部からExchange組織外部への送信時にはエンコード前のファイル自体のサイズで制限されるかされないかが決定される。 - SMTPクライアントを使用したExchange組織外部への送信および、SMTPでの組織外部からの受信メールに関してはエンコード後のサイズで制限されるかされないかが決定される。 このあたりの挙動はExchange Server 2010に限らず、以前のバージョンのExchangeでも同じはずですが、今回Exchange Server 2010 SP2にてきちんとまとめて確認しました。 Exchange組織内部から外部への送信時の動作 検証のために、制限値をすべて統一しておきます。 エンコード前には制限サイズ以下で、エンコードすると制限サイズを超えるサイズのファイルを準備します。 ※ここではメール用の転送エンコードとして一般的なBase64エンコードを想定しています。Base64エンコードではおおよそ33%ほどファイルサイズが大きくなります。 このファイルを添付して組織内部のユーザーと組織外部のユーザーとに向けて、組織内部のOutlookより送信します。 結果、きちんと組織内部のユーザーと組織外部のユーザーにメールが届きます。tracking logには以下のように記録されます。 TotalBytesの部分が注目の箇所です。内部宛てに関しては7154949となっており、エンコード前のサイズが記録されている事が分かります。添付ファイルのサイズよりも若干大きいですが、これはメールの本文やヘッダ等を含んだサイズに鳴っているためです。この値は送信、受信制限値内ですので、メールが届くのは自然な動きです。 違和感があるのは外部宛てのメッセージのTotalBytesの部分です。9774551となっており、エンコード済みのサイズになっていることが分かります。そしてこれは送信メッセージ制限を超えています。ですが、送信できちゃいます。納得いかない面もありますが、内部宛て、外部宛ての両方を宛先に入れたようなケースで、内部ユーザーには届いたけど、外部ユーザーには届かなかった……というようにするのもおかしな話なので、このような動きになっているのかなと思います。 Exchange組織外部から内部への送信時の動作 同様に、Exchange組織外部から内部への送信時の動作も見てみます。Outlook Expressから直接Exchange Server 2010のHUBに対してSMTPを送信し、テストしました。 Outlookをつかって内部から外部へ送信できた添付ファイルを添付して送信したところ、SMTPセッション中にサイズ制限で拒否されるという結果となりました。 内部から外部には送信できるのにその逆はだめっていうのは若干腑に落ちないですが、エンコード済みであるので…ということで筋は通っていますね。 ちなみに、Outlook ExpressはEHLOではなく、HELOを使って送信しており、事前にサイズチェック等していないので、添付ファイルも含めてメールを全て送り終わったあとでExchange Serverによりサイズチェックが行われ、サイズ超過が伝えられる…という流れでした。 この場合、受信サイズ制限により制限されていますので、挙動を見るために、送信サイズ制限はそのままで、受信サイズ制限のみ大きくし、追加でテストを行いました。 結果、SMTPセッションが正常に完了したあと、MBXに送信する段階で送信サイズ制限により送信できず、配信不能メッセージが生成される結果となりました。 この時、TotalBytesは一貫して9771052であるので、確かに送信サイズ制限にはひっかかります。内部に取り込んでるんだし、デコード後の実ファイルサイズでコントロールしてもいいんじゃないかという気もしますが、こういう実装なんでしょうね。結果的に、送信サイズ制限と受信サイズ制限の値を変える事でDSNの生成場所がかわりますが、「届かない」という事実には変化無いということが分かりました。 この挙動はコネクタおよびそこに付与する権限を変化させても行ってみましたが、全て同じ結果でした。 知っていれば何という事も無い話題ではありますが、知らないとかなり悩んでしまう挙動だと思います。皆さんもお気をつけ下さい。

最近はメールシステムが大容量化、重要化したり、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私は単純化して以下のように理解しました。(はしょり過ぎかもしれませんが……) ...

CassArrayは必ず作成すべし Exchange Server 2010では、OutlookクライアントからのMAPIアクセスに対してCasへのアクセスポイントを集約するための仕組みとしてCasArrayが存在します。それをコントロールするRPCClientAccessServerという属性がデータベースに存在します。この動きを理解していないと思わぬ落とし穴にはまる可能性があります。 基本的にCasArrayは2台以上のCASサーバーがサイト内に存在している場合にOutlookの接続先を指定するもので、接続先を単一の名前にすることで冗長化することを可能にしています(冗長化の仕組み自体はCasArrayは提供しないので、別途HWロードバランサー、SWロードバランサー、NLBなどで冗長化の仕組みを構築する必要があります)。サイト内に1台しかCASサーバーが存在しない場合には特にCASArrayを作成する必然性はありません。・・・が、実はその場合でもCasArrayを作成しておいたほうが良いです。つまり、どんな場合でも例外なくCasArrayを作成しておき、そこに対して接続させるように構成すべきなのです。このことは以下のドキュメントにも明記されています。 - [RPC クライアント アクセスについて: Exchange 2010 のヘルプ](http://technet.microsoft.com/ja-JP/library/ee332317.aspx) **クライアント アクセス サーバー アレイは、組織内に 1 つのクライアント アクセス サーバーしかない場合でも作成することをお推めします。**クライアント アクセス サーバー アレイが作成されると、クライアントは、クライアント アクセス サーバーの完全修飾ドメイン名 (FQDN) に直接ではなく、クライアント アクセス サーバー アレイの仮想名によって接続します。1 つのクライアント アクセス サーバーを Active Directory サイト内部で置き換える必要があるか、2 つめのクライアント アクセス サーバーを追加する場合、クライアント上でプロファイル更新は必要ありません。 つまり、一度プロファイルが作成されてしまうとCASの実ノードへのアクセスがクライアントに記憶されてしまい、その後CasArrayを使う構成にしたりCasを切り替えたりする場合にプロファイルの更新がクライアント側で必要になってしまう危険性があるのです。サーバー側で管理者が操作するだけで変更できるならともかく、クライアント側で個別に作業が発生してしまうのは管理者にとって悪夢です。しかもそれが自動化しづらいものとなると・・・。事前の準備が肝心です。 構築時の注意点 構築時にはいくつか注意点があります。知っていないと思わぬ挙動に頭を悩ませることになる危険性があります。 まず新しくCasArrayを作成するのは簡単です。 - New-ClientAccessArray Name "CAS Array" Fqdn "casarray.test.local" Site "SiteName" これでおしまい…ではないことに注意が必要です。Cas Arrayが作成されても自動的にそれが使われるようにはならないのです。きちんとDatabaseに対してCassArrayを使用するように設定を行う必要があります。具体的にはMailboxDatabaseのRpcClientAccessServer属性をCassArrayのFQDNにする必要があります。 - Set-MailboxDatabase DB1 -RpcClientAccessServer "casarray.test.local" この指定を忘れていると「CasArrayを構成しているのにCASが1台落ちたらクライアントがつながらなくなってしまった」というトラブルが発生します。しかもその時に全部のクライアントが同じ挙動になるのではなく、正常に接続できるOutlookクライアントもあれば、正常に接続できないOutlookクライアントもある・・・という状況になってしまうはずです。なぜかというと、MailboxDatabaseのRpcClientAccessServer属性は以下のように決定、設定されるからです。 - サイト内にCasArrayが存在する場合 → CasArrayが設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居している場合 → サーバー自身が設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居していない場合 → サイト内のCASからランダムに選ばれ設定される つまり、CasArray作成前に先行的にMailboxDBが作成され、Outlookプロファイルが作成されるとそのクライアントはCASの実ノードに接続されてしまうのです。その後CasArrayの構成を正しくやり直すと、そのあとで作られたOutlookプロファイルはCasArrayにきちんと向きますが、それ以前のものは自動では変更されません。 ...

空き時間情報とは 「空き時間情報」は各個人(各メールボックス)の予定表情報のうち、何時から何時に予定が入っているか等の「空き時間」の情報を抜き出したものです。主に会議出席依頼を作成中にメンバーの予定表を一括で参照する際に利用されます。各個人のメールボックスの予定表のデータそのものを参照するのとは別のロジックで取得されます。 Outlookのバージョンと空き時間情報の取得方法 空き時間情報の取得方法、取得場所はOutlookのバージョンによって大きく異なります。 - ～Outlook2003 パブリックフォルダを使って空き時間情報を投稿、取得します。 - Outlook2007～ Exchange Server 2003までのバージョンに対してはパブリックフォルダを使って空き時間情報を投稿、取得します。 - Exchange Server 2007以降のバージョンに対しては可用性サービスから空き時間情報を取得します。 Outlook2003の時代(Exchange Server 2003の時代)にはパブリックフォルダから空き時間情報を取得する方法しか存在しなかったのでOutlook2003はどのバージョンのExchange Serverに接続しようとも(Exchange Server 2007, 2010であったとしても)常にパブリックフォルダに空き時間情報があるものとして動作します。Outlook2007以降は下位互換のためにパブリックフォルダに空き時間情報があるとして動作することもできますが、Exchange Server 2007以降に接続していると判断すれば可用性サービスを利用するモードに切り替わります。そのほうが色々と問題(※後述)が発生しないからです。 Exchange Serverのバージョンと空き時間情報の提供方法 Exchange Serverのバージョンによっても空き時間情報の提供方法は異なります。 - ～Exchange Server 2003 空き時間情報は管理グループに一番初めに作成されたパブリックフォルダストア内に自動的に格納場所が作成されます。便宜的に「提供方法」と書きましたが、Exchange Serverは場所を提供するだけで、後はOutlookクライアントが空き時間情報のアイテムを投稿、参照する形になります。パブリックフォルダ機能をユーザーに解放しない場合でも、システムが正常に動作するためにパブリックフォルダストアを削除することはできません。 → - Exchange Server 2007～ Outlook 2007以降のクライアントに対して可用性サービスを提供します。 可用性サービスはWebサービスです。 - Outlook 2003(以下)が存在する場合にはパブリックフォルダを作成し、空き時間情報の投稿、取得場所を提供することができます。Outlook 2007以降しか存在しない環境ではパブリックフォルダを作成しないことも選択できます。 空き時間情報の場所と動きの違い Exchange Server 2003, Outlook 2003の時代とExchange Server 2007, Outlook 2007以降とでは空き時間情報関連の動作が全くことなることがわかりました。これだけ大きな変化をさせたからには以前の方法には大きな問題があり、新しい方法ではそれが改善されているはずです。比較表がtechnetに記載されていますので以下に引用します。 空き時間コンポーネント Exchange 2003 で実行されている Outlook 2003 Exchange 2010 または Exchange 2007 で実行されている Outlook 2007 ...

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange Serverでは過去のバージョンから最新のバージョンまで一貫して「存在しないユーザー宛てのメールでも一度受け入れる。その後、ユーザーが存在しなければNDRを生成し送信する」という動きになっています。ユーザーが存在しなければSMTPセッション中に「User Unknown」というような応答を返し、そもそもメールを受け入れない場合に比べるとExchange Serverのリソースを多く消費することになります。 もちろんこの挙動にも、どのアドレスでも受け入れることによって「存在するアドレスをspam業者に収集されない」という良い面がありますので、一概に悪いわけではありません。ただ、このあたりに関してもExchange Server 2010にはtarpit機能があり、連続してSMTP送信を行ってくるホストに対しては遅延させることができますし、セッション中に拒否したい…というシチュエーションも少なからずあるものと思います。 これをHUB上でどのようにできるのか、ということを調べてみました。以下手順です。 AntiSpam機能のインストール c d % s y s t e m d r i v e % / P r o g r a m F i l e s \ M i c r o s o f t \ E x c h a n g e S e r v e r \ V 1 4 \ S c r i p t s / i n s t a l l - A n t i s p a m A g e n t s . p s 1 R e s t a r t - S e r v i c e M S E x c h a n g e T r a n s p o r t ※必要な全サーバーで実行する ...