Outlooklockingnetworking连接/会话？

场景：

我们有一个“自动订单”机器坐在angular落里，用Outlook 2003运行XP。它的工作是检查特定帐户上的新电子邮件，当它遇到一个它检查电子邮件正文以确定哪个客户来自（使用macros），然后在parsing附件之前检查附件中的特定订单代码，然后将.csv文件导入我们定制的ERP之前创build一个.csv文件（然后通过电子邮件发送到一个销售团队） /销售订单系统来创build订单。

问题：

机器会定期出现networking连接丢失的症状（无法连接到任何networking源）。有时几天后，有时一个多星期。电子邮件/订单处理量似乎没有链接。

附加信息：

机器.pst存储在映射的networking位置。
创build的.csv存储在映射的networking位置。
这是一个工作组，而不是一个域。
所有networking驱动器都是来自Ubuntu文件服务器的Samba共享。
我们的定制系统从数据库（MySQL）Ubuntu服务器运行。

到目前为止，

我已经换了机器（以前是Win2000）与相同的症状。
重新启动机器修复问题。
closuresOutlook，然后结束任务Outlook.exe后台进程修复该问题。
如果您closuresOutlook，而没有结束后台进程，outlook将不会重新打开（说它无法findPST文件，它不会打开任何networking位置）。
Outlook是否有某种“最大会话”将其链接到networking活动，邮件请求后不会closures？自动归档可能导致这个？
有没有一个工具来检查/显示每个outlook.exe进程正在做什么？

还没有find很多方法来解决这个问题，因为它是如此不常见…

你应该首先考虑的是这个。将PST存储在共享networking位置上，导致networking中出现无数问题，并导致networking丢失和SAN性能下降。

我会build议坚持PST本地和复制PST每天使用计划的工作，或免费工具simular我已经使用（免费PST备份（这个工具是非常共享的，所以你可能会find更好的东西））。

最简单，如果hacky，解决方法是使用计划的作业重新启动Outlook。由于重新启动Outlook修复了这个问题，所以这个问题必须与Outlook或者你运行的脚本有关，所以祝你好运。

似乎你会得到最大的里程，找出电子邮件stream量低到不存在的时间，并安排在当时每天重新启动Outlook。问题解决了，至less在这个系统着火或者掉落硬盘之前等等。但是这又是一场灾难，又是一个不同的问题。

肯定听起来像一个networking连接问题 – Outlook的MAPI连接限制为32并发连接，但看到你不使用Exchange这可能不是问题。我当然可以看到这个设置如何阻塞你的networking。

我会build议如下：

将.pst本地移动到计算机。过去你可能没有问题，但这并不意味着你将来不会。 PST文件是腐败臭名昭着，所以帮自己一个忙，并采取networking等式。
创build一个简单的批处理脚本，将.pst文件复制到您的networking共享中，并使用任务计划程序按照您希望的方式运行。

如果你真的想看看发生了什么，你应该尝试使用Wireshark这样的软件来监视你的networking，这将有助于你更好地了解你的networking在这个问题发生的时候正在做什么。一个简单的方法也可以查看任务pipe理器中的networking使用情况 – 如果您看到尖峰stream量，那么在共享驱动器上写入PST可能是问题。