Software Deployment

Have you tried extracting the .MSI file from the .EXE and using that to deploy the application?

And to find the machines that have the issue you mention, you could make an SMS collection or a report that looks to see if the "C:\Program Files\Java\jre6\bin\java.exe" file exists...

I can run a report to check for that file, but how can I make a collection based off that file?

I read up on the instructions, but never had this issue before. All my past installations worked fine. What seems to be happening, the JAVA install kicks off, but sometime during it, looks like it just stops, and reports back as success.

This isn't affecting all users, but some users. So I don't know what the issue is about.

Mixed users of Win XP SP2 & 3. All hardware the same. Just....scattered results.

Have you checked here to see if anything you ignored or you did wrong? http://itninja.com/link/java-downloads-for-all-operating-systems

The 'AgreeToLicense' property will be ignored, since you can't specify private properties via the command line, only public properties. Public properties are the ones in all-capitals.

Here's what I'm looking at. Seems that the install kicks off, decompresses the files, and everything just stops, and all the events report back as success.

c:\program files\java\jre6\ has the following:

bin folder
lib folder
core.zip (the contents of the java6-20 file)
patchjre.exe
zipper.exe

So it seems that the install is trying to kick off, but then just stops. Thoughts?

- Run the install as far as the first screen.
- Locate the extracted MSI. It'll either be in the %TEMP% folder or in a new folder somewhere beneath %AppData%.
- Copy the MSI somewhere safe, renaming it along the way to something sensible.
- Use this MSI to install. Use the 'verbose log' switch to produce a log of the install's progress:

MSIExec /i [path to and name of MSI] /l*v %temp%\jre-6u20.log

The log should tell you what the problem is. Search for the text 'Return value 3'. Somewhere in the dozen or so lines above and below that text will be log entries detailing what failed.

You can make a collection based off the existence of an .EXE by using something like this:

select * from SMS_R_System where SMS_R_System.ResourceID not in (select SMS_R_System.ResourceID from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceID where SMS_G_System_SoftwareFile.FileName = "java.exe" and SMS_G_System_SoftwareFile.FilePath like "%\\Program Files\\Java\\jre6\\bin\\%")

Thanks for that. Wasn't aware of the SoftwareFile table. I was able to make that query and check the results.

Now...how I can I do the opposite? How can I check for machines that DON'T have java.exe within program files\java\jre6\bin ?

I tried to do:

Software Files.File Name is not equal to "java.exe"
and
Software Files.FilePath is equal to "c:\program files\java\jre6\bin"

Results were all over the place. I checked a bunch of them, and they all had Java installed properly.

VBScab,

I was just able to duplicate the issue on my test workstation. Pushed the following to my machine via SMS

MsiExec.exe /i jre1.6.0_20.msi /qn /l*v c:\j-6u20.log

Read the log, and I'm not sure what to be looking for since the log shows that the installation was successful. I can post up the log...but it's 570kb worth of plain text, so that's quite a bit.

SMS and Event log shows successful installation.

Go into Program Files\Java\jre6\

\bin
\lib
core.zip (33mb)
patchjre.exe (0kb)
zipper.exe (64kb)

Looks like it was in the middle of installing, when it came down to extracting, it failed out, and just spit out Successful.

Reviewing the log...I'm seeing a bunch of -2147287038 errors. That usually means MSI is looking for a file, but can't find it. Is it looking for the MST file? It's in the same folder as the rest of the setup files.

jre1.6.0_20.msi (568kb)
Data1.cab (12693kb)
lzma.dll
gtapi.dll
sp1033.mst (4877kb)

Do I need to call for the MST within the command-line? And still though, the installation is not failing on all, just random. But it's hard for me to find out why since it's happening on random machines, but all reporting successful.

If I were you, I'd roll back your test machine, restart it, run the install and monitor it with ProcMon. Somewhere in ProcMon's output window will be the key to the problem. An initial stab would suggest permissions so you may see 'ACCESS DENIED' entries in the output window's 'Result' column.

All show as SUCCESS. Even with the install failing.

I wouldn't worry about MSTs for now. Get the bare MSI going first.

