用于排查 Exchange ActiveSync 问题的脚本

原文发布于 2012 年 2 月 1 日（星期三）

• ActiveSyncReport 脚本
• 下载（该链接可能指向英文页面）

Exchange 支持团队经常接到下面的案例：使用 Exchange ActiveSync (EAS) 协议的移动设备向 Exchange 服务器发送的请求太多，导致服务器资源不足，从而实际引发了“拒绝服务”(DOS) 攻击。此类情况最糟糕的结果是其他可能没有使用 EAS 协议进行连接的用户也无法使用服务器。我们在下面的知识库文章中记录了此问题并提供了可能的解决措施：

2469722（该链接可能指向英文页面） 因为 Exchange 资源占用问题而无法使用 Exchange ActiveSync 进行连接

近期有关此问题的一个示例是 Apple iOS 4.0 设备每 30 秒重试一次完全同步（请参阅 TS3398（该链接可能指向英文页面））。另一个示例则是有些设备不知道如何处理来自 Exchange 服务器的“邮箱已满”响应，导致服务器尝试重新连接。这可能造成此类设备尝试连接以及与邮箱同步的频率超过 60 次/分钟，从而缩短设备上电池的使用寿命并引起服务器的性能问题。

管理移动设备和平衡不同类型客户端之间的可用服务器资源对于 IT 管理员来说是一项艰巨的挑战。尝试跟踪哪些设备会导致 Exchange 2010/2007 客户端访问服务器 (CAS) 或 Exchange 2003 前端 (FE) 服务器的资源耗尽问题确实很难。如上面文章中所介绍的那样，您可以使用日志解析器从 IIS 日志提取有用的统计信息 （请参阅下面的注释） ，但是大多数管理员不具备专业知识，也没有时间草拟一个查询来从冗长的日志中提取此类信息。

这篇博文的目的是向 Exchange 社区中的所有人介绍新的 PowerShell 脚本，可以使用该脚本识别导致资源耗尽问题的设备，帮助确定性能趋势并自动生成连续监视的报告。使用该脚本，您可以快速而轻松地深入分析您用户的 EAS 活动，这是面对可能会增大到数 GB 的 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”部分）。

IIS 6

1. 在“IIS 管理器”中，右键单击网站名称（大多数情况下应为“默认网站”），然后选择“属性”
2. 单击“网站”选项卡。

哪些移动设备负责与服务器进行通信？

在我们探究脚本的细节之前，让我们先看看使用 EAS 与 Microsoft Exchange 进行通信的移动设备的一些重要要求。

• 当移动设备收到来自服务器的非预期响应时，由设备处理响应并以合理的间隔适当地重试。另外，设备负责处理发生在 IIS 之外发生的超时，这可能是由网络延迟引起的。
• 对于设备发送给 IIS/Exchange 的每一个请求，它还应该报告用户代理（该链接可能指向英文页面）。

使用该脚本时您会看到什么？

该脚本使用 Microsoft Log Parser 2.2 解析 IIS 日志并生成结果。它根据您使用的开关（见下表）为日志解析器创建不同的 SQL 查询。之前的一篇博文 Exchange 2003 - Active Sync 报告（该链接可能指向英文页面）针对类似的方面对日志解析器进行了介绍。该博文中的信息同样适用于 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 协议规范（该链接可能指向英文页面） 。

除了这些命令，脚本还记录下面的参数。

1. 用户

2. 用户名称

3. 设备类型

4. 设备 ID

5. 用户代理

6. sc-bytes：仅在 IIS 日志记录中启用了此标记时才可用。

7. cs-bytes：仅在 IIS 日志记录中启用了此标记时才可用。

8. 所用时间（毫秒）：仅在 IIS 日志记录中启用了此标记时才可用。

9. 请求的总数或设备 ID 的请求

10. 所有 4xx 状态代码的总数

11. 所有 5xx 状态代码的总数（有关详细信息，请参阅面向 IIS 6.0 的知识库：318380 以及知识库：943891）

12. 409 状态代码：409（冲突）- 无法为请求 URI 创建集合，除非创建了一个或多个中间集合。服务器不得自动创建那些中间集合（参考资料：RFC 4918（该链接可能指向英文页面））

13. 500 状态代码：设备发送 OPTIONS 命令后，可能会从服务器那里收到 500 响应以及“MissingCscCacheEntry”错误。当面向 Internet 的 CAS 阵列代理内部 CAS 阵列请求的相关性出现问题时，可能会发生这种情况。当面向 Internet 的阵列将请求发送到内部阵列时，CAS 服务器将首先使用 401 进行回应。在接下来的通信中，请求由内部阵列中的其他 CAS 服务器进行处理。解决该内部 CAS 阵列的相关性问题就是解决方案。

14. 503 状态代码：由于服务器临时过载或维护问题，服务器当前无法处理请求。其含义是，这属于临时情况，一段时间后将会得到缓解。如果该可能延迟的时间已知，则会显示在重试间隔标头中。如果未给出重试间隔，客户端将按照处理 500 响应的方式处理该响应。

    注释：存在 503 状态代码并不表示服务器在发生过载时必须使用该状态代码。某些服务器可能只是简单地拒绝连接。（参考资料：RFC 2616（该链接可能指向英文页面） ）

15. 507 状态代码：507（存储不足）状态代码表示无法对资源执行方法，原因是服务器无法存储成功完成请求所需的表示形式。该情况被视为临时情况。如果收到此状态代码的请求是用户操作的结果，则该请求不得重复，除非由单独的用户操作提出。（参考资料：RFC 4918（该链接可能指向英文页面））

