none
Powershell MSI installer deployment not installing RRS feed

  • Question

  • Howdy all, thank you in advance to any takers!

    I have written a simple script that runs fine locally but when I deploy it, the Installer log says it has reconfigured the product instead of installing it.

    I deploy via Autotask and the script runs as the logged in user with elevated privileges.

    The program I am deploying has never successfully installed yet on the target test machine.

    I have tried going straight to start-process without Invoke-Command and the -ScriptBlock and have the same result.

    Also, though I have specified ALLUSERS=1, the log says 0 still.

    I've tried about a hundred variations to get it to work, and it works locally every time.

    Windows Installer sits in task manager after the fail for up to 30 mins.

    If anyone has any suggestions as to why it will not install, I would greatly appreciate it!

    Thanks again.

    This is what the Log says at completion;

     "MSI (s) (8C:8C) [23:02:38:814]: Windows Installer reconfigured the product. Product Name: TELUS Business Connect. Product Version: 19.4.0.37336. Product Language: 1033. Manufacturer: TELUS. Reconfiguration success or error status: 0."

    this is the code;

    new-item c:\temppath -itemtype directory
    Expand-Archive bizconnect.zip -DestinationPath "C:\temppath"
    Invoke-Command -ScriptBlock {start-process -FilePath msiexec.exe -wait -argumentlist '/i c:\temppath\TELUSBusinessConnectForWindows-19.4.0.msi ALLUSERS=1 /quiet /l c:\logfile.log'} | Out-Null

    Thanks again all!

    Saturday, December 21, 2019 8:24 PM

Answers

  • No matter how you are deploying it only the vendor can answer your questions about their installer. MS does not build installers.  MS provides the API and each vendor chooses how to use it.

    Command line support of an installer is up to the vendor to implement.

    To see all MS provided switches type "msiexec -?"

    "PUBLIC PROPERTIES" are defined and implemented by the vendor.

    Installer issues are not scripting issues.  This is not an installer forum.

    Autotask is also not a Microsoft technology and any issues with it need to be presented to the vendor.  You canot elevate a standard user account and only an admin can install for all users.


    \_(ツ)_/



    • Edited by jrv Saturday, December 21, 2019 9:39 PM
    • Proposed as answer by jrv Monday, December 23, 2019 9:49 PM
    • Marked as answer by Richard MuellerMVP, Moderator Tuesday, December 31, 2019 2:47 PM
    Saturday, December 21, 2019 9:37 PM

All replies

  • To begin you should not use login scripts to deploy software as this will not work as expected.

    Second - you will need to contact the vendor of the software to resolve install issues.  This is vender specific and cannot be answered here.


    \_(ツ)_/

    Saturday, December 21, 2019 8:46 PM
  • It is not a login script.

    You did not read my post.

    Someone else please assist if you have time.

    Thanks to any takers!

    Sozo

    Saturday, December 21, 2019 8:52 PM
  • No matter how you are deploying it only the vendor can answer your questions about their installer. MS does not build installers.  MS provides the API and each vendor chooses how to use it.

    Command line support of an installer is up to the vendor to implement.

    To see all MS provided switches type "msiexec -?"

    "PUBLIC PROPERTIES" are defined and implemented by the vendor.

    Installer issues are not scripting issues.  This is not an installer forum.

    Autotask is also not a Microsoft technology and any issues with it need to be presented to the vendor.  You canot elevate a standard user account and only an admin can install for all users.


    \_(ツ)_/



    • Edited by jrv Saturday, December 21, 2019 9:39 PM
    • Proposed as answer by jrv Monday, December 23, 2019 9:49 PM
    • Marked as answer by Richard MuellerMVP, Moderator Tuesday, December 31, 2019 2:47 PM
    Saturday, December 21, 2019 9:37 PM
  • I hear you however I see many people with a similar question to mine who have faced this same issue and gotten it figured, it is just a simple script for a simple MSI install and the issue seems to be with my scripting capability and script.

    Permissions are not the issue, Autotask is not the issue, I have deployed several packages via Autotask to many users, it is possible that you are correct about the Public Properties, however in this case, I doubt it.

    In any case, I am starting to see a pattern here, every time I post, you hijack/ruin the thread with useless comments, and then no one wants to read through yours to get to the good stuff. See my last thread on this forum https://social.technet.microsoft.com/Forums/en-US/9df1205d-a596-493e-bede-7a7675ea61d8/uninstall-exe-with-powershell?forum=ITCG

    Which was resolved in short order on SpiceWorks.

    I see all your "points" and fine, you know some stuff, however, please forever ignore any further posts that you see from me, I find you unhelpful and distracting to others who may have something valuable to add.

    Sorry for the candor if it offends you, however it is the case.

    Best regards,

    Sozo


    Saturday, December 21, 2019 9:59 PM
  • I am not offended but I do think you are reading this wrong. There is no script error. The script is just running the MSI. MSIs are run by the system and the execution just tells the system that it needs to open the MSI database and execute the internal instructions. The script has no control over this.

    I suggest reading the documentation for the MS installer technology to understand how this works and why a script cannot effect this outside of just running the command line.  An MSI is not a part of PowerShell it is an external process that runs under the system.  There is a system service called MSI Service.

     get-service msiserver

    That is what is doing the install.  All parameters and behaviors of the install are controlled by the vender via scripts inside the MSI.  We cannot guess at how the installer is configured by this package,  Only the vendor can tell you that,

    We can say that the package must be run as an Administrator in an elevated session and the supported modes are given by the "msiexec /?" list.  Custom behaviors are set by the vendor.

    There is no PowerShell command or syntax that can affect this.

    Most installer questions asked here are either answered by suggesting the elevation or adding the /quiet switch.  At time other switches may be suggested.  Your issue has nothing to do with these switches.  A package that is designed as a single user install cannot be installed for all users.  A package that is designed for all users cannot be installed as a single users.  A package that is designed for both modes will install as a single user when run as a normal user and will install for all users when installed from and admin account.

    None of this has anything to do with PowerShell or scripting.  It is just basic Windows technology that can be customized by a vendor.  Again - read the installer documentation until you clearly understand what is going on.  The faster way to solve this is to post in the vendors forum.


    \_(ツ)_/

    Saturday, December 21, 2019 10:34 PM
  • For anyone who needs/finds this in the future, the answer was;

    msiexec.exe /i TELUSBusinessConnectForWindows-19.4.0.msi ALLUSERS=1 /L*V "C:\Windows\temp\TelusBusConnect\businessconnect.log" /qn

    Monday, December 23, 2019 9:29 PM
  • That has noting to do with scripting. As you can see it is very vendor specific. Whenever anyone has a question about custom installer usage they always need to contact the vender for assistance. That answer has been posted in the forum dozens of times.


    \_(ツ)_/

    Monday, December 23, 2019 9:48 PM