Scripts

ZenPrint runs a handful of PowerShell scripts on managed endpoints, all fetched on demand from the server by the bootstrap. You don’t deploy any of them; the bootstrap pulls them per run. Before every mode (except Cleanup) the bootstrap also runs a small check-in step automatically.

Recommended schedule

Mode	Cadence	Run on
Reconcile	Daily	Every managed endpoint
Scan	Weekly	One or two endpoints per location
Poll	Daily	One or two endpoints per location
Capture	On demand	An eligible endpoint, after flagging a printer
Cleanup	On demand	An endpoint you’re offboarding

Check-in isn’t scheduled on its own; it runs automatically before every mode except Cleanup. Any mode can also be triggered ad-hoc from your RMM at any time, so the table is just the steady-state cadence, not a limit.

check-in (automatic)

Purpose: register the endpoint with ZenPrint and keep its record current. You don’t schedule this; the bootstrap runs it ahead of whatever mode you scheduled.

What it does: reports the endpoint’s identity (hostname, OS, RMM organization/location or group path) to ZenPrint, which registers it the first time and resolves its client/location, then caches the endpoint ID for the mode that follows.

In the RMM log you’ll see whether it was a first-time registration (Registered as a new endpoint with ZenPrint) or a refresh (Endpoint already registered), the resolved client/location, and a warning if the endpoint is still unassigned.

Because check-in runs before every mode, an endpoint registers the first time any of its scheduled tasks runs. In practice reconcile is the one mode you run fleet-wide, so it’s what registers every endpoint. Scan is heavier (it sweeps the network), so you run it on only one or two endpoints per location rather than everywhere.

scan

Purpose: discover network printers.

What it does each run:

1. Discovers network printers by checking the ARP cache and probing common printer ports.
2. Reports each discovered printer (MAC, IP, manufacturer, model, serial, hostname) to ZenPrint, which adds it to the fleet if new or updates its info if known.

The sweep only runs once the endpoint is mapped to a location. An unmapped endpoint has nowhere to attach discovered printers, so scan is a no-op until it has one.

• RMMs with a fixed organization/site structure (e.g. NinjaOne): the endpoint auto-maps to a client and location on check-in, so scan discovers its printers on the same run. No action needed from you.
• RMMs that organize endpoints by groups, folders, or tags (e.g. Level.io): the endpoint registers unassigned. After you map its group to a client and location, the next scan discovers its printers.

The server decides this per scan (the script just obeys), and endpoint approval status doesn’t matter; only whether it has a location. Suspended and offboarding clients are skipped too. By default an endpoint scans the subnets it sits on, limited to network adapters that have a default gateway — so virtual adapters from WSL, Docker, or Hyper-V (which create gateway-less networks, often large 172.x ranges) are skipped automatically rather than wasting a scan on thousands of phantom hosts. To override auto-detection, or to scan other subnets at a site, set Scan Networks (comma-separated CIDRs) on the location’s edit dialog and ZenPrint hands exactly those to the endpoint on its next scan.

Schedule: weekly on one or two endpoints per location, enough to cover the site’s printers. New printers are rare in an MSP fleet, so a weekly cadence catches them with minimal noise. You don’t need scan on every endpoint: registration rides on check-in (which runs under reconcile), so scan is only about network coverage. Pick the endpoint at each site most likely to be online, and trigger ad-hoc when you plug in a new printer.

What you’ll see: new printers appear in Fleet → Printers with Discovered status. They flip to Active automatically when you create the first queue on them, or you can dismiss them if they’re not printers you want to manage. Dismissed printers stay on a blocklist so future scans won’t re-create them.

reconcile

Purpose: make the endpoint’s installed queues match what ZenPrint thinks should be there. This is where queues actually get installed, updated, or removed.

What it does each run:

1. Asks ZenPrint which queues should be installed on this endpoint.
2. Compares that list to what’s currently installed locally.
3. Applies the difference:
   • Install any queue that should be there but isn’t
   • Update any queue whose configuration has changed (rename, driver swap, port change)
   • Remove any queue that’s no longer in the list
   • Skip queues whose configuration hasn’t changed (no-op)