16. 451 状态代码：Exchange 2007/2010 在确定设备应该为 EAS 连接使用“更好”的 CAS 时，将 HTTP 451 响应返回给 EAS 客户端。用于确定“更好”CAS 的逻辑基于 Active Directory 站点以及 CAS 是否为“面向 Internet”。如果指定了 ExternalUrl 属性（在 Microsoft-Server-ActiveSync 虚拟目录上），那么该 CAS 就被视为面向 Internet 进行 EAS 连接。（ 参考资料：TechNet 文章 Exchange ActiveSync 返回了 HTTP 451 错误和了解代理和重定向）

17. TooManyJobsQueued 错误：有关“TooManyJobsQueued”的详细信息，请参阅上面引用的知识库：2469722（该链接可能指向英文页面）

18. OverBudget：预算是用户或应用程序针对特定设置可能具有的访问量。预算表示用户可以具有多少个连接或者每一分钟时间内允许用户进行多少个活动。（参考资料：TechNet 文章）

19. 下面是一部分常见状态代码（该链接可能指向英文页面）：

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

您能使用该脚本做什么？

您可以使用该脚本处理日志以检索下面的详细信息：

1. 按用户/设备 ID 列出的命中数（向服务器发送最大数量请求的用户/设备）
2. 每小时/每天命中数（帮助确定用户/设备发送请求的频率，时间值以秒为单位进行输入）
3. 按具有指定阈值限制的设备的命中数（此处您可以指定命中/请求的限制，即每小时/每天发送 1000 个请求的所有用户等等）
4. 以 CSV 格式导出的结果
5. 结果的 HTML 报告
6. 用于监视的电子邮件报告（CSV/HTML 格式）

必备组件：

使用该脚本之前，请确保您的机器上已安装了以下组件：

• Log Parser 2.2（该链接可能指向英文页面）。
• Windows PowerShell 2.0（默认情况下 Windows 7 和 Windows 2008 R2 上已安装该组件）

脚本参数

您如何使用该脚本？

下面一些示例（使用命令）说明您如何使用该脚本以及为何使用它们。

命中数超过 1000

下面的命令将解析文件夹 W3SVC1 中的所有 IIS 日志，并仅报告按用户和设备划分的超过 1000 的命中。

.\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 开关提供需要保存的输出或结果文件的位置，MinimumHits 的值为“1000”，上面的表中已介绍该脚本参数]

输出：

通常，如果某个设备每天发送超过 1000 个请求，那么我们视其为“高使用率”，如果命中（请求）数超过 1500，那么设备或环境可能存在问题。在该情况下，应进一步调查设备和其用户的活动。

在实际操作中，某些情况下我们注意到有多个用户通过 EAS 大量命中他们的 Exchange 服务器（约 25000 次命中，每小时 1000 次），结果耗尽了服务器的资源。通过进一步的调查我们发现，所有那些用户的请求都在后端邮箱服务器上引发了 507 错误。与那些 EAS 用户交谈后了解到，他们在那个时间段内达到了邮箱大小限制 (25 MB) 并尝试通过删除其他文件夹中的邮件来释放空间。在此类情况下，在 EAS 请求的 IIS 日志中也能看到 HTTP 503（“TooManyJobsQueued”）响应，如下面的知识库文章所述：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

输出：

使用上面的信息，您可以选择一个用户/设备并查看每小时的趋势。这可帮助识别它是用户操作还是程序操作。

在实际操作中，某些情况下我们必须找出哪些设备修改了日历项。所以我们查看用户/设备活动，并按照它们发送到服务器的不同命令对其进行排序。之后我们只是关注哪些用户/设备发送了“MeetingResponse”命令，以及其频率、时间段和进一步的相关详细信息。这可帮助我们将问题范围缩小到相关的用户及其日历特定活动，以更好地解决基本日历问题。

另一个要查找的设备相关命令和错误为“Options”命令，如果对设备执行此命令不成功，则会在 IIS 日志中返回 HTTP 409 错误代码。

隔离一天

下面的命令将仅解析文件夹 W3SVC1 中与日期 12-24-2011 匹配的文件，并仅报告超过 1000 次的命中。

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

输出：

使用上面的信息，您可以识别发送大量请求的用户。在列中，您还可以看到那些用户发送的是何种命令。这可帮助找出更具有指导性和更高效的故障排除技术。

您应该查找什么？

在脚本的帮助下分析 IIS 日志时，您应该查找一个不断重复发送的特定命令。所发送的特定命令的频率很重要，任何经常失败的命令也同样重要，应进一步对其进行研究。我们还应该查看并比较某些命令执行之间的等待时间。一般而言，执行时间较长或造成服务器延迟响应的命令很可疑，应进一步对其进行研究。但请记住，Ping 命令是一个例外，因为其执行时间较长且也将经常出现在日志中，但这是正常的。

如果您发现连接设备时连续失败，且错误代码为 403，其表示该设备未启用基于 EAS 的访问。有时，移动设备用户抱怨存在连接问题，而没意识到他们实际上没有正确输入其凭据（可以理解，因为在移动设备上很容易犯这种错误）。当查看日志时，您可以重点关注该用户，并且可能会发现该用户的设备在发出“Provision”命令后失败。

创建用于监视的报告

您可能想要创建报告或生成包含此类报告和用户活动详细信息的电子邮件。

下面的命令将解析文件夹 W3SVC1 中的所有 IIS 日志并仅报告超过 1000 次的命中。另外，其还创建结果的 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 和 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 以查看原文