Disable 32-bit Java updates on 64-bit Windows with Group Policy

By default, an installation of Java will check for updates and then will prompt the end user to install the update whether or not the user has Admin rights. In a small environment, this may not be a problem, but in a larger environment, this can generate a lot of unnecessary support requests. If you’ve installed 32-bit/x86 Java on your 64-bit/x64 Operating System, the normal method of disabling Java updates with Group Policy isn’t going to work. You’ll need to add a Registry key in the Wow6432Node area of HKEY_LOCAL_MACHINE. Here’s how to do that so that your end users don’t see messages like this:

Standard warning about disabling the update utility for 3rd party software: You still need to update 3rd party software just like you would install monthly updates from Microsoft. This tutorial is intended for systems administrators that are using some kind of systems management product for updating 3rd party software. Many of the security flaws in 3rd party software can lead to malware infections and/or compromised computers. If you disable the update notifications, you still need to keep the software up to date!

This tutorial applies to 32-bit Java running on a 64-bit Operating System. If you’re running 32-bit Java on a 32-bit Operating System, you’ll need a different tutorial.

x86 Java stores the setting that you need to disable updates in HKEY_LOCAL_MACHINESOFTWAREWow6432NodeJavaSoftJava UpdatePolicy in 64-bit Windows. The registry entry is named EnableJavaUpdate and is a DWORD value that defaults to 1 for the update functionality to be enabled. Setting the value to 0 disables updates. Here’s what it looks like in the Registry with updates enabled:

You could set this manually, but there’s actually a much easier way to do this in Group Policy. First off you’ll need a Group Policy Object (GPO) that applies to your computers that need to have the updater disabled. In my example, it is an empty GPO, but there’s no reason why you can’t add this to an existing GPO.

In your GPO, go to Computer Configuration > Preferences > Windows Settings > Registry. Right-click and choose New > Registry Item.

If you have the 32-bit Java installed on your management station (running 64-bit Windows), you can browse the registry to the setting you’ll be changing. (If you don’t, you can skip the next couple of steps and copy the entry manually.) In the Window that opens, click the “…” button next to Key Path.

Browse down to HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432Node > JavaSoft > Java Update > Policy. In the bottom window, you should see EnableJavaUpdate. Click on it and then click Select.

When you’re taken back to the last window, it should look something like the screenshot below. If you didn’t have Java installed on your management station, you can enter the following:

Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SOFTWAREWow6432NodeJavaSoftJava UpdatePolicy
Value name: EnableJavaUpdate
Value type: REG_DWORD
Value data: 00000000 (that’s 8 zero’s)

When you click OK, it should look something like this in the Group Policy Management Editor:

All that is left is to let Group Policy refresh on your test systems (or you can run a gpupdate.exe manually).

One last thing… Java updates have (at least in my experience) been kind enough to wipe out this setting after install. As long as your ‘Action’ is set to ‘Update,’ you should be good… Group Policy will recreate the entry at the next refresh.

 

Series Navigation<< Disable Java updates with Group PolicyDisable Adobe Reader X updates with Group Policy >>

Kyle Beckman

Kyle is a Systems Administrator with 15+ years of experience. He currently works in Higher Education supporting everything from smartphones to desktop PC's to Hyper-V Failover Clusters. (If it has a IP address, he probably supports it!) He has also worked in Small Business IT consulting supporting a wide variety of businesses and non-profit organizations.

Kyle is also the Vice President of the Atlanta Windows Infrastructure and Virtualization User Group (WINVUG).You can find additional articles he's written on 4sysops.com.

13 Comments

Add a Comment
  1. In the middle of the page you say:

    Browse down to HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432JavaSoft > Java Update > Policy

    I believe you meant:

    Browse down to HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432Node > JavaSoft > Java Update > Policy

  2. Any issues trying to apply this policy to 32 bit devices? In a mixed environment, I’d like to have all my bases covered.

    Thanks,

    1. Not that I’m aware of… however, you may want to set an item-level target in the Common tab that limits the scope to just your 64-bit devices.

  3. Can I put both the 64-bit and the 32-bit registry keys to disable the updates in one group policy if I set the item-level target for each?

    1. Yes, but there are some gotchas with using the item-level targeting. I should have something up soon covering this.

  4. hi Kyle

    Since you mentioned that there are some “gotchas” with using the item level targeting. Could you let us know what it is? I have a mixed environment of 32 & 64bits OS using 32bit Java. Thank you for your time!

    1. I figured this out. Item Level Targeting for the 32 bit OS, I use the KEY Registry to look up for a match. If there is a match in the registry keys, apply the change. Ex: If HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy called EnableJavaUpdate exist, then do this…
      For the 64bit If HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy exist, then do this…

      1. That will work for Java, but it won’t necessarily help you if you need to target a Group Policy Preference to a specific architecture. I’ll have a post later this week on how to do that!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

© 2014 trekker.net