Print and Document Services

What Is Print and Document Services?

Print and Document Services is the Windows Server role that centralises printer management. Instead of every workstation holding its own local printer driver and talking directly to a network printer, a print server owns the shared queue, the driver, and the port, and clients connect to that queue over the network.

Think of a print server as a librarian rather than a photocopier. Client computers do not need to know how to physically operate a specific printer model; they hand the print job to the print server, which already has the correct driver and knows exactly how to talk to that device. When the printer changes, only the print server’s driver needs updating, not every workstation’s.

The role’s central console is the Print Management snap-in, and its central process is the Print Spooler service. The role also includes optional role services for Internet Printing (printing over HTTP using IPP) and the deprecated LPD Service (Line Printer Daemon, for UNIX-style LPR clients) — Microsoft flagged LPD and LPR for eventual removal starting with Windows Server 2012, so new deployments should avoid depending on it.

Installing the Role

Print and Document Services installs like any other Windows Server role: through Server Manager’s Add Roles and Features wizard, or from PowerShell. On Server Core, PowerShell is the only option.

# Install the Print Server role service and its management tools
Install-WindowsFeature -Name Print-Server -IncludeManagementTools

# Confirm what installed
Get-WindowsFeature -Name Print*

# Optional role services, install only if you need them
Install-WindowsFeature -Name Print-Internet -IncludeManagementTools
Install-WindowsFeature -Name Print-LPD-Service

In Server Manager, the same install is Add Roles and Features > Server Roles > Print and Document Services > Print Server. A restart is not normally required for the Print Server role service itself. Once installed, the Print Spooler service (display name Print Spooler, service name Spooler) starts automatically and stays running as long as any printer queue exists on the box.

The Print Management Console

Open the console from Server Manager’s Tools menu, or run printmanagement.msc directly. It gives you four things in one place: Print Servers (the server itself, its drivers, ports, and printers), Custom Filters (saved views, useful for spotting queues with jammed jobs across a whole print server farm), Deployed Printers (printers pushed out via Group Policy), and the ability to add remote print servers to the same console so one administrator can manage a fleet from a single window.

Right-clicking Drivers under a print server lets you add a driver from the local driver store, from Windows Update, or from an INF supplied by the manufacturer — this has to happen before a driver can be attached to any printer. Right-clicking Ports lets you create a TCP/IP, LPR, or local port. Right-clicking Printers lets you add a printer to an existing port and driver, and share it.

Managing Printers, Ports, and Drivers with PowerShell

The PrintManagement module ships with Windows Server and mirrors what the console does. A printer is built from three pieces that must exist in this order: a driver, a port, then the printer itself that ties them together and shares the result.

# Add a printer driver (it must already be in the driver store — use
# pnputil /add-driver first if it isn't, or add it via the console's
# Add Driver wizard)
Add-PrinterDriver -Name "HP Universal Printing PCL 6"

# Create a standard TCP/IP port pointing at the printer's IP address
Add-PrinterPort -Name "IP_192.168.10.50" -PrinterHostAddress "192.168.10.50"

