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.

Source Resiliency

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.

System Policies

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: –

User Policies

Machine Policies

User Policies

The following user policies can be configured under

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer

Machine Policies

The following machine policies can be configured under:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

System Reboots

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.

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.

System Restore

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

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.

Application Packaging Demo Video For Your Preview