Disable Java updates with Group Policy

Please note:  This article was originally posted on February 6, 2012.  Translation: It’s old!  This article does not cover how to disable all update notifications, just the task tray notification that was common in 2012.  Oracle has changed Java’s update process to be more intrusive to encourage computer users to upgrade to the latest version.  And, you should…  Better yet, remove Java if you don’t need it.  If you can’t remove it, run it in a sandboxed environment and not your day-to-day system.


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 when a user that doesn’t have Admin rights gets a UAC prompt that wants Admin credentials. Here’s how to disable the Java update checks so that your end users don’t see messages like this:

Java Update Notification in Windows 7

Let me start with my 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 unless you have a really good reason not to. This tutorial is intended for systems administrators that are using some kind of systems management product for updating 3rd party software like SCCM, Landesk, etc. 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 32-bit Operating System or 64-bit Java running on 64-bit Operating System. If you’re running 32-bit Java on a 64-bit Operating System, there’s a different setting that you’ll need.

Disabling the Java update notifications is actually pretty easy. There’s a registry setting in HKEY_LOCAL_MACHINE that will allow you to completely disable both update notifications and the update functionality. The full path of the key is HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy. 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:

Registry Editor - EnableJavaUpdate Shown in Registry

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.

Group Policy Management Editor - Add Registry Setting

If you have Java installed on your management station, 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.

New Registry Properties in Group Policy Editor

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

Registry Item Browser - DisableJavaUpdate

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
Key Path: SOFTWARE\JavaSoft\Java Update\Policy
Value name: EnableJavaUpdate
Value type: REG_DWORD
Value data: 00000000 (that’s 8 zero’s)

EnableJavaUpdate Setting to Disable Updates

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

Group Policy Management Editor - Add Registry Settings Finished

All that is left is to let Group Policy refresh on your test systems (or you can run a gpupdate.exe manually). If you open the Registry Editor, you should see the setting changed:

Registry Editor - Java Updates Disabled

If you’re on a 32-bit OS, you can go to the Control Panel, run the Java Control Panel tool, and you’ll see that the Update tab is now gone. (For some reason, the 64-bit version of Java on a 64-bit OS doesn’t have the Update tab.)

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.

July 1, 2012 Update – The tutorial has been tested against both Java 6 and Java 7. While it isn’t possible for me to test against every single ‘Update’ of each version, I have tested the Gold/RTM version of both and several later releases with the same experience that is outlined in the tutorial. Unless Oracle makes some significant change to Java (in which case I will update this article), it should stand to reason that this tutorial will continue to work on later releases.

Series Navigation<< Disable 3rd Party Software Updaters with Group Policy: IntroductionDisable 32-bit Java updates on 64-bit Windows with Group Policy >>

