What makes a slick application installation?

Answer: Something made by me. Obviously.

But on a more serious note, I was asked something like this in a job interview recently (didn’t get the job – was rather gutting).

But it’s a valid question, especially for when deploying applications in a corporate environment. For those of you who don’t know me in the real world, I currently work as an application packager for a large engineering company that shall remain nameless. As an application packager, I either modify existing MSI installers to work in our environment via a transform, repackage applications into the MSI format, or I sequence them using Microsoft App-V Sequencer.

Over my time in this profession, I’ve seen many applications and I’ve seen almost as many weird ways to install them. Here are some of the (many) conclusions that I’ve come to, that will maximize efficiency in a corporate environment, when using the MSI installer format

Minimize user interaction

We don’t want users sitting there during installation, wondering what path the application should go to, then setting it to something silly. We want to install all applications with the bare minimum amount of user interaction, but we also want a visible process to show that the installation is happening.

Running the installation with the /qb switch is an ideal start – the user will see a progress bar, but they shouldn’t be able to change anything. The visibility will give the user assurance that something is happening, but will allow us to keep the final installation consistent across the board.

Naturally, as no interaction is possible during installation, everything should be preselected in the MSI / MST file – including installation paths,  shortcuts, features, license servers and anything else that is required. This also makes things nice and consistent for if issues occur at a later date.

Custom actions. If they can be avoided, do so

Custom actions can be a brilliant tool, but when used to do the tasks that the MSI can natively do, they are the work of Satan and all his little minions. If the MSI can’t do it, use a custom action. If the MSI can do it, then let the MSI work in the way it was intended. One example that I like to remember is an application I worked on a while ago – it dropped in five files to the same directory and installed nothing else. There was one custom action – which was used to set the installation directory. The job could have been done much better via the directory table.

Don’t use hardcoded paths

When somebody puts a hardcoded path into an application deployment, a technical support person dies. It’s a scientifically proven fact…

Actually it’s not a proven fact. But something you shouldn’t do. Imagine that somebody writes a script to drop a file into C:\WINNT and at a later date, a new system build changes the directory to C:\Windows. That’s an issue that will annoy users, create unnecessary support calls. Time is money and that hardcoded path cost time to fix.

Quick example, I worked on – there was an application (in a 32bit MSI) which had a series of VBscript custom actions. These scripts had literally hundreds of hardcoded paths, pointing to C:\Program Files\*various locations*. On a 32bit machine, the installation worked. But as soon as we tried a 64bit machine where the installation path moved to C:\Program Files (x86)\*various locations*, things started to go wrong. It was fixed but it wasn’t a quick fix.

User a transform when amending a vendor MSI

A user has asked for a piece of software made by Bloggs Inc. Bloggs Inc. has been nice enough to supply an MSI based installer, meaning you don’t need to do a full repackage. Happy days.

User has also requested a couple of changes to the installer – maybe a new installation path or having all features preselected to be installed. Before you go and save the MSI with those changes made, don’t do it. Save a transform instead.

Couple of reasons – first reason is that a vendor is far more likely to support an application that has been installed with a transform laid on top of the MSI, than a application where you have altered the actual installer. Second reason is that if you open up the MSI in Orca then drag your MST on top, Orca (and most other packaging tools) will provide you will a nice clear layout of all the changes. Makes it somewhat easier to track back if you break something.


So you have a slick, robust installation process for your installation. Document that process! Supposing you’ve finished packaging a particularly nasty application – it’ll get released to the users and they will be happy. Right until a year down the line when Nasty Application 2.0 is released. You’ll sit there going through some of the head scratching moments that you had originally. Unless you documented it beforehand – then you can track back to the previous version and hopefully send version two out in a fraction of the time that the original version took.

This applies to everything from the smallest property change, right up to the gritty details of a fully loaded SQL Express command line and answer file. If it will help in the future, write it down. Simple

So that’s a few thoughts. I have many others but they can wait for another time. Hopefully these tips will help you avoid images like the one below:

%d bloggers like this: