Skip to content
ZenPrint Docs

Capturing Drivers

ZenPrint has three driver sources:

  • Custom: you uploaded a ZIP through the UI
  • Captured: pulled from an endpoint that already has the printer’s driver installed
  • ZenPrint Library: shared drivers, maintained by ZenPrint and available to every tenant. Not user-editable.

The ZenPrint Library is a curated set of drivers ZenPrint maintains and makes available across tenants, so a common printer often already has a ready driver you can assign without capturing your own. Your captured and custom drivers stay private to your tenant. When ZenPrint adds a driver to the Library, any capture details that identify a specific endpoint (such as its IP address or hostname) are removed first.

Capture is the path you’ll use most often. Most printers already have a working driver installed somewhere in your fleet, and capture lets you extract it once and reuse it everywhere.

When to capture

Capture works when:

  • You have at least one endpoint reporting in at the printer’s location
  • That endpoint has a working queue pointing at the printer’s IP
  • The customer (client) and site (location) are both in Active or Paused status, not Suspended or Offboarding

If any of these aren’t true, capture silently no-ops or refuses. The UI shows a readiness check before you flag the printer: it counts eligible endpoints and warns you if there are zero.

The capture flow

  1. Fleet → Printers → open the row’s ⋯ menu.
  2. Click Capture. A readiness modal opens, showing how many endpoints at the location can perform the capture (that is, how many have a working queue pointing at this printer’s IP). If that count is zero, the modal warns you that capture would silently do nothing.
  3. Confirm. The printer is flagged for capture, and an amber tray icon appears in the row’s Actions column so you can see at a glance which printers are waiting.
  4. Trigger the capture run. Capture is on-demand only. Run the bootstrap’s Capture mode ad-hoc from your RMM on an eligible endpoint at the printer’s location.
  5. On the next run, an eligible endpoint extracts the driver from its local print spooler, packages it up, and uploads it to ZenPrint.
  6. The new driver appears under Drivers with source Captured. The capture flag clears automatically.

You can cancel a pending capture before it’s picked up: click the amber tray icon on the printer row and confirm.

Printers with more than one queue

A single printer often has several queues installed on the same endpoint, typically one per page description language: a PCL6 queue and a PostScript queue pointing at the same device. Each of those queues uses a different driver.

Capture takes all of them. One capture run on that endpoint uploads one driver package per distinct driver, so you get a Captured row for each. They’re told apart by the print language in the driver name, for example “Ricoh MP C307 PCL6” and “Ricoh MP C307 PS”. Pick whichever one you want when you build the ZenPrint queue; you don’t have to capture twice.

Queues that share a driver (a duplicated queue with different settings, say) only produce one driver record, since there’s only one driver involved. The same holds across printers: flag five identical printers at a site and the shared driver is uploaded once, not five times.

Dedup

ZenPrint dedupes captured drivers by name, manufacturer, and version (scoped to your tenant plus the shared ZenPrint Library). If you capture the same driver from two different endpoints, you get one driver record, not two, even if the underlying ZIPs differ slightly due to file ordering or timestamps.

When the driver doesn’t report a version (rare, usually very old drivers), ZenPrint falls back to byte-identical comparison.

If the driver already exists when capture runs, the capture flag clears anyway, so you don’t end up with a stuck “pending” flag because someone else already captured it.

Manual upload

When you have a driver ZIP from the vendor (or another tenant) and don’t want to wait for a capture cycle, upload it directly:

  1. Drivers → Upload (button in the top-right of the Drivers page).
  2. Drop the ZIP. ZenPrint unzips it, scans every driver file inside, and pulls out metadata (manufacturer, model, version, language, architecture, supported devices).
  3. You’ll see a card for every driver file in the package. A single vendor ZIP often contains drivers for an entire product line, so pick the ones you want. Cards are sorted with Printer-class first, and only those are pre-selected. Non-Printer cards (Class: Extension, Class: Monitor, Class: USB, and so on) appear with an amber badge and are left unchecked. That’s almost always what you want, since extensions and monitors install separately and rarely belong in a manual upload, but you can opt them in if you have a reason.
  4. The selected drivers are saved with source Custom and are immediately available for queue assignment.

