Print Jobs Not Being Tracked by PaperCut

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 to tell if the print job is being tracked… Log on to the PaperCut server, click Logs, then Job Log, and verify that the job print job is being tracked by PaperCut. If you do see the job here, then navigate to Printers then the Jobs Pending Release tab and look for the job there. If you don’t see the job recorded on either of those pages… then PaperCut doesn’t know about the print job. This troubleshooting article was written especially for you. 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 integral to print tracking, and is installed whenever setting up these PaperCut features: PaperCut NG/MF Server Application PaperCut NG/MF Secondary Server PaperCut NG/MF Site Server PaperCut NG/MF Direct Print Monitor (for end-user’s workstations) If you have a print server sharing the queues, make sure the user is printing to one of those queues, and not accidentally bypassing PaperCut by printing directly to the printer. If you don’t have a print server, 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. Is the Print Provider version up to date? This section is relevant if you are not printing to a queue hosted on the PaperCut server but instead are printing to a queue hosted on a Secondary Server, Site Server, or Direct Print Monitor. 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, Site Server, or Direct Print Monitor 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. Is the Print Provider configured with the right server details? This section is relevant if you are not printing to a queue hosted on the PaperCut server but instead are printing to a queue hosted on a Secondary Server, Site Server, or Direct Print Monitor. Confirm that the connection details for the PaperCut server are correct in the print-provider.conf file. To do so, navigate to [app-path]\providers\print\[platform]\print-provider.conf on a 64-bit Windows PaperCut MF server this path would be C:\Program Files\PaperCut MF\providers\print\win\print-provider.conf. Open this file using a plain text editor like Notepad and then look for the section… # Define the name or IP address of the application server. # On secondary server installs, this value should be changed to point to the # primary application server. # Default: 127.0.0.1 # Examples: mainserver.localdomain.com, win2003, 1.2.3.4 # # IMPORTANT: Please restart the server or the "Print Provider Service" after # changing this value. # ApplicationServer=PaperCutSRV01.yourdomain.org Confirm that the line starting with ApplicationServer= has the correct hostname or IP address for your PaperCut server. If it does not, then update this line with the correct details and then restart the server or Print Provider service. Is the printer listed in PaperCut? PaperCut monitors ‘Print queues’ rather than the actual physical printers. 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. macOS - Is PaperCut configured to track the printer? This section applies specifically to macOS Print Servers, or workstations running the Direct Print Monitor. 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. Is the job being canceled due to On Demand User Creation settings? 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! Is the job being tracked as the wrong 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. Make sure Branch Office Direct Printing is off 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 these ‘Direct’ macOS queues installed with Print Deploy? There is one very specific scenario when direct printing queues are cloned from a macOS workstation and then pushed out via print deploy. PaperCut is unable to detect whether this is a ‘server’ queue or a ‘direct’ queue, and assumes the queue is server-hosted to prevent the job from being tracked twice. Try this to change the print queue type: In the Admin web interface, click Enable Printing. In the Print queues list, click the three dots icon next to the print queue you want to update. In Type, select Print direct. Close the pop-up. Test printing from the macOS workstation. If the printer is deployed through Group Policy… 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. 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. 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 Print Deploy feature, designed to help you get the right printer to the right person in the right location, automatically.