This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Java update 55 failing

FormerMember
FormerMember

I deployed the latest Java Update (55) to a test group of users.  Almost all of them are failing with the following error code.  0x80070643 (Fatal error during installation)  I see this in the update events tab of the update.  Are there any more logs I can look at to troubleshoot this issue?

  • FormerMember
    0 FormerMember

    I just pushed Adobe Reader as well and it's failing with the same error code in PatchManagement...

  • Have you used the Client Certificate Management from Patch Manager? I have had several computers that needed that done to them before 3rd party updates would install. Another place to look is Windows Update Local Policy Management. Make sure that the Windows Update Local Policy Management settings include "Allowed signed content from intranet Microsoft update service location" Hope these tips help.

  • 0x80070643 is actually a generic MSI installer failure, so the first place to check would be MSI logs. Here's a KB article we have on troubleshooting this error.


    http://knowledgebase.solarwinds.com/kb/questions/4081


  • FormerMember
    0 FormerMember

    After doing some digging and not really getting anywhere, I randomly tried turning off our McAfee Antivirus, and magically the install worked fine.  Does anyone have any experience setting up exclusions for these installs.  I did push out Java Update 51, and adobe reader 11.06 with no issue, now that I'm trying these updates I'm convinced it's McAfee.

  • Does anyone have any experience setting up exclusions for these installs.


    Generally speaking, your AV/AM software should be configured to exclude the %windir%\SoftwareDistribution\Download folder and all subfolders/files. At a minimum (if possible), you should disable Scan-On-Create for that folder tree.

    This file is only written by the WUAgent, and only with verified files obtained from AU/WU/MU/WSUS, so there's no practical need to engage these files with AV/AM software on create, but it's not a bad idea to include the folder in a daily/weekly filesystem scan.


    In many cases what's happening is that the installer is creating a temporary subfolder in ~\Download and that folder creation (and subsequent file writes) are triggering the AV/AM software to do a Scan-On-Create task and locking the files while the installer is trying to execute.