Symptoms

After installing Software Asset Management, and re-running Discovery, when looking at the Software Installations related list on a Server form in the CMDB, you may not have any software listed.

Release

All 

Causes and Resolutions

The 'Software Installations' related list is not there

Only some Form Views have the related list added out-of-box. 

Solution:

• For other forms, such as AIX Server, HP-UX Server, Solaris Server, you can customize the form's related lists to add this.
• For other forms that should have it, such as Windows Server and Linux Server, previous customisations may have blocked it being updated, so these too can be customised to add it.

I have a 'Software Installed' related list instead

Before installing Software Asset Management, Discovery and SCCM imports will populate the Software Installed [cmdb_software_instance] table instead. When SAM is installed, that related list should be automatically replaced by the Software Installations [cmdb_sam_sw_install] one. If you have previously customised the related lists of the form, the changes by the plugin activation may have been skipped.

Solutions:

• Check that you do actually have the Software Asset Management (premium/professional) plugin installed.
• You can customize the form's related lists to remove 'Software Installed' and add 'Software Installations'
  '

The 'Software Installations' related list is empty

There are several causes of this, and here are a few:

cmdb_software_instance records were not migrated

The plugin activation should run a script to migrate the cmdb_software_instance records to the new cmdb_sam_sw_install table.

You can check that has happened by navigating to Software Asset - System - Migrate Software Installs, and you should see "Data has already been migrated"

Solution:

• If migration has not yet happened, this form will allow you to start that

The Server was re-Discovered, but the Installed Software probe or Pattern had errors

There could be a few causes for this too. 

Solution:

• Investigate the error messages in the normal way. There are various KB Articles that can help with this.

The Server was re-Discovered successfully, but Software Installations were not created

One possible cause of this is Probe Caching. This system checks if the data returned from the Probe is the same as last time, and if it is then it doesn't bother re-running the Sensor.

If the Sensor has not run since activating SAM, then it will not have had a chance to insert into the new table yet.

Solutions:

• Turn off Discovery Probe Caching for all probes. This will increase the workload on the instance during Discovery schedules, but is normally fine to do. Set Discovery Property glide.discovery.use_probe_results_cache=false
• Turn off Probe Caching for specific probes, by unticking the "Cache results" Checkbox on the Probe record. Navigate to Discovery Definition - Probes, and filter by name contains Installed Software to get this list:
  • AIX - Installed Software
  • HP-UX - Installed Software
  • Linux - Installed Software
  • Mac OS X - Installed Software
  • Solaris - Installed Software
  • Windows - Installed Software

Note: Since Kingston release, some instances will be using Patterns for fetching Installed Software instead, and so this would not be the cause. Checking the Discovery log would confirm that.

The Windows Server was re-Discovered successfully, and SCCM Integration is installed

The Microsoft SCCM Integrations' can be set to exclusively manage Windows computer Software Installation records. If that is the case, Discovery will not update the cmdb_sam_sw_install table for Windows computers ans servers.

Solution:

• Check the glide.discovery.software_sccm_managed system property. If it is true, it probably should remain that way, and the solution is to re-run the SCCM Imports.

Search the documentation for topic "Discovery and SCCM together".

SCCM and other Import sets run, but fail to update Windows Software Installations

The out-of-box transform map scripts in the Microsoft SCCM Integration plugins' update sets have logic to automatically switch tables after SAM is installed, but if there have been customisations then those may not have that logic and may still be populating the cmdb_software_instance table.

Solutions:

• Check the Import Set and Transform history and debug in the normal way.
• Check your custom Transforms are using the correct cmdb_sam_sw_install table and update them if necessary.