Known Issues

We have reproduced behavior where CUPS default printer settings can cause documents to be printed in the wrong color format (for example grayscale instead of color and vice-versa). We don't believe this is a 'new' issue, but something that will crop up depending on the PPD / print driver in use.

The behavior is best explained through an example, and this can be experienced without the need for any PaperCut products to be installed - this happens at the CUPS level with manufacturer drivers.

Example:

• Setup: Customer sets up library-grayscale and library-color print queues. The default settings include 'print in color' disabled for the library-grayscale printer, and 'print in color' enabled for the library-color printer.
• Test: Customer prints document 1 to library-grayscale. The document prints grayscale. Print to the library-color print queue, and ensure that color is enabled. The document prints (incorrectly) in grayscale. Print to the library-color print queue again, ensuring that color is enabled. The document prints (correctly) in color.

What appears to be happening is that CUPS retains the default setting used in the last print job - so in the example above the second job prints incorrectly in grayscale, because the previously printed job was grayscale. The third print job sent to the color queue prints correctly in color because the previous job was set to color.

We will update this Known Issue as and when we discover more information. In the meantime a suggested workaround is to promote black and white printing (PaperCut Pocket and Hive) or suggest that users print in grayscale through print scripting (PaperCut NG and MF). In this workaround users can print documents in color and then choose to convert selected documents to grayscale / black and white.

