After the general overview about application packaging, benefits and best practices in Part I of this series, it is time to start working understanding existing installation packages, handle some examples and reviewing step-by-step processes we will need to start packaging applications.

In this second post, the focus will be packaging applications without the use of any 3^rd party tool, basically achieving applications deployment with silent and customized installations. What we will review in this article:

1. MSI Files are your New Best Friends
a) Reviewing the Windows Installer
b) Using MSIEXEC.EXE
2. Understanding and Identifying Installer Vendors
a) InstallShield Overview
b) Wise Installation System Overview
c) Inno Setup Overview
d) SetupBuilder and ActualInstaller Overview
3. Packaging Examples for Silent and Customized Installations: First Approach
a) Finding our MSI when there’s no MSI
b) Creating and Using “.iss” Answer Files
c) Troubleshooting InstallShield Deployments

MSI Files are your New Best Friends

So, after we’ve decided that silent installations is going to be our first stop in packaging applications, we must know that MSI files provides the best way to achieve that.

An MSI file is a container that works with an embedded engine in the OS (Windows Installer service) in order to facilitate applications installations and uninstallations. This platform (MSI + Windows Installer service) contains all necessary instruments to accomplish a customized, automated and silent installation.

Later in the next following posts we will discuss on the components in an MSI file, but initially we can take a quick overview about the Windows Installer platform, the MSI files and how we should interact with them.

Reviewing the Windows Installer

The Windows Installer service appeared embedded in the Windows OS since Windows 2000 and with the solution to several problems about inconsistencies in the software vendors on how they were using the application installers, typically in setup.exe files.

The Windows Installer services function is to support the application life-cycle: installation and customization, maintenance (auto-repair and patching for example) and retirement. To process all of these steps is msiexec.exe. MSIEXEC takes all the information contained in the MSI file (installation database, a summary information stream, and data streams for various parts of the installation) and other optional (in most cases) files, to perform the installation or desired process.

These other files can be MST (Windows Installer Transform), which contains customizations for the installation (for example, features to be installed); MSP (Windows Installer Patch) representing application update/patch.

The complete list for installation files available:

It is important to remember that MSI files support silent installations natively; meaning that every application containing one will be suited for this type of installation.

We will take a closer look to the MSI components in the following posts when we start building our own. For now, we will focus on how to use them in silent installations.

Using MSIEXEC.EXE

As we were talking, msiexec.exe represents the engine from which the Windows Installer performs any of the life-cycle tasks of each application. Using msiexec, if you haven’t before, it’s simple and should not represent any problem.

Once we have our MSI file, using it for silent installations should be in most cases as the following example:

msiexec.exe /I <path_to_MSI.msi> /qn

• Using “/I” parameter at the beginning we are configuring MSIEXEC to install or configure the application (also known as “product”).
• The “/qn” parameter represents for a “quiet” (q) installation (no user interaction) and “No User Interface” (n). This way, the application will complete its installation without prompting any notification for the user.

If everything about packaging and deploying applications would be represented by MSI files, then these articles won’t be necessary. We’ll see that most of the times, we will have to deal with EXE files for deployment.

Also, using these EXE files could have different methods according the vendor that created the installer. In the following section we will review how to handle those situations.

Understanding and Identifying Installer Vendors

Even though there are plenty of EXE files which contain MSI files within (to be reviewed later in this post), there are other files with no MSI file available but supporting a silent installation method. To identify how we can silent install the application we must first understand which installer vendor (if any) was used for this app. Identifying is not always easy, the installer icon available could be helpful and sometimes we will just have to guess.

The most common vendors involved in installation files are:

• InstallShield, from Flexera Software
• Wise Installation System (formerly InstallMaster), from Symantec (previously from Wise)
• SetupBuilder, from LinderSoft
• ActualInstaller, from Softeza Development
• Inno Setup, from JR Software (open source project)

InstallShield Overview

This is probably the most common vendor involved for developing installation files. We can easily identify their installers by reviewing the logo involved.

There are also two ways we can deploy InstallShield packages, which actually depends if the MSI file was included in the installation package:

1. If the MSI is included in the package, the InstallShield installer should support a silent installation using this example (the /v parameter is optional for verbose):

setup.exe /s /v"/qn"

2. If the MSI is not included there’s an interesting method for some legacy installers to use “answer files”, InstallShield calls this “Package for the Web”. We will need to run an installation with specific parameters to generate our answer file (“.iss”) that we can later use for deploying the application silently and with specific parameters. We will discuss the details later in this article.

The “Package for the Web” has been discontinued by Flexera Software, and it will no longer be available for InstallShield packages. But, most likely, in most organizations we can still find this alternative as a valid method.

To review the complete parameters available for InstallShield check this link: “Setup.exe Command Line Parameters”

Wise Installation System Overview

You will find this installation file type in some legacy applications in your environment. Wise Solutions was the creator of this platform, which originally started with CompuServe; later on was acquired by Altiris Inc, which also had been acquired by Symantec on 2007. The last release of this suite was 9.0 but has been already discontinued by Symantec.

The applications created with this platform support the classic “/s” parameter for silent installations.

setup.exe /s