# Create and share the printer, tying the driver to the port
Add-Printer -Name "Finance-3F-HP-M608" `
  -DriverName "HP Universal Printing PCL 6" `
  -PortName "IP_192.168.10.50" `
  -Shared -ShareName "Finance-3F-HP-M608"

# List every printer on a server, with its driver and share name
Get-Printer -ComputerName PRINT01 | Select-Object Name, DriverName, ShareName, Shared

# List installed drivers and their environment (x64, x86, ARM64)
Get-PrinterDriver -ComputerName PRINT01 | Select-Object Name, DriverVersion, PrinterEnvironment

# Set a default paper size and duplex mode for a queue
Set-PrintConfiguration -PrinterName "Finance-3F-HP-M608" -PaperSize A4 -DuplexingMode TwoSidedLongEdge

# Remove a decommissioned printer
Remove-Printer -Name "Finance-3F-HP-M608" -ComputerName PRINT01

Printer Driver Isolation

A printer driver is third-party code running with access to the spooler process. A poorly written driver — and there are a lot of them — can crash, leak memory, or corrupt state in ways that would otherwise take the entire Print Spooler service down with it, which stops every queue on the server, not just the one using the bad driver. Driver isolation exists to contain that blast radius.

Think of driver isolation as separating problem tenants into their own apartment rather than letting every driver share one open-plan office with the spooler. If one driver misbehaves, it only affects processes it shares an isolation boundary with, not the spooler itself.

Whether a driver is capable of isolation is declared by the driver’s own INF file (the DriverIsolation keyword); an administrator can only choose which of the supported modes to use, not force isolation onto a driver that never declared support for it. The per-driver mode is set from the Print Management console — expand Print Servers > (server) > Drivers, right-click a driver, open Properties, and use the driver isolation setting there. There is no dedicated PowerShell cmdlet for this in the PrintManagement module, so the console (or the underlying spooler API, for custom tooling) is the supported path.

Two related Group Policy settings sit under Computer Configuration > Policies > Administrative Templates > Printers: Execute print drivers in isolated processes, which can force isolation on or off fleet-wide regardless of the per-driver setting, and Override print driver execution compatibility setting reported by print driver, which forces isolation even for a driver whose INF never declared support for it — useful during troubleshooting, but not something to leave enabled indiscriminately, since an unsupported driver forced into isolation can misbehave in new ways.

Point and Print and the PrintNightmare Hardening

Point and Print is what lets a client connect to a shared printer on a print server and automatically download and install the matching driver, without a user hunting down and running a separate driver installer. It is the feature that makes browsing to \\printserver\printername and getting a working printer in seconds actually work.

That convenience is exactly why it became a security problem. CVE-2021-34527 (“PrintNightmare”) and the related CVE-2021-34481 showed that Point and Print’s driver-installation path could be abused to run attacker-supplied code with SYSTEM privileges on a client, because in the vulnerable configuration a non-administrator could trigger driver installation without an elevation prompt. Microsoft shipped a series of updates through mid-to-late 2021 that changed the secure default and gave administrators explicit registry and Group Policy control over the behaviour.

The controlling registry values live under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint:

Before the July 6, 2021 updates, RestrictDriverInstallationToAdministrators did not exist and members of the built-in Print Operators-style groups could install unsigned drivers with no elevation. The July 6, 2021 update introduced the value with a default that still allowed the old behaviour; the August 10, 2021 update changed the effective default so that driver installation requires administrator rights unless an administrator explicitly opts out. Treat any print server or client where this value is deliberately set to 0 as a documented exception, not a forgotten setting.

The matching Group Policy path — Computer Configuration > Policies > Administrative Templates > Printers > Point and Print Restrictions — was itself relocated. It used to live under User Configuration > Policies > Administrative Templates > Control Panel > Printers, and Windows now silently ignores the policy if it is configured in that old user-context location. If Point and Print Restrictions ever appears to have no effect, checking whether it was configured under the old User Configuration path instead of the current Computer Configuration path is the first thing to check.

Deploying Printers with Group Policy

There are two supported ways to push a shared printer connection out to a fleet without asking every user to browse for it. The first is from the Print Management console itself: right-click a shared printer under Print Servers > (server) > Printers and choose Deploy with Group Policy. It prompts for an existing GPO and a scope — The users that this GPO applies to (per user) makes the printer follow the user to whatever computer they log on to, and The computers that this GPO applies to (per machine) makes the printer available to anyone using that computer. Per-user deployments write to User Configuration > Policies > Windows Settings > Deployed Printers; per-machine deployments write to the equivalent node under Computer Configuration.

The second method is Group Policy Preferences: in the Group Policy Management Editor, go to User Configuration > Preferences > Control Panel Settings > Printers, right-click, and add a Shared Printer item. GPP printers support item-level targeting (deploy a specific printer only to a specific OU, security group, or site), which the Print Management console’s own wizard does not.

Gotchas and Best Practices

Keep drivers current and minimal — every extra driver version on a print server is one more thing that can crash the spooler, and orphaned drivers left behind after a printer model is retired serve no purpose. Prefer the print-class or Type 4 (v4) drivers where the printer supports them: they install without per-architecture driver copies and use the enhanced Point and Print compatibility driver for older clients, reducing the number of driver binaries the server has to maintain. Cluster the Print Spooler role on a failover cluster, or run more than one print server behind DNS round robin, if a single print server going down would meaningfully block business printing — the role itself has no built-in high availability.

Troubleshooting Cheat Sheet

Final Thoughts

Print and Document Services is one of the older, quieter roles in Windows Server, and that is exactly why its defaults matter — most administrators configure a print server once and don’t revisit it until something breaks or a security scan flags it. Driver isolation and Point and Print security are not separate advanced topics bolted onto printing; they are the mechanism that decides whether a bad driver takes down one queue or the whole spooler, and whether a compromised or spoofed print server can push code onto every client that connects to it.

Treat the print server the same way you would treat any other server that clients trust to hand them executable code: patch it, minimise the drivers on it, and leave the PrintNightmare-era hardening in its secure default state unless there is a specific, documented, and scoped reason to relax it.