When running a Transaction Report, negative balances in the CSV export appear with an apostrophe (e.g., '-10.0 instead of -10.0). This prevents some external systems from correctly importing the data.


Workarounds:

Open the CSV in a text editor and remove the apostrophe manually before importing it into external systems.

If feasible, downgrade to 24.1.2 until a fix is available.




Web interface shows error HTTP ERROR 500 javax.servlet.ServletException: javax.servlet.ServletException: Unable to resolve expression "mailto:' when applying a perpetual license that has a negative number of Site Servers available in the Global Entitlements Service.

• This does not impact licenses being applied where there is a positive number of Site Server entitlements available.
• This does not impact licenses being applied where there are any other types of entitlements which have been over-claimed (into the negative) - e.g. devices.
• This does not impact Application Servers where a license is already applied and has a negative number of available Site Server entitlements.
• This does not impact Application Servers where a license is already applied and has a negative number of available Site Server entitlements, and the App Server is restarted.

This will only happen in the extremely rare case where a license has a finite number of Site Servers in the entitlements (e.g. 2), AND that entitlement has been over-claimed (e.g. available Site Servers is -1) AND that license is then uploaded to an Application Server AND that Application server that the license is uploaded to has one or more site servers attached to it (listed under the 'Sites' tab).

The web interface will then produce the error above. The only option to restore service is to restore the Application Server database.

Customers may see Background entitlements sync failed. Reason: Failed to sync entitlements. Failed to decrypt claim response. error in the logs, for Site Servers.

This error can be ignored since Site Servers do not need to sync with the Global Entitlements Service (GES). Only Application Servers need to sync with the GES.

We are looking to resolve this in an upcoming maintenance release.

When a non-embedded device (e.g., Network Card Reader, VCC Controller) is added to the Devices list, attempting to access PaperCut Admin UI > About > Registration triggers a HTML error.


We’re actively working on having this resolved in the next maintenance release.


PaperCut gives an unexpected error when trying to release jobs from the "Printers > Jobs Pending Release" queue, specifically for jobs sent to a virtual queue and released by the built in "Admin" account.

Error:
Unable to invoke method doRelease on web.components.ReleaseStationJobs$Enhance_49@22a83049[PrinterRelease/jobs]: Cannot find user admin

Workaround: Log into the Admin console as an account that's not the built in "Admin" account, with release privileges, and you can release jobs normally.

Note: Releasing jobs at a device is NOT impacted.

Multiple jr-fontxxxx.ttf files can take up a large amount of space within /server/tmp/.

These files are created if someone runs a PDF format report (e.g. any report within the Reports tab, where PDF is selected as the output format).

Workaround:
The files are indeed temporary, so can be safely deleted to save space. Some files may not be able to be deleted while the Application Server service is running, in which case to clear them entirely, during off-hours you'll need to stop the Application Server service, delete the temporary files, then start the Application Server service.

We are looking to fix this so that the temporary files are cleaned up properly, in a future release.

Note that this has now been resolved in PaperCut version 24.1.3.

Users can’t complete MFA card self-association on devices connected to site servers. This happens because the application server can’t decrypt information required for this feature. This issue was identified while addressing a related problem PO-2410

Our developers are aware of the issue and it’s currently being scoped for resolution.

Note that this has now been resolved in PaperCut version 24.1.3.

Our recent fix for double-tap issues on Xerox Altalink 81xx series devices (in version 24.1.2) has unexpectedly caused the browser to become unresponsive on Altalink 80xx and Versalink 71xx series devices.


We’re actively collaborating with the Xerox EIP team to find a resolution.


Workaround: If you’re using Altalink 80xx or Versalink 71xx devices, we recommend not upgrading to 24.1.2, or, if already upgraded, downgrading to PaperCut MF v24.1.1 until a fix is available.

Note that this has now been resolved in PaperCut version 24.1.3.

For HP, Xerox, and Toshiba devices that are connected to a site server, scanning reports and archived scans may show incorrect document names and Scan Action IDs.

This issue occurs when multiple scans are performed in the same session (e.g., when selecting "scan more pages" at the device).

Papercut Universal Print Connector unable to print jobs on Win 11 24H2. Team is actively investigating the issue. However connector works as expected in Windows 10 environments.

Note that this has been resolved in 2024-12-10-1226.

Important Notice: Print Deploy Shared Secret Expiration with Entra ID SSO

In Print Deploy, a shared secret is used for all customers utilising Single Sign-On (SSO) to enable user authentication through Microsoft Entra ID. The shared secret expired on November 24, 2024.

To find out if you’re using Entra ID, you can go to Enable Printing > Print Deploy > Settings > Authentication methods and if Microsoft is checked then you are using Entra ID.

To ensure uninterrupted authentication, we strongly recommend switching on auto updates (Enable Printing>Setting>AutoUpdates) to ensure you will receive the latest Print Deploy version 1.9.2768. It’s only the Print Deploy server that needs to be updated, not the Print Deploy Clients.

If you're not able to enable auto-update, you can manually update Print Deploy by following the steps here: Manually update the Print Deploy Server to the latest version

Organizations can also configure their own custom Entra ID application, allowing them to proactively manage their own secrets should they wish to do so, steps here: Use a custom Microsoft Entra ID application with Print Deploy

Note:The MF application server uses a different shared secret and is not affected.

In versions 24.0.4 or later, when an SFD device is created and no SFD entitlements are available, the device will consume an available MFD entitlement.

When this occurs, the brand usage table in the About->Registration tab will indicate that the incorrect brand license is in use. This error is visual only and will not disrupt device or server licensing.

Workaround: To force SFP licenses to not use MFD entitlements, set the subscriptions.sfp-entitlement-consumption.enabled config key set to N but ensure you have the appropriate SFP licenses.

Note that this has now been resolved in PaperCut version 24.1.3.

[Also linked to PO-2569]. Intermittent errors may be seen in the Application Log, normally on the hour, indicating a sync failure:

Unable to contact PaperCut Gateway Service. Ensure your server is online and try again. If still failing, contact your Accredited Reseller for support.
Background entitlements sync failed. Reason: Request to PaperCut MF gateway service failed. Internal Server Error.

These are not critical errors and can mostly be safely ignored. For example if the hourly syncs are intermittently failing, and if you can see that the 'last synced' time under About > Registration > License Info (or Subscriptions) is showing a recent time stamp, then the errors can be safely ignored.

For peace of mind, you can perform a manual sync under About > Registration > License Info (or Subscriptions), then press the Sync button if required.

Note that despite some of these errors being downgraded from ERROR level to WARN level in 24.0.5 (under PO-2569), some sync errors may still appear as ERROR level.

We are aware that this issue with the sync intermittently failing is causing unnecessary alarm, and are working to address this - in the meantime, functionality, printing and licensing will not be impacted.

Update in version 24.1.1: Changes include changing the synchronization frequency within PaperCut NG/MF, to randomize Application Server syncs during the hour, preventing simultaneous server requests.

On Xerox devices with firmware 121.xxx, tapping the screen may result in a "double tap". Mitigation: Downgrade to firmware 120.xxx.

Note that this is not a 'new' Known Issue. This is something that has occasionally cropped up if the step in the KM embedded manual gets accidentally skipped.

Konica Minolta devices log print jobs as copy jobs.
This happens in particular in conjunction with print release.

Fix:

Please ensure that print jobs go to the copier “unauthenticated”. See the section titled Enabling unauthenticated printing in the Konica Minolta Embedded Manual.

Note: Both the Print Driver settings and the Front Panel / LCD settings need to be changed.

By default in some Unix distributions, Unix PAM users are unable to log in to PaperCut NG/MF.

This known issue refers to the User/Group sync source Unix Standard (PAM, nsswitch etc.).

Is your PAM (Pluggable Authentication Modules) setup configured to deny services by default? Some Linux/Unix distributions adopt more stringent defaults for unspecified management groups i.e. account, authentication, password and session.
Note: As with any security related modifications, make sure these authentication changes are right for you.

Fix:

Edit the /etc/pam.d/papercut PAM configuration file with appropriate permissions, and add the following lines:
auth required pam_unix.so
account required pam_unix.so

Please note: The module name (pam_unix.so) may be different for your Linux/Unix distribution.

Save the file. Changes should come into effect immediately.

Issue: Users will experience login delays or failures if devices are upgraded to Xerox firmware version 120.xxx or above (with the last known stable version being 120.009.003.20000).

Resolution:
Update impacted devices to use firmware version 121.xxx.034.28900 available from xerox.com. Be aware that there may be other issues with this firmware, including another PaperCut MF known issue CDSS-4678.

If PaperCut MF is configured to use OAuth authentication for SMTP, email notifications in Job Ticketing will fail. Job Ticketing relies on the same SMTP settings as PaperCut MF, but it currently does not support OAuth for authentication.

The issue is caused by the system utilising the wrong configuration key to construct the URL sent in the notification email.

Currently, the system.network-address key, intended for internal communications between system components, is being used instead of the system.network-address.user-facing key, which is designed to present user-friendly URLs.

As a result, the email link may display the internal network address and port number of the wrong server (such as the Site Server if the MFD is connected to them), which is not intended for user access.

The PaperCut development team are aware of the issue and are investigating a fix.

Note that this has now been resolved in the 24.1.1 release.

After upgrading to version 24.0.4 or later, you may see an error on the About > Registration page: You are using a license for a device your organization is not licensed for. Please contact your PaperCut Accredited Reseller for assistance.

This relates to the new 'brand breakdown' table mentioned in the release notes: "Added a device brand breakdown table in the About > Registration page which will allow for better insight into which device brands are being used and licensed on the server. Note: After upgrading to 24.0.4, the license file will need to be uploaded again in order to display the license counts in the Brand breakdown table. [PO-2448]"

Workaround:
You will need to re-upload your license file, through About > Registration > Register. After re-uploading, the correct brand breakdown information should be shown, and the incorrect error message should disappear.

Customers utilizing Print Deploy to install Mobility Print queues may notice that these queues fail to install if they've implemented "Sign in with Microsoft" and affected end users have UPNs that contain uppercase characters within EntraID.

Symptoms of this issue are recorded in both the Print Deploy client and Mobility Print server logs.

Example from the Print Deploy Client log:
pc-print-deploy-client.exe: STDOUT|SUP "500 Internal Server Error" returned (attempts=0) {"src":"service.go:404"}

Example from the Mobility Print server log:
mobility-print.exe: STDOUT|ERROR Failed to validate credentials. [ credentialsType=Microsoft access token err=userPrincipalName from Graph API (TestUser@papercut.com) does not match the user (testuser@papercut.com) ] auth.go:204

Disclaimer:
The workaround below is only recommended for administrators familiar with PowerShell and Azure AD / EntraID. While the steps below have been tested, this is still considered unsupported in that any unintended side effects are the responsibility of the administrator who chooses to perform them.

The following steps will automate the conversion of UPNs stored in EntraID to lowercase via PowerShell.

Install the required Module and set the execution policy for the logged in user to run remote signed code (this can be reverted later):
Install-Module -Name Azure, Azure.Storage -Repository PSGallery -AllowClobber -Force
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Import the Module and connect to AzureAD using an administrator account  (make sure to enter your Tenant ID after -tenantID):
Import-Module -Name Azure
Connect-AzureAD -tenantID your-tenant-id-here

Test to ensure the authenticated user account is able to retrieve users:
Get-AzureADUser  

This should return a list of users (example output):
ObjectId DisplayName UserPrincipalName UserType
-------- ----------- ----------------- --------
102df3af-95be-48d9-b4d7-dcf648113d1c Test User Test.User@testuser.onmicrosoft.com Member

Feel free to test the command on a single user:
Set-AzureADUser -ObjectId TestUser@test.com -UserPrincipalName testuser@test.com  

Finally, the code below will convert all user UPNs to lowercase within your Azure tenant. This only changes the UserPrincipalName attribute to lowercase - no other modifications are made:
$arr = Get-AzureADuser
$output = ForEach ($user in $arr) {Set-AzureADuser -ObjectID $user.UserPrincipalName -UserPrincipalName $user.UserPrincipalName.ToLower()}

The application used to print images in Web Print and Email to Print can fail in Web Print sandbox configurations due to a file path parsing error.

Workaround:
Obtain a 23.0.7 version of image-handler.exe.

Modify the HotFolder path so it in not the default W:\ and contains a subfolder name.

Contact PaperCut support for an updated version of image-handler.exe.

The PaperCut application makes a connection to a cloud service for license activation and verification. When there is a failure, the current message is an Error (e.g. Background entitlements sync failed. Reason: Request to PaperCut MF gateway service failed. Internal Server Error.) even after license registration has been successful.

This message is causing unnecessary alarm for PaperCut administrators and can be ignored if there have been subsequent successful syncs.

We are making a change in a future release to create this message as a Warning once the license has been registered.

In version 24.0.5, the error level for some of these errors have been reduced from ERROR to WARN. However, we are working on fixes to resolve this issue with the background sync more permanently in the future - see known issue PO-2745 for more information.

When attempting to set queues as optional when associating them with a Zone, the Optional checkbox at the bottom of the Print Queue list is unusable.

Print queues can still be set to Optional one by one using the three dot menu located on each print queue within a Zone.

We have reports of missing PaperCut MF icons in the display while the Basic interface view is selected. This is reported to be happening in Konica iSeries and Develop ineo+ devices across multiple firmware versions.

Reported firmware versions: G00-RB, G00-RD, GC4-RD, G00-P8, GC4-RB

Workaround:

- Switching to Classic Interface view will show the missing icons.

- A device restart will temporarily resolve the issue for a limited time until the error occurs again.

- Downgrading to an older version of the firmware: G00-Q8

Customers experiencing this issue should reach out to their local Konica Minolta field engineer to help them resolve the issue as the workaround might look different for each customer.

We have reports of intermittent white screen display in Konica iSeries devices across multiple firmware versions.

Reported firmware versions: G00-RB, G00-RD, GC4-RD, G00-P8, GC4-RB

A firmware fix GC2-RE is now available for these devices:

- bizHub C3350i, C3351i, C4050i, C4051i
- ineo+ 3350i, 3351i, 4050i, 4051i
- d-Color MF3303, MF4003

Upgrading to the latest firmware fixes the issue. We have had a 100% success rate. The new firmware is under special firmware on the page of the device items.
For devices where firmware is not available, or customers still experiencing this issue after a firmware update should reach out to their Authorized Konica Minolta Partner as additional configuration changes may be required after a firmware upgrade.

Known Workarounds:
- A device restart will temporarily resolve the issue for a limited time until the error occurs again.
- Downgrading to an older version of the firmware: G00-Q8 seems to have fixed the issue for a customer.

Canon i-SENSYS/imageCLASS/Satera devices are not tracking USB print jobs

PaperCut has now released Microsoft Windows Arm64 support for the majority of client components.

They are using Window's x64 emulation feature, Prism.

Please note: Arm64 is targeted at portable devices such as laptops, tablets, and we are prioritising support for these devices.

• PaperCut Global PostScript Printer Driver: The Windows Arm64 printer spooler requires architecture specific printer drivers. x64 printer drivers can not be used. Version 100.3.0.0 of the PaperCut Global PostScript Printer driver (included in PaperCut NG/MF 24.0.3 and Print Provider version 111.0.16.8220)

Products & features that are released:

• PaperCut Pocket Edge Node installer
• PaperCut Hive Edge Node installer
• PaperCut Mobility Printer Installer Client (legacy)
• PaperCut NG/MF - Print Deploy - Mobility Print Import Wizard
• PaperCut NG/MF - manual installation of `providers\print\drivers\global\win`
• PaperCut TCP/IP Port: The Windows Arm64 printer spooler requires architecture specific printer port drivers. We are investigating this further and will be released later but is currently a low priority. This impacts Hardware Page Count Validation.

Products & features under testing

• PaperCut NG/MF - Server installations - Not supported in the near future: primary server, secondary server, site-server, direct-print-monitor installations
• PaperCut NG/MF - Print Deploy clients
• GhostTrap: GhostTrap is an open source product that PaperCut contributes to significantly. This product converts PDLs such as PostScript and PCL in to PDF. GhostTrap currently only installs to x64 systems. We are investigating supporting an enhancement to allow installation to Arm64 systems and allowing Prism emulation to handle running GhostTrap.

  Products & features under testing

  • PaperCut Pocket Edge Node installer
  • PaperCut Hive Edge Node installer
  • PaperCut Mobility Print server
  • PaperCut NG/MF DocProc on prem service
  • PaperCut NG/MF WebPrint service (server & sandbox)
  • PaperCut NG/MF Print Deploy: This feature clones many different printer driver across multiple operating systems. Support for Arm64 printer drivers from manufacturers appears sparse at this time. We are adding support for Arm64 drivers at this time. Please note: If you clone a print queue with an Arm64 printer driver, it will likely overwrite an x64 driver on the server.
  • PaperCut NG/MF Print Deploy Cloner: wmic.exe has been deprecated and causes an error when cloning. Resolved in - Cloner version v701, released in Print Deploy server version 1.8.2680. [PD-2066]

When the Ricoh SmartSDK embedded version 3.2.7 is used with MF versions 24.0.3 and below, advanced scan to fax will not work as the new embedded version expects additional parameters.

Resolution:
Upgrade to PaperCut MF 24.0.4 or newer and use the Ricoh SmartSDK embedded version 3.2.7

Issue

There is an issue accessing Pay Station devices from the Admin UI. When selecting the device or when running the Pay Station report, you are taken to an error page with the following: "Required parameter userSourceType of component DeviceDetails/deviceAuthOptions is not bound." If the goal is to remove an unwanted pay station use the workaround below.

Workaround: You can delete the device using server commands: So for example, if you want to delete "pay station 1", you'd run the command like this (instead of using a server name, you literally use the word device): server-command.exe delete-printer device pay station 1

Update August 12th 2024: There is now a 23.0.9 hotfix version available. Please contact support and reference PO-2548 when requesting this version.

Please note that this has now been resolved in version 24.0.4.

When an SFP consumes an MFD entitlement, inconsistent values for the MFD/Full Embedded and SFP/Lite Embedded rows in the Device & Connectors table on the About > Registration page are displayed.

Please note that this has now been resolved in version 24.0.4.

Microsoft Defender may classify Print Deploy binaries as malicious. We can confidently say that these are false positives.
The root cause has been identified and we're working closely with Microsoft to implement a fix in a future release of Print Deploy.

Workaround:
Follow the guidance contained within our AntiVirus False Positive knowledge base article here.

The Print Deploy server may crash on PaperCut servers that have been affected by the recent CrowdStrike incident due to the client.conf.toml file becoming corrupt.

Symptom:
The Print Deploy page, located on the Enable Printing tab within the NG/MF admin web interface will be blank.

Log snippet:
2024/07/19 02:07:51 pc-print-deploy-server.exe: STDOUT|ERROR: Print Deploy Server will now terminate. initialise config: failed to load config from file c:\Program Files\PaperCut MF\providers\print-deploy\win\data\config\client.conf.toml: toml: line 1: files cannot contain NULL bytes; probably using UTF-16; TOML files must be UTF-8 {"src":"main.go:61"}

Solution:
Delete the client.conf.toml file located here:
[app-path]\PaperCut MF\providers\print-deploy\win\data\config

Then proceed to restart the PaperCut Print Deploy service.

With the Print Deploy client UI already displayed, selecting the taskbar (Windows) or menubar (macOS) Print Deploy client icon and choosing “View my printers” will open a tab in the default browser displaying the Print Deploy client UI.

The Print Deploy client icon is missing or disappears from the Windows system tray.

Workaround: Restart the Print Deploy Client service or restart the affected machine(s)

This bug will be addressed in a forthcoming client update.

We have investigated reports that customers experience a non-blocking error dialog on Ricoh Smart SDK 5 devices using PaperCut Integrated Scanning when ext-device.ricoh.scan.prompt.checkbox.checked is configured with N. This problem appears to be related to a specific Ricoh firmware version. Please refer to the hardware manufacturer for updates.

Workaround:
Configure ext-device.ricoh.scan.prompt.checkbox.checked Y

Roll back the Ricoh firmware to the previous version.

Ricoh is actively investigating this issue.

Issue

Customers have reported a null pointer exception in a number of HP devices after upgrading to 24.0.2. An error message pops up on the device with a dialog saying “please wait 15 minutes, contact admin."

Workaround

Delete the device and re-embed the software.
It should be noted that if the Application Server, or Application Server Service is restarted, this process will need to be repeated.

After installing the Print Deploy client on Ubuntu 22.04.4 the client windows displays a message "Could not connect: Connection refused"

Workaround: Right click on the page and select “Reload”

When upgrading from PaperCut MF version 23.x and earlier to version 24.0.1 and later, an internet connection is required for the Application Server. See Important points to know about PaperCut MF licensing (Internet connection requirements) for more information.

Some customers do not allow their Application Servers to access the internet, so will experience licensing issues when upgrading to version 24.0.1 or later. See When upgrading to PaperCut MF v24.0 or later and the Application Server is offline.

We have plans to deliver support for offline activation for both Perpetual License customers and Subscriptions customers by November 2024. When released, customers will be required to request an offline activation from their reseller, providing both their license file/ activation code and server identification. If you'd like to be notified about this, contact us and quote "PO-2223", or keep an eye on the latest PaperCut MF release notes.

Workaround:

In the short term, for customers who upgrade to 24.0.2 or later we will increase the current offline grace period from 30 days to 120 days. This means customers can upgrade now and have 120 days to either activate online, or activate offline once that functionality becomes available. Remember also that even after this period expires, users and functionality is not impacted at all, only the administrator login will be restricted to certain pages.

If you believe that your Application Server should have access to the Global Entitlements Service, see General troubleshooting Global Entitlements Service (GES) connections for troubleshooting tips.

In PaperCut MF pre-v24, SFP (single function printers) were able to use MFD entitlements. Upon upgrading to 24.0.1, this was disallowed and printers became not licensed. As of 18 June 2024 AEST, SFP printers will automatically claim any available MFD entitlements, preserving pre v24 functionality. If incorrect data is still being displayed in the About > Registration page, click the ‘Sync’ button to refresh data.

This fix has been addressed in the cloud service. An updated MF version is not required.

A Release Station may still report as ‘In Use’ even when it is shut down, using up an entitlement which should have been released.

Workaround:

Restart the PaperCut Application Server service, and then click the Sync button in the PaperCut MF admin interface, under About > Registration > License Info.

In PaperCut MF version 24, when restoring a database backup or restoring a server after the loss of the original server, the PaperCut MF Application Server may fail to successfully activate, or may stop the use of some entitlements because it believes the entitlements are in use elsewhere.

Changes in licensing with version 24 means that Application Servers using the same CRN all share the same set of entitlements - see Global set of entitlements for more information. This means that if you build a new Application Server and restore your data from your original server, the Global Entitlements Server thinks this is a new additional Application Server, so you will only have access to the entitlements that your original server had not already claimed.

To work around this issue, you should ensure that you backup your server.uuid file from the old server where possible.

1. On your active server, locate the server.uuid file from [App Server install directory]\server, for example: C:\Program Files\PaperCut MF\server.
2. Copy this file somewhere safe, to a different server or network location.

When you have restored your data onto the new server, you will need to copy the server.uuid file back to the same location on the new server: [App Server install directory]\server, for example: C:\Program Files\PaperCut MF\server.

You should now be able to start up the server and the claimed entitlements should match up with what is in use currently.

If you are still seeing issues with activation or with claiming the entitlements (e.g. number of devices that you’re entitled to) then you will need to contact PaperCut tech support to ask them to release the original server's entitlements in the back-end.

When using the server command install-license on version 24.0.1, the license may install correctly but buttons on the ‘Registration’ tab may be missing or broken.

We recommend not using the install-license command on 24.0.1 until this is resolved.

PaperCut Partners managing PaperCut MF subscription customers with Multiverse are prevented from seeing the correct subscription details. Partners will see the customer’s old license information through Multiverse and will not see the current subscription.

Customers are not impacted by this issue - customers viewing the subscription under About > Registration > Subscriptions will see their correct subscription information.

Note that this does not impact perpetual license customers (customers not running a Subscription).

In HA environments using PaperCut MF’s natively supported Application Server Failover, there is an issue where the subscription or perpetual license doesn’t register correctly.

Our recommendation is to not upgrade to version 24 if you are using HA features in your environment.

Please note that if you’re using High Availability using e.g. MS Failover Cluster Manager or VMWare vCenter High Availability, or if you’re using HA with Print Deploy only, then these solutions will continue to work as expected.

This issue has now been resolved in PaperCut NG/MF version 24.0.5.

Since implementing PC-17476 (user card PINs are now one-way hashed for enhanced security) in v22.1.0, the knock-on effect is that the encoding increases the time it takes for a User/Group Synchronisation to complete for every user by 8-10 seconds if they have populated a new or changed PIN field from your User/Group Synchronisation Source.

We are investigating ways to minimise the negative performance effect of this security change. In the interim, you can utilise feature PO-540 and use the config key user.card.pin.hash-encode=N to control whether user PINs will be hashed encoded in the server.properties file. After you make this change, you must save the server.properties file and then restart the MF Application Server service to apply the change.

Please note that this has now been resolved in version 24.0.3.

Some Kyocera devices get a "System error" on black and white scans when the device is set to use High Compression PDF by default.

To work around this limitation, per device configurations can be configured to disable high compression:
ext-device.kyocera-mita.scan.pdf.high-compression=N
ext-device.kyocera-mita.scan.use-file-default-settings=N

Alternatively, the device settings can be changed to not use High Compression PDF by default.

In an environment where Mobility Print queues have been deployed, and the Direct Print Monitor bundled with the Print Deploy Client is present, Application Server logs will be flooded with the following warning:

Printer 'PrinterName' on server 'pd-client' will not be monitored because it a remote HTTP printer. Please re-install as a local printer or with a standard TCP printer

This is superfluous logging that can safely be ignored. We have a fix to prevent this logging in a future release of Print Deploy.

Workaround:

If you aren't deploying direct print queues in your environment, you can prevent this by uninstalling the Direct Print Monitor component from client workstations. Additionally, to prevent this with future installations, you can skip the installation of the bundled Direct Print Monitor following the instructions here.

UPDATE:
Fix is available in macOS client v1439 and Windows client v1778, which is available in Print Deploy server version 1.8.2614 .

Tips on getting this fix quicker:
Enable auto updates, follow Enable or disable auto-updates on the server. To trigger an auto-update immediately, restart the Print Deploy server service.

Once the server has been upgraded, Print Deploy clients will automatically update over a few days. To avoid waiting for clients to update automatically, you can:

• Download the latest Print Deploy client from the Print Deploy admin interface and deploy it with your MDM tool of choice or install it manually on clients.
• For MacOS clients, if you can run terminal commands remotely, you can trigger an auto-update within 10 - 70 minutes by restarting the client.
  Run sudo launchctl unload /Library/LaunchDaemons/pc-print-deploy-client.plist
  And then sudo launchctl load /Library/LaunchDaemons/pc-print-deploy-client.plist
• For Windows clients: Restart the PaperCut Print Deploy Client service from services.msc.

Issue:

In environments where the Direct Print Monitor bundled with the Print Deploy Client is present, non-Print Deploy printers that reside on a client device may be registered and monitored.

These registered printer objects will be listed in the "Printers" tab of the PaperCut NG/MF Admin web interface with the following syntax:

pd-client\PrinterName

Workaround:

If you aren't deploying direct print queues in your environment, you can prevent this by uninstalling the Direct Print Monitor component from client workstations. Additionally, to prevent this with future installations, you can skip the installation of the bundled Direct Print Monitor following the instructions here.

Update:

Any left over "pd-client" printers can be deleted individually in PaperCut on the Printers page, or deleted in bulk using the server command delete-printer pd-client “[All Printers]”. For more information see Bulk deleting printers.

The Microsoft digital signature in use for the PaperCut Global PostScript driver is not valid due to a minor edit to the driver inf. There is no version change in the driver. Workaround: Use the 100.3.0.0 version driver from any previous version of PaperCut 23. We are reverting the edit in the next release.

UPDATE:
Fix is available in Windows client v1781, which is available in Print Deploy server version 1.8.2616.

Tips on getting this fix quicker:
Enable auto updates, follow Enable or disable auto-updates on the server. To trigger an auto-update immediately, restart the Print Deploy server service.

Once the server has been upgraded, Print Deploy clients will automatically update over a few days. To avoid waiting for clients to update automatically, you can:

• Download the latest Print Deploy client from the Print Deploy admin interface and deploy it with your MDM tool of choice or install it manually on clients.
• For Windows clients: Restart the PaperCut Print Deploy Client service from services.msc. This will trigger an auto-update within 10-70 minutes.

Issue:
We have received reports that server shared printers are being unshared by Print Deploy. We are investigating a correlation between a printer's share setting on the reference machine used to clone printers, and that this then overrides the server's share setting of the printer.

UPDATE:
Fix is available in macOS client v1413 and Windows client v1745, which is available in Print Deploy server version 1.8.2588.

Tips on getting this fix quicker:
Enable auto updates, follow Enable or disable auto-updates on the server. To trigger an auto-update immediately, restart the Print Deploy server service.

Once the server has been upgraded, Print Deploy clients will automatically update over a few days. To avoid waiting for clients to update automatically, you can:

• Download the latest Print Deploy client from the Print Deploy admin interface and deploy it with your MDM tool of choice or install it manually on clients.
• For MacOS clients, if you can run terminal commands remotely, you can trigger an auto-update within 10 - 70 minutes by restarting the client.
  Run sudo launchctl unload /Library/LaunchDaemons/pc-print-deploy-client.plist
  And then sudo launchctl load /Library/LaunchDaemons/pc-print-deploy-client.plist
• For Windows clients: Restart the PaperCut Print Deploy Client service from services.msc.

Issue:
We have had multiple reports that after upgrading to the latest print deploy client, version 1.8.1744, the printers will show in the client simply as "loading....."

Cause:
We believe the issue with only show if the Print Deploy Client is being deployed with the "skipdpm=true"flag. Printers previously installed before the client updated will continue to work, but will show as "loading..." in the client UI.

Workaround:
At this time, if the printers are working as they were previously installed, then no action urgent action is required, as this is just a visual confusion. However if new queues do not deploy, then the immediate workaround is to deploy the client with the DPM being installed.

Fix:
Please note that this has now been resolved in PD Server version 1.8.2588.

Universal Print connection fails when installing a new Universal Print connector with recent versions of PaperCut MF (23.0.7, 22.1.5, 21.2.14, 20.1.10).

Note: If you already had Universal Print installed before the upgrade, there is no impact - the connector will continue to work as normal.

Workaround:
Use Windows’ Services panel (services.msc) select PaperCut connector for Microsoft Universal Print then right click and select Restart . This will restart the service and MF will connect successfully to the Universal Print connector.

When using Print Deploy server version 1.8.2580 or later, and running a version of PaperCut NG/MF other than 20.1.10, 21.2.14, 22.1.5 or 23.0.7 or later, you will receive an error: PaperCut requires an important security update before you can clone. To continue, download the latest PaperCut installer from https://www.papercut.com/products/upgrade when trying to clone new queues.

To resolve this, you will need to upgrade PaperCut NG/MF to version 20.1.10, 21.2.14, 22.1.5 or 23.0.7 and later - as detailed on our PaperCut NG/MF Security Bulletin (March 2024).

(Also known as PD-1916, PD-1919)

IMPORTANT: Customers running PaperCut NG/MF version 20.0.2 or earlier will first need to upgrade to PaperCut NG/MF version 20.0.4 before upgrading to a more recent version. See Known Issue PD-1942 for more information.

Customers running PaperCut NG/MF version 20.0.2 or earlier AND using Print Deploy version 1.3.1267 and earlier will first need to upgrade to PaperCut NG/MF version 20.0.4 before upgrading to a later version.

If you’re running PaperCut NG/MF version 20.0.2 or earlier, check your version of Print Deploy by going to the PaperCut admin interface, then Enable Printing > Print Deploy then checking the Print Deploy version number at the bottom of the screen.

Workaround:
If you are running PaperCut NG/MF version 20.0.2 or earlier AND using Print Deploy version 1.3.1267 and earlier, you’ll need to:

1. Upgrade to PaperCut NG/MF version 20.0.4
2. Upgrade from 20.0.4 to the appropriate fix version listed on our upgrade page: https://www.papercut.com/products/upgrade

If you do accidentally upgrade straight from 20.0.2 or earlier to a later version, you’ll need to downgrade your PaperCut NG/MF install back to your original version as documented on our Downgrading PaperCut (to an older version) page. Then upgrade to version 20.0.4, then upgrade to a fixed version as detailed above.

Download links for 20.0.4:
PaperCut MF version 20.0.4 - Windows, macOS, Linux.
PaperCut NG version 20.0.4 - Windows, macOS, Linux.

Issue:
We have had multiple reports that upgrading to 23.0.5 + can cause an "unknown error" when a restricted user attempts to start a scan. This has been observed on a wide range of Toshiba V3+ devices. If the user is then set to "unrestricted", then the scan will start without issue. Downgrading the MF server to 23.0.4 appears to rectify the issue. We have also had reports that toggling "Track & control scanning" may also change the behaviour. This does not appear to effect all installations.

Cause:
We have now determined that if the system locale for the MF application uses a currency that does not use a "." as the decimal separator, then you will see this error for restricted users. This will be rectified in an upcoming release after 23.0.7

Workaround:
Changing the system locale of the MF server to a currency that uses "." as its decimal separator, such as US, will temporarily resolve this issue. We have had reports that you can then set the individual locale override per Toshiba with the config key "ext-device.toshiba.locale-override" back to what it should be.

Update: This has now been fixed in version 23.0.8.

A change (Apple ticket reference 123028502) introduced in macOS Sonoma 14.4 affects the PaperCut Print Provider's ability to restart CUPS (Common Unix Printing System). As a result, the Print Provider is unable to track and monitor newly added print queues. It's important to note that existing print queues will continue to be monitored and controlled without interruption.

We have a fix planned for a future version of PaperCut NG/MF, but in the interim the script responsible for tracking/controlling printers can be replaced with a working version using the instructions found here.

UPDATE:
Fix is available in macOS client v1412, which is available in Print Deploy server version 1.8.2587.

Tips on getting this fix quicker:
Enable auto updates, follow Enable or disable auto-updates on the server. To trigger an auto-update immediately, restart the Print Deploy server service.

Once the server has been upgraded, Print Deploy clients will automatically update over a few days. To avoid waiting for clients to update automatically, you can:

• Download the latest MacOS Print Deploy client from the Print Deploy admin interface and deploy it with your MDM tool of choice or install it manually on clients.
• If you can run terminal commands remotely, you can trigger an auto-update within 10 - 70 minutes by restarting the client.
  Run sudo launchctl unload /Library/LaunchDaemons/pc-print-deploy-client.plist
  And then sudo launchctl load /Library/LaunchDaemons/pc-print-deploy-client.plist

WORKAROUND:
You can manually apply the fix. Please refer Fix Print Tracking in Mac Sonoma 14.4 for more information.

ORIGINAL:
Due to a change (Apple ticket reference 123028502) introduced in macOS Sonoma 14.4, the Print Deploy Client fails to restart CUPS (Common Unix Printing System), preventing Print Deploy from installing new Direct Print queues. As a result, users won't be able to install new Direct Print queues. However, existing print queues installed on their Macs remain functional for printing.

More specifically, when upgrading from PaperCut MF version 22.x or earlier, to 23.0.0 or later, customers may see error Failed to complete job when scanning - only if using KM devices connected to a site server.

Workaround:

A workaround is to restart the Application Server service, and then the Site Server service on the site server, to re-establish webdav communication between the two.

In some cases the server.log files may incorrectly report the free space on the Application Server is 0.0 MB. e.g. free space: 0.0 MB.

Some customers have seen the correct free space reported after a machine restart, however others have seen the 0MB persist, even when there is plenty of space available. This issue does not appear limited to a particular operating system.

Please note that this has now been resolved in version 24.0.4.

We are aware of an issue that may prevent an application server from starting.

The issue is very dependent on environment, and has so far only been seen on some Linux servers.

An affected server will fail to start after clean installation or upgrade, and the server log will show error messages that include the phrase

Requested bean is currently in creation: Is there an unresolvable circular reference?

We are working to fix the issue and expect to include the resolution in the next maintenance release.

Update: this has now been resolved in version 23.0.7.

Issue Details:

Integrated scan actions making use of the CLA integration will fail to complete as the job is unable to be uploaded to the cloud destination.

Symptoms:

Failed scan jobs will display the following error in the PaperCut Application server log:
Delivering scan images for scan job jobId@ failed with an error: CLA-Upload returned bad exit code, exitCode: 1. See more details in the server log.

Investigation Status:

Our Product Development team is aware of this issue and they're working to identify the root cause.

Since version 1.8.2568, Print Deploy fails to import Mobility Print / BYOD friendly print queues.

When entering the Mobility Print address manually, the admin interface displays a "No printers found for this server."

When scanning for Mobility Print servers, the admin interface doesn't display any Mobility Print servers.

UPDATE:
Fix is available in MacOS client v1403, which is available in Print Deploy server version 1.8.2568. This fix also automatically recovers a user's CUPS IPP backend if Print Deploy previously broke it.

Tips on getting this fix quicker:
Enable auto updates, follow Enable or disable auto-updates on the server. To trigger an auto-update immediately, restart the Print Deploy server service.

Once the server has been upgraded, Print Deploy clients will automatically update over a few days. To avoid waiting for clients to update automatically, you can:

• Download the latest MacOS Print Deploy client from the Print Deploy admin interface an deploy it with your MDM tool of choice or install it manually on clients.
• If you can run terminal commands remotely, you can trigger an auto-update within 10 - 70 minutes by restarting the client.
  Run sudo launchctl unload /Library/LaunchDaemons/pc-print-deploy-client.plist
  And then sudo launchctl load /Library/LaunchDaemons/pc-print-deploy-client.plist

ORIGINAL:
We are working on a fix.

In the meantime, to restore the IPP backend manually, run this command on the client Mac:
sudo cp -p /System/Library/Templates/Data/usr/libexec/cups/backend/ipp /usr/libexec/cups/backend/ipp

Until we have a fix, IPP printing will continue to break when a Mobility Print or IPPS print queue is deployed.

Models reported (to date):

• Xerox Altalink 80xx series devices
• Versalink B405
• Versalink C405
• Versalink C7025

PaperCut has tested Xerox AltaLink 81xx series devices on the latest firmware and V3 browser and have not been able to replicate this issue on that series.

Additionally, it appears that only devices running 2nd Gen EIP Web Browser may be impacted by this issue.

Customers with Xerox devices are advised not to upgrade to PaperCut MF 23.0.5.

Please reach out to us via this link PaperCut Support Team and quote CDSS-3375 should you be experiencing this issue. Please do not forget to quote the model and firmware version of the device, too.

It is often possible to import older database export files into a more recent version of PaperCut, but sometimes changes to database structure or management mean that older imports cannot be supported.

v23.x contains changes that make it impossible to support DB imports from earlier versions of PaperCut.

In general it is best practice to only import databases that were exported from the same version of PaperCut as the target import server, but in the event that it is necessary to import an older database export into a v23.x or later PaperCut server, it can be done by setting up a clean version of PaperCut MF 22.1.4 or earlier, importing the database, and then upgrading the server to v23.0 or later.

When installing the latest (1.4.x) GhostTrap (see Where do I download the latest GhostTrap from?), you need to have the Microsoft C++ runtime environment installed. On some servers this may be installed by default.

If you do not have the Microsoft packages installed, you may see errors when GhostTrap is running, for example Can't load GhostScript DLL, LoadLibrary error code 126 and Ghost Trap: Parent unable to load GS DLL.

If you are experiencing this issue after installing/upgrading GhostTrap version 1.4.x, ensure that you have the C++ redistributable installed from e.g. https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170.

Note that this has now been resolved in GhostTrap version 1.4.10.03.1, which now optionally auto-installs the dependency or prompts for the installation. See GhostTrap release history for more information.

Issue:
When running v23 & using the latest version of the User Client (required, see PO-1845), if the printer is set as "unauthenticated", then credentials popup box will not close.

Replication Testing:
Set a printer as unauthenticated
Run the latest user client and confirms it runs as the logged in user
Print to the unauthenticated printer
Credentials box pops up, enter credentials of a user
Observe user client update with correct balance and name in system tray
Popup box will not close and submit the job

Workaround:
At this time, there is no known workaround. Changing the printer to authenticated / Using Mobility Print will work.

Update 19th Dec, 2023:
This has been resolved with PaperCut MF/NG version 23.0.4:

• Backward-compatibility has been restored for Application Server version 23.0.4 with previous versions of the user client. The exception to this is if you upgraded your clients to the version included with 23.0.3, you'll need to upgrade them to the version included with 23.0.4.
• If you are upgrading from version 23.0.2 or earlier, you don't need to update the client version at the same time as the Application Server - the 23.0.4 Application Server remains backward compatible with previous user client versions.

Some customers have reported seeing error Unable to successfully retrieve valid data from secure connection to server when using older versions of the PaperCut Client for authentication, after upgrading the Application server to 23.0.3.

Please note that has only been seen when using the PaperCut user client for authentication (when a user has to enter their username and password into the PaperCut user client login). If you're only using the user client for the balance window, or for shared account selection, but not authentication, this will not be an issue. This also does not impact the user web interface login.

Workaround:
Upgrading the PaperCut Client to the latest version should resolve the issue, however we are adding this to the known issues page as an additional disclaimer for customers planning to upgrade so that they know that the PaperCut Client will need to be updated in tandem with the server.

Update 19th Dec, 2023:
This has been resolved with PaperCut MF/NG version 23.0.4:

• Backward-compatibility has been restored for Application Server version 23.0.4 with previous versions of the user client. The exception to this is if you upgraded your clients to the version included with 23.0.3, you'll need to upgrade them to the version included with 23.0.4.
• If you are upgrading from version 23.0.2 or earlier, you don't need to update the client version at the same time as the Application Server - the 23.0.4 Application Server remains backward compatible with previous user client versions.

Print deploy is failing to install the printer because pc-print-updater is failing to run with a Access is denied message.

You can confirm this is happening by reviewing the pc-print-deploy-client.log and looking for this line in the logs:

updater.exe: STDERR|ERROR: Operation failed with error: rename update2023-09-04-1440 v2023-09-04-1440: Access is denied.

Workaround is available based on your configuration.

If you are using DPM:

Make sure all the PD client installations have DPM enabled during installation (that means, don't pass SKIP_DPM=true during installations)

If you don't need or use DPM installed with PD Client:

Set DPMUpgradesEnabled to false in client.conf.toml file in the Print Deploy server (C:\Program Files\PaperCut MF\providers\print-deploy\win\data\config)

Restart Print Deploy server service. This will stop sending DPM upgrade commands to client.

The Print Deploy team is aware of this issue and will release a fix soon

An issue has surfaced on Ricoh SmartSDK v3.2.4 where the custom color schemes fail to display correctly on specific sections of the embedded application. Update: This has now been fixed in version 23.0.8.

Incident details
The Hardware Page Count feature does not work when using the Print Provider in the new HTTPS configuration released in NG/MF version 23.0.1.

Workaround:
If you require Hardware Page Count to be performed you must currently disable HTTPS in the Print Provider.

Investigation Status:
The issue is now fixed for Windows and Linux in PaperCut MF version 23.0.3. Work is in progress to fix this for MacOS too.

After configuring Gmail with OAuth or Outlook with OAuth and sending a successful scan to email or notification email, the email feature stops working later and upon inspection, the settings have been cleared from the Options / Notifications page. The settings are cleared due to an error returned by the email provider. We have discovered the authentication failure messages from the provider are not necessarily a cause for alarm. If you have successfully configured OAuth and email has worked, we have a hotfix available based on PaperCut 22.1.4 to prevent clearing the validated Options / Notification settings on these error conditions. Please create a Technical Support Request at support.papercut.com to obtain the hot fix version.

Note that this has now been resolved in PaperCut MF and NG version 23.0.3.

The user client deployed by Intune as per: https://www.papercut.com/help/manuals/ng-mf/clienttool/user-client-install-microsoft-intune fails to install.

Once the Intune package has been created & uploaded to Intune - administrators should be able to specify what context it is added as (user/system)but this defaults to user, causing the install to fail.

Workaround Pre PaperCut Version 24.0.2:

To change this to system you need to edit the XML & follow the below steps before uploading the Intune file created in Step 1 in the installation guide:

Edit XML file

• Open the Intune package file in 7zip browse to \IntuneWinPackage\Metadata\Detection.xml

• Modify the MsiExecutionContext XML from User to System and save

You can now upload to Intune and you’ll see the install behaviour change from user to System. This process will need to be repeated if an updated client needs to be deployed.

A permanent fix is in 24.0.2, please upgrade PaperCut to resolve this issue.

We have seen very rare cases when Canon devices present an on-screen NPE (Null Pointer Exception) error while processing scans, which is caused by a paper size mismatch between the device and the support page sizes in PaperCut. Workaround - you can resolve these errors by manually adding the following 2 config keys to the effected Canon Device in PaperCut and adding the necessary values to it (ie. A4, A3).: 'ext-device.scan.paper-sizes' 'ext-device.scan.default-paper-size'

Update:
As of 20.9.2023, this should now be resolved by a code change made in our Cloud Compression Engine. This does not require any action to the NG/MF server. Issue:
Integrated Scan PDF's with OCR (make searchable) and compression enabled are currently crashing in Adobe. Other PDF readers and web browsers are NOT crashing when opening these PDFs.

Cause:
At this time we believe this to be caused by the most recent Adobe Reader update (12th September), however investigation is ongoing. Adobe Release Notes

Workaround:
Set the PDF/A flag in the scan action will result in the PDF successfully opening in Adobe. Or, open the PDF in another supported program, such as Google Chrome or Microsoft Edge.

Solution:
At this time we are investigating the cause. If you would like updates, please keep an eye on this Known Issue, or log a ticket with PaperCut Support and quote "SC-1998", your PaperCut CRN and request to be added to updates to this JIRA.

With PaperCut Embedded - When using the UI panel on the device, the touchscreen is unresponsive and will often require several presses to register the input.

Models reported:
C8130
C8155
C8170

The Print Deploy Client may fail to install server hosted print queues due to permissions issue introduced in the latest version. A fix is forthcoming.

When using Integrated Scanning with certain Konica Minolta (KM) production level devices including KM AccurioPrint 2100 series and Bizhub PRO 1100 series devices, scanning will produce an error Error: Scan job could not be completed. Please contact your administrator.

Please note that this only impacts KM devices in the AccurioPrint 2100 series, and only impacts scan jobs done through the MF Integrated Scanning feature. Device initiated scan jobs are not impacted.

Resolved in 23.0.1

Incident details
Users may find that when they attempt to select the file name of an Integrated Scanning job, the text field is unresponsive. This can make it difficult to make minor changes to the text field on the devices screen. So far confirmed effected devices are Altalink C8130, C8045 & C8145. This does not seem to be Firmware dependant. This only occurs when at the device physically, if performing the action via the remote panel, the issue will not be present.

Cause:
We believe this was introduced at some point during V22 of PaperCut MF. Confirmed effected is 22.0.9 onwards.

Request:
At this time we are tracking effected customers via CDSS-2455. If you are effected, we kindly ask that you log a support ticket with PaperCut Support quoting "CDSS-2455", as well as your CRN, model of device and MF version number. Thank you.

When using integrated scanning on certain Sharp devices; Should a restricted user’s scan exceed the system.scan.email-max-job-size-kb value, any subsequent scans fail to process with the error “Your account allows only one job at a time. Please wait for other jobs to finish”

To resolve this, a PaperCut Application Service restart is required.

We are actively working on a fix for this issue.

Please note that this has now been resolved in the 23.0.0 release (released publicly as 23.0.1).

You can find out if you are affected by this issue if you are using a) Print Deploy b) the Print Deploy "Serverless" feature c) direct print queues with the Direct Print Monitor. Find a Print Deploy Client affected by this slowness and search in the Print Deploy Client's print-provider.log file for:

