Help! My users are able to print successfully, but their print jobs jobs aren’t getting tracked in PaperCut at all - what’s going wrong?
There are various scenarios that could lead to PaperCut being unable to monitor users print jobs. Below are some troubleshooting tips to ensure that you are able to capture print jobs correctly.
Note that this article covers the scenario where you can print successfully (the job comes flying out of the printer), but when you look at the user logs, or print logs in PaperCut - you can’t see any record of that job.
Related articles:
- Troubleshooting missing or disappearing print jobs
- Troubleshooting jobs that have the wrong username / owner name
How does PaperCut track print jobs?
For PaperCut to track a print, the “PaperCut Print Provider” service must be running on the computer or server doing the printer. This service is added whenever you install the PaperCut NG/MF server application, PaperCut NG/MF Secondary server, PaperCut NG/MF Site Server, or PaperCut NG/MF Direct Print Monitor (for end-user’s workstations).
If printing is happening through a shared print queue on a Print Server, one of those must be installed for the job to be tracked.
If printing is happening directly from a user’s workstation to a local printer (connected by USB for example) then the Direct Print Monitor must be installed on that user’s workstation or the job will bypass PaperCut and not be tracked.
Is the PaperCut Print Provider service started?
The Print Provider is a critical service used to connect to the printing system on the server (the “Print Spooler” in Windows or “CUPS” in macOS/Linux). This service pauses and analyzes print jobs. If it’s not running, you’ll still be able to log into the web interface of your PaperCut server, but new jobs will not appear in the logs.
First check to make sure the Print Provider service is running on the affected server (or workstation in the case of the Direct Print Monitor). Below are the steps you would follow on a Windows machine running the Print Provider. See our article on Stopping and Starting PaperCut Services to learn how to do this on other operating systems.
There are two common reasons why this service is not running. One is that the Windows Print Spooler Service was stopped and started for troubleshooting, this also stops the PaperCut Print Provider Service which is dependent on the Windows Print Spooler. The other reason is that the PaperCut Print Provider Service has been configured to run as a service account, but this account has been disabled or the password expired. If this is the case, you will see a telling error message when you try to start the service.
Steps:
- Log onto the affected Secondary Server, Site Server, or client workstation running the Direct Print Monitor.
- Click on the Start button, type services.msc, then hit enter.
- Find the PaperCut Print Provider service and ensure this is started by right-clicking on the service and choose Start.
- Ensure the service starts correctly and investigate any Windows errors as needed.
If the print jobs not being tracked are going through a secondary print server then make sure the Print Provider service on the secondary is running as well as being configured correctly. If it’s already listed as running, restart the Print Provider just as a precautionary measure. Just in case!
We also have great information on how to setup a secondary server in the Secondary Server section of the Help Center, in case you’re printing through an additional Print Server, that doesn’t yet have the PaperCut secondary server (Print Provider) installed.
Is this print queue tracked by PaperCut?
PaperCut monitors the ‘Print queue’ rather than the actual physical printer. Within the PaperCut Admin Interface, under the Printers tab, you’ll find a list of all the Print queues being monitored. You might have more than one print queue configured to point to the same physical printer - which is why you may see the same printer listed under e.g. printserver1\LibraryPrinter and also printserver2\LibraryPrinter and even testserver1\LibraryPrinter.
PaperCut can only track these print queues by having the Print Provider (or ‘Secondary server’) running on the same server or machine that is hosting the print queue. You’ll have already seen this if you’ve checked that the service is running on the server, in the step above.
Local print queues may include networked printers, such as those with their own network cards using a local TCP/IP port or physically connected printers attached via LPT or USB. Please double check the print queue on the print server is installed as a local print queue. For more information concerning adding print queues see here.
Now you have checked the print queues are setup correctly you need to make sure your users are printing to the correct print queue. If you have printers installed as local print queues on one or more print servers then the print queue should be shared and your users print to the share.
Users should not be printing directly to the IP address of the printer - everything must pass through a print queue that PaperCut is monitoring.
It is possible to monitor workstation attached printers by installing the PaperCut secondary server on the workstation, but shared network printers are best hosted on a print server and shared to client workstations. Check out the Secondary Server Help Center section for more information on secondary servers.
A great test to check you are printing to the server based print queue is to access the server side print queue and pause printing, on Windows this is done from the Printer menu on a print queue.
Then send a print job from the client to the printer, if everything is setup correctly then the print job should go into the print queue on the server and enter a paused state as per the screen shot below.
If the print job does not appear on the server based queue then you are not printing to the correct print queue. Normally this means that either the printer is hosted on a different server, or sometimes the print queue has been set up as a ‘direct queue’ - where you print directly from the workstation to the printer, bypassing the print server completely. If that has been done unintentionally, then it’s worth looking at our Prevent users bypassing PaperCut article.
Is PaperCut configured to ignore the printer?
On Windows (and macOS in more recent versions), print queues are automatically picked up and tracked by PaperCut. If you’re using an older version of PaperCut you should check that the print queue is ‘enabled’ in PaperCut - as per the Add/Remove Printer on macOS section of the Help Center.
If the printer is showing up under the Printers tab in the admin console, it’s a good sign that this is working - however it’s worth re-enabling the printer as per the link above, in case someone has disabled it at a later date.
Does the print job owner username exist in PaperCut?
If a user that PaperCut does not recognise prints to a print queue monitored by PaperCut, the “On Demand User Creation” rules kick in. The default On Demand User Creation option is to create the user on demand - which means an unrecognized user would get automatically created in PaperCut under the ‘Users’ tab.
However, if someone has changed the on-demand user creation settings to do not create the user and allow usage or do not create the user and deny usage then the user will not be created in PaperCut under the ‘Users’ tab, and PaperCut will not have a record of that job. In those cases, the user would not be created, but the job would print successfully (in the first case) or not print successfully (in the second case).
Head over to Options → User/Group Sync → On Demand User Creation to check this setting. If necessary change the setting to the less strict ‘Create the user on demand’ setting - then apply that and re-test. You’ll then be able to head into the Logs → Job Log page to see that test job in the list. This is a good opportunity to see if the job owner is listed as the job owner that you’re expecting too - if there’s a mismatch there it’s worth having a look at our article on Troubleshooting jobs that have the wrong owner name.
Otherwise if you don’t want to alter that setting, make sure that the user you’re expecting to be the owner of the print job, is listed under the Users tab in PaperCut. It’s also worth looking at the Logs → Application Log, since messages around on-demand user creation, or the cancelling of Print jobs will appear there - which can give clues as to what might be going wrong!
Are the Print Provider/Secondary Server versions incompatible with the App Server?
If you find print jobs from a secondary server are not being tracked, then it is important to make sure the version of PaperCut on the secondary server is equal or below the version of PaperCut running on the primary server.
- To check your Application Server version, head into the PaperCut Admin console, then into About → Version info which will list the full version of the App Server - e.g. 19.2.2.
- To check your Print Provider (Secondary Server) version, head into the file system at [installation path]\providers\server-version.txt (e.g. C:\Program Files\PaperCut MF\providers\server-version.txt. You’ll find the server version (e.g. 19.2.2) at the top of that file. It’s fine if the secondary server is on an older version of the software, but it will cause problems if you have e.g. version 19.2.2 secondary server version, talking to a 17.1.1 Application Server.
Are you printing as the correct user?
By looking for the job in the master job log in the Admin Console (Logs → Job Log) you will see which user and printer was recorded. You may need to set the filter for the date and time of print if it is a high volume print environment.
- Occasionally a print job is recorded under the wrong user in a terminal server setup because of a missing configuration step. Following the instructions here will correct the problem.
- Take a look through the Troubleshooting jobs with the wrong owner name article too, if you’re seeing the wrong username being recorded.
Are you using Branch Office Direct Printing?
When Branch Office Direct Printing (BODP) is enabled on a Windows Print queue, it allows the workstation to send a print job to the physical printer even when the print server is offline. This could potentially allow a print job to go untracked by PaperCut.
The solution is to either disable BODP on your Windows Print Server or to install the PaperCut Direct Print Monitor on your workstation to ensure the print jobs are tracked. To disable BODP, right click on your printer in the Windows Print Management Console and choose “Disable Branch Office Direct Printing”.
Are you using Group Policy to deploy the printer connection?
Some customers have experienced issues when using GPP to deploy the printer connection. What happens is that the printer is actually deployed as a direct print queue - enabling the workstation to print directly to the Print IP address, rather than through the Server print queue. There’s a good conversation on Technet that illustrates this bypassing the print server behavior.
In short, the solution was to instead use the Shared Printer Item in GPP instead - which distributes the shared print queue on the server as intended. It’s definitely worth testing using a workstation, and pausing the print queue on the server, in order to double check that you’re seeing the test print job going through the server print queue.
Alternatively, if you’re looking for an easier way to deploy your print queues across a range of platforms, it’s worth taking a look at our relatively new Print Deploy product - “a print queue deployment tool that gets the right printer drivers and print queues to the right person in the right location, automatically.”