When the computer you want to upload a driver from isn’t shown
When following the steps to upload a print queue and driver (as described in Creating and deploying PaperCut print queues and drivers ), a list of computers is displayed for you to choose where to upload the driver from. If the computer you’re looking for isn’t listed, consider the following.
Is the computer online and running the client (edge node) software?
In the list of computer displayed when you’re adding a driver to a print queue, only computers running the PaperCut Hive or Pocket client software are displayed. They must also be currently online (not powered off or sleeping).
If you’re not sure if the client software is installed, try re-installing it.
Ensure you are running the latest version of the client software. Computers with outdated client software will appear in the list of computers to choose from with a “Require update” label next to the computer name. To update the client software:
- In the admin console, go to Settings > Advanced and switch Diagnostic Mode to on (green).
- Go to Edge Mesh and select the three-dot menu on the outdated edge node (client software). A dropdown menu is displayed.
- Select Update Now. A popup opens.
- Select Update Now. The client software (edge node) updates.
Was the correct platform/OS selected?
You can choose to add a driver for Windows or macOS. For example, if you chose to add a Windows driver, only computers running Windows are displayed in the list of computers to choose from.
Can the computer connect to PaperCut’s cloud services?
If the computer can’t connect with PaperCut’s cloud services, it will not receive the message telling it to provide its list of print queues.
The simplest way to determine this is to check whether you can print and release jobs using the default PaperCut Printer queue. See Troubleshooting > Sending the print job .
When the print queue to copy isn’t shown
When following the steps to upload a print queue and driver (as described in Creating and deploying PaperCut print queues and drivers ), and the computer to upload the queue from has been chosen, a list of print queues is shown. If the print queue you have just created isn’t listed, consider the following.
Was the queue created as a direct TCP/IP connection?
Ensure that the queue uses a direct connection to the printer:
- Windows: TCP/IP or LPR protocol
- macOS: HP Jetdirect - Socket
If you created the print queue using a server or IPP connection, it will not be shown.
Refer to Preparing a printer driver for more details.
Can the computer connect to PaperCut’s cloud services?
If no print queues are listed, perhaps the computer is unable to connect with PaperCut’s cloud services.
The simplest way to determine this is to check whether you can print and release jobs using the default PaperCut Printer queue. See Troubleshooting > Sending the print job .
When cloning on macOS fails on error with failed to get dynamic link libraries referenced...
To clone a queue on a macOS machine, it must have the otool command line tool installed.
Can you run otool?
Does running otool in a terminal work properly? If not, you can install it by running xcode-select --install which will install command line developer tools.
Have otool but still getting a failure?
Try running xcode-select --reset in a terminal.
When the print queue isn’t deployed to users’ computers
Did you prepare and deploy print queues in PaperCut Hive or Pocket, but now you can’t see those print queues on the end-user’s computer? Consider the following potential causes.
Have you waited ten minutes since you’ve deployed the print queue?
The PaperCut Hive and PaperCut Pocket client checks for updated print queues:
- when there is a network change
- if the computer starts up, or a user logs in
- every 5 – 10 minutes.
When you make a change in the admin console, you need to wait for one of these events to trigger print queues refresh.
Does the deployment rule criteria match the user/computer’s attributes?
When you create a deployment rule, print queues only deploy when all the criteria are met. For example, if you specify a network range plus a specific user, then only that user will receive the print queue when they are connected to your specified network range.
In this example, if you intend to deploy the print queue to anyone connected to the network and also to a specific user, then create two deployment rules: one with a network range and one with a specific user.
If your deployment rule seems correct, also check the following:
- Does the computer’s local IP address match your deployment rule network range? The PaperCut Pocket/Hive client gathers the computer’s local IP address(es) when assessing whether print queues should be installed or not. PaperCut Pocket/Hive does not use the IP address of a proxy server or NAT gateway.
- Double-check the hostname matching text. Although regex is supported, it is easy to make a mistake when writing a regex-matching string. The easiest way to specify specific hosts is to create a comma-separated list of hostnames.
Print queue fails to install on Windows ARM64 computers
Some Windows drivers are not compatible with ARM64 computers and might fail to install. If the printer manufacturer doesn’t offer an ARM64 driver for your printer, then you can opt to use the built-in PaperCut Global Postscript driver that comes with PaperCut Hive and Pocket. To use this built-in driver, create a new Print Queue in the Print Queues section without changing the Windows driver that is listed by default.
Note, that although the PaperCut Global Postscript Driver supports most printers, it won’t support all printers.
PaperCut Hive and Pocket client logs
Still having issues? Learn how to collect the PaperCut Printer Client logs for troubleshooting and to share with your PaperCut Support contact.
When printing defaults aren’t set
After you create and copy a print queue and then start testing it (or have deployed it), if the default print settings when printing don’t match what you originally configured, consider the following.
Windows system vs user default print settings
Windows has both system-level printing defaults and user-level printing defaults. The system-level settings apply to all users.
If you are familiar with creating Windows printer shares, the system-level settings apply to the client systems. These are the ones that need to be set so that they take effect when copying the queue. Learn how to find system-level printing defaults in Windows.
Something else?
If the default print settings were configured from the correct location, but a setting still isn’t being copied, please get in touch . Include the:
- driver name and version you’re using
- brand and model of printer you used when configuring the print queue to copy
- OS type and version you created the print queue on
- OS type and version on which you see the issue.
When printing isn’t correct
After you create and copy a print queue and then start testing it (or have deployed it), but something isn’t right with the print jobs that come out, consider the following.
Was printing correct before copying the queue?
To rule out issues related to the process of copying and deploying the print queue, it is important to know whether or not the queue was working correctly before it was copied! If you’re not sure, consider setting up the queue again and performing some test prints.
If something isn’t working right at this stage, contact your PaperCut reseller or printer vendor for assistance.
Does the problem only occur after copying the queue?
If printing was correct before copying the queue, and the issue only occurs when testing or deploying it, please get in touch . Include the:
- the driver name and version you’re using
- the brand and model of printer you’re printing to
- the OS type and version you’re deploying the queue to
- if you’re feeling especially helpful, enable diagnostic mode , and include the job trace id from Logs > Job Log tab > (select your job) > Diagnostics > View job trace > Copy (at the top).
When the default queue isn’t correct
When you make changes to the default queue and don’t see the desired changes reflected on a machine, try uninstalling and installing the PaperCut Hive or Pocket client edge node software. The system assumes clients start off with the default global PaperCut Printer.
Has your PaperCut queue been removed or renamed? Have you changed it to use a manufacturer’s driver?
We recommend a clean installation of the PaperCut Hive or Pocket client edge node software, which will add the default global PaperCut Printer to the system. You can now use the feature to rename the default queue or make it use a manufacturer’s driver.
In Windows, does it take time for the Print dialog to appear or does the Print Spooler service crash while attempting to print?
Most print drivers can communicate with the physical printer they are connected to in order to fetch additional printer details. This setting is called ‘bidirectional communication’ and is enabled by default.
In PaperCut Hive, a Find-Me printer does not have a direct connection to any physical printer. Therefore, the driver will eventually fail to communicate, causing delays or spooler crashes.
The Windows OS provides a standard mechanism to configure this feature via the “Enable bidirectional support” driver option. When a Find-Me printer is configured with a manufacturer driver, PaperCut will automatically deselect this option.
Most print drivers honor this setting, but some drivers might have unique, non-standard ways of managing communication with the printer. If present, PaperCut will not disable these settings.
If you experience any of the following and you have confirmed that the “Enable bidirectional support” is disabled for your Find-Me queues, please contact your PaperCut reseller:
- delays when opening the print dialog
- issues when printing
- crashes of the Print Spooler service.
They can help determine if additional configuration is required to disable bidirectional communication.
When the print queue you’ve deployed using a deployment rule does not show
When following the steps to deploy a print queue (as described in Creating and deploying PaperCut print queues and drivers ), and nothing happens on the target computer, here are some things to check.
Is the client linked to a user?
Print queues won’t deploy to a computer if the client that has been deployed (for example, via MDM) when the user hasn’t linked up to PaperCut Hive or Pocket yet.
To check if a user is linked, go to the user.directory logs and look for entries containing user.ident.
If there is no linked user, authentication on print (for example, when the user signs in when releasing a job) will link the client to the correct user.
Until a user is linked, the client can’t apply deployment rules that target that user.
Have the firewall requirements been met?
If the device can’t connect to PaperCut’s Cloud Services due to firewall restrictions, the deployment won’t succeed.
Double-check that the system meets all PaperCut Hive firewall requirements.
If in doubt, see if the user can print and release a job from the PaperCut Printer. If that fails, firewall access might be the cause.
Do the logs show the correct host, user, and IP info?
During deployment, PaperCut Hive or Pocket evaluates the rules you’ve created against the client’s reported details. If the log shows incorrect data, the wrong rules might apply, or none at all.
To verify, check the conditions set in your deployment rules with the targeted computer. For example, your rules might state to deploy only to users in a specific group or subnet.
Even one mismatch might explain why the queue didn’t deploy.
Still stuck?
If everything seems in place — user is linked, firewall is open, log data aligns with the rules — but queues still won’t deploy, get in touch with support and include:
- a copy of the deployment rule(s)
- the edge node logs of the computer you’re targeting
- confirmation that the device is online and running the PaperCut print client
- whether the queue ever showed up before.
These details will help us narrow down what’s going wrong.
Comments