“Help! I’m an IT System Administrator that needs to provide unauthenticated printing from multiple systems and clients to a Windows Server! How do I achieve this?”
If your requirements don’t involve unauthenticated printing, we would recommend for you take to take a look at PaperCut NG/MF’s alternative features to enable macOS and Linux printing:
What’s this all about then?
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, similar to 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.
IT System Administrators building a print network to support varying systems (such as Windows, macOS, Linux etc.) have long relied on the Windows LPD Services as a convenient way to get print jobs onto a Windows Print Server. One of the attractive features of LPR is the interoperability 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.
This service is provided by Microsoft, but with the advent of Windows Server 2012 the original Windows LPD Service has since been deprecated. The LPD service on Windows Server can still be used - but at some point in the future it may be removed. At PaperCut we see environments where these protocols are used when there is a significant mix of clients are present, such as:
- macOS Clients/Servers.
- Linux Clients/Servers.
- AS400 Servers.
- Mainframes.
- ERP systems (such as SAP).
LPD/LPR implementations are not without their quirks though when working with PaperCut NG/MF, so use this article as a guide to minimize these unexpected behaviors.
PaperCut LPD Service
Installation
From v15.1 onwards, PaperCut NG/MF comes bundled with the PaperCut LPD Service with a wizard style installer. The installer file is located here: [app-path]\PaperCut NG/MF\providers\lpd\win\pc-lpd-installer.exe
The PaperCut LPD Service listens on port 515 by default, so IT System Administrators need to ensure network security services or the print server’s firewall don’t interfere with connections to this port. The installation wizard also checks for the Windows LPD Service and disables it to prevent port conflicts.
Please note: Unlike Microsoft’s implementation, the PaperCut LPD Service requires sharing the printer for clients to be able to connect to it via LPR. Through the application’s print queue monitoring and restriction abilities, PaperCut NG/MF’s implementation provides an extra level of control over print queue sharing over LPR. There isn’t a requirement for permission settings on the queue, so Windows users can still be prevented from connecting to these shares.
Connecting to the service
Most operating systems, including Windows, support connecting to an LPD Service via the LPR printing protocol. Here is the information you need:
- The address of the server running the PaperCut LPD Service.
- The name of the queue. (Either the share name or queue name will work.)
Please note: Some operating systems won’t allow spaces in the queue name, so a share or queue name that does not include spaces greatly improves the likelihood of a connection.
Example - CUPS (macOS & Linux)
- Login to the CUPS Administration web UI by pointing your client computer’s web browser to http://localhost:631.
- Click Administration >> Add Printer
- Scroll to Other Network Printers and choose LPD/LPR Host or Printer.
- Enter the connection string using either or a Hostname or IP Address, such as: lpd://hostname/queue or lpd://10.100.65.38/Global
- Finish creating the CUPS queue by entering the Name, Description, Location etc.
- Choose the driver and finish the install with the Add Printer button.
Final considerations
It’s important at this point to consider how print jobs are tracked. LPD/LPR jobs are sent with the username belonging to the client machine’s current log-on session. If the log-on username isn’t consistent with the PaperCut username you wish to bill the print job to, you may need to consider additional PaperCut NG/MF features like:
- Username aliasing.
- Unauthenticated printing.
- Enabling the ‘Override user-level settings’ at a given queue and charging all jobs to a given Shared Account if this queue services a single account.
Troubleshooting
PaperCut LPD Service
Can I remove the IP address from the username seen in the Windows print queue?
Heck yes! The PaperCut LPD Service added an option in the pc-lpd.config file to enable the host address to be removed from the job owner’s name (RemoveHostAddress = true).
Why do print jobs fail when non-ASCII characters are used in either the print job name or the username?
Check out this article on fixing encoding problems in the relevant print queue.
[Legacy] Windows’ LPD Service
The print jobs don’t come out of the printer and just disappear. What’s going on?
The most likely reason for this is the use of “Class”, “Mode 4,” or “Type 4” printer drivers on the Windows server’s print queue. The way the Windows Print Spooler works with these newer types of drivers means jobs from macOS or Linux clients won’t print.
If you’re in this situation, we recommend using an equivalent Type 3 driver from the same driver manufacturer. If your organization has a requirement for Type 4 drivers, we suggest duplicating the print queue with a Type 3 driver in this scenario.
The wrong username is associated with the print jobs, what gives?
One of the challenges we hear of when printing via the LPD protocol is that the print jobs are logged in PaperCut NG/MF 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 NG/MF’s Enterprise Environment Username Extraction feature it’s possible to accurately attribute these enterprise system-generated print jobs to PaperCut users.
Sometimes we see print jobs disappear occasionally, what’s happening?
The other problem encountered with Windows LPD printing is when print jobs disappear with an error message “A print job was attempted to be unpaused” in the PaperCut NG/MF logs. This may happen because the Windows Print Spooler service is able to resume LPR print jobs which PaperCut NG/MF has paused for analysis or Find-Me printing, at which point PaperCut NG/MF attempts to cancel the resumed job.
If after reading this article you decide that you still must use the deprecated Windows LPD Service then here’s our advice to avoid problems:
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, this will prevent the Windows Spooler from bypassing PaperCut NG/MF’s control. To do this:
- Open PrintManagement.msc on the Windows 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.