SCUPing JAVA (or not)

Back in June I wrote about my methodology of deploying SCUP and how I wished I had the time to work out deploying JAVA with SCUP.   The quarterly update for JAVA was released last week, so it was time to go another round.

When deploying JAVA in an interactive manner, the install will prompt the user if the browser is running or anything else is running that prevents access to files.    That in itself is annoying, because I’d often see computers at a screen prompting the user days later.   Further installs are blocked.   Not good.   So I in a /qb type of install, I would prompt the user to close the browser and when they don’t,  I close it for them.

That doesn’t really work in a silent install.    SCUP is a method of adding third party updates to the corporate update server.   The Windows Update Agent doesn’t appear to want to do things interactive with the user.

There isn’t a lot out there about SCUPing JAVA.    Kent Agerlund’s guide for installing SCUP 2011 has a example deploying JAVA, but it is the most vanilla example you could think of.   It doesn’t take into account any of the things I would do to deploy JAVA.   I’m shocked it works for anyone. (no offense intended Kent, I do love the SCUP 2011 instructions are great.)

I found a Oracle Forum thread and a Request for Enhancement that describe the problem perfectly.   When the browser is open and installing silently you’ll get an error “Error 25099. Unzipping core files failed.” 

“Inside the %PROGRAMFILES%\Java\JRE6\bin folder is the Microsoft Runtime Library file MSVCR71.DLL that gets locked if a browser is open. During installation, the older JRE6 version is removed (unless it was installed with the STATIC switch) except for MSVCR71.DLL. Then the silent installation begins, with the core.zip expanding in alphabetical order until it comes to the letter m where it finds MSVCR71.DLL and just stops (in a non-silent mode, the user would be thrown a dialog to quit the browser / jqs, etc.). No roll back, no repair, etc. So now your left with some residual files, some reg entries but no control panel, no entry in the ADD/Remove Programs list (ARP), no regsvr32 registration has occurred.”

 
Most installations that find a file in use would mark the file for replacement during reboot and then ask for reboot at the end of the installation.   Wouldn’t that be a better way to go?

The workaround provided in the discussion thread is to use the STATIC=1 flag.   That will install the new version of JAVA into its own directory.    This scenario was rejected by my management because this essentially reverts JAVA to its behavior prior to update 10.   The version installed with a static flag would remain forever until removed manually.

After all that, I went back to deploying through SCCM Software Distribution rather than SCUPing a software update.