Print Server Management

Server-side printing: spooler triage, deliberate driver deployment, and queue migrations
that don't cost a day of "I can't print" tickets. Client- or co-managed server -> your
output is a recommendation package for their administrator.

1. Confirm the blast radius says "server": one user -> printer-troubleshooting; one
   printer, all users -> that device or its queue; many printers, many users -> the
   server. Identify it in documentation (IT Glue / Hudu) and locate it in the RMM,
   verifying the role in the device details — PRINT/PS hostnames and class filters are
   hints, not evidence.

2. Spooler triage: check the Print Spooler state in the device's Windows services and read
   recent activity for crash history. Repeated crashes are classically a corrupt job stuck
   in the queue, a bad driver (one printer's taking down the shared spooler), or a recent
   Windows print update — look for patches landing just before the crashes began. Prior
   spooler tickets on this server mean fixing the cause, not the symptom.

3. Restart with consent: a spooler restart kills in-flight jobs for everyone — confirm
   with the requester first (or note printing is already fully down), then restart the
   service through the RMM. A suspected stuck job means a queue purge (clearing the spool
   directory), which is hands-on — hand the tech a deep link into the device with the
   steps spelled out. If crashes resume, isolate the offending driver or queue; recurring
   restarts are a stopgap, and must be labelled one.

4. Driver discipline: drivers go out through the documented mechanism (print management,
   GPO, deployment tool), never installed one-off on the server mid-incident. Prefer the
   vendor's stable or universal line, stage on one queue before fleet-wide rollout, and
   record every change in documentation.

5. Queue migration (server replacement): inventory every queue on the old server (name,
   share name, driver, IP port, defaults) from documentation plus a hands-on export the
   tech performs. Plan the cutover: recreate queues on the new server, stage drivers,
   migrate user and GPO mappings, keep the old server's shares alive until mappings are
   confirmed switched. Communicate the window; keep names and shares stable — a rename
   breaks scripted and hard-coded mappings. Route the plan for approval, tracked as its
   own ticket.

6. Output findings, root-cause hypothesis with evidence, actions taken (service restarts
   only) and handoff steps with deep links, as a note (apply the PSA Note Discipline base
   skill — plain text, no markdown or emojis).

Guardrails: no driver installs or software deployment here — this integration cannot run
scripts, so driver work is a spec plus a deep-link handoff. Queue migrations happen in a
change window with a rollback (the old server stays up until verified); never big-bang a
cutover in business hours.