This article discusses the eligibility of file evidence submitted by customers that can be accepted into the ARL for processing. With huge submissions of file evidence, it has necessitated a discussion of filtering evidence of most value while maintaining a high level of quality expected in the ARL.
Adding large volumes of file evidence to the ARL does not contribute to enhancing the quality of the data, unless the file confirms the recognition of important applications (commercial) or allows you to track usage.
Unfortunately, we are not able to manage large batches of unrecognized file evidence exported from the ‘unrecognized file evidence’ tab. These requests create intensive work and are not conducive to the ARL quality and inventory import performance.
The main objective with unrecognized file evidence is not in clearing them from the unrecognized tab, but in filtering out the evidence of most value to your environment and adding those to our library. The remaining evidence in the unrecognized tab will not impact consumption or recognition on the device. This streamlines our file evidence list and facilitates better usage calculation and recognition.
We are interested in working with ‘qualified’ file evidence that is filtered and vetted by you and your team to be useful in tracking usage (along with the commercial application the file allows to recognize).We would also consider the ‘proven to useless’ file evidence that can be validated as ignored by Flexera. A similar approach has recently been adapted for the Unix distribution (unlicensed) files. Overall, we wish to pursue the file evidence submissions on a more focused target with you.
To better focus on file evidence of most value, we would suggest you filter and then export your unrecognized evidence on two basic conditions:
Any significant changes to these criteria will be communicated in advance through Content notifications in the Flexera Community. Once we cover the most important file evidence, we can analyse the remaining evidence you have in your environment and determine the importance in processing and adding them to the ARL.
We work to continually improve the quality of evidence in FlexNet Manager, and a large part of that is the importance of the Flexera community. We have thousands of customers participating regularly in discussions that involve updates and changes to Flexera product and content.
This helps other customers new to the environment or working on similar topics to better understand our process. This also helps us update our content libraries based on customer input. We strongly recommend leveraging the Flexera community to better understand the scale of file evidence that will be of consequence to your environment.
For further details on this issue and a larger context to the task of managing evidence in Flexera, we have an important seminar conducted by our Product Manager Nicolas Rousseau that you can find here-
While we aim to reduce the task of processing large batches of evidence, we are simultaneously focusing on qualitative methods to reduce the impact and presence of unrecognized evidence in the Flexera UI. One method of pursuing this is for us to work on specific scripts that will only filter on evidence of most prevalence in your environment and look to publish a list of file evidence that is required for usage/recognition on that device. This is currently a project in its early stages of development and will be worked on as we expand our evidence quality capabilities.
There is one thing that could help to reduce workload both for customers and content team and it's maintaining consistency. Applications that have been in ARL for quite some time usually have correct file evidence mappings, but somehow this information is not fully utilized when new applications are added to ARL.
For example, file evidences are crucial for recognition of IBM applications and naming patterns do not change much throughout the years. However, often new versions/editions are added to ARL only with installer evidences mapped to them, even though old versions/editions were mainly recognized via file evidences. A lot of analysis and processing time could be saved if updated file evidence mappings were linked to new applications by default.
Another quite common issue - reported unrecognized file evidences are linked with applications "as is", without using wildcards, which means that the whole analysis and reporting exercise has to be repeated quite soon, especially if publisher is releasing minor version updates on a frequent basis.
Hello @Povilas ,
Thanks for this comment.
Indeed, there are good reasons why we are doing this (and I am the one to blame for the "qualified file evidence only" approach, but there are real hopes we can be more clever in expending automatically recognition on installer but also file evidence recognition based on past patterns. This is something that has started (please check the "Unrecognized Installer Evidence" report in this Managing Unrecognized Evidence Training Recording.
I just attached an "Unrecognized File Evidence Analysis" script and made the following answer to a question / remark from @dmathias in the same post that hopefully brings explanation and also perspective on this tricky matter. The goal is that each customer can get a feeling on the high priority evidence to recognize, but also that Flexera uses these scripts on the existing unrecognized evidence data to move from a "ticket based" extension to "Scripted Intelligence" (not to mention an overstated AI acronym!) recommendations.
File evidence recognition is tricky and frustrating. Sorry for the long but hopefully useful answer.
I try to be very clear in this training that in 99% of the cases, installer evidence are the one we need to recognize application... "installer evidence usage" is even provided on Windows operating systems. "This is a reasonable goal to have 0 unrecognized file evidences for Publishers in scope, but file evidence is a lost battle, files should be managed opportunistically when they are the only way to recognize applications (Java, some Tibco applications (we are currently working on this)) or the "unique" client file.
Our content team has suffered for years receiving batches of unrecognized file evidences (50K line export from the screen) with the short comment "please add to ARL".
Based on the Product Name, the files have been linked to the applications, 99% of the cases with "Not for recognition" rule.
Some interesting stats:
The content blog article https://community.flexera.com/t5/FlexNet-Manager-Content-Blog/Managing-requirement-for-File-Evidence/bc-p/246157#M472 states the file evidence will no longer be processed in batches from flat extracts because this is incredible time for no value and it decreases performance. We prefer spending one hour working with a custom to find the right files for 5 commercial applications of a Tier 2 vendor than 5 full days “processing” 4000 files that will all be unqualified and lead to 0 recognition. From an excel export, Flexera does not know the context, the applications (customers have the application managers) and the clever investigation cannot happen.
Long story short, file evidence is about quality and not quantity… the process should be:
We are conscious that we are asking more efforts than just exporting to Excel and sending to Support but with this intelligent collaborative contributions of the most skilled SAM community in the world :), the recognition quality will augment exponentially.
Then, this training opens to an areas that we are going use more: Intelligent Recognition. If we can recognize version 1, 2 and 6 of an application, why would we have version 3, 4 and 5 unrecognized?
We have scripts that can do the job (the Unrecognized Installer Evidence Analysis report shows the data, I attach to the recording announcement a script that does the job on File evidence but is too slow to be a report) and a big exciting track we are starting is to shift recognition from “random tickets opened by customers” to “Extensions recommended by scripts one existing unrecognized evidence data”.
I hope it helps,
Senior Product Manager
@Povilas I have experienced what you describe as well. Version 3.3 of an application has Add/Remove; but Versions 1-3.2 have only unrecognized file evidence. I'm trying to figure out how best to address this from a "hybrid evidence" perspective now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.