PaperCut Line Printer Daemon (LPD) Service
Last modified on 11 August 2020 04:24 PM
Administrators building a print network to support cross platform printing have long relied on the Windows LPD Services as a convenient way to get print jobs onto a Windows Print Server from a variety of clients. Historically, this service was provided by Windows from Windows NT onwards to support printing from Unix systems.
One of the attractive features of this type of interoperability is that clients connecting to the LPD service aren’t required to authenticate. The LPD service will simply accept print jobs with little scrutiny via this service and print them to end devices using the queues the server hosts.
With Microsoft announcing that the LPD service will shortly be deprecated, PaperCut now ships with its own LPD Service, to continue support for this method of print networking, and to provide end-to-end support for customers that use PaperCut and LPD.
Using the PaperCut LPD Service
The PaperCut LPD Service allows print network administrators to connect disparate systems to a Windows Print Server, allowing the server to accept jobs from:
Installing the PaperCut LPD Service
PaperCut v15.1 or later server installations will ship the PaperCut LPD Service with a wizard style installer.
The LPD Service listens on port 515 by default, so Administrators will need to ensure that this port is open to requests from clients (check that the port is not blocked by your firewall). The installation wizard will also check for previous versions of the Windows LPD Service also, and disable these to ensure there is no port conflict.
Note: The PaperCut LPD Service requires that you share the printer before being able to connect to it via LPR. This is different from Microsoft’s implementation, but provides an extra level of control over which queues can be printed to via LPR. No permissions need to be set on the queue, so Windows users can still be prevented from connecting to these shares.
Connecting to an LPD Service
Most operating systems, including Windows, support connecting to an LPD Service via the LPR printing protocol. The information you will need is;
Note: Some systems won’t allow spaces in queue names, so a share or queue name that does not include spaces will improve likelihood of connection.
An example in CUPS
Print jobs will be accepted via LPD into the Windows printing system.
It’s important at this point to consider how the print jobs are being tracked. The print jobs will be sent with the username from the client system: i.e. the Unix, Linux, Mac, etc username associated with the print job. If the username isn’t consistent with the Windows username you wish to bill the job for, you may need to consider additional PaperCut features like:
Print jobs don’t come out. They just disappear!
The most likely reason for this is the use of Mode 4 or Type 4 printer drivers on the Windows Print queue. Due to changes in the way the Windows Print Spooler works with these new drivers you can not use a Non-Windows Mode 4 driver to print to the queue.
In this situation we recommend that you use Mode 3 or Type 3 drivers.
Why do jobs fail when non-ASCII characters are used in either the jobname or the username?
Check out this article on: Fixing encoding problems/unintelligible characters appearing in PaperCut LPD job queue