There are various scenarios where the users want to print their print jobs but the PaperCut Application Server is unable to receive the information about the printing, including when:
The Application Server's machine is being rebooted,
The network link is down between a Secondary Print Server on a remote machine and the Application Server,
The administrator has decided to shutdown the Application Server for maintenance.
When this occurs PaperCut must decide on how to handle the print job without communicating with the Application Server. The administrator can configure PaperCut to handle new jobs in 3 ways:
Allow new print jobs to print but do not log (default),
Allow new print jobs to print and log after reconnection,
Do not allow new print jobs to print but hold and wait for reconnection.
Each of these options offer different compromises, and the best option will depend on the needs and priorities of a particular installation. For example, if it's important to never interrupt printing then options 1 or 2 can be selected. If it's important to strictly enforce quotas (i.e. allow the job to be cancelled if they do not have enough quota) and it is acceptable to delay printing until the connection is reestablished then option 3 can be chosen. These options are discussed in further detail below.
These configuration options are controlled under the + → .
This is the default mode and will allow jobs to print when the connection to the server is down (a "fail open" mode). The jobs printed during this period will not be logged in the Application Server. This mode can be used when:
It is important to not interrupt printing when outages occur,
The setup needs to be simple and easy to understand,
It is not important to log jobs printed during failures,
Strict quota enforcement is not required, Users will not be charged for printing that occurred during the outage.
This mode allows jobs to print when the connection to the primary server is down, but when the connection is re-established these jobs are re-sent to the Application Server and logged (a "fail open" mode with re-send/offline mode). This mode can be used when:
It is important to not interrupt printing when outages occur,
It is important to log/charge every job printed during failures,
Strict quota enforcement is less important. Users may end up using more credit than they have available.
In this failure mode the administrator can configure how these resent jobs are recorded in the job log:
Leave the job information unchanged (i.e. log the job against the user that printed it),
Change the recorded user to another nominated user,
Change the charging of the print job to a nominated shared account.
The default reconnection option is 1, where we log and charge the same way we would if the recording was done live. The administrator may consider this unfair to charge the user during this failure time (as there were no warning popups or ways of telling that the user's quota was reaching its limit). It may be more reasonable to use the reconnection options of 2 or 3. With option 2, the administrator can choose a new user such as "AppServerDown" to record the job as and in this way completely divorce the user from jobs printed during the failure.
If the administrator would still like to track who did the printing but just thinks it is unfair to charge their personal account, then reconnection option 3 can be chosen, and a new shared account such as "AppServerDown", or an account corresponding to the department owning the printer can be charged. Jobs are still recorded under the user's name.
When the connection to the Application Server opens up again, the print jobs will show up in the Application Server's job log within a few minutes. They will show up with a special status and icon in the job log (see figure below).
In this mode all jobs will be held in the queue while the connection to the server is down (a "fail closed" mode). Once the connection to the server is reestablished the jobs will be sent to the server and printing will be processed as normal. This mode can be used when:
Strict quota enforcement is required,
Secure Print Release or Find-me printing is used and jobs must not be printed until released by a user.
When using virtual queues and Find-me printing (see Chapter 14, Find Me Printing and Printer Load Balancing), it is recommended to hold the all jobs and wait for reconnection when the server connection is down. By default, this setting is enforced by PaperCut to ensure the correct operation of the virtual queue.
If jobs are released from the virtual queue when the server connection is down, the jobs would be released to the configured printer (i.e. the configured printer port). If the queue is configured with a NULL port, the jobs are deleted. If configured for a non-existent printer (e.g. LPT1) then the jobs go into an error state. If configured for a real printer, the jobs will be sent to the printer (contrary to the secure release / Find-me printing that the user expects). It is for these reasons that the failure mode on virtual queues is set to hold all jobs.
Some organizations prefer to have the virtual queue pointing to a real/physical printer so that if a failure occurs the jobs will be printed. This is usually only acceptable if the organization is happy that users jobs be printed on a single queue (bypassing any secure print release function). To configure this, enable the Override virtual queue failure mode option and select one of the alternative modes. This option is only visible on virtual queues.