Windows Installer: what the vendor ordered
Continuing the theme of working with 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 the previous article , Windows Installer is an industry standard installation file and is used in most application deployment systems. Vendor MSI is very convenient for system administrators involved in deploying software in corporate networks. It would seem that it is enough to take the installation parameters from the documentation, use them in the command line or in the transform - and it's done. Is everything so simple?
I suggest to look inside several vendor MSI and deal with their device.
There are exceptions to every rule. Despite the fact that the installation package was tested by the manufacturer, be prepared to face unforeseen behavior during the installation process that arises precisely in your unique conditions.
')
Naturally, when preparing an application for deployment in a corporate environment, one 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 an exe-installer - in this case it makes sense to try to get exactly the vendor MSI.
Suppose you need to deploy some application in our network. We usually 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 the installation package, go to themanufacturer’s root-tracker site and look for the package there. The site does not have a package in the format of MSI, only the online installer or setup.exe? Let's try to look 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 loud name like “For business” (for example, Google Chrome or Skype ), or on the manufacturer's ftp . If there is a choice of online and offline installer - choose the offline option.
A simple rule - the installation package (in any format) can be downloaded only from the official site (or ftp) of the manufacturer. NEVER download the installer from the “file archives” and “program directories”, so as not to face an unpleasant surprise .
Naturally, the full version 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 there are no installation files, feel free to contact the manufacturer's support service.
So, we have an installation package. If it is a file with the .msi extension, 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 .msi extension, this is also a candidate for the title of vendor MSI. If the installer is a file with the .exe extension, it should not be immediately discounted - there are chances that this is a “wrapper” and the vendor MSI will show up inside again.
This can be verified by:
• Try to open the exe file using an archiver (7-zip, WinRAR).
• Start the installation of the application from the existing exe-file and look into the temporary folders (% temp%). Usually, during installation, a folder with a random name is created, it contains installation files, including the msi file. Copy the installation files in a safe place - after the installation process is completed, the temporary folder is deleted.
• Look at the event logs at the end of the installation and check for the presence of fresh event records with 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 suggest you decide how many of them are “superfluous”).
Making sure that we are dealing with vendor MSI, we continue to research.
For convenience, I propose to highlight the main categories of vendor MSI. The classification is completely conditional and based only on personal experience.
• “Clean MSI”
• "Combined MSI"
• MSI with easy setup via transform or parameters
• MSI with setup wizard
• MSI with answer file
Now about each a little more detail and with examples.
A common property of this type of installer is the use of Windows Installer native 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" - Skype , InstEd .
To diagnose problems with such installers, the standard features are used - reading event log entries (Application log, events with the MsiInstaller source) or full installation logging (running msiexec with the / l * v <install.log> parameter).
In this category, I took installers in the Windows Installer format, installing resources in a way that is not standard for Windows Installer. In this case, the Windows Installer is used for auxiliary tasks, and the binary Custom Action (.dll or .exe) performs the bulk of the work.
Example one is Google Chrome for Business.
It is clearly seen that the File table in the installer is absent altogether, 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 into the system.
Another interesting example is the Java Runtime Environment. 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 located inside the zip archive (which in turn is inside the cab file) and then unpacked during the installation process:
The regutils.dll file is responsible for the main part of the installation process, the Custom Actions names are quite eloquent:
This type of installer is somewhat harder to diagnose errors - the Windows Installer logs will give us useful information only until the launch of the internal exe-file, and the exe-file does not always generate intelligible messages when errors occur. Also such vendor MSI harder to customize. Rather, our ability to customize the installation process is often limited only by the settings provided by the software manufacturer. For example, a software manufacturer does not always provide for the ability to disable the installation of shortcuts or make changes to the application settings files during its installation.
Installers of this type sometimes present unpleasant surprises during the installation process (you had to deal with the JRE and Adobe Flash Player, which fell to the execution of the Custom Action), and it may take some time to diagnose and correct errors.
We now turn to the options for customizing packages offered to us by software manufacturers.
This is the most common way - most vendor MSIs have the ability to do this. Typically, the manufacturer has already provided the most popular settings, such as disabling the auto-updates of the application and the settings for connecting to the server, and described this in the documentation. Settings can be described as installer command-line parameters, MSI parameters (MSI properties), or even registry entry descriptions that you can add to the transform for a package.
It is worth mentioning that sometimes in a newer version of the vendor MSI, the parameters may not behave as in the previous one (or stop working altogether, as once happened with the JRE autoupdate disable options that stopped working), but this is extremely rare.
Some vendors are not limited to publishing a list of command line parameters for installing and configuring the package. They provide a utility for tweaking the installer that performs several useful functions:
• An intuitive interface saves the system administrator from having to open the msi file in the editor and manually change a large number of records in the tables.
• The utility usually provides some “protection against a fool” and checks the correctness of the values ​​of variable parameters.
As a result of the configuration wizard for the msi file, a transform is formed that will be used when the package is deployed. Naturally, you can view the contents of the saved transform by applying it to the open msi file in the editor.
A good example of this approach is the Adobe Customization Wizard , which is used to customize the Adobe Reader and Adobe Acrobat installation settings:
Another example of a famous 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 the Windows Installer), which is used in the further deployment of MS Office in a corporate environment.
This type of installation package should rather be called “Setup.exe with an Answer File”. The idea is that a certain installation file (let's call it Setup.exe) reads a configuration file previously generated by the system administrator (config.xml) and generates a set of parameters for running the installation msi-file located next to it (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 will mention examples of such installers — Adobe Creative Suite configuration files (CS2-CS3 versions), as well as the use of the config.xml answer file for installing MS Office.
Usually 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 gets into the event logs.
As you can see, completely different installers sometimes hide behind the generic name vendor MSI. 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 the previous article , Windows Installer is an industry standard installation file and is used in most application deployment systems. Vendor MSI is very convenient for system administrators involved in deploying software in corporate networks. It would seem that it is enough to take the installation parameters from the documentation, use them in the command line or in the transform - and it's done. Is everything so simple?
I suggest to look inside several vendor MSI and deal with their device.
There are exceptions to every rule. Despite the fact that the installation package was tested by the manufacturer, be prepared to face unforeseen behavior during the installation process that arises precisely in your unique conditions.
')
Naturally, when preparing an application for deployment in a corporate environment, one 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 an exe-installer - in this case it makes sense to try to get exactly the vendor MSI.
Where to get vendor MSI?
Suppose you need to deploy some application in our network. We usually 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 the installation package, go to the
A simple rule - the installation package (in any format) can be downloaded only from the official site (or ftp) of the manufacturer. NEVER download the installer from the “file archives” and “program directories”, so as not to face an unpleasant surprise .
Naturally, the full version 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 there are no installation files, feel free to contact the manufacturer's support service.
So, we have an installation package. If it is a file with the .msi extension, 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 .msi extension, this is also a candidate for the title of vendor MSI. If the installer is a file with the .exe extension, it should not be immediately discounted - there are chances that this is a “wrapper” and the vendor MSI will show up inside again.
This can be verified by:
• Try to open the exe file using an archiver (7-zip, WinRAR).
• Start the installation of the application from the existing exe-file and look into the temporary folders (% temp%). Usually, during installation, a folder with a random name is created, it contains installation files, including the msi file. Copy the installation files in a safe place - after the installation process is completed, the temporary folder is deleted.
• Look at the event logs at the end of the installation and check for the presence of fresh event records with 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 suggest you decide how many of them are “superfluous”).
Making sure that we are dealing with vendor MSI, we continue to research.
For convenience, I propose to highlight the main categories of vendor MSI. The classification is completely conditional and based only on personal experience.
By type of resources:
• “Clean MSI”
• "Combined MSI"
By type of setting:
• MSI with easy setup via transform or parameters
• MSI with setup wizard
• MSI with answer file
Now about each a little more detail and with examples.
"Pure MSI"
A common property of this type of installer is the use of Windows Installer native 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" - Skype , InstEd .
To diagnose problems with such installers, the standard features are used - reading event log entries (Application log, events with the MsiInstaller source) or full installation logging (running msiexec with the / l * v <install.log> parameter).
"Combined MSI"
In this category, I took installers in the Windows Installer format, installing resources in a way that is not standard for Windows Installer. In this case, the Windows Installer is used for auxiliary tasks, and the binary Custom Action (.dll or .exe) performs the bulk of the work.
Example one is Google Chrome for Business.
It is clearly seen that the File table in the installer is absent altogether, 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 into the system.
Another interesting example is the Java Runtime Environment. 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 located inside the zip archive (which in turn is inside the cab file) and then unpacked during the installation process:
The regutils.dll file is responsible for the main part of the installation process, the Custom Actions names are quite eloquent:
This type of installer is somewhat harder to diagnose errors - the Windows Installer logs will give us useful information only until the launch of the internal exe-file, and the exe-file does not always generate intelligible messages when errors occur. Also such vendor MSI harder to customize. Rather, our ability to customize the installation process is often limited only by the settings provided by the software manufacturer. For example, a software manufacturer does not always provide for the ability to disable the installation of shortcuts or make changes to the application settings files during its installation.
Installers of this type sometimes present unpleasant surprises during the installation process (you had to deal with the JRE and Adobe Flash Player, which fell to the execution of the Custom Action), and it may take some time to diagnose and correct errors.
We now turn to the options for customizing packages offered to us by software manufacturers.
MSI with easy setup via transform or parameters
This is the most common way - most vendor MSIs have the ability to do this. Typically, the manufacturer has already provided the most popular settings, such as disabling the auto-updates of the application and the settings for connecting to the server, and described this in the documentation. Settings can be described as installer command-line parameters, MSI parameters (MSI properties), or even registry entry descriptions that you can add to the transform for a package.
It is worth mentioning that sometimes in a newer version of the vendor MSI, the parameters may not behave as in the previous one (or stop working altogether, as once happened with the JRE autoupdate disable options that stopped working), but this is extremely rare.
MSI with setup wizard
Some vendors are not limited to publishing a list of command line parameters for installing and configuring the package. They provide a utility for tweaking the installer that performs several useful functions:
• An intuitive interface saves the system administrator from having to open the msi file in the editor and manually change a large number of records in the tables.
• The utility usually provides some “protection against a fool” and checks the correctness of the values ​​of variable parameters.
As a result of the configuration wizard for the msi file, a transform is formed that will be used when the package is deployed. Naturally, you can view the contents of the saved transform by applying it to the open msi file in the editor.
A good example of this approach is the Adobe Customization Wizard , which is used to customize the Adobe Reader and Adobe Acrobat installation settings:
Another example of a famous 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 the Windows Installer), which is used in the 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 an Answer File”. The idea is that a certain installation file (let's call it Setup.exe) reads a configuration file previously generated by the system administrator (config.xml) and generates a set of parameters for running the installation msi-file located next to it (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 will mention examples of such installers — Adobe Creative Suite configuration files (CS2-CS3 versions), as well as the use of the config.xml answer file for installing MS Office.
Usually 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 gets into the event logs.
As you can see, completely different installers sometimes hide behind the generic name vendor MSI. I hope this review article helped you get an idea of ​​their diversity and possible installation problems and how to diagnose them.
Source: https://habr.com/ru/post/139213/
All Articles