A lot can happen to a print job as it finds it’s way from client to server and then to a paper tray on a device. Even before you throw in a world class print management solution such as PaperCut, Linux to Windows printing Gremlins can hijack a print job and cause merry hell.

Printing to Windows servers from Linux using LPR

In the following example our problem is printing from Linux via LPR to a Windows based virtual print queue is causing some print jobs to go missing. The jobs go to a central find-me virtual queue, and the MFD’s are set up to look at this queue so they can release jobs, nothing unusual here. In this scenario, the stand out part of the setup that may cause issues is the cross-platform printing. Not impossible but not without its niggles.

In situations like this, a lot of thoughts will run through the heads of our support team. Jobs going missing is not by design and more than likely our first idea is to suggest (in the nicest of ways) that it’s nothing to do with PaperCut. It just so happens PaperCut is the release mechanism for these jobs, and it highlights the problem. It’s not that we are overly precious about products we sell and support, but sometimes we have to go back a step and eliminate the basics first.

Step one – Rule out PaperCut (hopefully)

Anyone that has ever sent us a printing problem support ticket will know that getting PaperCut to ignore a queue or turning off the PaperCut print provider service (the bit that does all the ugly behind the scenes tracking) is a great test to help work out where the issue is. If it is still a problem without PaperCut owning the job, then the problem could well be network, driver or device related.

In our example above we have Linux to Windows printing and “some” (not all) jobs going missing. It would be much nicer from a support POV if all jobs went missing the “some” part is the sort of thing that makes it tricky. As it only impacts some jobs, we would need to delve into some logs or ask for them if not already provided.

For strange print problems like this the minimum information we would want is as follows:
Have PaperCut debug logs, The two places to enable debug are the PaperCut Application Server and PaperCut Print Provider.

With debugging on it makes the PaperCut logs include more details that may shine a light on the problem. If it is a rare problem, then you may need to increase the amount of logs PaperCut captures. By default, modern versions of PaperCut keep up to 2048MB of log files and splits them up into 40 files roughly 50MB in size. You can see these in this folder:
C:\Program Files\PaperCut MF\server\logs

Grab OS logs

There is also value in obtaining the Operating Systems print logs as well. By default, print jobs on Windows Server are not logged in the Windows Event Viewer. Why this is, I have no idea, but it can be useful when troubleshooting.
On Windows Server 2008/2012 you need to go to Event Viewer. Then click Applications and Service Logs, then find print services under Microsoft –> Windows once there click Operational and enable log. It is well worth creating a custom view and allowing all the options to be recorded.
With all of the logs above and some details around the date/time/user/print job name etc. of the support issue, we are onto a good start. These extra details assist us when looking through log files.

What to look for?

On checking any logs, you can take a look at the very top of the server.log and will see some interesting data (example below).

017-02-09 11:54:07,956 INFO AppServer:166 - Starting application server version: 16.4 (Build 39158), Edition: MF, Platform: Microsoft Windows Server 2016 Standard - 10.0 64-bit [runtime: 1.8.0_92-b14 (amd64)], User: SYSTEM [WrapperSimpleAppMain]
2017-02-09 11:54:08,003 INFO AppServer:180 - System details - max memory: 1,820.5 MB, processors: 2, database: Derby, home: "C:\Program Files\PaperCut MF\server", free space: 187,740.3 MB, hostname: PAPERCUT, IP addresses: [10.51.1.69, 10.66.66.2, fe80:0:0:0:5946:6f7:7959:13d0%eth1, fe80:0:0:0:c5bb:6897:4b3b:9065%eth2] (Primary: 10.66.66.2), Server ID: 9ae36005-cb29-4b18-80ea-18f669a8c3d4, time-zone: Europe/London, calendar: GregorianCalendar, locale: en_GB, encoding: windows-1252 [WrapperSimpleAppMain]

This tells us some important information about the setup such as version (and build), server spec, database type etc. We then use various tools to filter out the noise and check for anything obvious such as:

• Under spec server (low memory or only 1 cpu core etc)
• Are they running an old OS or version of PaperCut?
• Time-stamps  in the logs out of order
• Errors and warning codes

What is the issue?

In this example, the stand out problem from the logs was the following repeated line:
PaperCut TCP/IP Port has detected that job (number) on printer “Find-me-virtual” has been resumed outside of PaperCut’s control. Printing of this job will be prevented.
This message also appears within the PaperCut Admin UI to assist in identifying problems easily.
This message tells us they are using a PaperCut TCP/IP Port and gives us the name of the queue. PaperCut has reported that something (or someone) has tried to gain control over the print job and because of this PaperCut has removed the job from the queue. It could be that a user has sufficient rights on the print queue to attempt to resume the print jobs paused in the queue. It may also be a 3rd party application such as another print management service tried to take control of the job. In this example, we are going for a different option that is causing random jobs to go missing.

PaperCut LPD to the rescue

After checking some details, we learn the customer is using the built in Windows LPD service to handle the print jobs. Using the Windows LPD service is not unusual in customers running Enterprise Linux systems that generate print jobs. LPD setups can get upset when features such as secure print release and virtual find-me queues are used.

The PaperCut Dev team developed their own LPD service to work around these idiosyncrasies, and you can read more and download it here.

The Windows LPD service has not changed much over the years which is why PaperCut created their own that is updated and supported when needed.

Running the PaperCut LPD version should solve the problem of PaperCut deleting these jobs.
We would also suggest that the virtual queue be set up to use LPT1 or a Nul port instead of using the PaperCut TCP/IP port. No print jobs should ever print from the Virtual find-me queue and the PaperCut port was designed for use with hardware checking and its just needed on the target printer queue in that instance.
Some useful links for reference:

• http://www.PaperCut.com/kb/Main/PrintQueueSetUpOnWindows
  
• http://www.PaperCut.com/kb/Main/PaperCutLPDService
• http://www.PaperCut.com/kb/Main/AttemptedToBeUnpaused

Depending on the results of printing without PaperCut we would have also looked into the driver to see if printing using another driver or to another device brand worked ok. With any troubleshooting it is often about finding out as many facts as possible, the more context we receive, the better we can assist with fixing.

As always, if you run into problems then get in touch.