More specifically, the Installer service spawns a new msiexec.exe process under the user's security context to handle the portion of the installation that's installed to the user's profile. The Installer service uses its own elevated security context (i.e., the LocalSystem account) to process the part of the machine-specific installation to which the user doesn't have rights. Applications deployed in this way are called managed applications. The privilege escalation that Windows Installer uses for managed applications is generally available only in Group Policy-based deployments, although you can also enable it outside of Group Policy Object (GPO)-based deployment through an Administrative Template policy.
The mutually dependent relationship between Group Policy and the Windows Installer service also includes the ability to perform advertisements. When you assign an application to a user in Group Policy, you in effect perform an advertised installation, as I mentioned earlier. Thus, the Windows Installer engine doesn't process an .msi file per se but rather an application advertisement script (.aas file). The .aas file is created when you use Group Policy to deploy the application. To create the .aas file, Group Policy Editor (GPE) actually calls a function exported by msi.dll (a core DLL that msiexec.exe uses) that generates a unique advertisement script within the GPO. Thus, when the Windows Installer engine processes the advertisement script, it knows where the associated .msi file is and what portions of the application to advertise. In other words, GPO-based software installation is tightly tied to the Windows Installer service, and vice versa.
Storing Installer Files on a Workstation
Let's look at what happens on a workstation when the Windows Installer service installs an .msi package. First, to facilitate rollback of a failed installation, Installer backs up any files it replaces to a temporary location on the user's hard disk—usually C:\config.msi. If you visit that folder while an installation is in progress, you'll see some oddly named temporary files that the Installer service creates. The Installer service deletes the temporary files after the installation is complete.
After finishing an installation, Windows Installer stores a copy of the installation's associated .msi file and any transforms that Windows Installer used to install the application in \%windir%\installer, assigning the files unique code names (e.g., 19fe9b79.msi). The files in \%windir%\installer are essentially cached copies of all the .msi files that Windows Installer has installed on the computer. Having the cached versions available lets a user change or remove an application without accessing the original installation source package, which might be on a server share that a roaming user can't access. Windows keeps track of all installed .msi-based applications; the installed features, components, and patches; and the file name of the cached .msi file (among other things) in the registry.
To determine which cryptically named .msi file corresponds to an application on your workstation, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData. The keys under this location are organized by username SID, with the LocalSystem account, S-1-5-18, shown first and typically listing all applications that have been installed per machine. Per-user installations are listed under the corresponding user's SID.
Launching Installer Files at the Command Line and in Scripts
Two additional ways to launch Windows Installer packaged installations are from the command line or in a script. At the command line, you can execute msiexec.exe to perform various installation tasks. (You can find the complete list of command-line options for msiexec.exe in the Microsoft article "Command-Line Switches for the Microsoft Windows Installer Tool," at http://support.microsoft.com/?kbid=227091.) For example, you can use the command-line method to install one feature in an application package, such as the DNS console tools in the Windows 2003 Administration Tools (adminpak.msi). Use Orca to find the correct feature name—in this case, FeDNSConsole—then, at the command line execute msiexec.exe to perform the installation, as follows:
msiexec /I adminpak.msi ADDLOCAL=FeDNSConsole
This command uses the ADDLOCAL property to tell the Windows Installer service which of the package's features the service should install. The command-line method is a faster alternative to users choosing which features to install or to administrators using a transform file to install certain features.
The Windows Installer SDK includes examples of how you can use Windows Script Host (WSH) scripts to interact with Windows Installer and .msi packages. The WindowsInstaller.Installer object provides methods and properties that you can use in scripts to perform actions such as listing all .msi-based packages installed on a system, adding a .cab file to an .msi database, applying a transform to an installation, and comparing two .msi database files. For more information about Windows Installer scripting objects, see the sample scripts in the Installer SDK directory in the folder Samples\sysmgmt\msi\Scripts or at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/using_the_automation_interface.asp.
Go Forth and Install
As you've seen, Windows Installer means much more than just clicking an .msi file. The powerful Windows Installer technology lets you install applications in a robust and resilient way, but to get the most from it, you must understand how it works. Use the information in this article to explore Windows Installer and optimize your application-packaging solutions.
End of Article
Prev. page
1
2
[3]
next page -->