A 200 MB vendor ZIP only takes up 200 MB of storage even if it contains drivers for ten different models. ZenPrint stores the package once and references it from every driver row.

Every stored driver package, whether captured or uploaded, includes a small zenprint-manifest.json describing what it is (name, manufacturer, supported models, version). It is metadata only and is ignored at install time, so it has no effect on the driver itself. It keeps the package self-describing if it is ever moved between tenants or servers.

One driver, a whole product line

A vendor driver file usually covers a family of printers, not a single model. Brother and HP routinely ship thirty or more models in one file, and the driver installs on every one of them.

The Drivers table shows one model per row, with a +N models pill next to it when the driver covers more. The count is the number of distinct printers the package supports; a driver file lists each model once per Windows architecture, and ZenPrint collapses those before counting. Click the pill to see the full list. Search covers every model in that list, not just the one on display, so looking up a specific model finds the driver that supports it even when the row headlines a different model in the same family.

The queue driver picker uses the same list twice: to sort drivers by how well they fit the printer you are creating a queue for, and to search. Type a model into the picker’s search box and you get every driver that supports it, each one showing which model it matched on, even when its name says something broader.

Driver names

Each row is titled with a name built from what the package declares: the manufacturer, the model line it covers, the page description language it speaks, and how many models it covers. A file covering the HP LaserJet Pro M404dn and M404dw reads as “HP LaserJet Pro M404 PCL6 (2 models)”.

The line is worked out from the model numbers in the package. When every model is a variant of one number, that number names the driver. When a package covers two or more different models, there’s no single name to give it, so it falls back to the vendor’s own name for the package with its lead model behind it, and the model count tells you how much it really covers. Click the count to see the full list.

Some packages cover a vendor’s whole product line and share nothing but the brand name, which is no use as a title. For those ZenPrint uses the name the vendor gives the package inside the driver files themselves, so Brother’s 193-model laser package reads as “Brother Laser Printer Driver (193 models)” and their inkjet one as “Brother Inkjet Printer Driver”.

Ricoh and a few others go further and sell one engine under several brands, so a single package covers models badged RICOH, Gestetner, LANIER, NRG and SAVIN. Those models have nothing in common at all, and the vendor tends to give every package the same name regardless of which product line it covers. When ZenPrint sees that shape it adds the driver’s own model behind the package name, so the packs stay distinguishable: “Ricoh PCL6 Printer Driver - RICOH IM C2000 PCL 6 (13 models)” next to “Ricoh PCL6 Printer Driver - RICOH IM C3000 PCL 6 (12 models)”.

Universal drivers

A universal driver is marked (universal) instead of carrying a model count. That is deliberate: a universal package doesn’t list the printers it drives, only the one or two names it registers itself under, so a count would understate it badly. It works across a vendor’s range and negotiates each printer’s capabilities when it installs.

The queue driver picker knows the difference. A universal driver is offered for any printer of that brand, ranked below an exact model match but above a generic same-vendor one, so you get the specific driver when there is one and a working fallback when there isn’t.

On a driver that covers exactly one model you’ll see a second, greyer line under the title: Installs as …. That’s the Windows driver name, the exact name Windows knows the driver by once it’s installed on an endpoint. For a captured driver it is the name of the printer the capture ran against, which is why it usually differs from the title. Match on it when you’re comparing a ZenPrint row against what you see in the Printers list on a Windows machine.

A driver covering a family has no single install name, so that line isn’t shown for one. Each queue installs the entry for its own printer: assign a Brother family package to a queue for an MFC-L2860DW and the endpoint registers the MFC-L2860DW entry, not the DCP-L2620DW one the row happens to be titled after. That matters because Windows takes the printer’s capabilities (paper trays, duplex, colour, fax) from the entry it registered. One driver row covers the whole family, so there’s no reason to keep a separate copy of a driver per model. If the package declares no entry for a queue’s model, the package’s own name is used as a fallback, which still prints. The queue drawer’s On the endpoint column shows the name that was actually registered.