41 thoughts on “Disable Java updates with Group Policy

  1. Andy May 31, 2012 / 5:53 AM

    Really useful info. Worked perfectly for us. Many thanks!

    • Rod May 20, 2016 / 9:24 AM

      Thanks for your explanations. It has, as most solutions do, raised another questions for my environment.

      We have multiple subnets across the country with a perhaps 700 computers mostly remote from us.

      We have a mix of: 1> 32bit_java on 32bit_OS, 2> 32bit_java on 64bit_OS, and 64bit_java on 64bit_OS.

      If I read the information accurately below, if I create 2 GPOs and apply them to the whole domain, in order to disable java for all those options, I may inadvertently cause a security risk where the incorrect GPO was applied on a system that was not applicable?

      If true, is there a possible solution?



  2. Joey Blackburn June 20, 2012 / 3:08 PM

    I have one question about this that I would like to address. Once the tab is removed does it also turn off/ remove the check from the “Check for Updates AutomaticallY”? From everything I have ready about this know one hass addressed wheter or not that check is removed or by simply killing the tab it also gets rid of the auto update feature. Can we say for sure that once the tab is removed it will not allow auto updates to run and check for updates?

    Joey B

  3. kyle June 20, 2012 / 7:01 PM

    Hi Joey… I fired up a VM and tested this out. Essentially, the answer is yes. Setting this registry key disables the automatic update check that Java performs; the Java Control Panel applet shows that by just removing the whole Update tab. This doesn’t stop someone from running jucheck.exe to manually check for updates, it just stops the check from running automatically.

  4. Doug June 25, 2012 / 7:55 PM

    Does this work with all versions of Java? My company runs an older version and was wondering if they changed the location of these registry entries in newer versions of Java.

  5. kyle June 25, 2012 / 8:42 PM

    I’ve been using this since Java 6 Update 15. If you can tell me which version you’re using, I’ll be glad to test it out in a lab VM and let you know if it works.

  6. Doug June 28, 2012 / 12:28 PM

    We have 6/18 mostly but find alot of different versions. 6/33, 7/4. Thanks for offering to test.

  7. kyle July 1, 2012 / 8:20 PM

    I’ve tested Java 6 Update 18, Update 33, and Java 7… all have the same outcome as the article. I was pretty sure they would, I just wanted to make sure before I said something that was incorrect. I’ve also updated the article to reflect the versions tested.

  8. Luis G September 6, 2012 / 10:36 AM

    Make sure that the option “Apply once and do not reapply” is disabled, this option is located at the Common tab when editing the registry GPO (take a look at the 4th and 6th images of this article).

    If this option is not cleared, when a new version of java is installed the registry key will go back to 1 and the GPO will not change it again.

    Great article, many thanks.

  9. Nico September 10, 2012 / 11:44 PM

    Good stuff, thanks for that, it works great (step 3/5 as well)!

  10. Kyle September 11, 2012 / 7:04 PM

    Great advice, Luis! Thanks! By default, the “Apply once and do not reapply” shouldn’t be checked… I hope you didn’t have to learn this one from experience. 🙂

  11. David Priest September 28, 2012 / 8:56 AM

    Great job, clear instructions with detailed screen shots. Thanks for taking the time to do this.

  12. Enrique January 14, 2013 / 4:07 PM

    Great Write up! Had my policy setup & tested in my lab in no time.

    Have one question does anybody know if it makes a difference if I only create 1 policy with both registry entries. We have 64-bit Java running on 64-bit Operating System & 32-bit Java on a 64-bit Operating System. I will in time clean it up, but want to push the policy while we upgrade PCs.

  13. Jlaw January 28, 2013 / 7:37 AM

    Thanks for this, I’d just like to point out if your running 64bit windows and 32bit Java then the reg entries are in a slightly different location and will be found under
    hklmsoftwarewow6432nodejavasoft etc

      • Marcus Shugart April 8, 2015 / 3:02 PM

        Correction you did NOT cover that specific question in link provided!
        Although this is a dated post I wanted to bring up the point the link you provided DOES NOT answer the question! You stated the process is not the same and the registry entries are in different locations depending upon 32bit on a 32bit O/S or 32bit on a 64bit O/S however the question was is it problematic to place both registry entries in your GPO and push them without using GPO preferences or a WMI filter to determine which change to apply.
        Regardless of if it may or may not be problimatic I would have went a step further and detailed options to include the ladder.

        • Kyle Beckman April 12, 2015 / 6:18 PM

          No idea what you’re talking about since this is a 3 year old post and you aren’t telling me what the question is you’re talking about. It is a bad practice to push x86 and x64 configurations to all computers regardless of whether they are x86 or x64; you need to push x86 to x86 and x64 to x64. You’re going to end up with files in places like C:\Program Files (x86)\ or in WOW6432Node in the Registry when those locations don’t exist. Since you’re putting files or entries into places they shouldn’t exist, you’re entering into unsupported territory where things can happen or break unexpectedly. In one case, I’ve seen a hardware manufacturer’s software installer check for the existence of C:\Windows\SysWOW64\ as the test for whether a system was x64. That means that all systems that were x86 refused to install the software because the poorly written installer thought they were x64.

  14. Rosanne February 20, 2013 / 3:18 PM

    I’m still having problems with this… We set the GPO up, and applied it. When I look at the registry settings, the key is indeed set to 0. Except I’m still seeing the popups. (and no, it isn’t a 64 bit machine.) Any ideas? Is there another key somewhere that I’m missing?

    • Kyle Beckman February 20, 2013 / 5:24 PM

      Without seeing the output of a gpresult, it is hard for me to tell. I would double-check your settings and make sure there isn’t something that is off. I’d also try setting the Registry entry manually on a machine to see if the setting takes. If it does, there may be an error in your policy. If it doesn’t, there may be something else going on with your systems.

  15. John February 21, 2013 / 10:01 AM

    Quick question, Im currently setting up a GPO to disable the java updates, but in my registry there isn’t an entry for EnableJavaUpdate in HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava UpdatePolicy

    (Java is definitely installed),

    There are entires for inHKEY_LOCAL_MACHINESOFTWAREJavaSoftJava UpdatePolicyJavaFx for Frequency, UpdateSchedule and UpdateScheduleMinutes

    Would changing these make any difference?

    Any advice be great thanks

    • Kyle Beckman February 21, 2013 / 10:39 AM

      Setting the EnableJavaUpdate is all I’ve ever needed.

  16. Paul March 4, 2013 / 4:26 AM


    Was your Java installed as a different user? e.g. admin user? If so, the Update folder will be under their profile. I’ve just found this in my install.

    When running regedit as my admin account I found it in;

    HKEY_CURRENT_USERSoftwareJavaSoftJava Update

    • Kyle Beckman March 4, 2013 / 11:48 AM

      Can you give me the system configuration that allowed you to install this inside a user’s account? (OS, Java version, user rights assigned to the user, status of UAC, etc.) I just tried to reproduce this behavior on a test system and couldn’t. My experience has always been that Java installs, by default, into Program Files or Program Files (x86) after a UAC prompt. Running the installer without Admin rights or UAC disabled usually results in nothing happening. If you can give me directions I can use to reproduce what you’re seeing, I’ll document it all and update these posts.

  17. Cameron Brennan March 27, 2013 / 2:21 AM


    Thanks for the info – i’ve applied this on several machines – XP and Win 7 and they all work…except for one model laptop (win 7) for some reason!

    The group policy that I have created dumps the dword value onto the machines and it is set correctly but the update tab in Java is still there. I have compared this to another model Win 7 laptop with the same version of Win 7 and the same version of Java (Ver 7 update 17) but it just won’t get rid of that tab. I’m logging on as the same user on each machine and the laptop is in the same OU as the other working laptop.

    I’ve looked at the logs and debug log for group policy but can’t see why. Any ideas?


    • Kyle Beckman March 27, 2013 / 5:09 PM

      Honestly, I’m at a loss. If it is applying the registry value to the correct location, then something with Java is causing it to ignore the setting. The biggest thing I’ve seen is using the wrong setting for the wrong bitness (32 vs 64 bit). The only other thing I can think of since you mentioned that it was one specific model would be if there is something unique to the Java installed on that model machine. If you’re using the OS image from the vendor, it could quite literally be anything. If you’re not, there may be something specific to how the software was deployed to the system or possibly something like a third-party tool causing a conflict.

  18. Cameron Brennan March 27, 2013 / 9:23 PM

    You are a champion! I uninstalled Java completely and installed the 64 bit version and now it is working. It must’ve been something funny with how it was originally installed. Thanks again!

  19. John Denver February 7, 2014 / 12:09 PM

    You made a mistake!!

    Action: Update
    Key Path: SOFTWARE\JavaSoft\Java\UpdatePolicy
    Value name: EnableJavaUpdate
    Value type: REG_DWORD
    Value data: 00000000 (that’s 8 zero’s)

    Key path should be:SOFTWARE\JavaSoft\Java Update\Policy

    • Kyle Beckman February 9, 2014 / 1:16 PM

      Me? A mistake? Nooooooo….. Seems to be right now… though I have no idea how the Revision counter for the article went up. :-”

      (Thanks for the head’s up!)

  20. Mick March 31, 2014 / 2:30 PM

    Hi Kyle, I’m hoping you can help because I am still having probs with this. I disabled update in both places (software\javasoft and software\wow6432node\javasoft) and it is still trying to update. This is in Citrix 4.5 on 64 bit Windows 2003 server. The software update is going to the users Remote Desktop Profile location, as assigned in AD. Profile size is restricted and this is causing logon problems with Profile Space Exceeded messages. Can anyone let me know what else I can check to stop these Java updates?

    Thanks much,
    Mick in Princeton

  21. Ronnie October 25, 2014 / 8:03 AM

    I want to use the GPO to block Java from using BITS (Background Intelligent Transfer Service). This is only because every time Java update runs, it fails. I know I can go into the properties of Java and change the compatibility to windows2000 to fix this but that’s not what I want to do. I want to deny use of BITS to the jucheck.exe which will force it to use it’s other services and not fail on install. If you could help with this, it will be much appreciated.


  22. Carol March 17, 2015 / 5:00 PM

    What does this mean:
    I have no “update” tab on my Java control panel.
    I have no EnabledJavaUpdate set to 0… or 1… or even existing.
    I have Java 6.25 and 7.45 installed.

    Will I get auto-updates????

  23. Shemsher July 28, 2015 / 9:50 AM

    My environment in the AD Server does not have Java Installed and there are no entry found in the GPO registry in this location.(GPO)>Computer Configuration>Windows Settings>Security Settings>Registry. Also I did not notice the ‘Preferences’ option after Computer Configuration. Need your help.

    • Kyle Beckman August 4, 2015 / 7:25 PM

      You really shouldn’t be managing your Group Policy from a DC. You should be managing it from a management workstation that is the latest OS that your organization supports. If you don’t have Java installed, you can type in the information manually. If you’re not seeing Preferences, it sounds like you may have 2003 DC’s.

      • Lupe January 15, 2016 / 6:11 PM

        In 2012 AD, it is recommended to do GP policies from the Domain Controller because you can do more functions from there. The training books I have mention that also. If you do it from your local computer, you will not see all the features, only the ones your PC support. If you in Win7, You can’t view Win8 or Win10 specific GP policies.

        • Kyle Beckman January 15, 2016 / 7:00 PM

          I’d be interested in knowing which training books are recommending that you edit your Group Policy directly on a DC… because that is a really bad practice in a production environment. You should ALWAYS be editing from either a management station running the latest OS you want to manage or a “jump box” running the latest server OS. If you’re managing Window 10, you need to be editing Group Policy from a Windows 10 box… not your DC.

  24. Asten M September 10, 2015 / 8:37 AM

    Found another location in the registry that it might appear in:
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy

    This is the location that removed the Update tab for me.

    Found it in this location on the following two test machines:
    Windows 7 Pro x64
    Windows 7 Ultimate x64

  25. abdelrahman November 11, 2015 / 2:10 AM

    thank you for that,it’s really help me alot.

  26. Jeremy C May 12, 2016 / 10:15 AM

    We have windows 8.1 computers, most running 32-bit Java, some 64-bit Java. All computers are 64-bit OS. I have created a GPO for both 32-bit java and 64-bit java. We have Oracle and the Oracle applications page opens with Java. Every time someone opens this, they get a prompt telling them Java needs to be updated. They have to click “Later” to keep working but this is becoming a hassle. I have to log into each computer as administrator to update it. Is there another way around this? I did notice on another post about 2 other keys. “Change the value of EnableJavaUpdate to 0.
    Change the value of NotifyDownload to 0
    Create a new DWORD of EnableAutoUpdateCheck and set the value to 0.”
    Do you know if this could be the cause? Should I add these 2 others in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy

    • Kyle Beckman October 26, 2016 / 8:13 PM

      Yep… This article was written in February 2012. The Java update process has been updated to be way more intrusive. This article doesn’t cover removing that.

  27. name October 26, 2016 / 7:47 AM

    None of the explanations about removing Java update notification works.

    • Kyle Beckman October 26, 2016 / 8:10 PM

      Probably because this article is 4 1/2 years old. Sorry… time to get rid of Java.

Comments are closed.