Exchange Server

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

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