Environments with large numbers of Direct Print Monitors

KB Home   |   Environments with large numbers of Direct Print Monitors

Main.LargeNumberofDirectPrintMonitors History

Hide minor edits - Show changes to output

June 27, 2019, at 05:42 PM by employee 82 - i added the bit about disabling the ios print service
Added lines 60-64:
!!!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@@.
June 27, 2019, at 01:41 AM by timg - Minor typos.
Changed lines 23-25 from:
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 [[https://www.papercut.com/support/resources/manuals/ng-mf/common/topics/direct-printing.html|manual]] for more details.

Otherwise, the impact of ''not'' doing the registration won't impact printing or print-tracking. Jobs will still get tracked, and the printers will still appear in the admin console.
to:
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 [[https://www.papercut.com/support/resources/manuals/ng-mf/common/topics/direct-printing.html|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.
June 26, 2019, at 06:17 AM by timg - Minor updates.
Added lines 25-26:
Otherwise, the impact of ''not'' doing the registration won't impact printing or print-tracking. Jobs will still get tracked, and the printers will still appear in the admin console.
Changed line 50 from:
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 a print job is sent to one of the printers on that workstation.
to:
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.
June 26, 2019, at 06:08 AM by timg - Minor updates
Changed lines 9-10 from:
It depends. We've seen customers with high thousands of Direct Print Monitors, some running perfectly ok, and others are seeing some of the impacts 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!
to:
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.
Changed lines 15-18 from:
If you have thousands of Direct Print Monitors (DPMs), this 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).

These 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.
to:
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.
Changed lines 23-24 from:
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.
to:
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 [[https://www.papercut.com/support/resources/manuals/ng-mf/common/topics/direct-printing.html|manual]] for more details.
Added line 46:
(also called 'lazy registration')
June 26, 2019, at 05:40 AM by timg - Created article
Added lines 1-61:
(:title 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 [[https://www.papercut.com/support/resources/manuals/ng-mf/common/topics/direct-printing.html|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 impacts 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), this 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).

These 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.

!!How do I fix it?

!!!Make sure you're running 19.1.0 or later!

(Soon to be released)

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

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 a print job 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.


\\

!!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 [[https://support.papercut.com|Support Portal]] for further assistance.

----
''Categories:'' [[Category.Printers|+]], [[Category.Implementation|+]]
----

[-Keywords: DPM, direct print monitor, large load, wide-scale, high volume -]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on June 27, 2019, at 05:42 PM
Printable View   |   Article History   |   Edit Article