<
You are here: Configuration > Advanced printer management > Behavior on server connection failures

Behavior on server connection failures

There are various scenarios where the users want to print their print jobs but the PaperCut Application ServerAn Application Server is the primary server program responsible for providing the PaperCut user interface, storing data, and providing services to users. PaperCut uses the Application Server to manage user and account information, manage printers, calculate print costs, provide a web browser interface to administrators and end users, and much more. is unable to receive the information about the printing, including when:

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:

  1. Allow new print jobs to print but do not log (default),

  2. Allow new print jobs to print and log after reconnection,

  3. 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 depends on the needs and priorities of a particular installation. For example, if it's important to never interrupt printing then select options 1 or 2. If it's important to strictly enforce quotas (i.e. allow the job to be canceled if they do not have enough quota) and it is acceptable to delay printing until the connection is reestablished then choose option 3. These options are discussed in detail below.

These configuration options are controlled under the Printers [select printer] > Failure Mode .

Failure mode settings

Mode 1: Allow new jobs to print but do not log

This is the default mode and allows jobs to print when the connection to the server is down (a "fail open" mode). The jobs printed during this period are not logged in the Application Server. Use this mode 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.

Mode 2: Allow new jobs to print and log after reconnection

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). Use this mode 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 can use more credit than they have available.

In this failure modeFailure mode allows you to control the behaviour under error conditions, such as, connections problems between the Application Server and secondary server. the administrator can configure how these resent jobs are recorded in the job logThe job log retains a history of all print jobs including the following details: the user who printed (ie. their network user ID), the time of the print event, the number of pages, document attributes such as color, duplex, grayscale, paper size, document area, paper length, where the print job originated from (the workstation name or IP address), and the document name and type (for example, a Word document’s file name).:

  1. Leave the job information unchanged (i.e. log the job against the user that printed it),

  2. Change the recorded user to another nominated user,

  3. Change the charging of the print job to a nominated shared accountA shared account is an account that is shared by multiple users. For example, in business, shared accounts can be used to track printing costs by business unit, project, or client. Organizations like legal firms, engineering firms, or accounting offices often have long lists of accounts, projects, clients, or matters. In a school or university, shared accounts can be used to track printing by departments, classes, or subjects..

The default reconnection option is 1, where logging and charging is done in the same way as if the recording was done live. The administrator might 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 might 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 wants to track who did the printing but thinks it is unfair to charge their personal account, then choose reconnection option 3, 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 show up in the Application Server's job log within a few minutes. They show up with a special status and icon in the job log (see figure below).

Mode 3: Do not allow new print jobs to print but hold and wait for reconnection

In this mode all jobs are 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 are sent to the server and printing is processed as normal. Use this mode 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.

Failure mode settings on virtual queues

When using virtual queues and Find-me printing (see 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 are 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 are printed. This is usually only acceptable if the organization is happy that users jobs be printed on a single queue (bypassing any secure print releaseSecure print release places print jobs in a holding state until the user authenticates and releases the job at the printer. This means sensitive print jobs will not sit uncollected on the printer. function). To configure this, select the Override virtual queue failure mode check box; then select one of the alternative modes. This option is visible only on virtual queues.