实战Exchange ActiveSync日志诊断

在上一篇博文《Exchange 2007 前端 IIS 内存占用太高》当中，咱们提到在Exchange2007时代，移动设备的EAS链接其实并无多少，随着时间的推移，一些没有及时升级的2007的邮件系统由于移动设备用户愈来愈多，也慢慢暴露出产品自己的性能问题。

限制MSExchangeSyncAppPool进程池的内存占用能够临时解决该问题，那么当问题体如今Exchange2010或者2013上呢。该问题就不只仅是处在自己产品性能上面，而是要考虑到当下各式各样移动设备对Exchange EAS链接的友好性。例如：IOS4.0、IOS 6.1都存在过下降Exchange服务器性能的问题。这些问题常常被反映为：用EAS协议链接的移动设备发送的请求太多，且过于频繁（超过默认1000队列的限制），致使占用服务器资源不足，引起了实际意义上的DDOS。

因此好心的支持团队集合了各方面……呃…智慧（Powershell + LogParser + IIS日志），弄出了这样一个脚本。

http://blogs.technet.com/b/exchange_chs/archive/2012/02/24/exchange-activesync.aspx

脚本的做用是，经过Powershell调用LogParser分析EAS产生的IIS日志，生成报表等等

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

1. 按用户/设备 ID 列出的命中数（向服务器发送最大数量请求的用户/设备）

2. 每小时/天天命中数（帮助肯定用户/设备发送请求的频率，时间值以秒为单位进行输入）

3. 按具备指定阈值限制的设备的命中数（此处您能够指定命中/请求的限制，即每小时/天天发送 1000 个请求的全部用户等等）

4. 以 CSV 格式导出的结果

5. 结果的 HTML 报告

6. 用于监视的电子邮件报告（CSV/HTML 格式）

 

在使用以前，首先要保证服务器上安装了Log Parser2.2:http://www.microsoft.com/download/en/details.aspx?id=24659

以及Powershell2.0（最低）

若是你的服务器仍是Windows Server2003 ，那么颇有可能会由于存在PowerShell 1.0而没法安装2.0，升级方法是，中止全部Exchange前端服务并改成手动，卸载PowerShell 1.0 （是个更新补丁对应kb926139），重启，安装Powershell 2.0，再重启，开启全部Exchange服务。

https://technet.microsoft.com/zh-cn/library/ff354975(v=EXCHG.80).aspx

安装好了以后，咱们还须要检查IIS日志是否打开（听说默认启用……可是）：

IIS 7

1. 在“IIS 管理器”中，展开服务器名称，即“ExchangeServer (Contoso\Administrator)”

2. 在“功能视图”中，双击“日志记录”（位于“IIS”部分）。

IIS 6

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

2. 单击“网站”选项卡。

 

接下来是LogParser 2.2 ，下载好以后直接安装便可。须要注意的是该工具不支持windows server 2012或更新的操做系统…

新版本添加了UI https://gallery.technet.microsoft.com/Log-Parser-Studio-cd458765

经常使用来分析一些SQL日志之类的，我以前也用来分析受飞客（Conficker）病毒影响的客户端引起的大量域控请求，有空的话能够再给你们聊聊这个。

万事具有，开始动手。

打开IIS日志文件夹，须要注意的是若是你是刚刚才打开IIS日志选项，这些日志可能不会很完整，最好是等1天左右，他才会收集完整的日志下来。这个很好理解，从你打开选项开始收集嘛。

这里我设置的IIS选项里，日志是按照每一天来截断的，很奇怪他截断的时间是下午四点左右到次日下午四点左右，没搞懂是按照什么样的时区机制运行。

将要分析的日志copy出来，例如这里咱们分析个几天的

 

而后将脚本解压出来

 

首先来第一条命令，以前微软说过：“若是某个设备天天发送超过 1000 个请求，那么咱们视其为“高使用率”，若是命中（请求）数超过 1500，那么设备或环境可能存在问题。在该状况下，应进一步调查设备和其用户的活动。”

.\ActiveSyncReport.ps1 -IISLog "IIS日志路径" -LogparserExec "LogParser路径" -ActiveSyncOutputFolder 输出文件夹 -MinimumHits 1000

运行完成后会生成2个文件，带Hits of 1000的，就是单独的超过1000请求的设备。固然这里没有规定日期区间，因此结果应该是3天内超过1000次请求的项目。

若是是规定某一天，则命令格式为

.\ActiveSyncReport.ps1 -IISLog "IIS日志路径" -LogparserExec "LogParser路径" -ActiveSyncOutputFolder 输出文件夹 -MinimumHits 1000 –Date 05-30-2015

这个文件大体是下图这样子：

日志里包含的信息有：

1. 用户

2. 用户名称

3. 设备类型

4. 设备 ID （经过这里能够查看IOS的User-agent对应的IOS版本http://www.enterpriseios.com/wiki/Complete_List_of_iOS_User_Agent_Strings）

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 响应的方式处理该响应。

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

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

17. 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 错误和了解代理和重定向）

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

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

20. 下面是一部分常见状态代码（该连接可能指向英文页面）： InvalidContent、ServerError、ServerErrorRetryLater、MailboxQuotaExceeded、DeviceIsBlockedForThisUser、AccessDenied、SyncStateNotFound、DeviceNotFullyProvisionable、DeviceNotProvisioned、ItemNotFound、UserDisabledForSync

这么blabla一堆，最主要的就是Hits这个命中总数，也就是总请求数量，若是超过1500的话…其实我我的以为1500这个阈值已通过时了，对于目前的Ex2010或者2013的架构来讲，这个数字未免也过低了一些，毕竟硬件架构性能在提高嘛。

从这个报告里，还有提供了更多的其余参数，上面的列表都列出来大部分，而没有列出的项目，则表明了一些由移动设备发起的动做，相似GetAttachment、Settings、MoveItems等等，从字面意思上就能理解。这可帮助找出更具备指导性和更高效的故障排除技术

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

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

 

更多实用的命令还有：

.\ActiveSyncReport.ps1 -IISLog "IIS日志路径" -LogparserExec "LogParser路径" –ActiveSyncOutputFolder 输出文件夹 –DeviceID  设备ID –Hourly

经过上面表里提取出的设备ID，来查询该设备ID每小时的访问次数

下面的命令将日志文件并报告超过 1000 次的命中。另外，其还建立结果的 HTML 报告。

.\ActiveSyncReport.ps1 -IISLog "IIS日志路径" –LogparserExec  "LogParser路径" –ActiveSyncOutputFolder 输出文件夹 -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