Windows Installer: what the vendor ordered
Continuing the theme of working with the Windows Installer, today I propose to talk about ready-made installers provided by software manufacturers - the term “vendor MSI” is widely used to refer to them.
As you remember from a previous article , Windows Installer is the industry standard for installation files and is used in most application deployment systems. Vendor MSI is very convenient for system administrators involved in software deployment in corporate networks. It would seem that it is enough to take the installation parameters from the documentation, use them on the command line or in a transform - and the job is done. Is it that simple?
I propose to look inside several vendor MSI and deal with their device.
There are exceptions to every rule. Despite the fact that the installation package has been tested by the manufacturer, be prepared to encounter unforeseen behavior during the installation process that occurs in your unique conditions.
Naturally, when preparing an application for deployment in a corporate environment, you should be guided primarily by the recommendations of the software manufacturer. However, sometimes the deployment system understands only the MSI format, and the vendor provides only the exe-installer - in this case, it makes sense to try to get the vendor MSI.
Suppose you need to deploy some application on our network. Usually we have an installation package received from the software manufacturer - copied from the installation disk, downloaded from the official site, etc.
If we do not have an installation package, we go to themanufacturer’s root tracker and look for the package there. The site does not have a package in MSI format, only an online installer or setup.exe? Let's try to search better. Often, the msi file for corporate users along with the deployment instructions is not on the main page, but in the section of the site with a big name like “For business” (for example, Google Chrome or Skype ), or on the ftp of the manufacturer. If there is a choice from the online and offline installer, select the offline option.
A simple rule is that the installation package (in any format) can only be downloaded from the manufacturer’s official website (or ftp). NEVER download the installer from the “file archives” and “program directories” so as not to encounter an unpleasant surprise .
Naturally, full versions of paid applications like Adobe Creative Suite you will not find in the public domain. If you have a license for the corporate version, but no installation files, feel free to contact the manufacturer’s support service.
So, we have the installation package. If it is a file with the extension .msi - we are dealing with vendor MSI (thanks, Cap!). If the installer contains a set of files, among which there is a file (s) with the extension .msi, this is also a candidate for the rank of vendor MSI. If the installer is a file with the .exe extension, it should not be written off immediately - there is a chance that this is a “wrapper” and vendor MSI will be found inside again.
This can be verified as follows:
• Try to open the exe-file using the archiver program (7-zip, WinRAR).
• Launch the installation of the application from the existing exe-file and look at the temporary folders (% temp%). Usually during installation, a folder with a random name is created, it contains installation files, including an msi file. We copy the installation files to a safe place - after the installation process is completed, the temporary folder is deleted.
• Look in the event logs at the end of the installation and check for fresh event records from the MsiInstaller source.
• your option?
Let's start with a simple experiment on the iTunes installer - open the iTunesSetup.exe file using 7-zip and see that it includes five msi files at once (I’ll suggest you decide on how many of them are “extra”).
After making sure that we are dealing with vendor MSI, we continue the study.
For convenience, I propose to highlight the main categories vendor MSI. The classification is completely arbitrary and based only on personal experience.
• “Pure MSI”
• “Combined MSI”
• MSI with simple configuration through transforms or parameters
• MSI with setup wizard
• MSI with answer file
Now about each a little more in detail and with examples.
A common property of this type of installers is the use of native Windows Installer mechanisms for installing files and registry keys. The records corresponding to these resources are present in the MSI tables (File, Registry, Shortcut, etc.). To make changes to the installation, it is enough to edit the records of these tables in the transform - you have almost complete control over the installation process.
Simple examples of “pure MSI” are Skype , InstEd .
To diagnose problems with such installers, standard features are used - reading event log entries (Application log, events with the MsiInstaller source) or full installation logging (starting msiexec with the / l * v parameter)
I included installers in the Windows Installer format in this category, installing resources in a non-standard way for Windows Installer. In this case, the Windows Installer is used for auxiliary tasks, and the main part of the work is performed by the binary Custom Action (.dll or .exe).
An example is Google Chrome for Business.
It is clearly seen that the File table in the installer is completely absent, and the main part of the installation is performed by a binary Custom Action called DoInstall, inside it there are files that will be installed on the system.
Another interesting example is the Java Runtime Environment. We extract the msi-file with the accompanying cab-file from the offline installer , distributed in the format of the exe-file.
The File table of this vendor MSI contains only four entries, the main application files are inside the zip archive (which, in turn, is inside the cab file) with their subsequent unpacking during the installation process:
regutils.dll, the name Custom, is responsible for the main part of the installation process Actions are quite eloquent:
This type of installer is a little more difficult to diagnose errors - the Windows Installer logs will give us useful information only until the start of the internal exe file, and the exe file itself does not always generate intelligible messages when errors occur. Also, such vendor MSIs are more difficult to configure. Or rather, our installation process setup options are most often limited only by the settings provided by the software manufacturer. For example, the software manufacturer does not always provide the ability to disable the installation of shortcuts or make changes to the application configuration files when installing it.
Installers of this type sometimes bring unpleasant surprises during the installation process (you had to deal with the JRE and Adobe Flash Player, who fell through the execution of Custom Action), and it may take some time to diagnose and fix errors.
Now let's move on to the package customization options offered by software manufacturers.
This is the most common way - most vendor MSIs have the ability to do this. Usually, the manufacturer has already provided the most popular settings, such as disabling application auto-updates and server connection settings, and described this in the documentation. Settings can be described in the form of installer command line parameters, MSI parameters (MSI properties) or even descriptions of registry entries that you can add to the transform for the package.
It is worth mentioning that sometimes in a newer version of vendor MSI, the parameters may behave differently from the previous one (or completely stop working, as it once happened with the JRE auto-update settings that stopped working ), but this is extremely rare.
Some vendors are not limited to publishing a list of command-line options for installing and configuring the package. They provide a utility for fine-tuning the installer that performs several useful functions:
• An intuitive interface eliminates the need for the system administrator to open the msi file in the editor and manually change a large number of entries in the tables
• The utility usually provides some “protection against fool” and checks the correctness of the values of the variable parameters.
As a result of the setup wizard for the msi file, a transform is formed that will be used when deploying the package. Naturally, you can view the contents of the saved transform by applying it to the msi file opened in the editor.
A good example of this approach is the Adobe Customization Wizard , which is used to configure installation options for Adobe Reader and Adobe Acrobat:
Another example of the well-known setup wizard is the Office Customization Tool (OCT) . This utility allows you to configure a large number of parameters related to the installation and user settings of MS Office. As a result of the wizard, an .msp file is created (a patch in the terminology of Windows Installer), which is used for further deployment of MS Office in a corporate environment.
This type of installation package should rather be called "Setup.exe with the answer file." The idea is that a certain installation file (let's call it Setup.exe) reads a configuration file (config.xml) previously generated by the system administrator and generates a set of parameters for launching a nearby msi installation file (or several msi files).
This approach does not provide for our work directly with the msi-file, so we will not dwell on it in too much detail. I’ll mention examples of such installers — Adobe Creative Suite settings files (versions CS2-CS3), as well as the use of the config.xml response file for installing MS Office.
Typically, for diagnostics in case of installation problems, you can use the log file created by the installer with a description of the stages of execution; additional information from the Windows Installer also ends up in the event logs.
As you can see, the generic name vendor MSI sometimes hides completely dissimilar installers. I hope this review article helped you get an idea of their diversity and possible installation problems and how to diagnose them.
As you remember from a previous article , Windows Installer is the industry standard for installation files and is used in most application deployment systems. Vendor MSI is very convenient for system administrators involved in software deployment in corporate networks. It would seem that it is enough to take the installation parameters from the documentation, use them on the command line or in a transform - and the job is done. Is it that simple?
I propose to look inside several vendor MSI and deal with their device.
There are exceptions to every rule. Despite the fact that the installation package has been tested by the manufacturer, be prepared to encounter unforeseen behavior during the installation process that occurs in your unique conditions.
Naturally, when preparing an application for deployment in a corporate environment, you should be guided primarily by the recommendations of the software manufacturer. However, sometimes the deployment system understands only the MSI format, and the vendor provides only the exe-installer - in this case, it makes sense to try to get the vendor MSI.
Where to get vendor MSI?
Suppose you need to deploy some application on our network. Usually we have an installation package received from the software manufacturer - copied from the installation disk, downloaded from the official site, etc.
If we do not have an installation package, we go to the
A simple rule is that the installation package (in any format) can only be downloaded from the manufacturer’s official website (or ftp). NEVER download the installer from the “file archives” and “program directories” so as not to encounter an unpleasant surprise .
Naturally, full versions of paid applications like Adobe Creative Suite you will not find in the public domain. If you have a license for the corporate version, but no installation files, feel free to contact the manufacturer’s support service.
So, we have the installation package. If it is a file with the extension .msi - we are dealing with vendor MSI (thanks, Cap!). If the installer contains a set of files, among which there is a file (s) with the extension .msi, this is also a candidate for the rank of vendor MSI. If the installer is a file with the .exe extension, it should not be written off immediately - there is a chance that this is a “wrapper” and vendor MSI will be found inside again.
This can be verified as follows:
• Try to open the exe-file using the archiver program (7-zip, WinRAR).
• Launch the installation of the application from the existing exe-file and look at the temporary folders (% temp%). Usually during installation, a folder with a random name is created, it contains installation files, including an msi file. We copy the installation files to a safe place - after the installation process is completed, the temporary folder is deleted.
• Look in the event logs at the end of the installation and check for fresh event records from the MsiInstaller source.
• your option?
Let's start with a simple experiment on the iTunes installer - open the iTunesSetup.exe file using 7-zip and see that it includes five msi files at once (I’ll suggest you decide on how many of them are “extra”).
After making sure that we are dealing with vendor MSI, we continue the study.
For convenience, I propose to highlight the main categories vendor MSI. The classification is completely arbitrary and based only on personal experience.
By type of resources:
• “Pure MSI”
• “Combined MSI”
By type of setting:
• MSI with simple configuration through transforms or parameters
• MSI with setup wizard
• MSI with answer file
Now about each a little more in detail and with examples.
"Clean MSI"
A common property of this type of installers is the use of native Windows Installer mechanisms for installing files and registry keys. The records corresponding to these resources are present in the MSI tables (File, Registry, Shortcut, etc.). To make changes to the installation, it is enough to edit the records of these tables in the transform - you have almost complete control over the installation process.
Simple examples of “pure MSI” are Skype , InstEd .
To diagnose problems with such installers, standard features are used - reading event log entries (Application log, events with the MsiInstaller source) or full installation logging (starting msiexec with the / l * v parameter
"Combined MSI"
I included installers in the Windows Installer format in this category, installing resources in a non-standard way for Windows Installer. In this case, the Windows Installer is used for auxiliary tasks, and the main part of the work is performed by the binary Custom Action (.dll or .exe).
An example is Google Chrome for Business.
It is clearly seen that the File table in the installer is completely absent, and the main part of the installation is performed by a binary Custom Action called DoInstall, inside it there are files that will be installed on the system.
Another interesting example is the Java Runtime Environment. We extract the msi-file with the accompanying cab-file from the offline installer , distributed in the format of the exe-file.
The File table of this vendor MSI contains only four entries, the main application files are inside the zip archive (which, in turn, is inside the cab file) with their subsequent unpacking during the installation process:
regutils.dll, the name Custom, is responsible for the main part of the installation process Actions are quite eloquent:
This type of installer is a little more difficult to diagnose errors - the Windows Installer logs will give us useful information only until the start of the internal exe file, and the exe file itself does not always generate intelligible messages when errors occur. Also, such vendor MSIs are more difficult to configure. Or rather, our installation process setup options are most often limited only by the settings provided by the software manufacturer. For example, the software manufacturer does not always provide the ability to disable the installation of shortcuts or make changes to the application configuration files when installing it.
Installers of this type sometimes bring unpleasant surprises during the installation process (you had to deal with the JRE and Adobe Flash Player, who fell through the execution of Custom Action), and it may take some time to diagnose and fix errors.
Now let's move on to the package customization options offered by software manufacturers.
MSI with simple configuration via transform or parameters
This is the most common way - most vendor MSIs have the ability to do this. Usually, the manufacturer has already provided the most popular settings, such as disabling application auto-updates and server connection settings, and described this in the documentation. Settings can be described in the form of installer command line parameters, MSI parameters (MSI properties) or even descriptions of registry entries that you can add to the transform for the package.
It is worth mentioning that sometimes in a newer version of vendor MSI, the parameters may behave differently from the previous one (or completely stop working, as it once happened with the JRE auto-update settings that stopped working ), but this is extremely rare.
MSI with setup wizard
Some vendors are not limited to publishing a list of command-line options for installing and configuring the package. They provide a utility for fine-tuning the installer that performs several useful functions:
• An intuitive interface eliminates the need for the system administrator to open the msi file in the editor and manually change a large number of entries in the tables
• The utility usually provides some “protection against fool” and checks the correctness of the values of the variable parameters.
As a result of the setup wizard for the msi file, a transform is formed that will be used when deploying the package. Naturally, you can view the contents of the saved transform by applying it to the msi file opened in the editor.
A good example of this approach is the Adobe Customization Wizard , which is used to configure installation options for Adobe Reader and Adobe Acrobat:
Another example of the well-known setup wizard is the Office Customization Tool (OCT) . This utility allows you to configure a large number of parameters related to the installation and user settings of MS Office. As a result of the wizard, an .msp file is created (a patch in the terminology of Windows Installer), which is used for further deployment of MS Office in a corporate environment.
MSI with answer file
This type of installation package should rather be called "Setup.exe with the answer file." The idea is that a certain installation file (let's call it Setup.exe) reads a configuration file (config.xml) previously generated by the system administrator and generates a set of parameters for launching a nearby msi installation file (or several msi files).
This approach does not provide for our work directly with the msi-file, so we will not dwell on it in too much detail. I’ll mention examples of such installers — Adobe Creative Suite settings files (versions CS2-CS3), as well as the use of the config.xml response file for installing MS Office.
Typically, for diagnostics in case of installation problems, you can use the log file created by the installer with a description of the stages of execution; additional information from the Windows Installer also ends up in the event logs.
As you can see, the generic name vendor MSI sometimes hides completely dissimilar installers. I hope this review article helped you get an idea of their diversity and possible installation problems and how to diagnose them.