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.

Begin by opening the Run menu and typing in msiexec /?. (See Figure 2-1)

A screenshot of the run dialog box depicts m s i e x e c slash question mark selected in the open drop-down. Ok button is shown selected.

Once you click the OK button, the help is displayed as shown in Figure 2-2.

A screenshot of a windows installer dialog box depicts install options, display options, and sets user interface level. Ok button is shown at the bottom.

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

(See Figure 2-3)

A screenshot of a window depicts the files tab active with file path is highlighted. The file name m s i e x e c. e x e is selected from this P C, O S DISK, windows, and system 32.

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.

In the PowerShell ISE, if you begin to type $ENV: the IntelliSense will display the available environment variables. (See Figure 2-4)

A screenshot of the windows PowerShell I S E depicts a drop-down menu of dollar E N V with ALL USERS PROFILE is selected.

You can also read all about PowerShell environment variables by typing:

help about_Environment_Variables in the PowerShell console. (See Figure 2-5)

A screenshot of windows PowerShell depicts short and long descriptions about environment variables.

For the application deployment script used by this book, the environment variable of $ENV:SystemRoot is appropriate as this will always resolve to the Windows installation directory. Figure 2-6 demonstrates this.

A screenshot of windows PowerShell depicts a code for dollar E N V, system root.

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.

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.

Enable logging using the /lp! switch followed by the name of the log file:

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

You can name the MSI property logfile anything you like, for example:

 msiexec /i MyProgram.msi /lp! PropertyLog.txt

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.

Figure 2-7 is the resulting log file of an MSI install and shows the property ERPSYSTEM can be configured as part of the installation if desired. By default, it has a value of Sage1000.

A screenshot of fusion properties notepad depicts the following menu: file, edit, format, view, and help. The notepad lists the properties information.

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.

Figure 2-8 shows that manually executing the MSI displays a default value of Sage 1000 for the ERP System. The company requires this setting to be changed to Sage Enterprise Management.

A screenshot of the install shield wizard depicts a drop-down for E R P system with sage 1000 selected. Next button at the bottom is selected.

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?

To find out, install the MSI with logging turned on using the following command line:

msiexec /i "FUSION Excel Connect Client 32bit.msi" /lp! PropertyLog.txt

Remember to use an administrative command prompt when installing. (See Figure 2-9)

A screenshot of an administrator, command prompt depicts a code to install the M S I.

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.

Figure 2-10 shows the Properties.txt file with the ERPSYSTEM public property value of SageX3.

A screenshot of fusion properties notepad depicts the following menu: file, edit, format, view, and help. The property of E R P SYSTEM equals sage X 3 is highlighted.

Armed with this knowledge, to successfully install “Fusion Excel Connect Client 32bit.msi” silently, suppressing any reboots and changing the default configuration to Sage Enterprise Management, the installation command line would now be:

msiexec /i "FUSION Excel Connect Client 32bit.msi" ERPSYSTEM=SageX3 /qn /norestart

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

Here is the location in the registry for 32-bit installations:

HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall

You will need to have a click-around on the various GUID subkeys to find the application you are looking for.

Figure 2-11 displays the details for the 32-bit installation of the Fusion Connect Client and reveals a lot of useful application information.

A screenshot of a registry editor window depicts a file of 32-bit installation is active. The file name, type and data of the display name and uninstall string are highlighted.

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.

To uninstall an MSI using the discovered uninstall string you use the /x switch followed by the GUID enclosed in the curly braces:

Msiexec /x {CF830660-82A5-47AA-BA0D-38A4B8BE427D}

Msiexec.exe allows you to uninstall silently and suppress reboots by using the same switches as previously explained:

Msiexec /x {CF830660-82A5-47AA-BA0D-38A4B8BE427D} /norestart /qn

Tip

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

The uninstall registry location for 64-bit MSIs can be found at

HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall

And here are the details for the 64-bit version of the same program. As you can see, the same application information is presented. (See Figure 2-12)

A screenshot of a registry editor window depicts a file of 64-bit installation is active. The file name, type and data of the display name and uninstall string are highlighted.

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.

Tip

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.