The Not-So Fine Art of Software Re-Packaging and Deployment

New and Improved / Amended Version!

Note: Thanks to Mikko Järvinen for reminding me about "Uninstall Testing", also known as "Package Removal Testing" or "PRT".  I added the changes below in blue (just FYI).

I had to prepare the following for an internal FAQ document to help our "customers" better understand the ramifications, and pontifications, with respect to processing a request to have software packaged (re-packaged) for deployment to their computers.  It's a work in progress, but this is where it stands right now...

Overview

Software can be installed in a variety of ways, but when it comes to installing software on a large number of computers in the shortest time, AND with the highest level of consistency and reliability, it requires a little more work.

Unfortunately, software vendors do not follow a common playbook when it comes to packaging their products for installation. Some products are packaged in a way that makes it easy to install them using automation tools. Most are not. When software is not packaged in a way that lends itself to being installed easily, it often requires "repackaging".

Packaging vs. Re-packaging

Packaging is the process whereby a software product is compiled into an original installation package. This is often a single ".exe" or "msi" file, but in many cases it results in a collection of many folders and files. An installer that comes as a single ".exe" file is referred to as an "Executable installer". An installer that comes as a single ".msi" file is referred to as a "Windows installer package".

Executable installer packages are the most common.  These are the familiar .exe packages (e.g. setup.exe). They often provide a built-in mechanism for launching them along with a list of options or settings to pre-configure the installation without having to step through a series of dialog input forms. In many cases, this includes the option for running it in "silent" mode. "Silent" mode allows the installation to run without displaying any forms or prompting for user input. This is essential for mass deployment using automation tools such as Microsoft Configuration Manager or Group Policy.

Repackaging is the process of taking the smelly crap that some vendors hand you, and mooshing it up into a new, less-smelly ball of goodness that can be installed "silently" and pre-configured, just the way your precious customers are begging for.  There are no limits to what qualifies as "repackaging".  It can be wrapping the installation parameters within a script file (pick your script language, it really doesn't matter that much), or it can be squeezing it through the meat-grinder of something like InstallShield, or AdminStudio, to make a whole new installation binary (i.e. a new .EXE, or a Windows Installer .MSI file, etc.).  I won't even bother with discussing .ZAP files because I just ate.

Did I just say that it doesn't really matter what scripting language you use? Well, that's sort of true.  I don't recommend you just pick a scripting language without considering how it will fit into what the rest of your organization uses.  Even more important, you need to consider what the environment will support (if you do everything in one language, you might find out some of the target devices don't support it).

Complications and Time Factor

One of the most commonly asked questions about packaging and re-packaging is "How long does it take?" The answer is always "It depends.". No two software installations work exactly the same. Because of this, it is impossible to predict how long it will take to get a workable unattended installation package prepared and tested. Some of the variables that play a critical role in determining the time it takes to re-package an installation include:

• The original installation package format and integrity
• Vendor licensing and activation requirements
• Removal or Upgrade of older versions
• Checking for, and resolving prerequisites
• Per-machine vs Per-user configuration settings
• Operating System dependencies
• Business-specific configuration settings
• Vendor compliance with Microsoft's recommended guidelines
• Client/Server dependencies

This is not an exhaustive list, and each of these can greatly impact the difficulty with re-packaging the installation. In some cases, it can render the re-packaging process ineffective, requiring manual installation and configuration; something we try to avoid at all costs.

Other factors that should be factored in:

• The relative chemical stimulant consumption rate of the under-paid coders hired by the vendor (on contract, of course).
• The address of the mobile trailer they call an "office"
• Whether they include "Grateful Dead Reunion Tour" dates as paid holidays
• When you say "InstallShield" and they respond with "What's that?"
• When you really have to explain to the vendor what a "silent install" is
• When you call their "support line" and reach the owner/president/senior architect/coder guy every time.

I'm sure I could add more, but I'm too tired right now.  Let's move on...

Testing and Validation

Once an installation package has been developed, the next step in the process is to test it. In most cases, this is done by using "test" computers whereby a designated user will "remote" into the test computer from their own location and test the software installation. This eliminates the need for customers to travel around to physically sit down at the test computer and allows greater flexibility with scheduling.

In most cases, a virtual machine "test computer" will suffice just fine.  It doesn't matter what you prefer to work with (VMware, VirtualPC, VirtualBox, etc.) as long as it works and users can remote into it and do what they do (crash and break things, usually).

