Exchange Server

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 ※必要な全サーバーで実行する ...

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

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange Serverにおける承認済みドメインと組織内に存在できるメールドメインとの関係について質問を受けたので、まとめて書いてみようと思います。 Exchange Server 2007以降には「承認済みドメイン」という設定があり、ここでドメインを以下の三種類に区別して管理できます。 - 権限のあるドメイン - 内部の中継ドメイン - 外部の中継ドメイン 権限のあるドメイン 権限のあるドメインは簡単に言うと「このExchange組織でのみ管理しているメールドメイン」という感じです。ですので… - そのドメイン宛のメールは受け入れる - 宛先をActive Directoryフォレスト内から探す - 宛先が存在すればメールを配信する - **宛先が存在していなければNDRを生成する** という動作をします。特にNDRを生成するという点が重要です。Exchange組織が１つだけしかなくて、MXレコードもその組織をむいていて、連携するものも何も無い！って時にはこのモードでドメインを登録すればおしまいなので楽ですね。そうではない時には別のモードも必要になります。 内部の中継ドメイン 内部の中継ドメインは「このExchange組織内にもそのドメインのメールアドレスを持っている人もいるけど、このExchange組織以外にも同じメールドメインを使っているメールシステムがある」という時に使います。 - そのドメイン宛のメールは受け入れる - 宛先をActive Directoryフォレスト内から探す - 宛先が存在すればメールを配信する - **宛先が存在していなければ、外部に送信する** 要は、NDRを生成しないわけですね。そして、内部の中継ドメインを設定する場合には大抵専用のSMTPコネクタを作成して同じメールドメインを共有しているメールシステムに向けて送信する形になると思います。 ExchangeではNDRを生成しないわけなので、別のメールシステムできちんとNDRを生成してあげる必要があります。やってしまいがちなのは、メールドメインを共有している別システムでも同じような設定をしてしまい、どちらにも存在していないメールアドレスに関してメールがループしてしまう構成ミスですね。「どこでNDRを生成するのか」というのはきちんと抑えておく必要があります。 外部の中継ドメイン 外部の中継ドメインは「Exchange組織内ではこのメールドメインを持っているユーザーはいないけど、中継だけする」という時に設定します。 - そのドメイン宛のメールは受け入れる - 宛先をActive Directoryフォレスト内から**探さず**、そのまま外部に送信する いちいち中は見ないで、全部リレーするだけの設定です。 信頼済みドメインに設定していないドメインのメールアドレスを設定した場合 信頼済みドメインに設定していないドメインのメールアドレスでも、実はActive Directory内のユーザーに設定できちゃいます、その場合どのような挙動になるかというと、組織内部からの送信時にはそのユーザーに届いてしまいます。内部の中継ドメインでも、外部の中継ドメインでも、どこにもなにも書いてなくてもこの挙動です。 この挙動は私が確認する限りExchange Server 2000のころから一貫しています。 管理者がメールアドレスを設定している訳なので当たり前と言えば当たり前の気もしますが、まったく管理権限が無いドメインに関しても操作できてしまうのはちょっと気持ち悪い気もしますね。でも、まぁ、そうなっているのですから仕方がないです。この動きを前提に設計を行ってください。

