Enterprise Print Servers

History

Networked, server-mediated printing predates the personal-computer LAN. The BSD UNIX line printer daemon (lpd), with its lpr/lpq/lprm client commands, established the client-submits-to-a-spooling-daemon model in the early 1980s; that protocol was later documented in RFC 1179 (August 1990). Novell NetWare popularized the print-server concept on PC LANs in the late 1980s and early 1990s with network print queues and dedicated print-server processes.

Microsoft's spooler architecture as it exists today derives from the Windows NT print subsystem and Windows 2000, which added the ability to publish print queues into Active Directory. On UNIX-like systems, CUPS (originally the "Common UNIX Printing System") was created by Michael Sweet at Easy Software Products, with first public releases in 1999, and rapidly became the default print system across Linux distributions. Apple adopted CUPS for Mac OS X 10.2 in August 2002, hired Sweet and purchased the CUPS source code in February 2007, and after Sweet left Apple in December 2019 the OpenPrinting organization forked the project in 2020 as the actively developed upstream.

Standardization of the network protocol followed. The Internet Printing Protocol (IPP) was developed in the late 1990s and standardized by the IETF as RFC 2910/2911 in 2000, later replaced by RFC 8010/8011 in 2017, and is maintained today by the Printer Working Group (PWG). The cloud era arrived with Microsoft Universal Print, which reached general availability in 2021 and relocates the print-server role to a Microsoft 365 hosted service.

Architecture

Windows print server. The Windows spooler is a set of user-mode components; Microsoft documents that all spooler components execute in user mode (only part of the Graphics Device Interface, the kernel-mode graphics engine, runs in kernel mode).

• Application and GDI — applications create jobs by calling GDI functions; GDI, together with the printer driver, either spools drawing instructions as an Enhanced Metafile (EMF) or renders a printable stream.
• winspool.drv — the client-side interface to the spooler; it exports the spooler's Win32 API and provides RPC stubs for reaching a server.
• spoolsv.exe — the spooler's API server, implemented as the Print Spooler service and started at boot. It exports an RPC interface and forwards calls to a print provider through the router.
• spoolss.dll (router) — selects which print provider handles a call based on the printer name or handle.
• Print providers — the local print provider (localspl.dll) handles printers managed by the local system, including directly network-attached printers; the network print provider (win32spl.dll) uses RPC to redirect calls to a remote server's spoolsv.exe, whose local print provider then does the work.
• Print processor — a plug-in that converts spooled data (for example EMF) into the final output format and controls features such as N-up, copies, and page order; supported input data types include EMF, RAW, and TEXT.
• Print monitors — language monitors and port monitors handle final device and port communication.

The Print and Document Services server role (called "Print Services" before Windows Server 2008 R2) packages this with management tooling, including the Print Management console and migration tooling that can export and import queues, drivers, and jobs.

CUPS server. CUPS is organized around a central scheduler:

• Scheduler (cupsd) — an HTTP and IPP server that manages printers, classes, jobs, subscriptions, and notifications, spawning external helper processes (usually under an unprivileged account) for printing, notification, and discovery.
• Configuration files — cupsd.conf, printers.conf, classes.conf, subscriptions.conf, the MIME rule files mime.types and mime.convs, plus per-printer PPD files.
• Spool and logs — jobs live in /var/spool/cups as control files and data files; logs in /var/log/cups are access_log, error_log, and page_log (the last enabling print accounting).
• Filters — convert job files toward a printable format.
• Backends — send data to and enumerate devices: AppSocket (JetDirect), IPP, LPD, and USB, plus DNS-SD and SNMP for discovery.
• Legacy compatibility — Berkeley commands (lpr, lpq, lprm, lpc) and System V commands (lp, lpstat, lpadmin, cancel, lpmove); incoming LPD requests are handled by cups-lpd on TCP port 515, conforming largely to RFC 1179.

How it works

A print server exposes logical print queues (a "printer" in both CUPS and Windows terminology) that map to one or more physical devices. Clients are configured — manually, by directory lookup, or by automatic discovery — to submit to these queues rather than to hardware directly.

On Windows, a client typically obtains the queue by Point and Print: connecting to a share such as \\server\sharename provisions either a full v3 driver or a driver-less v4 configuration to the client. The client's spooler then submits jobs over RPC to the server's spooler. Whether rendering happens on the client or the server is governed by client-side rendering (the default since Windows Vista) and can be forced server-side by Group Policy.

On CUPS, sharing is enabled on the server with cupsctl --share-printers and each queue is marked shareable with lpadmin -o printer-is-shared=true. Clients discover shared queues automatically via DNS-SD/Bonjour, or are pointed at a server explicitly through /etc/cups/client.conf (ServerName), a per-user ~/.cups/client.conf, or the CUPS_SERVER environment variable. Jobs travel over IPP by default.