And no, the engine won't look for it/them unless you specify it/them in the command line using the TRANSFORMS property.

If ProcMon isn't picking up anything wrong, then I'd stick my neck out and say that Update 20 is bad on certain machines. Do other JREs install OK on those?

Yeah, I pretty much just deploy it via SMS to all Windows XP clients.

Java 6_18 was pretty much a good 80-90% successful rate. Only issues I was having was error 1618. That's fine, I'll just send a remote reboot and try again.

Java 6_20, SMS is reporting back high successful rate, but the more I dig into it...seems that my success rate may only be about 50-60%. Not sure what it is.

Case 1, machines have different versions of 1.6.0_x. Installs fine...or breaks.
Case 2, machines have 1.6.0_18, installing _20. Installs fine...o breaks.

My problem is that if it fails...everything reports back as successful. So here I am thinking it was a good deployment. Reality, their Java is broken now.

Now, here's how I can almost duplicate it. If they have update 20, and I push update 20 again, it'll break. After it breaks, and I try again...MAY break. Try it one more time, it will be successful. No clue why this is. So I thought, alright, skip SMS, let's try to push it out via AD. Exact same issue. Re-download the update again from another computer, extract MSI, and use those files....same issue.

hi guys,
had a simular thing while pushing java via GPO from 6.11 to 6.20
to me it looked like the .20 installer waited for an event ( which was the termination of the jqs.exe service) which actually never happened.
so all the (test)clients where waiting while starting up showing "installing java 6 update 20" but they never came over that point.
all i had was a deinstalled 6.11 with no more java.
stopping that "java quick starter" service did the magic for me

bye,
b

hmmm...i DID have that in one of my initial scripts, but after a while, i just started to deploy just the command line to install java.

I will deploy the script that kills the JQS.exe.

Why not do that cleanly by stopping the service? Using WMI calls, you can do that in a loop, to ensure that the service has actually stopped before proceedign.

I've seen similar VB scripts on the boards that searches the registry for all versions of Java, uninstalls all of them, and I believe stops the java update, scheduler, and jqs services...and installs the version of Java you need.

I've tried it...but was getting mixed results as well. May need to try again.

http://itninja.com/question/stopping-a-service09&mpage=1&key=uninstall%2Cjava&#

In that thread, I was complaining that I couldn't get the script to work...that's because one of our GPOs was disabling the use of VB scripting. So I had to include "regsvr32 scrrun.dll" to re-enable that, then running the script. My only issue with that script...I have no clue if it's doing anything since it only reports back a 0 or 1.

Hi folks,
some time ago, i have posted a recipe for disabling the JQS service.
See: http://www.appdeploy.com/messageboards/fb.asp?m=45917
Regards, Nick

Did you mean "recipe", Nick? :)

corrected ;-)

I don't think it has to do with the jqs.exe. I'm dupllicated the issue with my own machine, and I don't have any java services running on mine. I'm just running the MSI directly, and nothing. The log file shows a successful installation.

So like I said...it removes the current version of Java out of "c:\program files\java\jre6" and extracts the files from Data1.cab into that folder....and the install stops right there. Reports back successful. Duplicating it on my machine...samething. I can get it to work if I run the EXE file a couple of times. One of those tries will end up installing and being successful.

I just tried to install jre1.6u20 manually (over 1.6u18) and had similar problems. I had to run the install twice, with a reboot and "uninstall old" in between, to get it to complete.

I don't know if this is related or not, but: in previous 1.6 versions, several of my users reported the "all the files are gone" behavior, only to discover that the files reappeared after rebooting. In other words, most of the installation was being initiated after the reboot. We never did identify the "run once" initiator. Sande

Wow, say that again? That sounds real similar that I've been having.

So install, reboot, then it worked? This thing is still racking my brain....

Been having a sort of similar problem with 6u20. Upgrading seems to have a reasonably high success rate, but the way we deploy some of our java applications via Zenworks is by running the java .msi file first... this will install Java if they have an outdated version, and if their version is up to date the installer should say "already up to date, doing nothing" and launch the java application.

