About LPD/LPR on Windows
The Line Printer Daemon protocol (LPD) and Line Printer Remote protocol (LPR) refer to a network protocol for submitting print jobs to a printer or print server, just like SMB or IPP.
Sometimes these terms are used interchangeably, but to be precise LPR refers to the protocol used by the client to send a print job, whereas LPD refers to the service running on the server.
Even though the Windows LPD Service has been deprecated with Windows Server 2012, we hear from customers that this service is occasionally still used with Unix or an ERP system like SAP to send print jobs to a Windows print server as opposed to using the more common SMB protocol.
LPD/LPR implementations are not without their quirks when working with PaperCut, so use this article as a guide to minimize unexpected behavior. Below are the main issues that we’ve encountered along with the solutions we advise.
The wrong username is associated with print jobs
One of the challenges we hear of when printing via LPD is that print jobs are logged in PaperCut with the wrong username. This may happen because an ERP system is actually submitting the print job on behalf of the user, which is why the username will appear to be “SYSTEM” or the name of the service account that the ERP system is running as.
Fortunately, with PaperCut’s Enterprise Environment Username Extraction feature it’s possible to accurately attribute these enterprise system-generated print jobs to PaperCut users.
Print jobs occasionally disappear
The other problem we hear about with LPD printing is that print jobs disappear with an error message “A print job was attempted to be unpaused” in the PaperCut logs. This may happen because the Windows Print Spooler Service is able to schedule LPR print jobs, overriding PaperCut’s ability to pause the job for analysis or Find-Me printing, at which point PaperCut attempts to cancel the rogue print job.
A simple solution is to switch from the Legacy Windows LPD Service to the PaperCut LPD Service which is fully supported and should prevent this issue from happening at all.
However, if you must use the Windows LPD Service then here’s our advice:
- Set up separate print queues (or a Find-Me print queue) exclusively for LPR printing. This makes troubleshooting much simpler because now LPR jobs have been isolated into their own print queue. Plus, you can give the print queue a share name suitable for *UNIX systems (e.g. ASCII only with no spaces).
- Pause the LPR print queue, which will prevent the Windows Spooler from bypassing PaperCut control. To do so open Print Management on the server, right click on the LPR print queue and choose Pause Printing. Normally if you do this Windows users will see a confusing balloon notification when they try to print that the queue is paused, but since you set up a separate print queue exclusively for LPR printing this won’t be a problem.
Still have questions?
Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.
Categories: Implementation / Deployment, Windows
Keywords: as400, iseries, jdedwards, lpd, legacy, mainframe, lpr limitations, lpr problems, lpd, print services for unix, “A print job was attempted to be unpaused while being held and was deleted by the system.”