Central to both is hold-and-schedule: the server accepts and stores the job, applies access control and quotas, selects an available physical device (a printer class in CUPS, or a printer pool), performs any format conversion, and streams the result to the device through the appropriate backend or port monitor.

Data flow

Windows (client to shared server queue):

• The application calls GDI; GDI and the driver produce an EMF spool file (or RAW if rendering immediately).
• The client spooler (winspool.drv to the router spoolss.dll) routes the job. For a remote shared printer, the network print provider win32spl.dll marshals the call over RPC.
• On the server, spoolsv.exe receives the RPC call and the local print provider localspl.dll creates a spool file.
• When scheduled, the print processor converts the spool data (EMF to RAW) or passes RAW through.
• A port monitor or language monitor sends the final page-description stream out the configured port — commonly a raw TCP/IP port or LPR.
• With client-side rendering, the rendering step occurs on the client, so fully rendered page-description data is what crosses to the server for queuing.

CUPS (client to server to device):

• The client submits via IPP (an HTTP POST carrying application/ipp) to the server's cupsd, which writes a control file and a data file in /var/spool/cups.
• cupsd consults the MIME rules and the printer's PPD to build a filter chain converting the document toward the printer's format.
• Filters run in sequence, optionally through a port monitor.
• A backend (AppSocket/JetDirect, IPP, LPD, or USB) transmits the final stream to the device.
• Each page is recorded in page_log; the data file is normally deleted after a successful print.

Operating system integration

Windows. Print serving is a first-class OS role (Print and Document Services) driven by the Print Spooler service (spoolsv.exe). Remote operation is defined by documented RPC-based protocols — the Print System Remote Protocol ([MS-RPRN]), the Print System Asynchronous Remote Protocol ([MS-PAR]), and the Print System Asynchronous Notification Protocol ([MS-PAN]). Management flows through the Print Management console and Group Policy; deployment and driver provisioning use Point and Print and the v4 print driver model with enhanced Point and Print, in which clients receive configuration without downloading the full manufacturer driver.

UNIX, Linux, and macOS. CUPS is the OS print subsystem, integrated via the standard lp and lpr command families, the IPP-based programming interface (libcups), and PPD-driven queues. macOS ships CUPS as its printing system, and Linux distributions ship cupsd as the default.

Windows and CUPS interoperate at the protocol level: CUPS can print to Windows shares over SMB (via Samba), and both speak IPP, so a CUPS client can queue to a Windows or IPP server and vice versa.

Relationship to standards

• IPP (Internet Printing Protocol) — the primary modern transport for both CUPS (native) and Windows (via the IPP class driver and Universal Print). Standardized in RFC 8010 (encoding and transport over HTTP) and RFC 8011 (model and semantics), which obsoleted the original RFC 2910 and RFC 2911. Maintained by the PWG; CUPS embeds an IPP server directly in cupsd.
• LPD/LPR (RFC 1179) — the legacy line-printer protocol on TCP 515; supported by CUPS via cups-lpd and by Windows' LPD components for backward compatibility.
• DNS-SD / Bonjour (mDNS) — used by CUPS and IPP Everywhere for zero-configuration discovery of shared queues.
• SMB/CIFS — the Windows print-sharing surface; CUPS can use it as a backend to Windows servers.
• PPD (PostScript Printer Description) — per-printer capability files historically central to CUPS, now increasingly superseded by IPP attribute models and IPP Everywhere.
• PWG standards and IPP Shared Infrastructure Extensions (IPP INFRA) — among the standards Universal Print builds on for driverless, cloud-mediated printing.

Relationship to technologies

• Directory services. Windows print servers can publish queues to Active Directory so users can search for printers by attributes. Publication calls the spooler's SetPrinter function with a PRINTER_INFO_7 structure, and the spooler mirrors published data into registry keys it maintains; the pubprn script can publish to a specified LDAP container. Group Policy governs publishing, pruning, and Point and Print behavior. CUPS uses DNS-SD for discovery rather than a heavyweight directory.
• RPC. Windows client-to-server print traffic is RPC-based. Windows 11 22H2 defaults print communication to RPC over TCP (with Named Pipes still available but disabled by default) and can optionally enforce Kerberos authentication in domain-joined environments.
• Network printing transports. Raw TCP (AppSocket/JetDirect on port 9100), LPR/LPD, IPP, and USB are the backends by which servers reach devices.
• Cloud printing. Universal Print relocates the server role to Microsoft 365, using Microsoft Entra ID identity, TLS, the Microsoft Graph print API, and an optional on-premises connector for legacy printers.

