PaperCut provides accurate tracking of printer usage by analyzing the printer spool file on the server. Before the job is sent to the printer, PaperCut determines the job attributes including the page count, color/grayscale, duplex, paper-size, etc. This up-front analysis allows PaperCut:
To calculate the job cost and determine up-front whether the user has enough credit to print.
To display the job details (e.g. the cost and page count) to the user in the print confirmation screens and release stations.
To apply filters and policy rules to print jobs (e.g. to disallow non-duplex jobs, or to enforce print policy using the advanced printer scripting).
After the job is queued for printing, PaperCut logs this print job information and charges the usage to the user.
If the job is sent to the printer but it does not print completely (e.g. if the user cancels the job at the printer), then print job hardware checks allow PaperCut to determine the actual number of pages printed. These checks are performed at the hardware-level by communicating with the printer via SNMP (Simple Network Management Protocol).
The combination of up-front spool file analysis and post-job hardware verification of the jobs provides the best of both worlds:
Accurate up-front page count and cost calculations; and
Verification of the printed pages after the job is completed.
The printer may report a difference to the PaperCut server's spool file analysis for a variety of reasons:
The user cancels the job at the printer's panel - e.g. LCD screen or cancel button.
The printer goes into an error state (e.g. out of toner) after the job has partially printed. The administrator may then cancel the job at the printer.
The print job may have become corrupted, causing the printer to print 100's of pages of junk (e.g. PostScript code) instead of the user's document!
Configuration "strangeness" such as the devices double-counting large pages or counting the blank page at the end of a duplex job. Most of these corner-cases have been worked around, however, like all things in Computing, some are bound to show up again!
PaperCut's hardware checks use the SNMP protocol to query the page counters of the printer. This is a network protocol supported by most network printers. To support hardware checks the following is required:
A network printer that supports the SNMP protocol.
SNMP enabled in the printer (also ensure the "public" SNMP community is enabled).
The network/firewall allows SNMP UDP packets from the print server to the printers. SNMP uses UDP port 161.
Some additional configuration of the printer queues may be required. See installation instructions in the section called “Configuring hardware checks”.
Only PaperCut should send jobs to the printer. If a job from another print server is sent it's possible the resulting statistics will be unreliable
The Printer SNMP standard allows querying of printer status and page count information over SNMP. PaperCut makes use of this information to verify the number of pages printed for each print job. This works as follows:
Before the print job is sent to the printer PaperCut confirms the printer is idle (i.e. not printing).
A snapshot of the page counters is retrieved using SNMP.
PaperCut waits for the job to complete by querying the printer status and page counts. If the printer is in error (e.g. out of paper), then PaperCut will continue to wait until the printer error is resolved and the job completes printing.
Once the job is completed and the printer is idle, another snapshot of the page counts is taken.
The total pages printed is calculated using the differences between the initial and the post-job snapshot.
Printer hardware checks are not enabled by default in installations of PaperCut. Enabling the checks requires some configuration within PaperCut and also some additional configuration of the operating system's printer queues. Hardware checks may be enabled/disabled at the individual printer queue level, or alternatively the settings can be applied to multiple printers using the the section called “Copying Printer Settings”.
To enable the print job hardware checks:
Navigate to the Printers tab.
Select the printer to configure.
Under the Advanced Configuration setting, enable the Enable print job hardware check option.
Press or to save the changes.
Important
On Windows print servers, you must also configure the printer to use a PaperCut TCP/IP Port. For instructions see the section called “Windows printer queue configuration”.
Tip
On Windows print servers, this setting can take up to 2 minutes to take effect. This can be sped up by restarting the PaperCut Print Provider service.
When a difference in page counts is reported by the printer, the administrator can choose how this is applied to the print jobs. This option is configured using the When a difference in page counts is detected: settings as follows:
'Show differences in the log status. Do not adjust'
The page count differences are recorded against the print job, but no adjustments are made to the page counts or job costs. This is the default option when hardware checks are enabled.
This mode can be useful when you want to use the hardware check information to validate refund request by users. In this case the administrator can verify that a user's job did not complete printing and then refund the job.
The hardware check information is displayed in the print log status and also in the refund screens.
'Apply differences and adjust the print cost automatically'
In this mode, the hardware check information is also recorded on the print jobs as described above. However, any differences in page count and costs will be automatically applied to the job.
For example, if a user printed a 5 page document costing $0.50, and they cancelled the job after only 3 pages were printed, the job cost would be reduced to $0.30 and the user would be refunded $0.20.
In rare situations, it is possible for the hardware check to report an increased number of pages. For example, this might happen when a print job is corrupted and prints out 100's of pages of "junk" instead of what the user printed. In this case the hardware check will report an increased number of pages resulting in an increased cost. By default PaperCut will not apply the adjustments to the job if the cost would increase.
If you would prefer to apply the differences even if the cost is increased, then select the Always apply cost adjustments option.
Tip
To enable the hardware page counts quickly on multiple printers, use the Copy settings to other printers action available on the left of screen.
To perform printer hardware checks, the Windows printer queues need to be configured to use the PaperCut TCP/IP Port type. This port works just like the Standard TCP/IP Port that ships with Windows. The PaperCut TCP/IP Port allows PaperCut MF to perform the page count checks before and after printing the job.
To configure an existing printer queue to use a PaperCut TCP/IP Port
Open the Printers list
Right-click on the printer and select Printer Properties or Properties
Select the Ports tab.
Press the Add Port button.
Select the PaperCut TCP/IP Port option. (Note: if this port does not appear in the list of available port types, then please see the section called “Why is the PaperCut TCP/IP Port not available to be chosen in port selection on Windows?”.)
Press the New Port... button.
Enter the printer IP address and port name.
Press to save the new port.
Press the Close button on each dialog window.
This printer will now be configured to use the new port. The previous port may now be deleted if no longer in use by other printers.
To create a new printer queue to use a PaperCut TCP/IP Port:
Open the Printers list
Click the Add a Printer button.
Choose to add a Local printer.
When prompted for the printer port, select Create a new port.
Select the PaperCut TCP/IP Port option, and click .
Enter the printer IP address and port name.
Press to save the new port.
Complete the Add Printer wizard as normal choosing the drivers, etc.
When using Novell, Linux or Mac there is no additional configuration of the operating system required for hardware checks to be enabled. This function is controlled via the PaperCut administration console and will come into affect automatically shortly after the hardware checks are enabled. On Linux or Mac, the hardware checking is supported for the CUPS backends of socket, ipp and lpd.
By default, the hardware checks use the SNMP community string of "public". For a basic level of security, one can change the SNMP community string that is used. This must also be set in the configuration of the printer.
Open the file
[app_dir]/providers/print/[platform]/print-provider.confin a text editor such as Notepad.Locate the line
SNMPCommunity=and enter the new community string on the right-hand-side of the equals line. For example:SNMPCommunity=secretcommunity
Hardware check results are recorded in PaperCut on the print log records. When a hardware check is recorded the Checked status appears in the Status column of the print logs as shown below.
To see the basic details of the hardware check, hover your mouse over the Checked status.
When the hardware check detects a difference, click the Checked status link to see more detailed information.
To manually apply hardware checks to a print job (if this is not configured to apply automatically):
Click on the Checked status.
Review the hardware check information.
Press the button. This will apply the page counts and any cost differences to the print log.
Hardware-level page count checks are not enabled by default. Sites should carefully consider these limitations and known issues before implementing:
The use of the PaperCut TCP/IP Ports in a Microsoft Clustered Windows Printing Environment should be considered experimental (see Chapter 28, Clustering and High Availability, for more information on Clustering in PaperCut). Clustering is a complex technology and further work is being undertaken to support the Hardware Page Count Checks in a clustered environment. We don't recommend its use in a production environment at this time.
Hardware-level checks will slow down printing a little (a few seconds between each job). The system needs to take a count snapshot before and after a job. The start/end of a job is detected by the printer entering an idle state and stabilization on some devices can take a few seconds (printing => idle). This process adds a small delay between each job.
Copier functions that delay printing such as printing to a "Mailbox" will prevent PaperCut from detecting the print job as it is expected that the print job is printed imediately.
Not all devices support SNMP and even some devices that do, do not support the ability to check page counts at the hardware level. Most major MPF/MFD devices support SNMP, however smaller printer brands may not. We suggest taking some time to test this option across your device type(s) once enabled.
On Windows, a different Printer Port needs to be installed/configured to support this level of device integration. Care has been taken to emulate the behavior of the Standard TCP/IP Port, however some drivers may complain if a non-default port is selected. Although this is rare, it may cause issues with some drivers. Always test the printer after changing the printer port. The development team is looking at ways to remove the dependency on a custom port, however at the current time this method has proven to be the most reliable.
The use of non-PaperCut hold/release functionality on printers and copiers may cause inaccurate hardware validation as it will appear that the job never prints, or at least in a timely fashion. It is recommended to use PaperCut based release stations where required: (see Chapter 13, Hold/Release Queues & Print Release Stations
If you have many printers it's very time consuming to use the Windows GUI to change the ports! Sorry about this, however we've not found a reliable way to script this process. Our recommended approach is to first test on a representative sample of your devices for a few days, then role the port change out across your fleet. We have found that some good music on the iPod and copious amounts of coffee will help ease the frustration :-)
Verify that the printer supports SNMP and that SNMP v1 or v2 is enabled in the printer's admin interface.
Ensure that your networks and firewalls allow SNMP traffic (i.e. UDP port 161) between your print server and printers.
If using a Windows print server, check that the printer is configured to use the PaperCut TCP/IP Port. See the section called “Windows printer queue configuration”
Verify that hardware checks are enabled in PaperCut. See the section called “Configuring hardware checks”.
You can test that PaperCut can query SNMP data from the printer by running the following in a command prompt or terminal/shell:
Windows:
[app-path]\providers\print\[platform]\pc-print-monitor.exe -p -h [printer-ip]
Mac/Linux/Novell:
[app-path]/providers/print/[platform]/pc-print-monitor -p -h [printer-ip]
If SNMP data can be retrieved, some basic status information will be printed. If not, an error is displayed.
If you are still unable to diagnose the problem, then please send the following log files in a support request:
Windows:
[app-path]\providers\print\[platform]\print-monitor.log* [app-path]\providers\print\[platform]\print-provider.log*
Mac/Linux/Novell:
[app-path]/providers/print/[platform]/print-provider.log*
An intermittent networking problem between the print server and printer may have stopped the SNMP page counts from being retrieved. E.g. the network was briefly interrupted while PaperCut was waiting for the print job to finish printing.
If the job is deleted from the print queue while in progress PaperCut will cancel any hardware checks and the Checked status will not appear on the print log. To avoid this, it is recommended to fix any problems (e.g. out of paper, etc) at the printer and then allow the document to finish printing. This will allow PaperCut to retrieve the page counts from the printer after the job completes. Only delete the job from the queue if it stays stuck even after the printer error has been resolved.
A possible reason why the PaperCut TCP/IP Port is not available may be because the port was unable to be installed due to a Security Policy disabling the installation of unsigned drivers. A solution for this is to change the Security Policy for the unsigned driver installation behavior to either allow unsigned driver installations or to warn but allow their installation.