Universal Printer (1 in 100) fails to transfer to client

[spmnemrc]

I am working with a client to resolve what we are calling a "printer stall" condition.

The client works perfectly most of the time. However every so often the Universal Printer does not send the PDF to the work station. I can still control the session perfectly on the screen, without restarting the session and after about 3 or so minutes I can print to the "Universal Printer" again and it works perfectly.

How can I troubleshoot this on the server side?

[hansen]

Which version of TSplus are you using? And which version of Windows is the TSplus server?

[spmnemrc]

TS-Plus version: 9.80.1.24
Windows Server 2012 R2

[admin]

Hello,

A 1 in 100 print jobs that fails is not quite easy to diagnose and is a pretty good average success rate if you ask me. It could be because of a network issue, a corrupted download of the print job to client's side. This can occur when the network is saturated with simultaneous download and connection requests.

[spmnemrc]

Oliver

Thank you for your time.

Every print job is important and when you do thousands a day and you receive a phone call for every 1 in 100 well you see what I mean.

I am in charge of making this right. Here is what I know so far.

When the printing stalls, the job NEVER transfers to the local client, nothing prints, nothing in queue, no error message. This is also hold true for TSPrint printers (not just Universal). The next time this happens I will do the following.

1. Try to print to the "Servers" Microsoft XPS printer.
2. Try to print in another instance of the the remoteApp in another Window.

My questions for you.

Are there service EXE's that I can examine on the server side? Are there folders I can watch on the server side?

My hunch is that every so often the print job manager cannot reconcile the session from which the job came and send it down the right pipe. How can I test this?

I have limited time to troubleshoot because it corrects itself.....so given that, what timed events might correct themselves in TSPlus with regard to print jobs, how can I troubleshoot these, are there any logs I can activate?

[John]

Hello,

Very soon now (most probably next week) we will announce the release 10.10.

The main enhancement is for the Universal Printer.

1) We will replace the OEM version of CutePDF we are using for the past 10 years by our own development.
2) We will use the RDP virtual chanels to copy the generated PDF files instead of doing a "file copy"

I suggest you to install and to test this new release when it will be ready.
Because it will be based on a completly different technology we can expect that it will fix your problem.

Kind regards

John

[spmnemrc]

John

Thanks for the reply. The PDF engine can make or break the process on the driver or rendering side. I have seen small generated PDFs rendered as 100% images with SumatraPDF clog a print queue with no way to fix it. Which ever you choose I believe it is important to have 100% control give and give users the same on both sides.

Regarding the RDP virtual chanels, TSPrint also claims to use these. In my situation (this situation) TSPrint did not work either, it was also stalled. So I am concerned about the print spooler and how is accepts and delegates print jobs and where one might get lost and how I can protect my users from it.

[spmnemrc]

This continues to be an issue for me. Today I am going to baby sit the print queue, after it arrives in the queue (Print direct to printer) and is gets removed, where is the next stop on the train? I assume at this point we have a PDF somewhere on the server. Where can I observe that?

[hansen]

As a sysadmin, I feel you pain. Great you're taking the extra step. Doesn't the event log say anything?

[spmnemrc]

I am watching the printer operational log. So far my jobs are working OK. I see the job being sent to CPWPU997 which is the port name for the CustExt in ProgramFIles (x86)\TSPlus\UniversalPrinter. From there I do not know where TSPlus creates the PDF to transfer to the connected client.