I am considering setting up PaperCut NG/ChargeBack over a WAN network. One site will host the primary server and remote sites will host a local print server reporting back to the primary server. What are the technical considerations?

Independent installs at each site is usually the most common deployment method, however if you have a good quality WAN link, then there are a number of benefits in doing a centralized install with secondary servers at remote sites. These advantages include:

• Centralized logging
• Centralized administration
• Backups required only at one site
• Less system administration
• Users can "roam" keeping their single account and settings

System administrations should however consider the following pitfalls:

• A failed or downed network connection may result in loss of logging. PaperCut has a fail-open design by default and will not disrupt printing on failure, however some logging data may be lost during this period.
• Server-server and client-server communication will consume some bandwidth. The traffic however associated with a standard connection is very minimal. The protocol used for communication is XML Web Services based over HTTP (XML-RPC), is very bandwidth efficient, and designed to work well over high latency WAN links. Expected traffic estimates are:
  • Server-Server communication: ~500 bytes (0.5kb) per print job
  • Client-Server communication (static load): ~200 bytes (0.2kb) per minute
• There is further discussion on this topic in the user manual, Appendix E.

Alternative

An alternative to a centralized install is to have an independent installation at each site (each site hosts their own primary server). This is often a more appropriate configuration if WAN links are unreliable. Administrators can however still gain a centralized view of the data by scheduling reports, say monthly, to be automatically emailed through a single person for collation.

Special notes on client deployment on centralized setups

The client's zero-install deployment method is the easiest method of deploying the client. The downside of this method unmodified in a WAN type environment is that client binaries and associated files are pulled in off the central server on start-up. This is not usually a problem on a fast local network, but may pose problems when pulling the client down off a WAN network. Because of this we recommend the following alternate methods on remote sites (sites other than the one hosting the primary PaperCut server).

1. Consider locally installing the client on the workstations or using pc-client-local-cache.exe - an automated version that caches itself on the local harddrive.
2. A better option is to host the client on the remote sites on a local share. This involves creating a share on a server on the remote site that mirrors the PCClient share on the main server. Simply create a folder on the server, share as PCClient and copy all files from the primary server's PCClient share. Configure clients on the remote site to start the local copy of the client. Note: Remember if you upgrade the primary server in the future, remember to also upgrade the client on this remote share points.
3. Large organizations with expert system administrators may be able to improved on option 2 by utilizing Microsoft Distributed File System (DFS) or equivalent technologies on other platforms. This will provide "local transparency" when accessing the client share. You can read more about DFS at:
   http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx

It also should be noted that when the client is started, it does connect to the server. The traffic however associated with a standard connection is very minimal. The protocol is XML Web Services based over HTTP, is very bandwidth efficient, and designed to work well over high latency WAN links.

keywords: corporate networks, multiple locations, remote print management

Categories: Implementation, Architecture, Printers