Partager via

MSExchange Availability / 4002 イベントについて

  • Article

こんにちは。Exchange サポート チームの竹本です。
今回のトピックは Exchange 2010 を運用いただいている中で記録される、以下のイベントについてです。
* これは Exchange 2013 でも記録される事があるイベントですが、Exchange 2010 とは少し動作が異なるので、また別の機会にご紹介します。

ログの名前: Application
ソース: MSExchange Availability
イベント ID: 4002
タスクのカテゴリ: 空き時間情報サービス
レベル: エラー
コンピューター: <サーバー名>
説明:
プロセス 6900: ProxyWebRequest CrossSite from S-1-5-21-1010069120-3847555201-2423240907-8630 to https://<サーバー名>:443/ews/exchange.asmx が失敗しました。呼び出し元の SID は NetworkCredentials です。返された例外は Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: Proxy web request failed. ---> System.Net.WebException: リモート名を解決できませんでした。

エラーの原因はイベント内に記録された詳細により異なりますが、CAS サーバーで記録されるこのイベントは、マルチサイト構成の環境において空き時間情報のプロキシ処理に失敗したことを示しています。

Exchange 2010 環境下で Outlook 2007 以降のクライアントが他人の空き時間情報を参照する際、その要求は CAS サーバー上の可用性サービスによって処理されますが、空き時間情報の参照先となるメール ボックスが、参照元のメールボックスとは異なる　AD サイトに所属している場合、要求は以下の通り参照先メールボックスが所属するサイトの CAS サーバーにプロキシされます。

  1. サイトA の CAS サーバーは、AD に対してクエリを発行し、ユーザーのメールボックスの場所と、メールボックス サーバー上にインストールされている Microsoft Exchange のバージョンを確認します。
  2. ユーザーのメールボックスが サイトA とは別の AD サイト内 (サイトB) の Exchange 2010 メールボックス サーバーにある場合、サイトA の CAS サーバーはその要求をサイトB の CAS サーバーに対してプロキシします。
  3. サイトB の CAS サーバーは、要求に基づきメールボックスに直接アクセスし情報を取得した上で、サイトA の CAS サーバーに応答を返します。
  4. サイトA の CAS サーバーは、サイトB の CAS サーバーから受け取った応答結果を元に、クライアントに応答を返します。

この動作につきましては、以下でも紹介させていただいておりますので、併せてご参照ください。

Title: プロキシとリダイレクトについて
URL: https://technet.microsoft.com/ja-jp/library/bb310763(v=exchg.141).aspx

そのため冒頭のエラーが発生している場合、2. のプロキシ処理が何らかの要因で失敗しているという事になり、ユーザーは他サイトのユーザーの空き時間情報を正しく取得できていない可能性が高い、という事になります。
このような場合、まずはエラーが発生しているサーバーでブラウザを起動し、エラーに記録されている URL に対して実際にアクセスをしてみてください。名前解決が正しく行われネットワーク的に疎通ができている環境であれば、資格情報を要求するプロンプトが表示されます。資格情報が要求されず、"ページが表示できません" となってしまう場合には、ネットワーク的な疎通 (443 ポート) が正しく行える環境となっているかを確認することが最優先です。

ではこの URL はどのようにして決められているのでしょうか。ここに Exchange 2010 SP3 の適用可否が影響してきます。
Exchange 2010 SP2 以前の環境では、参照先サイトに存在する CAS サーバーの EWS 仮想ディレクトリ (Get-WebServiceVirtualDirectory で取得可能な仮想ディレクトリ) に設定された InternalURL の値が取得され、接続先として使用されていました。しかしながら、この URL は通常 CAS アレイや負荷分散装置などの仮想ホスト名に変更される事が一般的であり、お客様の構成によっては正しくアフィニティが維持されずに非効率な通信や問題が生じるケースがありました。
そこで SP3 以降では InternalURL ではなく、同仮想ディレクトリの InternalNLBBypassURL の値が使用されるように変更されています。この値には既定でそのサーバーのホスト名または FQDN が設定されており、明示的に変更が行われるシチュエーションもありません。これによりアフィニティが正しく維持できるようになり、より効率的なプロキシ処理が可能となっています。

