Fleet Overview

The Fleet page (/fleet) is where you spend most of your time. One page, one URL, five tabs, scoped by a drill-down ladder that runs from “everything across every tenant” down to “just this group of endpoints at this site.”

The scope ladder

Across the top of the page, breadcrumbs show your current scope. You can be at one of four levels:

Scope	URL	Shows
Global	`/fleet`	All clients across every location. Default landing.
Client	`/fleet?client=<id>`	One client; all their locations and resources.
Location	`/fleet?client=<id>&location=<id>`	One site within one client.
Group	`/fleet?client=<id>&location=<id>&group=<id>`	A named group of endpoints within a location.

Drill down by clicking the client card, then the location card, then the group filter. Step back up via the breadcrumbs.

The scope filters cascade through every tab. If you’re at location scope, the Endpoints tab shows only that location’s endpoints, and the Printers tab shows only printers at that location (with one exception; see Printers tab below).

The five tabs

Endpoints

Every machine that’s reporting in via the bootstrap script. Statuses:

Active (green): registered and reporting normally
Pending (yellow): checked in, awaiting your approval. A pending endpoint won’t reconcile any queues until you approve it; ZenPrint never auto-activates one.
Inactive (gray): deactivated, no longer pulling reconcile

What you can do here, depending on role and scope:

Approve / Deactivate an endpoint
Delete: hard-removes the endpoint record and its installations. Cascades to remove related rows.
Assign to group: drop the endpoint into a named group at its current location.

Bulk actions: Approve and Deactivate. Tick the checkbox on the rows you want, or the one in the header to take the whole page, and both buttons appear in the action bar. Neither needs a particular scope, so on a first onboarding run you can stay at fleet level, set the Status filter to Pending, and approve everything that has checked in so far in one click. Moving endpoints into a group is different: that still needs a single location selected, because a group belongs to one location.

The header checkbox takes the endpoints on the current page, not every endpoint matching your filter. When there’s more than one page, the action bar spells that out (“50 endpoint(s) selected (this page only; 137 match your filter)”), and the list refreshes after each approval so you can work through the rest.

Endpoints with no location yet are skipped instead of approved, and the confirmation says how many. Assign them to a location first, or set up a group mapping if your RMM has no site structure for ZenPrint to read, then approve them.

The Unmanaged filter narrows the list to endpoints that are reporting print queues ZenPrint doesn’t manage, or to the ones that aren’t. It works at every scope, so you can drill into a client or a location first and then ask which of those machines still have leftovers. Useful in both directions: “With unmanaged” is your worklist when you’re taking over from another print-management tool, and “Without unmanaged” is how you watch that worklist empty out.

The filter is part of the URL (?ep_unmanaged=with), so you can bookmark or share a link that opens straight onto it.

The endpoint detail drawer opens when you click an endpoint row. It puts what ZenPrint wants on this endpoint next to what the endpoint actually reports, so you can read the difference in one pass instead of comparing two lists.

Each row has an Assigned side (the queue, its printer, its driver, its config, and where the assignment came from: Direct, Group: <name>, or Location: <name>), an Installed on endpoint side (the queue as it exists on the machine, with its local name, driver, and port), and a status between them naming the relationship:

In sync: assigned, installed, and its settings match.
Config drift: installed, but its settings on the machine have diverged from the assigned config.
Install failed: the last attempt failed. The error from the endpoint is shown on the row.
Pending install: assigned, not on the machine yet. It lands on the next reconcile run.
Missing on endpoint: ZenPrint recorded this queue as installed, but the endpoint has stopped reporting it, usually because someone deleted it locally. The next reconcile puts it back.
Removing: queued for removal on the next reconcile run.
Not assigned: the queue is on the machine and ZenPrint installed it, but nothing assigns it here any more. The next reconcile removes it unless you assign it back.

Rows sort by how much they need attention, so problems are at the top and in-sync queues at the bottom.

Row actions (subject to your permissions):