But unfortunately there are no other options available for customization and the exit status when you executed the process was inconsistent, so it might get a little bit confusing.

Inno Setup Overview

This open source project has been receiving significant contribution of the community in all the years it has been available (since 1997), supports all Windows OS, including Windows 8 and Windows Server 2012.

The command line used for supporting silent installations in this suite are:

setup.exe /sp- /verysilent /norestart

• “/sp-“: Disables the “This will install… Do you wish to continue?” prompt at the beginning of Setup.
• “/verysilent”: Will execute silently the installation process. The “/silent” parameter is available but, even though it will not require users’ intervention will show a progress bar.
• “/norestart”: Prevents automatic restarts, which can be very useful if the “verysilent” parameter is used since it will automatically restart the OS without the user intervening.

For more information about Inno command lines available: “Setup Command Line Parameters”.

SetupBuilder and ActualInstaller Overview

SetupBuilder and ActualInstaller represent a couple of somehow new installation packagers’ vendors available in the market. Like many of these recent suites, both platforms support Windows 8 and Windows Server 2012.

One of the most common standards for recent installation packagers is the use of the same type of parameters for the silent and customized installations. SetupBuilder and ActualInstaller have the same silent installation method:

setup.exe /S

Among other providers we will find the same parameters that can be used, we have to be aware that sometimes the parameters are case-sensitive.

Packaging Examples for Silent and Customized Deployments: First Approach

Let’s review some of the examples we can find when we want to package applications using silent and customized deployments.

Finding our MSI when there’s no MSI

One common situation that we might find is that the application we are trying to deploy does not contain an MSI file, instead we are provided with an exe file that could not support silent installations. But, fortunately, most times there are some secrets hiding in plain sight.

When we are handling EXE installer files (usually as setup.exe), several times we are using an installer file that is actually a packaged set of files that contain an MSI, installation instructions and other optional files that could be used during the installation.

Companies use this alternative to have more scalable installation procedures that cannot be achieved with one MSI file. For example: Adding several MSI files which can be activated depending on the type of installation selected by the user. One example for this situation is Apple’s iTunes.

There are a two ways to extract the needed MSI file/s. Let’s review them using Google Earth as our application:

In the particular case of Google Earth, we need to download the standalone installer for the application available in this link.

1. Double click the EXE installer file and when the installation wizard starts access %TEMP% folder to locate our MSI. This process is called “expanding EXE packages”.

Most of the times, the files are located in a folder using a random name (in this case %TEMP%\._msige61).

2. Use 7-Zip File Manager to browse inside the EXE file. This free tool is quite useful, all we need to do is use the option “Open Inside” and we can browse around the installer and handle all the files within.

3. Some software vendors provide a command line to extract the files without the need to double click them or using 7-Zip File Manager.

Once we have our MSI, the process for a silent installation is simple:

msiexec /i “Google Earth.msi” /qn

Creating and Using “.iss” Answer Files

As we reviewed earlier in this article, InstallShield represents one of the vendors commonly used by software companies to create their installers. When we handle this type of installer, we get the simple option to use the “/s /qn” parameter or we might need to create an answer file.

This answer or response file is represented by our “.iss”. This file must be created running a command line which will install the software normally with all the desired options, but creating in the process the .iss file to be used in other deployments. Since every time we need to create an answer file we will need to install the software, using virtual machines and snapshots will be quite useful at this point.

InstallShield also supports the use of different compiled scripts, .ins files. Only applies for InstallScript and InstallScript MSI projects only, InstallShield version 12 and earlier.

The process for creating response files and then deploying the package is the following:

1. Locate your setup.exe (or the installer’s name) and a target machine to deploy the application (ideally a virtual machine).

2. Open a command line and execute the following to create the “setup.iss” response file:

setup.exe /r

The response file will be created in %WINDIR% (typically C:\Windows), but we can alternatively change the path by using the following command line:

setup.exe /r /f1”C:\setup.iss”

Note that there’s no space between –f1 and the “<>“ with the destination path.

3. Install the application with all the customization’s necessary.

4. Once is completed, locate the setup.iss file created.

5. To deploy the application, if we are using the .iss file with the default name (“setup.iss”) and is located in the same folder as the installer, we can deploy our package using the following command line:

setup.exe /s /v/qn

If we changed the name of the response file or we have it located in a different folder, the command line should be the following:

setup.exe /s /f1”<.iss name and location>”

Keep in mind that there’s no space between –f1 and the “<>“ with the file location.

6. [Optional] We can use /f2 as a parameter to create a log file for the deployment:

setup.exe /s /f1”<.iss name and location>” /f2”<.log name and location>

If we don’t set log file name and location, it will automatically generate “setup.log” file.

Troubleshooting InstallShield Deployments

In case there’s a deployment issue with our package, creating the setup.log would be mandatory in order to find out the exact problem we have.

The Setup.log file contains three sections.

• [InstallShield Silent]: Identifies the version of InstallShield Silent used in the silent installation.
• [Application]: Details Installed application’s name and version, and the company name.
• [ResponseResult]: The result code indicating whether or not the silent installation succeeded.

The result codes can be one of the following:

-0 Success.
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialogs are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.

In the next article we will review more details about silent and customized deployment, including more examples in more complex scenarios.