Exchange Server

スライド作成、資料作成の際にVisioのステンシルがあると助かります。 以下みつけたいい感じのステンシルへのリンクを紹介します。他にも見つけたら追加しますね。他にもいいものを知っている方がいたら教えて下さい。 - [TechNet System Center 2012 R2 - Virtual Machine Manager (SCVMM) Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-7a5f1fcd) - [TechNet System Center 2012 R2 - Data Protection Manager (DPM) Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-Data-ef61aa5d) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) Infrastructure Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-44552676) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) Application Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-0608df9a) - [TechNet System Center 2012 R2-Operations Manager (SCOM) Network Monitoring Visio Stencil](http://gallery.technet.microsoft.com/System-Center-2012-R2-a159ebae) - [TechNet System Center 2012 R2 - Operations Manager (SCOM) APM Visio Stencils](http://gallery.technet.microsoft.com/System-Center-2012-R2-57f8418e) - [TechNet Windows Server 2012 Visio stencil](http://gallery.technet.microsoft.com/Windows-Server-2012-Visio-bcac9141) - [TechNet SCCM 2012 Visio Stencils](http://gallery.technet.microsoft.com/SCCM-2012-Visio-Stencils-166257b0) - [TechNet Hyper-V,SCVMM-Vision Stencil](http://gallery.technet.microsoft.com/Hyper-VSCVMM-Vision-Stencil-3dc18770) - [TechNet Windows Azure Pack & Windows Azure Visio Stencil](http://gallery.technet.microsoft.com/Windows-Azure-Pack-Windows-813d13a8) - [スクリプト Active Directory Visio Stencils 2013 - Directory Services Visio Stencils](http://gallery.technet.microsoft.com/scriptcenter/Active-Directory-Visio-136ad959) - [Visio Stencil 2013 : SharePoint - Lync - Exchange – Windows](http://gallery.technet.microsoft.com/office/Visio-Stencil-2013-1d09cb4d) - [Office Custom Lync Stencil](http://gallery.technet.microsoft.com/office/Custom-Lync-Stencil-f17a902f)

Exchange Team Blog日本語版の更新は2013年6月20日以降は行われない、というそっけない通知が出ていました。 - [http://blogs.technet.com/b/exchange_jp/archive/2013/06/07/3577368.aspx](http://blogs.technet.com/b/exchange_jp/archive/2013/06/07/3577368.aspx) すべてのことに当てはまりますが、翻訳するというのはかなり時間もコストもかかりますので、今後もますますこのような傾向は加速するものと思います。これまでもそうですが英語の重要性がますます高まっていきますね。

Exchange Server Teamブログにて予定表の直接予約設定が行われているメールボックスを見つけて無効化するスクリプトが公開されています。 - Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/09/use-exchange-web-services-and-powershell-to-discover-and-remove-direct-booking-settings.aspx これはとても素晴らしいスクリプトですね。有効に活用したいところです。 ところで、このブログの中で以下の部分が個人的に注目の箇所でした。 While the Direct Booking method for resource scheduling can indeed work on Exchange Server 2007/2010/2013, we strongly recommend that you disable Direct Booking for resource mailboxes and use the Resource Booking Attendant instead. 直接予約を使わないことを「強く推奨」しているとは知りませんでした。理由には納得ですしそうすべきと私も重います。ですが、実際の案件の中ではわざわざOutlookのレジストリを変更してまでして直接予約を有効にするケースがあります。なぜそんなことをするのかというとExchange Server 2003から使い続けているユーザーが2007, 2010に移行したタイミングで会議室予約時の挙動が変わってしまうのを良しとしない顧客がいるからです。 何かを「変更」するということを極端に嫌い、リスクを避け、変化を嫌い、何かあった時の責任を取りたくない…という気持ちはわからないでもないのですが、何に関しても「より良く改善していく」ということはやはり行うべきだし、ましてや製品を作っている側が「そうしてくれ」といっているようなことには従うべきだと思います。そうでなければ結局無駄なトラブルを招いたり、製品のメリットをきちんと最大限引き出すことができませんので。 というわけで、予定表の予約方法に関してはサーバーサイドで全部コントロールするようにすべきですね。 ...

Exchange team blogにてEWS(Exchange Web Service)を使ってパーソナルタグをつけるという話題がありました。 - Using Exchange Web Services to Apply a Personal Tag to a Custom Folder - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/20/using-exchange-web-services-to-apply-a-personal-tag-to-a-custom-folder.aspx Exchange Server 2013に移行する際に管理フォルダーを使っている場合にそれをどうやって移行するか、という話題もありますがEWSを使った場合にそれが「サポートされるのか」ということに言及しています。 答えは「サポートされる」だそうです。もちろんEWSを利用するコードのロジックは含まれないですが、ドキュメントとして公開されているEWSのAPIはサポートされるということです。 EWSを叩くだけでも「開発！」となってしまい拒否反応を起こす人や、そもそもコードをかけない人なども多いですがExchange(に限らないですが)を管理していてコードが書けないのでは相当管理工数に違いが出てしまいますので使うべきところでは積極的に使っていくべきだと私は考えます。

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 Onlineへの移行も進んでいるようですが、ハイブリッド構成などでExchange Onlineからオンプレミス方向へのメールボックス移行などの必要性も発生します。このあたりを調べる必要があったのでまとめて記録しておきます。 前提条件：まずきちんとハイブリッド構成にしておくこと まずはじめにきちんとハイブリッド構成にしておく必要があります。これには以下のExchange Server Deployment Assistant(ExDeploy)が便利です。 - Home - Exchange Deployment Assistant http://technet.microsoft.com/en-us/exdeploy2010/default(EXCHG.150).aspx 希望する構成と、いくつかの質問に答えるとなすべきことを教えてくれます。 メールボックス移動実施方法 メールボックスの移動方法に関しては以下のドキュメントが非常によくまとまっています。 - Exchange Hybrid Deployment – Moving Cloud-Based Mailboxes to the On-Premises Organization http://community.office365.com/en-us/wikis/exchange/566.aspx クラウドで作成されたアカウントとオンプレミスで作成された上でクラウドに移動したアカウントとでは違う手順になるので注意が必要です。 トラブル Exchange Onlineからオンプレミスへのメールボックス移行の際にいくつかの問題が発生するケースがあるようです。以下、検索してすぐにみつかったケースです。 - Error message when you try to use the New-MoveRequest cmdlet to move a mailbox from Exchange Online in Office 365 to the on-premises environment in a hybrid deployment: "Operation has timed out" http://support.microsoft.com/kb/2723127/en-us - Mailbox Move from cloud to on-premises issue: Relinquishing job because the mailbox is locked. The job will attempt to continue again after. What to do? - Email and calendar - Office 365 - Microsoft Office 365 Community http://community.office365.com/en-us/forums/158/t/84117.aspx ...

今回はメールボックス移行(移動)時のトランザクションログの生成量に関してです。 特に、Exchange Serverのバージョンアップ時には、大量のメールボックス移動が発生します。この中で移行先のメールボックスに関しては大量にメールボックス、メールアイテム等を書き込むことになりますのでメールボックスサイズ以上の量のトランザクションログが発生します。一方、移行元のメールボックス側にはトランザクションログは大量に発生するのでしょうか?しないのでしょうか? この問題は移行案件があるたびに、案件メンバーから質問もでますし、実はネット上の情報も混乱しています。さらに、実際の挙動も不思議な感じです。 確認できるネット上の情報 メールボックス データベースおよびログの容量の要因について: Exchange 2010 のヘルプ http://technet.microsoft.com/ja-jp/library/ee832796(v=exchg.141).aspx 移動元サーバーでログに記録されるのはレコードの削除で、ログの量は多くありませんが、移動先サーバーでは転送されたすべてのデータを最初にトランザクション ログに書き込む必要があります。 Exchange Server 2003 でのメールボックスの移動 http://support.microsoft.com/kb/821829/ja データを 1 GB 移動するたびに、移動元および移動先のサーバーに 1 GB のトランザクション ログが生成されます。トランザクション ログ ドライブに十分な空き容量があることを確認してください。 バージョンの違いはありますが、真逆のことが書かれています。 Exchange Server 2007から2010への移行テストでの実績 以下は特定の環境で簡単にテストしてみた結果です。 - 移行先発生量 100MB移行時 –> 約200MB程度 - 1GB移行時 –> 約1.5GB程度 - 移行元発生量 100MB移行時 –> 約2MB程度 - 1GB移行時 –> 約200MB程度 移行元にもそれなりの量のトランザクションログが生成されています。しかも、元々のメールボックス容量と比較して正比例の関係にもなっていません。 また、移行をトリガーとせずにトランザクションログが異常に大量生成されるようなバグも過去存在しています。 - An Exchange Server 2007 mailbox server randomly generates many transaction logs in an Exchange Server 2007 Service Pack 1 environment http://support.microsoft.com/kb/947014/en-us ...

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

しばらく前になりますが、Exchange Server 2003のパブリックフォルダの複製トラブル対応に使えるPublic Folder replication troubleshooterというWebベースのツールが公開されています。 Public Folder replication troubleshooter - Exchange Team Blog - Site Home - TechNet Blogsなぜこんな時期に今更Exchange Server 2003のパブリックフォルダの話が?という感じではありますが、結局のところExchange Server 2003から新しいバージョンに移行する……というケースがまだまだ多いのだろうと思われます。パブリックフォルダは無くなる、無くなると言われて機能拡張が2003のころからほぼされないままであるという現実とも無関係ではないだろうと思います。 Exchange Server 2007, 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では過去のバージョンから最新のバージョンまで一貫して「存在しないユーザー宛てのメールでも一度受け入れる。その後、ユーザーが存在しなければ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における承認済みドメインと組織内に存在できるメールドメインとの関係について質問を受けたので、まとめて書いてみようと思います。 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のころから一貫しています。 管理者がメールアドレスを設定している訳なので当たり前と言えば当たり前の気もしますが、まったく管理権限が無いドメインに関しても操作できてしまうのはちょっと気持ち悪い気もしますね。でも、まぁ、そうなっているのですから仕方がないです。この動きを前提に設計を行ってください。

空き時間情報とは 「空き時間情報」は各個人(各メールボックス)の予定表情報のうち、何時から何時に予定が入っているか等の「空き時間」の情報を抜き出したものです。主に会議出席依頼を作成中にメンバーの予定表を一括で参照する際に利用されます。各個人のメールボックスの予定表のデータそのものを参照するのとは別のロジックで取得されます。 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側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。