I am curious as to what others in the community are doing since Kaseya and Ninite can no longer patch Java. I wrote a script to check current Java.exe usage and found roughly 30% of our desktops under management were actively using Oracle based Java. We are looking at transitioning to Amazon Corretto but have found some issues with applications and their hardcoding use of Java(Oracle).
Oracle charging $2.50 per user / pre month for patching Java: https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html
I got a ticket opened with support on this status a few months back about this very same thing but they did not get back to me.
Looked at Corretto as well but like you I discovered this does not work for all applications (in my case SAGE).
In terms of the fees, I am awaiting a response on those suppliers of SW dependant on Java to establish whether they are prepared to provide updates FOC since their SW needs it at the client endpoint.
Forgot to ask, did you get some official statement from Kaseya regarding the JAVA situation?
Would you be able to share the script or point me in the direction of how you are detecting usage for the application? We are also in the middle between what the users need vs what they actually use. A usage report will allow us to identify the true need.
As it is a licensing change by Oracle, I don't really know what we can expect Kaseya or Ninite or any other third-party to say other than, yeah, that sucks, don't know why they did that.
It'd be great if they came up with some sort of work-around but I don't see how we can expect it.
Manual updates still work directly on the client, maybe one of us can come up with a way to leverage that?
mikey090tx As a quick grab I used Nirsoft ExecutedProgramList.exe with a Tab export and parsed for "java.exe" then reported that to a Custom Field. In reviewing what Nirsoft was grabbing you can look at the 'HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache' Registry Key for Java.exe then check for C:\Windows\Prefetch for Last modified date and report it to the Custom Field.
karode A manual update may work but with the licensing change may get you(your customer) in some trouble. If I was working for Oracle I would have a call back for any system running a Professional version of the OS that is Domain joined in that 5 megabyte wrapper that calls the install. Just a matter of time until they restrict the installation...
No argument there....my only point was it isn't something we can expect Kaseya to resolve.
Tim- Thanks for the information, I will see if I can give this a try and get some results. We know that the options for some people would be to perform manual deployments or script /automate the executable installs but the risk is the EUA and the cost involved. Some may go with using outdated (pre announcement) versions but the security risk would be high and any information security department would be on high alert.
Has anyone had any experience with the alternatives and what you gain \lose by going with that direction?
mikey090tx I have been running into the same thing that Chris mentioned with Software companies that have not embraced other versions of Java and may/may not have hard coded settings to work with the Oracle Java versions (presumably due to a lack of forethought)
I'm testing the use of the AdoptOpenJDK.org builds for compatibility.
So far from the perspective of the JRE the core is compatible with the existing version of Java and these builds are available via Ninite & Chocolatey.
The downside to all of these implementations is that the ControlPanel applet that managed the configuration of the Java console (which could make or break the compatibility with applications reliant on Java) is not available. It appears to be possible, if a previous version of the JDK or JRE is installed, to change the version of Java that it points to but it's effectiveness in managing it is a complete unknown.
If the new OpenSource JRE is compatible then we all need to plan on figuring out a method to cleanly uninstall Java and install the AdoptOpenJDK-JRE in place of it. For many of us it also presents the question of our position, as MSPs, in recommending / supporting Open Source over licensed software.
What may be an even larger questions is if the VSA itself has any dependencies on Java and how the licensing will be handled if that is the case.