MSI package deployment overview: How-To and How-Not-To

Windows Installer. A prime example of a great idea that, when properly implemented makes life much easier. Yet more often than not this great idea is implemented in a less than perfect manner, and rage mixed with sorrow follow shortly thereafter.

I frequently get questions on how to deploy MSI-based applications into production, as well as how to patch those apps that are already deployed. Microsoft created an very nice vehicle to address this question that drives like this:

How it should work:

Theoretically when an application comes in an MSI, deployment to the masses would happen as follows:
1. Create an administrative install with the 'msiexec /a package.msi' command
2. Use a packaging tool to create a transform to tailor the install to your specific needs
3. Deploy it to the world using the 'msiexec /i package.msi transforms=transform.mst' along with the silent install command of your choice.

In the event that a patch is released, it will come in an .msp package. To patch your environment, you'd proceed like this:
1. Patch your administrative install with the 'msiexec /p patch.msp /a admininstallpackage.msi'
2. Reinstall your client installations by send the the 'msiexec /vasu' command to them (can use other parameters, 'v' is key however.)

Down the road at some point you'll likely need to either upgrade or remove that package, which is accomplished as such:
1. Add the GUID of of the currently deployed package to the upgrade field of your new package.
2. Deploy the new package and it will detect and remove the old
-or-
1. Send the 'msiexec /x' command with the silent flag of your choice to machines that have the package installed

So essentially you're performing all client installs from the same point, so in the event that a patch is released, you simply update that point and recache the install on your clients.

Easy, right? Ideally yes, but read on as I burst your happy little windows installer bubble, and laugh manically as the shrapnel from the balloon snaps you in the eye.

How it actually works in most cases:

Ask anyone that packages applications regularly and they'll usually give you mixed reviews of MSI packages. When properly created they are easy to deploy, easy to maintain, and easy to remove. However the reality is that software vendors other than Microsoft themselves rarely create MSI's properly, and it ends up being more of a headache than a help.

As with so many things today the need to 'make it simple' has generated some tools to aid software vendors in the task of getting their software into installable packages for their customers. The tools themselves, such as InstallShield and Wise are actually quite good, but they do unfortunately make it easy to create a semi-functional windows installer package.

So what does this mean exactly?



*Insert dramatic pause*




It means that very few vendor-provided MSI's work the way that MSI's should. *Insert collective sigh from the audience followed by confused mumblings* It means that very few MSI's were actually meant to be translated into an administrative install point, and it means that very few software companies that ship their product in a MSI installation ever send out updates in MSP format.

What do I do with those MSI's that do not function properly?

The right way to handle these varies. If you have a strong Windows Installer background you could attempt to fix their MSI so that it acts as an MSI should. Alternatively, you could just thoroughly test their install and work within their specification to deploy it. This is the most common solution. Those installs generally work, just be prepared to test thoroughly in your environement.

As a last resort you could utilize a tool such as Wise or InstallShield to recapture the application. I'll go into these tools and this method in great detail later, but as an overview the software essentially watches and records the installation, and uses that information to create it's own new install. There are some deffinate risks involved in this, as I will outline later, and generally this is an if-all-else-fails tactic. Choose wisely.


And there you have it, deploying windows installer applications and patches in a nutshell. One of the (perhaps masochistic) draws for me to application packaging is that there is a lot of real world problem solving here. Take the bull by the horns, test it, analyze it, and figure out which route you should take.