Implementing LPR connections to Windows print queues

KB Home   |   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.

  • 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.
  • 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 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

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.

Categories: Implementation / Deployment, Troubleshooting

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.”


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 March 06, 2014, at 01:40 AM
Printable View   |   Article History   |   Edit Article