MSI Windows Installer Bootstrapping
- April 13, 2022
- Posted by: Pavithra
- Category: End User Computing
What is bootstrapping?
MSI Windows Installer Bootstrapping , A setup application Instmsi.exe is available with the Windows Installer SDK that contains all logic and functionality to install Windows Installer
When bootstrapping is used?
MSI Windows Installer Bootstrapping , Currently every installation that attempts to use the Windows® Installer begins by checking whether the installer is present on the user’s computer, and if it is not present, whether the user and computer are ready to install Windows Installer. However, a bootstrapping application must manage this installation. The bootstrapping application must first check to see whether Windows Installer is currently installed. Applications can get the version of Windows Installer currently installed by using DllGetVersion. If Windows Installer is not currently installed, the bootstrapping application must query the operating system to determine which version of the Instmsi.exe is required. Once the installation of Windows Installer has initiated, the bootstrapping application must handle return codes from the Instmsi.exe application and handle any reboot that is incurred during the Windows Installer installation
Digital Signature and Windows Installer
The Windows Installer version 2.0 uses digital signatures to detect corrupted resources. A signer certificate may be compared to the signer certificate of an external resource to be installed by the package.
With Windows Installer version 2.0, digital signatures can be used with Windows Installer packages, transforms, patches, merge modules, and external cabinet files. Windows Installer version 2.0 is integrated with Software Restriction Policy on Microsoft® Windows XP. Policies can be created to allow or prevent installations based upon different criteria, including a particular signer certificate or publisher. The Windows Installer version 2.0 can perform signature validation of external cabinet files on all platforms where CryptoAPI version 2.0 is installed.
Note that the sample Setup.exe bootstrap provided with the Windows Installer SDK performs a signature check on a Windows Installer package prior to initiating the installation.
Performing an administrative installation removes the digital signature from the package. An administrative installation modifies the installation package in order to add the AdminProperties stream, which would invalidate the original digital signature. An administrator can resign the package. Applying a patch to an administrative installation also removes the digital signature from the package. The reason is because the changes persist in the patched installation package of the administrative installation. An administrator can resign the package. Starting with Windows Installer 3.0, User Account Control (UAC) Patching enables non-administrator users to patch applications installed in the per-machine context. UAC patching is enabled by providing a signer certificate in the MsiPatchCertificate table and signing patches with the same certificate.
What is Source Resiliency?
Applications that rely on network resources for installation-on-demand are susceptible to source failures if the source location should change for any reason or become damaged. The Windows Installer provides source resiliency for features that are installed on-demand by using a source list. The source list contains the locations searched by the installer for installation packages. The entries in this list can be network locations, Uniform Resource Locators (URLs), or compact discs. If one of these sources fails, the installer can quickly and seamlessly try the next. If it still does not find, it prompts the user for the source location.
How does Source Resiliency work?
The application developer does not need to incorporate any special information into the installer package to ensure source resiliency. Once the application is installed, the installer has the behavior of adding the last successfully used source as an entry in the source list. By default, this source is the location from which the installer package is initially installed, and is the same as the SourceDir property. A system administrator can change the source list by applying a transform or by changing the SOURCELIST property from the command line or in the Property table. The installer begins searching for a source by checking the most recently used source location in the source list. If this search fails, the installer searches the list of network sources, then media sources, and finally URL sources. System administrators can change this search order using the SearchOrder system policy. If these searches fail, the installer may present a Browse Dialog so that the user can search for the source manually. The browse dialog box cannot be displayed if the User Interface Level is set to none. Commonly, the installer should only display a browse dialog box if the current user is an administrator or if the installation does not require elevated privileges. An administrator can control the display of the browse dialog box to users with the DisableBrowse and AllowLockDownBrowse policies. An administrator also controls whether users can install applications from sources located on media by using the DisableMedia and AllowLockDownMedia policies. The use of these policies depends on the Windows Installer version.
What are System Policies?
The installation behavior of the Windows Installer can be configured by an administrator by using the Group Policy Editor (GPE), on Microsoft Windows 2000 or by using the System Policy Editor on Windows 95, Windows 98, and Microsoft Windows NT. There are two types of System Policies: –
The following user policies can be configured under
|Value name||Value data types||Description|
|AlwaysInstallElevated||REG_DWORD||If this value is set to “1” and the corresponding computer value is also set, the installer always installs with elevated privileges. Otherwise, the installer uses elevated privileges to install managed applications and uses the current user’s privilege level for non-managed applications.|
|DisableMedia||REG_DWORD||If the DisableMedia policy is set to “1”, users and administrators running a maintenance installation of one product are prevented from using the Browse Dialog to browse media sources, such as CD-ROM, for the sources of other installable products. Browsing for other products is prevented regardless of whether the installation is with elevated privileges. It is still possible for the user to reinstall the product from media if the user has a correctly labeled media source. This policy is not available with Windows Installer version 1.0.|
|DisableRollback||REG_DWORD||If this value is set to “1”, the installer will not store rollback files during installation, disabling installation rollback. By default, rollback is enabled. Administrators are advised to not use this policy unless it is absolutely essential.|
|SearchOrder||REG_SZ||Order in which the installer searches the three different types of sources: “n” – network “m” – media (CD-ROM or DVD) “u” – URL (Uniform Resource Locator) For example, a value of “nmu” instructs the installer to search network sources first, media sources second, and URL sources last. Leaving out a letter removes the corresponding volume type from the search. Default order in absence of this value is network first, then media followed by URL.|
|TransformsAtSource policy||REG_DWORD||If this value exists and is set to “1”; the installer searches for transform files in the root of any network sources in the sourcelist for the product. By default, transforms are stored in the Application Data folder of a user’s profile. This policy is not available with Windows Installer version 1.1.|
The following machine policies can be configured under:
|Policy||Value data type||Description|
|AlwaysInstallElevated||REG_DWORD||If this policy value is set to “1” and the corresponding user value is also set, the installer always installs with elevated privileges. Otherwise, the installer uses elevated privileges to install managed applications and uses the current user’s privilege level for unmanaged applications.|
|AllowLockdownBrowse||REG_DWORD||If this policy value is set to “1”, non-administrative users can browse for new sources while running an installation at elevated privileges. The default is that only administrators can browse for sources during an elevated installation. Setting this policy also enables non-administrative users to run programs at LocalSystem privileges during an elevated installation. This policy is not available with Windows Installer version 1.0.|
|AllowLockdownMedia||REG_DWORD||If this policy value is set to “1”, non-administrative users can use media sources, such as a CD-ROM, while running an installation at elevated privileges. The default is that only administrators can use media sources during an elevated installation. Setting this policy also enables non-administrative users to run programs at LocalSystem privileges during an elevated installation. This policy is not available with Windows Installer version 1.0.|
|AllowLockdownPatch||REG_DWORD||If this per-machine system policy value is not set, only administrators can patch existing products that were installed at elevated privileges. If this policy value is set to “1”, non-administrative users can, in some cases, apply patches to products while running an installation using elevated privileges. With the policy set, the patch can install minor upgrades while running an installation using elevated privileges; the patch cannot install major upgrades. Setting this policy also enables non-administrative users to run programs at LocalSystem privileges during an elevated installation. This policy is not available with Windows Installer version 1.0.|
|Debug||REG_DWORD||If this policy value exists and is set to “1”, the installer writes common debugging messages to the debugger using the OutputDebugString function. If this value exists and is set to “2”, the installer writes all valid debugging messages to the debugger using the OutputDebugString function. This policy is for debugging purposes only and may not be supported in future versions of Windows Installer.|
|DisableAutomaticApplicationShutdown||REG_DWORD||If this policy value exists and is set to “1”, Windows Installer does not interact with Restart Manager but will use the FilesInUse Dialog functionality. This policy is available beginning with Windows Installer version 4.0.|
|DisableBrowse||REG_DWORD||If this policy value exists and is set to “1”, users are prevented from browsing to locate installer sources. The Use feature from combo box for direct input is locked and the Browse button is disabled.|
|DisableFlyWeightPatching||REG_DWORD||If this per-machine system policy value is set to “1”, all Patch Optimization options are turned off during the installation. This policy is available beginning with Windows installer version 3.0.|
|DisableLUAPatching||REG_DWORD||If this per-machine system policy value is set to “1”, the installer prevents non-administrators from using least-privileged account (LUA) patching to any application installed on the computer. When this value is not set or “0”, non-administrators can apply LUA patches to LUA-enabled application.|
|DisableMSI||REG_DWORD||If this policy value is set to “Null”, “absent”, or any number other than “1” or “2”, the effect on the Windows Installer depends on the operating system. On Windows Server 2003, or when using Windows Installer 3.0 with Windows 2000 Server, Windows Installer is enabled for managed applications and disabled for unmanaged application installs. On Windows XP, Windows 98, or Windows 95, the Windows Installer is enabled for all applications. If this policy value is set to “0”, Windows Installer is enabled for all applications. All install operations are allowed. If this policy value is set to “1”, Windows Installer is disabled for unmanaged applications but is still enabled for managed applications. Non-elevated per-user installations are blocked. Per-user elevated and per-machine installs are allowed. If this policy value is set to “2”, Windows Installer is always disabled for all applications. No installs are allowed including repairs, reinstalls, or on-demand installations.|
|DisablePatch||REG_DWORD||If this policy value is set to “1” the installer does not apply patches. This policy can be used to provide security in environments where patching must be restricted.|
|DisablePatchUninstall||REG_DWORD||If this policy value is set to “1”, patches cannot be removed from the computer by a user or an administrator. The Windows Installer can still remove patches that are no longer applicable to a product. This policy is available beginning with Windows installer version 3.0.|
|DisableRollback||REG_DWORD||If this policy value is set to “1”, the installer does not store rollback files during installation, disabling installation rollback. By default, rollback is enabled. Administrators are advised not to use this policy unless it is absolutely essential. This policy is not available with Windows Installer version 1.0.|
|DisableUserInstalls||REG_DWORD||If this policy value is not set, the installer searches the registry for products in the following order: managed products that are registered as per-user, unmanaged products that are registered as per-user, and finally products that are registered as per-machine. If this policy value is set to “1”, the installer ignores all products that are registered as per-user and only searches for products that are registered as per-machine. An attempt to perform a per-user installation causes the installer to display an error message and stops the installation. This policy is available with Windows Installer version 2.0 and later versions.|
|EnforceUpgradeComponentRules||REG_DWORD||Set this policy value to “1” to apply upgrade component rules during small updates and minor upgrades of all products on the computer. This policy is available beginning with Windows Installer version 3.0.|
|EnableAdminTSRemote||REG_DWORD||Setting this policy enables administrators to perform installations from Terminal Server client sessions. This policy is not available with Windows Installer version 1.0. This policy is only available with Windows 2000 or later.|
|EnableUserControl||REG_DWORD||If this policy value is set to “1”, then the installer can pass all public properties to the server side during a managed installation using elevated privileges. Setting this policy has the same effect as setting the EnableUserControl property.|
|LimitSystemRestoreCheckpointing||REG_DWORD||This policy turns off the creation of checkpoints by Windows Installer. If the policy value is set to “0” or “absent”, Windows Installer does normal check pointing for install or uninstall. If the policy value is set to “1”, Windows Installer creates no checkpoints. This policy value is available with Windows Installer version 2.0 and later.|
|Logging||REG_SZ||This policy value is used only if logging has not been enabled by the “/L” command-line option or MsiEnableLog. If a policy is set in this case, a log file is created in the temp directory with the random name: MSI*.LOG. Specify the logging mode by setting the policy value to a string of characters. Use the same characters to specify logging mode policy as used by the ‘/L’ command-line option. Note that you cannot use “+” and “*” for the policy.|
|MaxPatchCacheSize||REG_DWORD||If this policy value is set to a value greater than “0”, Windows Installer saves old versions of patched files in a cache. Set the value to the maximum percentage of disk space that can be used for the file cache. For example, a value of “15” and sets the maximum to 15%. Set to “0” to save no files. When this policy is not set, the default is 10%.|
|SafeForScripting||REG_DWORD||If this policy value is set to “1”, users are not prompted when scripts use installer automation within a Web page. This may be useful for Web-based tools but can allow silent installations of applications without user knowledge or consent.|
|TransformsSecure policy||REG_DWORD||Setting the TransformsSecure policy value to “1” informs the installer that transforms are to be cached locally on the user’s computer in a location where the user does not have write access. This policy is not available with Windows Installer version 1.0.|
|DisableLoggingFromPackage||REG_DWORD||Set this policy value to “1” to disable the logging specified for the package by the MsiLogging property for all users of the computer. This policy is available starting with Windows Installer version 4.0.|
What is a System Reboot?
The Windows Installer can determine when a reboot of the system is necessary and automatically prompt the user to reboot at the end of the installation. For example, the installer automatically prompts for a reboot if it needs to replace any files that are in use during the installation. Installation package authors can schedule and suppress reboots by using standard actions in the sequence tables and by setting properties. The following actions and properties are used to handle system reboots.
|Action, dialog box, or property||Brief description|
|ForceReboot Action||Prompts the user for a reboot during the installation.|
|ScheduleReboot Action||Prompts the user for a reboot at the end of the installation.|
|REBOOT Property||Forces or suppresses certain automatic prompts for a system reboot.|
|REBOOTPROMPT Property||Suppresses the display of prompts for reboots to the user. Any needed reboots happen automatically.|
|AFTERREBOOT Property||Commonly used in a condition imposed on the ForceReboot Action.|
|InstallValidate Action||Displays the FilesInUse Dialog, if necessary, giving users the opportunity to shut down processes and avoid some system reboots.|
|FilesInUse Dialog||Gives users the opportunity to shut down processes to avoid some system reboots.|
|MsiRMFilesInUse Dialog||Gives users the option to use the Restart Manager to close and restart applications. Available beginning with Windows Installer version 4.0 on Windows Vista.|
|ReplacedInUseFiles Property||Set if the installer installs over a file in use. This property is used by custom actions to detect that a reboot is required.|
|MSIRESTARTMANAGERCONTROL||Property to disable Windows Installer interaction with the Restart Manager. Available beginning with Windows Installer version 4.0 on Windows Vista|
|MSIDISABLERMRESTART||Specifies how the Restart Manager closes and restarts applications. Available beginning with Windows Installer version 4.0 on Windows Vista|
|MSIRMSHUTDOWN||Specifies how the Restart Manager closes and restarts applications. Available beginning with Windows Installer version 4.0 on Windows Vista|
|MsiSystemRebootPending||Installer sets this property if a restart of the operating system is pending. Available beginning with Windows Installer version 4.0 on Windows Vista|
|DisableAutomaticApplicationShutdown||Policy to disable Windows Installer interaction with Restart Manager. Available beginning with Windows Installer version 4.0 on Windows Vista|
How does a System Reboot work?
The installer can determine when a reboot of the system is necessary and prompt the user with a request to reboot. Commonly, a system reboot is required because the installer is attempting to install a file that is currently being used. If the InstallValidate action detects the installation of a file in use it displays the FilesInUse Dialog. A FilesInUse dialog box alerts the user of processes currently running files that must be overwritten or deleted by the installation. This gives the user the opportunity to shut down these processes and avoid having to reboot the computer to complete the replacement or deletion of these files. If you expect the installer to display a FilesInUseDialog, but it does not, this may be due to one of the following reasons:
The files in use are not executables.
The installer is not actually trying to install those files.
The process holding those files is the process invoking the installation.
The process holding those files is one that does not have a window with a title associated with it.
What is System Restore?
System Restore monitors system changes and saves the system state as a restore point. If a system problem develops as a result of a system change, the user can return the system to a previous state using the data from a restore point. Applications and the system can create restore points when system changes occur. System Restore also creates checkpoints every 24 hours of absolute time. It can also be configured to create restore points at regular intervals. In addition, users can create restore points at any time. System Restore does not restore user data or documents, so it will not cause users to lose their files, e-mail, browsing history, or favorites. System Restore is also made available to users in safe mode, making it easier for them to restore their computers to a state before problems occurred.
How does System Restore work?
System Restore monitors a core set of system and application files, archiving the states of these files before system changes are made. System Restore also saves a full snapshot of the registry and some dynamic system files. When System Restore detects that the user is not actively using the computer, it compresses the registry and any file copies made. System Restore requires a minimum of 200 MB of free disk space on the system drive at installation. When the amount of free disk space falls below 50 MB on any drive, System Restore switches to standby mode and stops creating restore points. All restore points are deleted at that time. System Restore reactivates and resumes creating restore points as soon as 200 MB of disk space is free on the system drive. The files that are monitored or excluded from monitoring are specified in the file %windir%\system32\restore\Filelist.xml. As the computer is used over time, restore points are collected in the data archive without any management or intervention required by the user. If the user ever needs to restore the system to a previous state, the available restore points are made visible to the user through the System Restore user interface. The user can choose any of these restore points. The only way to access this archive of restore points is through the System Restore user interface and the System Restore API; this is to protect data integrity and prevent accidental changes made by the user, applications, or other agents. To restore a system, System Restore undoes file changes made to monitored files, recapturing the file state at the time of the selected restore point. It then replaces the current registry with the one saved for the selected restore point.
Restore points are created to allow users a choice of previous system states. Each restore point contains the necessary information needed to restore the system to the chosen state. Restore points are created before key changes are made to the system. System Restore has an automatic restore point space-management feature that purges the oldest restore points to make room for new ones, while still enabling the user to recover from any recent destructive changes. System Restore takes a maximum of 12 percent of the disk space in systems with hard drives over 4 gigabytes (GB), and a maximum of 400 megabytes (MB) for hard drives under 4 GB. To reduce the maximum storage limit, use the System application in the Control Panel. System Restore provides users with the ability to restore the system to its state on a specific days. It does this by creating a restore point every 24 hours. These restore points are saved and compressed, and these choices are available to the user through the System Restore user interface. Users can also manually create and name a restore point at any time from within the System Restore user interface.
Windows File Protection (WFP)
What is Windows File Protection?
Windows File Protection (WFP) is a hidden service which prevents programs from replacing critical Windows system files. Programs must not overwrite these files because they are used by the operating system and by other programs. Protecting these files prevents problems with programs and the operating system. WFP protects critical system files that are installed as part of Windows (for example, files with a .DLL, .EXE, .OCX and .SYS extension and some True Type fonts). WFP uses the file signatures and catalog files that are generated by code signing to verify if protected system files are the correct Microsoft versions.
If a program uses a different method to replace protected files, WFP restores the original files. The Windows Installer adheres to WFP when installing critical system files and calls WFP with a request to install or replace the protected file instead of trying to install or replace a protected file itself. A copy of all such files is maintained in C:\windows\system32\dllcache.
How does WFP Work?
The WFP works according to the following steps
When the InstallFiles actionor any other action scheduled before InstallFiles attempts to install a file protected on Windows 2000, the installer calls WFP with a request to install or replace the protected file.
The installer requests the file installation from WFP immediately after executing the InstallFiles action.
WFP installs or replaces the file on the user’s system with a cached version of the protected file. This does not guarantee that the version of the file installed form the cache is the version required by the application.
After WFP has installed the file, the installer determines whether this version matches the version in the package. If the file version in the package is greater than the installed version, the installer informs the user that it cannot upgrade the system and that an update of the operating system may be required for the application.
If any action sequenced after InstallFiles attempts to install or replace a protected file not already installed on the system, the installer cannot call the WFP to install the file. In this case the installer informs the user that it cannot update and that an update of the operating system may be required for the application.
The installer also checks with WFP when removing files and never attempts to remove protected system files.
The Installer has no mechanism for by-passing WFP and if your package attempts to replace a protected file, the installation may not give the expected result. For the sake of application compatibility, the install does not fail if it is unable to update a WFP file. Instead, an entry is written to the application event log. However, it is important to note that the application may not be using the intended version of the file.
Do not be tempted to work around this by using a custom action or other means. WFP will roll-back any changes you make. In any case, even if you managed to force your changes onto the system replacing protected files is simply unsupported by any means except Microsoft-approved methods.
User Account Control (UAC)
What is User Account Control?
With User Account Control enabled, interactive administrators normally run with least user privileges, but they can self-elevate to perform administrative tasks by giving explicit consent with the Consent UI. Such administrative tasks include installing software and drivers, changing system-wide settings, viewing or changing other user accounts, and running administrative tools. In their least-privileged state, administrators are referred to as protected administrators. In their elevated state, they are referred to as Elevated administrators. In contrast, Standard users can’t elevate by themselves, but they can ask an administrator to elevate them using the Credential UI. The Built-in Administrator account doesn’t require elevation.
Why should we use UAC?
User Account Control provides the following benefits:
It reduces the requirement of explicit consent to run with administrative privileges.
For managed environments, it allows users to be more productive when running as Standard users by removing unnecessary restrictions.
For home environments, it gives users better control over system-wide changes, including what software is installed.
It gives Standard users the ability to ask administrators to give them permission to perform administrative tasks within their current session.
User Interface Levels
Windows Installer provides package developers the capability to author an internal user interface that has multiple levels of functionality. Because the internal UI must be created by the author of the package, the behavior of the full UI, reduced UI, basic UI, and None levels depends on the installation package. The following table describes the functionality commonly ascribed to UI levels.
|Full UI||Displays modal and modeless dialog boxes that have been authored into the internal UI. Displays authored Error Dialog boxes. A full UI commonly exhibits User Interface Wizard Behavior.|
|Reduced UI||Displays any modeless dialog boxes that have been authored into the UI. Does not display any authored modal dialog boxes. Displays authored Error Dialog boxes. Displays Disk Prompt messages. Displays FilesInUse Dialog boxes.|
|Basic UI||Displays the built-in modeless dialog boxes that show progress messages. Displays built-in error dialog boxes. Does not display any authored dialog boxes. Prompts users to insert a disk by displaying a dialog box containing the DiskPrompt property value.|
|None||None means a silent installation that displays no UI.|