Implementing LPD/LPR on Windows with PaperCut

KB Home   |   Implementing LPD/LPR on Windows with PaperCut

Main.LPROnWindows History

Hide minor edits - Show changes to output

July 31, 2018, at 08:02 PM by Aaron Pouliot - Clarifications from Alan
Changed lines 10-12 from:
When working with PaperCut, LPD/LPR implementations are not without their quirks, 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.

!!!Wrong username associated with print jobs
to:
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
Changed lines 17-19 from:
!!!Disappearing print jobs
The other problem we hear about with LPD printing is that print jobs disappear with an error message “[[https://www.papercut.com/kb/Main/AttemptedToBeUnpaused|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, sometimes overriding PaperCut’s ability to pause the job for analysis or Find-Me printing.
to:
!!!Print jobs occasionally disappear
The other problem we hear about with LPD printing is that print jobs disappear with an error message
“[[https://www.papercut.com/kb/Main/AttemptedToBeUnpaused|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.
Changed line 25 from:
* Pause the LPR print queue, which will prevent the Windows Spooler from bypassing PaperCut control.  To do so, open Print Management console 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.
to:
* 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.
July 31, 2018, at 07:56 PM by Aaron Pouliot - fixed typo
Changed line 4 from:
The Line Printer Daemon protocol (LDP) 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.
to:
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.
July 31, 2018, at 07:54 PM by Aaron Pouliot - Overhauled article with input from Alan
Changed lines 1-3 from:
(:title Using LPD/LPR with Windows and PaperCut:)

!!About LPD/LPR Printing
to:
(:title Implementing LPD/LPR on Windows with PaperCut:)

!!About LPD/LPR on Windows
Changed lines 10-11 from:
When working with PaperCut, LPD/LPR implementations are not without their quirks, so use this article as a guide to minimize unexpected behavior.
!!Wrong username associated with print jobs
to:
When working with PaperCut, LPD/LPR implementations are not without their quirks, 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.

!
!!Wrong username associated with print jobs
Changed lines 16-17 from:
!!Disappearing print jobs
to:

!
!!Disappearing print jobs
July 31, 2018, at 07:50 PM by Aaron Pouliot - Overhauled article with input from Alan
Changed lines 16-19 from:
The other problem we hear about with LPD printing is that print jobs disappear with an error message “[[https://www.papercut.com/kb/Main/AttemptedToBeUnpaused|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, sometimes overriding PaperCut’s ability to pause the job for analysis or Find-Me printing.
to:
The other problem we hear about with LPD printing is that print jobs disappear with an error message “[[https://www.papercut.com/kb/Main/AttemptedToBeUnpaused|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, sometimes overriding PaperCut’s ability to pause the job for analysis or Find-Me printing.
Changed lines 20-23 from:
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 console 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.
to:
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 console 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.
July 31, 2018, at 07:49 PM by Aaron Pouliot - Overhauled article with input from Alan
Changed lines 1-25 from:
(:title Implementing LPR connections to Windows print queues:)

LPR connections to Windows print servers are useful in organizations running Unix/SAP/enterprise systems that generate printing that should be tracked through PaperCut, where those systems cannot connect to Windows print queues via normal SMB. Commonly, the enterprise systems are configured to print via LPR to the shared Windows print queues, rather than directly printing to devices.

LPR implementations are not without their quirks, especially when dealing with advanced print functionality like Secure Print Release and Find Me printing. Use this article as a guide when performing such an implementation to minimize unexpected behavior.

* [[https://www.papercut.com/kb/Main/PrintQueueSetUpOnWindows|Remove Creator/Owner permissions]]: Windows LPR can attempt to resubmit a job to the printer port; this will remove the ability for
the print workflow to be affected by this behavior.

* [[https:
//www.papercut.com/products/ng/manual/ch-find-me-printing-and-load-balancing.html|Use Find-Me printing]]: This will usually be a requirement of sites which use enterprise systems, but if not, the use of a virtual queue as the destination of the LPR connection makes controlling the behavior of jobs submitted LPR significantly less complicated.

* When using Find-Me printing create a separate Global Virtual Queue for LPR jobs.  Don't reuse an existing queue used for jobs sent in via
the standard Windows printing protocol.  For example, call the queue "global-queue-lpr". There are a number of reasons for this:
** It gives you an opportunity to use a simpler name more suitable for *UNIX basis systems (e
.g. ASCII only with no spaces).
** It isolates LPR jobs into a separate queue - this can help you diagnose problems
.
** It's advised to set the queue to a "paused" state (see following steps).  If the same queue is shared by Windows users (who can see the state), it may confuse them.  

* Ensure
the printer port of the virtual queue is set to a port that is not connected to a real printer. For example, set to to an unused [@LPT1@] port. This will assist in denying any attempt by Windows LPR to progress the job without proper PaperCut control. Do not set this port to [@NUL@] or equivalent, as this will almost certainly lead to missing print jobs.

* Pause the virtual
print queue. As no job should ever progress through the virtual queue to the print port, this is an additional safeguard against Windows LPR bypassing PaperCut control.

* Finally
, it is possible to accurately attribute these enterprise system-generated print jobs to PaperCut users via the use of [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-external-usernames.html|Enterprise Environment Username Extraction]].

If you have followed above suggestions and are still receiving an error of "A print job was attempted to be unpaused while being held and was deleted", please contact ''support@papercut
.com''

''Note:'' PaperCut Software is aware of the limitations with the LPR implementation on Windows, and we are aware that the LPR implementation
is a legacy service. Alternatives are being investigated, however the recommended configuration above, although complex, has been proven in production use for a number of years among many customer sites.
to:
(:title Using LPD/LPR with Windows and PaperCut:)

!!About LPD/LPR Printing
The Line Printer Daemon protocol (LDP) 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. 

When working with PaperCut, LPD
/LPR implementations are not without their quirks, so use this article as a guide to minimize unexpected behavior.
!!Wrong username 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 [[https://www
.papercut.com/support/resources/manuals/ng-mf/applicationserver/topics/printer-external-usernames.html|Enterprise Environment Username Extraction]] feature it’s possible to accurately attribute these enterprise system-generated print jobs to PaperCut users.
!!Disappearing print jobs
The other problem we hear about with LPD printing is that print jobs disappear with an error message “[[https://www.papercut.com/kb/Main/AttemptedToBeUnpaused|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, sometimes overriding PaperCut’s ability to pause the job for analysis or Find-Me printing.

A simple solution is to switch from the Legacy Windows LPD Service to the [[https://www.papercut.com/kb/Main/PaperCutLPDService|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 console 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 [[https://support.papercut.com|Support Portal]] for further assistance.
 
Changed line 31 from:
''Categories:'' [[Category.Implementation|+]], [[Category.Troubleshooting|+]]
to:
''Categories:'' [[Category.Implementation|+]], [[Category.Windows|+]]
Changed line 29 from:
[-Keywords: as400, iseries, jdedwards, lpd, legacy, mainframe, lpr limitations, lpr problems, lpd, print services for unix-]
to:
[-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."-]
Changed lines 3-10 from:
LPR connections to Windows print servers are useful in organisations running Unix/SAP/enterprise systems that generate printing that should be tracked through PaperCut, where those systems cannot connect to Windows print queues via normal SMB. Commonly, the enterprise systems are configured to print via LPR to the shared Windows print queues, rather than directly printing to devices.

LPR implementations are not without their quirks, especially when dealing with advanced print functionality like Secure Print Release and Find Me printing. Use this article as a guide when performing such an implementation to minimize unexpected behaviour.

* [[https://www.papercut.com/kb/Main/PrintQueueSetUpOnWindows|Remove Creator/Owner permissions]]: Windows LPR can attempt to resubmit a job to the printer port; this will remove the ability for the print workflow to be affected by this behaviour.

* [[https://www.papercut.com/products/ng/manual/ch-find-me-printing-and-load-balancing.html|Use Find-Me printing]]: This will usually be a requirement of sites which use enterprise systems, but if not, the use of a virtual queue as the destination of the LPR connection makes controlling the behaviour of jobs submitted LPR significantly less complicated.
to:
LPR connections to Windows print servers are useful in organizations running Unix/SAP/enterprise systems that generate printing that should be tracked through PaperCut, where those systems cannot connect to Windows print queues via normal SMB. Commonly, the enterprise systems are configured to print via LPR to the shared Windows print queues, rather than directly printing to devices.

LPR implementations are not without their quirks, especially when dealing with advanced print functionality like Secure Print Release and Find Me printing. Use this article as a guide when performing such an implementation to minimize unexpected behavior.

* [[https://www.papercut.com/kb/Main/PrintQueueSetUpOnWindows|Remove Creator/Owner permissions]]: Windows LPR can attempt to resubmit a job to the printer port; this will remove the ability for the print workflow to be affected by this behavior.

* [[https://www.papercut.com/products/ng/manual/ch-find-me-printing-and-load-balancing.html|Use Find-Me printing]]: This will usually be a requirement of sites which use enterprise systems, but if not, the use of a virtual queue as the destination of the LPR connection makes controlling the behavior of jobs submitted LPR significantly less complicated.
Changed lines 22-23 from:
If you have followed above suggestions and are still receiving an error of "A print job was attempted to be unpaused while being held and was deleted", please contact Support@PaperCut.com
to:
If you have followed above suggestions and are still receiving an error of "A print job was attempted to be unpaused while being held and was deleted", please contact ''support@papercut.com''
Added lines 22-23:
If you have followed above suggestions and are still receiving an error of "A print job was attempted to be unpaused while being held and was deleted", please contact Support@PaperCut.com
Changed lines 22-23 from:
''Note:''
to:
''Note:'' PaperCut Software is aware of the limitations with the LPR implementation on Windows, and we are aware that the LPR implementation is a legacy service. Alternatives are being investigated, however the recommended configuration above, although complex, has been proven in production use for a number of years among many customer sites.
Changed line 12 from:
** It gives you an opportunity to use a simpler name more suitable for *UNIX basis systems (e.g. ascii only with no spaces).
to:
** It gives you an opportunity to use a simpler name more suitable for *UNIX basis systems (e.g. ASCII only with no spaces).
Changed line 13 from:
** It isolates LRP jobs into a separate queue - this can help you diagnose problems.
to:
** It isolates LPR jobs into a separate queue - this can help you diagnose problems.
Changed lines 12-13 from:
** It gives you an opportunity to use a simpler name more suitible for *UNIX basis systems (e.g. ascii only with no spaces)
** It isolates LRP jobs into a seperate queue - this can help you diagnose problems.
to:
** It gives you an opportunity to use a simpler name more suitable for *UNIX basis systems (e.g. ascii only with no spaces).
** It isolates LRP jobs into a separate queue - this can help you diagnose problems.
Added lines 11-15:
* When using Find-Me printing create a separate Global Virtual Queue for LPR jobs.  Don't reuse an existing queue used for jobs sent in via the standard Windows printing protocol.  For example, call the queue "global-queue-lpr". There are a number of reasons for this:
** It gives you an opportunity to use a simpler name more suitible for *UNIX basis systems (e.g. ascii only with no spaces)
** It isolates LRP jobs into a seperate queue - this can help you diagnose problems.
** It's advised to set the queue to a "paused" state (see following steps).  If the same queue is shared by Windows users (who can see the state), it may confuse them. 

Added lines 22-23:
''Note:''
Changed lines 11-12 from:
* Ensure the printer port of the virtual queue is set to a port that is not connected, such as the legacy [@LPT1@] port. This will assist in denying any attempt by Windows LPR to progress the job without proper PaperCut control. Do not set this port to [@NUL@] or equivalent, as this will almost certainly lead to missing print jobs.
to:
* Ensure the printer port of the virtual queue is set to a port that is not connected to a real printer. For example, set to to an unused [@LPT1@] port. This will assist in denying any attempt by Windows LPR to progress the job without proper PaperCut control. Do not set this port to [@NUL@] or equivalent, as this will almost certainly lead to missing print jobs.
Changed line 20 from:
[-Keywords: as400, iseries, jdedwards, lpd, legacy, mainframe-]
to:
[-Keywords: as400, iseries, jdedwards, lpd, legacy, mainframe, lpr limitations, lpr problems, lpd, print services for unix-]
Added lines 1-20:
(:title Implementing LPR connections to Windows print queues:)

LPR connections to Windows print servers are useful in organisations running Unix/SAP/enterprise systems that generate printing that should be tracked through PaperCut, where those systems cannot connect to Windows print queues via normal SMB. Commonly, the enterprise systems are configured to print via LPR to the shared Windows print queues, rather than directly printing to devices.

LPR implementations are not without their quirks, especially when dealing with advanced print functionality like Secure Print Release and Find Me printing. Use this article as a guide when performing such an implementation to minimize unexpected behaviour.

* [[https://www.papercut.com/kb/Main/PrintQueueSetUpOnWindows|Remove Creator/Owner permissions]]: Windows LPR can attempt to resubmit a job to the printer port; this will remove the ability for the print workflow to be affected by this behaviour.

* [[https://www.papercut.com/products/ng/manual/ch-find-me-printing-and-load-balancing.html|Use Find-Me printing]]: This will usually be a requirement of sites which use enterprise systems, but if not, the use of a virtual queue as the destination of the LPR connection makes controlling the behaviour of jobs submitted LPR significantly less complicated.

* Ensure the printer port of the virtual queue is set to a port that is not connected, such as the legacy [@LPT1@] port. This will assist in denying any attempt by Windows LPR to progress the job without proper PaperCut control. Do not set this port to [@NUL@] or equivalent, as this will almost certainly lead to missing print jobs.

* Pause the virtual print queue. As no job should ever progress through the virtual queue to the print port, this is an additional safeguard against Windows LPR bypassing PaperCut control.

* Finally, it is possible to accurately attribute these enterprise system-generated print jobs to PaperCut users via the use of [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-external-usernames.html|Enterprise Environment Username Extraction]].

----
''Categories:'' [[Category.Implementation|+]], [[Category.Troubleshooting|+]]
----
[-Keywords: as400, iseries, jdedwards, lpd, legacy, mainframe-]

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 July 31, 2018, at 08:02 PM
Printable View   |   Article History   |   Edit Article