PaperCut LPD Service

KB Home   |   PaperCut LPD Service

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:

  • Mac Clients/Servers
  • Linux Clients/Servers
  • AS400 Servers
  • Mainframes
  • …any other client or server that supports LPR printing (LPD is the ‘server’, LPR is the client)
  • Bypass any authentication requirements to print to a Windows Server

Installing the PaperCut LPD Service

PaperCut v15.1 or later server installations will ship the PaperCut LPD Service with a wizard style installer.

[appath]\providers\lpd\win\pc-lpd-installer.exe

The LPD Service listens on port 515 by default, so Administrators need to ensure network security services or the print server’s firewall don’t interfere with connections to the port. The installation wizard also checks for the Windows LPD Service and disables it to prevent port conflicts.

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’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 an LPD 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 work.

Note: Some systems won’t allow spaces in queue names, so a share or queue name that does not include spaces improves the likelihood of connection.

An example in CUPS

  1. Log into the CUPS Administration UI by pointing your client computer’s web browser to http://localhost:631/.
  2. Click Administration >> Add Printer
  3. Scroll to Other Network Printers and choose ‘LPD/LPR Host or Printer’
  4. Enter the connection string formatted like one of these examples:
    lpd://hostname/queue
    lpd://10.100.65.38/Global
    Noting again, queue name can be either the share name or print queue name on the Print Server and should not contain spaces.
  5. Finish creating the CUPS queue by entering the Name, Description, Location etc.
  6. Choose the driver and finish the install with Add Printer

Next steps

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 job to, you may need to consider additional PaperCut features like:

Troubleshooting

Q Print jobs don’t come out. They 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 print queue. The way the Windows Print Spooler works with these new drivers means jobs from Linux or macOS clients won’t print, and in this situation, we recommend using equivalent Type 3 drivers. If your organization has a requirement for Type 4 drivers (e.g. WindowsRT), we suggest duplicating the print queue with a Type 3 driver.

Q 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 in the print queue.


Categories: Architecture, Implementation / Deployment


[-Keywords: PSFU, Print Services for Unix, Windows TCP/IP Services, LPD, LPR]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on September 20, 2018, at 11:43 PM
Printable View   |   Article History   |   Edit Article