Exchange 分析器工具介绍及案例分析

　除了可以下载这些工具，这些工具也包含在Exchange Server 2007 Toolbox 中，可以从Exchange Management Console来访问。
　　对这些工具我们有很大的热情，并且我们也愿意它具有一定的影响性。下面我将讲述一些关于Microsoft 产品支持服务使用Exchange Troubleshooting Assistant 组件的支持案例。接着，我将讲述一些Exchange 最佳实践分析器的成功故事。我非常愿意将产品支持服务使用这些工具帮助排错支持请求的成功故事与您分享。
　　请思考这些来自我们产品支持服务案例中的例子，从中我们不仅可以学到自己如何使用这些工具，甚至熟悉了它们的存在。这就是为什么您将看到这样的描述，说“尝试解决该问题的几天后，我运行了分析器工具，然后马上就解决了该问题。”在这些案例中，支持工程师可能只是知道该工具的存在。
　　Exchange Troubleshooting Assistant
　　Exchange Troubleshooting Assistant (ExTRA) 包含了下面三个组件：
　　· Exchange Performance Troubleshooting Analyzer (ExPTA)
　　· Exchange Mail Flow Analyzer (ExMFA)
　　· Exchange Disaster Recovery Analyzer (ExDRA)
　　当您打开Microsoft Exchange Troubleshooting Assistant 的时候，您可以选择Performance Troubleshooter 、Mail Flow Troubleshooter 、Database Recovery Management 。我将这些使用ExTRA 组件帮助排错问题的成功故事组合在一起。
性能问题
　　性能问题是最麻烦和消耗时间的问题。技术支持工程师一般不会只拿一个问题，并只做这个问题直到它被完成。在大多数问题中，在客户和技术支持工程师之间有一些前后来回，如他们尝试不同的方法和检查不同的设置。性能问题能够持续数星期才能被解决。
　　Performance Troubleshooting Analyzer对花多长时间解决这些问题有一个很大影响。在不使用Exchange Troubleshooting Assistant，平均要花42分钟来解决一个问题。使用该工具，平均时间可以缩短到12分钟。
　　下面的表格说明了ExPTA 对排错性能问题的影响。表格中描述的时间是技术支持工程师记录的花在每个案例上的时间数量。
　

时间或案例	使用ExPTA	手动
平均时间	12 分钟	42分钟
最小时间	4分钟	3分钟
最大时间	1 小时16分钟	8 小时23分钟
平均时间	10 分钟	33分钟
初始解决方法交付	12 个案例	3个案例
没有解决的案例	1个案例	19个案例

　　从上述的表格中，一个具有代表性的是使用ExPTA 解决一个问题的最大时间只有1 小时16分钟，比不使用ExPTA 的平均时间要长。另一个具有代表性的是，当客户和技术支持工程师第一次联系的时候，我们能够解决问题的数量。认为上面的表格说明了当在联系产品支持服务之前经常使用ExTRA，我们将看到性能问题的数量会减少。
　　症状： Outlook RPC 弹出窗口
　　根本原因： 客户端限制操作
　　支持工程师的评论： ExPTA 报告指出客户端使用使用限制操作，如该操作是处理Exchange 在一个文件夹或文件夹集合(有效地，带有相关标准的一个数据库表格)上创建一个视图的请求的一部分。如果文件夹或文件夹集合上的视图已经有一个匹配的限制，Exchange 使用现有的视图来满足用户的请求。如果试图没有一个匹配限制，Exchange 创建一个新的视图。创建视图比使用现有的视图要花更多的成本。在开始运行ExPTA的两天里这个问题被隔离。
　　症状： Outlook RPC 弹出窗口
　　根本原因： 高数据库平均读和写时间
　　支持工程师的评论：当我在客户现场的时候，我使用ExPTA。让客户实时看到 这个输出是很好的，因为在通常情况下您将不得不收集性能数据，手动检查它，然后将每个计数器与性能白皮书中建议的阀值进行一一比较，接着将比较的结果展示给用户。该工具帮助节省了大量通常隔离基于性能问题要消耗的人力时间。
　　症状： Outlook RPC 弹出窗口
　　根本原因： SAN 磁盘延迟
　　支持工程师的评论：一那到问题，我就请求客户运行 ExPTA ，该问题在一天之内就被隔离出来。
　　症状： Outlook RPC 弹出窗口
　　根本原因： Exchange 服务器数据库所在的驱动器磁盘瓶颈
　　支持工程师的评论：一那到问题，我就请求客户运行 ExPTA ，该问题在三天之内就被隔离出来。
邮件流问题
　　不幸的是，我没有相同的数据来说明对于邮件流和数据库恢复所节省的具体时间。大体来说，有很少的案例可以选择，我们没有机会来运行相同的学习像我们在性能问题上所做的那样。
　　[b]症状： 在两个路由组之间邮件排列在路由组连接器中
　　根本原因：远端服务器的FQDN不正确
　　支持工程师的评论：第一个路由组中的所有4台Exchange 服务器有到第二个路由组的所有服务器的对列。在应用程序日志中，您看到事件ID 4000 “在DNS中不能绑定到远端目的服务器”。ExMFA帮助我们及时解决了该问题。在我们修改了涉及到的所有的SMTP 服务器的FQDN并重启了路由服务之后，邮件队列被清空。
　　症状： 邮件堆积在分类器队列之后， InetInfo 达到百分之九十九。
　　根本原因：非标准的SMTP 接收器
　　支持工程师的评论： ExMFA让我们很容易地看到服务器上的非标准的SMTP 接收器。它将该问题的根本原因告诉我们。
　　症状： 邮件堆积在队列中
　　根本原因： 缺省的 SMTP 域名更改
　　支持工程师的评论： ExMFA确认了缺省SMTP 虚拟服务器域名称的更改。
　　数据库恢复
　　症状： 邮箱和公用文件夹存储卸载，不能被成功地加载
　　根本原因： E00.log 文件丢失
　　支持工程师的评论： 开始我让用户下载ExTRA 工具，然后运行DRA 向导。用户将输出的XML文件发送给我，该文件清晰地说明了E00.log 文件丢失，存储必须成功加载。ExDRA 建议找到丢失的日志文件，从备份中恢复或修复该数据库。
　　我们在防病毒软件隔离文件夹中找到丢失的日志文件，将它恢复到它原来的路径。该存储被成功加载，整个恢复花了不到一个小时。
在分析数据库头和找到丢失日志ExDRA 节省了时间和效力。它也提供了从灾难中恢复的几个建议。该用户对使用ExDRA非常开心，为所有将来可能发生的问题他决定使用它和它的其他功能。
　　我将在所有的灾难恢复案例中使用ExDRA，来帮助更多的用户比以前更快地恢复灾难。
　　症状： 数据库没有加载
　　根本原因： 日志文件损坏
　　支持工程师的评论： ExDRA 给我们要处理的正确的选项，在同一天服务器就恢复正常运行
　　症状： 数据库没有加载
　　根本原因： 日志文件的序列达到限制 (E00FFFFF.log)
　　支持工程师的评论：ExDRA 给我们要处理的正确的选项，在五十分钟之内服务器就恢复正常运行。
　　总结
　　正如您所看到的，我们发现在Exchange 排错中Exchange 分析工具是非常有价值的。因此下次，Exchange 服务器开始出现问题后，在联系微软的产品技术支持之前先尝试这些工具。从最小的代价来说，您将节省一些时间，当您开支持请求后您可以将报告发送给我们。最好的情况是，您将发现该问题在解决它的时候，可以节省您自己的时间和金钱。[/b]