Certas impressões PostScript do SAP causam sobrecarga no servidor RPM

Question

Esta situação pode ser um pouco localizada, mas a raiz do problema significa que pode acontecer desde que você esteja passando o PostScript (e possivelmente outros tipos de trabalhos de impressão) através de um firewall com Controle de aplicativos ou um recurso semelhante ativado (digamos, porque você tem um túnel de VPN para um site remoto).

Executamos o Brooks RPM em uma estação de trabalho para aceitar trabalhos de impressão PostScript do nosso servidor SAP. Basicamente, ele aplica um script para converter a entrada (um arquivo PostScript) em PDF, dar um nome legal e enviá-lo para o endereço de e-mail do usuário com uma linha de assunto pré-formatada para facilitar o encaminhamento. O servidor SAP está fisicamente localizado em nosso site. Tenho usuários SAP aqui e em um site remoto, ao qual estamos conectados por meio de um túnel VPN (os detalhes da conexão são irrelevantes).

De vez em quando, certos documentos enviavam trabalhos de impressão repetidos infinitamente para o servidor quando eram impressos. Os sintomas foram os seguintes:

• Mais de um tipo de documento teve o problema
• O erro pode ser reproduzido de forma consistente nos documentos "problemáticos"
• A impressão estava incompleta, mas é interessante que cada cópia do trabalho de impressão tivesse um estado diferente de incompletude
• O problema ocorreu apenas no site remoto
• De ambas as extremidades, o tráfego de rede parecia totalmente normal (ou seja, nenhum pacote descartado, etc.) e nenhum outro trabalho de impressão estava tendo problemas

Para corrigir o problema, tivemos que interromper o serviço de spool de impressora do Windows, limpar% WINDIR% \ system32 \ spool \ PRINTERS e reiniciar o serviço de spool de impressora - somente depois os trabalhos de impressão repetidos parariam. Achei totalmente estranho que as impressões tivessem conteúdo diferente a cada vez - imaginei que o servidor SAP estava produzindo consistentemente arquivos PostScript malformados em resposta a cada relatório de falha do servidor de impressão, mas isso foi refutado quando verificamos o log de spool de impressora SAP - havia apenas uma saída registrada para cada tentativa de impressão. Do meu (reconhecidamente carente) entendimento de spooling de impressão, os trabalhos de impressão não deveriam ter conteúdo diferente a cada vez, já que o conteúdo não estava realmente sendo regenerado.

Acontece que eu estava meio certo - os trabalhos de impressão foram desconfigurados, mas não pela SAP.

    

Answer 1

tl; versão dr: era o SonicWALL App Control.

O cara que escreveu o script, o administrador do site remoto, meu chefe e eu nos sentamos no meu site para resolver o problema. Conseguimos isolar o problema a algo que está acontecendo em trânsito - um arquivo PS de amostra no spool do servidor RPM estava corrompido, mas o arquivo PS correspondente no spool de impressora do cliente estava perfeitamente bem quando o convertemos em PDF. Além disso, usar o laptop do administrador do site remoto (lembre-se, ele estava conosco no meu site) para imprimir um documento com problema não provocou uma inundação.

Nós desencadeamos uma inundação de uma máquina remota e fizemos uma verificação na rede novamente - o tráfego parecia totalmente normal. Em seguida, o administrador do site remoto deu uma olhada em um log não relacionado e viu algo totalmente errado:

O SonicWALL App Control identificou incorretamente o tráfego dos trabalhos de impressão como uma transferência de arquivo IM e cortava a conexão após a detecção - isso explica a inconsistência do conteúdo dos trabalhos de impressão. Depois de colocarmos o nosso servidor de impressão no firewall, o problema desapareceu.

Parece óbvio agora, mas retrospectiva é 20/20.

Então, em resumo: se você está tendo problemas com trabalhos de impressão que passam por um firewall, verifique se eles estão sendo apanhados por qualquer tipo de filtro de aplicativos.