Exchange Server 2010におけるメッセージサイズ制限について

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 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の生成場所がかわりますが、「届かない」という事実には変化無いということが分かりました。 この挙動はコネクタおよびそこに付与する権限を変化させても行ってみましたが、全て同じ結果でした。 知っていれば何という事も無い話題ではありますが、知らないとかなり悩んでしまう挙動だと思います。皆さんもお気をつけ下さい。

September 25, 2012 · 1 min · 胡田昌彦

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を伝える必要等も発生するのでその点からも確認が必要です。 ...

September 3, 2012 · 1 min · 胡田昌彦

Exchange Server 2010(SP1)は規定の設定のままでは高負荷時にメール配送遅延が発生します。

今回は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 接続です。 ...

March 6, 2012 · 1 min · 胡田昌彦

Exchange Server 2010導入時にはCASが1台しかなくても例外なく極力早い段階でRPCClientAccessServerを設定するべきです

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にきちんと向きますが、それ以前のものは自動では変更されません。 ...

March 2, 2012 · 1 min · 胡田昌彦

空き時間情報の取得について

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 空き時間情報とは 「空き時間情報」は各個人(各メールボックス)の予定表情報のうち、何時から何時に予定が入っているか等の「空き時間」の情報を抜き出したものです。主に会議出席依頼を作成中にメンバーの予定表を一括で参照する際に利用されます。各個人のメールボックスの予定表のデータそのものを参照するのとは別のロジックで取得されます。 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 ...

February 9, 2012 · 1 min · 胡田昌彦