Dispatcher Paragon knows three types of queues: direct, secure and shared:
- Direct queues are mainly suitable for small network printers where authentication is not required because there is only a limited number of users who send submit print jobs to them. Their configuration requires a non-trivial amount of effort by administrators who need to configure them in Dispatcher Paragon, create a shared printer for every device and deploy them to the right people.
- Configuration of secure queue is easy, as it does not require any configuration on Dispatcher Paragon side and only one shared printer and GPO for every spooling Dispatcher Paragon server. The biggest challenge here is how to deploy the queue for traveling users who change their location and therefore need to send print job into a different server.
- Standard shared queues (print delegation) are similar to direct queues because each of them needs to have a unique name and a unique shared printer. In addition, when a change is needed, it must be done by administrators. This is significantly improved by self-managed shared queues where only one shared printer per Dispatcher Paragon server is needed and users can manage members of their personal shared queues by themselves in the web portal provided by the SWC-49 product extension.
This article describes how these queues can be created in Dispatcher Paragon and deployed to users using Group Policy Objects (GPO) in Active Directory, which is the most widely used deployment method.
Direct Queues
The main benefit of direct queues is that they are transparent to users, all print jobs are released at the print device as soon as they are accepted and (optionally) analyzed by Dispatcher Paragon. Users will not notice any significant delay while metadata of their jobs is captured by Dispatcher Paragon for reporting purposes. Every direct queue has a specific name and is assigned to a particular print device as shown below. Each of the following license modules activates direct queues: Authentication, Print Roaming, Reporting, Credit and Billing and Rule-Based Engine.
The Group Policy Object for printer deployment to users needs to contain network path to the shared printer created beforehand and it needs to be assigned to an Organizational Unit with users. An example of a group policy object follows.
At this moment, the print queue will be connected to all user accounts in the Organizational Unit and users will see the printer in their Windows accounts when they log in. All print jobs will go through Dispatcher Paragon with stopping there and will be immediately printed and accounted.
These steps need to be done for every printer with a direct queue, which might be time-consuming especially in environments with a large fleet because all Group Policy Objects must be carefully assigned to appropriate Organizational Units in Active Directory for users to see only what they are supposed to see. It may be challenging especially for traveling users.
Secure Queue
Secure queue is the most widely used option because they hold jobs until their owner authenticates at a print device. When users want to release their print job securely, then there is no need to do any special configuration on Dispatcher Paragon side, as all print jobs will end up in the secure queue when there is no other queue type with the given name. The name set in LPR headers is usually "secure" but only for clear understanding of the destination not because it would change anything on print job processing. From license perspective, the only module, which activates secure queue is Print Roaming.
Deployment to user workstations is similar to the previous example. It is recommended to create a shared printer pointing to a spooling Dispatcher Paragon server. The queue name set in LPR port configuration can be for example "secure" bu, as it was explained before, the only rule is that there shall not be any other direct or shared queue in Dispatcher Paragon with the same name.Configuration of the Group Policy Object is the same as in the previous example, only the printer name is different.
Shared Queues (Print Delegation)
Finally, the last type are shared queues which provide similar user experience to the secure queues (authenticate before release) and are configured similarly as direct queues (specific queue name). The difference is that there are multiple users who are assigned to the shared queue, who can release the waiting shared print jobs. A real-world example is the boss-secretary scenario when the boss writes a letter and asks their secretary to print and send it. Let's explain how this is achieved in Dispatcher Paragon. Shared queues are activated only by the Print Roaming license module in the same way as secure queue.
First, an administrator needs to create a shared queue and assign members.Then create a new shared printer in Windows. The queue name specified in Dispatcher Paragon is used in LPR port configuration.
In the last step, an administrator needs to create a Group Policy Object, which will make sure that the printer is connected to the right Windows account(s). In this case, it is enough to assign the policy to the boss as he is the only person who should be able to send print jobs into the shared queue. It means that the boss will see two printers in Windows – one for secure print and the other for shared print.
Shared queues in Dispatcher Paragon are managed by administrator and only administrators are allowed to create them and set their members. Mind that those print jobs can be submitted by any user regardless of their queue membership or access.
Self-Service Shared Queues (Print Delegation)
Standard shared queues, as documented above, can be a burden to manage as all work is done by administrator. Some customers prefer to let users do the work themselves, for which we can use Rule-Based Engine and the SWC-49 product extension (Web interface for delegated print queue), see
https://paragon.konicaminolta.com/customer-support-service/extensions-store. With that approach the administrators can improve the user experience:
- Only create and deploy a single shared printer to be used by all eligible users who want to delegate their print jobs, regardless of which shared queue group they belong to.
- Use the SWC-49 product extension so that every user can self-manage who belongs into their personal shared queue list.
- Utilize Rule-Based Engine to redirect all print jobs from the specific shared printer into user's personal shared queue.
From configuration point of view, it is necessary to create a new rule in Rule-Based Engine, which redirects all print jobs from the shared printer into user's personal shared queue.Next, create a shared printer.
And deploy it to all users who should be able to send print jobs to personal shared queues.
Finally, users log in to the queue self-management portal where they can look for colleagues who they want to add to their personal shared queue or remove from it.