ERROR: OpenPrinterA: printer_name=''\\pd-client\YOUR_DIRECT_PRINT_QUEUE_NAME - The printer name is invalid. (Error: 1801)
INFO : Redirect target print server omitted as target print server (pd-client) is as same as configuration key ServerName (pd-client)

Please log a ticket with the PaperCut Support Team if you would like to be proactively notified of the fix for this issue in an upcoming release of NG/MF & Print Deploy.

Please note that this has been fixed in PaperCut MF/NG version 22.1.4.

PaperCut NG and PaperCut MF are often configured to allow for print jobs to be submitted to one print queue, but then released via another. For example, Find Me Printing involves users printing to a "virtual" queue, with that job being redirected to a separate "physical" print queue when the user later triggers its release. Behind the scenes, the print job spool file is being copied from the origin queue, submitted to the destination queue as though it was a new print job, with the original job back over in the origin queue then being deleted. For some print systems, a similar process is undertaken when applying a conversion to a print job, like converting from color to grayscale, or from 1-sided to 2-sided.

In iPrint environments, users may have the iPrint Client installed. When our solution redirects or converts a print job, iPrint will detect that the original version of the job has been cancelled, and by default the iPrint Client will notify the user of this cancellation. The job will proceed successfully, but users may be mislead by the errant notification into believing their job has been cancelled.

To avoid any such confusion, we recommend that organisations running the iPrint Client disable client notifications:

https://www.papercut.com/kb/Main/IPrintCanceledJobs

Update:
We believe that setting SSL to strong defaults in the "server.properties" should resolve this issue with TLS1.3. If you are experiencing this issue, please change the following settings, and restart the App service. The device should embed successfully:

server.ssl.protocols=auto
server.ssl.cipher-suites=auto
server.ssl.using-strong-defaults=Y
server.ssl.follow-client-cipher-order=Y
server.ssl.sni-host-check-enabled=N

Issue:
We have had some reports that new Canon MFDs are coming with the minimum TLS setting set to 1.2, and the maximum setting set to 1.3.

So far confirmed devices are as follows. Canon - imageRUNNER ADVANCE DX C3935i / C3930i / C3926i / C3922i. With these settings, embedding the Canon may fail, and simply display a blank white screen.

We are currently investigating potential solutions.

Workaround:
If you set the minimum TLS to 1.0, and maximum to 1.2, the device should embed successfully.

SMTP server settings may appear blank after upgrading to 22.1.2 - however email notifications and scan to email will continue to work.

After upgrading to 22.1.2, you may find that Options > Notifications > SMTP Server Options > SMTP server is set to Choose..., as though you haven't set up an SMTP server.

IMPORTANT: please note that this issue does not actually impact the sending of emails - in the background the SMTP server settings will be retained.

If you do re-select the correct server type that you were using (e.g. Gmail or Custom etc) you may find that some of the fields are blank. Please ensure that you re-populate those fields before applying/saving any changes. Otherwise it will save the blank fields, and email notifications will stop working.

As an example, if you were using Custom before upgrading, then after the upgrade you will find the SMTP server set to Choose.... If you then re-select Custom from the drop down, you may find that the Host, Port and Encryption fields are blank. You'll need to re-populate those fields before saving (applying) the changes.

You can find previous settings through the config editor, in the following keys:

• notify.smtp.encryption-method
• notify.smtp.port
• notify.smtp.reject-untrusted-certificates
• notify.smtp.server

Please note that this has now been resolved in the PaperCut MF/NG 22.1.3 release.

The Windows Print Deploy Cloner may fail to properly clone if a Printer Port has a tab (\t) in the port name or host.

Example: 192.168.0.10     HP Universal Printing PCL 6

To work around this, please remove the tab (\t) from the name.

The Print Deploy team are aware of this issue and will look to fix this in a future release.

User management integrations could break if configured to use internal user passwords less than 8 characters.

A change in 22.1.0 and later (related to the security hardening efforts) enforces a minimum 8 characters for all Internal User passwords.

Some customers (including customers using Nexudus integrations) have reported issues when using 22.1.0 or later because the integration attempts to create users with 4-character passwords. Creation of users then fails with the 8-character enforcement in place.

Workaround:

We recommend changing the Nexudus (or other user management integrations) configuration to use an 8-character minimum password length instead when using PaperCut MF/NG version 22.1.0 or later.

Please note that this has now been resolved in the PaperCut MF/NG 22.1.3 release: "For internal user accounts only, re-introduced honoring of config key min-password-length to allow admins to set minimum password length for users. Admin password length minimum is still 8 characters since 22.1.1."

Interactive Scan Destination does not retain user id field customisation after upgrade from 21.0.4 to 22.0.11. Workaround solution: re-create the scan action.

The Windows Print Deploy Client may fail to update from a Windows Print Deploy Server.

You can confirm this is happening by reviewing the pc-print-deploy-client.log and looking for this line in the logs:

2023/06/21 17:12:57 updater.exe: STDERR|ERROR: download checksum failed

The Print Deploy team is aware of this issue and will release a fix as soon as possible.

There have been reports of intermittent Ricoh SmartSDK problems when the Site Server the device is connected to goes into offline mode.

The onscreen error states "Could not execute batch: SQL insert...."

When the Site Server reconnects with the App server, the issue is immediately rectified.

Please note that this has now been resolved in the PaperCut MF 22.1.3 release.

Due to a Xerox firmware issue on some Versalink and Primelink models, users that have more than 32 characters in their username (for example users UPNs) are unable to authenticate. When this happens the screen on the MFD may show either a "Can't communicate with authentication server" or "Could not log in. The server could not be found or is unavailable" error.

These models of Xerox devices are working as per Xerox defined specifications. Customers using Versalink and Primelink modelswith PaperCut MF will need to ensure that whatever field they plan on using as their User ID should consist of no more than 32 characters.

If you want to contact Xerox about this issue directly, please reference: FER 17493.

We have received reports of some customers seeing increased memory usage on the Application Server, when scanning very large jobs (e.g. 20+ pages with lots of color images) using Integrated Scanning, with Toshiba V3 devices. In some circumstances this can impact overall Application Server performance. This does appear to be only impacting Toshiba V3 devices when using Integrated Scanning with very large scans.

We're actively investigating this.

Workaround:

