Wide Area Networks (WAN) Considerations

I am considering setting up PaperCut 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? Option 1 - Deploy a PaperCut Site Server. PaperCut Site Servers provide the most robust multi-site PaperCut deployment model. The majority of PaperCut deployments are designed with a centralised primary server, complemented by a number of local print servers communicating back to the primary site over WAN links. 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 However this solution relies on the availability of the WAN link between primary and secondary sites. The PaperCut Site Server can be deployed at each remote site to defend against the primary server becoming unavailable, and retain all the features of a centralised installation. Essential print and copy services will remain available even during a network outage. System administrations should consider the following: Existing Print Providers are easily upgraded to be Site Servers, making efficient use of server infrastructure. Configuration data is replicated between sites, which generates some traffic overhead. On the other hand, the Site Server will reduce the WAN traffic from embedded devices. The precise traffic volumes will depend on the number of users in the solution and the number of embedded devices at each site. Client-server communications (see Option 2) still traverses the WAN links and will have a minor impact on bandwidth consumption. Option 2 - One site will host the primary server and remote sites will host a local print server reporting back to the primary server. Customers that have a reliable and good quality WAN link between their sites can choose to install their multi-site solution without the PaperCut Site Server. 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 unless the failure mode of “Allow new print jobs to print and log after reconnection” is selected. With this latter mode, when the connection is reestablished, the job log data will be resent to the server. Further discussion on this topic can be found in the user manual, Behavior on Server Connection Failures. Server-server and client-server communication will still 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. Option 3 - One site will host a reporting server and remote sites will host their own primary print server reporting back to the reporting server. Installing PaperCut in a decentralized method is to have an independent installation at each site (each site hosts their own primary server). This can be a more appropriate configuration if there are a few largely autonomous sites. In this case, a primary PaperCut server can be installed at each site. This configuration leverages a PaperCut feature called “Central reporting”. This will allow each sites database to talk to one central location and consolidate the data together for easy reporting. The large advantage of this is that each site is not reliant on the WAN while maintaining reporting integrity. As PaperCut has a browser based administration console, administrators can manage the remote Papercut servers to enable centralized administration or the administration can be segregated to provide local administration, or a mix of both as required. 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). 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. 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. 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.