Silently Installing Applications with MSI – Part 2: Options

In the first part of the 2-part blog, I went over some of the various command line switches for MSI's. These were the basic options for installing an MSI quietly or silently with little or no user input. In this part, I'll be discussing MSI Property values, how to find them and how to modify them to change many of the details of an MSI install.

At this point, you have you basic MSI install command:

msiexec /i “D:\Downloads\acroRead.msi” /qb!

But, let’s say that you want it installed somewhere other than the default. Or you only want to install it for the currently logged in user (for example: programs that you only want to see when you log in to the local admin account but you don’t want other users to see it on their desktop or start menu). That’s where MSI Public Properties come in, and they are slightly less easy to find than the command line switches, and they can be different for each MSI. In order to find these properties, you’ll need a tool to open the MSI database. There are a number of these, but Microsoft provides a free one as part of their SDK. Do a search online for Microsoft SDK and download the one for your OS (7, 8, 8.1) and install it. Once that’s complete, find the Orca installer and run it. On my Win 8.1 test machine with the 8.1 SDK installed, I found it in “C:\Program Files (x86)\Windows Kits\8.1\bin\x86” and it was called “Orca-x86_en-us.msi”. For the purposes of this post, this is the tool I will use.

It only takes a second to install Orca and it almost doesn’t look like it actually did anything, but if you right-click on an MSI there should be an “Edit with Orca” option in the context menu. For this example I’ll be opening the MSI database for Adobe Reader 11. I downloaded the offline installer for Adobe Reader 11, which came as a Zip file. After extracting the zip file I find an EXE and an MSI. I right clicked on the MSI and chose “Edit with Orca”. The Orca editor opens and opens the Adobe Reader MSI database. On the left side of the screen is a list of tables. There is a lot of valuable information in these tables, and will allow you to complete revamp the entire structure of the MSI, however, unless you know what you are doing, tread very carefully. Some value changes can render the whole MSI inoperable. The table we are most interested in is the Property table, so open that up and you’ll see a list of Properties and values on the right side of the editor.

If you sort the Property list alphabetically, you’ll see a Property for “AgreeToLicense” which is currently set to “No”. Two other properties I’m interested in are called “EULA_ACCEPT” which is also set to “No”, and “RebootYesNo” which is set to “Yes”. Some of the Properties and values you see in an MSI can be quite confusing, but these are pretty straight forward, don’t agree to the license, don’t accept the EULA and reboot the computer if needed. What isn’t so clear is that the MSI isn’t saying no to agree to the license and EULA, but, rather, display them on the screen so you can accept them.

So, I’ve got those values, but, what if I want to install it to a different folder? Well, the MSI database has another table called “Directory” and when you open that one there is a long list of Properties, but there are two that jump out at me: INSTALLDIR and TARGETDIR. But, which one is the right one? Well, if you notice, on this table, there are actually three columns:Property, DirectoryParent and DefaultDir. If you look at the DirectoryParent value for INSTALLDIR it says “READER_11.0”, but the DirectoryParent value for TARGETDIR is blank. This means that INSTALLDIR is going to the default Adobe Reader location, so if you change this value, you are only changing the name of the folder Adobe Reader is installed into. TARGETDIR is the Property we need.

Now, we have four properties: AgreeToLicense, EULA_ACCEPT, RebootYesNo, TARGETDIR. There are two ways to change these variables: on the command line, or in a Transform file. Let’s discuss command line first.

Changing property values on the command line is pretty easy, you just add PROPERTY=VALUE on the command line. So, to modify the MSI with the properties listed above, our new command line is:

msiexec /i “D:\Downloads\acroRead.msi” /qb! AgreeToLicense=”Yes” EULA_ACCEPT=”Yes” RebootYesNo=”No” TARGETDIR=”D:\ApplicationFolder\Adobe_Reader_11.0″

And done! Once this command line runs, the MSI installer will read the database presented in the option value after /i (in this case D:\Downloads\acroRead.msi) and then take the properties listed, find them in the database and replace them with the values you gave on the command line. This only applies at the current run time and does not affect the MSI itself. If you want to install the same MSI on another computer, you need to type in the whole command line again.

NOTE: You can change these values directly in the MSI with Orca and save the MSI with the modified values. It will save you time on multiple installs, however, it is not considered best practice and if the vendor discovers you have modified the MSI itself, they will not provide support if something doesn’t work. They will provide support for values modified on the command line.