In some cases, usually when special hardware devices are required to be used with the software, it may be necessary for the customer to physically sit down at the test computer and log on, so they can use the hardware devices properly.

The process whereby customers test the software prior to it being deployed into production, is referred to as "User Acceptance Testing", or UAT.  But be careful, as UAT is *NOT* the entire testing process.  It's just one piece of it.

The most basic testing process goes something like this:

1. Install the application using the normal means, on an isolated test computer.  This helps the repackager get familiar with how the application "normally" installs, and what options and settings it provides along the way to completion.  This is sometimes called "Installation Analysis Testing" or IAT.  It's also equally important to use this step for documenting the "footprint" an application installation leaves on a computer.  Having a complete list of changes it makes to the Registry, File System, Services and security environment, are all crucial pieces of information. This is required for making sure that you build an uninstall package that does a thorough job of cleaning up when the application is removed.
2. After repacking, use the new repackaged package (a mouthful, sorry), to do the install to verify that it (A) installs properly, even silently, and (B) launches and functions properly after installation. This is sometimes called "Initial Package Testing" or IPT.  After running the IPT, it is vital that you confirm that the installed application functions properly. This also adds a new dimension to the "footprint" by virtue of launching and using the application, which often initiates a chain of post-installation configuration processes that modify additional things in the Registry, File System, Services, and so forth.  This is where a wrench often comes flying in from left field during the uninstall testing (IRT), so be prepared to make some adjustments to your uninstall package.
3. After the repackaged package has passed IPT, it's time to load it up into your deployment/distribution system (i.e. Microsoft System Center Configuration Manager) - (and you thought I couldn't string a bunch of words together into a longer name than that, pffft!).  Once loaded into your deployment system, the next step is to target a test computer to verify that the deployment system delivers the installation package, and installs it successfully.  This is sometimes called "Package Deployment Testing" or PDT.
4. After PDT, it's time to go to User Acceptance Testing, or UAT.  In most situations, you can use the same targeted test computer from the PDT without have to do another deployment, but the choice is yours (and varies by individual circumstances).
5. Once UAT is complete, you should be ready to remove the safety lock and fire with both barrels.  In other words, you should be ready to go to Production Deployment.

Some important notes pertaining to the above gibberish:

• Steps 2, 3 and 4 should be performed on a test computer for each type of target configuration.  In other words, if you will be expected to deploy this to Windows XP, Vista, Windows 7 and Windows 8 computers, you should definitely perform each test on an appropriate test computer.  And don't forget that 32-bit and 64-bit configurations add another layer of complexity (and testing).
• If your target user base does not (generally) have local Administrative permissions on their computer device, make sure you package and test with that expectation.  And more importantly: Be sure to have a user account logon and launch the application the FIRST TIME after being deployed, so that it will behave as it would on the other 99.99% of the target clients (unless you expect to walk around, or remote into, every computer after the deployment - which would probably suck).
• Useful tools in your arsenal for developing installation packages are InstallShield and AdminStudio.  But in addition to their primary capabilities, another useful aspect of AdminStudio is to use the Repackager "snapshot" feature to help compare "before" and "after" system states when doing your Uninstall development and testing.  For example, you can take a "before" snapshot, install and run the application, and then take an "after" snapshot.  The results of comparing both snapshots will reveal what aggregate changes were made to the system, thereby helping to shine some light on how to develop an effective package for removing the application completely and cleaning up behind it.

The level of testing you employ will depend upon the nature of your environment obviously.  The smaller and less complex an environment is, the less likely you will need to perform as many phases of testing. But it never hurts to test more than you think you should.  It usually saves you from yourself later on (if your poorly-tested, bad packaging output lands on 10,000 devices over a weekend, your Monday will very likely suck ass indeed).

Deployment

Once a software installation package has been tested and approved by the customer, the IT department can then begin to deploy it to the requested devices. The method we use is an automated deployment tool named Microsoft System Center Configuration Manager.

Final Thoughts

Software Packaging and Repackaging (two distinct processes) are a combination of science and art. While based upon technology (science), there is a lot of human intuition (art) involved as well.  If you expect to master these things using one or the other alone, you will be in for a tough time.  Also, be prepared to consume additional quantities of caffeine.