It throws up a UAC prompt without warning / explanation / asking first
It doesn’t work half the time
It installs the Ask toolbar if your aren’t careful to opt out
Even though Java needs to be kept up to date, we simply cannot have users being harassed by a utility that doesn’t work, then installs crapware when it does.
Turning off the Updater is as simple as setting a registry value – the catch is that most instructions online do not account for 64-bit windows.
The registry item on a 32-bit machine is a DWORD in the key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy called EnableJavaUpdate. Set it to 0. On a 64-bit machine, it could be in the previous location, and/or it could be in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy
The way I chose to do it was with Machine Group Policy Preferences – Registry items. I use Item-level targeting to make sure the values exist before updating them.
This is a screenshot of the Registry items – showing where to place the Item-level targeting, and what settings to use
(The main reason for the targeting is to prevent it from creating the Wow6432Node on 32-bit machines)
I recently encountered a server that was having problems applying group policy. I encountered the following errors:
Log: Application
Source: Group Policy Registry
Event ID: 8194
Message:The client-side extension could not remove user policy settings for 'GPONAME {n-n-n-n-n}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
Log: System
Source: GroupPolicy
Event ID: 1085
Message: Windows failed to apply the Group Policy Registry settings. Group Policy Registry settings might have its own log file. Please click on the "More information" link.
The More info link is useless -don’t waste your time. Also, it would appear there is no trace file. Searching for these errors on Google will get you suggestions about deleting GPOs on the Domain controller, but the thing is, I need this GPO.
To diagnose this issue, you will first need to enable Group Policy tracing. On the machine having the problems, open up the local group policy editor (run gpedit.msc) and browse to:
Computer Policy \ Administrative Templates \ System \ Group Policy \ Logging and tracing
This contains a list of all the Group Policy Modules / extensions. Select the one that matches the error message in the system event log. (In my case, it was Registry Policy Processing)
enable the policy, change Tracing to “On” and click Ok.
Now open an elevated (Run as Administrator) command prompt, and type gpupdate. This should get the errors to throw again, but this time it will write out a trace file.
You should be able to find that trace file in C:\ProgramData\GroupPolicy\Preference\Trace\User.log. Open it up and look for a line containing “The data is Invalid”. You should see something like the following:
GPH data file : C:\ProgramData\Microsoft\Group Policy\History\{...-...-...-...-...}\S-1-5-21-...-...-...-...\Preferences\Registry\Registry.xml
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
Completed remove GPH. [ hr = 0x8007000d "The data is invalid." ]
Leaving ProcessGroupPolicyExRegistry() returned 0x8007000d
The filename after GPH data file is the corrupt file. Most likely is is an empty XML File. I just renamed the folder C:\ProgramData\Microsoft\Group Policy\History\{guid}\{sid} to be {sid}.bak.
(Note: you may need to change your folder options to be able to access the file)
Now run gpupdate again, and it should recreate the history file with the correct contents. Problem solved!