The second option for changing this values is through using an MST. This is a “Transform” file used in conjunction with an MSI. For our example above, we only changed 4 properties, so putting them on the command line isn’t all that difficult, but let’s say you had 10 properties you wanted to change. Putting all of that on the command line can be cumbersome and might be too long for the MSI installer to handle. So, we use MST’s.

To create an MST, open the MSI database in Orca again. At the top, in the menu bar, click on the Transform menu option, then click on “New Transform”. It won’t look like it did anything, but you’ll notice the first two menu options on the Transform menu are no grayed out and the 4th and 5th options (Generate Transform and Close Transform) are now accessible. This means that the MSI table is in an MST editing mode. Go back to the Property table and find AgreeToLicense, click twice on the value and change it from “No” to “Yes”. Do the same for EULA_ACCEPT and change RebootYesNo to “No”. Now, here’s the tricky part. We found the TARGETDIR property by going to the Directory table, but that doesn’t have a value option, just a DirectoryParent and DefaultDir. Here, we have two options, we could change the value that’s in DefaultDir, or we could go back to the Property table. Once in the Property table, right click anywhere on the right side of the editor and the context menu pops up. Click the option for “Add row” and a dialog box will pop up. In order to add the property and values, you have to select the Property line at the top of the window, then type in the Property name at the bottom of the window, in this case “TARGETDIR“. Then click on the Value line at the top of the window and type in the path for the install at the bottom of the window.

You will now notice that the Property table on the left now has a green line in front of it, this denotes any table that has had a row modified via MST. On the right side of the editor, any new entry or value is surrounded by a green rectangle. This way you can easily see the modifications you made with the MST, or modifications other people have made with their MST’s if you use the “Apply Transform” option from the Tranform menu. You can cancel the changes by going to the Tranform menu and selecting “Close Transform”, or you can save the modifications by clicking “Generate Transform”. You will be asked where you want to save the file, with the MSI is the best choose and you can name it whatever you want, however you should take care not to overwrite any MST’s that might have come with the application. I named mine “Reader.mst” but you could give it a more descriptive name if you want. In situations where you are dealing with multiple companies, you could have multiple MST’s that meet their needs. Then you could have one MSI and apply companyOne.mst to one company and companyTwo.mst to another, which cuts down on your administration time.

Now, we have to tell the Installer to work with the MST, so we go back to our basic command line:

msiexec /i “D:\Downloads\acroRead.msi” /qb!

To tell the MSI Installer to work with the MST we use the TRANSFORMS property. If the MST file is the in the same location as your MSI, you should have to give it the full path, but, sometimes it gets flaky and doesn’t really work all that well. So, the new command line is:

msiexec /i “D:\Downloads\acroRead.msi” /qb! TRANSFORMS=”reader.mst”

This makes our command line a little more manageable and we won’t have to remember all those properties and values, and we now how a single point to make addition changes, just by modifying the MST.

A couple of points to remember:

1. A lot of this stuff I’ve learned over time. I spent almost 5 years as an Software Automation Specialist doing this day-in, day-out on hundreds of different applications. What works for one app might not work on another. I developed an HTA based app for a former worksite that created automation packages and extracted information from MSI’s and could automate a simple MSI in about 10 seconds, and there’s still a lot I don’t know.
2. Don’t be afraid to make mistakes. Getting a new copy of an MSI is easy. If you’re worried about messing up your system, create a VM and play around with it.
3. What works for one MSI may not work for another. I’ve dealt with applications that were a nightmare, and the documentation provided by the manufacturer was note helpful.
4. Just when you think an application will be easy to automate, it will be hard. Just when you think an application will be a headache to automate, it’s easy.
5. Some OEM’s are a pain, some are a blessing. I created scripts to install my applications. One of those applications took me 7 lines of code to do the install portion (not counting attached functions), but installing that app took 305 lines of code….. No joke. Took me over a week to get the script together.
6. This link shows the Standard Installer command line options, but most helpful is the notes that show you what the equivalent option is for the Windows Installer, a number of which are listed on the Windows Installer link I posted in the first part of the blog

There are also a number of sites that can help you automate an application. Adobe tends to have automation/deployment documentation for most of their products but the documentation can be a little tricky at times. itninja.com is another good resource for information about automated installs for both MSI and EXE installers. Sourceforge Installer is also another good reference source.

I hope you enjoy the guide.