Freigeben über


Exchange ActiveSync に関する問題をトラブルシューティングするためのスクリプト

原文の記事の投稿日: 2012 年 2 月 1 日 (水曜日)

Exchange サポート チームでは、Exchange ActiveSync (EAS) プロトコルを使用したモバイル デバイスから Exchange サーバーに数多くの要求を送ると、サーバーのリソースが不足し、事実上、サービス拒否 (DoS) 攻撃が発生するというケースについて、比較的頻繁に相談を受けています。このような状況において最悪なのは、接続用に EAS プロトコルを使用していない他のユーザーもサーバーを使用できなくなることがあるということです。この問題について考えられる軽減策を、次のサポート技術情報の記事で取り上げています。

2469722 (英語) Unable to connect using Exchange ActiveSync due to Exchange resource consumption

この問題の最近の例は、30 秒おきに完全な同期を再試行する Apple iOS 4.0 デバイスです (「TS3398 (英語)」を参照してください)。もう 1 つの例は、Exchange サーバーからの「メールボックスが一杯」という応答の処理方法がわからないため、結果として再接続を何度も試行するデバイスです。これにより、このようなデバイスは、1 分間に 60 回以上メールボックスに対して接続および同期を試行し、その結果、デバイスの電池の寿命が短くなり、サーバーでパフォーマンスの問題が発生します。

モバイル デバイスの管理と、さまざまな種類のクライアント間で使用できるサーバー リソースのバランスを保つことは、IT 管理者にとって困難な課題です。Exchange 2010/2007 Client Access サーバー (CAS) または Exchange 2003 フロントエンド (FE) サーバーで、どのデバイスがリソース不足の原因となるかを見つけ出すことは簡単な仕事ではありません。上の記事に記載されているように、Log Parser を使用して有益な統計を IIS ログ (以下の注を参照) から抽出できますが、ほとんどの管理者には、クエリを作成して、延々と続く長いログからそのような情報を抽出するための時間や専門知識がありません。

この投稿は、Exchange コミュニティに参加しているすべてのユーザーに、新しい PowerShell スクリプトを紹介することを目的としています。このスクリプトを使用すると、リソース不足の問題の原因となるデバイスを特定し、パフォーマンスの傾向をつかみ、継続した監視のためのレポートを自動的に作成できます。また、このスクリプトにより、ユーザーの EAS アクティビティを簡単かつ迅速にドリルすることもできます。これは、IIS ログのサイズが数ギガバイトまで増える可能性がある場合、重要なタスクになることがあります。このスクリプトを使用すると、複数の EAS デバイスを使用しているユーザーを簡単に特定できます。また、通常の EAS アクティビティ時にはベースラインを確立するためのツールとしても使用でき、その他の場合には比較やレポートの目的で使用できます。電子メール通知を受信するために使用できる自動監視機能も備えられています。

注: スクリプトは、Exchange 2010、Exchange 2007、および Exchange 2003 の各サーバー上で IIS ログに対して使用できます。
EAS プロトコルや Microsoft Exchange を使用したモバイル デバイス間のすべての通信は、CAS/FE サーバー上で W3C (英語) 形式で IIS ログに記録されます。ログの記録が有効になった既定の W3C フィールドは、IIS 6.0 と 7.0/7.5 とでは異なります (IIS 7.0 には 7.5 と同じフィールドがあります)。このスクリプトは、両方のバージョンに対して機能します。

IIS ログ

EAS は HTTP を使用するため、すべての EAS 要求は IIS ログに記録されます (これは、既定で有効になっています)。管理者は、サーバーの領域を節約するために IIS ログを無効にする場合があります。ログが有効になっているかどうかを確認したり、ログ ファイルの場所を見つけ出すには、次の手順に従います。

IIS 7

  1. IIS マネージャーで、ExchangeServer (Contoso\Administrator) などのサーバーの名前を展開します。
  2. [機能ビュー] の [IIS] セクションで [Logging] (ログの記録) をダブルクリックします。

