Marking Active Install as False in cmdb_sam_sw_install table in SAM Pro.

anandsaurabh47
Tera Contributor

Hello All,

 

We have integrated Systrack application in ServiceNow to bring Software Installation details in cmdb_sam_sw_install table. And, it's creating a new record of Software installation every time in the table even in case of minor update also. In this way, It's keep on creating multiple versions of the software. E.g. I have 15+ records of Adobe Acrobat, Zscaler, etc in same device with minor changes in the versions.
1. Is this expected behavior, If not then how it can be fixed. I am not developer but I am working with the development team.
2. I read about the Active Install, De-Duplication scheduled job. But technically this is not exactly the duplicates, but same record with version change so If De-duplication scheduled job can identify these as duplicates
3. Development team proposed a solution to flag Active install as False or all lower version. Should we implement this as this OOB field.

Please help!

1 ACCEPTED SOLUTION

SAMfluencer
ServiceNow Employee

Hi @anandsaurabh47 ,

 

I would suggestion trying below recommendation.

 

1. Is this expected behavior?

Partially - but it's a configuration problem, not a platform limitation.

Systrack is designed to track granular software inventory including minor version changes. When it pushes data into cmdb_sam_sw_install , if the integration transform map is not configured to match and update existing records (upsert logic), it will simply insert a new row on every sync cycle.

 

How to fix it: The development team needs to review the Import Set Transform Map for the Systrack integration and ensure a coalesce field (match key) is defined. If a match is found using the coalesce fields, the existing record will be updated with the information being imported. If a match is not found, a new record will be inserted into the database.

 

https://therockethq.gitbooks.io/servicenow1/content/index/index/fundamentals/fundamentals-concepts/i...

 

If the goal is to treat minor version bumps as updates to the same install record, exclude version from the coalesce and let the transform map update the version field in-place on match.

 

https://www.servicenow.com/docs/r/yokohama/integrate-applications/system-import-sets/c_ImportSetCoal...

https://www.servicenowelite.com/blog/2014/3/30/coalesce-methods

https://www.servicenow.com/community/developer-blog/servicenow-things-to-know-70-indexing-coalesce-f...

 

2. Will the Active Install De-duplication Scheduled Job catch these?

 

No - not reliably.

 

There are duplicate software install records on cmdb_sam_sw_install  with different Discovery Sources, and the expectation after running the "SAM - Deduplicate Install Table"  job is that Active Install is updated https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0958768 but this only works when records are true duplicates. Since your records have different versions, the job won't treat them as duplicates.

 

https://noderegister.service-now.com/kb?id=kb_article_view&sysparm_article=KB1123484

 

3. Should you implement the dev team's proposal to flag lower versions as Active Install = False?

 

Reasonable short-term workaround, but needs guardrails.

 

When the same software installation is discovered by multiple discovery sources, only one will be set to active = true. The remainder will be set to false. This is to avoid double-counting in reporting. https://www.servicenow.com/community/sam-forum/significance-of-quot-active-install-quot-field-on-the...

 

The most common scenario where Active Install = False is during installation de-duplication. There is not an automatic job that invalidates stale installs. You can also manually set this field to false. https://www.servicenow.com/community/sam-forum/what-marks-or-sets-software-installations-cmdb-sam-sw...

 

Another scheduled job that updates the Active Install field is SAM - Deduplicate Install Table. This job runs daily by default.  https://www.servicenow.com/community/sam-forum/what-marks-or-sets-software-installations-cmdb-sam-sw...

 

https://www.servicenow.com/community/sam-blog/understanding-the-inner-details-of-software-install-cr...

 

If this helped - amazing, you're welcome, go click Helpful and Accept as Solution. If it didn't - well, at least you learned what not to do. Either way, we grow. 

 

Cheers, Abby

ITAM Principal Solution Architect

View solution in original post

3 REPLIES 3

SAMfluencer
ServiceNow Employee

Hi @anandsaurabh47 ,

 

I would suggestion trying below recommendation.

 

1. Is this expected behavior?

Partially - but it's a configuration problem, not a platform limitation.

Systrack is designed to track granular software inventory including minor version changes. When it pushes data into cmdb_sam_sw_install , if the integration transform map is not configured to match and update existing records (upsert logic), it will simply insert a new row on every sync cycle.

 

How to fix it: The development team needs to review the Import Set Transform Map for the Systrack integration and ensure a coalesce field (match key) is defined. If a match is found using the coalesce fields, the existing record will be updated with the information being imported. If a match is not found, a new record will be inserted into the database.

 

https://therockethq.gitbooks.io/servicenow1/content/index/index/fundamentals/fundamentals-concepts/i...

 

If the goal is to treat minor version bumps as updates to the same install record, exclude version from the coalesce and let the transform map update the version field in-place on match.

 

https://www.servicenow.com/docs/r/yokohama/integrate-applications/system-import-sets/c_ImportSetCoal...

https://www.servicenowelite.com/blog/2014/3/30/coalesce-methods

https://www.servicenow.com/community/developer-blog/servicenow-things-to-know-70-indexing-coalesce-f...

 

2. Will the Active Install De-duplication Scheduled Job catch these?

 

No - not reliably.

 

There are duplicate software install records on cmdb_sam_sw_install  with different Discovery Sources, and the expectation after running the "SAM - Deduplicate Install Table"  job is that Active Install is updated https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0958768 but this only works when records are true duplicates. Since your records have different versions, the job won't treat them as duplicates.

 

https://noderegister.service-now.com/kb?id=kb_article_view&sysparm_article=KB1123484

 

3. Should you implement the dev team's proposal to flag lower versions as Active Install = False?

 

Reasonable short-term workaround, but needs guardrails.

 

When the same software installation is discovered by multiple discovery sources, only one will be set to active = true. The remainder will be set to false. This is to avoid double-counting in reporting. https://www.servicenow.com/community/sam-forum/significance-of-quot-active-install-quot-field-on-the...

 

The most common scenario where Active Install = False is during installation de-duplication. There is not an automatic job that invalidates stale installs. You can also manually set this field to false. https://www.servicenow.com/community/sam-forum/what-marks-or-sets-software-installations-cmdb-sam-sw...

 

Another scheduled job that updates the Active Install field is SAM - Deduplicate Install Table. This job runs daily by default.  https://www.servicenow.com/community/sam-forum/what-marks-or-sets-software-installations-cmdb-sam-sw...

 

https://www.servicenow.com/community/sam-blog/understanding-the-inner-details-of-software-install-cr...

 

If this helped - amazing, you're welcome, go click Helpful and Accept as Solution. If it didn't - well, at least you learned what not to do. Either way, we grow. 

 

Cheers, Abby

ITAM Principal Solution Architect

anandsaurabh47
Tera Contributor

Thanks @SAMfluencer 
Now my client also wanted to track all the previous versions installed (recommended by internal teams) for future reference. While I don't see this fruitful to keep record of those version in cmdb_sam_sw_install table which is not truly available in the devices. And, this table should be the exact replica of the current software installations in the devices.

However, upon saying that this will contribute to the reconciliation and will impact the compliance, licensing calculation. He suggested again to flag active install - False so that it won't contribute in Reconciliation.

Could you please suggest any other possible solution for this to have the record of previous versions without impacting the reconciliations.