1. Windows Installer Registry Key
2. Open Source Registry Repair Software

Registry keys for configuring Automatic Updates & WSUS. Registry keys for Windows Updates. 3 = Automatically download and notify of installation.

Windows Installer (previously known as Microsoft Installer,^[3]codenameDarwin)^[4][5] is a software component and application programming interface (API) of Microsoft Windows used for the installation, maintenance, and removal of software. The installation information, and optionally the files themselves, are packaged in installation packages, loosely relational databases structured as COM Structured Storages and commonly known as 'MSI files', from their default filename extensions. Windows Installer contains significant changes from its predecessor, Setup API. New features include a GUIframework and automatic generation of the uninstallation sequence. Windows Installer is positioned as an alternative to stand-alone executable installer frameworks such as older versions of InstallShield and NSIS.

Windows Installer Registry Key

Before the introduction of Windows Store, Microsoft encouraged third parties to use Windows Installer as the basis for installation frameworks, so that they synchronize correctly with other installers and keep the internal database of installed products consistent. Important features such as rollback and versioning depend on a consistent internal database for reliable operation. Furthermore, Windows Installer facilitates the principle of least privilege by performing software installations by proxy for unprivileged users.

• 1Logical structure of packages
• 2Setup phases
• 3Other features
• 4Developing installer packages

Logical structure of packages[edit]

A package describes the installation of one or more full products and is universally identified by a GUID. A product is made up of components, grouped into features. Windows Installer does not handle dependencies between products.

Products[edit]

A single, installed, working program (or set of programs) is a product. A product is identified by a unique GUID (the ProductCode property) providing an authoritative identity throughout the world. The GUID, in combination with the version number (ProductVersion property), allows for release management of the product's files and registry keys.

A package includes the package logic and other metadata that relates to how the package executes when running. For example, changing an EXE file in the product may require the ProductCode or ProductVersion to be changed for the release management. However, merely changing or adding a launch condition (with the product remaining exactly the same as the previous version) would still require the PackageCode to change for release management of the MSI file itself.

Features[edit]

A feature is a hierarchical group of components. A feature may contain any number of components and other sub-features. Smaller packages can consist of a single feature. More complex installers may display a 'custom setup' dialog box, from which the user can select which features to install or remove.

The package author defines the product features. A word processor, for example, might place the program's core file into one feature, and the program's help files, optional spelling checker and stationery modules into additional features.

Components[edit]

A component is the basic unit of a product. Each component is treated by Windows Installer as a unit. The installer cannot install just part of a component.^[6] Components can contain program files, folders, COM components, registry keys, and shortcuts. The user does not directly interact with components.

Components are identified globally by GUIDs; thus the same component can be shared among several features of the same package or multiple packages, ideally through the use of Merge Modules.

Key paths[edit]

A key path is a specific file, registry key, or ODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the term key file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination folder is taken to be the key path. When an MSI-based program is launched, Windows Installer checks the existence of key paths. If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), the related feature is re-installed. This process is known as self-healing or self-repair. No two components should use the same key path.

Setup phases[edit]

User interface[edit]

The user interface phase typically queries the target system, displays an installation wizard and enables the user to change various options that will affect the installation.

However, the user interface sequence should not make any changes to the system, for the following reasons:

1. A user may install or uninstall an MSI package in passive mode or silent mode, bypassing this phase entirely. (Passive mode bypasses the user interface phase but shows a graphical progress bar. Silent mode shows nothing.) During installation, information gathered in this phase may be supplied beforehand through the command-line interface.
2. The user interface sequence runs with user privileges, and not with the elevated privileges required during installation.

Execute[edit]

Open Source Registry Repair Software

When the user clicks the 'Install' button in a typical MSI installation wizard, installation proceeds to the Execute phase, in which software components are actually installed. The Execute phase makes system changes, but it does not display any user interface elements.

The Execute phase happens in two steps:^{[clarification needed Two mode or two steps? Do both run?]}

