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