Choose your language

Choose your login

Contact us

Troubleshooting Disappearing jobs with Find-Me Printing

THE PAGE APPLIES TO:

“Help! We’ve set up Find-Me Printing in our print environment but we’re seeing print jobs disappear when users try to release them! Why does this happen and how can we fix it?”

PaperCut’s Find-Me Printing feature allows users to send print jobs to a one single print queue and release their print job at any printer. When it works, it can make users and sysadmins lives easier but when it doesn’t work it can be a frustrating experience.

Thankfully we’ve seen most of the things that can go wrong with Find-Me Printing and we’ve documented those reasons below.

This article specifically addresses scenarios where print jobs sent to a Find-Me queue will disappear, but regular print queues on the server work just fine.

Is this a problem with Find-Me Printing or printing in general?

First things first, we need to establish whether this is a problem with Find-Me Printing or printing to this printer/driver/server in general. To do so, let’s take Find-Me Printing out of the picture for a moment and try sending a print job to a “destination” print queue on the server. For this to be a good apples to apples test, the destination queue should have the same driver, settings, etc… as the Find-Me queue.

Does this print job also vanish? If so, see our article on Missing or Disappearing Print Jobs.

If you establish this problem only occurs when printing to the Find-Me print queue, continue below…

Is the print server set up correctly for Find-Me printing?

To ensure the best experience when using PaperCut we recommend following our Best practices for configuring Windows Print Servers guide. Below are the highlights that are especially important in a Find-Me Printing scenario:

  • Ideally your Find-Me print queue should be configured to use a Local Port using the name “nul” and not any other port such as a Standard TCP/IP Port, not a PaperCut TCP/IP Port, or WSD Port)
  • In a Find-Me Printing scenario you should not mix and match Type-3 print drivers (usually downloaded from the manufacturer) and Type-4 print drivers (bundled with Windows Server 2012 and newer). For a number of reasons we recommend sticking with Type-3 Print drivers.
  • In Windows print environments, make sure Advanced Printing Features is configured uniformly across all the print queues.

Are jobs inadvertently releasing to the wrong destination queue?

Sometimes we see that a step has been overlooked during Find-Me Printing Setup and now jobs are being inadvertently released to the wrong device.

You can check for this by looking at the Job log in the admin interface (log in to PaperCut as admin → choose LogsJob Log). Find the print job in question and see if this was released to a different printer than the one which was intended. If that’s the case, you’ll need to revisit how Find-Me Printing is configured.

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 problem only happen when jobs are redirected across print servers?

It’s possible to configure Find-Me printing so that jobs can be submitted to one server, and then released to a queue hosted on a completely different print server. We call this “Cross server redirection” and there are a few ways this can go awry.

  • Both servers must be the same OS type (Windows → Windows, or macOS → macOS etc). If you have a mixed environment of Windows, Linux, and macOS servers and clients then take a look at Find-Me Printing on Multiple OSes to see what’s required.
  • Make sure that the PaperCut Print Provider service is running as a Service Account that has rights to submit a job to the destination print queue. Local system will not have these permissions. More details in the “Error: 5” section below.
  • Confirm the Print Provider service on both servers is actually running (we’ve seen cases where the password for the service account on one server expires).
  • In Windows environments, “Share this printer” must be enabled for the destination queues on the Secondary Server for cross-server redirection to work.

Do you see the “Error: 5” message?

To check for this error, look in the PaperCut Application Log for the message Access is denied. (Error: 5). If this error is occurring, it will be seen in the Application Log (found in Logs → Application Log).

Unable to redirect job from \\PrintServer1\Find-Me-Printer to \\PrintServer2\DestinationPrinter. Is the "Print Provider" service running under a user account with permissions to redirect to the target printer? User:SYSTEM - Access is denied. (Error: 5)

On this page of the manual we discuss how to set up “Cross-server job redirection”. For this to work, the PaperCut Print Provider service must be running as a user account with privileges to copy the spool files to the other print server. The “local system” (or “SYSTEM”) account in Windows does not have permission to do this. If you have not configured the Print Provider service to run as a domain user account, but try to set up Find-Me Printing to redirect jobs from one print server to another then you will probably encounter this error.

Do you see the “Error: 1801” message?

To check for this error, look in the PaperCut Application Log for the message Unable to redirect job… (Error: 1801). If this error is occurring, it will be seen in the Application Log (found in Logs → Application Log).

Here’s what you may see in the Application Log in PaperCut:

Unable to redirect job from [=\\PrintSRV01\find-me-printer=] to [=\\PrintSRV01\library-color=]. Is the "Print Provider" service running under a user account with permissions to redirect to the target printer? User: SYSTEM - T (Error: 1801)

