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:
Vista
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.
