来自SAP的某些PostScript打印在RPM服务器上导致泛滥

这种情况可能有点局限性，但问题的根源意味着，只要您通过具有应用程序控制或类似function的防火墙传递PostScript（可能还有其他types的打印作业），就可能发生这种情况（说，因为你有一个到远程站点的VPN隧道）。

我们在台式机上运行Brooks RPM以接受来自SAP服务器的PostScript打印作业。基本上，它应用脚本来将input（PostScript文件）转换为PDF，给它一个不错的名字，并将其发送到用户的电子邮件地址，带有预格式化的主题行以便于转发。 SAP服务器位于我们的网站上。我在这里和远程站点都有SAP用户，我们通过VPN隧道（连接的细节无关紧要）连接到这个站点。

有一段时间，某些文档在打印时向服务器发送无限重复的打印作业。症状如下：

不止一种types的文件有问题
错误可以在“问题”文件上一致地复制
打印输出不完整，但有趣的是，每一份打印作业都有不完整的状态
该问题只发生在远程站点
从两端，networkingstream量看起来完全正常（即没有丢包等），没有其他打印作业有问题

要解决这个问题，我们必须停止Windows打印机假脱机服务，清除％WINDIR％\ system32 \ spool \ PRINTERS并重新启动打印机假脱机服务 – 只有这样重复的打印作业才会停止。我发现每次打印输出都会有不同的内容，这让我觉得奇怪 – 我猜测SAP服务器一直在生成格式不正确的PostScript文件，以响应来自打印服务器的每个故障报告，但是当我们检查SAP打印机假脱机日志 – 每次打印尝试只有一个logging输出。从我对打印假脱机的理解（当然缺乏）来看，每次打印作业都不应该有不同的内容，因为内容实际上没有被重新生成。

事实certificate，我是对的 – 印刷工作被打破，但不是由SAP。

tl; dr版本：这是SonicWALL应用程序控制。

写剧本的人，远程站点的pipe理员，我的老板和我坐在我的现场解决问题。我们设法将问题隔离到传输中发生的问题 – RPM服务器后台打印中的示例PS文件已损坏，但当我们将其转换为PDF时，客户打印机后台打印机上匹配的PS文件是完全正确的。此外，使用远程站点pipe理员的笔记本电脑（请记住，他与我们在我的网站）打印问题文件没有触发洪水。

我们从远程机器触发了洪水，再次进行了networking检查 – stream量看起来完全正常。然后，远程站点pipe理员看了一个不相关的日志，看到了一些完全closures的东西：

假阳性

事实certificate，SonicWALL应用程序控制不正确地将打印作业的stream量识别为IM文件传输，并在检测时切断连接 – 这解释了打印作业内容的不一致性。一旦我们将我们的打印服务器列入防火墙，问题就消失了。

现在看起来很明显，但后见之明是20/20。

因此，总之：如果您在通过防火墙的打印作业中遇到问题，请检查它们是否被任何types的应用程序过滤。