We have discovered that this issue only happens when debug mode is enabled on the Application Server. As a temporary workaround while we investigate a full fix, we recommend switching off debug mode (in the PaperCut MF admin console > Options > Advanced > then ensure that "Enable debug mode" is unchecked.

Please note that this has now been resolved in version 24.0.4.

The User web interface (the new non-default version) shows a blank page after login.

The new user web interface (with limited functionality) is not enabled by default. When using version 22.0.11 or later, the user is presented with a blank page after logging in.

Important: the original (default) user web interface is not impacted by this issue.

Please note that this has now been resolved in the 22.1.1 release.

The Print Deploy Clone on macOS may incorrectly clone an IPP Print Queue with missing data if the IPP endpoint (CUPS or PaperCut Mobility Print) is unavailable during cloning.

This will cause the printer to fail to install on a Print Deploy Client machine.

Workaround: Ensure the IPP endpoint is available during cloning.

You can find a similar log entry in the

pc-print-deploy-client.log
 of: 

Failed to install printer Print-Deploy-Mobility: printer connection type  is not supported. valid values: [mobilityprint, directprint, serverprint] {"src":"pdservice.go:653"}
The Print Deploy will release a fix for this shortly.

                  

The Print Deploy Server in some cases may configure the Direct Print Monitor with an empty ApplicationServer address value, or an address that is unresolvable from the Print Deploy Clients. This may cause Direct Printing Find-Me printing setups to stop working, or otherwise cause jobs submitted to these Direct Print queues to not be logged.

WORKAROUND:

Please manually configure the correct Application Server address under Enable Printing -> Print Deploy -> Settings -> Direct Print options, which is resolvable from your client machine, remembering to Save the change towards the bottom of the page.

UPDATE May 15th 2023: This has been resolved in version 1.7.2336 of Print Deploy.

When the user navigates from Device functions back to PaperCut MF Home page, the user is automatically logged out of PaperCut MF. PaperCut has released a new Kyocera HyPAS embedded application (v3.2.4) that resolves this issue. Please contact our support team to obtain this version.

Please note that this has been resolved in PaperCut MF version 22.1.2

Multiple personal account issue:

When a refund is made, the refund is credited to the personal default account instead of the personal account that was originally charged.

We're actively investigating this issue, so if you believe you've encountered it please reach out via our support portal and quote PO-1345.

Please note that this has now been resolved in PaperCut MF/NG version 22.1.3.

PaperCut versions prior to 20.1.7, 21.2.11 and 22.0.9 are vulnerable to a serious security exploit and should be patched immediately. All customers should update to the latest version of PaperCut as soon as possible.

Further information is available here.

Issue reported in 1.7.2307 Print Deploy Server version and Windows v1588 Print Deploy Client version.

The Print Deploy Client will display Navigation to webpage was cancelled or Can't reach this page. The PaperCut Print Deploy Client logs will show Service stopped with exit code 1 and Restarting service (crash count: n) along with ERR Failed to create env version file updater: no evn version contained

We're actively investigating this issue, so if you believe you've encountered it please reach out via our support portal and quote PD-1640.

UPDATE May 15th 2023: This has been resolved in version 1.7.2336 of Print Deploy.

Changes to the Direct Print Monitor (DPM) in these versions seems to have resulted in some Print Deploy Clients mistakenly registering non-PaperCut, local printers with the application server.

These printers will appear in the Printers pane, in the following form:

pd-client\printerName

The client machines may then not be able to print to these local printers.

We're actively investigating this issue, so if you believe you've encountered it please reach out via our support portal and quote PD-1638.

UPDATE May 15th 2023: This has been resolved in version 1.7.2336 of Print Deploy.

Some locations are reporting instances of pc-client.exe crashing under certain circumstances. All locations thus far have confirmed the anti virus software in use is Java based which is involved with the crash.

We are investigating the issue and will update with details as we understand the issue in greater depth - including the exact circumstances where the client could crash.

Windows will report Application Error event 1000 in Windows Logs / Application.

A quick solution for a small number of workstations is to running the application in Windows 8 Compatibility Mode as we work to resolve this issue.

Alternatively, if account selection is the primary use of PC-Client, configuring the users to "Automatically charge to a single shared account" may also be an option.

One advanced solution if the PaperCut Client is starting from a share on the server is to run these commands to edit the registry on each workstation:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "\\SERVER\PCClient\win\pc-client-local-cache.exe" /t REG_SZ /d WIN8RTM

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "\\SERVER\PCClient\win\pc-client.exe" /t REG_SZ /d WIN8RTM

Be sure to update the path with the fully-qualified domain name of your server!

This could impact:

• pc-release.exe
• pc-release-manager.exe
• pc-release-secure.exe
• pc-pay-station.exe
• pc-client.exe
• pc-client-java.exe
• db-tools.exe
• server-command.exe
• create-ssl-keystore.exe
• sharp-configuration-tool.exe
• and others.
  
  
  Please note that this has now been resolved in the 22.1.1 release.

We have found that when performing the "Configure SmartSDK Connection" on the ROC Tool with the effected versions, the task may fail with the following error:

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Workaround(s):
We have had reports toggling HTTPS to OFF for the device works without issue.
OR
Please use the 1.4.2 ROC Tool.

Solution:
We are currently working on a new version of the Tool to be released with an upcoming MF release.

Please note that this has now been resolved in PaperCut MF version 22.1.2

Chromebooks may fail to discover Print Deploy printers on the latest Print Deploy release. The main indicator of this is the following Chrome console message:
TypeError: Cannot read properties of undefined (reading 'includes')

With the v1.7.2302 release, the Print Deploy Client crashes when it has been installed without the Direct Print Monitor (SKIP_DPM).

When using some Canon Type 4 drivers on printers, you will be unable to redirect print job between queues if they both use these Canon Type 4 drivers. E.g. from a hold/release queue to an output queue.

After receiving the auto-update to Version 1.1.30 (2 Mar, 2023) on their Doc Proc server customers are reporting a noticeable increase in their scan file sizes.

Description:When the control panel times out during an active copy/job scan job, a “4011” error shows on the screen. This occurs while performing large copy or scan jobs on Toshiba MDS V3+ devices.

Workaround:Toshiba has introduced two new settings Background Copy and Background Scan which is disabled by default. These settings need to be enabled in order to resolve the issue.

1. Log in to the MFP web interface (TopAccess) with your web browser as the “Admin” user.
2. Select the Administration tab > select Setup tab
3. Under Functions, set the Background Copy option to Enable
4. Set Background Scan option to Enable
5. Save the settings

When using the i-Option KM Embedded on MF, changes to the ‘ext-device.konica-minolta.id-number-button.label’ config key has no effect on the App display.

The account selection option and pending print jobs are not displayed after logging in on outlined models.

We are looking into this issue and are currently looking to resolve this issue in v22.0.11.

Workaround:
Some customers encountering the issue have reported a temporary workaround by configuring these devices with the Automatically release jobs upon login setting under Devices > [select device] > Print Release (please see configuring secure print release in the manual for more info).

The other option you have is to downgrade your PaperCut MF Application server and devices back down to v22.0.7 in the interim but please be aware you will be vulnerable to the following security issues by not being on v22.0.9.

Please note: this has now been resolved in version 22.0.11.

The readme.txt file for batch-devices.csv is not up to date with the latest device name changes.

Please edit as follows when building a batch-devices.csv file for deploying Fuji devices:

The following lines need to be removed (lines 93-94):

FUJIFILM:

FujiFilm Business

The following lines need to be added:

FUJIFILM_V7:

Fujifilm BI AIP 7+

FUJIFILM_SFP:

Fujifilm BI AIP 7+ (Printer only)

Please note that this has been resolved in PaperCut MF version 22.0.10.

Also known as PIE-709
When connecting a Secondary Universal Print connector to the Primary App Server, the auth token for Universal Printer will not work if it begins with an "a". Capitalisation will make no difference.

For example - The auth token set to "PaperCut" will work, but "aPaperCut" will fail.

You will see the following in the Secondary Log - Failed to subscribe to primary connector: 401 Unauthorized

The Primary UP logs will show - ERR authorizationMiddleware.go:30 Unauthorized request

Workaround - Change the auth token to have anything other than an "a" as the first character.

Optional Printers in Print Deploy are some times not reinstalled when a user moves between zones.

The Print Deploy development team are aware of this issue and are working on a fix.

If a scan fails during the process of being written to the device storage medium (e.g. SD card is full or otherwise unwritable), the scan will fail but the message 'ScanPrompt.sending' will be displayed to the user instead of the correct message 'ScanProgress.failSave'.

Workaround

This can be prevented from occurring again by unplugging and initializing the SD card storage, or by using an SD card with a larger storage capacity.

If the Recipients field of a Scheduled Report is empty and the Copy button is pressed, the report copy will not have all of the attributes visible.

When copying a Scheduled report, ensure that the Recipients field is not empty.

Toshiba have added a Confidentiality setting to their devices which masks usernames in the Toshiba job logs. In some regions, this setting, Log Data Privacy Setting is set to Not to store by default. When this is set to Not to store, PaperCut MF is unable track user-level usage for all device job types (print, scan, fax, copy) since the username cannot be determined.

Workaround: Set Log Data Privacy Setting to Store

1. Log in to the MFP web interface (TopAccess) with your web browser as the “Admin” user.
2. Select the Administration tab > select Setup tab
3. Under Confidentiality Setting, set the Log Data Privacy Setting option to Store
4. Save the settings.

To fix a problem with no one knowing the randomly generated ID PIN for self-registering internal users, we have made some changes. ID PINs not picked by the users themselves, if/when sent through emails, will be in clear text instead of being masked by ****. A new constraint also becomes effective on the Options > User/Group Sync page with regard to internal users.

This fix has brought about some minor changes on the Options > User/Group Sync page. The problem we will address in the 22.0.9 release, is when end users are allowed to self-register as internal users, IF the admin had set up the system to auto generate ID PINs, there was no way for the end user or admin to know what the PIN was, because the PIN is masked by `****` in their email as well as on the post-registration screen.

We've therefore implemented a fix to reveal the ID PINs that was auto-generated as clear text in the emails that are delivered to users. This brought about the necessity for email notifications. We've therefore added one constraint on the Options > User/Group Sync page that if all three are true:
1. Internal users are enabled.
2. User can self-register.
3. ID PINs are randomly generated by system as opposed to self-chosen.

... then both of these boxes must be ticked:
1. User must enter an email address.
2. Also send email confirmation to the user.

Should the first 3 conditions be met and either of the 2 boxes mentioned is not ticked, the page will not save, and will show an error. This is to ensure that when the 3 conditions are met, we can always notify the user of their ID PIN.

Please note that the method admins use to add internal users is not affected. Admins can continue to add internal users without providing an email address, because the admins have to input a PIN value while creating internal users. If they choose to, they can inform end users of their ID PINs in different ways, e.g. separate email or in-person verification process.

Due to this new constraint, we also changed the default value of "Also email confirmation to the user" box to be ticked, as "User must enter an email address" is already by default on. This does not affect the settings of old installs. The constraint will NOT apply to pre-existing configurations. It only applies when you try to change any settings on the Options > User/Group Sync page because that is when the validation processes run again.

For more information, see the kb: Options User Group Sync Change in 22.0.9.

IP-SUBNET filters are being detected as IP-RANGEs and including too many IP addresses.

Workaround: Print Deploy administrators can reliably use CIDR notation when using IP based filters.

More detail: Print Deploy supports multiple filters on Zones, restricting what printers are applied to a client. This includes IP based filters.

Print Deploy administrators may use IP-CIDR, IP-RANGE and IP-SUBNET filters.

Due to an issue in detecting the use of a SUBNET vs RANGE, a client may receive more printers than expected due to the SUBNET being detected as a RANGE.

Example: 10.0.0.0-255.255.255.0 includes all IPs from 10.0.0.0 to 255.255.254.255 and thus would incorrectly match 192.168.12.33.

In the 'Enable Printing > Mobile & BYOD > Common Mobile Printing Options' section of the NG/MF admin interface, changes made to the 'When a job arrives from an unknown email address' setting are not saved successfully (even though it indicates it is) - after saving, and then refreshing/revisiting the page, the setting is reverted.
(This issue is also known as PO-1134)

Please note that this has now been resolved in PaperCut version 22.0.9.

Problem: Sharp introduced the secondary switch button on the operation panel in Sharp CR5s. After doing a power cycle using that switch (power off and then wake up), user is unable to login to PaperCut MF by swiping their card. This is only happening with unregistered card readers and while powering off/on using the secondary switch on the panel. Other authentication methods work in this scenario. This is not an issue when a power-cycle of the machine is done using the main power switch.

Sharp is currently working on getting a firmware released to fix this issue.

Workaround: It is recommended to register the card reader as this issue only occurs with unregistered card readers.

There is a regression in 22.0.8 which is causing all PDF scan jobs to be delivered in PDF/A format. This effects both On-Prem and Cloud Document Processing services.

After upgrading to 22.0.8 the ‘Sign in with Microsoft’ button no longer works for logging in to the User or Admin web interfaces when the ‘Import disabled users’ option is disabled on the Azure sync settings. You can still login with username/password on these pages though, it’s only SSO that won’t work. WORKAROUND: Don’t use SSO - login with username/password. Enable the ‘Import disabled users’ option on the Azure sync settings - although this will potentially import a large number of unwanted user accounts into the database.

Authorize.net does not provide full support for Unicode characters in user names.

This can result in payments made via Authorize.net failing if the user's name includes unsupported Unicode characters. Unsupported characters include the 'é' character used in the French language.

UPDATE: The default for "ext-device.block-release-on-error.paper-out-using-trays" key will be changed to "no" in 22.0.9.

This configuration key was added in 22.0.8, and we have seen some confusion around how this key works & what it is for. Hopefully this Known Issue will clear things up.

Before you read this, please make sure you have read Step 3 in the Manual .

Reason for this additional config key:

Before this key, the global “noPaper” value was not honoured by a large number of OEMs. The addition of the new key enables the “noPaper” value to work on the vast majority of devices, regardless of OEM. The ongoing exceptions are Brother and Epson devices. During our testing these devices do not return the “noPaper” command we use with either key.

So with this key added, we now provide the same outcome to the “noPaper” value for most devices, creating a common outcome across all devices.

In fact, with this key, we now offer a wider range of variables for all OEMs, from only blocking release when all trays with a particular tray size are out (all_size), to blocking release when all trays are out of paper (all).

Default setting:

The decision was made to set the default key to “any”, so that it would match the original “noPaper” default setting. This setting blocks release when any of the trays is out of paper.
We understand that due to the increase in devices now supporting this configuration, that this level of tray detection may be leading to understandable confusion.

We currently have a tracking number for changing the default configuration to “no”, which would effectively disable this configuration key and require manually setting one of the other options explained in the manual. Please log a ticket with PaperCut Support and quote “PIE-219” if you wish to see us change this. Please let us know if you would prefer the default to be set to “all”, so that we only block release when all trays are out of paper. Update: Please see top of Known Issue.

Further notes:

This new configuration key is not retroactively added after upgrading to 22.0.8. However if no key is present in 22.0.8, we will assume the default value of “any”. Remember that “noPaper” still needs to be enabled for this to be honoured.

In the past, Xerox devices required an extra flag for the default key of “inputTrayEmpty”. If the new key is being used, this is no longer required as the “noPaper” command will be honoured. The manual will be updated to reflect this change (PIE-220)

“noPaper” MUST be set in “ext-device.block-release-on-error.snmp-error-list” for the new configuration key to be used in any capacity. This is the top level trigger for tray detection. Consider the new key an extension of the “noPaper” command.

Note that this key is now defaulted to "no" in 22.0.9

When installing PaperCut NG/MF 22.0.8 for the first time there is a possibility that the Print Deploy Server service does not start properly.

A coffee cup is shown instead.

Workaround: Restart the PaperCut Print Deploy Server service.

You can confirm you are experincing this specific issue by confirming these two entries in the PaperCut Print Deploy Server logs: pc-print-deploy.log

During startup: 2023/01/25 09:30:10 pc-print-deploy-server.exe: STDOUT|ERROR: failed to read C:\Program Files\PaperCut MF\server\data\internal-api-key.dat: open C:\Program Files\PaperCut MF\server\data\internal-api-key.dat: The system cannot find the file specified. {"src":"authmf.go:32"}

When viewing the Print Deploy Server admin interface: 2023/01/25 09:31:46 pc-print-deploy-server.exe: STDOUT|ERROR: AdminAPIAuth: error: authorization key provided for this request is invalid {"src":"verification.go:20"}

The Print Deploy team are aware of this and will update this KB article when there is a fix available.

Please note that this has now been resolved in PaperCut version 22.0.9.

We are finding with some customers who have MF Application servers using NG/MF's High Availability feature, that MFDs can show this error message on their touch screens when a failover to a new Application Server node happens:

Unexpected error communicating with the server java.io.IOException: An unexpected network error occurred

This doesn't appear to be specific to any MFD manufacturer and we have so far seen this on HP, Ricoh and Lexmark devices.

Initial investigations appear to point at the .mapdb files used on shared storage between the MF HA clustered nodes as the probable cause.

We have reports of errors with HP legacy FututreSmart copiers after upgrading to 22.0.8.

The copiers will fail to start, and show errors on the Device Details page of the PaperCut Admin UI.

We are investigating, but in the meantime advise customers with legacy FutureSmart copiers to remain on 22.0.7 or earlier.

Please note that this has now been resolved in PaperCut version 22.0.9.

We have reports of an issue after upgrading to 22.0.8. Devices fail to complete integration, and show a StackOverflowError message in the logs. This has been observed on C8170 and C8135 copiers.

Please note that this has now been resolved in PaperCut version 22.0.9.

(Since renamed to PO-1205)

Since version 22.0.8, modifying child/sub accounts with batch import, server command, or API fails with error expecting EOF, found ')'.

This only happens if you are importing/updating sub-accounts. If you're only importing/updating Parent accounts, this works successfully.

Another way the problem can manifest is if child/sub accounts are in use, and you attempt to set one of these accounts as a default shared account for a user, or configure a user to automatically charge to one of these accounts. If a user was already configured to automatically charge to a child/sub account, or had a child/sub account as their default account, prior to upgrading to 22.0.8, attempting to modify any attribute for that user will also result in this error.

If a user attempts to use Web Cashier to charge items to a child/sub account, the problem will also occur.

Workaround: for now, adding the child/sub-accounts manually through the user interface (Accounts > Actions > Create new account) is the only workaround for the import issue.

For the user details issue, there is no workaround besides not configuring the use of child/sub accounts.

For the Web Cashier issue, there is also no workaround.

Update 17th Jan 2023: there is now a hotfix available for this issue if needed. Please quote PO-1205 when contacting us to ask for it - thank you!

We'll also be looking to resolve this issue officially in an upcoming release.

Please note that this has now been resolved in PaperCut version 22.0.9.

After upgrading to 22.0.8 you may experience a regular (but intermittent) ‘Pre-authorization required’ error message appear on Konica MFDs, when using swipe card login.

This does not seem to effect any other form of login method - only swipe cards.

Workaround: In lieu of migrating to an alternative login method (E.g ID or username/password), the only known workaround is to downgrade the PaperCut MF server to the previous version.

Update 17th Jan 2023: A further workaround is to set the key ext-device.konica-minolta.browser.enable-fast-login-flow to N which disables the faster login flow. As a result, the login time may be slightly increased, however the issue with the pre-authorization error message will disappear. Please see the 'PaperCut MF - Konica Minolta i-Option Embedded Manual' for more information about setting that key.

In the meantime we are working on a fix for the fast-login-flow option.

Please note that this has now been resolved in PaperCut version 22.0.9.

When running older versions of the Application Server with newer versions of the Print Provider (22.0.8 or later) you may see an error in the App Server debug logs: Print provider 10.3.33.172 was denied access to the application server as it is running a newer, incompatible, version 107.1.0.4602-1B73A92.

In the 22.0.8 release we introduced a feature which allows newer versions of the Print Provider to communicate with older versions of the Application Server (ref PC-18655).

This means that you can for example be running a 20.x.x version of the Application Server, and run the Print Provider from 22.0.8 or later on your secondary servers. This will work fine as per the enhancement in the release note, however you may see this red-herring alert in your Application Server debug logs. This can be safely ignored (as long as the Print Provider is reporting jobs to the Application Server correctly and appears to be working ok).

(Also known as PIE-295)

In NG/MF version 22.0.8 we released a feature (PIE-40) which enables the Print Provider on CUPS servers to keep track of all currently held print jobs during a server reboot. This feature is not switched on by default.

Previously, the jobs being held during a server reboot would be 'lost' (they wouldn't be printed or tracked). Note that this impacted CUPS servers only (not Windows).

With version 22.0.8, this feature can be enabled by adding the job persistence config key JobHoldPersistence=on into the print-provider.conf file. From version 22.0.10 (under change PIE-294) this config key will be added to the print-provider.conf file, but will be set to OFF by default.

We will be looking to switch this on by default in a future version - this change is tracked by PO-1199/PIE-295.

Enabling the feature

Manually add the following line to the print-provider.conf file and restart the Print Provider:
JobHoldPersistence=on

Important note: Version 22.0.8 contains an issue that in some cases could cause unreleased print jobs to be released when the server is restarted. This issue (tracked as PIE-226) has been fixed in the 22.0.9 release.

End users running macOS Ventura (beta at the time of writing) will be presented with a "Background Items Added" popup when the PaperCut NG/MF Print Deploy Client is installed to their machine.

This is an inbuilt feature of the new version of the macOS operating system. macOS Administrators can hide all messages of this type by using existing 3rd party MDM tools to manage com.apple.notificationsettings settings.

PaperCut Mobility Print queues cloned, not imported, by Print Deploy are being deployed with the CUPS configuration of authinforequired username,password in error.

PaperCut Mobility Print queues do not require the use of authinforequired.

macOS users will be presented with an operating system level prompt to enter a username and password, preventing normal printing operations.

This has been resolved in 1.7.2234 (Dec 20 2022).

Newer versions of Adobe Acrobat Reader may fail to process PDF jobs on a Web Print Sandbox server. We're still investigating, but for now the admin can elect to use Xpdf to process PDF jobs instead, to sidestep the issue. In an elevated Notepad session, open the following file on the Sandbox server:

[app-path]\providers\web-print\[platform]\web-print.conf

Add the following line to the end of the file:

options.pdf=xpdf

Save the file and close/open the application, then confirm PDF job submissions work without issue. If you believe you've encountered this issue, please reach out through our support portal and quote reference PIE-208.

Please note that this has now been resolved in PaperCut version 22.0.9.

Held print jobs which are not in PCL6 or PostScript format may no longer be tracked when the PaperCut Print Provider service is restarted. Text, PCL5c, XPS, and ZPL are known spool file formats which are not tracked in this scenario.

Please note that this will only impact print jobs which are being held (e.g. in a hold/release queue) at the time that the Print Provider Service (or the server) is restarted.

Workaround: When a PCL6 or PostScript driver for your printer is available, use that driver instead.

Please note: this has now been resolved in PaperCut version 22.0.8

Print Deploy Users with a username that end in a "mime type" (e.g. "john.ma") and use either a Domain/Directory joined machine or "Sign in with Google" may experience issues with the Print Deploy Client intermittently showing a "This is awkward." error message.

This is caused by an API call to the PaperCut NG/MF Application Server not returning expected data.

The Print Deploy team are aware of this issue and will release a fix, independent of a PaperCut NG/MF change, shortly

When configuring a device as a Release Station (Print Release at an MFD), print queues may appear under the wrong heading. This does not impact the functionality of hold/release queues, and does not happen if you have not recently changed the type of print queue in use.

For example, if you configure a print queue with 'Enable hold/release queue' and then head into Devices > [select device] > Summary > Print Release > Enable print release. You will see the printer appear successfully under the 'Physical with Hold/Release' or 'Virtual with Hold/Release' sections of the list.

If you then go back and update the print queue to uncheck 'Enable hold/release queue' and then head into the same device setting, the printer should appear under the 'No Hold/Release' section. Instead it mistakenly appears under the original 'Physical with Hold/Release' or 'Virtual with Hold/Release' section.


This can be fixed by restarting the Application Server - however we believe this will only be seen if customers are making regular changes to the hold/release properties of a queue. This will not impact any of the hold/release functionality or find-me functionality.

Please note that this has now been resolved in PaperCut version 22.0.9.

The default URLs in use within our RBS Worldpay payment gateway are outdated.
In order to utilise the updated version with the correct addresses, please download the latest version, which can be found here https://www.papercut.com/kb/Main/SettingupthePaymentGateway#step-2-download-and-install-the-payment-gateway-module
If required you can follow the instructions for installing the payment gateway module here https://www.papercut.com/support/payment-gateway-guides/

When attempting to run the Print Deploy Cloner on macOS Ventura the following error will be displayed

"PaperCut Print Deploy Cloner.command" can't be opened because (null) is not allowed to open documents in Terminal.

Workaround 1: Mount the DMG and run the Cloner directly from Finder:

1. Navigate to /Volumes/PaperCut\ Print\ Deploy\ Cloner
2. Right click on PaperCut\ Print\ Deploy\ Cloner and select "Show package contents"
3. Navigate to Contents/MacOS/
4. Double click PaperCut\ Print\ Deploy\ Cloner.command

Workaround 2: Mount the DMG and run the Cloner directly from the Terminal:

/Volumes/PaperCut\ Print\ Deploy\ Cloner/PaperCut\ Print\ Deploy\ Cloner.app/Contents/MacOS/PaperCut\ Print\ Deploy\ Cloner.command ; exit

The Print Deploy team are monitoring this issue and believe an update of macOS may fix this issue. We are also investigating changes to the macOS Print Deploy Cloner to support this change in macOS Ventura

When selecting Gmail OAuth2 for Email to Print and filling out the client ID and client secret fields, the Authorize Via Google button is misaligned. When the button is pressed, the application does not navigate to the Google authentication page.

When configuring Fujifilm devices with ext-device.fujifilm.login.id-field.numeric set to Y, the regular device keyboard is displayed on screen instead of the expected numeric keypad

Please note: this has now been resolved in version 22.0.11.

When setting up a Toshiba MDS V3+ device with PaperCut MF, when running firmware version 17.0.0 or later, the device may fail to connect to PaperCut with error: This is not a Toshiba device or it was not registered successfully. This is due to a new REST endpoint service that has been added in the latest firmware, and causes the device registration to fail.

Workaround:

Disable the REST endpoint on the device. This will not have any side-effects on the functionality of the device.

1. Log in to the MFP web interface (TopAccess) with your web browser as the “Admin” user.
2. Select the Administration tab > select Setup tab > select ODCA section.
3. Under REST, set the Enable Port option to Disable
4. Save the settings.

We have also updated the Toshiba MDS V3 Embedded manual with this information (see section 2.4.16).

When you are attempting to configure your Devices to utilize new queues for Print Release. You are unable to see the newly created queues until you restart the PaperCut Application Server.

It has recently come to our attention that some customers cannot use Email to Print function with Microsoft Office 365 / Exchange mail servers due to traffic throttling. The manifestation of the problem can be:

• The service works for a while and then stops
• Logs showing email fetching failures, sometimes the logs will explicitly say this is due to throttling, and usually after that, we will get a different type of exception FolderClosedException, causing the input stream reading process to fail;
• Sometimes the failure point is at attempts to delete emails after fetching. Deletion is also part of the IMAP/POP3 functionality.

For more information, please see Recent Issues with IMAP or POP3 for Microsoft Exchange Mail Servers.

Upgrading your existing server from 22.0.4 or earlier, to 22.0.5 or later will generate the following message on the screens of all existing Fujifilm Business devices:

This is not a Fuji Xerox device or was not registered correctly.

This is due to the changes made for Fujifilm Business devices, documented in the 22.0.5 release notes.

IMPORTANT: Please read the Upgrading PaperCut MF to 22.0.5 with an existing Fujifilm Business device fleet article for more information.

Please note that further changes have been made in 22.0.7 which make this process easier. Please see details in the FujiFilm upgrade article above for more information.

When using Sharp CR5 devices and card authentication, users may be taken back to the login screen after logging in. This can look as though the device briefly logs in the user, then immediately logs the user back out.

This only happens with card authentication (username/password or ID number authentication are not impacted), and does not happen with all CR5 devices - some are not impacted at all, and others display this login issue.

We are actively working with Sharp Australia and Sharp Japan to resolve this issue with the highest priority.

Please note: This has now been resolved in PaperCut version 22.0.8.

When a native copy, scan or fax job is performed on a Fujifilm device and no account selection has been made, the logged in user will be returned to the PaperCut login screen.

WORKAROUND - Select an account on the PaperCut account selection screen before pressing the device home button

While using Integrated Scanning on a Fujifilm device, if a user's balance reaches zero and is subsequently topped up with additional funds while remaining logged into the device, the user will not be able to perform additional Integrated scans. Users must log out of the device, then log in to the device again to see their balance updated

A payment gateway integration for Moneris Checkout was introduced in version 22.0.229 of the payment gateway module.

This new integration currently works with versions 21 and higher of PaperCut MF/NG, but attempting to use it with versions 19 and 20 will result in an error similar to the following:

Unable to invoke method formSubmit on ext.paymentgateway.pages.ExtnMonerisCheckout$Enhance_22@1f76794b[ExtnMonerisCheckout]: null

We have a hot-fix build available on request, please contact support and quote PO-1047.

The environment value in configuration file should be “prod” not “pro”

"Unknown license status" warning appears on the "About" tab when you have less than 20 days of M&S Support remaining.

We are working on a fix - in the meantime printing / tracking / copying / faxing / scanning should all continue to work without issues.

If you see this error and you are experiencing issues making configuration changes (e.g. adding Print Deploy zones) please reach out to the Customer Care team through support.papercut.com. Otherwise all other functionality should continue to work without issues.

Please note: This has now been resolved in the 22.0.6 release.

Users receive an error No data type for node: org.hibernate.hql.ast.tree.MethodNode when trying to run the Executive Summary report (Reports > User > Executive Summary) or looking at Printer Statistics (Printers -> [select printer] -> Statistics). This looks to only be an issue if an external database (specifically SQL Server or Postgres confirmed so far) is in use.

Other reports run successfully.

Update: This looks to impact customers using SQL Server and Postgres. MySQL and Derby (internal) databases do not appear to be impacted.

Please note: This has now been resolved in the 22.0.6 release.

There is currently a problem affecting Email to Print authentication using Google OAuth2 client IF the MF server runs on port 80 (http) or 443 (https), instead of 9191 or 9192. This bug does not happen when any other ports are used, so long as they are not 80 or 443. Hot fix will be provided to affected customers and the simple fix will be added to future releases.

Please note: This has now been resolved in the 22.0.6 release.

If you are running Print Deploy Server v1.7.2184 and if the Print Deploy server is on a Windows server, and if you have macOS Clients, printer installations on those macOS clients will fail.

The Print Deploy team will be releasing a fix for this issue as soon as possible.

From version v1.7.2177, if you clone new printers, then driver and capability files from previously cloned printers are deleted from the repository for that operating system.
The previously cloned printers will fail to install on end user devices. Printers that are already installed will keep working.

Recovery steps:
If you have a recent backup after upgrading to v1.7.2177 or later and before you recloned, you can copy back the contents of the following directories.
~\providers\print-deploy\win\data\repository\drivers\[os]
~\providers\print-deploy\win\data\repository\capabilities\[os]

If your backups are from older versions of Print Deploy prior to v1.7.2177, then reach out to our support team at https://www.papercut.com/support/#papercut-mf and we’ll help you recover by reverting back to an older version.

From version v1.7.2177, if a SysAdmin has cloned print queues from reference machines running different macOS versions, print queues that have been cloned from reference machines running older macOS versions will fail to get installed in the client.

Workaround:
Browse to ~\providers\print-deploy\win\data\repository\drivers\mac\ and if you see multiple subdirectories in there, copy the contents of each subdirectory to the latest one.
For example, if you have two subdirectories, 10.14-amd64, 12.5-amd6, then copy the files from 10.14-amd64 to 12.5-amd64.

In some cases, the Print Deploy server fails to start after upgrading to version 1.7.2177. This occurs when there are old print queues in the Print Deploy Server with missing driver files or driver capabilities (.cap) files.

Please contact Support if you believe you've been affected by this issue.

After upgrade Admin users are not able to access the Help menu item; this page includes the customer support id, customer reference number, technical support contact information, and sales and solutions contact information. This is due to an erroneous permission added to the menu item which does not show in the access options list. Consequently these users will also show as having 'limited access' when all access options are granted.

Note that this has now been resolved in our 22.0.5 release.

After MacOS Mojave, when changing the default ArchiveDir setting in the PaperCut Print Provider, Print Archiving feature no longer works. The Print Provider application is unable to create new folders in a location other than under the initial application path.

We are finding that some Ricoh device's with the Smart Operations Panel are ignoring the 'System Auto Reset Timer' of the device, and the user will remain logged in indefinitely.

WORKAROUND - Currently downgrading the embedded to 3.0.2 will rectify the issue.

Please note that this has now been resolved in PaperCut version 22.0.9.

In PaperCut MF 22.0.3 support for Sharp CR5 Atlas and Titan models are missing. We are working on it to include it in the next release.

In the meantime, you can stay in PaperCut MF 22.0.2 or use this https://www.papercut.com/kb/Main/SharpCR5AtlasTitanwithMF#workaround-details

In PaperCut NG and MF 22.0.3, setting up a Google Cloud Directory user sync source will fail because the Google certificate import step fails with the following error:

The certificate failed to import. No changes were made.

Any Google Cloud Directory sync sources that were already set up using a PaperCut version prior to 22.0.3 will continue to work.

In order to resolve this issue, please follow the instructions below specific for your operating system.

Windows or Linux

Add the following line to the \custom\service.conf file:

wrapper.java.additional.8=-Dkeystore.pkcs12.legacy

After saving the file, restart the application server and confirm that you can now import the certificate.

MacOS

Add the following line to the \custom\launch-app-server.conf file:

PC_CUSTOM_SERVER_ARG=-Dkeystore.pkcs12.legacy

After saving the file, restart the application server and confirm that you can now import the certificate.

Customers have reported that since upgrading to Windows 10, when the PaperCut client (pc-client.exe) is started from a network share, users will not see the expected Toast notification "Print system message. Your attention is required." and instead see a vague message "new notification". Running the locally-installed version of the PaperCut Client works fine however.

Some Ricoh IMC devices embedded with SmartSDK app version 3.1 or greater display "java.uitl.Arraylist cannot be cast to java.lang.Boolean".

The current workaround is to utilize an older version of the SmartSDK application until this issue is resolved in an upcoming Maintenance Release.

Note that this has now been resolved in our 22.0.5 release.

Since version 21.2.10, when performing a new installation of PaperCut NG/MF, the print-and-device.script.enabled key is set to N by default. This means that scripting is disabled by default. This is expected behavior.

However, there should be a warning message that appears on the scripting page (e.g. under Devices > [select a device] > Scripting, or Printers > [select a printer] > Scripting), which tells the admin that scripting has been disabled, and links to instructions on how to enable scripting.

In version 22.0.0 and later this warning message is missing, so the scripting page just shows a blank page.

Workaround:

Enable scripting as described in the Enabling Print Scripting and Device Scripting KB.


Please note that this has now been resolved with our 22.0.3 release.

New Lexmark Firmware MXTGW.081.205 causes PaperCut embedded application to no longer function and causing a web front end Device Configuration page error. Affected models reported on so far is CX825 and MX722. Resolution is to downgrade the firmware on the device. Issue currently open with Lexmark and they are investigating.

With the release of new Sharp CR5 Atlas and Titan Models there is a change of the built-in browser type to the chromium browser. Due to this change, full embedded support for Sharp CR5 Atlas and Titan models won’t be available until an upcoming Maintenance Release (MR) for PaperCut MF.

Please see the Sharp CR5 Atlas and Titan bulletin for more information, and workarounds.

Please note that this has now been resolved with our 22.0.2 release.

The Print Deploy client is not correctly setting default printers based on the Zone configuration. Users may need to manually set their own default if required.

If a scan action is using Document Processing (e.g. OCR, batch splitting, blank page removal, despeckle, deskew) the output is always PDF/A - even if the Convert to PDF/A checkbox is unchecked.

The checkbox can be found in Devices > Scan Actions > [select a scan action] > Details > Output settings > File type > PDF > Convert to PDF/A. If the scan action is using a document processing feature as detailed above, the checkbox will not impact the output file type.

We are hoping to fix this in a future maintenance release.

Workarounds: the only ways around this currently are:

• Use the device's native scanning function.
• Do not enable any of the document processing features for that scan action.

Side note: If you happen to be using the preview-release version 22.0.0, you'll find that the checkbox does actually work succesfully - and if you uncheck the Convert to PDF/A box you will receive a 'regular' PDF instead. This is not the case with 22.0.1 and 22.0.2, where the output will continue to be PDF/A in the circumstances above.

Update: This issue has been resolved in version 22.0.3 of PaperCut MF. After updating to version 22.0.3, existing scan actions from previous PaperCut MF versions that have any of document processing features enabled will now have the PDF/A box ticked. If the checkbox is subsequently unticked, the checkbox will now function as expected, and deliver the job as PDF instead of PDF/A.

Windows Print Deploy Clients that are left logged out (e.g. after a restart) will display an error page to end users saying "Can't reach this page".

This is caused by the computer being left at the login screen for too long and the Print Deploy Client stopping.

Please upgrade to Print Deploy server version 1.6.2096 and Print Deploy Client version v1484 to rectify this issue.

Users who have not authenticated to the PaperCut Print Deploy Client previously may not be shown a popup prompting for authentication.

Workaround: Users may still right click the Print Deploy Client in the taskbar / system tray and access their printers via "View My Printers" and follow the authentication prompts there.

Some Kyocera devices do not support mixed size scanning when they are set to an "inch" region (such as US). The current known work around is for your technician to set the device region to a metric region.

The following TASKalfa devices are affected: 8002i, 7002i, 6002i, 5002i, 4002i, 3511i, 3011i, 8052i, 7052i, 6052ci, 5052ci, 4052ci, 3552ci, 3252ci, 2552ci, Ecosys MA5500

Note that this has been resolved in version 23.0.0, under CDSS-1865.

iPrint OES2018 SP3 servers running PaperCut will experience issues with print job redirection due to an iPrint update - the known issues prevents Printer Redirection and Hardware checks.

We have a hotfix Print Provider available to fix this issue, and this updated Print Provider will be included in a future public release.

Please note that this has now been resolved with our 22.0.3 release.

If the installation of a printer takes longer than expected, the Print Deploy Client may show to the user that the printer failed to install correctly even though the user can see the printer in their printer list when printing and printing works as expected.

The Print Deploy team will be releasing a fix for this issue as soon as possible.

If there are optional printers in the Print Deploy Client printer list, after installing optional printers the printer disappears from the printers list as expected but the total number of printers doesn't get updated and remains the same.

Note: This was partially resolved in version 21.2.6 and later under PO-710, but there have been additional cases found (when using certain drivers or when "raw printing" such as can be used with Samba printing when clients are doing the rendering) where this bug will happen even in these fixed versions.

Recent changes to Print Provider may cause print jobs with a number of copies (n) greater than 1 to be printed with n2 copies (number of copies multiplied by number of copies).

This behaviour was introduced in version 21.2.0 and only impacts the Print Provider when using Linux and macOS. The number of copies reported in PaperCut NG/MF will show the original number requested, but the actual number of copies printed will be n2.

Update: This has now been resolved in version 22.0.0 (available in the public release of 22.0.1).

(also known as PO-971)

When using Azure standard sync, the Card ID / Office / Department may not sync if you have selected 'import users from selected groups'.

We have identified an issue where the Card ID, Office and Department will not sync correctly (those fields will not be populated correctly in PaperCut MF/NG) if 'Import users from selected groups' is selected.

Workaround

Use the 'Import all users' option instead, which will then correctly populate the additional fields when the next sync happens (ensure that the config key user-source.update-user-details-card-id is set to Y).

Please note: this was incorrectly advertised that it was resolved in 22.0.8. This is not the case, but we are hoping to have this fixed in a future release.

Please note that this has now been resolved in PaperCut version 22.0.9.

Due to an unfortunate incident with our build system, the latest release of PaperCut NG and MF (21.2.6) contains log4j 2.17.0 binaries instead of 2.17.1.

We are working on a build to be released asap which will include log4j 2.17.1 and the fixes from 21.2.6.

In the meantime rolling back to 21.2.5 will restore the binaries for log4j 2.17.1, but without the fixes included in 21.2.6.

This has now been resolved in the 21.2.7 release, which contains the fixes from 21.2.6 and also log4j 2.17.1.

Convert to PDF/A conversion failing in certain circumstances.

Workaround
Enable deskew, despeckle or any of the blank page Document Processing operations and PDF/A will apply to the scanned document.

Upcoming Fix
A change within an upcoming version of Doc Proc will properly listen to the PDF/A flag and apply it correctly.

When using the Azure AD Sync with PaperCut, users may receive error AADSTS50126 when logging in.

This may happen if Federated Authentication is in use for that account - since PaperCut does not currently support Federated accounts for login with username/password where a browser is not in use. For example this may work when the user is logging into the User web interface through a browser, but may not work when the user is logging in with user/password authentication at a copier/device.

We have also seen some customers working around this in their environment using steps similar to these (external site): https://medium.com/@amanmcse/ropc-username-password-flow-fails-with-aadsts50126-invalid-username-or-password-for-federated-90c666b4808d

Recent changes to Print Provider may cause print jobs with a number of copies (n) greater than 1 to be printed with n² copies (number of copies multiplied by number of copies). This behaviour was introduced in version 21.2.0, 21.2.1, 21.2.3 and 21.2.4 and only impacts Print Provider when using Linux and Mac. The number of copies reported in PaperCut NG/MF will show the original number requested, but the actual number of copies printed will be n².

Please note that this has now been resolved in PaperCut NG and MF version 21.2.6.

Note: if you have applied the latest fix in 21.2.6 or later, and you're still experiencing this issue, you may be experiencing the specific case identified in PC-18730. We hope to have that additional issue resolved shortly.

A vulnerability was discovered (originally in 2019) in the SocketServer functionality of Log4j. This has been documented officially on the NIST site here: CVE-2019-17571

This vulnerability requires the Apache Log4j component to be configured to listen for logging events on a socket. PaperCut Products do not use this feature of Log4j and as such the vulnerability CVE-2019-17571 does not affect PaperCut Products.

Please also note that this is unrelated to the much-publicised RCE vulnerability in log engine dependency Log4j (CVE-2021-44228) - which is documented in our other Known Issue for CVE-2021-44228.

PaperCut NG and MF have a dependency on the open source logging module log4j2.

A vulnerability has recently been discovered in log4j2 that may allow arbitrary code in logged strings to be executed. See here for details: https://www.lunasec.io/docs/blog/log4j-zero-day/. This vulnerability is sometimes called Log4Shell or LogJam, and defined in CVE-2021-44228.

Please note that only versions 21.0 and later are impacted. Versions 20 and earlier are NOT impacted by this.

Update 13th December

We have published a KB with more information about this Log4j vulnerability.

We are also hoping to have a maintenance release out shortly with a more permanent fix - however we highly recommend the configuration change above in the interim.

Update 14th December

The KB has been updated with a list of FAQs and confirmed impact on the User Client and Release Stations: PaperCut Log4j vulnerability information.

Update 15th December

A maintenance release version 21.2.3 is now publicly available which includes Apache log4j 2.16, and addresses CVE-2021–44228 and CVE-2021–45046

Update 21st December

A maintenance release version 21.2.4 is now publicly available which includes Apache log4j 2.17, and addresses CVE-2021–44228, CVE-2021–45046 and CVE-2021–45105

When enabling the "Sign in with Google" authentication option for Print Deploy an error can be seen in the Print Deploy server logs (pc-print-deploy.log) and authentication via Google will not work. 2021/11/12 17:52:44 pc-print-deploy-server.exe: STDOUT|ERROR: ServerErrorLog: http2: panic serving 10.0.0.51:51402: runtime error: invalid memory address or nil pointer dereference

Workaround: Restarting the PaperCut Print Deploy server service resolves this issue.

When using the Azure AD (standard) sync with version 21.2 or later, users can log in with username and password. However, 2FA/MFA is not currently supported for user logins.

Ensure that your security policy within the MS tenancy does not enforce 2FA on the PaperCut app (note that this doesn’t mean that you have to disable 2FA globally). If you are applying policies or conditional access at the machine level, it’s the PaperCut App Server that you’ll need to exclude from 2FA enforcement - not the devices that the users are logging into.

If you do have 2FA/MFA enabled in a policy which includes your PaperCut Application server, then users may see Error AADSTS50076 or AADSTS50079 when trying to log in through the web interface, at the device or through the user client.

Workaround

We currently recommend disabling 2FA/MFA (only) for the PaperCut Application Server app (or the PaperCut app server device if you're applying conditional policies at the machine level). This means that for 'other' login scenarios, users will still need to enter their MFA codes.

See Step 7 of the Preparing to use UPN usernames with PaperCut when synching with the standard Azure AD sync method guide for more information.

Update in version 23.0.1 and later

There is additional support for MFA in version 23.0.1 and later - see Overview of synchronizing user and group details with Entra ID (Azure AD) for more information. While this Known Issue is now 'resolved' since this release, the errors listed may still occur if using unsupported functionality (e.g. logging into an MFD interface using username/password when MFA is enabled). See Deciding which sync option is right for you for more info on which options are supported with MFA.

When using Print Deploy, the cloner tool will not run on macOS Monterey (12.0) or later. The app will fail with the error Unexpected Apple Disk Image filename.

Note that this was resolved in Print Deploy version 1.5.1947

If you:

1. Are using the standard Azure AD sync.
2. Have the config key user-source.update-user-details-card-id set to Y because you're synching the EmployeeID field from Azure into the Primary Card ID field in PaperCut.
3. Check the 'Auto generate random primary card ID number when blank' box under the Azure AD user/group sync options.

You'll notice that the checkbox gets unchecked when the page reloads. This is because in the background that checkbox is conflicting with the config key option to sync the field from Azure AD. You'll need to choose between either synching that primary field with Azure (keep the config key set to Y, but do not check the 'Auto generate random primary card ID number' checkbox), or not synching with Azure and instead using the auto-generated number (use the opposite settings).

One side effect of this is an edge case where you are synching your users for the first time. In this case if you perform the steps above and a brand new user is created in PaperCut, the user will initially have an auto-generated primary card ID number, even if they also have a valid EmployeeID in Azure. However at the next scheduled sync, because the checkbox to auto-generate the number will have been unchecked by the system, it will then correctly pull in the EmployeeID from Azure.

We're looking to get this resolved in a future release - but in the meantime as long as you don't set the conflicting values, it should behave as expected. It's also worth noting that the Secondary card number options are not impacted by this, since there is no curent option to sync the secondary card number with Azure AD.

When scanning using the Lexmark eSF app version 3.1.1, if you scan 30 pages or more the app will crash with Firmware Error [500.00] Profile "PaperCut Scan-to-Email" failed to stop before timeout.

Workaround
Increase the Lexmark device 'Screen Timeout'
Settings => Device => Screen Timeout
Our path is Settings => Device => Screen Timeout
Increase the Screen Timeout.300 seconds is the maximum possible.

Please note that this has been fixed in PaperCut MF/NG version 22.1.4.

Scan Actions which are saving as .DOCX files are currently creating files which are documents of images of the scan and that appear as password protected, rather than the expected text document.

When on version 21.1.2 and using the Print Provider's method to hide document names, customers may see that jobs sent for release are incorrectly pausing in the release / target queue, or jobs may be double-charged.

Case 1: If all of the following are true:

1. Using PaperCut version 21.1.2
2. Account selection is enabled for the user(s)
3. Document names are being hidden, specifically using the HideDocumentNames=on flag in the print-provider.conf file as documented on the Hide Document Names KB.

Then users may see jobs get 'stuck' in the target queue (the release queue) when trying to release their print job from a find-me / virtual queue. In the target print queue the job will show as 'paused'.

Case 2: If all of the following are true:

1. Using PaperCut version 21.1.2
2. Account selection is NOT enabled for the user(s)
3. Document names are being hidden, specifically using the HideDocumentNames=on flag in the print-provider.conf file as documented on the Hide Document Names KB.

Then users will not see any impact to releasing their jobs, however jobs redirected from a find-me queue / virtual queue to the target queue will be incorrectly double-charged and incorrectly show two entries in the job log.

Workarounds:

• Downgrade PaperCut to version 21.1.1
• Where possible (if your requirements and environment allow), switch over to using the Windows Server method to hide document names as detailed on the Hide Document Names KB.

We have withdrawn version 21.1.2 while this issue is worked on, and we hope to have a 21.1.3 release in early November which will resolve this issue.

We have discovered that in the latest round of security updates from Microsoft - specifically KB5006670 or KB5006672 - network printing can break for customers printing from workstations to server print queues. This can include new connection failures with error code '0x00000709'.

There are lots of sources of information on the internet surrounding Microsoft's latest changes, including Windows 10 KB5006670 update breaks network printing. Microsoft have also issued a Known Issue, however in our testing the impact appears to be a lot wider than only IPP printing.

Workarounds:

We have not been able to find any documentation or tips from other customers on an 'easy workaround' for this latest security update. Uninstalling the patch is obviously one non-recommended temporary solution here - but others include:

• Use an alternative method of network printing, e.g. using an LPD service and printing over LPR instead of using SMB. Find out more about that on our Using LPD with PaperCut article.
• Use PaperCut's Mobility Print solution to print from any device types, to shared Windows queues.
• Uninstall the October Windows Security updates.

Apologies that we don't have more information on this latest MS security update at this point, but we will post any more information as soon as we have it.

Update (22nd October):

We are working with Microsoft through a case on their Partner Portal on this issue and hoping for more news shortly.
(Please note that the workarounds above still apply in the meantime while we wait to hear any updates from Microsoft - at the moment we are relying on MS to resolve the issues with OS-level client > server printing. Our current recommendations for workarounds include using Mobility Print to bypass the issues introduced with these latest Microsoft security fixes).

Update (27th October):

Guidance from Microsoft to (specifically) help any customers seeing the 0x709 printer connection error, includes the requirement to open TCP/IP Ports needed by RPC, Remote Procedure Call. See Microsoft's article here.

Update (11 November):

We have reports that the specific TCP/IP Port for RPC which needs to be open is 135. Blocking port 135 results in error 0x6e4 when adding a connection to a shared printer.

Final update (22 November): Microsoft has released optional update KB5007253 to resolve this issue. Addresses a known issue that causes error codes 0x000006e4, 0x0000007c, or 0x00000709 when connecting to a remote printer that is shared on a Windows print server. Further details can be found at support.microsoft.com

#printnightmare

UPDATE:
There is no longer an indication that libappindicator support will be removed from Debian based Linux distributions. Original issue:

The Debian 11 Linux distribution has deprecated libappindicator packages which includes libappindicator3-1, a package required for the Print Deploy Client to interact with users.

PaperCut will migrate to another library as soon as possible.

Customers have reported success in installing the .deb packages manually. Please consult with your IT support whether this is an appropriate action for your environment.

When using Batch Splitting feature (separating large documents into separate scan files), the original document order is not retained. This issue is present in both Cloud on On-Prem Document Processing.

Please note that this has been resolved with version 21.2.5.

User PIN authentication will not work with Toshiba V2 MFDs from PaperCut MF v20.1.0 onwards. This is because PaperCut MF now stores all PINs in a one-way hash format in the MF database. (PC-17476)

On the Toshiba V2 platform, the device performs a PIN comparison and it cannot do a comparison on an already encrypted string. Toshiba V3+ devices are unaffected.

Workaround:
Please contact the PaperCut Support Team prior to any upgrade to v20.1.0 to receive a hotfix build and upgrade instructions to help circumvent this issue if you use PIN authentication or still have Toshiba V2 devices actively in your environment. We would recommend to take a back-up of your MF database and PIN codes prior to your upgrade.

Please note that this has now been resolved in PaperCut NG and MF version 21.2.6.

Note that you will need to set the config key "user.card.pin.hash-encode" to "N" if you are using the PaperCut Toshiba V2 and use PINs for login, to prevent user PINs from being hash encoded.

When trying to search on usernames within Web Cashier, the type ahead search functionality has stopped working since upgrading to 21.1.1 (or 20.1.4 or 19.2.5).

Workaround
Within the same browser session, login to both the administrator portal and the web cashier portal and the username search functionality will work. (Workaround is only applicable if the web cashier user has PaperCut administrator privileges).

Please note that this has been resolved with version 21.2.5.

Sept 2021 Microsoft Windows Security Update breaks Cross-server redirection.

We have discovered the September 14th 2021 Microsoft Windows Security Update KB5005568 can break cross-server redirection in Windows Server 2019 and Windows Server 2012. This issue can affect the redirection of print jobs from one server to another.

This issue can be identified by searching for entries within the Print Provider log(s) referencing Error: 283 & Error: 317

The Print Provider logs are found within: [app-path]\providers\print\[platform]\print-provider.log*​

Sample log entries
ERROR: PrinterRedirect.cpp:311 - Failed to redirect job to printer (StartDocPrinter). JobId: 99, Datatype: RAW, Printer: \\ExampleServer-01\Printer01 - Error: 283 [****]

2021-09-17 12:00:00,633 ERROR: PrinterRedirect.cpp:515 - Failed to redirect job to printer \\ExampleServer-01\Printer01 - The system cannot find message text for message number 0x (Error: 317) [*****]

PaperCut is working with Microsoft to try and find a workaround for this ongoing issue.

We have had reports of customers resolving this issue by:

• Uninstalling the KB5005568 patch from the server (not recommended).

Further workaround:

An additional temporary workaround is listed below, which allows customers to install the security fix. As detailed on the Microsoft KB, one temporary alternative to get printing working again is (on the Windows Print Server) to:

1. Add a new registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled (type DWORD)
2. Set the new key value to 0.
3. Restart the Print Spooler service.

This should allow cross-server redirection to work as before.

#printnightmare

We have heard reports of some customers experiencing error 0x0000011b when printing from Windows clients to Windows servers after applying the recent security updates from Microsoft.

We believe this is due to a protocol change which has been in Windows 10 since January but the recent updates now require that both client and server be able to use this new communication protocol method and error 0x0000011b is the result when there is a mismatch.

We have had reports of customers resolving this (and have tested ourselves with success) by:

• Uninstalling the patch from the server (not recommended).
• Ensuring that the patches are applied to the Server and the clients.

Other alternatives include using PaperCut's Mobility Print solution.

Further workaround:

An additional temporary workaround is listed below, which allows customers to install the security fix. As detailed on the Microsoft KB, one temporary alternative to get printing working again is (on the Windows Print Server) to:

1. Add a new registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled (type DWORD)
2. Set the new key value to 0.
3. Restart the Print Spooler service.

This should allow printing from Windows clients to the Windows server as before.

Note: these updates have also all been rolled up into the 'December' updates from Microsoft - so if you had previously not installed updates, and have now installed the December updates, you may see issues as a result of this.

Our most recent recommendations are:

• Use an alternative method of network printing, e.g. using an LPD service and printing over LPR instead of using SMB. Find out more about that on our Using LPD with PaperCut article.
• Use PaperCut's Mobility Print solution to print to shared Windows queues from any device types.

#printnightmare

We have discovered that the September Microsoft updates (including KB5005568 for Windows Server 2019) will break macOS to Windows printing when using SMB.

It's useful to note for troubleshooting purposes that this will be an issue whether environments are using PaperCut or not.

In our testing (and as found by a handful of customers so far) we have found that if a Windows print queue is shared over the network, and macOS devices are printing via SMB connections, printing will break after installing the September security patches on the server.

Workarounds: The only workarounds that we are aware of currently are:

• Use an alternative method of network printing, e.g. using an LPD service and printing over LPR instead of using SMB. Find out more about that on our Using LPD with PaperCut article.
• Use PaperCut's Mobility Print solution to print to shared Windows queues from any device types.

The updates associated with this include: KB5005568 (Windows Server 2019), KB5005613 (Windows Server 2012 R2), KB5005627 (Windows Server 2012 R2), KB5005623 (Windows Server 2012), KB5005607 (Windows Server 2012), KB5005606 (Windows Server 2008), KB5005618 (Windows Server 2008), KB5005565 (Windows 10 2004, 20H2, and 21H1), KB5005566 (Windows 10 1909), KB5005615 (Windows 7 Windows Server 2008 R2)

Update Feb 2022

We have seen rumors that Apple have fixed this with the latest Monterey versions (detailed here - specifically "Resolves an issue that prevented authenticating to a Windows print server with increased RPC authentication level"). However our testing internally has shown that this doesn't have any impact, and as far as we can tell, printing between macOS and Windows over SMB is still broken. We have also tested using a suggestion being floated on discussion boards on the internet, which suggest adding ?encryption=no to the connection string e.g. smb://printserver/print_queue?encryption=no will work. We have found that this does not resolve the issue either in our own testing.

We have also seen customers who have been successfully printing from macOS to Windows over SMB (despite having installed the security patches from last year) who are now suddently experiencing issues with the latest macOS Monterey releases.

Our recommendations remain at this point, to:

• Use an alternative method of network printing, e.g. using an LPD service and printing over LPR instead of using SMB. Find out more about that on our Using LPD with PaperCut article.
• Use PaperCut's Mobility Print solution to print to shared Windows queues from any device types.

Update October 2023

With macOS Sonoma now released (macOS 14), we are seeing further issues when printing macOS > Windows over SMB which can result in printers going into a Waiting state indefinitely. You might initially see them go into a Hold for Authentication state - if you click refresh and supply valid credentials, you will end up in the Waiting state. This is again something that happens with or without PaperCut involvement in the mix. There is a reddit thread where others have noticed this same behavior too.

Our recommendations remain at this point, to:

• Use an alternative method of network printing, e.g. using an LPD service and printing over LPR instead of using SMB. Find out more about that on our Using LPD with PaperCut article.
• Use PaperCut's Mobility Print solution to print to shared Windows queues from any device types.

Update March 2024

Early reports suggest Apple has fixed this behaviour in macOS Sonoma 14.4, and that printing via SMB from a macOS device to a Windows hosted print queue should now work.

#printnightmare

Current code requires HSTS to be enabled for SNI checking to be disabled. This can possibly manifest in various ways, including loss of ability for PaperCut embedded devices to communicate when configured with FQDN instead of IP address.

This has now been resolved in the 21.2.1 release.

When a admin user logs in to PaperCut and attempts to upload a PDF or other file to Web Print they may see an error message that says "server responded with 401 code" or ”server responded with 0 code". As far as we know this only affects admin users, and the simple solution confirmed by several customers is to open Options, click on the Admin Rights tab, and then remove and re-add the user or Group that has been assigned admin rights. It may also be necessary to clear the browsers cache before testing again.

PaperCut NG & PaperCut MF customers deploying multiple PaperCut Mobility Print queues via Print Deploy may experience an issue where end users are prompted to re-authenticate or log-in again on queues previously authenticated. We are investigating this issue as a priority.

On Toshiba V2 and V3 embedded devices, the Job Status button which is displayed on the Print Release page is no longer visible. This button is used to allow the user to see, for example, if there is an error on the printer such as a Paper Jam or No Paper using Toshiba's own graphical page.

The button is missing due to a bug in the processing of the EWB (Embedded Web Browser) version which has changed from a 3 component version number to a 4 component version number. This check was done in order to hide the button on older versions of the EWB which doesn't support this feature.

Workaround:

A workaround for this issue is to set an Advanced Device Configuration variable of ext-device.toshiba.show-job-status-button to the value of "ALWAYS" which will cause it to bypass the EWB version number check.

We have found cases where users see an error 'cannot connect to server' when trying to access the device functions, or starting a scan when using Toshiba devices with the PaperCut V3 app. Some users see this only intermittently and others may see this consistently.

Workaround

In troubleshooting these issues with Toshiba, we've discovered that this is related to DNS lookups done when unlocking the device.

The workaround is to head into Top Access > SMTP Authentication, and either switch the authentication to 'Plain' instead of 'Auto' - or switch it off entirely if not required.

The PaperCut Print Deploy Cloner does not correctly copy defaults and capabilities of PaperCut Mobility Print queues when cloning.

Capabilities and Defaults are settings like monochrome vs colour/color, duplex vs simple and device configurations such as stapling, multiple input trays.

Following the installation of Windows updates including KB5005652, released on the 10th August 2021. Non-administrator users may see a dialog with the message Do you trust this printer? when trying to install a printer (either through non PaperCut-related methods, or through e.g. PaperCut Print Deploy).

When the user selects 'Install driver', any non-admin user will then be presented with a error message Connect to printer - Windows cannot connect to the printer. This is due to the update documented on Microsoft's article - KB5005652 - Manage new Point and Print default driver installation behavior.

Workaround

We recommend using the workaround listed under the "Modify the default driver installation behavior using a registry key" section of 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:

1. 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.
2. 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.

Note: If you’d prefer to get away from Windows > Windows printing connections entirely, an alternative here is to use OPTION 2 - Enable Point and Print without admin rights in our PrintNightmare guide.

#printnightmare

We have heard initial reports from a few customers using Xerox Versalink devices, that copying and scanning fails with "error communicating to the job limits server" or "Can't communicate with authentication server".

This is impacting 21.0.3 or later.

Altalink devices do not appear to be affected. Print release and other functions work successfully, however scanning and copying may fail.

Workarounds:

• Disabling scan and copy tracking has also reported to resolve the issue, however this comes with obvious consequences.
• Partners have also confirmed that setting the advanced key ext-device.xerox.enable-preauth to N will also resolve the issue - however again that will have consequences on zero-stop and potentially allow users to run into negative balance.
• Rolling back to 21.0.2 or earlier will also resolve the issue.

We now have a hot fix available for this - please contact us with your CRN and quote PO-448 as well as any additional details that you would normally include.

Important note:

This has now been released publicly in version 21.2.1 (and is also included in 21.2.3 and 21.2.4).

However, we have spotted one case where this may not be resolved - we are looking to make additional fixes (for e.g. the VersaLink B405) under PO-707.

New Scan to Fax actions are not able to be created in 21.0.4 due to the 'Fax Server Settings' section missing from the interface.

Any previously created Scan to Fax actions will continue to work without any issues, and the Fax Server Settings will be retained. It is only new Scan to Fax actions that cannot be created.

We are aiming to resolve this in the next public release, and we do have a hot fix / manual workaround in the meantime if required. Please contact us and quote PC-18553. Thanks!

We have found that a small subset of HP devices (which we have yet to fully qualify/confirm) can get stuck on device integration when using PaperCut version 21.0.1 or later. The symptoms are that within the PaperCut admin interface, the device status shows that the integration never completes (.e.g. 'integration in progress'), and there may also be an error message on the MFD screen with Sign-in failed: The device is not available to use. Please try again in a few minutes.

We have been unable to recreate this with any of the devices in our lab, however there may be a pattern that the impacted devices are of a lower spec.

Please note that this has now been resolved in 21.1.2

We have renamed our app from 'Scans for PaperCut MF' to 'Scans for PaperCut'. No other changes have been made to the app, however any users who have performed a scan to Google Drive scan action prior to 9th July, 2021 may now see a message in the Google 'Security Checkup' page (within your Google account settings) flagging the app. The message may ask the user to 'Remove risky access to your data', and may display 'Scans for PaperCut' as an app which is from an unverified developer.

Please note that our verification status as a developer with Google has not changed, however following the app rename, the old app will now show as unverified. We are working with Google to see if they can re-verify the 'old' app, which would remove the security checkup flag.

Importantly, please note that scans to Google Drive for those users who verified the app prior to 9th July will not be impacted - scans will continue to be delivered without any issues.

Users who have verified the Scans for PaperCut app since the 9th July will also not be impacted by this, and additionally will not see any Security Checkup flags.

Workaround: Users who wish to resolve the security checkup flag can safely use the 'revoke access' button next to the app in the Security Checkup section to remove the app from the list. The next time the user performs a Scan to Google Drive action, they will receive the 'Authorization' email which they will need to perform once to give the new app access to their Google Drive (as they did when they performed their first scan to Google Drive). By authorizing the 'new' version of the app, this will then appear in the list as a verified app, and will not be flagged for action. This is not a requirement however - any users still using the old version of the app will not be impacted at all.

On the About page, the number of currently used devices in Licensed devices is unchanged, but the number of currently used devices in Advanced Experience Fax Devices is increased 1.

null

XM Cloud connection for Scan to Fax will return a Success message, even when testing with an incorrect token.

As of PaperCut NG/MF 21.0.3, when clicking the "Test Settings" button on the User/Group Sync page, you may see the following error message:

An ERROR occurred testing settings:Write operations are not allowed in read-only mode (FlushMode.MANUAL): Turn your Session into FlushMode.COMMIT/AUTO or remove 'readOnly' marker from transaction definition.

This only happens when clicking the "Test Settings" button, and not during an actual sync.

It is HIGHLY RECOMMENDED that you restart the PaperCut Application Server service after receiving this error and do not then perform a test sync. In our testing we have found that the test sync is still attempting to complete in the background, taking up more resources, and could eventually bring down the Application Server due to lack of resources.

Please note that the 'real' sync (and scheduled syncs) will still work as intended.

Update: This has now been resolved in the 21.0.4 release.

In version 21, we introduced the ability to login to the user and admin web interfaces pages using a "Sign in with Microsoft" button. The login workflow may ask the user to provide consent on behalf of their organization (if they are an admin in Azure AD), or request consent from an admin before being able to login (if they are a regular user in Azure AD). If permissions for the APIs in use have been granted by an admin in the Azure Portal for the application registration created during the setup process, these prompts should not appear. Presently, there is an issue where these prompts continue to appear.

Please note: This has now been resolved in version 21.1.1

When printing an Adobe document in B&W via a virtual printer using the PaperCut Global Driver, the print job is printed in Color and logged in Color through the output print queue which has a model specific manufacturer driver.

This does not affect direct printing, or printing via a virtual printer with a model specific (or Universal OEM) driver. It can be a challenge to use a model specific (or Universal OEM) driver in mixed fleets though, due to driver compatibility between manufacturers.

The recognized workarounds for this are:

1. Tick "Print in grayscale" option within Adobe DC
2. Use a model specific (or Universal OEM) driver on the virtual printer - if there is a mixed fleet of printer manufacturers, it might also be necessary to use a PDL Transform to ensure that this solution works successfully.

We are actively investigating this issue with a number of live customers.

Update Wednesday June 16th (AEST): Some customers have reported that restarting the Windows Print Spooler (and PaperCut Direct Print Monitor) on affected client machines has resolved this issue.

A root cause has yet to be found but if you're of the belief that you're having a similar issue you can try running through the following steps and submit a ticket to the Support Team. If you can record these troubleshooting steps with a screen recorder, it would be highly advantageous to us.

We need to know if the following troubleshooting steps work whilst the Print Deploy Client (Windows) is failing at the same time and from the same client.

• Click Start -> Run
• Type in in the server name, e.g. \\printserver.company.lan\ in the exact format of the printer you're trying to install (save a screenshot of what is input in before clicking OK.)
• If the previous step succeeds, double click the desired printer. (Save a screenshot of the printer having opened.)
• If the previous step succeeds, we need a copy of the usercontextservice.log and pc-print-deploy-client.log files showing from that machine and a screenshot showing that the above three steps worked.

Two alternative troubleshooting commands:

• PowerShell: Add-Printer -ConnectionName \\printServer\printerName
• cmd.exe: rundll32 printui.dll,PrintUIEntry /in /n \\printServer\printerName

Workaround:

Ensure that you're running Print Deploy version 1.5.1805 (or above) and then:

1. Add the line Features=["powershell"] to the client.conf.toml file on the Print Deploy server.
   For locations on PaperCut 23 and greater, this setting must be above the [PollingConfig] section of client.conf.toml.
   1. Restart the Print Deploy Server service.

   Please note that this has now been resolved in Print Deploy version 1.5.1876.

When using Print Deploy to deploy Mobility Print queues, the users may see a 'sign in to print' button and be prompted for credentials. Entering credentials does not add the printer(s).

In the app server debug logs, you will see a message similar to:

ERROR PrintJobAuthorizationController - Request rate '10/s'exceeded from: 127.0.0.1

Application Server does not start successfully when using an external database running MySQL 8.0.23 or above.

Error displayed in the PaperCut Admin console is:

class java.time.LocalDateTime cannot be cast to class java.lang.String (java.time.LocalDateTime and java.lang.String are in module java.base of loader 'bootstrap')

This is believed to be the issue called out on the MySQL bug listing here: https://bugs.mysql.com/bug.php?id=102435

We are currently investigating, and working on getting a patch available to resolve this issue.

Workaround: for now, please roll back to MySQL versions 8.0.22 or below.

Update: This has now been resolved in the 21.0.4 release.

PaperCut NG/MF has a 50 character limit on usernames, usernames over this limit will not be imported. This limit applies regardless of sync source and will especially impact customers using e.g. G-suite or Azure AD with UPNs, where usernames are more likely to be longer than 50 characters.

If a PaperCut Print Deploy server's Client Authentication method is set to AUTO or TRUST then PaperCut Mobility Print queues will fail to operate properly.

Depending on your client operating system, the behaviour exhibits differently:

• Microsoft Windows: the print queue fails to install
• macOS: queues install but any attempt to print results in the queue being deleted and re-installed

As a work around, Print Deploy Administrators can change the authentication method to PROMPT

A fix is being made ready.

Due to the presence of a "v" in the version field for the Print Deploy Client .deb package, the installation of the client may fail.

A new Print Deploy Client will be released shortly.

In very rare circumstances when using HP FutureSmart4 devices and Site Servers with unreliable networks, devices can go unresponsive.

We have found an issue that caused frequent re-integrations of devices on Site Servers, when network connection to the main server is poor.

This has now been resolved in our 21.0.3 release.

If a Print Deploy user logs in via an alias (e.g. "bob" and their real username is "bobcitizen") and a Print Deploy administrator has configured a Zone to have a Group Based filter, user Bob will not meet that filter's requirements.

As a work around, Print Deploy user Bob will need to log in with their non aliased username.

We will update this Known Issue when this is resolved.

Customers report that when users of the Chrome app enter their username and password to authenticate they see the correct list of printers, but if they click the "Sign-in with Google" button zero printers are returned. It has been determined that this only happens if the Zones in Print Deploy are assigned to Groups, rather than IP address range.

Users may notice that PaperCut Mobility Print queues that they elect to install via the Self Service functionality in PaperCut Print Deploy will fail to install.

This is confirmed by noting the following entry in the "pc-print-deploy-client.log"

Below is an example Windows PaperCut Print Deploy client logfile extract.

2021/03/15 18:06:05 pc-print-deploy-client.exe: STDOUT|ERR InstallPrinter: failed to install printer FOLLOW-ME with error: failed to install printer: unknown error: exit status 1. output: pc-printer-updater version 1.0.0.727-2f0cd118b2481cf114198311b563001c8b112b50
2021/03/15 18:06:05 pc-print-deploy-client.exe: STDOUT|please specify connection name for mobility queue
2021/03/15 18:06:05 pc-print-deploy-client.exe: STDOUT|Command installprn failed. Error: Input argument validation failed.
2021/03/15 18:06:05 pc-print-deploy-client.exe: STDOUT| {"src":"pdservice.go:406"}

As a work around, PaperCut Print Deploy administrators may change the printer to be no longer Optional and the printer will then be installed correctly.

The PaperCut Print Deploy team is working on a fix for this.

Sometimes during installation of an HP OXP copier with PaperCut MF, the PaperCut icon configuration may fail, resulting in blank purple squares appearing instead of the expected icons. The issue only occurs in some cases and is not consistent. We are investigating and will provide a fix in a future release. The workaround should this occur with a current release is to unregister the device from PaperCut and re-register it.

PaperCut 20.1.3 added a parameter - sendStringParametersAsUnicode=false - to the default connection string provided in the server.properties template file for SQL Server databases. This parameter increases query performance, but in cases where a username contains Unicode characters that are not available in the configured locale on the database server, it may cause failures to set or find those usernames. The change will not affect upgrades to existing installs, as the server.properties file is not overwritten during an upgrade. It is recommended that installs to new sites using SQL Server databases remove the parameter from the connection string, unless they are certain that they will not be affected. The parameter will be removed from the template in a future release.

Note that this has now been resolved in 20.1.3

Installations that make use of the "Sign in with Google" authentication method for PaperCut Print Deploy and deploy PaperCut Mobility Print queues may fail to install.

This impacts installations using PaperCut Mobility Print server version 1.0.3103.

An updated PaperCut Mobility Print server has been released to address this issue.

Affected versions:
Print Deploy Server: 1.5.1598
Mobility Print Server: 1.0.3103

Resolved versions:
Print Deploy Server: 1.5.1598
Mobility Print Server: 1.0.3107

Since PaperCut 20.0.2, the PaperCut server is not always able to reliably identify the originating address of an incoming request from a desktop Client.

This may cause issues, especially in environments with load balancers or other network components that may mask the originating IP.

Symptoms may include:

• Users apparently unable to log in
• More client session threads needed than with previous versions.
• In extreme cases the server could exhaust the reservoir of threads reserved for client sessions and all client operations will stop functioning.
• This log line should be seen throughout the server.log file when the problem occurs: "ERROR BaseXMLRPCServlet:259 - Error occurred processing XMLRPC request for: client-xmlrpc. System overload: Maximum number of concurrent requests (15960) exceeded"

It is recommended that sites using desktop clients with PaperCut 20.0.2 or later always set client.use-ip-reported-by-client = Y in order to avoid potential problems.

We've had reports of some customers seeing blank images instead of the proper custom product images / thumbnails when using Job Ticketing. This happens both in the admin interface and the customer interface.

Reports are mainly coming from Chrome users who have reported other browsers (e.g. Firefox and Edge) working fine, but other browsers may be impacted too.

We're actively investigating.

Page analysis discrepancies can happen for duplex print jobs with an odd number of pages where the last page is color.

If you have configured different costs for duplex grayscale pages vs duplex color pages there will be a cost discrepancy for those specific jobs (duplex print jobs with an odd number of pages where the last page is color).

If however you are charging the same for duplex grayscale pages and duplex color pages, costings will be correct.

NOTE: Page counting and cost analysis will not be impacted for any other jobs apart from the specific scenario above.

We have identified that the issue happens because the last page of an odd-numbered duplex job defaults to grayscale.We are currently investigating.

When printing in grayscale (by selecting grayscale when creating a print job or changing the print job setting at MFD), all released pages are blank.

If UserA installs an Optional Printer via the Print Deploy client, UserB (and subsequent users) who also have the same Optional Printer will not see the Printer Listed in the Print Deploy Client. However, the Optional Printer is installed to the operating system and UserB (and subsequent users) can print to the device.

We have found that HP OXP devices running 4.11 firmware will change the default sign in method to 'Local Device' after a change is made on the app server, after the device is rebooted, or sometimes just after a certain amount of time. This is only when using the PaperCut server-side setting of ext-device.hp_oxpd.permission.server-managed=N. Setting the default sign in method back to 'PaperCut' will work temporarily, but the default sign in method for the device returns to 'Local Device' later.

Devices which are managed by the server, using ext-device.hp_oxpd.permission.server-managed=Y do not appear to be impacted by this issue.

Workaround:

We are working with HP on determining changes in the 4.11 firmware which may be causing this - in the meantime we recommend downgrading devices to 4.10 firmware or earlier.

Update:

This has now been resolved in the 20.1.3 release.

The relatively new TASKalpha 408ci models are affected by an issue whereby the PaperCut functions from the PaperCut Home screen become unresponsive when selected. When the different functions are selected, they remain selected without responding to the desired action. All buttons available through the PaperCut embedded application become unresponsive.
408ci series devices are the only models affected by this issue. The PaperCut application nor the Kyocera embedded application versions relevant as the issue can be reproduced on multiple versions.

The workaround is to update the Eval firmware of your Kyocera 408ci series devices to v.01.02.0012 (2020-12-15)

If you have configured a Primary/Secondary sync source using either LDAP, Google Cloud Directory, or Azure AD Secure LDAP, less users may be returned during synchronization attempts in version 20.0.1 and above.

Specifically, this can occur when the Base DN, or your Google Cloud Identity domain name, does not match the User DN.

For example, for a Base DN of school.com, if a user has a User DN of the form student.school.com, PaperCut will no longer sync this user.

Similarly, for a Google Cloud Identity domain name of school.com, if a user is of the form student1@student.school.com, PaperCut will no longer sync this user.

If you believe you're encountering this issue, please contact PaperCut support and quote PC-17753, as a hot-fix build is available.

In summary:

• Application Server - will not run on macOS 11 (fixed in 20.1.1)
• Site Server - will not run on macOS 11 (fixed in 20.1.1)
• Print provider/secondary server - will pause all queues on macOS 11 (workaround available, and fixed in 20.1.1)
• User client software - works ok (when the app is copied from e.g. a Windows, macOS 10.x or Linux server to a laptop or PC running macOS 11).

There are two further issues found on macOS 11 while running the 20.1.1 build that we hope to resolve with a 20.1.2 release:

• Web print (when using the Application Server as the Web Print Server) will not work with macOS 11.
• User authentication to the admin or user web pages will not work for a local system user (using PAM). The local 'admin' account and any other directory sources will work ok.

For more detailed information see Known issues with macOS 11 (Big Sur)

Note: These issues have been resolved with the 20.1.1 release.

We have had some reports of some customers experiencing 'An internal error has occurred' error on Kyocera devices. This is also accompanied by an error in the logs: ERROR LocalPageServlet - java.lang.StackOverflowError at java.util.Collections$UnmodifiableMap$UnmodifiableEntrySet$1.next(Collections.java)

There is currently a hot fix available for this issue, and we are hoping to have this resolved in the public 20.1.3 release.

Please note that this was successfully resolved in 20.1.3.

Some printer queues may fail to deploy on macOS client machines with the following error: Stopped - 'Filter' failed.

This is caused by printer drivers having files and data in non-standard locations, or by using hard-coded locations for files.

Work is underway to support these environments.

Mobility Print queues imported via the Mobility Print import wizard in the Print Deploy admin console may fail to install on Windows client if the server is running on macOS or Linux. A Print Deploy client log will show an error similar to: 2020/10/27 16:13:24 pc-print-deploy-client.exe: STDOUT|CreateFile C:\Windows\TEMP\pd-driver-extracted[number]\pcglobal.inf: The system cannot find the file specified. Please contact support and reference PD-882 for a work around.

From PaperCut embedded versions 3.0.0 to 3.1.0, scanning to a USB drive locks up the MFD and eventually crashes the device with a firmware error.

A solution is forthcoming in the next embedded release.

The issue was introduced with the Integrated Scanning enhancement. If Integrated Scanning is not required, recommend downgrading to embedded version 2.10.0.

Copy jobs don’t stop after balance reaches $0. Balance goes into negative.

It has also been reported that Shared Accounts may not be charged correctly on some models (C7070 / C6570 / C5570 / C4570 / C3570 / C3070), but this has not yet been confirmed.

Affected models:
ApeosPort C7070 / C6570 / C5570 / C4570 / C3570 / C3070
ApeosPort 5570/4570

Update 13th October: We are working with Fuji Xerox to resolve these compatibility issues with the new devices.

Update 17th August 2023: this has been resolved in firmware versions 1.60.14 and later.

Lexmark LeSF - When duplex scanning via Integrated Scanning with Lexmark LeSF models. The device is flipping the 2nd page upside-down when scanning from the feeder (ADF).

When scanning from the glass, the incorrect rotation does not happen.

Fix is available - Please contact us if you need the updated Lexmark Embedded application.
Please request papercut-les21-3.1.0.fls and reference this known issue PC-17509 in your email.

Note that this will be resolved in the upcoming public release of 20.1.0, and LeSF App papercut-les21-3.1.0.fls

Canon Gen3+ self-association card registration error.
When users attempt to self-associate cards and their password contains a £$*&^% special character, the error Cannot use this Character is displayed within the password input text field on the Canon Gen3+ device screen.
This error stops the user from self-associating their card.

Note: This has now been resolved in a firmware update. Firmware Platform Version must include 3.13 or later.

Reports have included the inability to embed the device with PaperCut (installation appears to happen successfully, but the apps aren't installed), or the inability to scan with PaperCut.

Note that at this time this only appears to be impacting the new Altalink 81* series devices (e.g. B81* or C81* devices).

If you've come across other symptoms or if you've tried the below workarounds and it has / hasn't worked, either way, we'd love to hear from you - please send us a request, and mention PC-17688. Thank you!

Update 28-Sept: We are actively investigating these and working with Xerox for more information.

Update 2-Oct: So far we have had reports of B8145, B8170, C8155 all with issues embedding (the icons do not show up on the device) and C8155 (different customer reporting that embedding worked ok but integrated scanning did not work).

Update 6-Oct: Further investigations are ongoing with Xerox. They have suggested one additional workaround (for the icons-not-displaying issue) which we are exploring with them tomorrow (7th October): Enable all EIP Web Services options on the device web UI (Properties tab > General Setup > Extensible Service Setup > Extensible Service Registration > [Edit] > [Enable All] > [Save]).

Update 7-Oct: Successfully tested a B8145 and C8155 at the Xerox Lab.

Update 15-Oct: We are continuing investigations into reported issues with the 81* series devices, working with Xerox directly as well as with resellers. We have found that a large number of resellers are embedding these devices successfully (stepping through the Xerox manual exactly as written), without doing anything special - so our investigation is also looking at environmental and other variables involved in the installation process that could be causing issues for a small subset of environments.

Update 11-Nov: Checklist:

Most cases investigated so far have been resolved by:

• Making sure you're using PaperCut MF v 20.0.4 or later (which fixes an issue with scanning detailed in PC-17617).
• Make sure that the device time, and device timezone is set to the same time as the App Server time and timezone.
• Check that you're using the latest firmware (we've had reports of 111.009.000.27020 or later resolving issues).

Additional items to double check are:

1. Check the Device Status in the PaperCut Device Settings page - If it there is an error message referencing “IP Lockout”, or a message referencing authentication failure, then:
   • Make sure that the time and the timezone on the device matches the time and the timezone on the app server (and site server)
   • Make sure that the device admin credentials have been entered into PaperCut correctly.
   • If the message referenced “IP Lockout” then the device is currently blocking requests from PaperCut due to a prior authentication failure. You can try to clear the lockout - On the device, go to Apps -> Printing -> Printing Web Services -> Web Services IP lockout -> "Clear Lockout Button" - and try again, however there are reports that this does not always work, in which case you will need to wait for the lockout to expire, which it should do within 60 minutes.
2. Check the Device Status in the PaperCut Device Settings page - If there’s an error message referring to ‘verify that Xerox Network Accounting is installed and enabled’ then manually enable this through the device admin.
3. Reboot the device - it is possible that some configuration changes made during the registration process require a reboot before the change is actually complete. PaperCut should attempt to continue the registration following the reboot.

For customers specifically seeing ‘scanning failed’ issues with Integrated scanning. There are three things to check that we’ve seen so far:

• Enable all EIP Web Services options on the device web UI (Properties tab > General Setup > Extensible Service Setup > Extensible Service Registration > [Edit] > [Enable All] > [Save])
• On one customer device, “Allow Open Access to Job Information” on the device was Disabled, and it should be Enabled for scanning.
• There’s a ‘known scanning issue’ under PC-17617 - if you see a ‘scan failed’ message when using integrated scanning with PaperCut 20.0.3, this could be due to the Known Issue (fixed in 20.0.4 or workaround by enabling debug).

Update 26 May: Final update.

Successfully completed the Xerox self-validation process with PaperCut MF on 81* series devices. If you're experiencing issues similar to this, please confirm that you've checked all the items in the 'Checklist' section above.

Due to a limitation in some printer drivers on Windows, print jobs may fail due to the length of the auto-generated TCP/IP Printer Port name. This is resolved in version 1.4.1435.

We are investigating some scenarios where HP devices may be unable to contact the PaperCut server when the device is configured only to use DHE (Diffie Hellman) ciphers.

The message seen in this case will be related to SSLException: Could not generate DH keypair and subsequently DH key size must be multiple of 64, and can only range from 512 to 8192 (inclusive)

Note that when the device is configured to use alternative ciphers this issue does not exist, and SSL comms with the PaperCut server work without issues.

Update 30th October: There is now a hot fix available which can workaround this issue (by using a different crypto provider within PaperCut if necessary). Please contact us to get hold of the hot fix!

Update 23rd December: The 20.1.2 release now includes a fix for this (by using a different crypto provider within PaperCut if necessary). Please contact us and refer to PC-17674 for more instructions about enabling the new crypto provider.

Windows August 2020 updates contain a problem whereby after installing them you can no longer create a local nul port.

You receive an error 'The parameter is incorrect'.

Note that this does not effect an existing local nul port configured prior to the Windows Update.

We are working with Microsoft to investigate. This looks to be related to KB4571703 (2012 R2), KB 4578013 (Win 8.1), KB4570334 (Win 10).

Workaround: Use the add-printerport PowerShell command to add the port to an updated system:
add-printerport -Name nul

Update 7th October 2020: In 20.0.4, PaperCut now auto-creates the nul port as part of the installation - saving customers from having to use the PowerShell workaround above.

Note that Microsoft also resolved this in a subsequent Windows patch in August.

When scanning from an embedded Xerox device in v20.0.3, the scan fails with 'Scan Failed' and the server.log file shows 'java.io.IOException: Stream already closed'.

Workaround: enable application server debug logging (Options -> Advanced -> Diagnostics -> Enable Debug Mode).

We hope to have this fixed in our upcoming 20.0.4 release.

Update: This has now been fixed in our publicly available 20.0.4 release.

If a scan action has output types of PDF (non-searchable) and DOCX, and a user does a PDF scan. It will get put through OCR. If a scan action does not have DOCX as an option, the PDF will not get put through OCR.

A fix has been identified and will be included in an upcoming release.

Current workarounds:

1. Log out of the current OS session and log back in.

2. Restart the computer.

When a server print queue is being installed on the client and it takes longer than 1 minute, the process times out and causes the client to fail the installation.

When performing scans using Integrated Scanning on a Konica Minolta device, we have had reports of a small number of customers seeing a ClosedChannelException error appear.

We're actively investigating this and hope to have a hot fix available shortly.

Update: 7th August - we now have a hot fix available for anyone coming across this issue.

Update: 7th October - this has now been resolved in our 20.0.4 release.

Changing the port (on the reference machine) for an already cloned/deployed print queue and then redeploying this print queue may result in the original print queue on the client machine not being deleted. This can happen because the attempt to remove the old printer and old port may fail and no error is reported by the operating system. The subsequent addition of the new port will fail because the old port still exists in some form.

We have found an issue in on-premise Document Processing that could, in some rare circumstances, lead to two users both being sent the scanned document belonging to one of them. It is very unlikely to happen, but it is possible.

This issue will be fixed in an update to on-premise Document Processing that will be released early the week beginning August 3rd 2020.

The problem cannot occur with our cloud-hosted Document Processing engine.

In the meantime, there are two different workarounds available for customers concerned about this issue:

• Switch the document processing to the PaperCut cloud hosted servers, or
• Reconfigure the on-premise Document Processing servers to only allow a single job to be processed at a time (the default setting for maximum concurrent jobs is 2).

Please note: This issue has now been resolved in Document Processing server V 1.1.9

Users on Windows 8.1 devices with KB4489881 using the Print Deploy client installed may see an error similar to "Intl is not available." There was an error in the script on this page Error: Intl is not available. Do you want scripts to continue running on this page? KB4489881 can be removed if appropriate for your environment. Note: An update to Print Deploy will be published soon that fixes this issue.

Due to a limitation with the SDK/J integrated scanning workflow, the selection of B&W is not available. Only color or greyscale can be selected. For compatible devices, using the SmartSDK embedded application will enable the B&W integrated scanning option.

Mobility Print queues imported via wizard (not cloned) in Print Deploy may fail to install on macOS clients if they contain special characters in the name.

The PaperCut embedded solution fails to un-register, or uninstall in some cases showing an Error 37 message on the status screen. For example, single-function printers like the KM C3300i do not support Integrated Scanning. The printers can get stuck with Error 37, and the condition prevents the removal of the PaperCut MF embedded solution.

If a PC MF upgrade is not feasible, this can be worked around by the following steps:

1. Put the KM device on the older GG7-45 firmware.
2. Enable the PC MF embedded app integration.
3. Re-configure the SSL certificate.
4. Enable the PC MF embedded app integration again.
5. Set the following config key: ext-device.konica-minolta.skipsetup=Y

We've had a small number of customers upgrade to 20.0.x who have then experienced problems such as print jobs not going through, or popups not appearing for users. The customers identified have also found Failed to process print job: Could not obtain the lock for modifying account 'username' within 45 secs messages in the logs.


Detail of the Investigation:
We have found that if an environment is using the PaperCut User Client, and an admin then leaves the Admin Console open on the 'Dashboard' tab for 3 mins or more, and the client connections happen in a certain order, then a database lock can occur.


Workaround:
If you have installed 20.0 and are experiencing this issue, you will have to restart the Application Server to clear the lock. Once you have done this, make sure that the admins know not to let the Dashboard page timeout (3 mins by default) - or temporarily revoke access under Options -> Admin Rights -> then revoke the 'Access Dashboard' right.
This should stop the lock from happening.


Update 29 June 09:00 AEST:
Current investigations are centered around a potential lock which can be triggered by admins staying on the 'Dashboard' page of the Admin Interface and letting it time out (along with other requirements too). If a customer is running the PaperCut user client (for popups like shared account selection or print notifications) and sits on the Dashboard in the admin interface, and the client connections happen in a certain order, this can trigger this issue.

Once this issue is triggered, the remedy is to restart the Application Server.


Update 29 June 14:00 AEST:
We now have a hot fix available which should resolve this issue. We are also hoping to get this fix into a publicly available 20.0.2 release shortly. Please contact us if you need this hot fix - please also include 'request for hot fix PC-17485' in your email, along with your CRN and other details/debug logs/messages showing the symptoms your seeing.


Update 1 July 14:00 AEST:
We are now working on getting this fix included in a publicly available 20.0.2 release - hopefully available next week.


Update 7 July 14:00 AEST:
This issue has now been resolved in the publicly available release of 20.0.2.

You should be able to create a deployed device and a staged device with the same Hostname/IP. However, this is not possible for Kyocera at the moment.

You can create a staged Kyocera device if there is already a deployed device with the same hostname/IP in the PaperCut MF server.

You can not create them in reverse order though. So if there is a staged Kyocera, you can not create a deployed device for the same hostname/IP using the create multiple devices feature.

The workaround is to deploy the embedded software software using the manual installation method. (Contact your authorized partner for assistance). The same way they were created before this feature existed.

You should be able to create a deployed device and a staged device with the same Hostname/IP. However, this is not possible for Sharp at the moment.

You can create a staged Sharp device if there is already a deployed device with the same hostname/IP in the PaperCut MF server.

You can not create them in reverse order though. So if there is a staged Sharp, you can not create a deployed device for the same hostname/IP using the create multiple devices feature.

The work around is to create the deployed device the old fashioned way. The same way they were created before this feature existed.

Description:
An error caused by two groups with the same name synced. PaperCut expects group names to be unique but in the derby database the unique key can have sensitive values. This can happen when there are multiple sync sources with the same group names in both. For Example: one sync source is on prem active directory and the secondary source is Gsuite each contain the same group name, this will cause a conflict.
HTML Error Shown:
Unable to invoke method formSubmit on web.pages.GroupAddRemove$Enhance_59@7316309[GroupAddRemove]: Expected only one result, but got 2 List:
Workaround:
Only add the one group from the one source needed or rename the group until the bug is resolved.

You will see a message on the device screen saying “Access denied to this device.”

This has been resolved in OPS for PaperCut v 2.1.11.

Due to changes in the Device Web Common (DWC) where PIN passwords were changed to number password fields only when the feature is supported by the device, some Fuji-Xerox devices have now been found to not know how to treat the field, and as a result, when you press the PIN field the on-screen keyboard does not display.

Note that this has now been resolved with the 20.0.3 release.

Due to a change in the on-screen keyboard’s functionality, an issue where a user is attempting to use non-numeric characters when entering their ID to login on the device’s screen may not be possible. Authorisation via other methods (for example proximity or swipe cards) should not be affected.

Please note that this has been fixed as of version 19.2.0 of PaperCut MF.

Kyocera has identified some security protocols being turned off after a firmware upgrade to device firmware 2019.11.27*. We advise customers to check the protocol set up before and after the upgrade but to be safe install firmware versions prior to 2019.09.24 for now.

To work around this issue, either downgrade the firmware to versions prior to 2019.09.24 or please make sure WSD and Enhanced WSD scanning are both turned on, also that TLS1.2 is enabled.

When selecting the landscape duplex option in Integrated Scanning, the 2nd page (duplex side) gets flipped upside-down along the long edge on the resulting file. This can result in an incorrect orientation of the second page of the scan job.

Currently no workaround is available however a has been released with embedded version 3.0.3 (19.2.3)

After an installation of the OKI Open Platform, the status will show an "Error: Role already exists" message. Most things will still function, however, jobs will no longer be tracked (as we will no longer download the job log from the device).

Please note that this has now been resolved in version 19.2.4.

Upgrading to v2.4.3 has led to intermittent losses of the Integrated Scanning function on some devices.

Upgrading to MF v19.2.3 and upgrading the Ricoh SmartSDK to V2.4.4 resolves the issue. If you are not in a position to upgrade, we do have a workaround; please log a ticket over here referencing the known issues to receive a hotfix embedded build.

The printer installation popup window appears continuously, indicating that the Print Deploy client is attempting to reinstall the printer - even if no printer properties have changed.

When running the PaperCut NG/MF server installer, it resets the security permissions on the newly created web-print-hot-folder, to ensure functionality.

At this point the permissions can be set to whatever you require.

We have noticed though that the permissions on this folder are reset again every time the installer is run (E.g. during an upgrade), and this can potentially leave the web-print-hot-folder exposed on the network - so we are investigating not resetting these permissions during an upgrade.

You can workaround this issue in the meantime by manually adjusting the security permissions on this folder after an upgrade is performed.

The user will send the email with the attachment to print, but instead of the job printing, they will receive an email reply saying ”An application error was reported. Further action may be required: Email to Print - Error while fetching mail - null.”

This looks to be related to the method used to report the time-stamp of the email by the email server. So far this has been reported on Exchange and Office 365.

Note that this has now been resolved in 19.2.3

If deploying print queues to a user group where users within that group belong to a domain and have a ‘.’ in their username pattern (e.g. john.smith), print queues are not deployed for the user.

Updating Print Deploy on macOS resets the UserIdentityMethod config key. By default this value is set as auto, however you may have changed this to trust or prompt.

Updating the config key followed by restarting the Print Deploy service will fix this issue. More info can be found here.

Updating Print Deploy on macOS also resets values within the pc-print-deploy.conf file back to default values. You may have changed this content to configure Print Deploy auto updates.

This issue affects all current Print Deploy users.

Under certain circumstances in extremely busy environments this could happen when:

1. User sends a print job to a hold/release queue.
2. Print Administrator makes a change to the print queues on that print server, e.g. removing a print queue, adding a print queue or renaming a print queue - or the ~4am Print Provider daily maintenance refresh happens. (Note that making property changes like driver defaults is not included in this list - only major changes like add printer / remove printer / rename printer).
3. User then releases the job.

Note: if there are no changes being made by the print server administrator, and if jobs aren’t happening around the 4am maintenance window, then this issue will not be seen. If the scenario above was experienced, the behavior seen would be:
*The user walks up to a release station and releases the job. It would look as though the job didn’t successfully release to the printer, and the job would not actually print.
*If the user then went back to the release station and released the job again (it could be displayed again), the job would successfully release, but the user would then be charged twice for the job.
*The likelihood of this happening is even less if a find-me queue is in use, and the job is redirected to a different target queue on release.

This has now been resolved in 19.2.1.

For more information, and workarounds, have a look at the Known Issues with macOS page.

Several customers have reported that the Admin Console for Print Deploy displays a HTTP ERROR 500 along with a timeout error.

This error is difficult to reproduce and only happens in unreliable network environments where connections are terminated improperly.

This issues has been resolved in PaperCut NG/MF 19.2 GA and Print Deploy version 1.1.904, otherwise Restarting the PaperCut Application Server will resolve this issue temporarily.

Example partial error message:
HTTP ERROR 500
Problem accessing /print-deploy/admin/. Reason:
Server Error
Caused by:
java.net.SocketTimeoutException: timeout

Some customers may report that users will not be able to see their print jobs are available for release due to a Print Provider crash with this issue. PaperCut Sys Admins may see a similar message to this in the logs: Print Provider “printsrv01|192.0.0.1”: Print job “Document-1.pdf” printed by “user1” is offline and has been temporarily hidden from the Print Release screen.

Through our analysis we have determined that the Print Provider may stop when documents are printed using Windows 10 store apps to a shared print queue on a Windows Print Server with Print Archiving enabled on the same print queue. Workarounds to this include disabling Print Archiving on the relevant print queues, correcting the use of XPS2GDI print jobs to the PaperCut Print Server or have Windows 10 devices print through Mobility Print.

This issue seems to only affect PaperCut 19.1.5.

Please note that this has now been fixed in 19.2.1.

This random warning message has been appearing on some customer’s servers when they’re logged in to the Admin Interface - which is very misleading, an even more confusing.

One workaround is to clear it by either:

1. Reapply your license file to your server (on the About page in the Admin Interface), or


2. Restart the PaperCut Application Server service on your server


Please note that this has now been resolved in 19.2.4.

The PaperCut Print Provider service can redirect print jobs from one print queue to another, facilitating workflows such as Find Me Printing. It was found that a change introduced in version 19.1.4 could cause the Print Provider service to fail if Print Archiving was enabled on a print queue and a print job was redirected to it. A fix for this issue has been included in version 19.1.5.

(Also known as PO-16) When printing a document from Microsoft Applications (E.g. MS Word) which contains color images, and B&W output is chosen for the print setting, the color images still print as color on the page and the document is recorded as a color job (even though B&W output was chosen)

The issue does not appear to effect other applications - for example, printing from Adobe Reader does not present this problem.

Please note that this has now been resolved in version 21.1.2.

PaperCut is providing the logged in user’s email address.

This issue has been seen on firmware 101.002.009.00300 but apparently worked fine on previous 100 firmware. Xerox Support have reproduced the issue and have released a new patch for Altalink, Software Patch 1333899v2, on April 5, 2019.

Using remote software such as VNC (Virtual Network Computing) with the PaperCut Gen3+ embedded application does not display screen transitions occurring on the device. PaperCut is working with Canon to resolve the issue.

Several customers have reported that after deploying the pc-client-admin-deploy.msi package the client crashes soon after launching. The speed of the crash prevents logs from being obtained.

This is more likely to affect customers running PaperCut MF 19.0.5 and newer.

It’s possible to prevent this from happening by deploying a different PaperCut client by following the links below. Install the User Client on Windows

Alternately you may be able to resolve the issue by manually replacing the following files inside the Client installation directory.

Steps:

1. Download the latest Microsoft Visual C++ Redistributable
2. On the affected client computer, browse to the PaperCut MF Client folder
3. Replace msvcp140.dll and vcruntime140.dll with those downloaded from the Microsoft Visual C++ Redistributable
4. Run the Client
5. Please note that this has now been resolved in the 19.2.1 release.

When scan files from PaperCut Integrated Scanning are greater than 4MB, the file transfer consists of multiple packet uploads. In some rare circumstances with certain environments using the PaperCut Scan to Cloud Storage feature, the uploads to the cloud can intermittently fail.

Due to libraries updated with the 19.1 release, customers at those locations are reporting that the uploads to the cloud are now more reliable.

This has now been resolved in 19.1.1 (but 19.1.2 is highly recommended).

Until Lexmark release new firmware to fix this, you can workaround the issue by downgrading the firmware. The other option (if this it is not possible to downgrade the firmware) is to downgrade the PaperCut Lexmark Embedded Application to version 2.8.0 (or earlier)

This can cause issues if you’re expecting to track jobs based on the username e.g. ‘tim’ - rather than the username and the IP address as it appears in the print queue e.g. ‘tim (10.1.10.13)’.

If you are using the PaperCut LPD Service you can workaround this issue by:

1. Make sure that you’re using the latest LPD Service version, by running the installer in [app-path]\providers\lpd\win\pc-lpd-installer.exe
2. Edit the LPD Service config file: [app-path]\PaperCut LPD Service\pc-lpd.config
3. Add the line RemoveHostAddress = true (and save the config file)
4. Restart the LPD Service

This will remove the IP address from the username - both in the Print Queue view and also from the PaperCut logs - so that tracking against the usual username e.g. ‘tim’ will continue. This method strips out the IP address at the LPD Service level.

If you’re using the Microsoft LPD Service - or if you still want the IP address to show in the username at the OS level for other reasons (other integrations or workflows), there is also an alternative workaround:

1. Log into the PaperCut admin interface
2. Go to the Options tab
3. Go to the Config Editor (Advanced) action
4. Search for the system.normalize-network-username-regex config key
5. Enter a value of ^([^\s]+) and then click ‘update’

This second workaround is taken from Example 5 on the Normalizing Usernames KB article.

This will mean that the username in the print queue is untouched - however when PaperCut receives the job for tracking, it strips out the IP address at the App Server level.

Update: Please note that this has now been resolved in the 19.1.2 release.

When customising the Release Station software (e.g. using the second Step 1 from the Installing the Release Station article), if you’re using the font-color customization to change the font color of text, you’ll find that prior to 19.x, this did not impact the input fields (they would remain black text on the white input box background).

However since 19.0, that customization now impacts the input field text - for example if you’re running 19.0.1 and you have customized the release station to use grey text, you’ll find that the input box (e.g. username and password) text will also be grey.

Update: This has now been fixed in the 19.1.3 release. Init.

We have seen several users who have not configured the above URL settings in the TouchNet OneCard properties file correctly.

Make sure your vend-money-url setting ends with /transactions/onecard/vendmoney/process and balance-inquiry-url setting ends with /transactions/onecard/inquiry/process.

For example:

touchnet-onecard.vend-money-url=https://www.test.com/api/transactions/onecard/vendmoney/process

touchnet-onecard.balance-inquiry-url=https://www.test.com/api/transactions/onecard/inquiry/process

Then restart your PaperCut MF/NG server.

Update: this has now been clarified within the config files included with the latest version of the payment gateway.

A change introduced in PaperCut MF 19.0.4 around the Card/Identity Number self-association workflow was found to break self-association for Konica Minolta devices which have:

• No i-Option compatible web browser enabled
• Three user authentication methods enabled (i.e. Username and password, Identity number, and Swipe card)

For these devices, self-association would appear to work as expected, but the next login attempt with the same Card/Identity Number would result in a failure to authenticate.

A fix is planned for inclusion in a shortly forthcoming release of PaperCut MF, but the problem can also be worked around by heading to the Advanced Config subtab of the Device Details page for an afflicted device and updating the value of the following configuration key to Y:

ext-device.konica-minolta.login.prioritise-card = Y

Update: this has now been resolved in the 19.1.3 update.

If your TouchNet OneCard VIP gateway is configured for account types of track2Data then you will experience balance and transaction failures on those accounts.

Note that this has now been resolved in 19.1.1

We have seen several users with external databases housed on SQL servers where connection timeouts and rollback issues are causing server stability and performance issues.

This behaviour stems from a difference between the previous SQL database driver (used in V18 and earlier) and the current driver (used in V19 onwards)

We’ve corrected this in an upcoming version of PaperCut, however there is a simple workaround that can be implemented in conjunction with a PaperCut server restart.

To implement the workaround please add the following to the end of your existing SQL connection statement

;socketTimeout=600000



This has now also been resolved in 19.1.1.

Introduced in PaperCut MF 19.1, Device Scripting allows for programmatic control of many aspects of a user’s experience at an MFD, much akin to what Print Scripting facilitates for control of your printing workflow. With Device Scripts, PaperCut MF administrators are equipped to guide and direct user behaviour around copying and print release, as well as make adjustments to the charging of copy, scan, and fax jobs, all based on fully custom criteria, right down to individual users, or even time of day.

Whilst the initial implementation of Device Scripting enables a broad array of possible inputs and actions with which to solve problems and meet unique requirements, the sheer multitude of supported devices and methods through which PaperCut MF integrates with them incurs a small number of limitations. This article provides information around these limitations, and will be updated to reflect any changes concerning them down the line.

The hook deviceLoginHook does not support guest/anonymous access on some devices

When included in a Device Script, deviceLoginHook will be called at the point a user attempts to login to the applicable device, giving the opportunity to take actions such as denying their login, denying them access to colour copying based on criteria such as custom quotas, or filtering the Shared Accounts they can employ in the current login session. Whilst calling this hook is supported on all devices, testing has shown that the guest access authentication method may not trigger it on certain models. This appears to be due to slight variations in the specific authentication workflow for guest access on these devices, and which families of devices are likely to be impacted is accordingly unpredictable.

A warning concerning this will be displayed when using deviceLoginHook in a Device Script applied to a device that has guest access enabled. To test if this hook is compatible with guest access on your devices, the following snippet could be inserted into a Device Script:

function deviceLoginHook(inputs, actions) {
actions.log.info("Phew, looks like guest access is supported =)");
}

Once this Device Script is applied, walk up to the device and hit the Guest button to login, taking note of the time. Return to the PaperCut MF Admin web interface and check the Application Log subtab of the Logs tab. If you see an entry at the noted time of login which contains the text “Phew, looks like guest access is supported =)”, the device supports the hook in conjunction with guest access. If no matching entry can be found, please reach out to us via the Device Scripting Percolator page with the following details:

• Make and model of the device
• Version of firmware installed

… so that we can keep track of any unsupported models, and potentially determine ways to address this in future. Be sure to remove the Device Script snippet when you’re finished testing, too!

Note that anonymous access, an authentication method closely related to guest access, will similarly not be able to trigger this hook for any unsupported devices.

Introduced in PaperCut MF 19.1, Device Scripting allows for programmatic control of many aspects of a user’s experience at an MFD, much akin to what Print Scripting facilitates for control of your printing workflow. With Device Scripts, PaperCut MF administrators are equipped to guide and direct user behaviour around copying and print release, as well as make adjustments to the charging of copy, scan, and fax jobs, all based on fully custom criteria, right down to individual users, or even time of day.

Whilst the initial implementation of Device Scripting enables a broad array of possible inputs and actions with which to solve problems and meet unique requirements, the sheer multitude of supported devices and methods through which PaperCut MF integrates with them incurs a small number of limitations. This article provides information around these limitations, and will be updated to reflect any changes concerning them down the line.

The hook deviceJobLogHook is not supported on some device types

Commonly, devices integrated with PaperCut MF will keep track of the copies, scans, and faxes a user performs whilst logged in, and then return this data to the PaperCut MF Application Server once the user logs out. The Application Server then uses the charging configuration applied to a device to calculate how much to deduct from the relevant Shared Account or Personal Account balance, as well as enter job records into the Job Log.

The deviceJobLogHook portion of a Device Script is called during that post-processing of job data by the Application Server, allowing for granular charging adjustments, updates to custom quotas, or the insertion of comments into the Job Log. However, various device types deliver job data to the Application Server in differing ways, with these differentiations dependent on how each platform behaves in tandem with our software integration. The resulting workflow of some device types is incompatible with the present implementation of this hook.

In these cases, an applied Device Script will not trigger the deviceJobLogHook, rendering that section of the script inapplicable for the device types listed below:

• Brother
• Fuji Xerox (Legacy AIP only - ApeosPortV+ devices are supported)
• OKI Open Platform
• Toshiba

If you apply a Device Script containing deviceJobLogHook to a device of one of these types, a warning message will be displayed as above.

After logging in on Toshiba V3 device, if a network print job is sent to the device, when the job has finished it will log the user out. In a similar vein, if a longer running job is still going from the last user and then it finishes, whilst the next user has logged in, they will be logged out.

Evidence of this happening can also be seen in the Application Server Debug logs with the line of: “Forcing logout after scanning for deviceId:”.

A hot fix is available for this (based on 19.0.7) - and we have also now resolved this in 19.1.1

On Xerox Versalink models, when they are upgraded to PaperCut MF version 19.0.6 or 19.0.7, as a job is proceeding it will show the message, “Held: Validating Limits” but the job will not complete.

We suspect the new call to the Session API that was added in version 19.0.5 may have triggered an issue with the Xerox firmware just on Versalink. Reports back from the customer seem to confirm this theory.

Xerox has advised us of the relevant issue: CQGbl01318341.

The SPAR release xx.45.61 PL5-Rw for the entire Versalink family was released on June 29, 2019 to address this issue but we have yet to confirm the fix.

For Versalink models without the SPAR fix release, the Session API can be turned off in version 19.1 by setting ext-device.xerox.use-session-api to N.

Turning off the Session API will mean that for scenarios where a user changes multiple accounts in a session and/or uses Job Limits with a job where the user will log out before the job on the MFP has finished being analysed, the job may not be tracked correctly or may not enforce that an account was selected (if that selection option was enabled).

Please note that this has been resolved in 19.1.0

Update: this has now been resolved with the public 19.0.5 release.

Not to be confused with MAC-5278, which has similar appearances, however has been resolved by HP in the 4.7.1 (and above) firmware release. If you’re experiencing this error on devices, the first step will be to make sure that you’re running 4.7.1 firmware or above.

For other cases unresolved by the 4.7.1 firmware, we are continuing our investigations with HP Engineering.

Update: 19.1.1 is now live, and this version has further workarounds to reduce the likelihood of these errors from occurring. HP are also hoping to release a firmware update in the future to resolve the underlying issues around these errors.

As per the release notes: ‘Added an improved workaround to reduce the chances of 49.DE.xx error codes displaying on HP OXP devices’

As of PaperCut MF Version 19.0.0, the Kyocera Integrated Scanning functionality is over HTTPS, which may cause a failure related to a SNI Mismatch, specifically, a ‘Host does not match SNI’ error.

Typically, the FQDN specified by the certificate does not match the server name used when establishing the connection between the device and the server.

This is correctable by recreating the SSL certificate with one that includes the correct name.

As a workaround, you can disable SNI host checking by setting the following configuration key in the server.properties file on the Application Server, and then restarting the PaperCut Application Server service:

server.ssl.sni-host-check-enabled=N

This is only recommended as a stopgap measure until you’re able to recreate your certificate as noted above.

When viewing the Printer Toner information under Printers → [select printer] → Summary → Configuration → Toner Status, details may not display or may be out of date.

This does not impact Hardware Validation / Hardware Page checking.

Update: There is a hot fix available for this if needed. Please contact us if needed!

Update: This has now been resolved in MF version 19.0.6.

This could be through setting the config key client.config.show-balance to ‘N’ (on the server side) or using the config properties hide-balance=Y config option, or using the —hide-balance command line option when starting the client.

This has been fixed in 19.0.3.

We have seen instances where the client files are re-copied from the server, to the local workstation C:\Cache directory, even if the cached location is up to date. On slow networks this can result in a slower startup time for the user client.

In some cases with shared workstations (multi-user switching), users may see the error ‘Unable to create the local cache in ‘C:\Cache’.

We’re hoping to resolve this in the next release.

Update: there is now a hot fix available for this - please contact us if you need this!

Update: this has now been resolved in the public 19.0.4 release.

On saving, the ‘primary number’ source is updated to match the ‘secondary number’ source.

Note that this will not impact the sync behavior on upgrade unless someone uses the UI to update either the ‘primary number’ or ‘secondary number’ source configuration.

This has been resolved in 19.0.3.

The other versions of the client (including MSI, pc-client.exe and pc-client-local-cache.exe) are not impacted by this.

For users experiencing this, the behavior of client-local-install.exe will be that installation will work fine, however then when running the User Client, it won’t run at all - no error.

The workaround currently is to either not upgrade using the client-local-install.exe (old versions of the client work perfectly ok with later versions of the App Server), or uninstall the client from the local workstation, prior to using the client-local-install.exe to install the updated client.

This has now been resolved in 19.2.2

If you activated Scan to Cloud while on 18.x, then Scan to Cloud will work as expected. Likewise if you installed version 19.0 or later and you are activating Scan to Cloud for the first time, everything will work ok.

This has been fixed in 19.0.3.

A workaround is to head into the config editor, and set system.scan.cloud.api-url to https://scan.cloud.papercut.com.

If you’re wondering what Scan to Cloud is - check out Scan to Cloud Storage.

We are currently in discussion with Kyocera regarding this issue. It has been reported on Taskalfa 3553ci, 4053ci, and 5033ci models.

Workaround this display issue by selecting the refresh icon in the upper right of the screen to refresh the page.

Update: This has now been resolved in MF 19.0.6 / embedded v2.4.2.

If you print a job in Grayscale (‘High Quality CMYK Grayscale’ in the driver):

• In firmware 4.6.3 and below - pages were counted as grayscale pages by the device counters.
• In firmware 4.6.4 and above - pages are counted as color pages by the device counters.

This has two components impacted:

1. Color detection in PaperCut - with 4.6.3 and below, PaperCut would correctly count the pages as grayscale pages - and the device counter would match. Now with the 4.6.4 firmware, the device will register color pages, but PaperCut will still log and charge for grayscale pages.
2. When using grayscale conversion in scripts or filters & conversions, the job will be logged as grayscale in PaperCut logs, but will be logged as color in the device counters.

Within the HP driver there are two different options to print in grayscale:

• Black only (uses only black toner)
• CMYK Grayscale (uses mixed color toner to produce fine grayscale)

We are working with HP to confirm the intended behaviour and we hope to have a fix for this in an upcoming release.

Update: this has now been partially resolved in the public 19.0.4 release.

As per the release notes: HP Universal print driver (PCL, PostScript) or HP model-specific driver: Documents printed with a color selection of “High Quality CMYK Grayscale” are now counted as color jobs instead of grayscale. This change aligns with HP’s change in firmware version 4.6.4 and above where these jobs are now counted as color in device meter counts. This behaviour can be reversed by setting CompositeIsGrayscale in the print-provider.conf file to “True”.

A number of customers have confirmed that this has fixed the discrepancies that they were seeing.

Further Update: we have found some circumstances where the PJL headers GRAYSCALE=COMPOSITE and PLANESINUSE=1 are present in the spool file - in this case we may incorrectly detect the job as grayscale, whereas the device will report the job as color. If you are running 19.0.4 or above, and you’re finding that some color jobs are incorrectly logged as grayscale in PaperCut, this is probably the issue that you’re seeing.

Final Update: the additional circumstances mentioned above have now been resolved in the 19.0.7 release.

The ‘prompt for more pages’ option allows you to scan multiple pages in, and have them all bundled as one PDF. For example if you don’t have a document feeder, or if you have a particularly large document, you can scan a number of pages through separately, and using ‘prompt for more pages’ you’ll receive 1 PDF with the entire document.

This has been fixed in 19.0.3.

Please note that if you’re not using OCR, then you’ll not see this issue happening.

There is a hot-fix available to resolve this issue, and we also now have this fixed in the 19.0.3 release.

Please note that this does not impact the more recent Futuresmart platforms.

Instead, users will see the message “account needed”, displayed in the “Jobs Pending Release” page, or on the device or release station, when trying to release their print jobs. All jobs printed to hold/release queues subsequently (i.e. after the upgrade to version 19) will behave as normal, and will be available for release by the users.

This will only impact those jobs that were printed prior to the upgrade.

If you find yourself in this situation, the workarounds available are:

Clear your hold/release queues

We strongly advise to do the version 19 upgrade out of hours, and to ensure that Hold/Release Queues are cleared down pre-upgrade where possible.

If possible, clear out your hold/release queues - so that the pre-upgrade jobs are removed, and don’t cause confusion for users. Unfortunately this does have the obvious side-effect that users will have to re-print their jobs if they still need them.

Remove the job-status data from the Application Server

This issue has come about due to changes and improvements in the ability to select accounts to charge jobs to, at release time. See Assigning accounts at the MFD if you’re interested in this feature. To handle this, the status information about jobs being held has been changed.

One way to get around this is to:

1. Shut down the App Server
2. Remove the following files from [app-path]/server/data/internal/state/systemstate/
   
   held-jobs.curr.ser
   
   user-client-data.curr.ser
3. Start the PaperCut Application Server service

This will have the positive effect that the old status information will be removed, and the App Server will regenerate status information for any held jobs in the system. However there are also side effects:

• Jobs that were printed by users who have their account selection set to ‘Automatically Charge to Personal Account’ or ‘Automatically Charge to a Single Shared Account’, will then be available for release for those users. This is the good news.
• The bad news is that jobs that were printed by users who have their account selection set to e.g. ‘Show Standard Account Selection’ (i.e. the user has to select which account to use) will need to re-select the account required. If your users have the ability to assign accounts at the MFD, then they can do this - otherwise they will have to return to their computer, make sure that the PaperCut User Client is running, and re-select the required account.

If in doubt, reach out to us to chat!

In the following setup, the user will always be able to log into an EIP 1.5 (or below) device, and be able to make 1 copy, before being logged out due to not having enough credit:

• User is restricted
• User has a balance of 0 or less
• Account selection set to be able to select a Shared Account
• When a shared account is selected, option to ‘Charge personal account (and allocate to shared account for reporting)’ is selected

In that instance, every time the user logs in, they’ll be able to perform 1 copy job before getting kicked out.

Please note that this only happens with the exact configuration above. For any other combinations, Zero Stop will work as expected, and deny the user from performing any copy jobs. Additionally this only happens with devices that are EIP 1.5 or below. EIP 2.0 or above are unaffected.

Update: this has now been resolved in 19.0.3.

N/A

To be able to fix this issue, we are waiting for Ricoh Japan to add some metadata to the firmware. Ricoh Japan is planning on having the firmware ready very soon, at which point we will need to make the changes to our embedded application for the device function priority to work as expected.

As a workaround please do not use the auto reset timer, instead use the panel sleep timer (user will be logged out on panel sleep). This timer is set in minutes, with the minimum being 1 minute.

Please note that this has now been resolved in 19.2.1.

Starting with PaperCut 18.3.6 the Print Provider may crash during page analysis when certain PCL5 drivers are used. When this occurs, job will not be tracked or held and the Print Provider will need to be restarted.

Update: This has now been resolved in the 18.3.8 release.

During the device’s wake up process, the device won’t accept login requests. If a user swipes a card 10 seconds after being putting into sleep mode, the 1st swipe will wake up the device. But due to the device not accepting login requests, the user will not be logged in.

Update: This has now been resolved in 19.0.0

With the Grayscale Default (other sizes) cost set to $0.00 (which is the default value for this cost), and when a user has a positive credit balance in PaperCut, they can perform a copy or scan job of any size. This can leave them with a negative balance.

Please note that this has now been resolved in our 19.2.0 release.

Original user’s job settings can be modified by another user releasing the job
In any of the following environments where a user is able to release held print jobs originally printed by another user, this user is also able to change the settings of such jobs:

• In the 'External Device Settings' section of the Device Details page, the only enabled Access methods setting is 'Allow guest/anonymous access'.
• In the 'Print Release' section of the Device Details page, the 'Users have permission to:' dropdown menu is set to release any print jobs (charged to their account).

Print setting changes made prior to an Application Server outage are not applied if these print jobs are released during the outage
Print setting changes made prior to an Application Server outage are applied only if the jobs are also released prior to the outage or after the outage. However, these changes are not applied if they are released during the outage.

Initial attributes of print jobs
While users can change held print jobs from color to grayscale and from 1-sided to 2-sided, they cannot do the reverse (from grayscale to color and from 2-sided to 1-sided).

Unidentifiable account displayed at the device
If a job has been printed from a terminal using an unauthenticated user account, then the device displays the account of the terminal from which the user has printed the job, instead of the actual account of the printing user. However, upon release, this job is successfully charged to the user’s own account.

Maximum number of copies is 9999
When changing the number of copies of a print job, the maximum number that the UI allows is 9999.

Changing charging model while modifying a print job is not supported
If the 'Charging' cost model is changed via a print queue’s 'Printer Details' page in the Admin web interface whilst a print job held in that queue is simultaneously being modified on a device, unpredictable charging of that print job may occur. We recommend only changing the job cost model at a time when print jobs are unlikely to be modified.

Print setting changes made on multiple jobs are applied only on release
'Force grayscale' and/or 'Force 2-sided' on multiple held print jobs are applied only if the jobs are released after making the change.

Selection of Force grayscale and Force 2-sided checkboxes may be ignored
Selecting the Force grayscale or Force 2-sided checkboxes is ignored in the following situations:

• If multiple jobs are modified at once, and the jobs aren’t released after making the change and before logging out of the device, these changes will be forgotten.
• If there are multiple print jobs with a mix of PDLs that both support and don’t support changing settings, the checkboxes are still available for all print jobs. However, selecting either checkbox for a print job with an unsupported PDL will have no effect.

Selecting a Shared Account at the device - submitting a print job with no account selected
From PaperCut V19, you are able to submit a print job without selecting an account and this will allow you to select one on the copier’s screen. This new feature reduces the need of running the PaperCut user client on workstations.
With PaperCut V18, you are only able to CHANGE the account associated to a print job, after you have selected an account previously (you cannot submit a print job without an account being selected).

When Print Archiving is enabled, and a user changes their print job settings at the device, two spool files might be created in separate directories under [app-path]\server\data\archive; one for the original print job, and one for the modified print job, which leads to drive space wastage.

Only one print job is recorded in the Job Log, showing the print settings at the time the document was released.

Follow the steps here before uninstalling the embedded:

• In CWIS, go to “Properties → Security → Authentication Configuration” and set “Login Type” to “No Login Required”. Click “Apply” then “Reboot”. When the MFD has restarted, you can delete the device from PaperCut.

These steps are documented in the Fuji Xerox embedded manual, see section 7. Reach out to your Fuji Xerox reseller for more information.Update: This has now been resolved, and ApeosPort VII is now official supported with version 19.0.1 - please see the manual as above for the additional steps.

Field reports suggest that certain Kyocera models (e.g. the Taskalfa 2553ci, 3253ci, 3553ci, 4053ci, 5053ci, and 6053ci) do not currently automatically format optional hard disk drives upon installation, as earlier models did. The PaperCut MF Kyocera embedded solution cannot be successfully deployed to an unformatted hard disk, as users will subsequently not be able to access device functions due to a lack of the requisite permissions. The HDDs on these devices need to be formatted manually prior to installing the PaperCut MF Kyocera embedded solution.

This information has been added to the PaperCut MF Kyocera Embedded Manual, as an additional step during installation. It is possible this behaviour may also be changed in future releases of firmware for the affected models, but our current recommendation is to format all optional hard disks before deploying the Kyocera embedded solution.

Small number of users have seen an additional status message appearing when pressing a sequence of the home button and locked device icons:

This item is restricted. Try to use another account, or contact the system administrator or the person who set up this product

This happens when the device is configured to show the ‘locked’ native device icons (e.g. Print Release, Scan, Copy).

• Press one of the locked icons
• The login screen appears
• Don’t log in, but instead press the ‘home’ icon top left
• The above status message appears

Logging in through the ‘normal’ workflow still works without issues.

Update: This issue has now been resolved with the Firmware update 4.7.1 from HP.