• Immediate mode. In this phase, Windows Installer receives instructions, either from a user or an application, to install or uninstall features of a product. The requests cause the execution of sequences of actions, which query the installation database to build an internal script describing the execution phase in detail.
• Deferred mode. In this phase, the script built in immediate mode is executed in the context of the privileged Windows Installer service. The script must be executed by a privileged account because of the heterogeneity of the scenarios in which a setup operation is initiated. For example, elevated privileges are necessary to serve on-demand installation requests from non-privileged users. (To run with elevated privileges, however, the package must be deployed by a local administrator or advertised by a system administrator using Group Policy.)

Rollback[edit]

All installation operations are transactional.^[7] In other words, for each operation that Windows Installer performs, it generates an equivalent undo operation that would revert the change made to the system. In case any script action fails during deferred execution, or the operation is cancelled by the user, all the actions performed until that point are rolled back, restoring the system to its original state. Standard Windows Installer actions automatically write information into a rollback script; package authors who create custom actions that change the target system should also create corresponding rollback actions (as well as uninstall actions and uninstallation-rollback actions). As a design feature, if applied correctly this mechanism will also roll back a failed uninstall of an application to a good working state.

Other features[edit]

Advertisement[edit]

Windows Installer can advertise a product rather than actually install it.^[8] The product will appear installed to the user, but it will not actually be installed until it is run for the first time by triggering an entry point (by means of a Start menu shortcut, by opening a document that the product is configured to handle, or by invoking an advertised COM class). A package can be advertised by an administrator using Group Policy or other deployment mechanism, or by running the msiexec executable with the /jm (for per-machine advertisement) or /ju (for per-user advertisement) switch. Some MSI packages authored in InstallShield may prevent the use of these and other native MSI features.

The user must have administrator privileges to complete the advertised installation.

Installation on demand[edit]

Similar to advertising, it installs a feature as soon as the user tries to use it.^[9]

Administrative installation[edit]

An administrative installation creates an uncompressed source image for a product, typically to be used for installing or running an application from a network location.^[10] An administrative installation is not a typical installation, in that it does not create any shortcuts, register COM servers, create an Add or Remove Programs entry, and so on. Often an administrative installation enables a user to install the product in such a way that its features run from the uncompressed installation source.

Administrative installations are also useful when creating a Windows Installer patch, as this requires uncompressed images of the earlier and current versions of a product in order to compute binary file differences. An administrative installation is performed by running the msiexec executable with the /a switch.

Custom actions[edit]

The developer of an installer package may write code to serve their own purpose, delivered as a DLL, EXE, VBScript or JavaScript. This can be executed during the installation sequences, including when the user clicks a button in the user interface, or during the InstallExecuteSequence. Custom Actions typically validate product license keys, or initialize more complex services. Developers should normally provide inverse custom actions for use during uninstall. Norwegian wood ebook ita download.

Msiexec provides a way to break after loading a specified custom action DLL but before invoking the action.^[11]

Merge modules and nested executables[edit]

A Windows Installer package may contain another package to be installed at the same time. These are ideally provided as a .msm file component, but may also be a separate executable program which will be unpacked from the installer package during the InstallExecuteSequence and can be run immediately. The file can then optionally be deleted before the end of the InstallExecuteSequence, and so is ideal for using with older installers. .msm file component is called Microsoft Merge Module and is utilized to single out and integrate common components. It contains images of all tables, which have relevant information regarding the common components. Ready-made merge modules are supplied with Visual Studio or can be downloaded from the alternative sources.^[12]

Interoperability with Windows features[edit]

Windows Installer 4.0, which was shipped with Windows Vista, incorporates capabilities to take advantage of the User Account Control feature. If an application can install without elevated privileges, its MSI package can be marked as such, thus allowing install without prompting the user for Administrator credentials. Windows Installer also works in conjunction with the Restart Manager; when installing or updating an application or system component with 'full' user interface mode, the user will be displayed a list of affected applications that can be shut down, and then restarted after files have been updated. Installer actions running in silent mode perform these application restarts automatically. System services and tray applications can also be restarted in this manner.

