"Display Name" of SW record is different than "Discovered Product" of Discovery model

[PCN12]

I manage normalization of SW data. In my training it was explained to me that cmdb_sam_discovery_model is aggregated data of cmdb_sam_sw_install table. It came to my attention that there are instances where “Display name”( which is afaik name of software as it is discovered by the tool) in the sw install table is not in sync with “Discovered Product” in cmdb_sam_discovery_model table.

I see this for a few records of Red Hat, IBM, and other publishers. But it is not consistent.

Example:

Sw record “redhat-release” is in DM discovered product: “Red Hat Red Hat Enterprise Linux X.X”

Some sw records with “redhat-release” is in DM “redhat-release” (no changes)

For both the primary key of these discovery models displays “Red Hat.redhat-release*).

The changing from redhat-release to “Red Hat Red Hat Enterprise Linux X.X”  causes a two version in the DM and hence is excluded from automatic normalization (weirdly enough the versions are different).

Most of the difference between display name in sw install table and discovered product in DM goes align with what is done during normalization. I checked SN Knowledgebase for information about this behavior but unsuccessfully.

My first question, is the update of the discovered product field of the DM an OOB SAMPro feature? If so, where can I find more information about it?

Second question, when content team creates normalization rules, is it based on the values in Discovered Publisher, Discovered Product and Discovered Version field or is it based on the value of the Primary Key of the discovery model?

Thank you for your help!

[dreinhardt]

Hi @PCN12,

would be great if you could attach a few screenshots to give us a better understanding/visualization of the current issue.

My first question, is the update of the discovered product field of the DM an OOB SAMPro feature? If so, where can I find more information about it?

Second question, when content team creates normalization rules, is it based on the values in Discovered Publisher, Discovered Product and Discovered Version field or is it based on the value of the Primary Key of the discovery model?

No, a different "discovered product" will result in a new discovery model. As the primary key is the matching criteria and is based on the already mentioned values (Discovered Publisher, Discovered Product and Discovered Version). The seens display name is without the publisher and not relevant for matching.

Best, Dennis

[PCN12]

Hi Dennis,

Thank you very much for your reply.

Provided screenshots of xml and DM table to show you what I see. From your answer I take it that this is not intended:

   

Regards,

Karin

[dreinhardt]

Hi @PCN12 

This is strange, because my Red Hat Enterprise Linux Discovery Models are all imported with an expected primary key. What source is the data coming into your system from?

If the results indicate increased effort during normalization, please contact support to determine the cause for the data. If it only affects individual entries, you can probably just ignore it and normalize them manually, right?

Best, Dennis

[PCN12]

Hi Dennis,

Yes, it impacts normalization effort, and we are using custom code. What threw me off is that from all the packages that are discovered for Red Hat, redhat-release is the one that is renamed. And redhat-release is what normalization uses in discovery model table to map to licensable RHEL product.

Before I make a fuss and ask them to stay away from my Discover Model table, wanted to make sure that this is not an OOB feature. I wouldn't live it down 😄

Anyways, appreciate your input and help very much!

Best,

Karin