4. Reports the outcome of each operation back to ZenPrint so the dashboard can show success or failure.
5. Reports the endpoint’s full local print-queue list (managed and unmanaged) so ZenPrint can surface drift and queues it didn’t create.

Smart driver handling: if a queue needs an update but its driver hasn’t changed, reconcile re-applies only the changed fields rather than reinstalling the driver. Reinstalls only happen when the driver itself changes.

Active print jobs are respected. If the endpoint has jobs queued when reconcile runs, driver swaps are deferred to the next run. Renames and IP changes (the Windows printer port is re-minted when a printer’s IP changes) still happen immediately.

Force Reapply: from any endpoint’s row in the UI you can trigger a “rebuild everything” on the next reconcile run. It re-applies every field — name, port, config, and the driver itself — overwriting whatever’s on the machine. Use it when someone manually changed printer settings (a normal reconcile compares against ZenPrint’s own record of the endpoint, so it won’t notice a hand-edit on the machine; Force Reapply is how you make ZenPrint’s definition win).

Schedule: daily on every managed endpoint. Queue assignments are admin-initiated and, in a perfect world, end users aren’t local admins on managed workstations, so drift between runs is rare. A 24-hour lag on applying changes to a queue is acceptable for the vast majority of changes. When it isn’t, trigger reconcile ad-hoc from your RMM on the specific endpoint.

capture

Purpose: extract a driver from a printer that’s already working on one of your endpoints, so you can reuse it across the fleet.

What it does each run:

1. Asks ZenPrint whether any printers at this endpoint’s location have been flagged for capture.
2. For each one, finds a locally-installed queue pointing at the printer, pulls the driver files, packages them with metadata, and uploads to ZenPrint.
3. If ZenPrint already has the same driver (matched by name, manufacturer, and version), the existing driver is reused with no duplicate. The capture flag clears either way.

When capture refuses: if the printer’s client or location is suspended or offboarding, the script logs and exits without uploading. ZenPrint won’t accept new captures from blocked tenants.

Schedule: on-demand only. The operator clicks “Capture from this printer” in the UI to set the flag, then triggers the capture script from the RMM on an eligible endpoint. Don’t put it on a recurring schedule; polling for an empty pending list across hundreds of endpoints is pure waste.

Readiness check: before you can flag a printer for capture, ZenPrint counts how many active endpoints at the printer’s location have a queue pointing at it. If zero, capture would silently no-op, and the UI warns you with that count.

poll

Purpose: read SNMP supply levels (toner, ink, drum, fuser, waste) off network printers and report them back, so the Fleet shows current consumable levels and the per-consumable supply.low.* webhooks can alert you.

What it does each run:

1. Asks ZenPrint which printers this endpoint should poll. The server returns every printer at the endpoint’s location, so any mapped endpoint at a site can poll that site’s printers (it doesn’t have to be the one that discovered them).
2. For each printer it’s given, walks the printer’s SNMP supply table and reports each consumable’s level as a percentage.

It reads SNMP v2c and v1 with the public community. Printers with SNMP disabled, locked to v3, or using a non-default community return nothing and are skipped. Levels are a current snapshot only; there’s no history.

Schedule: daily, on one or two endpoints per location, enough to cover the site. Since targets are scoped by location, the poll machine doesn’t have to be the one that runs scan; any mapped endpoint at the site works. You don’t have to be precise: if several endpoints poll the same printer, ZenPrint dedups the reports, so overlapping coverage just costs a little redundant SNMP traffic. See supply levels for what you’ll see and the alerting behaviour.

Integrity and transport

Every script is fetched over HTTPS, authenticated with your API key. Before executing anything, the bootstrap verifies a cryptographic signature on the script content: the bytes are signed at ZenPrint build time with a key the server itself doesn’t hold, and the bootstrap refuses to run an unsigned or altered response. See Script Signing for how it works.

Scripts run with strict error handling. Any error aborts the run and the exit code bubbles up to your RMM, so failures show up where you’d expect.