Print Server Management

Server-side printing operations: keep the spooler honest, deploy drivers deliberately, and move print queues between servers without a day of "I can't print" tickets. This needs the RMM connected; if the print server is client- or co-managed, your output is a recommendation package for their administrator.

1. Confirm the blast radius says "server": one user -> route to printer-troubleshooting (troubleshooting-playbooks); one physical printer, all users -> likely the device or its queue; many printers, many users -> print server. Identify the server via documentation (IT Glue / Hudu) and locate it in the RMM (verify role in the device details — hostname inference like PRINT/PS is a hint, not a fact; don't trust a class filter).
2. Spooler triage: check the Print Spooler state in the device's Windows services; read the recent device activity for crash/restart history. Known-issue pattern check before restarting anything: repeated crashes are classically a corrupt job stuck in the queue, a bad driver (one printer's driver taking down the shared spooler), or a recent Windows print-related update — check the activity history for patches landing just before the crashes began. Read the ticket history for prior spooler tickets on this server; a chronic pattern means fix the cause, not the symptom.
3. Restart with consent: a spooler restart kills in-flight jobs for everyone. Confirm with the requester (or note the outage is already total), then restart the Print Spooler service through the RMM. If a stuck job is suspected, the queue purge (clearing the spool directory) is hands-on — hand the tech a deep link into the device in the RMM with the steps spelled out. If crashes resume, isolate the offending driver/queue rather than scheduling recurring restarts as a "fix" (acceptable only as a stopgap, and say so).
4. Driver deployment discipline: drivers are deployed through the documented mechanism (print management/GPO/deployment tool), never installed one-off on the server mid-incident. Prefer the vendor's stable/universal driver line; stage on one queue before fleet-wide rollout; record every driver change in documentation. This integration cannot deploy software — driver work is a spec + deep-link handoff.
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/GPO mappings, keep the old server's shares alive until mappings are confirmed switched). Communicate the cutover window; a queue rename breaks scripted/hard-coded mappings, so keep names/shares stable. Route the plan for approval and track as its own ticket.
6. Output per engagement: findings, root-cause hypothesis with evidence, actions taken (service restarts only), and handoff steps with deep links. Leave a plain-text note (no markdown/emojis).

Guardrails: spooler restarts affect every user printing through the server — confirm before acting unless printing is already fully down. Never chain automatic spooler restarts as a permanent fix without labeling it a stopgap and opening a root-cause ticket. No driver installs or software deployment through this skill — this integration cannot run scripts. Queue migrations happen in a change window with a rollback (old server stays up until verified) — never big-bang a cutover during business hours.