“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 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: 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:
- 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:
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”.
