Software Installation Normalization fields

Community Alums
Not applicable

Hi SAM Community,

I've had some questions from a client's Software Asset business users, who are asking for clarification on the Normalization fields that exist on the Software Installation table. The fields are not shown on the default view, but can be seen by adding them to the List view for the Software Installation table [cmdb_sam_sw_install]. These are not dot-walked fields.

The Software Installation table [cmdb_sam_sw_install] contains the following fields:

  • Normalized [is_normalized] (True/False)
  • Normalized Product [norm_product] (Reference to Software Product)
  • Normalized Publisher [norm_publisher] (Reference to Company)
  • Normalized publisher [normalized_publisher] (String)
  • Normalized display name [normalized_display_name] (String)
  • Normalized version [normalized_version] (String)
  • Normalized revision [normalized_revision] (String)

The questions are:

  • Are these fields still relevant on the Software Installation table, or are they now deprecated/redundant?
  • Are there situations or use cases where these fields should be populated with data?

As there are around 9 million records on this table currently, it seems like a waste to replicate the normalization data across millions of Software Installation records.

They are on Quebec currently and using the SCCM 2016 plugin to retrieve software installation data. After the load of data from SCCM, some of these fields, but not always all, are populated for some records but not for others, even when there are 2 records for the same Software Discovery Model, 1 will have no normalization data populated, while the other one will.

The SCCM 2016 plugin's transform script logic is incomplete and doesn't populate these data fields correctly for every Software Installation record, as it's logic does not cover all the scenarios and relies on many of these fields all being empty at the same time, which doesn't not always occur, which is why some of these fields don't get populated.

As this SCCM 2016 plugin is to be deprecated soon in the Tokyo release, and appears to no longer receive support or bug fixes from ServiceNow, would it be correct to advised our business users to ignore these Normalization fields on the Software Installation table and tell them to look at the Normalization fields on the related Software Discovery Model which does have all the normalization data on it already anyway?

All of these fields listed above on the Software Installation table appear to be redundant and unnecessary duplication of data as the data these fields appear to be about are all contained on the Software Discovery Model record [cmdb_sam_sw_discovery_model] related to the Installation where they do get populated correctly.

Does anyone know why these Normalization fields exist on the Software Installation table? are they old and redundant? I know I can fix the transform map script within the SCCM plugin to fill in these data fields correctly, but it seem like effort for nothing when the Normalization information is on the related Software Discovery Model record. We will also be upgrading to the Service Graph plugin to replace the SCCM plugin as well.

 

I have tried searching the community posts, and there are some posts that are similar but they don't answer my questions about if these fields should still be used or not and why.

 

Any expert information would be greatly appreciated.

1 ACCEPTED SOLUTION

Daniel Slocum
ServiceNow Employee
ServiceNow Employee

Hello Leigh,

There is no need to modify the SCCM Transform to populate those attributes. In fact, doing so could cause problems with Reconciliation. Those values are updated and used by the SAM Reconciliation Engine.

Only records tied to a Product that is licensable and Ignore Installs is false are updated, which is why some are empty. How are installs tied to a licensable product? When reconciliation runs, the Discovery Map details found on a Model record are used to build a query to return Discovery Models. Install records related to those Discovery Models are those which are updated provided Ignore Installs is false.

View solution in original post

2 REPLIES 2

Daniel Slocum
ServiceNow Employee
ServiceNow Employee

Hello Leigh,

There is no need to modify the SCCM Transform to populate those attributes. In fact, doing so could cause problems with Reconciliation. Those values are updated and used by the SAM Reconciliation Engine.

Only records tied to a Product that is licensable and Ignore Installs is false are updated, which is why some are empty. How are installs tied to a licensable product? When reconciliation runs, the Discovery Map details found on a Model record are used to build a query to return Discovery Models. Install records related to those Discovery Models are those which are updated provided Ignore Installs is false.

Community Alums
Not applicable

Hi Daniel,

Thank you very much for the response, I did not know the License Reconciliation process is what updates these Normalization fields on the Software Installation records. I was under the impression that the data was all updated from the SCCM import process. The SAM Reconciliation Script Include is protected, so the code is hidden. I can't find any reference in the online documentation to the reconciliation process being what updates these Normalization fields on the Software Installation records.

But anyway, your additional information lead us down the path to find that the instance is currently suffering from a known problem with reconciliation; https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0964607

We are currently in the process of upgrading to a more recent (and patched) version, so once the upgrade is completed, that should address the empty Normalization fields on some of the Software Installation records.

However, it still doesn't answer our other questions of why these fields even exist in the first place, would it not be better to just look at the normalization fields on the related Software Discovery Model and not have all the extra data duplication across hundreds of thousands of Software Installation records?