Change in Java recognition

[AAlbert1]

The Flexera content team will apply two changes to Java Platform recognition: 

• Stop using installer evidence. Installer evidence can cause false positives (Oracle Universal Installer Evidence particularly) and prevent from using the exemption by file path. Indeed, the exemption by file path works when only file evidence is triggering the application recognition. When a mix of file and installer is causing the recognition, the exemption will not be applied as the installer has no installation context and a safe approach is adopted that leads to not exempting the installation. These Installer Evidence will be linked to newly created ‘Java Unmanaged’ application.  
• Add Javaw.exe to file evidence recognition. Javaw.exe is the non-console version of java and happens sometimes not to be co-installed with Java.exe. Installer evidence normally triggers recognition when java.exe is not present, but this recognition will be stopped (see first item). Javaw.exe signatures will be added with the same version patterns as java.exe for the recognition of Java Platform (commercial). This could cause an augmentation of recognition, but the installer evidence was normally anyway triggering the recognition. 

We remind that on Unix, agents of version 2021R1 or later are necessary to correctly recognize Java (with version and installation path). Previous versions of the agent are just collecting file names (along with their path) and no version or company name... and OUI evidence (that will no longer be used). 

These changes are going to be part of 21st April 2023 ARL Release.  

[GregMisso]

Hi,

Can I please clarify what will happen re. the following - "These Installer Evidence will be linked to newly created ‘Java Unmanaged’ application. "? If the ARL is using file evidence to match the application record and the installer to map to the Java Unmanaged application, can we expect there to be (x2) Java applications recognised on the device ie. Java SE xx and Java Unmanaged xx?

Cheers,

Greg

[PaullCharman]

Hi,

Will this ‘Java Unmanaged’ application include differentiation for Freeware vs Commercial in line with the current ARL entries for Java Platform?

Thanks,

Paull

[bfaller]

As written, the purpose is to stop using installer evidences for Java (and preventing path exclusion). Then the new "Java unmanaged"  application should not be linked with Java licenses. It could be freeware or commercial. It does not change your local work to split between freeware and commercial for umbedded Java, but at least, path exclusion will work when relevant.

[nrousseau1]

Hello @GregMisso and @PaullCharman ,

As @bfaller says, the goal is to make the Java Platform commercial recognized solely through file evidence to have the exemption by file path work always (when a conflicting installer evidence is found on the device, the exemption will not work) and cover the various Java Platform deployment (console java.exe and non-console javaw.exe).

In parallel having unrecognized (or ignored) Java installer evidence will create emotion in these days (where Java is hot)... and some users may want to do correlation on when Java is reported by Installer evidence and not files (Which should never happen).

So, this may add confusion but this will be more efficient.

Best regards,

Nicolas

[PaullCharman]

Are there recommended file paths that need to be scanned for this functionality? 

[GregMisso]

Hi @PaullCharman ,

The Application Transparency Report will be your guide here. You should be able to identify most of the candidate file paths for exemption based on the path itself as this will reference a 3rd party solution in many cases. It is also best to check to see whether the Java license is covered as part of the third party entitlement.

Hope that helps.

Cheers.

[nrousseau1]

Thanks @GregMisso  for pointing to this very useful report (that can work on any of your recognized applications provided you have set the "Import detailed evidence" flag).

We have then a chicken and egg issue, if @PaullCharman your are asking this because you want to enable data collection only for specific path, there is a great variety of paths where java can be found because it can be related to many products (this is the "Embedded Java Instances" topic with the "exemption by file path" solution).

If you don't collect files or want to be selective, I would advise to use the IncludeFile agent setting that you can set through mgssetup.ini at installation time or directly in the registry (You can deploy the keys through an AD Group Policy).

Best regards,

Nicolas

[swannd]

Hi,

I am quite confused by this announcement. Would it be correct to summarise the change like this?

• The existing installer evidence rules in the ARL, used for Java recognition, cannot be reliably used for correct version recognition.
• File evidence is required for correct recognition, requiring the use of the FNMS agent (ie not SCCM).
• The old evidence will be linked to a new ‘Java Unmanaged’ application. As the chosen name includes the word "unmanaged" (a first for the ARL) I assume that it is not possible to manage Java using this application?

Thanks,
Dave.

[Sabbigeri]

As mentioned above, Changes has been completed for Java Platform Installer and File Evidence and these changes are part of latest ARL build 2740.

[GregMisso]

Hi,

I have just had a look at the changes post the ARL update to v2740. I can see the new 'freeware' Java Unmanaged Application, but am confused as to what it's purpose is now. There seems to be an evidence overlap with the existing apps. My understanding was that the installer evidence recognition was to be ignored from the existing apps, but this does not appear to be the case. Was this update configured correctly prior to release?

Cheers,

[bfaller]