Developing installer packages[edit]

Creating an installer package for a new application is not trivial. It is necessary to specify which files must be installed, to where and with what registry keys. Any non-standard operations can be done using Custom Actions, which are typically developed in DLLs. There are a number of commercial and freeware products to assist in creating MSI packages, including Visual Studio (up to VS 2010^[13]), InstallShield and WiX. To varying degrees, the user interface and behavior may be configured for use in less common situations such as unattended installation. Once prepared, an installer package is 'compiled' by reading the instructions and files from the developer's local machine, and creating the .msi file.

The user interface (dialog boxes) presented at the start of installation can be changed or configured by the setup engineer developing a new installer. There is a limited language of buttons, text fields and labels which can be arranged in a sequence of dialogue boxes. An installer package should be capable of running without any UI, for what is called 'unattended installation'.

ICE validation[edit]

Microsoft provides a set of Internal Consistency Evaluators (ICE) that can be used to detect potential problems with an MSI database.^[14] The ICE rules are combined into CUB files, which are stripped-down MSI files containing custom actions that test the target MSI database's contents for validation warnings and errors. ICE validation can be performed with the Platform SDK tools Orca and msival2, or with validation tools that ship with the various authoring environments.

For example, some of the ICE rules are:

• ICE09: Validates that any component destined for the System folder is marked as being permanent.
• ICE24: Validates that the product code, product version, and product language have appropriate formats.
• ICE33: Validates that the Registry table is not used for data better suited for another table (Class, Extension, Verb, and so on).

Addressing ICE validation warnings and errors is an important step in the release process.

Versions[edit]

In October 2018, Microsoft released MSIX Packaging Tool as the successor to MSI.

Tools[edit]

See also[edit]

• ZAP File – a way to perform an Application Installation when no MSI File exists.

References[edit]

1. ^ ^ab'Released Versions of Windows Installer'. Microsoft Developer Network. Microsoft. Retrieved 3 November 2012.
2. ^'File Extension .MSI Details'. Filext.com. Retrieved 2013-04-24.
3. ^Mensching, Rob (2003-11-25). 'Inside the MSI file format'. MSDN Blogs. Archived from the original on 2009-01-15. Retrieved 2017-02-15.
4. ^Mensching, Rob (2003-10-11). 'The story of Orca'. MSDN Blogs. Archived from the original on 2008-12-23. Retrieved 2017-02-15.
5. ^Smith, Chris (2005-07-01). 'Windows Installer, The .NET Framework, The Bootstrapper, and You'. MSDN Blogs. Retrieved 2017-02-15.
6. ^'Windows Installer Components'. MSDN Library. Microsoft Corporation. 2012-11-30. Retrieved 2013-04-08.
7. ^Rollback Installation
8. ^Advertisement
9. ^Installation-On-Demand
10. ^Administrative Installation
11. ^'Debugging Custom Actions (Windows)'. Msdn.microsoft.com. 2012-11-30. Retrieved 2013-04-24.
12. ^'Types of Packages: Non-Virtual Packages – Microsoft Windows Installer (MSI)'. itninja.com. 2016-12-28. Retrieved 2017-06-15.
13. ^ ^abBuck Hodges (2011-03-17). 'Visual Studio setup projects (vdproj) will not ship with future versions of VS'. MSDN Blogs.
14. ^Internal Consistency Evaluators – ICEs
15. ^'Applying Full-File Updates to Client Computers'. Microsoft. March 9, 2004. Archived from the original on April 10, 2004.
16. ^What's New in Windows Installer 4.5
17. ^'Released Versions of Windows Installer (Windows)'. Msdn.microsoft.com. 2012-11-30. Retrieved 2013-04-24.
18. ^'Windows Installer Tools & Tips'. InstallSite Stefan Krueger. Retrieved 19 November 2009.
19. ^'Windows Installer Deployment'. Microsoft Developers Network (MSDN) Library. Microsoft Corporation. August 2008. Retrieved 1 October 2009. Windows Installer deployment enables you to create installer packages to be distributed to users; the user runs the setup file and steps through a wizard to install the application.
20. ^'SharpDevelop Features'. IC#Code. Retrieved 31 March 2012.