そのため SP3 を適用されている環境で同エラーにより他サイトの空き時間情報を参照できない、という場合には、まずその URL に対してアクセス可能となっているか、InternalNLBBypassURL に正しくホスト名または FQDN が設定されているかといった点を、ご確認ください。

- 補足
このエラー イベントは通常 CAS サーバー上で記録されますが、稀にパブリック フォルダー (PF) サーバー上で記録されることもあります。そして PF サーバー上で記録されている場合には KB 2535105 の事象が発生している可能性があるため、要注意です。

上述の通り、Exchange 2010 環境下で動作する Outlook 2007 以降のクライアントは、CAS サーバーの可用性サービスに対して空き時間情報の取得を試みますが、Outlook 2003 や EWS が利用できない Lync クライアントでは、従来通り PF から空き時間情報を取得します。そして Exchange 2010 SP1 以降の環境では、このように PF 上の空き時間情報に対する要求が発生した際、その要求を CAS サーバーの可用性サービスに対してプロキシする機能が追加されています。これにより従来のクライアントも Outlook 2007 以降と同様に可用性サービスの機能が利用できるよう、RPC Client Access (RCA) サービスの機能が強化されています。
* 可用性サービスが利用できることで、Outlook 2003 でも他 Exchange 組織との空き時間情報共有 (フェデレーション) が可能になります。

しかしながら、この追加処理と .NET Framework の不具合により、NW 的に PF サーバーから CAS サーバーへの接続ができない場合など、PF サーバー上の RCA サービスで多数のスレッドが応答を待機しているような状態に陥ることがあります。
このような場合には冒頭のエラーが PF サーバー上で記録され、さらに RCA サービスは非常に高負荷な状態となり新規要求を受け付けず、Outlook から接続できない現象や、別の接続可能な PF サーバーへ接続するなどの現象が発生します。これが KB 2535105 の事象です。

Title : Outlook client applications cannot connect to public folders after you install Exchange Server 2010 SP1
URL : https://support.microsoft.com/kb/2535105

上記不具合に該当しているか否かの 1 つの指標としては、RCA サービスのスレッド数を確認することが有効です。
具体的には、タスク マネージャーのプロセス タブより以下のプロセスのスレッド数を確認します。
* スレッド数は既定で表示されません。"表示" – "列の選択" より "スレッド" にチェックを入れて表示します。

"Microsoft.Exchange.RpcClientAccess.Service.exe"

このスレッド数が 500 を超過している場合、KB 2535105 に該当している可能性が高い状況になります。その場合の確実な暫定対処としては、対象の PF サーバー上で RCA サービスを再起動することです。多数のスレッドが存在しているような場合、サービスの停止処理自体がハングし正しく行えない可能性もありますが、そのような場合にはタスク マネージャーより "Microsoft.Exchange.RpcClientAccess.Service" プロセスを強制的に終了し、その後、自動的にサービスが開始状態となることをご確認ください。
* PF サーバー上の RCA サービスは、パブリック フォルダーへのアクセスを処理する役割を担っているため、RCA サービスの再起動中には PF にアクセスできない事象が発生します。しかしながら、メールボックスへの接続やメールの送受信には影響ありません。

また恒久的な対処策としては KB にも記載の通り、レジストリを設定して Exchange 2010 SP1 以降で追加されたこのプロキシ機能を無効化頂くことが有効です。
この機能自体、フェデレーション等を使用して他 Exchange 組織との空き時間情報共有を行う際に、従来のクライアント (Outlook 2003) 用にのみ用意されている機能となっていますので、こちらを無効化しても最初から可用性サービスを使用するOutlook 2007 以降のクライアントでは、機能上の影響はありません。

今回は以上となりますが、Exchange 2013 の動作についても、準備ができ次第公開をさせていただきたいと思います。
今後も当ブログおよびサポート チームをよろしくお願いいたします。