Unassign: available on queues assigned directly to this endpoint. Queues inherited from a group or location show where they came from instead; change those at the group or location.
Assign to endpoint: on a Not assigned row, keeps a queue that’s already installed instead of letting the next reconcile remove it.

Below the table, Unmanaged queues on this endpoint lists the queues that exist on the machine but aren’t in ZenPrint’s desired state, with the same states and the same actions as the Unmanaged tab, so you can deal with them without leaving the endpoint.

Printers

Every printer device known to ZenPrint. The status badge reflects its lifecycle:

Active (green): has installed queues, in active use
Discovered (blue): found by scan, no queues yet
Missing (red): endpoints that used to see it have scanned since without finding it (see Health below)
Dismissed (gray): you explicitly hid it. The MAC stays on a blocklist so it won’t re-create on the next scan.

The Network column stacks the three ways a printer is addressed: its IP, its hostname, and its MAC. The hostname is the name the printer reports over SNMP (sysName), which is usually the name printed on its own web console and the name alerts use, so it is the quickest way to match a notification to a row. It is blank for printers that don’t report one; you can set it yourself from the printer’s Edit dialog.

Health

A Health strip above the table summarizes the current scope: how many printers are confirmed, missing, and stale. It follows the scope ladder, so scope to a client or a location and you see that scope’s numbers, and it ignores the table filters, so filtering the list below doesn’t change the summary.

On each printer row, the freshness shows in the colour of the “last seen” line under the status badge: gray when confirmed, amber when stale, red when missing. Hover the warning icon on a stale or missing row to see which endpoint last confirmed it.

Confirmed: an endpoint saw this printer on a recent scan (recent means within the last 7 days by default).
Stale: no scan has confirmed it lately, either because it went quiet or because no endpoint has scanned it yet. A freshly set-up fleet reads as mostly stale and turns confirmed as endpoints run their scans.
Missing: a printer that was being seen has gone. ZenPrint only marks it missing once every endpoint that previously saw it has scanned again without finding it, so a slow or paused scan schedule reads as stale, not missing.

Use the Health filter next to the Status filter to show only confirmed, stale, or missing printers. The filter narrows the list; the strip above keeps counting the whole scope.

Because scans run on demand from your RMM, all of this only moves when scans actually run. A printer goes missing on the scan that first fails to find it, not on a timer. That flip is also what fires the printer.offline webhook, once. It won’t re-fire on later scans while the printer stays missing, and re-arms if the printer comes back.

Supply levels

Printers that respond to SNMP show their toner and ink levels under the model: one coloured dot per cartridge, in its actual colour (black, cyan, magenta, yellow, read from the printer’s colorant table, not its language) followed by the percentage. A cartridge that’s low turns red. A cartridge whose level the printer reports as unknown shows with no percentage. Hover a dot for its full name. That’s all the column shows, so a glance down the fleet tells you which printers need toner.

Everything else the printer reports lives one click away. Under the dots is a Supply details link that expands a table of every supply: toner and ink again, plus drums, fuser and transfer kits, the waste box, and maintenance counters. Each row shows the supply name, its type and class, the level (current over maximum, as the printer reports it), the percentage, the state, and a colour swatch where the printer gives one. Rows are sorted by importance: toner and ink first, then drums, then the rest. Use it to answer “why does ZenPrint show this for that printer?” without leaving the page. Click again to collapse it. When a supply that isn’t a toner runs low (a waste box filling up, a kit near end of life), a red warning icon appears next to the Supply details link so you don’t have to expand every printer to find it, and the low row is flagged with the same icon. The poll time is shown at the bottom of the table.

Not every printer reports a percentage, and the table is honest about it rather than inventing one. Where a printer gives a level with no capacity to measure it against, the level is shown in the units the printer counts in, such as sheets, impressions or even grams of toner. Where it counts in percent, the percentage column fills in as usual. A dash means the printer gave no number at all.

The state column carries the printer’s own answer:

