False positive Inventory - We can't rely any more on inventoried data ! Software reporting false...

[Pascal KOTTE]

That's really amazing, but I see an Altiris 8.1 installation where the integrated inv_AddRemoveProgram "table" are not updated correctly.

Currently I check the Gather inventory with reset data option is setup (delta deactivated), and correctly running those computers. Logs seems OK.

But I still see a software, into the AddRemove dataclass, WITH the install flag on '1', all the same was removed from weeks...

So reports are wrong !

More over, when I try to use the "detection rules" instead, to make sure a software is there, or not, I discover some my previous colloeagues were using a detection rule putting the '>=' on version ! So of course, the 5.5 version was also compliant and compatible with the 5.0 version, and the platform is detecting both software component on all machines, the 5.0, installed in the same time the 5.5 version... OK was a very bad use the detectin rules, and I promess I was never make any recommandation to do this.

I change the detection rule, with '=' instead, and I run compliance with 3 new policies all 3 components, with 1 detection rule based MSI code, 2 detection rules based a file version checking...

The computer with a file with 5.5 version, is still reporting OK compliant with a detection checking a "5.0" ! Is the detection rule failed, is compliance "flag" into CMDB not reset correctly ?

No idea, but I can't reinstall from scratch a new database just to workaround this issue !

Any people any idea what's happen, and how to solve ?

[Pascal KOTTE]

Of course, I already apply this 

https://support.symantec.com/en_US/article.TECH249786.html

for the 1st part, our issue not related the second part, and removing the current 2'458'255 files inventoried, is it a fgood idea ? 

I am ready to clean the 1910 rows there

SELECT *
FROM ResourceUpdateSummary
WHERE InventoryClassGuid = 'A3855A05-D687-4969-8356-94717DF261F2'

But is it ?

InventoryClassGuid ResourceGuid CreatedDate ModifiedDate RowCount SMSForwardDate DataHash DataLastChangedDate

A3855A05-D687-4969-8356-94717DF261F2 5DF98865-1B04-49BA-98EF-00352404B8A0 2015-07-22 13:53:26.750 2015-07-22 13:53:30.293 18 NULL NULL 2015-07-22 13:53:30.293

A3855A05-D687-4969-8356-94717DF261F2 64AD54DD-B0A8-47F0-A3AE-003E177F82D0 2015-06-24 12:50:40.333 2017-10-02 13:38:10.797 794 NULL NULL 2017-10-02 13:38:10.797

A3855A05-D687-4969-8356-94717DF261F2 E2DA8DF3-8F03-46AD-93B9-00846F236E4F 2015-09-30 12:37:52.477 2018-06-04 12:44:23.713 805 NULL NULL 2018-06-04 12:44:23.713

A3855A05-D687-4969-8356-94717DF261F2 3F8887A5-30BA-45C6-92FA-0088EDAA14B0 2016-02-17 16:20:38.577 2018-06-20 13:30:58.470 1355 NULL NULL 2018-06-20 13:30:58.470

A3855A05-D687-4969-8356-94717DF261F2 CFF31144-488F-49D5-B0C8-00A084B5E82D 2015-08-04 11:22:30.243 2018-06-20 12:38:25.750 658 NULL NULL 2018-06-20 12:38:25.750

A3855A05-D687-4969-8356-94717DF261F2 5FCAD66E-BBFB-4E53-93E2-00A5C3E18C88 2015-07-01 13:07:13.880 2015-09-09 13:04:15.310 1369 NULL NULL 2015-09-09 13:04:15.310

A3855A05-D687-4969-8356-94717DF261F2 FC105B67-0FFD-4D84-9CD3-00B55FE9501C 2015-07-01 12:48:12.177 2018-06-20 12:48:46.430 774 NULL NULL 2018-06-20 12:48:46.430

[Juri Zenkevits]

Hi Pascal,

I think, you better should escalate the issue to Symantec team and our guys will help to pin-point the problem.

Before you delete lot's of stuff, we better find out what cause all this to avoid issue to repeat next time...

It can be:

 * resource update summary table corrupted (so, new data is not really being saved into DB, as the data hash matches the one in ResourceUpdateSummary)

  generally, it's quite safe to delete entries in that table - forcing new inventory to bypass hash checks and writes if there any