IIS 6

  1. IIS マネージャーで Web サイトの名前を右クリックし (通常は既定の Web サイトです)、[プロパティ] をクリックします。
  2. [Web サイト] タブをクリックします。

サーバーとの通信においてモバイル デバイスが果たす役割

スクリプトについて具体的に説明する前に、Microsoft Exchange との通信に EAS を使用するモバイル デバイスの重要な要件をいくつか見てみましょう。

  • モバイル デバイスでサーバーから予期しない応答が返された場合、応答を処理して妥当な間隔で適宜再試行する判断は、そのデバイスに委ねられています。また、デバイスは、ネットワークの待ち時間によって発生する可能性がある、IIS の外で発生するタイムアウトの処理にも関与します。
  • デバイスが IIS/Exchange に送信する各要求では、ユーザー エージェント (英語) (User-Agent) も報告されます。

このスクリプトの実行時の動作

スクリプトは Microsoft Log Parser 2.2 を使用して IIS ログを解析し、結果を生成します。使用するスイッチ (以下の表を参照) に基づいて Log Parser に対してさまざまな SQL クエリを作成します。Log Parser について述べた以前のブログ投稿「Exchange 2003 - Active Sync reporting (英語)」でも同様の点について触れています。投稿内の情報は、Exchange 2010 および 2007 にも当てはまります。このブログ投稿以降、新しいコマンドが EAS プロトコル (英語)に追加されました。このコマンドは、ログの処理時に、この新しいスクリプトによっても使用されます。

スクリプトが結果で報告する EAS コマンドは次のとおりです。

Sync、SendMail、SmartForward、SmartReply、GetAttachment、GetHierarchy、CreateCollection、DeleteCollection、MoveCollection、FolderSync、FolderCreate、FolderDelete、FolderUpdate、MoveItems、GetItemEstimate、MeetingResponse、Search、Settings、Ping、ItemOperations、Provision、ResolveRecipients、ValidateCert

各 EAS コマンドの詳細については、MSDN の「ActiveSync HTTP Protocol Specification (英語)」を参照してください。