However, what has been happening is if the machine is already at 6u20 the .msi installer goes and deletes a bunch of the files out of the Program Files folder, breaking the already installed 6u20. Upgrading from older versions seems to work okay. Rebooting does not cause it to fix itself. The .msi needs to be installed again, then uninstalled, then reinstalled. (or Program Files\Java deleted and then reinstall.)

Messed around with the upgrade table to see if for some reason it decided that GUID was outdated, and it needed to upgrade, but could not get that working in any way. I started comparing it with 6u17, which did not have this problem, but the .msi files were quite similar, so unsure what the difference is that is causing this issue.

If anyone has a clue on this it would be a great help.

PS. This is not the result of any tinkering I did with the transforms to the .msi. The straight-up, unedited .msi will behave like this, which is interesting.

THAT is the exact problem that I have.

Is there a query or script I can create and run within SMS so I can build a Collection so I can find out who might be affected by this, and redeploy Java 6u20?

Hey Guys,

dunno if this might be relevant, but did you look at maybe there being a link between the issues and JRE doing either a Patch-In-Place or Static installation.
I had a quick look at the JRE 1.6.0_20 msi and noticed a couple of properties (MODE / SAME_VERSION_MODE) related to these installation types. They come back ALOT in conditions, so I'd guess they have quite the impact on the installation flow

Looks like these get populated by a system search looking for registry keys in HKLM\Software\JavaSoft. Could it be variables like wether a previous version / same version was already installed STATIC/PATCH IN PLACE affecting the push results? Maybe something to throw a script at, make a little database of found values on target systems...

Just something I thought I'd throw out there

EDIT: looking at this link, does seems like you get widely varying install scenarios depending...

PJ

Gents

Just to get my thoughts in I had a problem with JQS service so disabled the service via GPO Created a Transform for the extracted MSI and deployed via SCCM and had a 3% failure but did this out of hours with wakeup the 3% failure was down to machine left logged in and running IE

Andrew

Hi folks,
does anybody have log files of such a behavior?
Would be interesting to have a look at them.
As i wrote before: We disabled the JQS service with version 6.0.12 and never had this problem since then.
I think this comes from an aborted update and the following rollback processes.
Regards, Nick

Hey, forgot to come back and post this when I figured it out...

For those of you having this problem, compare the 1.6.17 .msi with the 1.6.20 msi, in the RemoveFile Table, under the "InstallMode" field. I changed many of those from 3 (Remove on install and uninstall) to 2 (Remove only on uninstall). This solved my issue.

FYI: I did disable the JQS Service and deleted jqs.exe out of the zip file (and jqsservice.exe (or something)), and that had no effect on my issue.

Any chance you can upload your MSI?

Apparently not able to attach files... disabled or permission issue, here is a google doc link to the file, raw unedited .msi, and a following link to the transform... the transform has more than just the RemoveFiles table edited, it also adds a few other company policy stuff on top, which you can ignore.

MSI unedited link: http://docs.google.com/leaf?id=0Bz170qNApm2AYTZlNmZhZjItMWUxNS00Y2RkLTgwMzEtZmZjNzVlNGQzMTA0&hl=en&authkey=CNCCyYcM

Link to transform: http://docs.google.com/fileview?id=0Bz170qNApm2ANWE2N2ZlNmYtOThhOS00MDQ2LWIyZDUtMmJlMmI0ODZjMTgw&hl=en&authkey=CLKt6_YI

Ignore the fact that Google thinks .mst is some sort of word format and just download both files.

I had some problems trying to install a new version of Java. In my case it was Java 6 u32 on PCs that have Java 6 u20. I found my problems were due to Internet Explorer running on the PC and holding files open (The FilesInUse bug has been reported here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818480)

I've tested two solutions, both seemed to work OK in small-scale testing so far. One was to use a script (I used AutoIt) to check if iexplore.exe was running, prompt and wait for IE to close, then install v6u32.

I also created an SCCM 2007 package and used the Advertisement option to "Assign immediately after this event: Logoff" - this way IE is not running when the Java install executes.

 

:) got em. any other special instructions with them?