* issues with resolving links (associations) from 'software' to 'file' - these are harder to find, would require quite a bit of work on NS machines with such problems and some Symantec dev tools for it

* licensing glitches, when inventory NSE just not being written, because a license for this particular machines was taken away to some other computers (rare stuff, and usually produces lots of errors/warnings in server log)

 * duplicated resources (files/software components) with resource keys matched wrong way

* simple report bugs, that shows incorrect info, while it's really could be fine in DB.

Usually, when customers start to cleanup db manually - it can ends up quite .. messy ..

Beleive me, resoling all this software management issues is something, that is not as easy, as we think see at first glance.

 

[andykn101]

I seem to remember from the 7.n days that Software (file) Inventory uses different local cache (delta) files than the ghardware inventroy and that these sometimes aren't cleared by the Full inventory wipe that deletes the BAK files.

To see where the incorrect records are coming from:

Software Components

“What does the Source number indicate for Software Components, including referenced in Installed Software?”

• 1 – Msi scanner
• 2 – Inventory rule
• 4 – File list
• 8 – Add Remove programs entry
• 16 – Patch
• 32 – Server
• 64 – “Software Catalog Data Provider” using the rules provided by PC-Ware

http://www.symantec.com/docs/HOWTO84082

[Roman Vassiljev]

Hi Pascal,

 

Firstly I would like to comment KB article https://support.symantec.com/en_US/article.TECH249786.html (Inventory File data shows files existing on computers where the file has been upgraded or removed). 

In your case method for file scan really does not look applicable as it resolves issues with inventoried files, but not software. Unless you use Software Catalog Data Provide Inventory task for discovering software based on inventoried files. Do you use it? If not then I don't think that removing records from Inv_Installed_File_Details may help to resolve your problem

 

Secondly I agree with Juri Zenkevits, it may be more efficient to work with Symantec support to localize root cause of your observation.

Anyway it would be good to have more details, so could you please collect the following information for one of affected computers(if you escalate this problem to Support then provide them with this information):

 

1) You mentioned that Inv_AddRemoveProgram table contains record for Software with the install flag = '1' for affected computer, however you believe that this software is not installed on computer already. How did you verify it? May you please provide screenshot or output from Inv_AddRemoveProgram with remarks what computer/software are reported incorrectly. Just to double check that Computer ResourceGuid and SoftwareComponentGuid match to affected computer and software.

 

2) May you please also make screenshot or output of 'Programs and Features' from Control Panel of affected computer?

 

3) May you please run non-delta Software Inventory Scan once again on affected computer but with additional steps

3.1) Enable Trace logging of Symantec Management Agent before running scan

3.2) Enable capturing NSE files before running scan. 

to capture NSE on affected computer set the following registry key on this computer

[HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Transport]

"Capture Events Folder"="c:\\NSECaptures"

3.3) Provide Agent log captured during scan

3.4) Provide NSE files captured during scan(located on affected computer at location set in registry key in step 3.2)

3.5) Provide Software Cache file created by executed scan after scan is completed. This is XML file located at C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\data\SoftwareCache.xml

3.6) May you also provide SMP logs from server captured in timeframe between "scan is started" and "scan results appear on NS'

 

4) You mentioned that you used detection rule in order identify "is software installed or not " using alternative approach. Does it mean that you used targeted software inventory policy? May you please provide screenshot of rule you used? Or you may export rule as XML and provide this XML file

 

5) It would be nice to have agent logs captured with Trace level when those detection policies are executed on affected client.

 

6) You mentioned that "compliance "flag" into CMDB not reset correctly". May you please clarify what do you mean? Is my understanding correct that you expected to see compliance status changed after you had modified detection rule? May you please provide more accurate description what rule was used before change and what rule was used after change(if you may provide screenshots it would be the best option)?

 

7) You mentioned that you tried to detect software using file version check. Is it possible to provide this file as well, so that you may try to reproduce

detection problem in-house

 

Sorry for a lot of questions/requests, but we need them to localize problem as root cause may be in different places..

 

Thank you,

Roman