Queues and Assignment

A queue in ZenPrint is one printer, one driver, and one set of settings, bound to a specific name. Queues are the unit of “what gets installed on an endpoint.” The rest of the system exists to decide which queues belong on which endpoints.

Creating a queue

Every queue belongs to a printer. To create one:

1. Fleet → Printers → open the printer.
2. Scroll to the Queues panel and click Add Queue.
3. Fill in:
   • Name: what the queue will be called in the Windows print spooler on endpoints (e.g. HR Color, Reception B&W)
   • Driver: pick from the dropdown; only drivers your tenant has access to are listed (custom, captured, and ZenPrint Library). The list is grouped by how well each driver fits this printer. Exact match means the printer’s model is named in the driver’s own device list, so it’s a safe pick. Universal driver is a vendor-wide package from the same manufacturer. Same manufacturer is everything else from that brand with no model-level match. Drivers for other brands sort to the bottom. The grouping is a guide, not a lock: you can still pick anything. Exact matches depend on ZenPrint knowing the printer’s model, which comes from the network scan, so a printer that hasn’t been scanned yet falls back to manufacturer grouping.
   • Settings (optional): duplex, colour, paper size, and so on, via the settings form. Leave blank for driver defaults.
4. Save. The queue is created on the printer in Active status.

Creating the first queue on a Discovered printer auto-promotes the printer to Active. You don’t need to flip the status by hand.

The queue is defined now, but until you assign it somewhere, no endpoint will install it.

Assignment scopes

Queues are assigned to one of three target scopes, in increasing specificity:

Scope	Targets	When to use
Location	All endpoints at one location	Shared printers at a site, where everyone gets it
Group	All endpoints in a named group at one location	Department, role, or floor groupings within a site
Endpoint	One specific machine	Personal printers, kiosks, exception cases

Assignments cascade. An endpoint installs every queue assigned at its location, plus every queue assigned to a group it’s in, plus every queue assigned directly to it. The endpoint detail drawer shows where each installed queue came from, badged by source:

• Direct (amber): assigned to this specific endpoint
• Group: <name> (purple): inherited from a group
• Location: <name> (blue): inherited from the location

When the same queue is claimed at more than one scope (say it’s assigned to the location, to a group the endpoint is in, and to the endpoint directly), it still installs once. The most-specific assignment wins, and the endpoint drawer shows that most-specific source.

The assign modal

The assign modal opens from any of four entry points and adapts to what you’re assigning:

• Queue-anchored: open from a queue row. Pick endpoints, groups, or locations to assign this one queue to.
• Endpoint-anchored: open from an endpoint row. Pick queues at the endpoint’s client to assign to this endpoint.
• Group-anchored: same, but for a group.
• Location-anchored: same, but for a location.

The modal renders inherited assignments (from a parent group or location) read-only, so you can see the full picture. You can only mutate direct assignments at the anchor level; to remove an inherited assignment, edit the parent.

Each side has a searchable, checkable list: tick a target to add the assignment, untick it to remove it. Save commits all the additions and removals in one batch.

Arriving from a driver

Clicking a driver’s queue count on the Drivers page lands you here with the list filtered to that driver, and a Driver: … chip above the table saying so. Dismiss the chip (or hit Reset) to go back to every queue. The filter is in the URL, so the view is linkable and survives a refresh until you clear it.

Seeing where a queue actually landed

The assign modal shows intent: where a queue is supposed to go. To see what happened, click the number in a queue row’s Assign. column. The row opens a drawer listing every endpoint the queue reaches, and for each one:

• Assigned via: Direct, a group, or the location. That tells you where to go to change it: an assignment inherited from a group can’t be removed from a single endpoint.
• State: in sync, pending install, config drift, install failed, missing on endpoint, or not assigned any more. Install failures show the error underneath.
• On the endpoint: the queue’s local name and driver as the endpoint reports them, which is how you spot a queue that was renamed locally or adopted from another tool.
• Last verified: when the endpoint last confirmed it.

Endpoints that reconcile skips (inactive, or still pending approval) are listed too, marked as such. An assigned queue that never lands is usually explained by that line.

Row actions let you remove a direct assignment without leaving the drawer.

Bulk operations

The bulk bar at the bottom of the Queues tab activates when you check one or more queue rows. Available actions:

• Change Driver: swap to another driver across all selected queues
• Delete: remove all selected queues (cascades to their assignments and installations)
• Bulk Assign: assign all selected queues to one target (location, group, or endpoint)
• Bulk Unassign: the opposite

Bulk assign is the right tool for “I just captured an HP driver and want to attach the four lobby printer queues to the Lobby Endpoints group.”

The bulk bar respects client scoping on custom roles. A scoped user only sees rows within their scope, so out-of-scope queues never appear to select in the first place. The server re-checks scope on submit and refuses the action if a selection somehow falls outside it, so the rule holds even against a tampered request.

When endpoints move between customers

When an endpoint shows up under a new customer in your RMM (the NinjaOne organization changes, say), ZenPrint follows the move. The endpoint’s location is updated to match what the RMM is reporting.

