SAPからの特定のPostScript印刷により、RPMサーバーでフラッドが発生します
この状況は少しローカライズされている可能性がありますが、問題の根本は、PostScript（および場合によっては他の種類の印刷ジョブ）をファイアウォールを通過している限り発生する可能性があることを意味します アプリケーション制御 または同様の機能がオンになっています（たとえば、リモートサイトへのVPNトンネルがあるため）。
デスクトップマシンで Brooks RPM を実行して、SAPサーバーからPostScript印刷ジョブを受け入れます。基本的には、スクリプトを適用して入力（PostScriptファイル）をPDFに変換し、Nice名を付けて、転送を容易にするために、事前にフォーマットされた件名でユーザーの電子メールアドレスに送信します。 SAPサーバーは物理的に当サイトにあります。こことリモートサイトにSAPユーザーがいて、VPNトンネルを介して接続しています（接続の詳細は関係ありません）。
ときどき、特定のドキュメントは、印刷時にサーバーに無限に繰り返される印刷ジョブを送信していました。症状は次のとおりです。
- 複数の種類のドキュメントに問題がありました
- エラーは「問題のある」ドキュメントで一貫して再現される可能性があります
- 印刷は不完全でしたが、興味深いことに、印刷ジョブの各コピーには異なる不完全性の状態がありました。
- 問題はリモートサイトでのみ発生しました
- 両端から見ると、ネットワークトラフィックは完全に正常に見え（つまり、パケットのドロップなどはありません）、他の印刷ジョブに問題はありませんでした。
この問題を解決するには、Windowsプリンタースプールサービスを停止し、％WINDIR％\ system32\pool\PRINTERSをクリアして、プリンタースプールサービスを再起動する必要がありました。そうしないと、繰り返される印刷ジョブが停止します。プリントアウトの内容が毎回異なるのはまったく奇妙だと思いました-プリントサーバーからの各障害レポートに応じて、SAPサーバーが一貫して不正な形式のPostScriptファイルを生成していると推測しましたが、SAPプリンターのスプールログを確認したところ、これは反証されました-印刷の試行ごとに、レコードに出力が1つだけありました。印刷スプーリングについての私の（確かに欠けている）理解から、コンテンツが実際に再生成されていなかったので、印刷ジョブが毎回異なるコンテンツを持つべきではありませんでした。
私は半分正しかったことがわかりました-印刷ジョブは壊れていましたが、SAPによるものではありませんでした。
tl; drバージョン：SonicWALL AppControlでした。
スクリプトを書いた人、リモートサイトの管理者、上司、そして私は自分のサイトに座って問題を解決しました。転送中に発生した問題に問題を切り分けることができました。RPMサーバーのスプール内のサンプルPSファイルが破損していましたが、PDFに変換すると、クライアントのプリンタースプール上の一致するPSファイルは完全に正常でした。さらに、リモートサイト管理者のラップトップ（彼は私のサイトに一緒にいたことを思い出してください）を使用して問題のあるドキュメントを印刷しても、洪水は発生しませんでした。
リモートマシンからフラッドをトリガーし、ネットワークチェックを再度実行しました。トラフィックは完全に正常に見えました。次に、リモートサイトの管理者が無関係のログを調べて、まったく問題があることを確認しました。
SonicWALL App Controlが印刷ジョブのトラフィックをIMファイル転送として誤って識別し、検出時に接続を切断していたことが判明しました。これは、印刷ジョブのコンテンツの不整合を説明しています。ファイアウォールでプリントサーバーをホワイトリストに登録すると、問題は解消されました。
今は当たり前のようですが、後知恵は20/20です。
したがって、要約すると、ファイアウォールを通過する印刷ジョブで問題が発生した場合は、それらが何らかのアプリケーションフィルタリングによって取得されているかどうかを確認してください。