Msiexec.exe provides the means to install, modify, and perform operations on Windows Installer from the command line. This is the tool that, where possible, you should try to use all the time to install applications.
Msiexec can install MSI and MSP (patches) as well as accept parameters and MST (transform) files to customize the deployment.
It’s the easiest “tool” to use to deploy MSI files because it just works, and it provides the greatest flexibility.
It is another crucial step to master if you are to become a deployment expert and, in this chapter, you will learn about the relevant parameters it can accept, how to find valid property values and uninstall GUIDS.
Fundamentals
Msiexec.exe is found natively on all modern Microsoft Windows operating systems today. It is used to install applications that are in the MSI format. Any application that has the .msi extension can be double-clicked and msiexe.exe will launch automatically to install it.
View the Help
Msiexec.exe has a lot of parameters that can be passed to it, and you will learn about the pertinent ones later in this chapter. To view the available parameters, you can read the help that comes bundled with the tool.
This help file is useful for a quick reminder when you are on the go. Should you want more detailed help you should read the online help and I recommend taking a five-minute break to read through it.
The online documentation can be read here: https://docs.microsoft.com/en-gb/windows/win32/msi/command-line-options
Where Is It?
As you’ve just been shown, when you type msiexec /? directly into the Run dialog, it will automatically launch; you don’t need to type the complete file path to call it. For clarity and certainty, you should use the full path to msiexec.exe’s location when using it in PowerShell scripts.
Here’s where it can be found if the drive letter C: contains the operating system:
C:WindowsSystem32
Better to Use $Env:
“Better to use say what?” Yup, as you have just read, when accessing msiexec by using the full path, you are assuming that Windows was installed and accessed via the drive letter of C: But what if Windows was installed on drive D: or E: or any other drive letter?
If a PowerShell script has been hard coded to reference msiexec from C:WindowsSystem32 and Windows was installed on “D:”, then the deployment script would fail.
So how do you work around this issue? PowerShell includes many environment variables which come to the rescue for just such a situation.
Environment variables store data that is used by the operating system and other programs. Some hold paths (as you will shortly learn) while others may hold data about the logged-in user. (More on this later.)
There are many environment variables, and your PowerShell scripts can query them to determine the value.
You can also read all about PowerShell environment variables by typing:
Even if you are certain that you will be deploying to computers that have a standard Windows installation using the drive letter “C:”, it is very good practice to get into the habit of using environment variables wherever possible. After all, you may write a script for yourself now that you end up sharing later and who knows where the Windows installation resides in another organization?
Parameters
Before you begin your journey in earnest, you must understand the fundamentals of building up a command line to either install or uninstall an MSI application using msiexec.exe.
The parameters that you will mostly use with msiexec are /i , /x, /qn, /norestart, and sometimes PROPERTY.
I never find myself using the TRANSFORMS switch though there are certainly great use-cases for it and once again it’s worth a time-out to read the online documentation referenced earlier (if you haven’t already done so) to understand when a transforms file may be worth your while.
It is beyond the scope of this book to walk you through every single option available, so you will learn about the parameters used in most deployments. Let’s see how to build up a typical command line to install a fictitious MSI application: MyProduct.msi.
Installation
Silent Install
No Restart
Uninstall
Uninstalling is a similar process, except /x instead of /i as the first parameter.
At this stage, you cannot simply type: msiexec /i MyProduct.msi /qn /norestart (or any other msiexec command line) in the PowerShell deployment script and expect it to work – It still requires some PowerShell magic to make it function correctly. This is covered later in the book.
That’s essentially it for parameters. Of course, there are other parameters you can use as you saw from looking at the help, but these are the common ones that you will find yourself using in deployment scenarios.
Now that you have the basics under your belt, when it comes to scripting this later it will be a breeze.
Properties
Some MSIs have properties you can modify to customize the installation. For example, automatically accepting an End User License Agreement (EULA) or preventing the creation of a desktop shortcut. You do this by referencing the property with the associated value when you create your command line.
msiexec /i MyProduct.msi PROPERTY=value /qn /norestart where PROPERTY is the name of the property you wish to modify, and value is the value for that property.
You may or may not already know what the properties and values are that you require for your command line. On very rare occasions a product will come with some great documentation, and you know ahead of time exactly what you need.
But what if you don’t know this information? How can you find out which properties are available and what the permitted values are for them?
Which Properties Can Be Set?
There is more than one way to find out which properties can be configured for a given MSI, and the easiest method, as it does not require any extra “tools,” is to add some logging parameters to the install command line, and then perform a manual install on a test computer.
By examining the resulting log output, you can view which properties are available.
Once you have installed the MSI with logging turned on, look at the resulting: PropertyLog.txt: any Property(S) or Property(C) in the log that is in capitals is a public property and can usually be configured.
How to Find Valid Property Values
Understanding how to determine which properties may be modified as part of an MSI installation is a useful skill; however, on many an occasion, you will not know what the permitted property values are.
Finding out what these are is a straightforward process. You do this by installing the MSI first on a test computer having added the logging parameter to the installation command line.
Once you have manually selected all the desired install options, allow the installation to complete and inspect the resulting log file.
Let’s have an example: you must deploy an application, FUSION Excel Connect Client 32bit.msi, that requires user input to change a default configuration.
Using the previously shown technique to view the available properties from the log file, it was seen that the property to be set is ERPSYSTEM, but what should the correct property value be?
The installation was initiated with a full GUI. When the option to select the ERP system was presented, Sage Enterprise Management was selected. The installation was then allowed to complete.
Examining the Properties.txt log file revealed the value required to deploy the MSI with the correct configuration.
Uninstall GUIDs
There may come a time when you are required to uninstall an MSI before installing a new version.
When you install an MSI, it stores various useful information, including its display name and uninstall GUID in the registry.
Where this useful information is stored depends on whether it was a 32-bit or 64-bit installation.
32-Bit Installations
You will need to have a click-around on the various GUID subkeys to find the application you are looking for.
The most important registry values (as far as scripting an uninstall goes) are the Display Name and Uninstall String, as with these two pieces of information you can easily test for and script the uninstallation of a particular application.
The Wow6432Node registry entry indicates that you are running a 64-bit Windows version. The operating system uses this key to display a separate view of HKEY_LOCAL_MACHINESOFTWARE for 32-bit applications that run on 64-bit Windows versions.
64-Bit Installations
Knowing where to find the uninstall information enables you to search for the display name of the application that you wish to uninstall. You can then obtain the corresponding uninstall GUID before passing it to msiexec.exe to begin the uninstallation.
If there is a chance that some computers may have older versions of the software you are about to deploy, it’s best to verify if an older installed version exists first, and if so, uninstall it before the new application is installed. Now I don’t know about you, but that sounds like it would be an ideal candidate for a pre-deployment task that can be handled by a deployment template. Later in the book, it will be explained how to handle this exact scenario.
This was another heavy chapter, but like the chapter before, crucial to understand if you are to become a deployment guru.
Summary
In this chapter, you learned that MSIEXE.exe has built-in help files as well as a superior online help document, why it’s better to use PowerShell environment variables rather than hard-coding a path, and the various parameters that are used with most scripted application deployments.
You learned that you could customize the MSI installation by setting properties, how to view the allowed properties, and how to discover the valid property values.
You finished up by learning about the uninstall information that is written to the registry on every MSI installation.
The next chapter focuses on how to approach the dreaded Setup.exe.