In ARL 2740, new Java unmanaged appplication is freeware, which is not correct (see Oracle Java commercial evidence 8.361 and free 8.102). Either classification has to be changed to none, or application has to be splited into freeware unmanaged & commercial unmanaged.

[nrousseau1]

Hello @swannd ,

Please find below the answers to your summary.

• The existing installer evidence rules in the ARL, used for Java recognition, cannot be reliably used for correct version recognition. => [nr]: RIGHT! The other reason is the this installer evidence cause noise that prevent from using the "Exemption by File Path" feature published with ITAM / FNMS 2022R1.
• File evidence is required for correct recognition, requiring the use of the FNMS agent (ie not SCCM). [nr]: On Windows, the SCCM data bring data that is good for java recognition. The ARL does the job with SCCM data (java.exe, javaw.exe) . On Unix, you need the Flexera the catches java -version data, including installation path of the java instance.
• The old evidence will be linked to a new ‘Java Unmanaged’ application. As the chosen name includes the word "unmanaged" (a first for the ARL) I assume that it is not possible to manage Java using this application?  [nr]: This java unmanaged freeware application allows to avoid "unrecognized evidences with questions" and allows to keep an eye on the java installations. Note that only "Commercial" versions of the installer evidence link to this new application.

[nrousseau1]

Hello @bfaller ,

Thanks for giving the way to identify the "Javaw.exe without java.exe", very useful!

I however am not sure to understand the first sentence of your post. We have removed installer evidence from Java Commercial versions' recognition (and linked to a new Java Unmanaged application) and ADDED javaw.exe.

Thanks,

Nicolas

[nrousseau1]

Hello @GregMisso ,

Please see the answer I just made above.

"This java unmanaged freeware" application allows to avoid "unrecognized evidences with questions" and allows to keep an eye on the java installations. Note that only "Commercial" versions of the installer evidence link to this new application.

If you see this "unmanaged" application without a java platform installation, it may be a sign that java.exe and javaw.exe are not here while an installer evidence is here for the commercial application (which would be a surprise thing).