But queue assignments that were directly pinned to that endpoint (“this specific machine gets this queue”) get marked stale. They were set up for the old customer and probably shouldn’t follow. The dashboard surfaces a Stale Queue Assignments alert so you can decide what to do: rebind to a new queue, or accept the loss.

Group and location assignments aren’t affected by moves. They’re attached to the group or location, not the endpoint, so they heal automatically as the endpoint changes hands.

Queue settings

Beyond name and driver, queues carry a JSON settings blob with optional overrides:

• Duplex (one-sided, two-sided long edge, two-sided short edge)
• Colour mode (colour or mono)
• Paper size (A4, Letter, Legal, A3)
• Collate (on or off)

Empty fields mean “driver default,” and reconcile doesn’t touch what the driver says. Only set what you want to override.

Default printers

ZenPrint installs and configures queues. It doesn’t decide which one is the Windows default printer.

That’s deliberate. Reconcile runs as SYSTEM, and the default printer is a per-user setting, so there’s no single “the default” on a shared endpoint to begin with. Windows also moves it around on its own when “Let Windows manage my default printer” is on. A tool that enforced a default on every reconcile run would keep overwriting choices your users made, which is worse than leaving it alone.

If you do want to set a default, your RMM can do it in a couple of lines. ZenPrint isn’t involved and doesn’t need to be:

$name = 'Accounting-MFP'

New-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows' `
  -Name LegacyDefaultPrinterMode -Value 1 -PropertyType DWord -Force | Out-Null

Get-CimInstance Win32_Printer -Filter "Name='$name'" | Invoke-CimMethod -MethodName SetDefaultPrinter

Two things decide whether this works.

It has to run as the logged-on user, not as SYSTEM. Most RMMs run scripts as SYSTEM by default. If you leave that as-is, the script sets SYSTEM’s default printer, returns success, and the user sees nothing change. Check how your RMM runs a script in the user’s context, and trigger it on logon or on demand.

Set LegacyDefaultPrinterMode first. It turns off “Let Windows manage my default printer” for that user. Without it, Windows re-points the default at whatever the user printed to most recently, and the script looks like it randomly stops working.

One caveat on checking your work: the Settings app caches the current default and often still shows the old printer after the change. Applications pick up the new default when they next start. To confirm what actually got set, read it back instead of trusting the UI:

Get-CimInstance Win32_Printer -Filter "Default=TRUE" | Select-Object Name

This approach needs a printer name you can hardcode across the fleet, which is exactly what consistent queue naming in ZenPrint gives you. If the same printer is called something different at every site, you’re maintaining a per-site variant of the script and a mapping to go with it.

When a queue name is already taken on the endpoint

If an endpoint already has a queue with the name ZenPrint wants to use, reconcile takes that queue over instead of failing. It points the existing queue at the right port and driver, applies your config, and registers it as ZenPrint-managed from then on.

This matters if you run a naming convention. Standardise on something like <Model> - <Location> and you’ll hit the collision constantly, because whoever set the printer up before you probably reached for the same name. Taking the queue over rather than creating a second one means the endpoint ends up with one queue, not two, and the run reports it as adopted rather than installed.

Taking it over also keeps the printer itself in place, so a user who had it set as their default keeps it. Deleting and recreating the queue would lose that.

One thing it won’t do: if the name is already used by a different ZenPrint queue on the same endpoint, reconcile stops and says so rather than reassigning it. Rename one of the two.

Adoption doesn’t look at where the existing queue currently points. A queue on a stale address, from an old DHCP lease or a swapped unit, is exactly the case worth repairing, so reconcile moves it to the right port and reports the change. If you see an adoption repoint a queue you didn’t expect, that usually means two printers of the same model at one site are colliding under your naming convention.

When a queue is changed on the endpoint

Reconcile checks the two things about a managed queue that ZenPrint owns: the driver it uses, and the port it prints through. If someone changes either of those on the machine itself, the next reconcile run notices, puts them back, and tells you it did. Both are admin-level changes, so this is not something a user can trip by accident.

You see it in three places: the reconcile output in your RMM (a DRIFT line naming what it found), the audit log, and the drift.detected alert if you’ve subscribed to it. The alert fires once when a queue starts diverging and stays quiet until it’s back in sync, so a queue that keeps drifting won’t page you on every run.

Queue settings (duplex, colour, paper size) are not checked this way, on purpose. Printers report those back inconsistently, and a device that can’t duplex or that renames a paper size would look like it was drifting forever. Instead, if a printer refuses one of the settings ZenPrint applies, the queue’s row in the endpoint drawer says so directly: the queue is installed and printing, one setting just didn’t take.

When your changes take effect

You don’t push from the UI. Your changes update ZenPrint’s idea of what should be installed where, and the next reconcile run on each affected endpoint picks the change up and applies it.

Most changes propagate within whatever interval you’ve set reconcile to run on, typically 24 hours. Need it to happen faster? Trigger reconcile ad-hoc from your RMM on the specific endpoint.

See Scripts → reconcile for what reconcile actually does.