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
Jan 06, 2020 10:12 AM
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.
Jan 06, 2020 08:10 PM
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
Jan 07, 2020 06:17 AM
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.
Jan 07, 2020 07:56 AM
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
Jan 07, 2020 08:00 AM
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
Mar 03, 2020 05:08 AM
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
Mar 03, 2020 05:46 AM - edited Mar 03, 2020 06:48 AM
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.
Mar 03, 2020 07:40 AM
@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.
Mar 03, 2020 07:47 AM
Mar 05, 2020 07:51 AM
Mar 05, 2020 11:59 AM
Mar 05, 2020 12:20 PM
Mar 05, 2020 12:30 PM