Scaling Find Me Printing

KB Home   |   Scaling Find Me Printing

Find Me printing solves the problem of finding the closest printer from a long list of available printers. It is a roaming print service that allows print jobs to find users based on their physical location. Some organizations will want to utilize more than one Find Me print queue, and this article will cover the considerations that will need to be taken in before and during deployment.

Factors to consider

Before planning deployment of your Find Me print queues, some planning and considerations need to be noted down to ensure your environment will not only be easier to use, but will be compatible with your current printer fleet along with taking in usage statistics for each printer to ensure no print queue is under-resourced. This knowledge base article explains these factors in detail, however this will be covered again to ensure these factors are taken into consideration when planning your deployment.

What is the maximum number of held jobs per virtual queue?

We have seen that Windows operating systems have a limit on how many jobs can reside in a single print queue. For example on Windows problems/warnings can occur if there are more than 1000 jobs in a print queue. This is a limitation within Windows that needs to be taken into consideration, and the more printers/users you associated with a single global queue, the higher the anticipated number of jobs pending in the queue. Large organizations may end up hitting this upper job limit quite easily.

How long does a job stay in the virtual queue before it’s removed?

Timeout periods for held jobs within a virtual queue are the amount of time a job is held in the queue before it expires and is deleted. These times differ for each environment, and the default value differs between education and commercial/professional sites (2 hours for education, 4 hours for commercial/professional). The timeout is configurable but the default is a good compromise between user convenience and environmental savings. It is recommended to keep the timeout periods at the default values.

What if I want to extend the timeout periods for held jobs?

Sometimes extending the timeout periods of held jobs is requested, and the process for extending these timeouts needs to be very carefully planned and implemented to ensure the number of held jobs never reaches the maximum amount and specific print servers can handle the extra held jobs in each queue. It is recommended to increase the timeout period gradually over a period of weeks to ensure no queue is heavily overloaded.

The following variables need to be taken into account before any changes are made:

  • Average number of print jobs per day
  • Number of printers per virtual queue
  • Print server resource utilization
  • Average number of held jobs “forgotten” or never released
  • Number of print jobs sent to each virtual queue per day

These variables will greatly change your planning methods for extending the timeout period and it is important to get a feel of these numbers for each virtual queue before extending your timeout periods. Below is a brief planning method which should be a starting point for planning your timeout extension and give you an idea of the variables that need to be monitored throughout the timeout extension period.

It is recommended to extend your timeout period once a week, doubling the time each week until you have reached a suitable timeout period. This would mean if you wanted to extend the timeout to 24 hours, it will take about 5 weeks to go from the default 2 hours. There are two major variables that need to be monitored multiple times per day during peak usage periods until the timeout extensions are complete to ensure the extended timeouts are working as intended.

Number one is the number of print jobs in each virtual queue. How are each virtual queues job count looking? Are they hitting close to the maximum number of jobs? If so, you have two options that you can follow. Option one is to split the single virtual queue up into two or more virtual queues to lower the usage of each queue. Option two is to keep the timeout at a stable time period where the number of jobs will likely never reach the maximum of 1000 held jobs.

Number two is server resource utilization. How are the CPU and memory usage going with the extra load? Is the print server showing sluggishness after an extension of the timeout period? If so, there are two options you can follow. One is to set up another print server and separate these virtual queues over two print servers rather than one. The second option is to keep the timeout at a stable time period where the server will likely never be over-stressed.

What model and make of printers can I use in a single virtual queue?

Large organizations tend to have a mix of printer types, models and makes. The driver on the global virtual queue controls how the print job is rendered and what print options are available to the user. If there is a mix of devices in the organization there may need to be multiple global queues to support this mix. For example jobs rendered on a global queue with a Postscript driver cannot be routed across to a GDI based inkjet device. There may be the need to have multiple global queues each associated with different printer types.

Can I “mix and match” printer models for a single virtual queue?

If all of the printers support Postscript then the PaperCut Global Print driver for Windows (LInux? and Mac users can use the CUPS Universal Postscript driver) will do the trick for printing. You should test common areas across all devices to assure that page boundaries (printable area differences) and finishing options such as duplex combinations work as expected. Users can be instructed to use the direct queues on the server if the printer’s advanced features are required(e.g. stapling, folding, color profiles, etc). Please refer to the PaperCut documentation for more information on how to manage differences between printers.

How can I manage these queues once they are setup?

A single organization-wide global queue does offer some management/simplicity advantages but can introduce other complications. For example, a single queue can be a single point of failure for all users. Multiple global queues partitioned by office/building/floor/area can help mitigate this single-point-of-failure. This does not mean that the partitioned queue can only route jobs to printers in this area, it simply means that users in this region use this global queue by default. Jobs can still be configured to route to any device in the organization if this is what is desired.

What driver should I use for the global queue?

Itís important that the driver on the global queue is able to produce output (e.g. Postscript or PCL) that is compatible with all printers/MFDs that will be associated with the global queue. Chapter 11 in the PaperCut manual discusses some selection options. If you have a mixed device fleet, there is of course no substitute for good testing. Take the time to test your selected global queue driver with your target devices.

Planning your deployment

Now you know the factors in deploying multiple Find Me print queues, we can start planning the deployment. This planning will include how you want to separate each Find Me print queue, along with staged deployment of print queues within your organization.

How should I separate these queues?

This is the first question you should be asking that will require some thought. The separation of print queues is an option which the end users will notice the most as this will be the list they are given for printing, so care is needed in ensuring that the conventions for deployment are as easy to understand for the users as possible.

Along with this, the amount of maximum jobs per queue noted earlier need to be taken into account to ensure no printer queue is under too much stress. Most Find Me print queues are separated in the following manner:

  • One Find Me print queue per floor
  • One Find Me print queue per office
  • One Find Me print queue per campus
  • One Find Me print queue per department

Please note that a printer can be members of multiple virtual queues, so if there is an overlap in separation such as a printer being in two departments sharing a computer area, they can be members of both Find Me print queues.

Now I’ve planned, how do I deploy my virtual queues?

Now you have decided how you will be setting up your Find Me print queues, it is time to deploy them. The suggested method of deployment for this in larger organizations where reaching the maximum number of active jobs is a possibility, is to gradually deploy your printer fleet. Please note that if needed, whilst deploying the Find Me print queues, it is possible to keep the direct print queues set up to ensure a crossover period for users to get used to the Find Me print queue functionality.

The recommended deployment process for Find Me print queues is to deploy one virtual queue every couple of days and to monitor print queue load and active jobs on the print queue to ensure the active job limit is not reached. This process also allows you to roll back easily if there are unrelated factors that are preventing the deployment. If your Find Me print queues are spread across multiple print servers, it is advised to monitor network usage between the print servers in use, especially if there is likelihood of printing large spool files greater than 1GB that will be redirected through the network.

Once deployment has completed and the entirety of your environment is running Find Me printing, it is your decision whether direct print queues are removed for users, to ensure usage of Find Me printing only.


Categories: Administration, Configuration


Keywords: find me printing, hold release, multiple queue, virtual queue, deployment, considerations, FAQ

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 May 11, 2016, at 04:18 AM
Printable View   |   Article History   |   Edit Article