/build/static/layout/Breadcrumb_cap_w.png

Java - Why do you hate me so?

So I just about done with the grand summer reimage every system project, and have found that I didn't actually configure my Java deployment correctly. While I set JAVAUPDATE and AUTOUPDATECHECK to zero, considering myself safe from the dreaded Java Auto Update, it turns out there is a THIRD property you need to set, JU, in order to fully stop Java's updater.

Spare yourself from my fate, which looks like to be some script pushed out to all systems to somehow disable java auto update from prompting our user's to enter administrator credentials. (Which they don't have, and nobody like being reminded of that).

The Properties are set as such:

JAVAUPDATE = 0

AUTOUPDATECHECK = 0

JU = 0

Now... am I missing some FOURTH property? 0_o 


Comments

  • You can use the K1000 to disallow the jusched.exe process and that should take care of the updater. - tmeh 12 years ago
    • Ah, I see. Its a windows registry setting. - muebel 12 years ago
  • Disallow? Where's that configured? Very interesting. - muebel 12 years ago
  • Inventory>Software>Process...put a check mark next to the process name and under choose action select disallow selected item. - tmeh 12 years ago
    • and then make a script - muebel 12 years ago
  • Looking back at a transform I did for Java JRE 6 Update 13, those were the 3 that I used and it seamed to work at the time. Not sure if something changed with Java 7 or later updates of 6 though. We were also disabling the java systray icon that comes up when a java applet is launched but I don't think that will affect it: SYSTRAY=0 - ncsutmf 12 years ago
  • Through the K1000, should I duplicate the Disallow script and create a uniquely named one for Java? Also, what should I put for the Script Type? Do I leave it as an Offline Kscript? Do I need to check the Enabled box and should I just do this at next Client Checkin?

    Sorry. I just need specifics as I am new to the K1000. - J.R. Colby 12 years ago
  • Personally from what I have seen (7u7 and 6u35), none of those properties seem to do much. They do update reg entries in an MSI key, but entries in the Policy key seem to not be effected. Maybe they still work, but all the update options still show up in control panel which worries me.

    There are 2 msi installed with the java exe... java and the updater, if you are running XP you can just remove the AU app and the updater will be removed. On Win7 the uninstall of the updater gives a 1603 error at the end though it does seem to remove updater.

    If you deploy with only the extracted msi, you really don't have to worry about updates, because AU is installed with a different MSI. The issue I have found is the msi is all messed up and we have had large failure % (30%) due to a 2753 errors which seems common with jacked up msi, where essentially just use msi as a wrapper and use CAs to actually install with cust dll calls etc. Also the msi will bork the install if you run it twice, but 3rd time will fix it again etc etc etc.

    Java is just a plain old horrible msi, made worse because Oracle is changing it but not enough for the time being.

    I ended up deploying the exe and then running vbs afterwards removing the jusched entry in RUN, and changing the EnableJavaUpdate entry in Policy to 0. - dandirk 12 years ago
  • Going on to 7u17, it still stinks to deploy. The only way I've been able to make it work is to extract the MSI, create a managed install, cross fingers that MSI switches will work, and force my users to reboot their computers to update as it doesn't run very well live. - GeekSoldier 11 years ago
This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