cmdb_sam_sw_install and Discovery

ctsmith · ‎03-28-2023

Does anyone find cmdb_sam_sw_install table straight up unwieldy? It keeps a lot of stale records, the discovery sources often don't use the active flag (InTune keeps them active flag at false, ACC Visibility marks it as true) at all, or poorly at best.

And I can't seem to write a reconciliation rule to allow one discovery source to rule over another on this table. The table is not selectable in the hierarchy.

I have a BR that parses out version numbers and deletes all but the highest values but that is not ideal because that highest value might not actually be the true installed version.

And Discovery sources (InTune, SCCM, and ACC) do not seem to update, overwrite each other's records. If SCCM shows Sentinal One 1.1.1 and ACC shows 1.1.2 don't just leave the 1.1.1 record there and add another 1.1.2 record on top of that. That is confusing for reporting and auditing purposes. A report shows this person is running the outdated Sentinal One version 1.1.1 on their machine and is vulnerable, let's audit it; actually, no, it does have 1.1.2... or does it have both on there?

Any thoughts on handling software version more accurately when you've got multiple Discovery sources and you don't seem to be allowed to have one take ownership of the attributes for the software installations?

How do you all handle keeping this table fresh without BR or table cleanup trickery?

Rahul Priyadars · ‎03-28-2023

Are u using SAM Normalization ?

Regards

RP

ctsmith · ‎03-29-2023

Not really. We're in the process of setting up SAM Normalization and the jobs are running but not really doing anything as of yet. But I assumed that to be more for software entitlements and license reconciliation thing. This should really be happening at the IRE level beforehand where a discovery source owns the table and/or attributes for inserts/updates.

Rahul Priyadars · ‎03-29-2023

Discovery sources (InTune, SCCM, and ACC) do not seem to update, overwrite each other's records. If SCCM shows Sentinal One 1.1.1 and ACC shows 1.1.2 don't just leave the 1.1.1 record there and add another 1.1.2 record on top of that. That is confusing for reporting and auditing purposes. A report shows this person is running the outdated Sentinal One version 1.1.1 on their machine and is vulnerable, let's audit it; actually, no, it does have 1.1.2... or does it have both on there?---->do u have data source precedence and recon rules configured

One example for ur reference where u can control the updates from various sources-

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/ta...

(When using Identification and Reconciliation Engine (IRE), you can prevent a specific discovery (data) source from inserting new CIs for a specific class. Create IRE data source rules for discovery sources that you don't trust in creating CIs but continue to trust in updating those CIs that exist.)

Regards

RP

ctsmith · ‎03-29-2023

That's exactly what I'm saying from my initial post. I'm not really looking for a lesson on IRE and reconciliation; I understand the methods and use them currently. But in this case, none of the IRE/precedence rules are configurable for this table. That screenshot you sent me... Try to select the software install table.