The goal of this blog post is to provide people who need to provide silent installers for softwares with a general framework on how to approach this process. I often run into posts on IT-ninja, and Appdeploy before that, along the lines of ‘how to silently install this or that software’, that could easily be answered if the poster had a general approach to creating silent installations.. While I realise seasoned packagers will find alot (if not all) of this stuff to be trivial and self-evident, I still believe it has its value in teaching people a good packaging methodology.

I myself am what you might call a software packaging veteran, having been active in the field pretty much continuously for the past 9 years. During this time, like many of my colleagues, I’ve developed a standard approach in analysing installers. While posting this might cost me some much-coveted Ninja-points, I still think it might be appreciated :-)

This post will be mainly geared towards MSI packaging. While I am well aware of the advent of software virtualisation technologies like app-V, I still believe it worthwhile to focus on MSI in this post for a number of reasons:

1. While some might deny this, MSI will be around for a while yet. There are still a number of inherent limitations to software virtualisation, specifically App-V,  that will make the use of (complementary) MSI packages necessary. Most notably I’m thinking about drivers, context menu’s  and yes, Office applications
2. I absolutely believe in the future of App-V, but would like to stress that many of the principles of MSI packaging can and should be adhered to in App-V sequencing, even if a case could be made that App-V is more forgiving to ‘quick and dirty’ packaging, but that does not have to mean I like it…
3. Continuing on the last point, MSI packaging will remain a more labor-intensive job when trying to build silent, customised installers.
4. Even when building a virtualised package, a well built or customised MSI can be an easy starting point.

Generally speaking, when analysing an installer, 3 phases can be distinguished in the process:

1. Analysing required customisations: What exactly is it that the customer wants the install to look like? Is it a pretty much standard install, or are heavy modifications required? One should always remember packaging is a customer-oriented activity, and the whole process should start with a detailed description of exactly how the customer wants the software to be installed.
2. Analysing installation executables, keeping in mind the requirements from step 1: Now that we know what to change, what is the best way to implement this change? What is the core install source (MSI, Executable) and to what extent can the customisations easily be passed to these installers?
3. Customising the installers with either install parameters or transforms

The focus of this blog post will be on step 2, and to a lesser extent on step 1. While I will give a couple pointers on how to customise efficiently, this is very case-by-case, and it is my belief that a consistent method of installer analysis will make this more streamlined as well.

ANALYSING INSTALLERS – IS THERE AN MSI TO BE FOUND?

As stated, we will always go looking for MSI’s, whether they ARE the actual source installer, or are CONTAINED within the installer executable. To this end it is always advisable, if the installer is not natively a (vendor) MSI, to run the installer exe, and keep an eye on the system during this installation. First step I take is to try and open the exe in WinRAR, it might just be a self-extracting archive, and the MSIs might be just that easy to find.. If that does not work run the installer with /? and pray for an extraction parameter that gives you an MSI, final action is to monitor the installing user’s %TEMP% and %APPDATA% folders while running the exe.  In about 95% of cases, if not more, any msi contained in the installer will be extracted here. If so, grab it!! If not, we move on…

REQUIRED CHANGES vs AVAILABLE PARAMETERS vs TIME CONSTRAINTS

We haven’t found an MSI… damn… now what? This is when we go looking for command line parameters to the installer. Keeping in mind the customisations we want I’d suggest doing the following:

-          Look at the package KB on IT-Ninja for a list of parameters. There might even be one to extract an MSI after all, although, if you got past the previous paragraph, this is usually not the case. Second stop is the vendor website. If neither provide parameters, we might be stuck repackaging the installer.

-          Now the choice becomes whether or not to snapshot the install and build an msi ourselves. This can be avoided if ALL the required changes can be leveraged through command-line parameters or simple enough script statements (copying settings files for example). To me snapshotting is still an option in this case, since you will get increased control of what the installation does to the target machine, but this is where TIME constraints come into play, since tailoring a snapshot MSI generally takes longer than collecting the required command-line parameters.

-          If all the above does not pan out, we’re basically stuck snapshotting the installation and creating our own MSI

So now we either have a simple enough set of command line parameters for the setup executable, or we will be working with an MSI, either of our own making or provided by the vendor. Let’s quickly run through some basic priciples for the latter case

 PLAYING NICE WITH MSI – BASIC PRINCIPLES

-          When changing vendor MSIs, ALWAYS use transforms!! Why, do you ask? Well, in order to be able to maintain the ability to call on the vendor for assistance when building the installer, you’ll always want to hold on to their core installer. Otherwise it will become too easy for them to say you ‘messed up’ their installer, and they won’t help you. I know it sounds silly, but it happens, trust me. Also a transform is the most easily revertible means of modifying the installer.

-          NEVER REPACKAGE AN MSI. For basically the same reason as above, and the added reason of being able to implement possible future patches. Repackaging an MSI is actually far worse than changing it without a transform, so beware!!

-          Change AS LITTLE AS POSSIBLE  in transforms. While tools like Adminstudio’s InstallTailor will show you what changes are made to the properties of an MSI during an install, I tend to consider this a starting point only. Often during install a number of properties in the MSI are changed that are not strictly needed. Try to filter these out and leave them alone.

-          Analyse the installer’s DIALOGS: in order to identify exactly which properties you want to change, it is often useful to look through the MSI’s Dialog and Control tables, trying to link textboxes, radiogroups etc to the specific properties they change. Good thing here is it can actually be done without access to a complete packaging IDE, using just Orca or InstedIt.

-          When snapshotting, CLEAN UP!!  Only include changes relevant to the application in question, take out everything else. This is also where good exclusion lists are paramount, as well as, I hate to say, experience. Learn to distinguish the gold from the rubble. When not sure, take a stepwise approach. Try to exclude something and see if the application still works, but make a backup just in case..

BEWARE THE SNEAKY SETUP

Another point  I’d like to make is you always want to be aware of the possibility that the setup that contained an MSI, might actually be doing more during the installation than just installing these MSI’s. If you ever run into problems just running the MSI(s) contained in a setup, be prepared to do a so-called GAP CAPTURE. The principle behind this is as follows:

1)      Install the vendor msi, with any transforms you made

2)      Start your snapshotting tool of choice

3)      Run the setup.exe over your MSI

4)      (Run the application for the first time, there might be some settings done here)

5)      Stop the capture and look at the result

This might allow you to detect a number of extra actions that sneaky setup did, that you were never aware of. Or some settings that are done by that pesky application at first startup, that you just did not capture in your snapshot. Generally speaking, including a first startup of the application while snapshotting is a good idea, though not always necessary.

DRIVERS

Many seem to fear these packages. Me, I like em…

My general advise would be to ask yourself 2 questions

1)      Do I need more than just the driver for a piece of software?? While often a load of extra stuff gets installed, you might just need a driver. If this is the case, just look through the sources of the installer for the INF and CAT files, and make a package (using DifxAPP) to install them. An excellent blog post on this can be found here: http://www.itninja.com/blog/view/driver-installation-from-an-msi-using-microsoft-difx

2)      Are the drivers signed?? If they are not, try to get a signed version off the vendor, or if that does not work, SIGN THEM YOURSELVES. In today’s desktop world it is just no longer viable to work with unsigned drivers. There is an excellent guide on ITNinja on how to selfsign drivers here:  http://www.itninja.com/question/guide-to-signing-unsigned-drivers

So, that’s about it. While there is undoubtedly a lot more to cover, I think this a good start. Further topics can afterall be covered in later posts

Kr,

PJ