Exchange 分析工具成功案例

 

上一次修改主题: 2006-10-23

最近几个月,一些在 Microsoft® 工作的人开始撰写有关如何使用 Microsoft Exchange 分析工具帮助解决问题的文章、博客和新闻组文章。 如果您错过了这些内容,就让我来为您快速概括这些工具的用途。

Microsoft Exchange Best Practices Analyzer(英文网页)是为希望确定其 Exchange 服务器和拓扑的整体运行状况的管理员设计的。 该功能能够对 Exchange 服务器进行扫描,并标识不符合 Microsoft 最佳实践的项目。

Microsoft Exchange Troubleshooting Assistant(英文网页)有助于确定运行 Microsoft Exchange Server 的计算机的性能、邮件流和数据库装载问题的起因。 该工具可根据标识的故障现象自动生成专用故障排除步骤。

这些工具除了可供下载,还包含在 Exchange Server 2007 工具箱中,可以从 Exchange 系统管理器进行访问。

这些工具受到了许多的热情鼓舞,我们希望这种热情能够得到感染。 本月,我会为大家介绍一些 Microsoft 产品支持服务使用 Exchange 疑难解答助理组件的支持案例。下月,我将介绍一些 Exchange 最佳实践分析工具的成功案例。 我希望与大家分享部分在使用这些工具帮助解决支持请求时的产品支持服务成功案例。

请注意,这些示例来自这样的案例:我们在产品支持服务过程中不仅自己学会了如何使用这些工具,更重要的是意识到它们的存在。 这就是为什么您可以看到一些诸如“在不断尝试各种方法解决问题后,我运行了 Exchange 分析工具,问题立刻得到解决”的评论。 在这些情况下,支持工程师很可能已经意识到该工具的存在。

Exchange 疑难解答助理 (ExTRA) 由以下三个组件组成。

  • Exchange 性能故障排除分析工具 (ExPTA)
  • Exchange 邮件流分析工具 (ExMFA)
  • Exchange 灾难恢复分析工具 (ExDRA)

打开 Microsoft Exchange 疑难解答助理后,您可以选择性能故障排除工具、邮件流故障排除工具或数据库恢复管理。 我已经根据用于帮助解决问题的 ExTRA 组件将这些成功案例进行分类。

性能问题可能是解决起来最棘手和耗费时间的问题。 支持工程师通常不会接手一个案例并在问题解决之前不接手其他案例。 在大部分情况下,客户和支持工程师尝试不同的解决方案和检查不同的设置时在他们之间会有一些反复。 性能问题案例可能需要几个星期才能解决。

性能故障排除分析工具对于解决这些问题所需的时间长度有着重要的影响。 如果不使用 Exchange 疑难解答助理,解决一个问题平均需要 42 分钟。 而在使用 Exchange 疑难解答助理的情况下,平均时间缩短为 12 分钟。

下表显示了 ExPTA 对于解决性能问题所产生的影响。 列出的时间是支持工程师解决某一案例时记录的时间量。

 

时间或案例 使用 ExPTA 手动

平均时间

12 分钟

42 分钟

最短时间

4 分钟

3 分钟

最长时间

1 小时

16 分钟

8 小时

23 分钟

时间中位值

10 分钟

33 分钟

首次接触提交的解决方案

12 个案例

3 个案例

未解决的案例

1 个案例

19 个案例

真正吸引我注意的是,使用 ExPTA 解决案例的最长时间比不使用 ExPTA 解决案例的平均时间仅长大约 30 分钟。 另外值得注意的是,客户和支持工程师首次接触时能够解决问题的次数。 这一情况表明,用户在呼叫产品支持服务之前,使用 ExTRA 尝试解决问题的频率更高,因此我们有希望看到有关性能问题的案例数量减少。

故障现象 Outlook RPC 弹出框

根本原因 客户端 Restrict 操作

支持工程师的评论 ExPTA 报告指出客户端使用的 Restrict 操作,这是请求 Exchange 创建文件夹或文件夹组视图(事实上是一个具有相关标准的数据库表)的一部分过程。 如果文件夹或文件夹组视图已有匹配的限制,Exchange 将使用现有的视图来满足用户请求。 如果视图没有匹配的限制,Exchange 将创建一个新视图。 与使用现有视图相比,创建新视图的代价更高。 该问题在运行 ExPTA 的两天里被隔离出来。

 

