The PaperCut NG / MF solution was designed with distribution
in mind. The answer is built using the service-oriented architecture, which
allows its components to be installed on different machines with different
operating systems. This allows PaperCut NG / MF to be installed in a variety of
configurations, adapting to your network design, since no two sites are the
same.
The simplest and most common installation is to install
PaperCut NG / MF on a website's print server (where the site only has one). For
a small school or organization, the implementation need not be more complicated
than that. It is a single application Network Server Deployment, a single print server implementation, and suitable for
most deployments.
A few more complex implementation examples exist below, to
show what is possible. You can extend or merge some of these concepts to suit
your network and create the ideal PaperCut NG / MF implementation.
PaperCut NG / MF operates one layer above network printing
services. For this reason, design your solution to provide your printing
services first, and then integrate the PaperCut NG / MF application into your
network. That is, if you want a site-specific print server to stop large jobs
that cross-network links, do so. You can also use clustering to provide a high
delay for printing services.
PaperCut site server
The PaperCut site server can complete all solution projects
in the next section.
The PaperCut website Server Deployment offers the customer the risk of downpours that access to print
resources will not be interrupted by unexpected network interruptions. The
PaperCut site server implementation ensures that the essential services of the central
PaperCut server are supported locally in the event of a disaster. Site servers
are easy to install and hide the complexity of database replication to
administrators.
Although initially designed for use in multi-site solutions,
it is not the only use of the site server. Think of the site server as a proxy
for the application server, which can also perform a set of application server
tasks with the last known data set during an interruption.
Examples of
implementation
Scenario A: single site, multiple print servers
It is quite common for websites to have multiple print
servers, even if they are clients in one physical location.
IOS Printing: Implement supported printing from iOS devices
using a Mac server to complement a Windows print server.
Administrator/curriculum: Several schools separate printing
in the School Administration section from a page by general staff/students.
Bundling: 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 connected
printers.
PaperCut Site Server can add benefits to this deployment
scenario if the application server is deployed in the private cloud. The site
server would provide a local level of redundancy in the event of a connection
failure to cloud resources. One of the print servers could play this role, in
addition to hosting the print provider PaperCut.
Scenario B: multiple
sites, a single server
Not all multi-site installations depend on a print server at
each location. This may be since the sites are small and do not guarantee
resources or because they are large enough and have resources centralized in a
data center or the private cloud.
In both cases, if all printing is centralized through a
single application server and a single print server installation, the
installation will be the same as if it were a unique website with a single
server...
The PaperCut site server could add benefits to this
implementation if each site wanted to guarantee support for the primary
commercial services that use the MFD and the printed version during a network
interruption between a website and the application server.
