Nickadiemus
Nickadiemus

Reputation: 411

Does PowerShell /silent or /quiet arguments install bloated software that can be included in an application

To elaborate more on the question, I am creating a automated script that will install basic 3rd party and native software (chrome, adobe flash, silverlight, etc) on windows 10. I am learning as I go and was wondering if you run a silent/quiet install on a .msi or .exe file and it has 3rd party software that is by default checked to be installed when going through the Graphic User Interface install, does it install it by default?

Example

If I want to install Microsoft Silverlight, the GUI way makes you go through checkpoints before you install the software. In some of these checks they include default additions/changes to your local machine (as seen below). You can see that it defaults to Make Bing my search engine & Make MSN my homepage. Are these checks by default installed with silent or quiet install with PowerShell? If so is there a way to prevent or skip these?

enter image description here

Upvotes: 0

Views: 2343

Answers (2)

Stein Åsmul
Stein Åsmul

Reputation: 42206

Short Summary: The options seen in the dialog you posted appear to be written by a setup launcher binary and not by the main MSI that installs the runtime itself. Generally very poor deployment design, but it is what it is. Below is a description of how to create a regular MSI administration image to deploy from for corporate deployment. There are also design errors in the MSI that are attempted explained.


Silverlight: Had a look at Silverlight. As usual Microsoft has done something unusual - not following their own "standards". Essentially there is a launcher executable that kicks off an MSI installer (Windows Installer). The launcher executable seems to show the GUI you show in the screenshot above, and hence probably also write the settings to the registry. Not the way it should be - it should be written by the MSI itself and there should be a GUI in the MSI.

You can create an MSI installation image for Silverlight_x64.exe as follows:

  1. Extract: Silverlight_x64.exe using 7-Zip or equivalent.
    • I got a warning that there were some data after the end of the payload. Ignoring for now.
  2. Extracted Files: install.exe, install.res.dll, microsoft_defaults.exe, silverlight.7z, silverlight.msi.
    • install.exe and install.res.dll - launcher for setup
    • microsoft_defaults.exe - must be some settings writer
    • silverlight.7z - archive containing an MSP - Windows Installer patch package
    • silverlight.msi - empty MSI installer
  3. Admin Image: Ignoring the supporting dlls and exe files, you can create a real Windows Installer admin image as follows. First create an admin image from the MSI file, and then patch it with the MSP file:

    Admin Image:

    msiexec.exe /a silverlight.msi TARGETDIR=C:\Silverlight
    

    Patch Admin Image:

    msiexec.exe /a c:\Silverlight\silverlight.msi /p Silverlight.msp
    
  4. Transform: You can now create a transform to change what is installed with the MSI file as you see fit, or you can try to install the MSI as it is.

    • I got an error during installation which can indicate that the microsoft_defaults.exe file might be called during the installation and should be placed next to the MSI file in the extracted image.
    • How to customize an MSI installation with transforms is described in detail here: How to make better use of MSI files
  5. Installation: Finally you can install the MSI installer using a standard msiexec.exe command line:

    Install Command:

    msiexec.exe /i c:\Silverlight\silverlight.msi TRANSFORMS=c:\Silverlight\silverlight.mst /L*v C:\MyLog.log /QN
    
    • It looks like the custom actions RegisterAuthenticodeSIP and RegisterAuthenticodeSIP_64 are running self-registration after InstallFinalize. This will fail unless the whole setup is run elevated. A serious design error in the MSI.

Debugging & UAT: Once you take it upon yourself to create a standard MSI installation image for a package that is so "clunky" as this, you have to run some rounds of debugging and UAT testing to make sure it works, but generally you will see fewer failures if you have lots of machines to install to than to depend on these executables - provided nothing serious is missing. You can also determine what the executables write by monitoring them with tools for repackaging (Advanced Installer, Installshield, etc...) or system debugging (ProcMon.exe).


Original Answer:

I cannot look at this now, but let me throw some links your way. Have to make this an answer rather than a comment - will evolve it:

A setup.exe can wrap an MSI or be a legacy style installer that has nothing to do with MSI. MSI allows detailed control of what is installed and not, older style setups do as well, but in a less standardized fashion.

Upvotes: 2

Jeff Christman
Jeff Christman

Reputation: 101

Check out PowerShell DSC or Chocolatey. Both have packages that enable install silently.

Chocolatey https://chocolatey.org/packages/Silverlight

PowerShell DSC https://www.powershellgallery.com/packages/PSDscResources/2.4.0.0

Chocolatey is the easier of the two to work with.

Upvotes: 0

Related Questions