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 cross-tenant drivers, curated by ZenPrint and not user-editable

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 printer row.
  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.
  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: open the printer row again and click Cancel Capture.

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.

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)