Implementing LPR connections to Windows print queues
Last modified on 06 May 2013 04:15 PM

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.

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