これらのコマンドに加え、次のパラメーターもスクプリトによってログに記録されます。

  1. ユーザー

  2. ユーザー名

  3. デバイスの種類

  4. デバイス ID

  5. ユーザー エージェント

  6. sc-bytes: IIS ログでこのタグを有効にした場合にのみ使用できます。

  7. cs-bytes: IIS ログでこのタグを有効にした場合にのみ使用できます。

  8. time-taken (ミリ秒): IIS ログでこのタグを有効にした場合にのみ使用できます。

  9. 要求またはデバイス ID による要求の総数

  10. 4xx ステータス コードの総数

  11. 5xx ステータス コードの総数 (詳細については、IIS 6.0 に関する KB 318380 および KB 943891 を参照してください)

  12. 409 ステータス コード: 409 (競合) - 1 つ以上の中間コレクションが作成されるまで、コレクションを Request-URI で作成できません。サーバーでは中間コレクションを自動的に作成できません (参照: RFC 4918 (英語))

  13. 500 ステータス コード: デバイスは OPTIONS コマンドを送信した後、'MissingCscCacheEntry' エラーによりサーバーから 500 応答を受け取る場合があります。これは、インターネットに直接接続された CAS アレイで内部 CAS アレイへの要求をプロキシ化している場合に、アフィニティに関する問題の結果として発生する場合があります。インターネットに直接接続されたアレイが要求を内部アレイに送ると、CAS サーバーは、最初の 401 で応答します。次の通信では、内部アレイの別の CAS サーバーによって要求が処理されます。解決策は、内部 CAS アレイに関するアフィニティの問題を解決することです。

  14. 503 ステータス コード: サーバーの一時的な過負荷またはメンテナンスにより、現在、サーバーは要求を処理できません。これは、遅延後に負荷が減る一時的な状態を意味しています。認識されている場合、遅延の長さが Retry-After ヘッダーに示される場合があります。Retry-After が指定されていない場合、クライアントは 500 応答に対する処理と同じように応答を処理します。

    注: 503 ステータス コードが返された場合、過負荷状態のサーバーは必ずしもその情報を使用する必要はなく、単に接続を拒否することもできます。(参照: RFC 2616 のセクション 10.5.4 (503 サービス利用不可) (英語))

  15. 507 ステータス コード: 507 (容量不足) ステータス コードは、サーバーが要求を正常に完了するために必要な表現を保存できないため、メソッドが実行できなかったことを意味します。この状態は、一時的なものと考えられます。このステータス コードを受け取った要求がユーザー操作の結果であった場合は、別のユーザー操作によって要求されるまで要求を繰り返すことはできません。(参照: RFC 4918 (英語))

  16. 451 ステータス コード: Exchange 2007/2010 は、デバイスが EAS 接続に "より良い" CAS を使用する必要があると判断した場合、HTTP 451 応答を EAS クライアントに返します。"より良い" CAS の判断に使用されるロジックは、Active Directory サイトを基本とし、CAS が "インターネットに直接接続されている" かどうかで判断されます。Microsoft-Server-ActiveSync 仮想ディレクトリに ExternalUrl プロパティが指定されている場合、その CAS は EAS 接続についてインターネットに直接接続されていると見なされます。(参照: TechNet 記事「Exchange ActiveSync から HTTP 451 エラーが返された」および「プロキシとリダイレクトについて」)

  17. TooManyJobsQueued エラー: 'TooManyJobsQueued' エラーの詳細については、前述の KB 2469722 (英語) を参照してください。

  18. OverBudget: バジェットとは、特定の設定に対してユーザーまたはアプリケーションが保有するアクセス数のことです。このバジェットは、1 分間にユーザーが保持できる接続数、または許可されるアクティビティ数を表します。(参照: TechNet 記事)

  19. 一般的なステータス コード (英語)のサブセットは次のとおりです。

    InvalidContent、ServerError、ServerErrorRetryLater、MailboxQuotaExceeded、DeviceIsBlockedForThisUser、AccessDenied、SyncStateNotFound、DeviceNotFullyProvisionable、DeviceNotProvisioned、ItemNotFound、UserDisabledForSync

スクリプトで実行できる処理

このスクリプトを使用してログを処理し、次の情報を取得できます。

  1. ユーザー/デバイス ID ごとのヒット数 (最大数の要求をサーバーに送信したユーザー/デバイス)
  2. 時間/日あたりのヒット数 (ユーザー/デバイスによって要求が送信された頻度を特定するために役立ちます。時刻の値は秒単位で入力されます)
  3. しきい値の制限が指定されたデバイスごとのヒット数 (ヒット数/要求数に対して制限を指定できます。たとえば、時間/日あたりに 1,000 要求を送信するすべてのユーザーなど)
  4. 結果の CSV エクスポート
  5. 結果の HTML レポート
  6. 監視のため電子メール レポート (CSV/HTML 形式)

前提条件:

このスクリプトを使用する前に、使用しているコンピューターに次のツールがインストールされていることを確認してください。

スクリプト パラメーター

パラメーター 必須 種類 説明
ActiveSyncOutputFolder 必須 System.String CSV および HTML 出力ディレクトリ
ActiveSyncOutputPrefix 任意 System.String 出力ファイル名の前に文字列を付加します。
CreateZip 任意 System.Management。Automation.SwitchParameter ZIP ファイルを作成します。SendHTMLReport でのみ使用できます。
CreateZipSize 任意 System.In32 Threshold ファイルのサイズ。既定は 2 MB です。この制限を超えると、ファイルは圧縮されます。SendHTMLReport および CreateZip は true である必要があります
Date 任意 System.String 解析の対象の日付を指定します。日付は MM-DD-YYYY の形式で入力します。
DeviceId 任意 System.String 解析の対象の Active Sync Device ID
DisableColumnDetect 任意 System.ManagementAutomation.SwitchParameter ユーザーが有効にした可能性があるレポートに新しい列を追加する機能を無効にします。例: time-taken 注: 異なる W3C ヘッダーを持つ可能性がある複数のファイルに対して実行している場合は、このスイッチを使用します。
Help 任意 System.ManagementAutomation.SwitchParameter スイッチの説明を出力します。
ReportBySeconds 任意 System.Int32 秒単位で入力された値にレポート ベースを生成します。
Hourly 任意 System.ManagementAutomation.SwitchParameter 時間単位でレポートを生成します。
HTMLReport 任意 System.ManagementAutomation.SwitchParameter HTML レポートを作成します。
HTMLCSVHeaders 任意 System.String

