パブリック フォルダの複製のトラブルシュートについて

こんにちは、Exchange サポートチームの池田です。 Exchange 環境における、パブリック フォルダの複製の問題のトラブルシュート方法について紹介致します。 既に US の Exchange Team blog にて公開されておりますが、Exchange 環境でのパブリック フォルダの複製の問題に対する基本的なトラブルシュート方法が紹介されております。 Title: Public Folder replication troubleshooterURL  :  http://blogs.technet.com/b/exchange/archive/2012/11/12/public-folder-replication-troubleshooter.aspx 以下のリンクよりトラブルシュートのページに直接アクセスができます。 診断ログのレベルを上げたイベント ログの確認などをご自身で実施していただき、ステップバイステップで基本的なトラブルシュート方法が確認できます。 Title: Troubleshoot Public Folder Replication for Exchange Server 2003URL : http://support.microsoft.com/common/survey.aspx?scid=sw;en;3221&showpage=1 あくまで基本的なトラブルシュート方法となりますが、パブリック フォルダの複製に問題が発生した際には、参考にしてください。 以下、実行画面例となります。


Exchange 2010 環境にて、パブリック フォルダーのクォーター警告メッセージが配信されない

Exchange 2010 環境において、パブリック フォルダーのサイズ制限を設定することで、パブリック フォルダーの所有者に自動的にサイズ超過の警告メッセージを送付することが可能です。 Title: クォータ メッセージについてURL  : http://technet.microsoft.com/ja-jp/library/bb232173(v=exchg.141).aspx 警告が送付されるサイズ設定は、以下のコマンドの実行結果にある IssueWarningQuota の値から確認することが可能です。 また、新規作成したパブリック フォルダに対して以下のコマンドを実行した場合、UseDatabaseQuotaDefaults の値は True となっており、パブリック フォルダー データベースの [格納域の制限サイズ] の値が使用されることを示しております。 Get-PublicFolder -Identity <パブリック フォルダ名> | fl しかしながら、 該当パブリック フォルダのサイズが、[警告を表示するサイズ] 以上のサイズになったとしても、警告メッセージが所有者に対して送付されない現象が発生致します。警告メッセージを送付させるには、パブリック フォルダ新規作成後、以下のコマンドを実行し、UseDatabaseQuotaDefaults の値を一度設定する必要がございます ($Flase を設定し、個別の設定や、一度 $False を設定し、$True に戻す方法でも問題ございません)。 Set-PublicFolder -identity <パブリック フォルダ名> -UseDatabaseQuotaDefaults $True -現象の再現手順1. 新規にパブリック フォルダを作成します。2. 以下のコマンドを実行し、ユーザーに所有者の権限を付与します。 Add-PublicFolderClientPermission -identity <パブリック フォルダ名> -User <ユーザー名>…


Exchange サーバーのアドレス帳表示について

Exchange  サーバーでは、どのアドレス帳 (ここではグローバル アドレス一覧も含めます) に表示されるかどうかは、当該オブジェクト (ユーザー、グループ、連絡先等) の showInAddressBook 属性によって決定されます。この属性値については、ADSIEdit や ldifde などで直接確認いただくこともできますが、Exchange 2007 以降では以下のように Get-Mailbox の AddressListMembership というプロパティでも確認することができます。  例: この例では、user01 は “既定のグローバル アドレス一覧”、”すべての会議室”、そして “すべてのユーザー” に表示されることになります。  この、どのアドレス帳へ表示するかの仕組み自体は、Exchange 2003、2007、そして 2010 でも同様となりますが、showInAddressBook を更新する動作については Exchange 2007 から変更されています。Exchange 2003 までは、受信者更新サービス (Recipient Update Service: RUS) で指定されたサーバーにて、常時、または指定した間隔で更新する動作でした。(処理自体は System Attendant サービスが行っています)  例: 以下では、E2k3-1-A というサーバーが RUS を担っている状況です。   Exchange 2007 以降では、このサービスとしての RUS の動作は廃止されました。Exchange 2007 以降では、各オブジェクトの各種プロパティを変更するための管理コマンドレット…


Exchange 2010 でのメールの検索について

