Troubleshooting Find-Me Printing and Virtual Queues

“Help! We’ve set up Find-Me Printing in our print environment but we’re seeing print jobs disappear or other problems 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 Logs → Job 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: 32” message?

Occasionally customers report that Find Me Print jobs are failing with the below error message.

Mar 23 11:43:29 ERROR: Unable to open spool file for redirect. - The process cannot access the file because it is being used by another process. (Error: 32)

This is usually an indication that a process other than PaperCut has an exclusive file lock on the print spool files. This can be caused by Anti-virus, backup or more even more customer-unique software.

To better determine where the issue lies some of our customers have reported success by using SysInternals ( http://technet.microsoft.com/en-us/sysinternals/default.aspx ) “Process Monitor”. This application is able to monitor a Windows Server and see what processes are accessing what resources. Once known steps can be taken to resolve this issue.

When monitoring file access it is best to filter the events to only include the Print Spooler directory, by default C:\Windows\System32\Spool\. Please also note that this kind of monitoring may have a impact on system performance.

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 Logs → Application Log).

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

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.

Something prints but the output is ‘gibberish’

We sometimes hear from end-users that a printer is outputting pages and pages of “gibberish”. Usually what this means is that the printer is unable to parse the spool file and is just printing the raw PostScript of the print job.

This is a relatively common problem that happens without PaperCut, usually because the printer is not compatible with the print driver. In the context of Find-Me printing, this issue arises when the driver used with the Find-Me Print queue is not compatible with your specific printer model.

It is important to note that some printers from certain OEMs don’t support PostScript without purchasing an add-on module. This should be taken into consideration when using any PostScript driver, including the PaperCut Global PostScript driver.

To figure out the best print driver for your Find-Me queue, please revisit the section titled “What print driver should be used for the Find-Me print queue?” in our article Common Questions about Find-Me Printing .