Environments with large numbers of Direct Print Monitors

If you have a large number of workstations that all print to local printers, chances are you’re already using the Direct Print Monitor feature of PaperCut.

If you have a gigantic number of these (we’re talking thousands and thousands) then there can be other things to keep in mind!

What’s a ‘large number’?

It depends. We’ve seen customers with high thousands of Direct Print Monitors, some running perfectly ok, and others are seeing some of the impact resolved by some of the features below. Performance can be influenced by the Application Server spec, the network, the number of Direct Print Monitors, the technique used for Windows patching, and more.

If in doubt - reach out to us and have a chat.

What should I be aware of?

If you have thousands of Direct Print Monitors (DPMs), the ‘register printer’ events can sometimes cause excess load on the PaperCut App Server - which can then manifest itself through poor performance for PaperCut users (slow popups, slow or unresponsive web interface etc).

It’s important to note that printing across thousands of DPMs is not an issue here - it is only the ‘registration’ process that can cause additional load. Even if everyone prints something at the same time, the App Server will be able to handle the load without issues.

The additional registration events can sometimes be triggered by environmental actions - for example, deploying a Windows update to all of the thousands of workstations… which causes all the DPMs to restart at the same time… and then call into the Application Server at the same time. They can also be triggered by maintenance tasks - for example at around 4am the DPMs call into the App Server to provide an ‘up to date’ list of printers and printer properties to the App Server. In the wrong scenario, this can also put additional strain on the App Server.

What exactly does the printer registration process do?

In summary, the Direct Print Monitor looks at all the print queue information for local printers on the workstation, and then reports that data to the App Server. This includes things like the IP address, driver details and more.

This process is particularly important when using Direct Print Monitors, since if the DPM doesn’t report the IP address of the printer back to the App Server, the App Server won’t be able to see that Printer1 connected to Workstation1 is the same as Printer1 connected to Workstation2 - and so will not be able to link those printers under one ‘umbrella’ printer in the admin console - one of the main benefits of using the Direct Print Monitor (see direct printing manual for more details).

Additionally, the IP address is used for toner monitoring and notifications - without this the Application Server won’t be able to fetch the toner values through SNMP, so toner values will not update, and there won’t be any toner notifications.

Otherwise, the impact of not doing the registration will not impact printing or print-tracking. Jobs will still get tracked, pop-ups will still appear (where configured to), and the printers will still appear in the admin console.

How do I fix it?

Make sure you’re running 19.1.0 or later!

This release contains a fix that means that the Application Server can naturally handle excess load from DPMs a lot better - it does this by throttling the requests, so that it’s never overwhelmed. If you run this latest version there is a good chance that you don’t actually need to apply any of the other config changes below.

Turn off the 4am daily refresh

This can be done by setting DoDailyServiceRefresh=off. This will stop the DPM from doing a daily re-registration of printers. If you are doing some kind of daily restart on your workstations, or if they all get turned off at night and on again in the morning, then you can disable this, since the restart itself will perform that function.

This configuration setting is located (and further documented) in the /providers/direct-print-monitor/win/direct-print-monitor.conf config file for the Direct Print Monitor.

Stagger the Application Server call after a DPM restart

This can be done by setting RandomDelayRegisterPrintersMins=240, which will add a random delay of (in this example) up to 4 hours between the startup of the DPM and the registration of any printers with the Application Server.

This configuration setting is located (and further documented) in the /providers/direct-print-monitor/win/direct-print-monitor.conf config file for the Direct Print Monitor.

Switch off the printer registration process entirely

(also called ‘lazy registration’)

This can be done by setting EnableRegisterPrinters=off, this will switch off any kind of ‘regular’ printer registration, and instead printers will only be registered with the App Server when the first print job after a restart is sent to one of the printers on that workstation.

We don’t recommend using this setting unless absolutely necessary.

This configuration setting is located (and further documented) in the /providers/direct-print-monitor/win/direct-print-monitor.conf config file for the Direct Print Monitor.

Finally, make sure to disable the iOS Print Service on macOS computers using the Direct Print Monitor

Disabling the iOS Print service on each macOS workstation prevents a flood of duplicate AirPrint advertisements. You can deactivate the PaperCut iOS Print service using the application’s disable script:

• In Terminal, change to this directory: /Applications/PaperCut [NG or MF]/providers/iosprint/mac/
• Run ./disable-iosprint.command.

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.