Troubleshooting Web Print problems

STATUS= Finished: Queued for printing

This means that the job has been successfully uploaded to Web Print and sent to the printer. If you’re not seeing the job after this, check to see if this issue happens without Web Print when simply printing from the server. For additional troubleshooting ideas, check out Missing Or Disappearing Print Jobs.

STATUS= Finished: Held in a queue

This means that the job has been successfully uploaded to Web Print, submitted to the printer, and is now held by PaperCut because Hold/Release or Find-Me Printing has been configured. In order to release the job, the user must release the print job after logging into a copier or a PaperCut Release Station.

STATUS= Denied: [Reason for denial]

PaperCut may be configured to deny print jobs for a lot of different reasons. One common example is that the user has run out of balance and their account is set to restricted, which would result in the message “Denied: Not enough available credit”.

Print jobs may also be denied for being too large, for having too many pages, for having a disallowed file extension, or being in color or duplex. Usually this happens because the printer in PaperCut was configured this way on purpose. These settings are managed for each printer in PaperCut under Printers > [printer name] > Filters & Restrictions.

STATUS= Canceled: Canceled by print policy

Seen to happen when a print script is enabled and requires a pop-up. Web Print works with Print Scripting but does not support pop-up notifications. You will either need to disable Print Scripting for this printer, or rewrite the script to ignore documents when the source is Web Print.

STATUS= Failed: Printer ‘\\PaperCutSRV01\library-color’ is currently not available.

This means that Web Print is unable to print the job because the printer cannot be found, which can happen for several different reasons.

• The print queue was deleted from the server

• The print queue was renamed on the server

• The print server was renamed

• The print server name is longer than the supported NetBIOS name (no greater than 15 characters)

• No print queue with this exact name is set up on the Web Print Sandbox

• The print queue no longer works because of Windows security changes related to Print Nightmare.

• Or an extremely specific issue resolved with PaperCut version 17.4 that affected Web Print Sandboxes on Windows Server 2008 R2 or Windows 8 and above using Client-Side Rendering (CSR)

In most of those scenarios Web Print is unable to submit the print job, because the name of the “printer” in PaperCut does not actually match the name of a print queue that exists on the server or Sandbox.

To resolve, log onto the PaperCut server running the Web Print Service or workstation running the Web Print Sandbox application and make sure that the print queue still exists and that the name matches what is in PaperCut. If the print queue or print server was renamed recently, then follow these steps in How to Rename a Printer to make sure the printer has also been renamed in PaperCut.

Then try sending a test page to that printer, making a note of any Windows error that may appear, then troubleshoot accordingly.

The Web Print sandbox should send print jobs to a server-hosted printer, not a direct printer. The printer connection should be directed at the print server's hostname, not IP address.

STATUS= Failed: Timed out

This message will be preceded by “Rendering successful. Preparing job for processing” finally it will be replaced by this message after a few minutes.

It has been seen to happen in a couple situations:

• The PaperCut Print Provider service is not started. In this case the print job may still print successfully but users will see the “Failed: Timed out” error.

• On the Web Print Sandbox there may be an Office application like Word with an open dialog box which is preventing the job from printing.

• Make sure the Web Print hot folder is mapped on the Sandbox machine.

• More than one Known Issue (specifically PC-15889 affecting PaperCut 19.0.4 and PC-9941 affecting PaperCut 16.2) resulted in Web Print jobs failing with this error message.

• Canon Generic drivers configured with “Spooling at Host” enabled. Discussed further here .

• Some other condition related to the print queue or driver having an issue.

If you’re running Web Print Default mode, log onto the PaperCut Application Server and make sure that the “PaperCut Print Provider” service is started following these steps. Also if you are encountering this message with an older version of PaperCut, try upgrading.

If this is a Web Print Sandbox, log on as the workstation as the Web Print user account and ensure that you can print an Office document normally and there are no prompts or dialog boxes blocking the application from printing.

Also try printing a Windows test page to the print queue (without Web Print) to ensure the print queue and printer are working as expected.

STATUS= Error: Unable copy print data file when preparing print job

The Web Print Service or Sandbox is supposed to copy the print job to the %TEMP% directory but fails for these reasons that we’ve seen:

• the computer running Web Print has run out of disk space

• the Web Print Sandbox user account doesn’t have write permissions to the %TEMP% directory

The exact steps to get this working will depend on whether this is the Web Print Service or Web Print Sandbox. If this is the Web Print service running as SYSTEM, then this directory will be located in C:\Windows\Temp\web-print. Whereas if this is the Web Print service running as a service account or the Web Print Sandbox, then the path will be %TEMP%\web-print.

Check the server where Web Print is running to ensure there is adequate disk space. Also if Web Print is running as a service account or if this is the Web Print Sandbox then check the permissions on the %TEMP% directory to ensure that this user account has read, write, and modify privileges.

STATUS= Failed: Unable to start handler to render print job

This has been seen to happen for the same reason as the Unable copy print data file when preparing print job error, but when an image file is uploaded to Web Print instead of a PDF. We believe this happens when the “image handler” used by Web Print for images (like .png and .jpeg files) fails to print the job for some reason.

We know from testing that you can encounter this error if the Service or Sandbox is unable to write to the Windows %TEMP% directory as described above.

• Another customer let us know they started seeing this error after configuring the Web Print service to run as a Service Account, and realized this was happening because Microsoft Edge was the default PDF viewer. Once they set Adobe to the default PDF viewer, this problem went away.

• In another case, a customer was encountering this error when users would attempt to upload password-protected documents to Web Print. In this case, when logged in as the Web Print Sandbox user, you would see an open password dialog prompt waiting for input. If you encounter this, please raise a support ticket and reference “PC-5325”.

• More recently we have seen a few situations where this happened after applying Windows patches. In a remote session we found that even trying to print a document through Word or Adobe on the server running the Web Print Sandbox application (without PaperCut) would cause Word or Adobe to freeze or crash. We attempted to remove and re-add the print queue and ran into the error “Windows cannot connect to the printer 0×0000007c”. This error message is associated with the Microsoft patches released to address the Print Nightmare vulnerability, and there is more information on our Known Issues page. Once the customer resolved this issue, they were able to re-add the printer to the Web Print Sandbox and then were able to resume printing through PaperCut’s Web Print.

Reach out to us through the link at the bottom of this article and let us know if you encounter this message for another reason.

STATUS= Failed: Cannot access network printer ‘\\server\printer’ from ‘system’ account

This happens when the Web Print Service, which runs as local system by default, tries to submit a print job to a queue hosted on another print server but lacks permission. In the world of Windows the local system account has full admin rights on the local server, but cannot interact with anything on the network, including a print queue on another server, hence the error.

Resolving this error depends on whether your PaperCut implementation is supposed to be using the Web Print Service (default) or Web Print Sandbox.

• If you use the Web Print Service… There are at least two ways to fix this. The hard way to resolve this is to configure the Web Print Service to run as a domain user or Service Account with permissions to send print jobs to the print queue on the other print server. The easy way to resolve this is to simply make sure that any print queues published through web print are hosted on the print server that is running PaperCut.

• If you use the Web Print Sandbox… This error should never be seen for print jobs submitted through a Web Print Sandbox because this application doesn’t use the system account and must run as a logged-in user. If you are seeing this error, it means that the Web Print Service was not disabled on the PaperCut server and is still running. Disable the Web Print Service by opening services.msc, right-click on the service PaperCut Web Print Server, choose Properties, then make sure that the service is stopped and that the startup type is Disabled.

Curiously, you may also see that Office documents will succeed but PDFs and image files won’t. This is because office documents are printed through the Web Print Sandbox which runs as a domain user account, and PDFs fail because are printed by the Web Print Service which might be running as local system.

Additionally this also has been seen to happen when someone edits the line ServerName= in the Print Provider configuration file, print-provider.conf. If this is the case, this change must be reverted as it is not compatible in most Web Print implementations.

An admin might have made this change deliberately because they wanted to hide the name of the print server in Web Print for security reasons or to make things simpler for users. A better method for hiding the name of the print server in Web Print is described on our page about using Javascript to customize the User Web interface.