Wide Area Networks (WAN) Considerations

KB Home   |   Wide Area Networks (WAN) Considerations

Main.WideAreaNetworkConsiderations History

Hide minor edits - Show changes to output

February 24, 2015, at 11:10 PM by 203.222.91.204 -
Changed line 7 from:
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:
to:
PaperCut [[https://www.papercut.com/tour/site-server/|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:
February 24, 2015, at 01:41 AM by 203.222.91.204 -
Changed lines 5-8 from:
!!!Option 1) One site will host the primary server and remote sites will host a local print server reporting back to the primary server.

An independent install 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:
to:
!!!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:
Changed lines 12-13 from:
* Users can "roam" keeping their single account and settings
to:
* 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.
Changed lines 23-37 from:

* 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, [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html | Behavior on Server Connection Failures]].

* 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, [[https://www.papercut.com/products/ng/manual/apdx-capacity-planning-bandwidth.html | Appendix E]].

!!!Option 2) 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 is often a more appropriate configuration if WAN links are unreliable.

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. 
to:
* 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, [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html|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, [[https://www.papercut.com/products/ng/manual/apdx-capacity-planning-bandwidth.html|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.
Added line 34:
May 05, 2014, at 05:36 AM by TimBentley - Removed NG reference
May 05, 2014, at 05:36 AM by TimBentley - Removed NG reference
Changed lines 3-4 from:
'''I am considering setting up PaperCut NG 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?'''
to:
'''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?'''
Changed lines 3-6 from:
Q: I am considering setting up PaperCut NG 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?

A: 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:
to:
'''I am considering setting up PaperCut NG 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) One site will host the primary server and remote sites will host a local print server reporting back to the primary server.

An independent install 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:
Changed lines 25-28 from:
!!! 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.

to:
!!!Option 2) 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 is often a more appropriate configuration if WAN links are unreliable.

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.

Changed line 51 from:
----
to:
----
Deleted lines 16-17:
* If the Print Provider is stopped then any pending held jobs will be lost after the Print Provider restarts. This problem will be fixed in an upcoming release, such that, after the Print Provider is restarted, the held jobs will continue to be held as they were before the Print Provider shut down.
Changed lines 3-4 from:
Q: 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?
to:
Q: I am considering setting up PaperCut NG 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?
September 28, 2010, at 07:21 AM by Tim - Mention about persistence of held jobs over provider restart
Added lines 17-18:
* If the Print Provider is stopped then any pending held jobs will be lost after the Print Provider restarts. This problem will be fixed in an upcoming release, such that, after the Print Provider is restarted, the held jobs will continue to be held as they were before the Print Provider shut down.
September 22, 2010, at 01:22 AM by Tim - fix up the format
Changed lines 15-20 from:
* 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,
[[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html | Behavior on Server Connection Failures]].
to:
* 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, [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html | Behavior on Server Connection Failures]].
September 22, 2010, at 01:19 AM by Tim - talk about replay too
Changed lines 15-16 from:
* 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.
to:
* 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,
[[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html | Behavior on Server Connection Failures]]
.
Changed lines 33-34 from:
# 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.
to:
# 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.''
September 07, 2007, at 12:35 AM by 218.214.136.161 -
Changed lines 23-25 from:

!! Special notes on client deployment
to:
!!! 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
Added lines 21-23:
* There is further discussion on this topic in the user manual, [[http://www.papercut.biz/products/ng/manual/apdx-capacity-planning-bandwidth.html | Appendix E]].

Changed lines 28-29 from:
# 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.
to:
# 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.
Changed lines 25-26 from:
# Consider locally installing the client on the workstations.  There is an installer to assist with this process ([@client-local-install.exe@]), or alternatively you can script the install with something like [@XCOPY@].  The client is very basis and has no [=DLL's=] to register or dependency on registry keys.
to:
# 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.
Changed lines 11-12 from:
to:
* Users can "roam" keeping their single account and settings
Changed lines 17-19 from:
** Server-Server communication: ~500 bytes (0.5kb) per print job
** Client-Server communication: ~200 bytes (0.2kb) per minute
to:
** Server-Server communication: [-~500 bytes (0.5kb) per print job-]
** Client-Server communication (static load): [-~200 bytes (0.2kb) per minute-]
Changed lines 29-30 from:
   http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx
to:

-->http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx
Changed lines 28-29 from:
# 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 [[http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) | here]].
to:
# 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
Changed line 22 from:
The client's zero-install deployment method is the easiest method of deploying the client.  The downside of this method in a WAN type environment is that client binaries and associated files are pulled in off the server on start.  This is not usually a problem on a fast local network, but may pose problems on 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).
to:
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).
Changed lines 28-29 from:
# Large organizations with expert system administrators may be able to improved on option 2 by utilizing Microsoft DFS or equivalent technologies on other platforms.  This will provide "local transparency" when accessing the client share.  You can read more about DFS [[http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) | here]].
to:
# 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 [[http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) | here]].
Changed lines 3-4 from:
Q: 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?
to:
Q: 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?
Changed lines 24-25 from:
# Consider locally installing the client on the workstations.  There is an installer to assist with this process (client-local-install.exe), or alternatively you can script the install with something like [=XCOPY=].  The client is very basis and has no [=DLL's=] to register or dependency on registry keys.
to:
# Consider locally installing the client on the workstations.  There is an installer to assist with this process ([@client-local-install.exe@]), or alternatively you can script the install with something like [@XCOPY@].  The client is very basis and has no [=DLL's=] to register or dependency on registry keys.
Added lines 1-36:
(:title Wide Area Networks (WAN) Considerations :)

Q: 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?

A: 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

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: ~200 bytes (0.2kb) per minute

!! Special notes on client deployment

The client's zero-install deployment method is the easiest method of deploying the client.  The downside of this method in a WAN type environment is that client binaries and associated files are pulled in off the server on start.  This is not usually a problem on a fast local network, but may pose problems on 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.  There is an installer to assist with this process (client-local-install.exe), or alternatively you can script the install with something like [=XCOPY=].  The client is very basis and has no [=DLL's=] to register or dependency on registry keys.

# 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.

# Large organizations with expert system administrators may be able to improved on option 2 by utilizing Microsoft DFS or equivalent technologies on other platforms.  This will provide "local transparency" when accessing the client share.  You can read more about DFS [[http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) | here]].

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]]
----

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on February 24, 2015, at 11:10 PM
Printable View   |   Article History   |   Edit Article