Exchange 2010 環境において、Outlook オンラインモード、および OWA でのメッセージの検索は、既定では Exchange Search によるインデックスを使用した検索が行われます。 Microsoft Search では、検索対象のアイテムの文字列を日本語のワードブレーカーによって解析し、リストを作成します。アイテムを検索する際には、このワード リストにある単語に対して完全一致か、前方一致による検索が行われます。例として、”警告通知メール” という文字列が “警告/通知/メール” のようにワードブレークされたとします。この場合、「警」 という文字で検索した場合、前方一致により 「警告」 に合致しますが、「告」 で検索した場合、前方一致での検索に該当しないため、該当メッセージが検索結果に表示されません。 ワードブレークによるアイテムの文字列のワード リスト作成、及び検索する文字列の文章解析においては、文章内の句読点や文字の並びにより、抽出されるワードが異なることがあり、ワードの前後の文章などにも影響を受けるため、ワード抽出の固定的な法則はございません。なお、このワードブレークにより、氏名による検索において意図した結果にならない例として 「西村」、「山部」、「新名」、「大場」、「三谷」、「森村」 といった報告がございました。 Exchange 2010 SP1 以降の検索について Exchange 2010 SP1 以降では、パフォーマンスの改善のために、既定では前方一致での検索が行われません。上記の例において、OWA にて 「警」 という文字を検索文字として入力したとしても、「警告」 に合致しません。 前方一致による検索を行うには、検索文字の後にアスタリスク (*) を付与して検索することで、前方一致による検索が可能となります (例: 警*)。 Title: How to Use AQS to Construct Complex Discovery QueriesURL  : http://blogs.technet.com/b/exchangesearch/archive/2012/03/10/how-to-use-aqs-to-construct-complex-discovery-queries.aspx なお、OWA 検索時の既定の動作として、前方一致による検索を行わせるには、以下の手順で設定ファイルを変更します。…


Exchange 2007/2010 環境において予定表の重複予約が発生する現象について

Exchange 2007 以降ではカレンダー アシスタントを使用した予定表の予約を自動承諾する機能があり、同じ時間帯の会議出席依頼をリソース メールボックスが受信すると重複予約を避けるために予約がキャンセルされるように設定することが出来ます。Get-MailboxCalendarSettings / Get-CalendarProcessing コマンドの AutomateProcessing パラメータが “AutoAccept” に設定されている場合は、カレンダー アシスタントを使用した自動承諾が有効です。 この度、カレンダー アシスタントの自動承諾が有効となっている場合でも、特定の条件下で重複予約が承諾される問題が確認されました。重複予約は以下の条件下で発生します。 (1) 終日の予定を作成(2) (1) と重なる期間に 0 時から始まる、あるいは 0 時までの定期的な予定を作成 (2) の定期的な予定が (1) の終日の予定と重複していたとしても、この定期的な予定は承諾されます。以下、本現象の例を画面ショットにてご案内させていただきます。 ・11/13 に終日の予定をリソース メールボックス room01 に登録します 条件 (1) が完了しましたので、続いて条件 (2) の定期的な予定を作成します。条件 (2) の “終日の予定直前、あるいは直後を含む” とは、この場合、以下のいずれかを含む定期的な予定になります。 ・11/13 0:00 で終了する予定・11/14 0:00 から開始する予定 今回は 11/13 0:00 で終了する予定として、以下の定期的な予定を作成します。 開始時間: 23:00終了時間: 00:00繰り返し期間: 11/12, 11/13…


Outlook の動作履歴について

Exchange サーバーの提供する Autodiscover や Web サービスへのアクセスについてトラブルシュートする際に有効なOutlook の動作履歴をご紹介いたします。Outlook の動作履歴は一般的に Outlook のトラブルシュートの際に取得しますが、Autodiscover や Web サービスへのアクセスのトラブルシュートについても有効です。 取得方法 Outlook を起動して、[ファイル]-[オプション]-[詳細設定] から [その他] に記載の [トラブル シューティングを記録する] にチェックを入れて OK をクリックします。Outlook を再起動後、現象を再現します。ログは、%TEMP% に出力されますが、今回、Autodiscover や Web サービスについては以下のファイルとフォルダが対象となります。    olkas フォルダ   outlook logging フォルダ   olkdisc.log それでは、各ログについてご紹介します。 olkdisc.log こちらは、Autodiscover に関するログとなります。いくつか例を見てみます。以下は最もシンプルなログとなりますが、最初の autodiscover.example.local へのアクセスで成功している状態です (この例ではクライアントはワークグループ環境となっているため、最初に autodiscover.<SMTP ドメイン> へのアクセスを行っています)。 Thread Tick Count Date/Time Description1064 1022611843 11/02/12 14:44:44 Autodiscover…


リンクされたメールボックスを使用している場合の空き時間情報の参照権限について

こんにちは、Exchange サポートチームの和山です。今回は、リンクされたメールボックスを使用している場合に発生する、空き時間情報の参照時の制限事項についてご紹介します。 予定表を他の複数のユーザーと共有する場合、グループに対して “参照者” や “空き時間情報” などのアクセス許可を割り当てることがあるかと思います。この時、グループのメンバーがリンクされたメールボックスであった場合、以下のような動作となります。 <”参照者” 以上の権限の場合>グループに割り当てられたアクセス許可を使用して予定表にアクセスします。* ただし、空き時間情報の取得操作に関しては “既定” のアクセス許可を使用して実施されます。 <“空き時間情報” または “空き時間情報、件名、場所” 権限の場合>”既定” のアクセス許可を使用して予定表にアクセスします。 グループに対して “空き時間情報” または “空き時間情報、件名、場所” のアクセス許可が割り当てられている場合、通常のメールボックスであればグループに割り当てられたアクセス許可を使用します。しかしリンクされたメールボックスの場合、空き時間情報に特化した上記 2 つのアクセス許可についてはグループに割り当てられたアクセス許可ではなく、”既定” のアクセス許可を使用します。この動作については、現在のところリンクされたメールボックスを使用した場合の制限事項となっていますため、ご利用いただく際はご注意ください。 リンクされたメールボックスから空き時間情報を取得できるようにするための回避策としては以下の 2 つの方法があります。1. グループではなく、”既定” に対してアクセス許可を付与する。2. グループではなく、リンクされたメールボックス個人に対してアクセス許可を付与する。   – 2013/08/19 Update -先日リリースされた Exchange Server 2010 SP3 RU2 において、この動作の修正が行われ、リンクされたメールボックスをご利用の場合も空き時間情報を取得可能となりました。対応手順は以下の通りです。 1. Exchange 2010 に Exchange Server 2010 SP3 RU2 を適用します。2. CAS サーバーの下記フォルダにある web.config…


