MSI Generation
Previous  Top  Next

Thinstall can optionally generate auto-registering .msi files during the build process.


When to consider building an MSI

You may consider building an MSI database when you need to deliver Thinstall packaged applications through traditional desktop management systems to remote locations and have shortcuts and filetype associations automatically created. .msi packages provide a very simply way to do this. Most systems including plain Active Directory Group Policy provide simple methods to push and execute .msi packages.

What is included in a MSI database created by Thinstall?

1. A copy of all the Thinstalled EXE files for a specific project
2. A copy of the ThinReg registration utility.

What happens when a Thinstall created .msi package is executed on an end-user desktop?

1. The msi database will extract your Thinstalled EXE file(s) to c:\program files. You can use the optional configuration option MSIInstallDirectory to control where files are extracted to.
If you specify ALLUSERS="" to msiexec, or you create a .msi package that install's per-user by default using the configuration option MSIDefaultInstallAllUsers then the Thinstalled EXE files will be extracted to the users %AppData% directory.
2. The msi install will execute ThinReg to register filetypes and create shortcuts.

How to build an MSI database

1. Edit a package file generated by package.ini to specify "MSIFilename=<filename>.msi"
2. run build.bat

Note: If MSIFilename is not specified, msi generation will be skipped during the build process.

By default, the generated database will install machine-wide. You can change this by setting the option


This will create a database which will have a default of per-user installation.

msiexec command-line parameters
Irrespective of what you specified at package build time, you can still override the type of installation at deploy time. For example, if you created the database with "MSIDefaultInstallAllUsers=1", you can still force a per-user deployment by deploying using:

msiexec /i <database>.msi ALLUSERS=""

If you want to force a per-machine deployment you'd use:

msiexec /i <database>.msi ALLUSERS=1

To default to per-machine install for Administrators (belonging to the "Administrators" group) and per-user for non-Administrators, set the value of MSIDefaultInstallAllUsers to 2.

When doing a per-machine deployment, the default installation directory is the localized equivalent of "%ProgramFilesDir%\<InventoryName> (Thinstalled)". For a per-user deploy, the default is "%AppData%\<InventoryName> (Thinstalled)". In both cases, you can override the installation directory by passing an INSTALLDIR property to msiexec:

msiexec /i <database>.msi INSTALLDIR=C:\Mydir\Mypackage

For deployment on Vista, you need to indicate whether an installer needs elevated privileges or not. Normally, when doing a per-user install you won't need elevated privileges but when doing a per-machine install you will. You can specify whether the package needs elevated privileges by using the "MSIRequireElevatedPrivileges" option. If you're going to deploy the installer machine-wide, set the value to "1". This will result in UAC prompts (if you have them enabled), even if you force a per-user installation by using the ALLUSERS="" commandline option. By setting the option to "0", you won't get a UAC prompt but the install will fail if you then try to install it machine-wide.

Handling Upgrades
A MSI database contains a number of codes, among which a "ProductCode" and an "UpgradeCode". When rebuilding a package, it is recommended that the UpgradeCode is kept the same. This can be specified using the "MSIUpgradeCode" option. You can change the ProductCode (via the MSIProductCode option) if desired. The advantage of changing the ProductCode is that it is easier to install a newer version. If the ProductCode of the new version is the same as the ProductCode of the old version, the install will prompt you to remove the old version using Add/Remove Programs first. If the ProductCode is different, the install will silently uninstall the old version and then install the new version.
If you don't specify a MSIProductCode option, a different ProductCode will be generated for each build automatically.