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 “physical” 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…
We’ll need to 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:
You may then see the following prompt…
If you do, open a Terminal window, and run the noted command:
Once that’s done, jump back to your browser and reload the page. Once the CUPS web interface is displayed, head over the “Administration” tab, and click the “Add Printer” found therein.
You’ll first be asked to choose a connection type for the printer. We don’t really want any of the ones listed here, so for now, just select "AppSocket/HP JetDirect" before clicking to “Continue”.
Now we get to actually specify the connection for the device, and this part is the trick! Plug the following into the “Connection:” field before hitting “Continue”:
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, we need to pick the driver. For most setups, this should be the same driver used by the physical 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”, hit “Continue”, select “Generic PostScript Printer (en)” for the “Model”, and then click to “Add Printer”.
The null printer has now been added your macOS print server. You’ll then need to 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, as well as making sure to immediately 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 physical queues using the “Job Redirection Settings” found just below, and you’re all set!
- 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.
Keywords: /dev/null, /dev/nul, fake printer port, null printer, zono,