–HTMLReport でのエクスポート対象の IIS CSV ヘッダー

既定値: "DeviceID,Hits,Ping,Sync,FolderSync,DeviceType,User-Agent"

IISLogs 必須 System.Array

IIS ログ ディレクトリ例: - IISLogs D:\Server,'D:\Server 2'

LogParserExec 必須 System.String LogParser.exe へのパス
MinimumHits 任意 System.Int32 CSV および HTML でレポートに生成される最小ヒットしきい値
SendEmailReport 任意 System.ManagementAutomation.SwitchParameter 電子メール レポート機能を有効にします。
SMTPRecipient 任意 System.String SMTP 受信者
SMTPSender 任意 System.String SMTP 送信者
SMTPServer 任意 System.String SMTP Server
TopHits 任意 System.Int32

返される上位ヒット数。例: TopHits 50、これは、Hourly または ReportBySeconds では使用できません

スクリプトの使用方法

スクリプトの使用方法と使用する理由に関する (コマンドを用いた) 例を以下に示します。

1,000 を超えるヒット数

次のコマンドは、フォルダー W3SVC1 内のすべての IIS ログを解析し、ユーザーおよびデバイスによる 1,000 を超えたヒット数のみを報告します。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000

[上のコマンドでは、スクリプト 'ActiveSyncReport.ps1' が C ドライブのルートに配置され、 -IISLog スイッチで IIS ログの既定の場所が指定され、 -LogparserExec スイッチが Log Parser の実行可能なアプリケーション ファイルを参照し、 -ActiveSyncOutputFolder スイッチが、出力または結果ファイルが保存される場所を指定します。'1000' という値を持つ MinimumHits は、上の表で説明されているスクリプト パラメーターです]

出力:

image

通常、デバイスが 1 日に 1,000 を超える要求を送信する場合、これを "使用頻度が高い" と見なします。ヒット数 (要求数) が 1,500 を超える場合は、デバイスまたは環境に問題がある可能性があります。この場合は、デバイスとそのユーザーのアクティビティをさらに詳しく調べる必要があります。

実際に、たとえば EAS を使用して Exchange サーバーに何度も (最大 25,000 ヒット、1 時間に 1,000 ヒット) アクセスしたユーザーが何人かいた場合、結果としてサーバーのリソースが不足します。さらに詳しく調べると、これらのユーザーの要求がすべて、バックエンドでのメールボックス サーバーで 507 エラーになっていることがわかりました。これらの EAS ユーザーに聞いてみると、対象の期間に、メールボックス サイズの上限 (25 MB) に達し、さまざまなフォルダーからメールを削除して、サイズ制限に達しないようにしていたことがわかりました。このような状況では、EAS 要求に対して IIS ログに HTTP 503 ('TooManyJobsQueued') 応答が記録されることがあります (KB 2469722 (英語) を参照)。

特定のデバイス ID の切り分け

次のコマンドは、フォルダー C:\IISLogs 内のすべての IIS ログを解析し、デバイス ID xxxxxx を探して、時間毎の統計を表示します。

.\ActiveSyncReport.ps1 -IISLog " C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports –DeviceID xxxxxx -Hourly

出力:

image

