- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi community
I dont have SAM module but i want to track what software versions are installed on ci servers. I was planning on using software instance table and the installed on field on cis. I will also use the software package table and relate it to the software instance table. Can u tell me if this is the correct approach ?
Thanks in advance
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Anthony,
Yes, your approach is correct, and you do not need SAM for this. SAM adds license reconciliation and compliance on top of the install data - tracking what is installed, and where, is core CMDB.
Use the out-of-the-box model instead of building a custom relationship:
1. Software Package [cmdb_ci_spkg] holds the product and the version. Keep one package record per name + version (and edition where that matters), for example Name = Microsoft SQL Server, Version = 2019. The version lives on the package, not on the install record.
2. Software Instance [cmdb_software_instance] is exactly the join you described. Each row links one package to one CI through its two reference fields:
- Software -> the cmdb_ci_spkg record
- Installed on -> the server CI (cmdb_ci / cmdb_ci_server)
So do not relate the package directly to the CI. The instance record IS that relationship, and it is what lets the same package appear on many servers without duplicating the package.
For reporting, build the report on cmdb_software_instance and dot-walk to Installed on.Name for the server and Software.Name / Software.Version for the product and version. Filter on the Installed on CI class if you only want servers.
One thing to plan for: if you later start running Discovery against these servers, let Discovery maintain the install data for the CIs it scans instead of keeping a parallel manual list, otherwise you will end up with stale and duplicate installs. And if you ever activate SAM later, keeping one clean package per name + version from the start makes that move much easier, because SAM reconciles licenses against exactly this kind of install data.
Regards,
Karimuddin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Anthony,
Yes, your approach is correct, and you do not need SAM for this. SAM adds license reconciliation and compliance on top of the install data - tracking what is installed, and where, is core CMDB.
Use the out-of-the-box model instead of building a custom relationship:
1. Software Package [cmdb_ci_spkg] holds the product and the version. Keep one package record per name + version (and edition where that matters), for example Name = Microsoft SQL Server, Version = 2019. The version lives on the package, not on the install record.
2. Software Instance [cmdb_software_instance] is exactly the join you described. Each row links one package to one CI through its two reference fields:
- Software -> the cmdb_ci_spkg record
- Installed on -> the server CI (cmdb_ci / cmdb_ci_server)
So do not relate the package directly to the CI. The instance record IS that relationship, and it is what lets the same package appear on many servers without duplicating the package.
For reporting, build the report on cmdb_software_instance and dot-walk to Installed on.Name for the server and Software.Name / Software.Version for the product and version. Filter on the Installed on CI class if you only want servers.
One thing to plan for: if you later start running Discovery against these servers, let Discovery maintain the install data for the CIs it scans instead of keeping a parallel manual list, otherwise you will end up with stale and duplicate installs. And if you ever activate SAM later, keeping one clean package per name + version from the start makes that move much easier, because SAM reconciles licenses against exactly this kind of install data.
Regards,
Karimuddin
