2014-08-28 22:03:52
来 源
中存储网
Exchange邮件服务器
本文要介绍的方法就是使用Process Tracking Log tool for Exchange Server这个工具来对Exchange进行监控。

本文要介绍的方法就是使用Process Tracking Log tool for Exchange Server这个工具来对Exchange进行监控。通过搜索引擎,可以很容易的找到该工具,不过可能很多朋友都会遇到这样一个问题:为什么我使用脚本分析到的结果总是空的呢?笔者在这里也遇到了这样的问题,花费了好大功夫才找到了问题的原因,最终获取到需要的数据。为了日后大家可以避免我走的这条弯路,在此分享解决的方法。

一 工具介绍

Process Tracking Log tool for Exchange Server可以在以下网址中找到并下载:

http://blogs.technet.com/b/exchange/archive/2011/10/21/updated-process-tracking-log-ptl-tool-for-use-with-exchange-2007-and-exchange-2010.aspx

如果英文不大好,也可以看看以下地址的介绍:

http://technet.microsoft.com/zh-cn/library/ff597982(v=exchg.80).aspx

使用该脚本获得的数据主要有:

  • MTDsnFailureResults.csv 文件包括所有失败原因的详细信息。
  • 对于帮助排除特定服务器上或组织中发生的重复邮件传送问题,MTDuplicateDeliveryResults.csv 文件非常有用。
  • MTNextHopResults.csv 文件包括邮件数以及通过 SMTP 和 StoreDriver 组件发送到每个下一跃点服务器的平均邮件大小。
  • MTExpandResults.csv 文件包括通讯组 SMTP 地址、每个通讯组扩展操作的收件人数和执行的通讯组扩展数。
  • MTLogStatistics.csv 文件包括处理的每个日志文件的大量统计信息。
  • MTDeliveryLatencyExceptions.csv 文件包括 MinDeliveryLatency 和 MaxDeliveryLatency 字段。这些字段包含延迟度量(以秒为单位)。这些字段用于量度针对特定邮件发生的传送。仅当只传送一个邮件时这些度量才有效。您可以使用此信息来帮助确定邮件传送过程中的下一跃点是否是造成收件人子集延迟的原因。
  • MTMbxFullRecipResults.csv 文件包含“邮箱已满”事件的结果。此文件包括已满邮箱的 SMTP 地址和 NDR 计数。
  • MTReceiveResults.csv 文件包括邮件数以及使用 SMTP 或 StoreDriver 组件提交邮件的每个主机的平均邮件大小。
  • MTTopRecipientResults.csv 文件包括 SMTP 地址、邮箱服务器名称和主要收件人接收到的邮件。主要收件人是指那些接收邮件数多于平均邮件数的收件人。
  • MTTopSendersbyDeliverResults.csv 文件包括 SMTP 地址及主要邮件发件人发送的邮件数。主要发件人是指那些发送邮件数多于平均邮件数的发件人。这包括来自组织外部发件人的邮件。
  • MTTopSendersbySubmitResults.csv 文件包括 SMTP 地址、邮箱服务器名称和主要发件人发送的邮件。主要发件人是指发送邮件数多于平均数的用户。此文件仅包括使用 StoreDriver(而不是 SMTP)从邮箱提交的邮件。
  • MTEventTimeDistribution.csv 文件显示按小时计算的事件分发数。此文件可帮助提供一种绘制事件时间图的手段。
  • MTMessageSizeDistribution.csv 文件基于邮件大小显示邮件分布。该分布可以根据邮件数、占邮件总数的百分比和小于当前邮件大小的邮件百分比进行细分。这可以帮助确定组织中邮件大小的分布范围。
  • MTRecipientNotFoundResults.csv 文件包含有关在全局地址列表 (GAL) 或 Active Directory 目录服务中找不到的收件人的统计信息。
  • MTDomainExpiredResults.csv 包含可能有助于排除 DSN 故障的条目。例如,因为拼写错误而出现 DSN 故障或目标服务器的不可用时间超过两天(默认的过期超时间隔)的情况下,这些条目可以帮助排除故障。
  • 仅当大小超过 iMaxMessageSizeThresholdKB 值的邮件存在跟踪日志事件时才会生成 MTMessageSizeExceptions.csv 输出文件。默认阈值为 64MB。如果没有这种跟踪日志事件,则不会生成该文件。
  • MTMailSubmissionDistribution.csv 文件包含提交的分布情况(按 MessageClass 和 ClientType 分类)。通过此文件可以分析 SUBMIT 事件 SourceContext 字段,以便按 ClientType 和 MessageClass 确定提交的分布情况。此文件依赖于邮箱角色跟踪日志。

    二 工具使用

    关于该脚本的使用方法,这里就不详细叙述了,如果不清楚的话,还可以通过搜索引擎搜索到具体的使用方法。在此只详细说明按照脚本中的使用说明为何会每次得到空白的数据。原因是因为该工具不能读取到UTF-8编码的文本的内容,没错,Exchange传输日志的编码就是UTF-8,问题就是出在这里。现在你明白了为什么每次执行脚本产生的输出文件都是空白了吧。打开一个传输日志文件,将其另存为,看看“编码”,没错,就是UTF-8。

    好吧,那下一步就是要找一个方法,如何实现将传输日志文件的编码从UTF-8转换成脚本可以识别的编码方式了。网上有不少的工具可以实现这样的转换,但是这些工具不能定时的自动进行。那还是把目光投入到如何通过脚本来转换吧。网上找到由fastslz编写的一个转换脚本,加以修改以后用来转换编码。

    2.1 打开记事本,将以下内容复制到记事本中:

    2.2 将文件保存为UTF82ANSI.vbs,在此假定把脚本保存在C盘根目录下。

    2.3 再编写一个批处理用于执行UTF82ANSI.vbs,实现转换。

    假设传输日志已被拷贝至D:Log文件夹下。为什么要拷贝呢,因为不建议直接对传输日志文件进行转换,一方面转换后可能会影响日志的使用,另一方面最新的日志文件正在写入转换会失败。

    编写批处理脚本,假定脚本文件名为CodeChange.bat内容如下:

    2.4 双击执行CodeChange.bat,日志文件即可实现编码转换。如需定期执行,则可制订任务计划执行即可,在此就不再赘述了。

    声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。