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.
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.
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.
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.
While waiting for the issue to happen it can be a good idea to seek clarity on the problem.
Depending on the nature of the problem, the bare minimum information for us to help is:
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 firstname.lastname@example.org