故障现象 Outlook RPC 弹出框

根本原因 高数据库平均读取和写入次数

支持工程师的评论 我曾在客户面前现场使用 ExPTA。 让客户当场看到结果的感觉非常好,而以前通常需要收集和手动检查 Perfmon 数据、将每个计数器与性能白皮书中建议的阈值进行比较,再将结果提供给客户。 该工具帮助我们节省了大量用于隔离性能相关问题的工时。

 

故障现象 Outlook RPC 弹出框

根本原因 SAN 磁盘延迟

支持工程师的评论 一拿到案例,我就请求客户运行 ExPTA,问题在一天内就被隔离出来。

 

故障现象 Outlook RPC 弹出框

根本原因 Exchange 数据库服务器驱动器上的磁盘瓶颈

支持工程师的评论 一拿到案例,我就请求客户运行 ExPTA,问题在三天内就被隔离出来。

遗憾的是,我无法像对待性能问题一样提供同样的数据,来证明解决邮件流和数据库恢复问题的实际节约时间。 总之,可选择的案例相对较少,而且我们也没有机会像解决性能问题一样进行同样的研究。

故障现象 邮件在两个路由组之间的路由组连接器上排队等候

根本原因 远程服务器的 FQDN 错误

支持工程师的评论 第一个路由组中的全部四个 Exchange 服务器的队列到达第二个路由组中的两个服务器。 在应用程序日志中,将记录事件 ID 4000“无法绑定到 DNS 中的远程目标服务器”。 ExMFA 有助于我们及时解决此问题。 在更正所有 SMTP 服务器上的 FQDN 并重新启动路由服务后,邮件队列即被清除。

 

故障现象 邮件滞留在分类后队列中,InetInfo 进程占用 99% 的 CPU

根本原因 非标准的 SMTP 接收器

支持工程师的评论 ExMFA 可以使我们轻松看到服务器上的非标准 SMTP 事件接收器。 它为我们指出了问题的根本原因。

 

故障现象 邮件滞留在队列中

根本原因 默认的 SMTP 域名改变

支持工程师的评论 ExMFA 标识出默认 SMTP 虚拟服务器域的名称变化。

故障现象 邮箱和公共文件夹存储被卸除,并且无法成功装载

根本原因 E00.log 缺失

支持工程师的评论 我首先要求客户下载 ExTRA 工具并运行 DRA 向导。 然后他将 XML 输出发送给我,很明显是因为 E00.log 缺失,但是必须有该文件才能成功装载存储。 ExDRA 建议查找缺失的日志、还原备份或修复数据库。

我们在防病毒隔离文件夹中找到了缺失的日志文件,并将其还原到原始路径。 随后存储成功装载,整个恢复过程在一小时内完成。

ExDRA 节省了分析数据库头和查找缺失日志的时间和工作量。 它还为灾难恢复提供了多个建议。 客户对 ExDRA 感到十分满意,并决定在以后出现问题时继续使用该工具及其其他功能。

我会继续将 ExDRA 用于所有的灾难恢复案例中,以帮助更多的客户在更短的时间内实现灾难恢复。

 

故障现象 数据库无法装载

根本原因 日志文件被损坏

支持工程师的评论 ExDRA 为我们提供了正确的选择,使操作得以继续。 服务器于当天重新启动并正常运行。

 

故障现象 数据库无法装载

根本原因 日志文件序列到达极限 (E00FFFFF.log)

支持工程师的评论 ExDRA 提供了正确的选择,使操作得以继续。 服务器在 50 分钟内重新启动并正常运行。

大家可以看到,Exchange 分析工具在解决 Exchange 问题时十分有用。 所以,下次 Exchange Server 发生故障时,您在呼叫产品支持服务之前可以先尝试使用这些工具。 至少可以节约您在打开支持请求时为我们提供报告的时间。 最好您可以自己找到问题并动手解决,节约自己的时间和金钱。

敬请期待下个月的 Exchange 最佳实践分析工具成功案例!

 
显示: