I have many clients where the java update 7u71 is not working properly. On some Clients it works, on others not. I can't notice a pattern. The update will be installed through gpo to Windows 7 x64 Computers. It seems the update interrupts for some reason.

After interrupted update:

On deployment share:

GPO Java7 update history:

GPO Settings

Does anybody know why this happens?
2 Comments   [ + ] Show Comments


  • Even on clients where the update worked. After another reboot it ends up with a broken JRE. This means it reapplies the GPO again. But I never clicked "redeploy" in the GPO-Editor.

    jre7u67 -> jre7u71 fails

    jre7u67 -> jre7u71 works (sometimes)
    but then
    jre7u71 -> jre7u71 JRE is broken.
  • Hence the desireability of performing an MSIZAP operation every time you install JRE to remove any existing versions.
Please log in to comment


From experience, the Java installers are not that reliable when there is an earlier version installed. We ended up using msizap to delete any previous versions before installing the latest as this seemed to solve the sort of issues we, and you, were experiencing.
Answered 11/26/2014 by: EdT
Red Belt

  • There is a script on this site which purports to remove all JREs (up to the version for which it was authored, obviously). Mind you, I've not seen any issues with leaving older versions behind, so long as the PATH to them is removed. Wny leave them? Well, as you know, some vendors are cerebrally-challenged and hard-code paths to files and/or registry settings when checking for the installed version.

    Having said *that*, I have in the past "ghosted" registry data for such applications (i.e. created dummy entries for version x.y_z that point to the actual installed version a.b_c).
Please log in to comment
Answer this question or Comment on this question for clarity