What is the purpose of the Printer Queue table?

[Bob Mullineaux]

What is the purpose of the Printer Queue table (autopopulated by Discovery)?  The table seems to sit out there by itself and not certain where discovery gets the information (I assume Servers) but it seems there are no references or relationships created.  There is no useful information collected and no useful attributes.  What is purpose and the value of this table in the CMDB?

[sachin_namjoshi]

Servicenow OOB discovery populate  the print queue when it finds a local printer that is also connected to the network with a valid ip..Take a look at the windows printer sensor to see what its trying to do

• A print queue is a virtual concept, a holding area to contain spooled jobs whilst the printer is trying to catch up. You don't send a job to a printer, you actually send it to a queue and let it eventually emerge.

Further information that could be useful:

• A printer requires a queue for it to be used. So every printer should have at least one queue.
• A printer may have several queues - each queue will process the data differently.   This is a common technique for managing multi-tray printers; one queue will be used for letter-headed notepaper, another for plain paper, another for punched, etc.   Each queue will instruct the printer to select a specific tray before proceeding with the job.
• A queue doesn't require a printer - it can continue to accept jobs whilst the printer is off-line, for example: being repaired.  
• Some queues don't terminate in a printer - like a "PDF printer", or fax server.   Attempting to send a document to that queue will process the document in some way.

Regards,

Sachin

[Bob Mullineaux]

Hi Sachin,

Thanks for the comments.  I do indeed understand what a Print Queue is...that wasn't really my question.  My question is more specific to how or why the Print Queue CI is structured in the CMDB (or lack thereof).   First there is no useful information (attributes), nor does Discovery populate any useful information concerning the Print Queue. The only attributes I see are the Name and an IP Address and the IP Address is not populated with an actual IP.   I cannot even determine which Server or Printer the Print Queue was discovered from and there are no relationships or references to other CIs (e.g. Installed On would be a nice attribute to have but does not exist). 

[LoXodonte]

Hello, thank you for the information. We would like to know how we can relate a Print Queue CI, to a Printer CI so that when an incident is created referencing a Printer CI, the queue objects are also associated, and easily viewable without going down a rabbit-hole drill down in Service Now. 

We are customizing our printer form and as we are logically organizing the fields we have determined that certain fields could be better suited for the Print queue CI, at least IF it is easy to access from the Printer CI as a child object. We want to customize our Queue CI to include custom fields such as Queue Name, Share Name, Server, Group Restriction, and Data class. However, this information is only useful to us if we can view all the Print queues from within Printer CI, and is also only useful if Print Queue CI's can have status info as well. Printer CI's have a status to distinguish if they are deployed, deprecated, etc, but there doesn't appear to be anything out of the box to identify, or manage the state of a Queue CI - which seems odd given queues are just as likely, if not more likely to change states. Is it possible to delete or change the state of Queue CI's, and can they be associated with a Printer CI in multiples and easily viewable; acting as a child object of a Printer CI?

Rename Printer scenario

1.) Tech creates a ticket to rename a print queue which has just changed locations.

2.) We would like this Tech to add a Printer CI to the ticket, and then update the Printer CI information manually: the changes will be tracked in the CI log which our escalation team can reference to identify changes which need to occur on the production objects. Basically, asset tracking and the desired Administration changes can occur in one shot. 

3.) The tech updates the location information of the Printer CI, but also needs to update the Print Queue CI information because the share name is dependent upon the location.

4.) How can the tech easily identify all associated queues, and update them? How would this be performed in a scenario where a queue needs to be deleted or retired?

If this sort of management is not feasible, or if there is an alternate workflow for which print queues were imagined to be used, I would like to be informed. Otherwise it would make more sense for us to consolidate the information of the Print queue CI, into the record with the Printer CI. There are obvious downsides to this given that print hardware can have multiple queues, but this is purely a workflow issue where our decisions would be based on what we most commonly see, and what is going to be the most efficient.