> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Print Server Management

> Operate a client's print server layer — spooler known-issue triage, driver deployment discipline (no ad-hoc driver installs), and planning queue migrations to a new server. Use when "everyone can't print", the spooler keeps dying, or print queues need to move.

<Info>
  **Category:** Devices & Infrastructure · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/devices-and-infrastructure/print-server-management/SKILL.md)
</Info>

**Connectors:** `NinjaOne` `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** Multiple users at a client can't print, the Print Spooler crashes repeatedly on a print server, or a print server is being retired and its queues must migrate.

**Run it:** on one print server, on demand (not a Flow — service restarts and migrations need requester consent and change windows).

## Prompt

```
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.
```


## Related topics

- [PaperCut / PrinterLogic](/skill-library/troubleshooting-playbooks/papercut-printerlogic.md)
- [Thread MCP Server: Developer Guide](/super-magic/thread-mcp-server-developer-guide.md)
- [Label and Receipt Printers](/skill-library/troubleshooting-playbooks/label-receipt-printers.md)