Life in the trenches of support can be rewarding, no one gets a support gig without a desire to help people.

A lot of support (for any product) is working logically to diagnose where the issue may lay. That also includes a fair amount of politely trying to point out it is not your product that is the issue and it is the customer’s server/network/DNS/firewall/proxy/firmware etc, always a tough conversation when the perception is that PaperCut is the problem because, to the customer, PaperCut = Printing. Not an unreasonable assumption, but chances are the same issue will be there if PaperCut was not installed (and what a miserable world that would be!).

A good test is to turn off the PaperCut print provider service, without this service PaperCut will not track or be aware of any print jobs. Or, simply ignore the problem print queue (a less destructive option), this will allow your users to carry on printing to other queues without problems.

What went wrong?

Popular support problems include “Printing is slow” or “Print jobs disappeared”. Slow or missing print jobs have pretty much, always been down to the driver and queue settings so… make sure you are using the same print language between the virtual queue and physical queues and check that advanced printing features and bi-directional support is disabled. Also, make sure the drivers are up to date and not type 4. Or better yet have a read of our best practices guide for Windows print servers and you will be off to a good start.

Get the ball rolling

If you encounter any oddities with printing, print release or incorrect page counting issues start with the following…

First up, enable debugging within PaperCut in two places. The two places are the PaperCut Application Server and PaperCut Print Provider.

Enabling debug in the application server is just a tick box, the full instructions are here. The default log collection size of 2GB is good enough for most sites but if the problem is rare or the customer has a lot of print queues/embedded devices then feel free to increase that size (go for 4GB).

More importantly, for print issues, we need to enable debug in the print provider. This step is vital when troubleshooting print problems. Without debugging switched on the default logs won’t contain much in the way of useful data. The print provider does all the ugly work behind the scenes and contains all print activity for the server. Make sure this is enabled for the server with the problem queue.

Last of all, if you are having issues on a Windows server please get the event viewer tracking print jobs as per this page https://www.papercut.com/kb/Main/LogPrintJobsInEventViewer
We do this because, If we can see what the OS thinks happens to the print job then it helps with the troubleshooting process.

If you check the debug log for the print job in question you can see the Job ID, this ID is the same ID assigned by the OS to the print job so you can easily find it in the event viewer.

Recreate (or wait…)

In an ideal world, you would be able to recreate the problem on demand and send us the log files. Annoyingly life does not always work out like that so leave debug on and be sure to flag any issues. Once you have enabled debug etc either reproduce the error (if possible) or wait until the error reproduces itself, this may involve the customer being aware so they can look out for the issue and report when it happens. How to find the correct logs and what to send us is all included in the links above.

When working through issues like this the more context around the issue we receive the better for us. Ideally, we would want the debug logs from the app server and print provider as well as an export of the Windows event viewer, more importantly, the logs should cover the time frame the issue happened in.

Troubleshooting

While waiting for the issue to happen it can be a good idea to seek clarity on the problem.

• Does it happen to more than one user/computer (is the issue with a certain user or machine or perhaps from a certain application?)
• Try printing as a domain admin or from the PaperCut server, do you get the same results?
• What happened to the print job (Always good to know, did it print? did papercut log it as printed/canceled/refunded?)
• What did the devices own logs say happened to the print job? (MFD’s are very clever and will contain their own internal job log. Take a look, it could help work out what went on)
• If it is a page count problem, grab the driver and install it on a laptop running the latest version of PaperCut, does the same thing happen?

What to collect

Depending on the nature of the problem, the bare minimum information for us to help is:

• Description of the problem (context is king)
• Date and time of the print job (ever looked through 900MB of log files? being able to narrow it down keeps support teams sane when looking at all those tabs in Notepad++)

• Name of the user that had the issue (refines the search)
• Name of the print job that caused the problem (and again)
• Name/IP of the printer the job was released from (good to verify)

A screenshot of the “Job log” tab showing the problem print job will provide a lot of this information, so if possible please include one.

The more pieces of the puzzle we receive the quicker we can join the corners and make progress. Once we have files we will follow the job through the logs to work out what happened and advise accordingly.

Need technical help? reach out to the team on support@selectec.com