Skip to content

Choose your language

  • No results

Choose your login

  • No results
Support

How can we help?

Lightbulb icon
Lightbulb icon

Here’s your answer

Sources:

Lightbulb icon

Oops!

We currently don’t have an answer for this and our teams are working on resolving the issue. If you still need help,
User reading a resource

Popular resources

Help center

FAQs
Conversation bubbles

Contact us

Search

Troubleshooting the PaperCut Print Deploy Client

This page applies to:

Refer to this article if you are running into any issues with the Print Deploy Client.

Basic checks

  • See which version is running. As a first troubleshooting step, ensure the Print Deploy server and client are running the latest versions. The Print Deploy client will display the version number on one side. Compare this version number to the Print Deploy Release history by looking up the last 4 digits.

    Know that automatic updates can be toggled off , so check this setting if the client is not running the latest version.
  • Check system requirements. Make sure client and server meet the Print Deploy minimum system requirements . Trying to run the Print Deploy Client installer on an unsupported processor (such as 32-bit) will result in the error message: ‘This installation package is not supported by this processor type. Contact your product vendor’.

PaperCut is already installed

You’re seeing this error message:
This software cannot be installed on the same machine as where PaperCut MF/NG is installed

Print Deploy Client Setup error that says "This software cannot be installed on the same machine as where PaperCut MF is installed." You might see this error when certain PaperCut components are already installed on a user’s computer. This could be the PaperCut Application Server, Site Server, Secondary Server, or most likely the Direct Print Monitor. Print Deploy cannot be installed alongside these components.

The PaperCut User Client (for balance display and billing) won’t trigger this error, and can run alongside Print Deploy without issue.

To resolve, uninstall the other PaperCut software before attempting to install the Print Deploy Client.

  • Windows clients: Check in “Programs and Features” to see if any PaperCut software is already installed and follow the normal steps to uninstall the software from there.
  • macOS clients: Check in the “Applications” folder to see if any PaperCut software is already installed and run the Uninstall script to remove.

The Print Deploy client is unable to connect

After the user logs in they see an error message in the Print Deploy client: “Well this is akward” followed by “The Print Deploy client can’t find it’s servers! Check your network connection and click Try again.”

What’s going on? The most likely explanation is that the Print Deploy Client can’t connect to the PaperCut server or has received an error from the server.

Perform these checks:

  • When launching, the Print Deploy client reads the file client.conf.toml to determine the server name, then checks this file to make sure that the correct server hostname was specified during installation. Consider trying the fully qualified domain name of the server or IP address instead.
  • Ensure the firewall port 9174 (HTTPS) outbound TCP port to the PaperCut Application Server is open per Print Deploy system requirements page . As a test, use a browser on the client workstation and navigate to https://<server-name>:9174. If successful you’ll see a green coffee cup graphic.
  • Check the Print Deploy service is running on the PaperCut server:
    Log in to the web interface of the PaperCut server as an admin, click “Enable Printing”, then check the Print Deploy tab to confirm.
  • When deploying the Print Deploy client through an MDM such as JAMF, double- check instructions to ensure everything is configured as documented. Try specifying the server’s fully-qualified domain name or IP address.
  • For further troubleshooting there is also be a post-installation log located in <install-directory>/data/logs that might offer additional insight.

Users are being prompted for credentials to install a printer on Windows

A UAC (User Account Control) prompt in Windows is normal behavior when standard users try to connect to a server-hosted printer to download a new driver. This has been a requirement in Windows since the print security changes following Print Nightmare in 2021.

The exact message says “Do you want to allow this app to make changes to your device?” with the specified app being “Printer driver software installation” from Microsoft Windows.

This behavior happens with or without Print Deploy. To see for yourself, try browsing to the share on the print server to add the printer as that user:

  1. Log in to a workstation as a user.
  2. Click the Windows icon, type “run” and click Enter.
  3. Type the address of the print server, like \\servername, then click the printer you want to add. (This is similar to what Print Deploy does.)
  4. When installing a new driver the will see an authentication prompt, if they do not have local admin rights. Also, the user must have some permissions to access the shared Windows print queue on the print server.

There are a few different ways around this.

  • Clone and deploy Direct Print queues, as opposed to server-hosted queues. The downside is that this is not compatible with Find-Me Printing or Print Archiving. Steps: ​​​ Directly print from workstations to printers using Print Deploy .
  • Import print queues from Mobility Print. This method imports the print queues from your Mobility Print server into Print Deploy. This doesn’t require the Windows authentication prompt and instead users authenticate with their PaperCut credentials. Steps: Import Mobility Print queues .
  • Use Type-4 Drivers. These are the printer drivers that come preinstalled with any Windows OS since Windows 8 (including Windows 10 and 11) and do not need to be downloaded, so there will be no UAC prompt. However, there are some limitations that we document here: Limitations with Type 4 Drivers and PaperCut .
  • Turn off the security feature that forces the UAC prompt for printer installation (not recommended). This suggestion warrants caution. It entails editing “Modify the default driver installation behavior using a registry key” discussed in this Microsoft article (set registry key RestrictDriverInstallationToAdministrators to 0) to allow non-admins to install printers as before. However, with that advice, we also highly recommend Microsoft’s additional protections:
    • Configure clients to only trust specific print servers and packages, as per the “Permit users to only connect to specific print servers that you trust” and “Permit users to only connect to specific Package Point and Print servers that you trust” sections of the Microsoft KB article .
    • For any machines that are not sharing out printers, disable the Computer Configuration item “Allow Print Spooler to accept client connections” as detailed through controlling printing through Group Policy .
  • Pre-install the driver (not recommended). Some customers have found that if they install the print driver on a user’s workstation in advance, then the client won’t need to download the driver from the Windows print server, so the UAC prompt won’t be triggered. This might work if you only have a couple drivers and you can push them out through an MDM, but can break the moment a driver is updated on the server, so we can’t recommend this for everyone.

