/build/static/layout/Breadcrumb_cap_w.png

[BUG] Arguments in "Install Args" field via "Install a software package" from Scripting isn't parsed correctly on K1000

I believe I found a bug whenever I use Scripting to deploy software packages with arguments. Here's an example with steps to reproduce.

Suppose I want to deploy the latest version of Java (or any other software that supports silent installation). In Inventory=>Software=>Java 8 Update 60 (64-bit), I uploaded the EXE installer, as shown below:


Duk4q8.png

Next I go to Scripting, create a new Script, and setup my Task 1 to something like this:

q4U03u.png

Obviously if I left the Install Args area blank and hit "Run Now" to run the script, it won't be a silent installation and I'll be presented with the full installation wizard.

So then I decided to use the following arguments: INSTALL_SILENT=1 AUTO_UPDATE=0 WEB_ANALYTICS=0 REBOOT=0. 

1TYPRc.png.

Normally I would assume that this field will simply append the args to the installer since the field is simply labeled as "Install Args", so basically {KACE_DOWNLOAD_FOLDER}\jre-8u60-windows-x64.exe  INSTALL_SILENT=1 AUTO_UPDATE=0 WEB_ANALYTICS=0 REBOOT=0. However after I manually run the script, Java didn't get installed and the installer wasn't even launched at all.

I already have script debugging enabled on the workstation, so I took a look at the KAgent log file and I can see why it didn't run:
7OCza1.png

So it seems like KACE assumed the first argument "INSTALL_SILENT=1" is the EXE installer and the rest as after that as the actual arguments.
Fine, since it seems like the KACE interprets the first parameter of "Install Args" field as the installer and the rest as arguments, I changed it to this:

00S9Gr.png

Saved and ran the script manually hoping it'll install, but it didn't again. I went to check the log again, but it looks like it read and ran correctly:
tbq28P.png

Still confused, I checked the log and see why the installer would run when the Install Args is blank, and from that I finally know why.

 Rl64uf.png

The Command= part contains the full path to the EXE installer when Install Args is blank. If the Install Args field isn't blank, the full path isn't provided and will have to be manually entered in. So if I did this:

4JdBmE.png
It finally installs correctly.

Now I don't want to always figure out the correct XXXX id path every time I create a new script (C:\ProgramData\Dell\KACE\downloads\XXXX,) and was hoping there would be KACE variable for the "downloads" folder, but unfortunately there is only $(KACE_DEPENDENCY_DIR) variable.

RECOMMENDED FIX
  • The Install Args field should be left alone and KACE shouldn't attempt to break it into two parameters. That's just too confusing for new admins running KACE for the first time. I can understand why you want to break up that field into two parameters (if the software package is a ZIP that contains multiple EXE/MSI), but I rather have a new field with something like "Installer file name:" and from there the admin can specify which file to use and provide the actual argument in the Install Args field.
  • If the suggestion above is not doable, at least give us some variable like $(KACE_DOWNLOADS_DIR) variable. Then we can put in something like $(KACE_DOWNLOADS_DIR)\setup.exe SOME_ARG=1 in the Install Args field.

UPDATE:
**SOMETIMES it doesn't work, and only when the script is running as Local System, which is weird that it doesn't work. I tested this further by running cmd session with Local System and a session with a domain user with admin rights and ran kdeploy.exe with the right parameters. Kdeploy.exe completed within a second when running as Local System (no software installed), whereas it took about 20 seconds for domain user (software did get installed properly). Maybe I'll file this as a separate bug report.

0 Comments   [ + ] Show comments

Answers (2)

Posted by: lpansarini 7 years ago
Senior Yellow Belt
1
I got the same problem with other softwares, like WinRar and Google chrome.

This is a Bug or Not?
Posted by: brucegoose03 9 years ago
5th Degree Black Belt
0
I just ran this setup with java 8 update 40 with the same switches you ran and got the same results. 

I put in to have this submitted as a bug. 

WORKAROUND:

I run it as a domain admin (local system doesn't always work right with java for me)

This is how I do my java install from a script:
IxFnyc.png


And I attach the .exe and the .cfg to the script. 

ALl the .cfg file is a text file with these contents:

INSTALL_SILENT=EnableAUTO_UPDATE=DisableEULA=EnableREBOOT=DisableSPONSORS=Disable

Reference: 

http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jre-installer-options.html

https://docs.oracle.com/javacomponents/msi-jre8/install-guide/installing_jre_msi.htm



Comments:
  • Yup that's the similar setup that I'm currently using as a workaround. I also have to use a domain admin account for this to work.

    FYI for those who want to push Java 8 Update 60 x86 on 64-bit Windows while running as SYSTEM, it won't work due to this:

    https://harryjohnston.wordpress.com/2011/02/20/installing-32-bit-software-as-system-in-windows-7-x64/

    The MSI is stored in the SysWow64 folder and the installer attempts to run it in System32. If you do a symbolic link first, it'll then work. - axie 9 years ago
    • I had no idea! thanks for sharing that! - brucegoose03 9 years ago
    • If ran as a domain admin, will it install correctly without having to do a symbolic link? - MansaMusa 9 years ago
      • That's correct and it will install correctly. I've been deploying Java without the symbolic link if using domain account with admin rights. It would've been so much easier if Oracle provided a working MSI for non-enterprise customers.

        EDIT: And this only applies if you're using the EXE. Since you got the MSI working, then this won't apply. - axie 9 years ago
 
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