Yes, just looking at one of such Windows host.. Possibly, not all the packages can be discovered or the information about the packages as to collect the info about the package list discovery is using getPackageList WMI method. There are 5 different locations and to speed up this process, a temp WMI class is being created on a remote machine. Could be that some of the locations are not being aggregating properly and thats how the counting is failing..? Or in case of Windows - it could be a registry records, that are orphan and that in reality the package has been uninstalled already, however the record is still there..
Dunno about the Solaris though.. No access to certain files can be an option?
Thanks for your explanations. But I still don't understand why the count is different, and what that means to me.
The docs says package_count is "The number of packages".
But why do we even need an explicit attribute for the package count?
There are some other interesting things I obeserved that may be related to this mismatch.
For a windows server I have these values:
Item Count Attribute "package_count" 312 Related packages (through Host:HostedSoftware:InstalledSoftware:Package) 249 Section "getPackageList" (on the DiscoveryAccess)
Packages shown on "DiscoveredPackages" node 156
1 of 1 people found this helpful
This is not expected. Please create a ticket with customer support.
2 of 2 people found this helpful
So, I did a little checking on this in my environment.
I don't think this is a problem within Discovery, but rather an indicator of other problems in the systems being discovered
Here is an example of Windows, where the package_list is different than the get_packages() method. It appears there are duplicate entries in the Windows package manager:
Here is an example on Linux. In my case, the only linux examples where the package count differed was when the access method to Linux was via SNMP, not SSH. SNMP does not pull back enough details to uniquely identify packages:
Here is my modified Query:
//search for mis-mached package counts in the last 28 days
where package_count <> nodecount(traverse Host:HostedSoftware:InstalledSoftware:Package)
and nodecount(traverse Host:HostedSoftware:InstalledSoftware:Package) > 0 and last_update_success > currentTime() - 28 * 24 * 3600 * 10000000
4 of 4 people found this helpful
Fundamentally the package commands expect the reported packages to be unique. If they are not then you end up with a different number of Package nodes to the number of reported packages.
I've opened a Support Case to investigate this issue.
Hi Andrew Waters,
I've opened a Support Case to investigate this issue. They directed me to your comment, so maybe you can give me an answer to my question:
Why BMC Discovery treats the package count as a separate attribute, which can be different of the actually package count?
There is just one more place where the count of related items is explicitly shown, which is patch count.
Whats the purpose of those "count" attributes?