Determine if MSI/EXE supports certain flag/argument?

Question

I'm creating an auto-updater that can run MSIs and EXEs. These MSIs/EXEs aren't my own. I'd like to use any unattended/silent install option if it exists. Is there some way to determine if an MSI/EXE has some sort of unattended install support and, if so, get the right argument so I can pass it to the file when I run it? I know, by default '/quiet' is the silent install option, but I'm also curious about EXEs and any MSIs that maybe have customized this option.

This question - detect msi parameters for unattended install - is similar, but the links in the answer are broken and I can't figure out from the answer what I would do.

Thanks.

Answer 1

Just run through the installer with logging turned on and it will show you all of the possible parameters that the specific MSI accepts.

For example: msiexec /log logfile.txt /i installer.msi

Run through the entire installer and the logfile.txt will show you the passable parameters as "Property(S)" or "Property(C)" with the name in all caps.

Source: http://www.codeproject.com/Articles/16767/How-to-Pass-Command-Line-Arguments-to-MSI-Installe

Answer 2

(Note: I posted a variation of this response on the detect msi parameters for unattended install question you mentioned.)

There's lessmsi, is a great tool that certainly works here if you're willing to use a GUI and do some manual investigation.

You can try the following command:

lessmsi l -tProperty <msi_name>

...But it's unlikely that the above will have everything you're looking for.

One way to essentially guarantee that you get all the possible properties is to actually perform either an installation, repair, or uninstall with the MSI file and log the process as mentioned in Jon Heese's answer.

If you want less text to sift through in the log file, you can set the log setting to log only the properties:

<msi_name> /lp! <msi_property_logfile>

or

msiexec /lp! <msi_property_logfile> /i <msi_name>

I prefer a method that bypasses the need of install/remove/repair-ing through "extraction". The advantages this method has over lessmsi is that it doesn't require a 3rd-party utility (i.e. lessmsi), and it doesn't require you to mess with any installations. You do need to have enough disk space to actually install the program (and probably some additional space, to be safe). Then you can do something like:

msiexec /a <msi_name> /lp! <msi_property_logfile> TARGETDIR=<absolute_path_to_extract_to>

Note that the <absolute_path_to_extract_to> can point to a nonexistent directory (the command will create the directories necessary or fail).

If you hate the installation UI for whatever reason you can append the /qr option, which will 'reduce' and possibly eliminate the UI without impairing the property logging process. Be warned however--if you go "lower" than the reduced UI (viz. /qb|/passive or /qn|/quiet), your <msi_property_logfile> may be missing some properties.

The following command can effectively produce a Property log file for each MSI file in some directory (use DIR /B rather than DIR /B/S to not recurse subdirectories; remove the RD command if you want to keep the extracted files):

cmd /C "FOR /F delims^=^| %G IN ('DIR /B/S "%DirToSearch%\*.msi"') DO msiexec /a "%G" /qr /lp! "%~nG_log.txt" TARGETDIR="%~dpnG_extract" && RD /S/Q "%~dpnG_extract""

and if you want to run that in PowerShell for whatever reason, use the command below instead:

cmd /C "FOR /F delims^=^| %G IN ('DIR /B/S ""%DirToSearch%\*.msi""') DO msiexec /a ""%G"" /qr /lp! ""%~nG_log.txt"" TARGETDIR=""%~dpnG_extract"" && RD /S/Q ""%~dpnG_extract"""

Once the process has finished, you simply open up the logfile and note the lines beginning with Property(S):/Property(C):as Jon Heese mentioned.

Generally speaking, the parameters/properties that can be set for an install are logged in ALL CAPS; for example, ALLUSERS can be set ALLUSERS=1 so that the installation is for all users.

Answer 3

If it's MSI, then the parameters are standard, you can get the list of options with msiexec /? or view the docs on MSDN.

There's no way to detect options for an arbitrary EXE which options it supports, if any. Try to find docs from the vendor, or try /? switch…