Software Deployment Question

Java 7 update 21 - Can't deploy with K1000

06/04/2013 7415 views


Until Java 7 upd17, I used to deploy Java with
msiexec /i "jre1.7.0_17.msi" /qn AUTOUPDATECHECK=0 IEXPLORER=1 JAVAUPDATE=0 JU=0 MOZILLA=1
after uploading the MSI plus CAB in a zip file to the Kbox.

But on Java 7 update 21, that doesn't work anymore.

I also tried:
- jxpiinstall.exe /s /l c:\javalog.txt
- A .BAT file, with the msiexec command inside plus a lot of "taskkill" commands.

Nothing worked.
ONe thing caught my attention: instead of the old Data1.cab we used to find out along with the MSI installer, we now have DLLs. I wonder if a KACE deployment can recognize non-registered DLLs during the install.

Anyway, I'm totally stumped. Any tips would be greatly appreciated.
Has anyone managed to deploy Java 7 update 21 through KACE?

Thanks in advance

Answer Summary:
0 Comments   [ + ] Show comments


  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.

Community Chosen Answer


I have done it do 300+ users but i do it in a script. I installed Java on my computer and went to C:\Users\username\AppData\Local\Sun\Java  and took everything in there and stuck it on my software server i have for simple installs like this.


Here is my script below:


Dim WshShell

Set WshShell = WScript.CreateObject("Wscript.Shell")

WshShell.Run "msiexec /i \\yourserver\jre1.7.0_21-c.msi /qb-", 1, True

WshShell.Run "regedit /s \\yourserver\\noupdate.reg"


the registry hack turns off autoupdates. This may not be everyone's cup of tea with deployment but I pretty much use all scripts for installs. I like being able to control more within a VBS

Answered 06/05/2013 by: areiner
4th Degree Black Belt

All Answers


Moving this down here because I posted it in the wrong spot lol

I just finished packaging 7u21 as well, it installed really well. I used an install.bat with the "Windows Offline" downloaded from here: https://www.java.com/en/download/manual.jsp

install.bat was just: start /wait jre-7u21-windows-i586.exe /s /v"/norestart AUTOUPDATECHECK=0 JAVAUPDATE=0 JU=0" MOZILLA=1

You might give that one a try as well. Worked really well for me. I even added it to our K2 for use in the base image.

Answered 06/05/2013 by: samzeeco
10th Degree Black Belt

  • I do that all the time.
    • I think the Answer this question button is what threw me off. But I guess that's a smart way to do it because question owners would often ask more questions or give updates via the answer function instead of through comments. Makes sense to use a button.
  • I'm trying to avoid scripts for now while I'm still checking what the Kbox is really about, so I tried samzeeco's solution first.

    Unfortunately it didn't work yet. I think I've done everything correctly: zipped the .bat and the .exe together and upped the zip to the kbox, created the distribution with "configure manually" and running the batch file without prepend msiexec. It concludes the installation at the user machine, but Java u21 is not there.

    At kdeploy.txt log file, the only kind of error message I've found was:
    "failed to convert the stdout/stderr content in to UTF-8 using code page 850"
    When I tried to "use default" instead of "configure manually", found a message on kdeploy.txt saying that couldn't be done (although instructions clearly say it's possible).

    The command line works fine in my computer.

    Is there anything I may be doing wrong?
    Thanks a lot for all your help
    • Are you strictly sticking to Distribution right now for software deployments?
      • Yes, I tried that to no avail. Led me to think that the new dlls could be the cause. It works perfectly with update 17.
        I'll resort to scripts if needed, but would prefer to have everything fixed by MI.
    • That's strange... I know when I did a package and had that issue I tried a program called "RunAsCurrentUser.exe" that worked for me. I wrote a blog about it, you might give it a try since it working on my machine but not through KACE is what prompted me to find and try this: http://www.itninja.com/blog/view/running-k1000-managed-installations-as-the-current-user

      I'm guessing the software record that holds the zip for use in Managed Installations has the OS you're trying to deploy to right? We had an issue with some deployments not going to a Windows 8 PC because the Windows 8 OS wasn't selected in the software record.
      • I took a look and will definitely keep that for the future. For now, however, my users don`t have admin permissions and therefore cannot install anything, so if I use runascurrentuser, I guess they will be presented with the UAC screen
        About the OS version: yep, I had trouble with that before, so I double check it all the time. All fine.

        Perhaps there is another log I can check, besides kdeploy?

I simply deploy the JRE .exe with the /s switch and have no issues...

"jre-7u21-windows-i586.exe" /s

Answered 06/05/2013 by: jegolf
Red Belt

  • You can get the offline install .exe here: http://www.java.com/en/download/manual.jsp
  • That works IF I remove the /s.
    I tried with "default" and "configure manually", with the exe name between quotes or not. It only works on "default", with no parameters. Not enough for me, I need a silent install. But that`s definitely a beginning, thanks. Any other tips are very welcome.
  • For Run Parameters just enter /s...screen shot below.
  • Also - upload the offline installer to your software inventory record for Java 7 Update 21...

Here's a shot of the setup for a silent install:

Answered 06/06/2013 by: jegolf
Red Belt

  • That`s my screen exactly. No dice. If I remove the /s switch, it works. At least now I'm sure I'm not doing anything stupid, thanks for the screenshot.
    The only thing I can think about trying now is to uninstall Update 17 first. Do you think overwriting the old version could be the problem with u21?
  • Actually - this rings a bell now. My brain is mesh towards the end of the week. Are you deploying the 32bit Java to a 64bit OS? I always had issues with that scenario so I use a script instead. For my managed installs - I have one MI for 32bit JRE has a label to target only 32bit OSes and another MI for 64bit JRE has a label to target only 64bit OSes. I then use the script to push 32bit JRE to 64bit OSes. I limit deployment to 64bit machines without Java, run it every 2 hours, and for Tasks - on success, run a batch file, "\\sharepath\jre-7u21-windows-i586.exe" /s

    Kinda a pain but that's how I got it to work.
  • Funny, that didn't use to be a problem until last update.
    Anyway, yes, I am installing java 32 on 64bit Windows machines. We don't have 32bit Windows ones anymore, but everybody still use 32bit browsers.
    So I guess my only options at this point are script or non-silent install...
    I'll give the script a try and report back, then. Thanks!

Ok, I've finally found my stupid mistake and installed Java 7u21 32-bits in a 64-bit Windows.

It is still possible to install it using the method I explained in the first paragraph of my OP. Problem is, I tried that without using the offline installer.

As I reviewed all posts here, I realized I haven't used the offline installer until jknox posted that link to it (that's why I had dlls instead of cab files). Once I went back to the original plan with the offline installer, all worked.

So, managed installation goes as follows:

- Extract the MSI and the data1.cab file from the offline installer (.exe).
- Pack them together in a zip file
- Upload that zip file to the Java 7 update 21 entry at Inventory>Software
- Create a Distribution using the Java 7 update 21 Software entry
- Select Configure Manually
- Command line = msiexec /i "jre1.7.0_21.msi" /qn AUTOUPDATECHECK=0 IEXPLORER=1 JAVAUPDATE=0 JU=0 MOZILLA=1
- Don't prepend Msiexec

And that's it. Java 7.21 32-bits is installed in a 64-bit machine.
Thank you all for your input, and sorry for such a dumb mistake.

Answered 06/06/2013 by: colossus
Senior Yellow Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