The name and the title are separate on purpose. The Windows driver name has to stay exactly as the driver package declares it, because that string is what the endpoint installs by. The title is only a label, so it can be the more useful of the two.

Driver class

Each driver row carries a Type 3 or Type 4 badge. That’s the Windows print driver class, not a version number: Type 3 is the classic model where the vendor’s package renders the job, Type 4 is the newer packaged model Windows prefers. ZenPrint reads it off the endpoint when it captures a driver, and off the INF when you upload one, so it’s filled in without you doing anything.

It’s worth a glance when a queue installs cleanly but doesn’t print, because the class is one of the things that can differ between a machine where a driver works and one where it doesn’t. Note that a driver’s name often contains the vendor’s own version, so a row can read “HP Universal Printing PCL 6 (v8.2.0)” with a Type 3 badge. Those are two different things: v8.2.0 is HP’s release, and Type 3 is how Windows loads it.

Rows promoted before ZenPrint recorded the class show no badge.

Driver signing on the endpoint

Windows will not install a driver package whose catalog is signed by a publisher that machine has not been told to trust. It refuses with “the publisher of an Authenticode signed catalog has not yet been established as trusted”, and it is a property of the machine rather than the package: the same driver installs without complaint on a PC that once ran the vendor’s own installer, and fails on a clean one.

Reconcile handles this for you. Before installing a package it reads the catalog’s signing certificate and adds it to the endpoint’s Trusted Publishers store, and its root certificate too if the chain is not already trusted. The alternative would be importing the same certificate by hand on every endpoint, which reaches the same end state with more work and no more safety: the driver either comes from the ZenPrint library or you uploaded or captured it yourself.

Each import is written to the script log with the certificate’s subject and thumbprint, so a run that widened a machine’s trust says so:

[WARN] Trusting driver publisher from hpcu360u.cat : CN=HP Inc., O=HP Inc. [A1B2...]

If an install still fails, the reason Windows gave is shown on the queue’s row in the endpoint drawer.

Which queues use a driver

The Queues number on a driver row is a link. It opens the Fleet page’s Queues tab filtered to that driver, so you get the full list with search, sorting, pagination and the client scope selector, however many customers it spans. A chip at the top of the filters names the driver and clears the filter when you dismiss it.

The number counts queues, not deployments: a queue assigned to forty endpoints counts once. To see where a queue actually landed, open that queue’s own assignment count in the Queues tab.

Lifecycle

A driver in the Drivers table is one of:

  • Unused: no queues reference it. Delete is straightforward; the driver and its stored files are removed.
  • In use: at least one queue references it. Delete opens the safe-delete modal, which lists every queue using the driver and gives you a replacement-driver picker. Pick the replacement, confirm, and the affected queues are rebound and the original is deleted in one operation.
  • ZenPrint Library: shared cross-tenant drivers are not deletable from any tenant. The Delete button is hidden on those rows.

The safe-delete modal is the only way to delete an in-use driver; there’s no “delete and break queues” option. This is deliberate. A queue with a deleted driver would fail on the next reconcile run, and whoever’s on duty when it fails usually has no idea why the driver vanished. Forcing a replacement pick at delete time means the swap is intentional and audited.

What captured drivers look like

A captured driver carries extra metadata that manually-uploaded drivers don’t have:

  • Source: Captured
  • Captured from IP: the printer’s IP at capture time, useful for tracing back where a driver came from
  • Captured models: the model strings the driver claims to support (often broader than just the printer it came from)

Otherwise it behaves identically to a custom-uploaded driver. You can assign queues to it, delete it via safe-delete, and so on.

Capture vs vendor download

Capture beats downloading from the vendor site when:

  • The vendor site is paywalled or requires login
  • The vendor ZIP is hundreds of MB and you only need one model
  • You want the exact version that’s currently working in production, not the newest, which sometimes regresses

Vendor download beats capture when:

  • No endpoint has the driver yet (first-time install)
  • You want a newer version than what’s deployed
  • The driver isn’t installed via the standard print spooler (rare, mostly weird industrial printers)