OK, a normal reading.
Low, at or below the alerting threshold.
No percentage, the printer reported a real level on a scale that can’t be turned into a percentage. You can read the level, but this supply will never raise a low-supply alert, because there is nothing for a threshold to compare against.
Some remaining, the printer will only say there is supply left, without saying how much. Common on Brother mono lasers, which keep the real figure in their own private data. It rules out empty, so it doesn’t raise an alert either.
Unknown, the printer reported nothing usable.

The last three are limits of what the device exposes, not faults in the reading, and no amount of polling will change them. If a printer matters enough to need alerting and it sits in one of those states, the practical answers are a page-count-based replacement schedule or the vendor’s own tooling.

Below the supply table, the same drawer shows a Device section: facts the same poll reads off the printer, such as firmware version, the print languages it supports (PCL, PS, and so on), whether it prints in colour, its lifetime page count, and its contact and uptime. Only the facts a given printer actually reports appear, so the list varies by model. These are shown for information only. ZenPrint does not track or flag firmware versions or page counts, it just displays what the printer reports.

Levels come from the supply poll, a separate script your RMM runs on its own schedule. You choose which endpoints run it (the same way you choose which run scan). Each endpoint polls every printer at its location, so a single endpoint at a site covers that site’s printers, and it doesn’t have to be the one that discovered them. ZenPrint dedups when several endpoints report the same printer, so overlapping coverage is fine. (A printer just has to have been discovered by some scan first.)

When a supply drops to or below 15%, ZenPrint fires a per-consumable supply.low.* webhook (for example supply.low.toner) once. Only the primary consumables alert; the collapsed maintenance counters never do. It stays quiet until the supply is refilled and runs down again. Coverage depends on the printer: ZenPrint reads SNMP v2c and v1 with the public community, so printers with SNMP disabled, locked to v3, or using a non-default community won’t report supplies.

At group scope, the Printers tab works differently from the other scopes. Instead of showing every printer physically at the parent location, it shows printers the group actually uses: printers with queues installed on group-member endpoints, or printers assigned to the group directly. So cross-location printers (a shared satellite-office printer the group reaches over VPN) show up where they belong, and site-local printers the group has nothing to do with don’t.

Placement

Each printer has a free-text Placement field for where it physically sits within the site, e.g. “Reception, 2nd floor”, separate from its location (the site/office itself). Set it from the printer’s Edit dialog. At a location or group scope it appears as its own column; at the global and client scopes it shows as a 📍 line under the location. Handy for telling a tech which physical machine to walk to.

If the printer reports an SNMP sysLocation, scan seeds Placement from it the first time the printer is discovered, so a printer whose location is set in its own web console arrives already labelled. The seed only fills an empty field. Once you (or an earlier scan) have set a placement, later scans leave it alone, so your edit always wins. To re-seed from the device, clear the field and let the next scan run.

Per-printer actions:

Edit: manufacturer, model, hostname, serial, placement
Capture: flag for driver capture (see Capturing Drivers). While a capture is pending, the row shows an amber tray icon next to the ⋯ menu; click it to cancel
Dismiss / Restore: toggle blocklist status (only available on Discovered or Missing printers; you can’t dismiss a printer that has queues)
Accept IP / Dismiss IP: when scan detects an IP change, the printer’s pending_ip is set, and the operator decides whether to accept the move. Subscribe to printer.ip_changed if you’d rather be told than notice
Delete: cascades to remove queues, assignments, and installations

Bulk actions: Decommission and Activate. Decommissioning a printer flips its status and marks its queues for removal, and the next reconcile run cleans them off endpoints.

Queues

Every print queue declared in ZenPrint. Each row is one queue, one printer, one driver. Filtering shows queues at the current scope (location-scope queues, group-scope, endpoint-direct).

Per-queue actions:

Edit: rename, change driver, change settings
Delete: removes the queue and all its assignments and installations
Assign: open the assignment modal and target this queue at a location, group, or endpoint

Bulk actions:

Change driver: swap driver on N selected queues (for example, you captured a newer driver and want to roll it out)
Delete: wipe N queues
Bulk assign / unassign: target N queues at a location, group, or endpoint in one operation

