"Status" and "Install count" fields on cmdb_ci_spkg

[seberly]

How do the "Status" and "Install count" fields on cmdb_ci_spkg get populated?   It looks like Discovery is trying to or does in some way, but the seem to be a bit out of date.   "Install count" doesn't seem to be consistent with the "Installed on" related list, and there are records where "Install count" is 0 but the "Status" is "Installed".   Doesn't quite line up for me.   Anyone have insight here?

[jake_mckenna]

I would check out Software Asset Management plugin for a more updated setup for which tables to use related to software in your environment. I believe these process are more current to track installations and the use of counters is more reliable toward compliance. See links below for more detailed information

Discovery with the Software Asset Management Table Schema - ServiceNow Wiki

Software Asset Management - ServiceNow Wiki

[seberly]

Thanks for the quick reply, Jake!   So, the main problem I have with this article is that, although the diagram on the linked page would you lead to believe that the cmdb_sam_sw_install table is a child of cmdb_ci (or even a descendant at any level), it doesn't actually seem to be one.   Both looking at the schema map for cmdb_sam_sw_install and querying for a cmdb_sam_sw_install record on cmdb_ci give evidence to this fact.

The need I have is for someone to select on task.cmdb_ci, a reference that describes a software package - meaning not the specific installation of that package on a device, but ideally the package that is deployed to that device. (ex: We have a problem with the package of Microsoft Office 2013 that is deployed in our environment due to an improper configuration of that package.   I would create an incident, and I would select Microsoft Office 2013 as the "Configuration item").   Today we have task.cmdb_ci on the Incident form.   We are using this heavily, but just realized you cannot select anything that describes a software package.   This is partly due to a reference qualifier on task.cmdb_ci we have configured that limits the CIs you can select by class - this to eliminate the mess of unmanaged CI classes added to the CMDB by Discovery.   I would like to figure out what class I should add to the reference qualifier to solve my problem.

Maybe I'm asking the wrong question.   Maybe there's a better way to go about this.   Thoughts?

[jake_mckenna]

I think in general even with the plugin is enable that table is still populated, but the practice that i see is more along the lines of still assigning the incident to the users machine and that would be managed from a software category/subcategory indicating the type of issue. In this case we can see all the packages installed with that machine and match it with certain builds that might be affecting other Workstations with this model type.

Although this is a pretty heavy topic when you get down to it and managing it really comes down to who is best to resolve this issue based on the category and CI recorded.

[seberly]

I am there with you on "Configuration item" driving assignment.

But how would you how suggest we track that incident was for a specific package (cite my example above)?   In other words, it would be helpful to track that 100 incidents last week were for software packages (category/subcategory), but I would actually like to get more granular than that to say that out of those 100 incidents last week that were for software packages, I had 20 that were for Microsoft Office 2013.

How do suggest I accomplish that?

Thanks,

Scott