Kraft Kennedy has developed a deep knowledge of application packaging over the course of numerous desktop projects, ranging all the way back from Windows 2000 to the current Windows 8.1. Unfortunately, “difficult” application installers are still commonplace in the legal market and application packaging is still as challenging as ever. In this blog I share some of the best practices we use while developing our Application Vault, a repository of legal and non-legal applications used by our clients.
Golden Rule
One of the most highly regarded best practices for application packaging is to use the vendor install code as much as possible. There are several reasons to follow this tenant:
- Often there is logic within the installer that checks the state of the workstation and then determines what to install and how to install it.
- The code ensures that application upgrades work properly.
- Using the vendor installer is likely required for vendor support of the product.
Ideal Situation
The ideal situation is when the vendor installer is provided as a Microsoft Software Installer (MSI) file. We can use the vendor supplied MSI as a base for an application package, making any configuration changes by creating a transform file (MST file) and applying that MST during the installation of the application. Many vendor installers include a setup.exe executable as well as an MSI. The most desirable outcome here is that the setup.exe is merely an installation wrapper, and the MSI can be used directly without having to reference the setup.exe at all.
Often, though, when attempting to directly install using this type of MSI, an error dialog is displayed indicating that the application must be installed using setup.exe. With some software, this dialog box can be suppressed by using a transform file to ignore the logic that generates this error, and the application will install and function properly. In situations where the setup.exe executable must be used to install the software, we may still be able to use the MSI to create a transform file that contains configuration changes. To use the transform during the installation, we can try to use the following type of installation commands; for applications where we can eliminate the need for a setup.exe:
msiexec.exe /i “application.msi” TRANSFORMS=application.mst /qn
For applications where we must use the setup.exe we can more often than not still pass a transform:
setup.exe /s /v"TRANSFORMS=application.mst /qn"
Detective Work
When the vendor installer takes the form of a single setup executable you might be left scratching you head because no silent command line options exist. Luckily in this scenario there are a couple of ways to determine if there is an MSI that can be leveraged for creating an application package. Normally, the first step is to use 7-Zip (WinZip or WinRAR are also acceptable tools) to see if the setup files can be extracted, and then search the extracted contents. If this doesn’t provide a set of usable files, we can also try running the setup executable with a “/extract” parameter to see if this properly extracts the contents, which can then be searched. Lastly, another method is to initiate the installation using the setup executable, and then browse to the %TEMP% folder to see if the MSI (and set of supporting files) is available in a {GUID} folder that may be getting generated. If none of these provide a usable MSI file, then we try to see if the setup executable can be run silently. At this point it’s always a good idea to dig into whatever documentation is available to see if a silent process is supported by the vendor.
The last resort is always to capture the installation process to an MSI using a repackaging tool such as AdminStudio Repackager. Recapturing to an MSI removes all the logic that may have been included in the vendor installer. The captured MSI is a snapshot of what was installed to the system. To provide the best chance of capturing all files and settings, always use a system with the minimal number of required applications installed.