External links[edit]

• 'Windows Installer'. Microsoft Dev Center.
• InstallSite.org 'Resources for Setup Developers'

Applies To: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2

When you install an application using Windows Installer, those Windows Installer applications try to return to the path they were installed from when they need to install new components, repair the application, or update the application. This location is called the Windows Installer source location. Windows Installer Source Location Manager can automatically search Configuration Manager 2007 distribution points for the source files, even if the application was not originally installed from a distribution point. To enable Windows Installer source location, you configure the Windows Installer tab on the program properties in Configuration Manager 2007 packages.

Important

The Windows Installer Source Location Manager was designed and tested for a maximum of 1000 Windows Installer programs. Configuring the Windows Installer tab increases the policy size for all clients. Configuring more than 1000 Windows Installer programs can degrade client performance.

Scenarios Addressed by Windows Installer Source Location Manager

Problem Scenario 1: A user installs Microsoft Office from a CD. The user chooses Minimal installation, yet no longer retains the original installation CD. On first use of the speech tools, Windows Installer prompts the user to insert the Microsoft Office CD so that it can find the speech tools files. The user does not know the location of the Microsoft Office files and is unable to complete the speech tools installation.

Problem Scenario 2: A user installs Microsoft Office from a CD. The Contoso Company uses Configuration Manager 2007 to manage its Office security updates. When Windows Installer attempts to apply the security update, it requests files from the original CD. The user might or might not know the location of the files, and the security update might not be applied.

Problem Scenario 3: A network share is used as the installation location for a Windows Installer product. Some time after computers have installed the product from that share, the computer hosting the share is decommissioned or fails and is no longer on the network. When Windows Installer attempts to reconnect to that server, it will fail and display a dialog box to the user prompting for the original source files.

Definitions

The following terms relate to Windows Installer source location management.

• Windows Installer
  Refers to the Windows Installer technology for bundling applications and providing a simplified and programmatic installation experience.

• MSI
  Acronym for Microsoft Installer. Equivalent in meaning to Windows Installer.

• Product code
  A unique identifier assigned to each Windows Installer bundled application.

• Package code
  A unique identifier assigned to each Windows Installer bundled application that typically indicates minor revisions have occurred from the original Windows Installer bundled application (such as the application of a language-specific transform).

• .MSI file
  A reference to the file name extension associated with a Windows Installer bundled application.

• Product Source Update Manager
  An agent running on the Configuration Manager 2007 client that updates the list of network locations where Windows Installer can find source files.

Windows Installer Interactions

There are some specific interactions between Configuration Manager 2007 and Windows Installer that should be considered when using the Windows Installer source location management.

Managing Products that Have Identical Product Codes

Most Windows Installer-based products use different product codes for each version of the application. In some cases, Windows Installer application bundles might have identical product codes, yet differentiate versions by establishing a different package code. One example of this is Microsoft Visio 2002. In this example, the product code for the original release of Visio 2002 Professional ENU version is {90510409-6D54-11D4-BEE3-00C04F990354}. The SR1 version product code is also {90510409-6D54-11D4-BEE3-00C04F990354}. If the administrator has two Configuration Manager 2007 packages configured for Windows Installer source location management where one contains the original release version and the other contains the SR1 version, Product Source Update Manager will update the source location list on the clients with the entire list of distribution points for both products (because they have the same product code). Windows Installer will then match up the appropriate release when it attempts to find its specific files.

If you have products that have identical product codes for different versions, you should use Configuration Manager 2007 to update all the older version applications before adding the Windows Installer product code to the package for Windows Installer source location management.

Registry Values for Source Lists

Windows Installer maintains the list of source directories as part of its database. The information is then exposed in the registry. The specific registry hive and key that contains the source list varies depending on the type of installation (managed or unmanaged) and the associated privileges during installation (elevated or non-elevated). You will find the majority of the source lists in the following locations:

HKEY_CLASSES_ROOTInstallerProducts<product code>SourceListNet

HKEY_CURRENT_USERSoftwareMicrosoftInstallerProducts<product code>SourceListNet

Install Applications for All Users

If you plan to configure the Configuration Manager 2007 program to install a Windows Installer file in an administrative context by using the Run with administrative rights option, ensure that you use the Per-Machine Installation option as described in the Windows Installer documentation on MSDN http://go.microsoft.com/fwlink/?LinkId=103664. Otherwise, the application will run only for the Local System user. For example, if smstest.msi is a Windows Installer application, you might run it with the following command line:

msiexec /I smstest.msi ALLUSERS=2

Removing Existing Network Source Locations

Product Source Update Manager will find any distribution points for Configuration Manager 2007 programs that have Windows Installer information and will add the network source paths for those Windows Installer packages. When a source location is already stored (for example, if the program was installed from a locally available server instead of the Configuration Manager 2007 distribution point), Product Source Update Manager will append the Configuration Manager 2007 distribution point locations to the existing source location.

To fully understand this functionality and how source locations could be removed, consider the following scenario:

1. Microsoft Office XP is installed by user initiation (not by using Configuration Manager 2007) from server1share.

2. Windows Installer adds server1share to the last-used source registry key and stores server1share as the installation source.

3. The user initiates a repair of Office and Windows Installer to go to server1share to get the source files.

4. The Configuration Manager administrator now adds Office XP to Configuration Manager 2007 and adds the Windows Installer information for the PROPLUS.MSI file.

5. The client receives the update and appends smsserverdpshare to the list of sources for Office XP.

6. The network administrator decommissions server1. The server1share folder is no longer accessible to the client computer.

7. A security update is applied to Office XP; server1share is checked first and not found. Windows Installer rolls to the next location and smsserverdpshare is used to complete the update process; smsserverdpshare is now listed in the last-used source registry and becomes the official installation source.

8. Any subsequent security updates or repairs now start with a pointer to smsserverdpshare for Office XP.

Updating Windows Installer Source Location Manager

Several events can occur on the Configuration Manager 2007 client that will cause the Product Source Update Manager agent to update source locations for one or more Windows Installer products:

• Management Point Change Whenever a client’s resident or proxy management point changes, a full Windows Installer Source List Update Cycle will be run.

• Network Change If a client changes from one network subnet to another, a Windows Installer source list update cycle is triggered. If there are multiple network interfaces on the computer (for example, a docking station NIC and a wireless PC card), a Windows Installer source list update cycle will not be triggered if one of the subnets remains the same. Computers that use dial-up to connect to a corporate network will generate a network change, as well as computers that make a virtual private network (VPN) connection to another network. Whenever a client’s network subnet changes and remains in that subnet for more than eight hours, a full Windows Installer source list update cycle will be run.

• Control Panel Item Action The Configuration Manager Control Panel item has a Windows Installer Source List Update Cycle action. Selecting this action and clicking the Initiate Action button causes the Product Source Update Manager to complete a full update cycle.

• Running a Program with Associated Windows Installer Information If a program is installed on the client, and Windows Installer information is stored for that program (product code and file name), Product Source Update Manager will update the network locations after the program is installed. Whenever a single Windows Installer application is installed by using Configuration Manager 2007, a Windows Installer source list update cycle will be run for that one application only.

• Programmatic Trigger via API A Configuration Manager 2007 program can be run with a VBScript to enable a Windows Installer source list update cycle.

• User Logon/Logoff When a user logs on to the computer, Product Source Update Manager updates source paths for per-user installations of Windows Installer products for that logged-on user. When a user logs off, a flag is toggled indicating that only per-machine installations should be evaluated on any of the normal update cycle triggers.

See Also

Tasks

Concepts

For additional information, see Configuration Manager 2007 Information and Support.
To contact the documentation team, email SMSdocs@microsoft.com.