Software Fingerprint Information

[Shwetanjali]

Hi there,

Currently OCP provides information about the installed software in the form-
name: SQL Server (MSSQLSERVER), software_version: 14.0.1000.169
name: SQL Server Analysis Services (MSSQLSERVER), software_version: 14.0.1.439

However, I need information in the form where in it gives information also about the edition within the name, i.e.-
name: Microsoft SQL Server 2019 (64-bit), software_version: 14.0.1000.169
(similar to the information available in Control Panel>Program>Program and Features in windows)

Also, it also fails to provide information on the certain installed software.

Could you please suggest a work around for this.

[codingadvocate]

Looks like you’re running the dynamicDiscovery jobs. Those get information from RUNNING software, not INSTALLED software. There’s actually a VERY BIG difference between those two categories, and how you gather data for Software Asset Management (SAM). The dynamicDiscovery jobs start with active processes, in order to gather data about the software.

If you want installed software, you can create a job to go after content in the respective package managers. It’s pretty straightforward to run a command to list all packages, e.g. on Linux through yum, rpm, debian, etc. Or similar on Windows with MSI packages from Win32_Products, and the two main registry locations for add/remove programs.

Sometimes that’s useful, but it depends on the use-case and why you want the data. For example, the package managers will not provide what you need for a ITSM SAM solution. You won’t be able to find software that is provisioned to servers, outside of that manager… like enabling software through auto-provisioning tools, using a custom installer, something without an installer, etc. All of which are very common.

So you have two options:
1) Use a tool that has a large software fingerprint type repository, to be able to normalize the libraries/files/etc found. All the proprietary vendors listed on the main opencontentplatform.com page, do it this way. That methodology requires the vendor’s repository to already know about the software, before you can identify and track it… which leaves a lot of software out.

2) Use a tool that is able to dynamically discover signature data, without creating and maintaining a bunch of manual software signatures. The dynamicDiscovery jobs do it that way. And FWIW, this is the only tool I’ve seen that does it this way. Since it does it this way, any new software is automatically picked up and tracked (even when it’s internally developed software that a discovery product would never have seen before). However, it only profiles RUNNING software – not all the other binaries sitting on the disk.

[Shwetanjali]

Hi,

Thanks for your response. For now, my purpose can be solved just by using queries like “Get-WmiObject -Class Win32_Product”.
I found a script within OCP which can actually serve my purpose-“shared.shell_OS_software_packages.py”

However, the job (shared.powershell_OS_software_packages.json) for running the script has trigger point in the format-
“triggerType” : “date”,
“triggerArgs” : {
“run_date” : “2018-06-05 11:58:00”

I changed it to the format-
“triggerType” : “interval”,
“triggerArgs” : {
“weeks” : null,
“days” : null,
“hours” : null,
“minutes” : null,
“seconds” : 15,
“start_date” : “”,
“end_date” : “”
}

But the job didn’t run. Could you please advice, how can I run this job so that I can get output from it. If I am not wrong the api to get this data would be- …/ocp/data/SoftwarePackage

[codingadvocate]

Yep, that job uses the package managers as I mentioned above. On Windows, it’s pulling from from Win32_Products, along with the two main registry locations for add/remove programs.

If you want it to run, either use the API or the Admin Console GUI to change the job schedule (like you just showed), and then enable the job. So, make sure to change “isDisabled” to false.

I’m not sure what version of OCP you’re using, but if it’s old enough you may be able to just change the file on the server filesystem. You may have to restart OCP to pick up the file change (again, depending on the version). Newer versions use the job settings (schedule, parameters, etc) from the database table, so changing the file won’t matter after install… unless you update the package after changing the file.

But yes, all in all – change the schedule, enable the job… and it should gather that data.

[codingadvocate]

Oh, and yes… ocp/data/SoftwarePackage is one way to pull it out. That would show a bunch of objects like this:

{
“time_created”: “2021-04-01 15:03:24”,
“time_updated”: “2021-04-01 15:03:24”,
“time_gathered”: “2021-04-01 15:03:20”,
“object_created_by”: “powershell_OS_software_packages”,
“object_updated_by”: “powershell_OS_software_packages”,
“description”: “Caution. Removing this product might prevent some applications from running.”,
“caption”: “Microsoft Visual C++ 2017 x86 Debug Runtime – 14.14.26405”,
“name”: “Microsoft Visual C++ 2017 x86 Debug Runtime – 14.14.26405”,
“version”: “14.14.26405”,
“associated_date”: “20180626”,
“recorded_by”: “Windows Product from WMI”,
“company”: “Microsoft Corporation”,
“vendor”: “Microsoft Corporation”
}

[Author]

Posts