The PaperCut 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 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 onto a site’s Print Server (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 Server, Single Print Server deployment and suits the large majority of our customer’s deployments.
Some more complex implementation examples exist below, as a way of showing what’s possible. It should be easy to extend or merge some of these concepts to suit your network and create your ideal PaperCut deployment.
PaperCut operates at a layer above your network print services. For this reason we recommend you design your solution to provide your printing services first, then integrate the PaperCut Application into your network second. i.e. if you need to have a Print Server per site to stop large jobs traversing network links, do so. If you need to use clustering to provide high up time to printing services, make that choice too. PaperCut will then fit into these choices.
All of the solution designs in the next section can be complemented with the PaperCut Site Server.
The PaperCut site server gives the risk averse customer peace of mind that access to printing resources won’t be interrupted by unexpected network dropouts. Customers that deploy the PaperCut Site Server will ensure 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 like 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.
It is quite common for sites to have multiple print servers, even if they are a customer at a single physical location.
iOS printing - Supporting printing from iOS devices may be deployed 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 will need to be installed and configured to communicate with the Application Server. Detailed information on how to install a Secondary Print Provider is available in our manual.
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 Provider host.
Not all multi site installations rely on a print server on each site. This may be because the sites are small and don’t warrant the resources, or because they are quite large and have resources centralised in a data centre or on the private cloud.
In either case, if all printing is centralised 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.
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 centralised print server to only be sent back again to the remote site where the destination printer is located. This may 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 Secondary Print Providers 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.
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 centralised reporting service.
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.
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 may need to be managed in your environment.
| Deployment type | Benefits | Considerations |
|---|---|---|
| 1 site, multi server |
|
|
| Multi site, single server |
|
|
| Multi site, multi print servers |
|
|
| Multi site, multi Application Servers |
|
|
Table 10.1. Deployment model comparisons
For further details of setup for each scenario, please refer to the following resources. and .