We have actually seen this same issue come up in a case another customer raised with us. In testing, one of our content team members found that it appears if both 64 and 32 bit are installed, one of the older versions is not uninstalled depending which Java installer is run first. (Hope that made sense)
Our engineering team is still looking into this, so when I find out more I will update this thread.
thank you, so i guess that behavior will be fixed with an update of the xml metadata.
How do i know when this happens ?
I am not certain if this will be fixed via our XML. Like I said, we're still investigating to see what is causing this. It may or may not be something we can fix. However, I'll update when I find out either way. Thanks
I have gotten information back on this from our engineering team. Unfortunately this is a defect with no ETA for fix. The most plausible workaround is to create a script that can be pushed out to uninstall previous versions of Java. If you contact support directly we can provide you an example script.
This should have been corrected months ago, we're not exactly sure why you continue to see this issue. We are going to need a case for the issue and logs from one of the clients machines so we can track down what is going on.
Support Portal: https://support.shavlik.com/CaseLogging.aspx
From the client machine, please include any recent folders/files for Java in these locations: (zip all of the files in one file before uploading to the case)
Please reference this thread too.
Let me know if you have any questions.