Troubleshooting Missing or Disappearing Print Jobs with PaperCut NG and MF

“Help! Print jobs from our workstations don’t actually print. What should we check?” This is a bit of a mammoth article, but hopefully it gets you immediate help in figuring out ‘where have my print jobs gone?’ when printing with PaperCut NG or MF. This will take you through in-depth troubleshooting for scenarios where you or your users are pressing print, but nothing is coming out of the printer, and there are no jobs showing up for release when you log into a printer or release station. Related topics: Print Jobs aren’t being tracked by PaperCut Troubleshooting print jobs with Mobility Print Troubleshooting Find-Me Printing and Virtual Queues Troubleshooting jobs attributed to the wrong user or wrong owner name Where does the job go missing? This section is super important, and will set you up for ‘choosing your own adventure’ in the article, depending on what the behavior of your tests show! The first step is to narrow down where in the printing process the jobs are ‘disappearing’. To do this, try pausing the print queue on the server and attempt to recreate the issue: Log into the Windows print server. Open Print Management by pressing Windows key + R , then type printmanagement.msc and hit the enter key. Right-click on the printer and click Open Printer Queue. Click on Printer in the menu bar and check Pause Printing’=. Submit a print job that demonstrates the problem and ask these questions. Does the job at least show up? Does the Owner match the name of the PaperCut user? Is the status paused? Then resume the job by unchecking Pause Printing and then ask: Does the job disappear immediately, does it stay held in the queue, or was it never there in the first place? Which behavior describes your issue the best? If the job never reaches the print server or printer… If the job reaches the print server but then disappears from the queue… If the job reaches the print server and is held in the queue, but the user sees nothing to release… If the job reaches the print server, the user can release the job, but nothing prints out… The job never reaches the print server or printer… Is the print job somehow bypassing PaperCut? If the print job isn’t reaching the server at all, then check to see how the printer connection is set up. It could be the case that the workstation is printing straight to a Bonjour-enabled printer, or directly to the IP address of the printer. If this is the case, consider deleting this print queue and connecting to the print server instead. You can ensure this by having the user connect to a shared print queue on the print server or by setting up PaperCut Mobility Print to share printers. If printing through the server is not desired, then one option is to install the PaperCut Direct Print Monitor on the user’s workstation so that these jobs can be tracked. At a minimum we need to make certain that the user is printing to a queue that is monitored by PaperCut, and that print jobs show up in the PaperCut Job Log, otherwise there is not much for PaperCut to track. Is this a Mac client and are they seeing the notorious ‘hold for authentication’ error? If you’re seeing a ‘hold for authentication’ error in the print queue on the local macOS client, then take a look through the Troubleshooting ‘Hold for Authentication’ errors article. Is the print job coming from a Windows workstation that’s not joined to the domain? We’ve seen cases where the print queue was added on a Windows WORKGROUP computer, and then later the user’s password expired or the account was disabled. When this happens, the print job will never show up in the Windows print queue and will get cancelled without warning. This situation would happen with or without PaperCut. Try deleting and re-add the printer with up-to-date credentials to see if that works. Better yet, use Mobility Print to share print queues with WORKGROUP computers. The job reaches the print server but then disappears from the queue… If the job shows up in the print queue on the server, but doesn’t continue onto the printer or disappears before the user has the opportunity to release the job, then these are the things we check for… Is the Print Provider service running? Normally if this service is stopped, then print jobs will be allowed to pass through your print system (successfully printing) but not be tracked by PaperCut. However, when Find-Me Printing has been set up (usually with a nul port ) and the Print Provider is not running, then the job ‘prints’ straight to the nul port, and effectively disappears! This might happen if someone has stopped and started the Print Spooler, but has then forgotten to restart the Print Provider service. Double check this by heading into the Services console in Windows, and ensure the PaperCut Print Provider Service is started . Is PaperCut configured in a way that would cancel the jobs? It’s totally possible that PaperCut could be configured (or misconfigured) in such a way that print jobs are getting canceled. If this is the case, you can also see evidence of this in the Admin interface, under Logs → Application Log, where a message will state that the job was canceled due to policy. Is the user account Restricted and also out of balance? If the user account has a red X next to their name, then it means they are not allowed to print because they are out of credit. To fix this, set the user account to “unrestricted” or make sure the user has balance (at least enough for the cost of the test job). If this is the case, you can also see evidence of this in the Application Log, under Logs → Application Log, in the Admin interface. Is the printer in PaperCut configured to deny any jobs based on Filters & Restrictions? Check the Filters & Restrictions tab, under Printers → [select a printer] → Filters and restrictions. Worth keeping an eye out, since these conditions still apply when troubleshooting BYOD solutions (Mobility Print, Google Cloud Print, Web Print, and Email to Print) but because these users might not be running the client, they won’t see any pop up telling them why their job was canceled. You should also be able to see evidence of this in the job log, under Logs → Job Log. Is there a print script enabled for this printer in PaperCut? Check to see if there is a print script enabled on the print queue in question. Try temporarily disabling the script to see if this is causing the issue. In the PaperCut admin interface, head over to Printers → [select printer] → Scripting, and then uncheck the Enable Print Script checkbox. Save the settings, and try again. Is On-Demand User Creation set to ‘Deny Usage’? In a default PaperCut installation On-demand user creation is enabled so that print jobs from unknown users will be tracked. However, if this setting was changed to “do not create the user and deny usage” then print jobs from unknown users will be deleted by PaperCut. Confirm how this setting is configured by logging into the Admin interface and navigate to Options → User/Group Sync → On Demand User Creation. Depending on your organization’s needs, you may need to reevaluate this setting or make sure the user account gets imported or created in PaperCut. You can also see evidence of this in the Application Log, under Logs → Application Log, in the Admin interface. Do you see an error message in the Application log with “A print job was attempted to be unpaused while being held and was deleted by the system”? This means the job has been ‘resumed’ outside of PaperCut’s control. This is not a common issue, but if you come across this message then take a look at this article on the ‘attempted to be unpaused’ error. The job reaches the print server and is held in the queue, but the user sees nothing to release… Is the PaperCut Application Server waiting for the user to respond to a client Popup? Certain PaperCut features like Account Selection and Unauthenticated Printing require users to run the PaperCut Client on their workstations to respond to pop-up messages. This may be to select an account to bill to or enter their credentials when prompted. A handy way to see if this is the issue is to wait 10 minutes after printing the test job (I kid you not), and then head into the PaperCut admin interface, and look at Logs → Application Log. You’ll see a warning something along the lines of “Canceling print job x printed by user because they did not respond to the client popup within 10 minutes”: If you see this error, then try these steps: Is the Account Selection popup enabled for the user, but they haven’t seen the pop-up yet? To test, try changing the user settings to “automatically charge to personal account” (under Users → [select user] → Account Selection, in the PaperCut admin interface). Is the user or printer configured for Unauthenticated Printing? If so, then the workstation must be running the PaperCut client, and they must sign in when prompted. To confirm if that’s the case, you’ll need to check both the printer (Printers → [select printer] → Summary → Advanced Configuration → Unauthenticated printer (enable popup authentication)), and the user (Users → [select user] → Details → Advanced Options → Unauthenticated user (enable popup authentication)). Temporarily uncheck those options, save the setting, and re-test if you’re unsure. Is Print Scripting enabled on this printer, and is PaperCut waiting for the user to respond to a pop-up? To test, try disabling the Print Script (under Printers → [select printer] → Scripting → uncheck Enable Print Script). If the job then works when you change / disable these settings, then that’s great!! Next step is to make sure the PaperCut Client is installed and working. To test, send a client notification popup and make sure this is seen by the user. Hop over to the Client popup and Notification Issues Troubleshooting page if you’re after help with that. If users are sending jobs to a Find-Me printer… If users are sending jobs to a Find-Me Printer, then you should check to make sure… Find-Me Printing is enabled on the queue that users are sending jobs to The device in question is configured to show jobs from the Find-Me queue First, log into PaperCut and open the Printers list and select the Find-Me print queue. Examine the settings to ensure that all of the appropriate “destination queues” have been selected. Second, check the Devices section of PaperCut to ensure the MFD/Copier has “Enable find me printing support” enabled, and that the correct “destination queue” is selected that will output to this printer. If the wrong queue is selected, the print job may be going to the wrong printer, so it’s important to confirm this setting. Does the PaperCut username match the user that submitted the job? If the print job arrived at the print server, but doesn’t appear when the user signs into the Release Station or MFD then there could be a couple things going wrong. We see this happen occasionally when the owner of the print job doesn’t match the user doing the releasing. Look for the held print job in the PaperCut Admin interface under Printers → Jobs Pending Release. Does the username match what you would expect? If “Tim” printed the document, but PaperCut thinks the job was printed by “SYSTEM” then see our Troubleshooting jobs attributed to the wrong user or wrong owner name article. We see this happen occasionally when users print through a 3rd party service like Google Cloud Print, Presto, or some server. We also see this happen if the users are badging in with the wrong card, or the card is incorrectly associated with the wrong user. Rule out this scenario by having users log in with username/password instead of ID badge. The print job has been temporarily hidden from the Print Release screen This occurs when a user attempts to release their print job, but the Print Provider which is tracking the job is no longer able to contact the app server. This behavior was introduced as a security enhancement to prevent a scenario when print jobs are inadvertently released after the user walks away from an MFP when the Print Provider and the PaperCut server are not able to communicate. To confirm if this is what is happening in your environment, take a look at the Application Log, under Logs → Application Log. If you’ve found this issue happening in your environment, there’s some in-depth information about this over on the Print Job Temporarily Hidden article. Is this user configured as a release manager, but the user that submitted the job has account selection enabled? PaperCut might withhold a print job from the Release screen because a user has account selection enabled, is waiting for an account selection pop-up, or other reasons discussed above in this article. If you are troubleshooting a problem with “delegated print release” or “Hold/Release queue manager” in PaperCut, try turning this setting off and ensure that the job can first be seen at the release station interface (or the Mobile Release page http://your-server-name:9191/mobile/release ) before adding this extra layer of complexity. Is this user configured as a release manager, but is trying to release their own job? Currently if a user who is configured as a Release Manager logs in to release a job through the release station or release manager interface (at http://yourserver:9191/release ), they’ll only see the jobs that they have permission to release with their release-manager hat on. Have the print release manager open the browser and sign into the user web interface (at http://yourserver:9191/user ) to see and release their own print jobs. For example in the case below, Alice is a release manager, and has printed a job. Tim has also printed a job. Alice only has permissions to release jobs group people in the ‘students’ group, and ‘Tim’ is a member of the students group. Alice is a member of the staff group. With us so far? This is what an admin sees when logging into the Admin interface, and checking under the Printers → Jobs Pending Release tab: Since Alice has been configured as a release manager, when she logs into the /release interface, it will only show jobs from users in the ‘students’ group - in this case, Tim - so she isn’t able to see her own job: To release her own job, she should log into the /user URL as her, to be able to release her own job. The job reaches the print server, the user can release the job, but nothing prints out… Does this only happen when printing to a Find-Me queue? Sometimes the problem is just with Find-Me Printing specifically, but print jobs sent to other queues work just fine? To confirm, try printing straight to a “target” print queue on the same print server instead of the “Find-Me” print queue. Does the job go straight through? If so this might be an issue with the way that Find-Me Printing is configured. Have a look at our article on Troubleshooting Find Me Printing for the next steps. Is the print driver configured to require a PIN or other Authentication? Some manufacturer’s print drivers can be configured to show an authentication prompt for a user or department PIN. Xerox Pull/Print is one example, but Konica Minolta, Toshiba, Sharp and others may also have this feature. Confirm whether this is the case by printing a test page from the Windows print server. Is there an authentication prompt from the driver? If so, disable this setting (usually found in the Device Settings tab in Printer Properties on the Windows print queue). For example, Konica Minolta drivers can also behave by not asking for authentication and the job will just be canceled. You can see the auth settings here in the print driver defaults: In another example, for Sharp devices, make sure User Authentication is not enabled in Printing Defaults. When this is incorrectly enabled, customers may report a 042F Error in the log on the Sharp copier. There’s more information in the Known Issue for 042F errors article, along with a screenshot of the setting in the Printing Defaults. Does this only happen when printing from Windows 10 apps like Edge, and are you using driver authentication? When this happens we hear about print jobs getting stuck. We describe this scenario and the workaround in our article Jobs stuck with the status of ‘Printing’ . Is the print queue set up to use the PaperCut TCP/IP port instead of a Standard TCP/IP port? If the printer is in an error state, then this may prevent the next job from being sent to a print queue. If you’re not explicitly wanting to use hardware validation/checking , then use a Standard TCP/IP Port and don’t use the PaperCut TCP/IP port, unless it is absolutely necessary. This will slow down printing by design as PaperCut will wait until the printer reports that the last job was printed before sending the next one. There’s more information about the impact of Hardware Checking on printing speed . Does the problem only happen when printing from macOS to a Windows Print Server? If you’re printing from macOS to a Windows server, with Type-4 or XPS-enabled drivers, then the job will not get through - this is actually the case even without PaperCut running. For more of the gory details behind this, check out Windows and Type 4 Drivers . Still have questions? Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.