Oracle installer evidence false positive

[ianphischer]

Wondering if anyone else has seen this.

I have a laptop which is reporting in FNMS as having a lot of Oracle licenceable software installed - database, weblogic, web portal, etc. 

No Oracle products are installed, however I do have the output files from the execution of LMS scripts on some servers. It seems that the content of the LMS script output is triggering the agent into thinking I have Oracle products installed

My laptop is running WIndows, the ndi file refers to unix file paths for InstallLocation. FNMS doesn't seem to care that there is a mismatch

Was going to log as a bug, but thought I'd see what experiences others have had here first

[ChrisG]

I can't quite make any logical story to explain the observations you have made, but I would be pretty certain that the fact LMS script output exists on your computer would not explain what you are seeing here.

You could take a look at what is shown in the tracker.log file from the inventory gathering on your computer - the logging will generally give an indication of what information about running Oracle Database instances has been found to be included in the NDI file.

[ianphischer]

I looked at the tracker.log. Every file under my LMS Script Output is reporting as "has been detected as a possible package registry"

There are no running instances (as Oracle is not installed), yet FNMS reports Oracle products as installed. The only place on the system where any "evidence" exists is in the LMS script output. 

I'll log it as a formal support request

[JensWalton]

Hi Ian

Happy New Year!

If you are running the latest version of FNMS, have you checked the 'Evidence' Tab against the inventory record to see what type of evidence has been picked up?

Common OUI (Oracle Universal Installer) entries can reside in the registry XML files that are being picked up as part of the inventory gathering.

Regards, Jens

[ianphischer]

Hi Jens

Happy New Year to you too. I can confirm that Flexera is trawling the XML files that are the output of manual LMS script execution and using this as evidence to report that Oracle applications are installed on the device. This also explains why I see the evidence in the ndi file from Unix paths when the device is running Windows. It's not behaving correctly that's for sure. I have logged it and will post an update when we have found a resolution

[ianphischer]

Well I said I would post an update when resolved. This is not resolved in my mind, however Flexera engineering have suggested deleting the files is way to "fix" this. The ticket has been closed, however this will be escalated as reporting something as installed when it is not is a fundamental flaw in a product that is designed to assist in software licence optimisation

[andystaig]

There is good evidence that if a folder exists on a server containing LMS Collection Script output files only and no other Oracle evidence, the server will falsely be recognised by the FMNS agent as hosting Oracle products.

There is therefore a high risk that if historic LMS Collection Script outputs have been left on the server, that FMNS will continue to report Oracle usage, when it no longer remains.

This can easily be verified by droping a LMSCollection script output folder and sub-folders onto a server that previously did not report Oracle.

This would appear to be a generic bug in FMNS that needs to be addressed.

The solution would be for an automatic exclusion by FMNS of folders beginning "LMSCollection" (if this is a generic foldername) and/or where *\LMSCollection*\logs\ contains LMSlogfiles.txt

[JeffVoss]

Keep in mind, if Oracle has an audit done, they will run the LMS scripts and that output is what you have to reconcile your licenses too. Having the same false positive in FNMS is good, since you then know you need to clean it up and not have to argue about the false positive during the audit. Also note: you get the agent logs on the machine to help you find the "evidence" and prove it is a false positive. Easier than the auditors running the script and you have no vision into which of the over 300 xml files OUI uses caused the "evidence" to occur. FNMS is an audit defense tool. Having it tell you what the auditors will claim is installed allows you to take action before an audit as part of standard ongoing IT operations instead of crisis mode of figuring out how to prove the evidence gathering is flawed during the timelines of an audit. 

That said, I got a different FNMS engineer than you. They showed how to go through the machines agent log to find out which file contains the "evidence." Then you can validate the xml entry as correct or left over clutter from an uninstall or machine clone operation used to build the machine. If you can prove it is invalid, edit the xml file to remove the entry. Search the log file for the exact evidence entry found and it will lead to which xml file it is found in. Open the xml file to see the details of why it says it is installed. Prove or disprove the details and either remove the entry in the xml file or accept that it is actually installed and count it. 

[andystaig]

@JeffVoss I think you misunderstand the problem here. 

When the LMS script collection evidence itself left on the server is the false evidence that is being found by FMNS and which will not be found by the script itself, it is not helpful.

[andystaig]

1. The primary purpose of the LMS Collection Script is to collect Oracle installation evidence.
2. This includes making copies of relevant oracle XML files
3. This evidence is stored in a known directory hierarchy - this is known and documented and consistent across all users of LMS Collection scripts
4. We therefore know that the files in this known directory hierarchy are point in time copies of other files on the server
5. We also know that the files in this known directory hierarchy are not indicators or evidence of products being installed on the device at scan time, only at that historic point in time
6. The files in this directory hierarchy therefore cannot provide useful evidence that is not either elsewhere on the server or shouldn't exist
7. Data in this folder therefore is either duplicated or is providing a false positive that needs to be investigated.
8. Even after software has been deleted from the server, the existence of this directory hierarchy will mean that the usage will continue to be detected and reported

I understand that we can choose to exclude a known directory, but this is LMS collection data is data that FMNS should not be collecting.

[Danielwaters]

This is common.

Just because you don’t see them installed does not mean from the Oracle POV that you are not receiving residual benefit. The tool is doing the right thing by highlighting this issue since the scripts used by Flexera are identical to the scripts Oracle would use in an audit.

I’m not agreeing with Oracle here but with the data you have now, you can swiftly cleanup. Note some of the options removal can bring instability for future reference.

[andystaig]

Daniel - you misunderstand too.

Take this scenario.
2016. Run LMS Collection script. It discovers oracle db. Collection script results left on server
2017. Delete oracle db cleanly and completely
2018. Run flexera. It will find the LMS collection script results from 2016 and identify that Oracle db is installed.
Run LMS collection script. It will not identify that Oracle db is installed.

Flexera is flagging a false positive that could be avoided by identifying that the XML files are within a known folder hierarchy produced by the LMS collection script

[Danielwaters]

Ok that better clarifies what you are trying to do.

I’ve seen this a few times before, that the collection output has resulted in a trigger and/or that removal of the identification in the tool was not performed. I can’t recall what was done to correct this or isolate it but you can always consume the NDI on a test system to isolate further. It may be a bug but support will need further details as I’ve described.

You could also just delete the files from the server and just save yourself a lot of time.