Unmanaged

Every print queue found on an endpoint that ZenPrint doesn’t manage. These are queues a user or an old deployment left on the machine, the kind the endpoint reports but that aren’t in ZenPrint’s desired state. The tab is scoped by the same ladder as the others, so you can narrow to a client, a location, or a group.

Each queue is sorted into one of four states based on what ZenPrint knows about the printer behind it:

Redundant: a ZenPrint queue for this printer is assigned to this endpoint and installed on it. The unmanaged one is a duplicate, so it’s safe to clean up. A queue that’s assigned but hasn’t landed yet doesn’t count: until it’s actually on the machine it can’t replace anything.
Deployable: ZenPrint has a queue for this printer, it just isn’t deployed to this endpoint yet. Deploy it here and the unmanaged queue becomes redundant.
Needs queue: ZenPrint knows the printer but has no queue for it. Create a queue first.
Unknown: ZenPrint can’t tell what printer this queue points at. USB queues, queues deployed by another print-management tool, and any WSD queue whose device ZenPrint can’t resolve land here. Nothing is deployed or removed automatically, so a remote worker’s home printer is never touched by accident.

The same rows and actions also appear in each endpoint’s detail drawer, under Unmanaged queues on this endpoint. Use this tab when you’re working across a client or the whole fleet, and the drawer when you’re looking at one machine.

The State filter lets you show one bucket at a time. Deployable rows have a Deploy action that lets you pick which of the printer’s ZenPrint queues to install on that endpoint; Needs queue rows have a Create queue action that opens the queue builder for the printer. Both move the row up toward Redundant.

Any unmanaged queue can be removed, in one of two ways. Which one you get depends on the row, and the wording differs because the consequences do.

Redundant rows use Mark for removal. On the endpoint’s next reconcile the duplicate is removed from Windows, but only after ZenPrint confirms its own queue for that printer is actually installed there, so the endpoint is never left without a working queue. A marked row shows Marked for removal until then; if reconcile can’t confirm the replacement, it leaves the queue in place and the row shows Removal deferred.

Every other row uses Remove (nothing replaces it). There’s no replacement to wait for and there never will be, so reconcile removes the queue outright on the next run. This is the one to use when you’re taking over from another print-management tool, or clearing out queues nobody should have created. Anyone printing to that queue loses it until you deploy a ZenPrint queue for the printer, and the confirmation says so. It’s recorded against the operator who ran it.

Both need the queue delete permission. You can tick several rows and act on them together, including the header checkbox to take the whole page. The action bar shows how many of the selected queues have nothing replacing them, and if the selection mixes the two kinds the confirmation tells you how many fall into each. Rows that have a replacement keep their safety check either way, so a mixed selection never downgrades them.

One thing reconcile refuses either way: removing a queue ZenPrint has since taken over. If a queue was marked and then adopted (because a ZenPrint queue with the same name was deployed to that endpoint), the removal is skipped rather than deleting the queue ZenPrint now manages.

Drivers

Every driver available to the tenant. Three sources:

Custom: uploaded via Drivers → Upload
Captured: pulled from an endpoint via the capture flow
ZenPrint Library: curated cross-tenant drivers, shared and non-deletable

Filter by the Source dropdown. The toolbar also lets you upload a new driver.

Per-driver actions:

Download: pull the ZIP locally (for inspection or re-upload elsewhere)
Delete: only when not in use. If queues reference the driver, clicking Delete opens the safe-delete modal, which lists affected queues and lets you pick a replacement driver to rebind them to before deletion proceeds.

The ZenPrint Library driver is read-only.

How filtering composes

The scope ladder (URL params) and the per-tab filters (status, search, source, group) compose. At any level you can layer:

Status filter, e.g. “show only Active printers”
Search: substring match against manufacturer, model, hostname, IP, or MAC
Sort: column header click

Filters reset when you change scope (clicking a different client or location card). Selection state for bulk actions resets too, and the checkbox bar clears.