No, should be a simple "msiexec /i jre1.6.0_20.msi TRANSFORMS="1-JRE-1_6_0_20-base.Mst" /qb" and logging if you so desire. If you run the installer once, it will install fine. If you run it twice it will take a little bit longer as it deletes some files (tmp files and a few special files), and the third time it should just see everything is there and exit. This is exactly how the .msi for 6u17 works. Not sure why they designed it that way, but it does seems to work every time you run the msi, nothing important appears to be deleted.

Hmm.

I ran it on a machine that already had J6u20 on it, and did the same thing as the other machines, erased everything, then reported successful. If I run an uninstall (via msiexec cmd line) then an install, everything goes good.

My issue...or maybe someone can help, machines that might already have j6u20, I DONT want the install to run on there if the machine already has it.

I made a collection so it would only point to certain machines, but sometimes, it takes a while for SMS to update the collection, so I always have the case where SMS will install to a machine that already has it installed already...killing the already installed java.

...and what do you know, J6u21 just came out...crap.

If you're using MSI/MST rather than the EXE, WI should bail when it sees that [ProductCode] is already installed.

Well it seems to do a reconfigure/reinstall/repair if it's already installed. That's what's breaking the java.

And I'm running the same msi cmd line that you posted earlier.

Msiexec /I j6u20.msi /qn /l*v c:\blah.log

You are applying the transform, correct? Using Orca, apply the transform to the .msi and check the RemoveFile table, make sure the .mst is transforming that table...

msiexec /i jre1.6.0_20.msi TRANSFORMS="1-JRE-1_6_0_20-base.Mst" /qb

Post a log if you could... although let me take a quick crack at 6u21 if I get a second and see if the same issue is there.

EDIT:
Looks like the same issue is present in 6u21. I tried my transform and it appears to solve the issue again, so I'm happy with that solution.

Hmmm... well found your issue. Applying the transformed install to the previous non-transformed install will still cause it to break. It has to be installed from scratch using the transform.... Ill test the upgrade from 6u20 to 6u21... see if that works correctly.
Will also see if there is a workaround...

This is overall very troubling, especially with Java having so many quirky issues... not pleased about having to deploy this...

I was successfully able to update from the straight unedited 6u20to the 6u21 msi with mst with no issues, everything appears to be working fine, which is good, saved me a lot of hassle.

PM. :)

Deranjer's MSI/MST worked!

Hey everybody

This wonderful bug still seems to be present in Java 6 Update 23. Had a fun incident with a re-installation of our software GP and poof, all of our java installs no longer worked. Luckily for me, not too many people relied on Java, and I can run a script to remotely fix the rest, but this is a massive pain in the ***. You'd really think they'd want to push their product more and have an *extremely* friendly MSI installer ready to deploy on their site.

There is a bug ID page for this bug. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947907 . I accidentally spammed comments on this page given that their bugtracking website has terrible loadtimes. I can't say I'm really pleased with the response given thus far on this bug. They act as if we're at fault for "daring" to use an MSI installer, when in fact, they have the MSI method of deployment listed on java.com.

Apparently Oracle does not care about fixing any problem with jre, due to the fact that this problem still exists in jre1_6_0_24.msi , jre-6u24-windows-i586.exe and jre-6u24-windows-i586-s.exe. I am new to this, is there a way to edit Deranjer’s MSI/MST for the latest version of Java?

My workaround is to copy the regutils.dll back (I found a reference to it in the msi uninstall log.). Then you can uninstall or upgrade a broken install. Then I only install java on the condition it's not already the same version. Finally I check that the plugin is actually there. The exe installer will not work in 64 bit win7 as the System user.

rem in case of broken old install
copy /y regutils.dll "C:\Program Files (x86)\Java\jre6\bin\"

rem breaks install if run twice! (2nd to last 2 numbers in the GID is the version) (64 bit win7)
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{26A24AE4-039D-4CA4-87B4-2F83216030FF}
if errorlevel 1 start /wait msiexec.exe /i jre1.6.0_30.msi /qn

rem check
dir "C:\Program Files (x86)\Java\jre6\bin\new_plugin\npjp2.dll"