Access is denied error on Windows

You’re seeing the error message:
“Windows cannot connect to the printer. Access is denied.”

This happens when users do have permissions to install a print queue on their local machine but don’t have permissions to connect to the shared print queue on the server.

We know of at least two scenarios that can cause this:

  • When a workgroup computer is trying to connect to a domain-joined print server.
  • When workstations are joined to an Azure domain but the print server is not.

Instead of deploying Windows server-hosted queues, consider these alternatives:

  • Clone and deploy Direct Print queues, as opposed to server-hosted queues. The downside is that this is not compatible with Find-Me Printing or Print Archiving. Steps: ​​​ Set up Print Deploy in a print serverless (Direct Print) environment
  • Import print queues from Mobility Print: This method imports the print queues from your Mobility Print server into Print Deploy. This doesn’t require the Windows authentication prompt and instead users authenticate with their PaperCut credentials. Steps: Import Mobility Print queues .

“Failed” message after installing printer

We’ve seen this occur when there is a problem with the print queue, such as an unsigned driver or some other issue with the client creating the print queue.

Per our requirements :“The driver must be package-aware and digitally signed with a trusted certificate, preferably by Microsoft. If the certificate is provided by a third-party vendor, it must be preinstalled on all of the clients.”

If you encounter this problem, try another printer driver first. If that doesn’t work, reach out for assistance. We’ll ask you to reproduce the issue and follow the steps in Print Deploy Client Logs to share the usercontextservice.log and pc-print-deploy-client.log files.

Printers are slow to install

Troubleshooting steps are different depending on the type of print queue (direct print queue or server queue).

Direct print queues

Some drivers might take a few minutes to query the printer to determine the installed hardware capabilities, such as a duplexing unit. In Windows this feature is called Bidirectional Support . The problem is that if the printer is not accessible over the network, this process will still continue and take several minutes.

Consider using a different driver, disabling Bidirectional Support, or troubleshoot why the driver is not able to contact the printer.

Windows server-hosted queues

If it’s taking about 45 seconds to add each queue, it could be because the high dynamic port range (49152 - 65535) might be blocked on your Windows print server. When these ports are blocked, this will cause Slow Connection with Windows Print Servers .

Users see other’s printers

In the past, on shared Windows workstations (such as lab computers) where two or more users might be logged in, users were able to print using queues that another user had installed.

For Windows workstations, confirm that the configuration key SharedDeviceEnabled located in the file client.conf.toml is set to true. For more information see Shared computers (Windows only) .

On macOS workstations, this behavior is the default.

Printing issues

If the Print Deploy client successfully installed the printer, but there’s any problem with printing this is most likely a problem with the print driver, the print queue, or the physical printer itself.

If this is a Mobility Print queue, jump directly to our article Troubleshooting Mobility Print print jobs .

Now, let’s take the Print Deploy Client out of the equation - try connecting to the printer or (or server-hosted print queue) without the PaperCut Print Deploy client and try sending a print job. This might be easiest to test from the reference computer.

Further reading:

If you want to delve deeper into what might be happening, then debug information is available in the Windows Event Viewer Operational Log and the CUPS error_log when running in debug mode:

Linux client fails to install

When installing the Print Deploy Client on a Linux machine without CUPS ( Common Unix Printing System ) installed, the installation fails with an output similar to below:

william@gibson:~/Downloads$ sudo dpkg -i pc-print-deploy-client\[print-server.company.lan\].deb
[sudo] password for william:
(Reading database ... 166393 files and directories currently installed.)
Preparing to unpack pc-print-deploy-client[print-server.company.lan].deb ...
Unpacking papercutprintdeployclient (1.0.346) over (1.0.346) ...
Setting up papercutprintdeployclient (1.0.346) ...
dpkg: error processing package papercutprintdeployclient (--install):
 installed papercutprintdeployclient package post-installation script subprocess returned error exit status 1
Processing triggers for gnome-menus (3.36.0-1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for mailcap (3.69) ...
Errors were encountered while processing:
 papercutprintdeployclient

You can then check the following log file: /opt/PaperCutPrintDeployClient/data/logs/install.log

2022-01-27 15:00:02: +papercutprintdeployclient.postinst:162 installDPM(): rm -f configure-cups
2022-01-27 15:00:02: +papercutprintdeployclient.postinst:162 installDPM(): ln -s /opt/PaperCutPrintDeployClient/direct-print-monitor/providers/print/linux-x64/configure-cups .
2022-01-27 15:00:02: +papercutprintdeployclient.postinst:163 installDPM(): popd
2022-01-27 15:00:02: /
2022-01-27 15:00:02: +papercutprintdeployclient.postinst:165 installDPM(): /opt/PaperCutPrintDeployClient/direct-print-monitor/providers/print/linux-x64/roottasks install
2022-01-27 15:00:02: Updating print provider configuration...
2022-01-27 15:00:02: Installing CUPS print provider...
2022-01-27 15:00:02: Unable to find cupsd - is CUPS installed?

Still having issues? Check out how to collect the Print Deploy logs for troubleshooting to share with your PaperCut Support contact.

Comments