上の情報を使用して、ユーザー/デバイスを選び、1 時間ごとの傾向を確認できます。これは、ユーザー操作であるか、プログラムの操作であるかの判断に役立ちます。

実際には、あるケースで、カレンダー アイテムを修正しているデバイスを見つけ出す必要がありました。そこで、ユーザー/デバイスのアクティビティを調べ、サーバーに送信されたさまざまなコマンドによってアクティビティをソートしました。その後、どのユーザー/デバイスが 'MeetingResponse' コマンドを送っていたか、その頻度、期間、および関連する詳細情報に注目しました。これにより、関連したユーザーおよびそのカレンダー固有のアクティビティに対する問題の範囲を狭め、その基になっているカレンダーの問題により適切に対応することができました。

もう 1 つ注目した、デバイスに関連したコマンドおよびエラーは 'Options' コマンドです。このコマンドがデバイスに対して失敗した場合は、HTTP 409 エラー コードが IIS ログで返されます。

1 日の切り分け

次のコマンドは、フォルダー W3SVC1 内の日付 12-24-2011 に一致するファイルのみを解析し、1,000 を超えるヒット数のみを報告します。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 –Date 12-24-2011

出力:

image

上の情報を使用すると、送信した要求の数が多いユーザーを特定できます。また、列内で、これらのユーザーが送信するコマンドの種類を確認できます。これは、より直接的で効率的なトラブルシューティング方法を見つけるのに役立ちます。

何に注目するか

スクリプトを使用して IIS ログを解析する場合、何度も繰り返し送信されている、ある特定のコマンドを見つけ出す必要があります。特定のコマンドが送信される頻度が重要であり、何度も失敗しているコマンドも同じく非常に重要で、それをさらに詳しく調べる必要があります。特定のコマンドを実行した後の待機時間を調べて、コマンドごとに比較する必要もあります。通常、実行に比較的時間のかかるコマンドや、結果としてサーバーからの応答に遅れを発生させるコマンドは疑うべきであり、さらに詳しく調べる必要があります。ただし、Ping コマンドは実行に時間がかかるため、ログに頻繁に記録されることが予想されます。

エラー コード 403 によりデバイスが接続に失敗するエラーが継続して発生する場合、デバイスが EAS ベースのアクセスに対して有効になっていないことを意味する場合があります。モバイル デバイスのユーザーは、資格情報を正しく入力していないことに気付かずに、接続の問題に対して不平を言うことがあります (モバイル デバイスではそのような間違いを犯すのも無理はありませんが)。ログを調べると、対象のユーザーに注目し、ユーザーのデバイスが、'Provision' コマンドを発行した後に失敗していることに気付く場合があります。

監視のためのレポートの作成

レポートを作成し、作成したレポートやユーザー アクティビティの詳細を含む電子メールを生成できます。

次のコマンドは、フォルダー W3SVC1 内のすべての IIS ログを解析し、1,000 を超えるヒット数のみを報告します。また、結果の HTML レポートを作成します。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 -HTMLReport

次のコマンドは、フォルダー C:\Server1_Logs and D:\Server2_Logs 内のすべてのファイルを解析し、生成されたレポートを 'user@contoso.com' に電子メールで送信します。

.\ActiveSyncReport.ps1 -IISLog "C:\Server1_Logs",”D:\Server2_Logs” -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -SendEmailReport -SMTPRecipient user@contoso.com –SMTPSender user2@contoso.com -SMTPServer mail.contoso.com

このスクリプトが読者の方々のお役に立つことを心より願っています。このスクリプトがどのように役立ったか、その効果を高めるために我々に何ができるかについて情報をお寄せください。

Konstantin Papadakis および Brian Drepaul

M. Amir Haque、Will Duff、Steve Swift、Angelique Conde、Kary Wall、Chris Lineback、および Mike Lagase の各氏に感謝の意を表します。

これはローカライズされたブログ投稿です。原文の記事は、「A script to troubleshoot issues with Exchange ActiveSync」をご覧ください。