Discovering printers on your network
If you’re a hardened print queue aficionado, you’re bound to have some cuts and bruises from previous struggles trying to get the right printers showing up for the right people - or fiddling around endlessly with print queues and drivers.
With PaperCut Pocket and Hive, the product will do as much of the heavy lifting as it can for you! Short of us walking the floors and looking under desks for lost printers, we have a few network tricks up our sleeves to discover USB and networked printers in your organization.
Have a look through the behind-the-scenes details below on how PaperCut Pocket and Hive can help find your printers, organize them and publish them seamlessly to your users.
The printer discovery activity is actually made up of an elite team of processes. They’re all part of the Edge Node component that leaps into life when you install PaperCut Pocket or Hive.
The processes involved in printer discovery are:
Scanner process - the tool that hunts down things that look like printers on the network, or locally connected printers on your computer.
Probe process - once the scanner finds something that looks like a printer, the probe follows behind and sees what kind of printer it is, as well as what it’s capable of (for example, does it have a duplexing unit?).
Validator process - receives and checks out the information provided by the Probe by further interrogating the printers. Think bright-backlighting and intense questioning.
Reporter process - sends details about the newly found and verified printer up to the cloud.
Printer Registry - the ‘printer database in the sky’. This cloud component keeps track of which printers are associated with a specific organization, as well as all the capabilities and properties of the printers.
The scanner’s primary responsibility in printer discovery is to identify sources that look like printers on the device (Windows or macOS queues) - or somewhere on the network. There are two types of scanning:
Local queue scanner
The local queue scanner talks to CUPS (on macOS or Linux) or the Print Spooler (on Windows) to get information about the print queues configured on the local mac or PC. Note that the local queue scanner also moonlights as the ‘probe’ for local queue information. Nifty.
The network scanner starts by picking up clues from local print queues to prioritize which network addresses to scan - and then scans the network for devices that look like printers! The scanner then uses SNMP queries to check that the device found is actually a printer, and if so, what type of printer it is.
Luckily nothing too invasive!! The probe uses SNMP and IPP to collect as much data as possible on the printer candidates found by the scanner. The probe isn’t too picky or judgemental about what it finds - all it’s doing is gathering as much information as possible to hand over to the validator.
Just like humans, the printers are yearning for validation - luckily the validator steps up to help validate a printer, before reporting it to the cloud. The validator uses SNMP or IPP requests to further validate the previous findings, and to gather capabilities of the printer - can it do 2-sided prints? Is it out of toner? The validator needs to be able to retrieve at least an IP address, MAC address, and make or model of the printer before it can say ‘yes this is a printer’.
For locally configured queues on the Edge Node, the validator looks for the ConnectionURI (the connection string) in the local queue configuration (e.g. CUPS).
After the validator gives the nod to each printer found, the reporter sends the printer candidate (and all the additional SNMP or IPP data found) to the printer registry in the cloud. It’s worth repeating here that everything sent to the cloud - no matter how ‘innocent’ - is encrypted and sent over secure protocols. In this case, HTTPS.
The Printer Registry receives the printer candidate requests from the reporter and begins to piece together a ‘definition’ for each of the printers found. This definition includes the location (including the IP address for network printers or which machine it’s connected to, for a locally attached printer), the make and model of the printer, and its capabilities. From this information, it starts to build a big picture of the printer landscape.
It also creates a co-ordinator map, detailing which Edge Nodes have access to which printers. This is especially important for local printers (for example USB printers) - you can’t print to a USB printer unless you’re sending the job from the machine it’s plugged into! However it’s also important for network printers - organizations may have VLANs and other networking obstacles in place, which means that some printers are only accessible from certain workstations.
If the Print Registry doesn’t have enough information about a printer to build a genuine printer definition, it filters that printer out. It also applies filtering to printers that shouldn’t be registered, like PDF queues (Virtual printers), Fax queues, test printers, PaperCut MF monitored print queues, and PaperCut Mobility Print URIs.
Deduplication / printer matching
Multiple Edge Nodes could report the same printers more than once, so a printer matching algorithm finds matches for already-known printers. Like a dating app of the printer world, it looks at qualities such as IP addresses, ConnectionURIs, MAC addresses, hostnames, and serial numbers - and looks for that perfect match.
If the Printer Registry doesn’t find a match, (don’t feel too bad for the printer! It means it’s a unique bit of treasure that we’ve found!) then it registers the device as a new printer. It chooses a new name for the device, based on the metadata it received.
Sometimes the registration process will involve updating current printer data - for example, if newly found information is discovered about a printer that is already known. In that case, the device information is updated with the newly found information.
Do all the users have to run the discovery tool?
How often does the discovery process happen after the first install?
During working hours, the discovery process for locally-attached printers happens every 10 minutes and the discovery of network printers happens around once an hour.
Outside of working hours (9am-5pm in whichever timezone the Edge Node is located), discovery is less frequent (we don’t want to keep looking if there’s no-one in the office!). Checking for local printers happens once an hour, and checking for network printers happens every 12 hours.
I just renamed one of my print queues on my Edge Node - how long will it take to update in the admin interface?
I just installed a new printer - how long until it shows up in the admin interface?
I don’t see my network printer listed - why not?
As you’ve seen above, PaperCut Pocket and Hive use SNMP V1/V2 and IPP to discover printers. We also use your local printer queues as hints as to where to start the subnet scan. For example, if you have a printer at address 10.100.80.60, we will scan subnet 10.100.80.0/16.
We also need ports for SNMP 161/162 and 631 for IPP (check out the System Requirements - Firewall ports page for more details). If these ports are blocked, we will not discover a device. Ports might be allowed on a specific subnet but may be blocked from crossing onto other subnets, so if your printer is on another subnet that we cannot scan with SNMP or IPP ports, it’ll remain hidden to the discovery process.