cmdb_sam_sw_install and Discovery

[ctsmith]

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?

[Canjura]

If you found an answer to your question, can you please share how to setup the IRE rule to the cmdb_sam_sw_install table?

Thank you.

[ctsmith]

@Canjura Na.  IRE is not accessible on that table at all.  SN would like you to buy SAM Pro for any sort of automated normalization that would help alleviate this 😞 

[CátiaA]

Hi, Did you found any solution for this?

[cragland]

I noticed a recent inventory of an ACC workstation. The Recent ECC Queue collected data, but the data did not make it to the cmdb_sam_sw_install table. Is that what you're referring to?