我们有一个前端MS Exchange 2003服务器，最近人们开始抱怨电子邮件没有被交付。 仔细查看日志，我们发现这个错误信息：
> Event Type: Error > Event Source: Service Control Manager > Event Category: None > Event ID: 7031 > Date: 6/4/2009 > Time: 11:08:00 AM > User: N/A > Computer: <Server> > Description: > The IIS Admin Service service terminated unexpectedly. It has done > this 39 time(s). The following > corrective action will be taken in 1 > milliseconds: Run the configured > recovery program. 我们发现MS知识库文章Q304166 ，并能够确定哪些邮件Exchsrvr \ Mailroot \ vsi 1文件夹中通过一次删除它们并重新启动服务导致问题。
造成这一切破坏的电子邮件是一个通过电子邮件发送到3500个地址的200K PDF文件。 为什么交易会如此糟糕？ 我意识到3500是大量的人发邮件，但我会猜测，SMTP服务器会扼杀连接，并在晚上或甚至几天慢慢发送这封电子邮件。
我的问题：
Exchange中有没有一种方法可以确定最大的SMTP负载？ 有没有其他人看到这种相同的反应，或者我们应该在服务器上寻找configuration错误？
当/如果我们需要再次发送到一个大的组，有没有办法来衡量多less服务器可以在一个批处理，或者我需要用户Perfmon，并开始testing，看看它是如何处理100,250,400等？
这不是一个容量问题 – 这是一个错误。 应用程序中的任何未处理的exception都是一个错误。 （不要让开发者另外告诉你。）
你目前正在修补吗？
编辑：听起来像你find了一个错误，如果你能repro问题。 我不知道如何实际向微软报告这样的错误，但可能需要报告。
这绝对是一个错误。 Exchange 2003中的SMTP引擎实际上构build为一组由IIS SMTP引擎加载和运行的扩展。 如果w3svc崩溃，最有可能的原因是邮件格式不正确（包括地址不正确或收件人服务器行为不正常），而不是因为文件大小或收件人数量而产生负载。
如果您想进一步testing，可以让用户将消息发送到原始3500的较小的子组，以缩小问题的范围。
服务器不应该坠毁在这个。 我会打电话给MS跟进，我已经有MS支持的很好的经验，它非常值得。 如果你用MS支付一张票，问题就变成了他们的错（如此），他们就退还票。
作为一个便笺，你可以从MS购买technet plus，这个成本低于2个支持事件的成本，而technet plus包括2个支持呼叫以及访问testing软件和被pipe理的新闻组。