Outlook からの Web サービスへのアクセスについて

Exchange 2007/2010 環境下では Outlook は Autodiscover によってExchange サーバが提供する Web サービスにアクセスします。Autodiscover そのものについては既に Exchange 2007 からの機能になりますためご存じの方も多いかと存じますが、以下の資料等をご参考ください。    White Paper: Exchange 2007 Autodiscover Service   http://technet.microsoft.com/en-us/library/bb332063(v=exchg.80).aspx    Understanding the Autodiscover Service   http://technet.microsoft.com/en-us/library/bb124251.aspx Autodiscover や Web サービスのアクセス自体は通常の HTTP(S) 通信となりますため、Web のプロキシ サーバーを利用するよう構成している環境では、これらのリクエストが Exchange のクライアント アクセス サーバーへ送られるよう、適切にプロキシやその除外設定を構成する必要がございます。Outlook が参照するプロキシ設定につきましては [インターネットのプロパティ]  の [接続]-[LAN の設定] となります。 なお、適切にプロキシが設定がされていない場合には Exchange の Web サービスを利用することができないため、オフライン アドレス帳が同期できない、不在時の自動応答の設定時にエラーが発生するなどの可能性があります。また、リクエストが意図せずプロキシ サーバーへ送られるため、Outlook を起動すると認証ダイアログが表示されるといった現象として現れることもあります。 もし…


Exchange 2010 での自動転送ルールの挙動について

今回は Exchange Server 2010 で変更された自動転送ルールの挙動についてご紹介いたします。 Exchange Server 環境では以下の仕分けルール (Exchange Server 2010 では “受信トレイのルール” と呼ばれます) を利用することで、条件に合致したメールを受信した際に指定した宛先に自動的に転送させることができます。    ・<名前/添付リスト> へ転送する   ・添付して <名前/配布リスト> に転送する このような仕分けルールにおいて、Exchange Server 2003 や Exchange Server 2007 では転送する宛先に関して特に制限は設けられておりませんでした。そのため、以下のように 2 人のユーザーが互いに転送するように構成している場合には無限ループが発生する危険性がございました。    userA – 受信したメールを userB に転送   userB – 受信したメールを userA に転送 上記のこともあり、Exchange Server 2010 ではメールの送信者に対しては仕分けルールで自動転送が実施されないように動作が変更されております。例えば userC が以下のように仕分けルールを構成している状態で userD が userC にメールを送信した場合、userE にはメールが転送されますが userD にはメールが転送されない結果となります。…


OAB 仮想ディレクトリへの匿名アクセスについて

Exchange 2010 RTM からSP1 または SP2 へアップグレードする際に変更される OAB 仮想フォルダの設定についてご案内いたします。 OAB 仮想ディレクトリへの匿名アクセスを許可したい場合、Exchange 2010 RTM 環境では通常通り IIS マネージャから匿名認証を有効とすることで許可することができました。しかし、Exchange 2010 SP1 以降では、仮に [匿名認証] を有効にしていた場合でも既定では匿名でのアクセスは拒否される動作に変更されています。これは、既定で匿名アクセスを無効にするためのものであり、意図した変更となります。 IIS 7.0 以降では、匿名でのアクセス時に使用される既定のアカウントして、”IUSR” が使用されます。この設定については IIS マネージャから [匿名認証] を右クリックして、[編集] をクリックすることで表示できます。 Exchange 2010 SP1 以降で匿名アクセスが拒否される理由は、仮想ディレクトリ配下の OAB を格納しているフォルダの NTFS アクセス許可において、この IUSR への読み取り権限が拒否されるためとなります。    例:   この拒否設定は、Update-FileDistributionService  にてOAB フォルダの更新の度に実施されるため、上記の設定を変更しただけでは次回実行時に元に戻ります。   回避策について ご利用の環境で匿名認証を許可することが必須の場合には、以下の方法で匿名アクセスを許可することが可能です。 IIS 7.0 におきましては既定で IUSR を匿名認証の際に使用しますが、これを任意のアカウントへ変更することも可能です。以下の手順にて IUSR の代わりに別途作成したローカル…