Most MSI developers have been in the horrible situation of being responsible for wreaking havoc on IT infrastructure. That could be creating packages that boot all machines, destroy the network, can’t be uninstalled, or worse yet, installed at all! And that’s not to mention the packages that ruin Microsoft Office installations.

In all cases, these rogue packages require a ton of man hours and detective work to get things back to normal. They’re the packages that teach us valuable lessons and are a rite of passage – we’ll never make those mistakes ever again.

There are also the small mistakes and hang-ups that we tend to make again and again that cost time and resources every single day. These don’t awaken the same level of dread as larger mistakes, but they do cause headaches that can easily be avoided.

This guide is about creating high-quality packages that keep our IT systems and infrastructure running at peak performance, and that save time and resources now and for as long as the packages are in production.

1. Finish your packages.
We’ll start of this list with a little bit of common sense that has massive consequences. A package that is rolled out to a machine and requires additional actions from the user or the IT department is NOT finished. The longer the to-do list for the user or supporter, the lower the quality of the package. Use a few extra minutes to review or re-review settings, remove automatic updates, remove End User License Agreements and make sure the package works correctly the first time a user interacts with it. The fifteen or so minutes that you save in the packaging process turns into five minutes of disturbance for every user of that package. If the software comes with an MSI installation, it can be a good idea to install the software silently and use a capture program to record any and all changes that are made the first time the product is opened. These changes can then be made into a transform file for the vendor’s MSI file.

In a company with 1000 users, 10 minutes of package optimisation can potentially save over 160 hours. That’s a full month of work for an employee! Not to mention all of the extra support calls that an unfinished package generates.

2. Build ‘clean’ packages
When you convert non-MSI packages into MSI packages, one of the biggest challenges is making them as clean as possible (without data from the operating system or other applications). In most modern MSI suites, there is a Capture function to record the changes made by the installation. While the exact process can differ, it starts with a ‘before’ snapshot of the computer. Then, the installation is configured and an ‘after’ snapshot is created. The variations between the before and after snapshots are collected into a project that can be edited and compiled into an MSI package. It’s very important that the MSI package does not contain objects from the operating system or other applications as this can damage the system or other applications – one of the main causes of package failures.

Building clean packages isn’t easy. Even experienced MSI developers can have trouble seeing if a GUID in the registry belongs to the package or is ‘noise’. Use a tool that has good, updated exclusion lists so you have to do as little as possible! If your packages fail during the uninstallation test, it is typically because they contain objects that don’t belong to the applications.

By building high-quality MSI packages, you ensure that applications can be installed, patched, upgraded and uninstalled without issue. The extra time that you invest in building solid packages is returned many times over during the lifetime of the package.

3. Take standardisation seriously.
In medium to large businesses there is often a team that is responsible for application lifecycles and deployment. It takes an extremely long time and a lot of resources if there is no central definition of workflow, processes and/or tools. An ’if it ain’t broke, don’t fix it’ approach where the code is a mish-mash of vb-script, powershell, unattended setup, batch, MSI and some manual operations is a guaranteed recipe for expensive mistakes. Most don’t have the skillsets or competencies to cover all areas effectively, and you can quickly end in a situation where tasks are waiting until a specific employee has time or bandwidth. ”Only John knows Powershell!” By choosing a single methodology, everyone can support each other and knowledge can be shared equally. MSI allows for standardised logins, self-healing packages, safe uninstallation, etc. It will also reduce on-boarding time for new employees and everyone will know the exact procedure for solving challenges.

4. Document what’s important and forget the rest.
Almost everyone that has worked with application packaging has had a desire to or has made a package bank so they can ’easily make a few tweaks’ when the vendor releases a new version of a product. It almost never works!

You’ll almost always use as much time to build the package with adjustments and do all of the necessary testing as if you’d built the package from scratch. Experience tells us that the best method is to document the changes as simply and as quickly as possible. In practice, this is an ultra-short documentation that describes the IMPORTANT changes. You don’t need to take screen dumps of the entire installation and configuration of the product, just write down the results.

For example, the EULA dialogue window can be removed by placing this registry key in the package [HKEY_LOCAL_MACHINE\Software\ACME…]. This gives a short and easy-to-read documentation that’s easy to use next time an update is released.

Here is a simplified example of a short documentation of an MST file for Adobe Reader.

By making the change documentation short and precise, it’s easier to read and reuse.

5. Test, test and test again!
It can’t be stated enough! The only sure-fire way to perfect packages is testing, testing and more testing. Test that the installation works, test that it works for users without administrator privileges, test that it doesn’t conflict with other applications, test that it can be uninstalled, test that uninstallation doesn’t affect the OS or other applications. Testing should account for roughly 30% of the packaging project.

In a packaging team, you can split the development and testing so that you’re testing each other’s packages. This puts an extra set (or two) of eyes on the process, build and quality. It’s easier to work smarter together!