According to Microsoft this message is due to an Invalid Printer Name (the full message is 1801 ERROR_INVALID_PRINTER_NAME”) but we’ve seen a number of different conditions can trigger this error. It generally means that the destination print queue is unreachable…

For example:

  • The hostname of the print server that hosts the destination queue is greater than 15 characters. This is a longstanding Windows limitation.
  • This can happen if the destination print queue was deleted or renamed on the server.
  • This can happen if the PaperCut server is unable to resolve the hostname of the destination print server.
  • It can happen in the case of cross-server redirection if the required ports for Windows printing (particularly TCP 445) is blocked between the server that hosts the Find-Me queue and the server that hosts the destination queue.

Do you see the “Error: 1804” message?

To check for this error, look in the PaperCut Application Log for the message the specified datatype is invalid. If this error is occurring, it will be seen in the Application Log (found in LogsApplication Log).

Here’s what you may see in the Application Log in PaperCut:

Unable to redirect job from [=\\PrintSRV01\find-me-printer=] to [=\\PrintSRV01\library-color=]. Is the "Print Provider" service running under a user account with permissions to redirect to the destination printer? User: Alan-One- The specified datatype is invalid. (Error: 1804)

This is a windows error (1804 ERROR_INVALID_DATATYPE) which indicates the job couldn’t be redirected from one print queue to another because the format of the spool file of the print job, also known as the “datatype”, is incompatible with the way that the print queue is configured.

The most common way this happens is when Advanced Printing Features is enabled on the Find-Me queue, causing Windows to spool the print job in the EMF (Enhanced Metadata Format) datatype, but is not enabled on the destination print queue. For Find-Me printing to work, PaperCut copies the spool files from the Find-Me queue to the destination print queue but if this is expecting a different datatype, that’s when this error might occur.

The solution is to make sure that “Advanced Print Features” is set uniformly across all the print queues in a Find-Me Printing setup (preferably set to disabled).

More detail can be found in the article: The Specified Datatype Is Invalid.

Does this only happen from printing from Windows 10 Store Apps like Edge?

If so, you may want to read about this extremely specific, perfect-storm condition that happens when customers set up Find-Me Printing and use the built-in authentication methods available in some manufacturer’s print drivers.

The telltale sign is that one print job will be stuck in the Windows print queue with the status “Paused - Spooling” and another will have the status of “Printing”, and seems to hold up all other print jobs.

Check the Windows print queue on the server by opening printmanagement.msc → right-click on the printer in question → click Open Printer Queue. If you see jobs held up like this, then head over to our article Print Jobs stuck with the status of “Printing”.

Do you see the message “Error redirecting job” on macOS or Linux PaperCut servers?

Unlike the other messages in this article which are Windows-specific, this one usually appears on Linux and macOS systems. This is a generic error message, and we’ve seen a couple different things cause this problem.

The full message is “Error redirecting job to PrintSRV01\GutenbergLaserJet, see print-provider.log for details. Cancelling print job

However when we dig into the print-provider.log file we see the following error which tells us the command failed with “Exit code: 1” which just means it was unsuccessful without explaining why. “ERROR: print_command.c:268 - Failed to execute print command: lp -d \G\u\t\e\n\b\e\r\g\L\a\s\e\r\J\e\t\ -h PrintSRV01 -t \R\:\3\v\p\c\L\1\:\T\e\s\t\ \P\a\g\e -U \a\n\o\n\y\m\o\u\s -o raw \/\t\m\p\/\p\c\6\1\5\4\8\0\0\4\4\b\5\a\5 > /dev/null 2>&1 Exit code: 1 [6956]”.

In most cases, it was discovered that CUPS had been configured not to listen on localhost/127.0.0.1. The customers had deliberately commented out a line in cupsd.conf that would have allowed the Linux server to accept jobs from 127.0.0.1:631. Another customer said they had to add the line “Listen 127.0.0.1:631”. 

However there could be a different reason for the failure. Other customers have let us know that the issue was related to DNS not resolving the server name, an SSL-related issue because of a misconfigured certificate, or that printer sharing had been disabled on the destination print queue.

To investigate this further, we will likely ask for debug mode to be enabled in the Print Provider to understand the reason for the failure.

Alternatively we might ask you to edit the print-provider.conf file (found in <app-path>\providers\print\linux-x64\print-provider.conf) to use the RedirectCommand to output an error to a text file so we can see why the command is failing.

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.


Categories: Troubleshooting Articles , Find Me Printing


Keywords: Virtual Queue Issues

Comments

Last updated March 15, 2024