Available in PaperCut NG and PaperCut MF.

Multi-server and multi-site deployments

The PaperCut NG/MF solution is designed with distribution in mind. The solution is built using Service Oriented Architecture, which allows its components to be installed on different machines of varying OS’. This allows PaperCut NG/MF to be installed in a variety of configurations, adapting to your network design as no two sites are the same.

The simplest and most common installation is to install PaperCut NG/MF onto a site’s print serverA print server is a system responsible for hosting print queues and sharing printer resources to desktops. Users submit print jobs to a print server rather then directly to the printer itself. A print server can be a dedicated server but on many networks this server also performs other tasks, such as file serving (where the site has only one). For a school or a small organization the implementation doesn’t need to be any more complex than this. This is a single Application ServerAn Application Server is the primary server program responsible for providing the PaperCut user interface, storing data, and providing services to users. PaperCut uses the Application Server to manage user and account information, manage printers, calculate print costs, provide a web browser interface to administrators and end users, and much more., single print server deployment and suits the majority of deployments.

Some more complex implementation examples exist below, as a way of showing what’s possible. You can extend or merge some of these concepts to suit your network and create your ideal PaperCut NG/MF deployment.

PaperCut NG/MF operates at a layer above your network print services. For this reason, design your solution to provide your printing services first, then integrate the PaperCut NG/MF application into your network second. i.e. if you want a print server per site to stop large jobs traversing network links, do so. You can also use clusteringClustering allows your organisation to ensure your services are not affected if anything should happen to your main server. PaperCut is a cluster compatible application and is supported under Windows (Microsoft Cluster Server / MSCS, Microsoft Failover Cluster Manager / MSFCM, Vetitas Cluster Server / VCS) and Linux (Novell Cluster Services / NCS, Linux-HA) at all levels of the application, including: clustering at the print spooler service layer by integrating with clustering services, failover based clustering at the Application Server layer using clustering services, and at the database layer by utilising cluster aware databases such as Microsoft SQL Server, PostgreSQL, or Oracle. to provide high up time to printing services.

PaperCut Site Server

All of the solution designs in the next section can be complemented with the PaperCut Site Server.

The PaperCut Site ServerSite Servers take over the role of a Primary Application Server in the event of network outages. Key roles taken over include authentication, copy and print tracking and Find-Me printing. Site Servers ensure continuous availability of printing resources to support key business functions over unreliable network links or during unplanned network disruptions. gives the risk averse customer peace of mind that access to printing resources won’t be interrupted by unexpected network dropouts. Deploying the PaperCut Site Server ensures the critical services of the PaperCut primary server are supported locally during a disaster. Site Servers are simple to install and hide the complexity of database replication from Administrators.

Whilst initially designed for usage in multi site solutions, this isn’t the only usage of the Site Server. Think of the Site Server as a proxy to the Application Server that can also perform a set of the Application Server tasks with the last known set of data during an outage.

Deployment examples

Scenario A - Single site, multiple print servers

It is quite common for sites to have multiple print servers, even if they are a customer at a single physical location.

  • iOS printing—Deploy supporting printing from iOS devices using a Mac server to compliment a Windows print server.

  • Admin / Curriculum—A number of schools separate printing in the Administration section of the school from general staff/student printing.

  • Clustering—Each node of a clustered resource is installed as a print server.

Each of the print servers in this scenario must be installed and configured to communicate with the Application Server. For more information, see Configuring secondary print servers and locally attached printers.

The PaperCut Site Server could add benefit in this deployment scenario if your Application Server were deployed within the private cloud. The Site Server would offer a local level of redundancy in the event the connection to the cloud resources were to drop. One of the print servers could play this role in addition to being a PaperCut Print ProviderA Print Provider is a monitoring service installed on a secondary print server to allow PaperCut to control and track printers. This monitoring component intercepts the local printing and reports the use back to the primary Application Server. host.

Figure 4: Multiple site / multiple print server deployment

Scenario B - Multiple site, single server

Not all multi-site installations rely on a print server on each site. This might be because the sites are small and don’t warrant the resources, or because they are quite large and have resources centralized in a data center or on the private cloud.

In either case, if all printing is centralized through a single Application Server, single print server installation, the installation is the same as if it were a single site with a single server.

The PaperCut Site Server could add benefit in this deployment if each of the sites wanted to ensure key business services of MFD usage and Print Release were supported during a network outage between a site and Application Server.

Figure 5: Multiple site / single server deployment

Scenario C - Multiple site, multiple print server

The deployment of print servers into remote sites allows for print jobs to be spooled within the local site, alleviating the need for these jobs to be sent to a centralized print server to only be sent back again to the remote site where the destination printer is located. This might be the choice of design for customers with

  • Low bandwidth between sites

  • Large print jobs generated on sites (architects, design firms, etc)

  • Historical infrastructure that supports this

The PaperCut solution supports this design though the deployment of Configuring secondary print servers and locally attached printers on each of the print servers. This allows the print jobs to remain locally spooled, with only light-weight transactional data and control information being transmitted between sites.

The PaperCut Site Server would add significant benefit in this design, possibly being installed onto one of the existing print servers. This would provide local support for Application Server functions should the link between primary and secondary sites be unavailable.

Figure 6: Multiple site / multiple print server deployment

Scenario D - Multiple site, multiple print server, multiple Application Servers

It is also possible to install PaperCut into each site of a multiple site organization as if each site itself were a separate installation of PaperCut. PaperCut has the ability to link separate Application Servers together for reporting purposes. Each individual site then has the ability to function and be administered autonomously, relying only on the links between the sites when there is a need to run a report from the Central Reports

Each of the individual autonomous sites would use one of the previous installation options. The PaperCut Site Server could then be considered for deployment to offer the same benefits listed above within these installations.

Figure 7: Multi Site/Multi Server deployment

Scenario variations

All of these scenarios can be complemented with other approaches to address high availability, resilience and scalability, including:

Comparison table

The following table should assist with comparing deployment architectures. Different models offer different benefits and challenges. The key is to select the model that addresses your primary requirements, and to understand any constraints that need to be managed in your environment.

Deployment model comparisons
Deployment type Benefits Considerations
1 site, multi server

  • Printing load distribution

  • Central Application Server administration

  • Removes single-point sensitivity at print server layer

  • Multiple print servers to manage
Multi site, single server

  • Central administration

  • Simple deployment

  • Simple user management

  • Simple queue and device management

  • Job roaming across sites (Find-Me)

  • Requires robust WAN

  • Least complex setup
Multi site, multi print servers

  • Central administration

  • Simple user management

  • Reduced WAN traffic

  • Reflects commonly used architectures

  • Job roaming across sites (Find-Me)

  • Requires robust WAN

  • Requires more servers

  • Decentralized queue management

  • Multiple find-me queues

  • More complex setup
Multi site, multi Application Servers

  • Doesn't require robust WAN

  • Enables decentralized and parallel deployment and setup

  • Decentralized administration

  • Enables rolling updates

  • Consolidated reporting is available

  • Each site requires an independent implementation

  • Overall setup for all sites requires more time

  • No job roaming across sites (Find-Me)

Further resources

For further details of setup for each scenario, refer to the following resources. and .

Scenario A - Single site, multiple print servers

Scenario B - Multi Site, single server

Scenario C - Multi site, multi print server

Scenario D - Multi site, multi print server, multi Application Server