Relationship to manufacturers

HP JetDirect is the canonical dedicated hardware print server: external boxes and internal cards, introduced in March 1991, that attach a printer to a LAN. Its raw TCP/IP printing on port 9100 became a de facto standard that CUPS implements as its AppSocket (JetDirect) backend (socket:// device URIs) and that Windows reaches through a raw TCP/IP port. Strictly, the AppSocket name originated with Tektronix while HP's raw port-9100 protocol is JetDirect; CUPS groups them under one backend, but they are historically distinct. A JetDirect box is a network transport or attachment device with at most minimal queuing — it does not provide the centralized spooling, driver distribution, directory publishing, or accounting of a full print server.

Printer OEMs (HP, Epson, Canon, Brother, Lexmark, Xerox, and others) supply the drivers and PPDs a server stores and distributes, and increasingly ship IPP Everywhere, Universal Print–ready, and Mopria-conformant devices that need no vendor driver on the server or client. Microsoft and Apple/OpenPrinting supply the two dominant server stacks, and Samba provides the SMB print-server surface on UNIX-like systems.

Modern relevance

The classic on-premises print server remains widespread in enterprises for centralized driver management, queue-based access control, auditing, and secure-release printing. Three forces are reshaping it.

• Driverless printing. IPP Everywhere, Mopria, and the Windows inbox IPP class driver reduce dependence on vendor drivers, and CUPS is moving away from PPD-based drivers toward IPP attributes.
• Cloud print services. Universal Print eliminates on-premises print servers for many organizations, moving spooling, queue management, and discovery into Microsoft 365 with Entra ID identity; legacy printers are bridged with a connector.
• Security hardening. The 2021 PrintNightmare spooler vulnerabilities drove tighter Point and Print restrictions and the RPC changes in Windows 11 22H2. In 2024 a critical remote-code-execution chain in the UNIX-side printing stack — centered on the cups-browsed service and triggered by printing to a malicious queue — similarly reshaped defaults on Linux systems. Security, not just convenience, now motivates disabling or replacing the traditional spooler where possible.

Common misconceptions

• "A print server always renders print jobs." Not necessarily. With client-side rendering (the Windows default since Vista) and enhanced Point and Print, rendering often happens on the client; the server mainly queues and dispatches.
• "A JetDirect box is a print server in the same sense as a Windows or CUPS server." It is a network transport or attachment device with at most minimal queuing; it does not provide centralized spooling, driver distribution, directory publishing, or accounting.
• "Windows and CUPS cannot interoperate." They share IPP, and CUPS can print to Windows shares over SMB; cross-platform printing is routine.
• "Universal Print is just a hosted Windows print server." It is a re-architected cloud service based on IPP INFRA and Microsoft Graph, with Entra ID identity and per-device certificates — not a lift-and-shift of spoolsv.exe.
• "All spooler components run in the kernel." On Windows, all spooler components run in user mode; only part of GDI (the graphics engine) is kernel-mode.
• "Publishing a printer to Active Directory is what makes it shareable." Sharing and directory publication are distinct: a queue is shared at the server, and separately (and optionally) published to AD for searchability.

Timeline

1. Early 1980s

   BSD UNIX lpd/lpr establish the spooling-daemon model for network printing.

2. Late 1980s–early 1990s

   Novell NetWare popularizes PC-LAN print queues and dedicated print-server processes.

3. March 1991

   HP JetDirect network print-server products appear, using raw TCP/IP printing on port 9100.

4. August 1990

   RFC 1179 documents the LPD/LPR line-printer protocol.

5. 1999

   CUPS first released by Easy Software Products (Michael Sweet).

6. 2000

   IETF publishes IPP as RFC 2910/2911; the Windows 2000 spooler adds Active Directory printer publishing.

7. August 2002

   Apple adopts CUPS for Mac OS X 10.2.

8. February 2007

   Apple hires Michael Sweet and purchases the CUPS source code.

9. 2008 R2

   Windows Server renames the "Print Services" role to "Print and Document Services."

10. Windows Vista era

    client-side rendering becomes the default; v4 drivers and enhanced Point and Print follow.

11. 2017

    IPP is replaced by RFC 8010 and RFC 8011, maintained by the PWG.

12. 2020

    OpenPrinting forks CUPS as the active upstream after Michael Sweet leaves Apple (December 2019).

13. 2021

    PrintNightmare spooler vulnerabilities disclosed; Universal Print reaches general availability.

14. 2022

    Windows 11 22H2 defaults print RPC to RPC over TCP, with optional Kerberos enforcement.

15. 2024

    A critical remote-code-execution chain disclosed in the CUPS/cups-browsed stack affecting Linux systems.