I checked this Sunday on large customer (3K Java Platform 5 and 2.5K Java Platform 8 and the history shows no "Big Bang" on April 21st / 22nd. Looks good! Check on your side if you want to get a feeling on the impact for you of this ARL change.

[bvallen0713]

This thread is very confusing.  Are you guys saying we need to get rid of the evidence that is showing up in the Installer Evidence......or just to simply ignore it and go with what the File Evidence shows us?  In our Java Unmanaged Application it shows 1,442 different Installer Evidences.....(which has got to be incorrect) and none in the File Evidence.  Are we to ignore this new Java Unmanaged Application?

[JJacildo]

Hello @bvallen0713 , No need to get rid of any Installer Evidence. And Yes you can ignore this new Java Unmanaged Application - Where the Installer Evidence is now associated.

Hope that helps.

[bvallen0713]

Did anyone from Flexera work with Oracle on this change to verify that they won't audit and try to charge a customer if they see that Java 8 Update's xxx (ex: Java 8 Update 361) are installed?  I ask because it is installed on our laptops and some servers.....and it now is being reported as Installer Evidence on the Java Unmanaged Application. 

[hghastingsCG]

Have you seen this?

https://www.flexera.com/solutions/oracle-verified

[bvallen0713]

I could be wrong, but I don't think that link is anything new.  What is new is the way Flexera is recognizing Java.  My hope is that they worked with Oracle on their new change and got Oracle's approval.  We can't rely on the sole word of any software inventory vendor to tell us how to license Oracle Java.  My example is this: I have Java 8 Update 361 on my laptop.  Our build team pushes updates to our laptops.  In late April they pushed this one.  So according to my Add/Remove Program list, I have Java installed.  But according to Flexera I don't, because this is installer evidence not file evidence.  And unless Oracle has changed their ways, they would consider this as a valid install.

[nrousseau1]

Hello @bvallen0713 ,

Sorry if things look confusing. I would admit they are not simple. I delivered last week a session on Java with Jan Borchers and the recording will be posted later this week in the Community Hub.  You can subscribe to get notifications.

Everywhere java is deployed, you have a file (java.exe or javaw.exe or %/bin/java (on Unix). Taking your example, if Java 8 Update 361 is installed (Commercial version because update is >= 211), you will have a java.exe (/ javaw.exe) 8.0.361.XXX that will trigger the recognition of Java Platform Standard 8.

The new "Oracle Java unmanaged" application is a "bucket" application that  catches any installer evidence of any "commercial" version that can be useful for a second check (Java Platform Commercial versions will always be recognized on these servers, unless the installer evidence was a false positive. If monitoring the files is good enough to get a 100% accurate view of your Java deployment... if in addition these files' paths are good to trim all embedded instances (this is the exemption by file path), then, why would we use installer evidence?

Then, as the Java webinar insists on, you need to use file evidence to recognize java.

An important thing on the agent: versions 2022R1.6+ bring additional data that you can find in the Oracle Worksheet (just released in April): AMC agent, Mission Control and Unlock Commercial Feature that show additional licensable installations (eventually on "public" versions .

I paste some slides of the webinar

 

 

[bwcbwc59]

How would one gather file evidence from Windows computers? All the inventory tools from MS (Intune/SCCM) rely on Installer evidence in one form or another. By unilaterally making this change you've created a lot of unplanned work for our SLMS team.

Edit: Removed query about freeware included in the unmanaged application. I was under the impression that commercial licensing requirement only started with Java 8 211 and above and not to late releases of prior versions 6 and 7...

[bfaller]

Hello, java is one of the most downloaded tool. Then you can't rely only on tools like Intune/sccm, but like Flexera agent to gather commercial executables, even not installed... And with new oracle metrics, only one download may be risky.

Regards.

[bwcbwc59]

@bfaller - Agreed that downloaded "portable" copies of Java are a risk when using Installer evidence.  My concerns are: 1) This seems to be another case where FNMS is designed around the agent rather than around the inventory tools actually used by customers and 2) that they broke the existing installer evidence and all the reports and cross-application reconciliation processes that depend on it as part of the "solution".

[nrousseau1]

Hello @bwcbwc59 ,

Sorry for the frustration this situations creates. There is no easy solution to this complex problem but we will manage it.

If your inventory tool does not retrieve file evidence (SCCM can retrieve file evidence, and hopefully scoped file evidence), then you need indeed installer evidence (despite all the downsides they have: no path context and for Intune, no Publisher name neither).

We have on purpose parked "All Installer Evidence of All Java Commercial versions" in this "Java Platform Unmanaged" application that we could have named "Java Commercial From Installer Evidence (limited trust)". The idea was the people who need it can still fully use its normalization. You can

• Add this application for your Java license definition
• Flag the application with "Import Detailed Evidence"

Your License will show everywhere the application exists and the installations will trigger license consumption. Using the "Application Transparency report", you will see everywhere, for which raw version, Java has been identified from installer evidence.

Keeping installer evidence to recognize Java was preventing for customers who have the right level of information through file evidence to perform reliable monitoring of Java.

If other tools don't collect what is necessary to manage java (just like SCCM does not collect what is necessary to manage Oracle, SQL Server, Acrobat, Java etc.), then you can use this Java Platform Unmanaged application that will show you the best possible picture on imperfect inventory data without impacting all other customers that have the necessary file evidence.

Best regards,

Nicolas

[swannd]

"Java Platform Unmanaged" application that we could have named "Java Commercial from Installer Evidence (limited trust)"

This is a much better name. Will it be changed? :0)

[sissonr]

We continue to see installer evidence included in Oracle commercial Java applications (Java Development Kit 8 Standard, Java Runtime Environment 8 Standard) within our on-premise FNMS 2023 R1 environment. This seems to be at odds with this article, by which, as stated, we would expect all such Installer Evidence to have been shifted to the Java Unmanaged Application.

Here are some examples of Installer Evidence we still see within the applications. What is the explanation?

Name	Version	Publisher	Type	Source	Ignored	Assigned	Added evidence	Overlapping evidence
oracle.jre	1.8.0.261.012	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jre	1.8.0.231.%	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jre	1.8.0.261.00	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jre	1.8.0.211.%	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jre	1.8.0.341.%	Oracle%	Any	Flexera	No	Yes	No	No

oracle.jdk	1.8.0.261.%	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jdk	1.8.0.231.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 391 (%bit)	8.0.3910.13	Oracle%	Any	Flexera	No	Yes	No	No
Java Development Kit	1.8.0.291.09	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 211 (%	8.0.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 281 (%bit)	8.0.2810.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 231 (%-bit)	8.0.231%	Oracle%	Any	Flexera	No	Yes	No	No
Java Development Kit	1.8.0.221.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 301 (%-bit)	8.0.3010.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 301	8.0.3010.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 251 (%bit)	8.0.251%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 371 (%bit)	8.0.3710.%	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jdk	1.8.0.211.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 221 (%bit)	8.0.2210.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 291 (%bit)	8.0.2910.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 351	8.0.3510.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 361 (%bit)	8.0.3610.26	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 271	8.0.2710.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 271 (%bit)	8.0.2710.%	Oracle%	Any	Flexera	No	Yes	No	No
oracle.jdk	1.8.0.341.%	Oracle%	Any	Flexera	No	Yes	No	No
Java SE Development Kit 8 Update 391 (%bit)	8.0.3910.26	Oracle%	Any	Flexera	No	Yes	No	No

[bwcbwc59]

Just wanted to say thank you for restoring the more informative version information for Java Installer evidence as a supplement to the official file evidence in the ARLs. This has resolved almost all the complaints from our SLMS team.