今回はWindowsのクラスタ(MSFC(2008以降)、MSCS(2003より前))とMSDTCの関係について調べてみました。 MSDTCとは MSDTCは複数サーバーにまたがった処理を行う際に、不整合が起きないように複数サーバーの調整役を行ってくれるものです。特にデータベースが複数存在するときに全体の処理がきちんと終わったことを確認してから実際にデータ更新を反映させるような際に使われます。以下@ITの記事がイメージがわきやすいと思います。 - [第8回 テーブルアダプタでトランザクション － ＠IT](http://www.atmarkit.co.jp/fdotnet/vblab/vsdbprog_08/vsdbprog_08_03.html) - [第8回 テーブルアダプタでトランザクション － ＠IT](http://www.atmarkit.co.jp/fdotnet/vblab/vsdbprog_08/vsdbprog_08_04.html) サーバー管理屋さん的には動作するアプリケーションでMSDTCを利用するのであればきちんとMSDTCを動作させておいてあげる…という感じになります。特にSQL Serverをクラスタ化するような際にはきちんと考慮が必要ですね。(もちろんMSDTCを使わない処理しか行わないのであれば必要ないです。) Windows Server 2003(MSCS) - [The Microsoft support policy for the Microsoft Distributed Transaction Coordinator on clustered nodes](http://support.microsoft.com/kb/912374/en-us) The MSDTC is a cluster-aware application. You can configure the MSDTC as a clustered resource on clustered nodes. Microsoft only supports running the MSDTC on cluster nodes as a clustered resource. Microsoft does not support the MSDTC in a stand-alone configuration on cluster nodes. 上記では「MSDTCはクラスタ化可能な(cluster-aware)アプリケーションであり、クラスタノード上で構成されたクラスタ化されていないMSDTCはサポートしない」と書かれています。 ...

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 ...

Active Directoryを理解するためには、「パーティション」と「レプリケーションスコープ」の理解が欠かせません。簡単に解説してみたいと思います。 パーティション ActiveDirectoryのデータベースを保持しているのはドメインコントローラーです。そして、そのドメインコントローラーが持っているデータベースをより詳細に見ると、以下のように4つの大きなパーティションの種類があります。 パーティション名 格納されている情報 レプリケーションスコープ (複製範囲) Configuration Partition (構成パーティション) フォレスト、ドメインの構成情報 ActiveDirectory対応アプリケーションの構成情報 フォレストワイド Schema Partition (スキーマパーティション) ActiveDirectoryに存在するクラス、オブジェクトの設計情報 フォレストワイド Domain Partition (ドメインパーティション) ドメインに存在するオブジェクトの情報 ドメインワイド Application Partition (アプリケーションパーティション) ※2003から新規導入 ActiveDirectoryに情報を格納する用に設計されているアプリケーションの情報 色々 何かを操作するときに「この操作はどのパーティションに対しての操作なのか、情報はどこに保存されているのか」ということを意識できるようになるとActive Directoryのことがよくわかってきます。 特にアプリケーションパーティションを除く3つのパーティションは特に重要ですのでその用法含めてしっかり理解する必要があります。 具体的に見ていきましょう。 ADSIEdit 具体的にADの中を覗いていくためには、それ相応のツールが必要です。一番使えるのはADSIEditという、ADのデータベースを直接覗けるツールです。すべての情報が見え、すべての操作が行えるというある意味とても危険なツールです。 ADSIEditはSupport Toolsに含まれていますので、Support Toolsを導入しておきましょう。インストールCDやサービスパックCDにも含まれていますし、Webからダウンロードもできます。 - [ADSI Edit を使用した Active Directory 属性の編集](http://technet.microsoft.com/ja-jp/library/bb124152(EXCHG.65).aspx) - [Download details: Windows Server 2003 Service Pack 1 32-bit Support Tools](http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en) 起動方法としてはMMCを起動後、ADSIEditを組み込む方法もありますが、直接「ファイル名を指定して実行」から「adsiedit.msc」を起動してしまうのが楽だと思います。 このように起動すると、Domain, Configuration, Schemaの3つのパーティションに接続された状態でADSIEditが起動してきます。 以降の説明の中で"DC=test,DC=local"という記述が何度も出てきますが、これはこの画像を取得した環境のドメイン名(=フォレスト名)がtest.localであり、その名前が表れているものです。各自自分の環境の名前に読み替えてください。 Configuration Partition Configuration Partitionはその名の通り、構成情報が格納されています。Active Directory自身の構成情報や、Active Directory対応のアプリケーションの情報が入っています。 ...