Why Use a Null Printer? It can be extremely useful to have a print queue which, rather than printing itself, forwards prints on to one of a number of other printers. Setting this up in PaperCut is a snap; create a new printer, mark it as a “virtual queue” within PaperCut, and choose which “destination” print queues it can release to!
A virtual queue isn’t intended to ever actually print anything, but rather send its jobs on towards other queues which are associated with real, physical printers. Such functionality is instrumental for features like Find Me Printing, where users all print to the one print queue, but then release at the printer closest to them.
However, if for some reason the PaperCut Print Provider suddenly stops working on your print server, any virtual queues cease to be virtual, and they will instantly start behaving like normal printers. If a virtual print queue is associated with an actual printer, this could be very bad news! Any subsequent prints which a user intends to release securely to a printer in one location would instead come straight out at whatever printer the virtual queue is associated with.
So how do we avoid this? Thankfully, it’s a very simple fix. Instead of creating a virtual queue that points at an actual, physical printer, we make one that points… well, nowhere at all. All prints that are unintentionally released to such a queue will vanish without a trace; in other words, no pages will come out, nobody will get their hands on a document they shouldn’t see, and no paper is unnecessarily wasted!
To achieve this within a Windows printing environment, we recommend that your PaperCut virtual print queues be configured to use the “Nul” port. This way, errant prints will be dispatched to a port which isn’t connected to any device. You can read more about that process over here.
For macOS, the process is a little different…
Setting Up a macOS Null Printer Create the null printer via the CUPS web interface on your macOS print server. Logon to the server, open up a web browser, and enter in the following URL:
http://localhost:631
You may then see the following prompt…
If you do, open a Terminal window, and run the noted command:
cupsctl WebInterface=yes
Once that’s done, jump back to your browser (the CUPS web interface tab) and reload the page. Once the CUPS web interface is displayed, head into the Administration tab > then click the Add Printer button:
Choose the connection type for the nul printer. We don’t really want any of the ones listed here, so for now, just select AppSocket/HP JetDirect and then click Continue.
Enter the “connection” string for the device (this part is the trick!)
Copy and paste the following into the Connection field then click Continue
file:/dev/null
The name and other details are next. In my example, I’ve used a name of “nul”, but this can be whatever you like, and with whatever description you please. I’ve also preemptively chosen to “Share This Printer” before clicking to “Continue”!
Finally, select the driver to use.
For most setups, this should be the same driver used by the destination print queues you intend the virtual queue to forward to, but another good option is to use one of the highly generic, broadly compatible drivers built right in to CUPS… and they don’t come much more generic than the Generic PostScript Printer driver! Select Generic for the “Make” > click Continue > then select Generic PostScript Printer (en) for the “Model” > then click to Add Printer.
The null printer has now been added your macOS print server!
Run the Control Print Monitoring.command script found in the PaperCut installation directory on the server in order to enable tracking for this new queue.
(Optionally) you can also choose to change the Queue type to This is a virtual queue (jobs will be forwarded to a different queue) via the options found on the Printer Details page in the PaperCut administration console.
Select the relevant destination queues using the “Job Redirection Settings” found just below, and you’re all set!
Notes If PaperCut tracking is enabled for a null printer but the queue has not yet been configured to be virtual, sending print jobs through to it may cause errors. If this happens, change the queue type to virtual via the PaperCut administration console, and delete any stuck jobs from the queue via CUPS. When used on a virtual queue, the administrator should take into consideration the Failure Mode Settings. If set to Mode 1 or 2, the virtual queue will delete all print data sent to it during a failure preventing communication between the Application Server and the Print Provider on the virtual queue’s print server.
Comments
0 comments
Please sign in to leave a comment.