Kaseya Community

Script to deploy .msi file to multiple machines

  • Need some help writing a script to deploy a msi file straight from a website to multiple machines from the following website, any advice will do. Thanks, 

    https://download.microsoft.com/download/5/7/2/57249A3A-19D6-4901-ACCE-80924ABEB267/1033/x64/msodbcsql.msi

  • I would do it all from your VSA. (download the File and save it in the VSA Shared folder on your kaseya Server) then do a write file and then executeshell command with msiexec /quiet

  • You could also use the getURL step in an agent procedure.  This step will download the results of the provided webpage - if the URL is to a file, the file will be downloaded.

    The benefit to 's suggestion is this:  if many machines are on the same LAN, and if you can download the file to one machine and then copy from that LAN share to the other machines on the LAN, you'll save some external network bandwidth.  You could add additional steps to the above procedure to copy from a shared location to each target to leverage the benefit of LAN bandwidth.  If the machines aren't on the same LAN (or if you're not concerned about external network access bandwidth, use just the single getURL step, run the procedure on each endpoint, and allow each individual machine to go out to the internet and download the file.  

    If you want to run the .msi, use the installMSI step (or the executeShellCommand) to execute the installer.  Be sure to configure the getURL step to "wait for completion" if you plan to install after the download.

  • Hi Brande, i ran the following script:

    It downloads the file but it get stuck at the installation.

    Is there a script that can finish the installation without User input and finish the installation? 

    Any advice would help. Thanks. 

  • add /quiet to the end but if there is an error it wont show you.



    added more.
    [edited by: Cpowell2591 at 12:25 PM (GMT -8) on Nov 11, 2015]
  • i did that, but nothing happen. i think it's just stuck at the installation prompt.

  • ...or use the installMSI step instead of executeShellCommand to perform the install.  installMSI has some configurable arguments to allow for a quiet install.

  • msiexec /a C:\kworking\msodbcsql.msi /q

  • You might also want to look at the additional switches available (if you want to continue to use the executeShellCommand step, instead of installMSI).  On a local machine, run the installer with the /? switch to see the supported arguments.  For example:

    c:\myfile.msi /?

    In many cases, this will open a dialogue box to display the supported switches.  /quiet is appropriate for this installer, but it also supports the /passive switch.  If you can't get the installer to work, a couple of suggestions:

    --Try the exact same command (if using the executeShellCommand step) on the local machine.  The behavior you seen when you run the command locally is the same you should get when running via a script UNLESS the local user has install rights that are restricted from the System user or the user logged in at the time of execution.  Test alternatives to your script using the UseCredential step (must have a defined Agent > Set Credential account with admin privileges).  

    --Try running the install with some of the supported logging switches to get more detail on the cause of the unexpected behavior.

    In short, you should see the same behavior when running the install locally via command line as you do when running the install via a Kaseya AP using the executeShellCommand step, provided the user has sufficient rights to complete the command request.

    I would still default to using installMSI step any time the installer is an .msi file, unless I want to use switches that are not directly supported from within the installMSI step.  Either step type is potentially valid - it just depends on what you want/need to do.  

    As a recommendation, if you want to write an AP log entry that an application has successfully installed, don't make the assumption that just by executing the installer the install completed successfully.  Rather, add a pause to allow the install process to complete and then use the testFile step to validate the application (a specific file) is present after the install.  Check a file that would only be present upon successful install.  If you don't want to pause, or the installer will take a while to run, use a scheduleProcedure step at the end of the installer procedure to run a testFile script several minutes later.  You can get fancy by having the process reschedule if the file is not present, and running through a loop several times to ensure the installer had enough time to complete.  After some number of checks, then alert (send an email or something) to indicate that the installer was scheduled but the application didn't install.  

    Pausing procedures for a few seconds/minutes isn't a big deal, but since procedures run in serial, if you pause a procedure for a long period, you will prevent any other procedures from running during that time, which can cause headaches.

  • @

    Have you had a look at this MSDN page?

    msdn.microsoft.com/.../jj730315%28v=sql.110%29.aspx

    msiexec /quiet /passive /qn /i #vAgentConfiguration.AgentTempDir#\msodbcsql.msi IACCEPTMSODBCSQLLICENSETERMS=YES ADDLOCAL=ALL

  • whenever i try to run this command on cmd 

    it keep give me an error like this

    does anyone know what im doing wrong? 

    thanks

  • Try running the installer with one of the logging options enabled to see if you get additional detail.  Iirc, there were at least a few supported switches for logging.

  • @

    Googling that error message I notices that there are a few others people with the same issue and the only one that actually had a potential solution was on Experts Exchange by using Orca to make a transform file.

    I downloaded a copy of the Microsoft ODBC Driver 11 for SQL Server myself and used the exact same install switches on both a Windows 7 and 8 Pro 64bit VM's and I could not replicate the error message you reported so it should work. Note that I did run command window as Administrator.

    If the logging does not give you any insight as to what might be wrong try install it on another computer.