SQL Server Magazine

Last year, I wrote about the application-deployment (or software-installation) features of Windows 2000 (Win2K) in "Application Management in NT 5.0," April 1998. Software installation is a function of Active Directory (AD)-based group policies that lets you publish or assign applications to users within your AD domains. The engine behind software installation is the Windows installer service. The Windows installer (formerly Microsoft Installer—MSI) is a set of APIs, tools, and services that let you describe, install, and maintain applications within your Windows environment. In this article, I describe how the Windows installer works, how you can take advantage of the installer, and when you can use this service—it might be sooner than you think.

The Problem
In any Windows infrastructure with more than several hundred workstations, one of the big problems that administrators face is application deployment and configuration management. Windows applications are difficult to package, deploy, and maintain. Throw in the fact that you might have to deploy and maintain applications across hundreds or thousands of remote sites, and you begin to understand the clamor about thin clients and serverside application development. Therefore, a standard way to describe an application, such as binary files (executables, DLLs, OLE custom controls—OCXs), Registry entries, and user settings, is necessary. Also, applications need to recognize and respect shared components. For example, suppose I have two applications: one I've written inhouse and one I've purchased. I don't want to deal with application conflicts that exist because the vendor decided to include a newer version of a Visual Basic (VB) OCX than the version I use internally. I do want to install the standard application description to my workstation in one procedure (without user intervention) and be able to roll the application back if the installation fails. I want the ability to update or remove the application later without a lot of pain, and I want intelligent applications that fix missing or corrupted file components.

Inside the Installer
The installer technology includes the installer engine, which runs on the workstation or server, and APIs that expose information about an application's state (i.e., whether it's installed or uninstalled). The installer engine and APIs install, upgrade, and remove applications. Microsoft sometimes uses the names Windows installer and MSI interchangeably; however, MSI describes only the installer files' packaging format (i.e., an .msi application file).

Microsoft has placed the installer technology—specifically, AD's use of the installer technology within group policies—among Win2K's IntelliMirror features. The goal of IntelliMirror is to intelligently mirror, or reproduce, the user experience to any location. The user experience includes the user's data, environment, desktop preferences (i.e., user profile), and applications. To reproduce the user experience regardless of a user's network connections or computer, Microsoft came up with an efficient way to manage application installations and deliver them to the user. First, Microsoft developed a standard for writing clean applications. A clean application refers to an application that correctly places Registry entries, doesn't overwrite shared DLLs, doesn't put binaries and DLLs in some odd directory (i.e., other than the Program Files folder), and lets a user roam to other computers after application installation.

Second, to facilitate reproducing the user experience, Microsoft uses AD to deliver the clean applications securely to a user or computer via group policy. When you publish or assign an application with AD, the directory doesn't store the application binary files and Registry changes but rather references to the installation package. At each workstation, the installer engine interacts with the published or assigned application packages to install the packages in just-in-time (JIT) fashion. The engine runs as a regular Windows NT service. Running in service mode, the engine takes care of security context problems. For example, most applications require you to modify HKEY_LOCAL_MACHINE Registry keys with security restrictions to exclude nonadministrative users. In addition, an application might require a user to log on before the application can make profile changes (i.e., HKEY_CURRENT_USER). The installer engine, which ordinarily runs as a service using the Local System service account, handles these dual security context requirements. An active user's NT Explorer shell invokes the installer engine, which performs both user- and computer-specific installations that the MSI package defines.

Let's use an example of a Windows 2000 Professional (Win2K Pro) installation to examine the installer engine's dual-security role in distributing applications to either a user or computer via group policy. Suppose I edit a Group Policy Object (GPO) to assign in AD a Microsoft Word MSI package that gets applied to user Jsmith. (For more information about the AD's GPOs, see "Application Management in NT 5.0," April 1998.) The next time Jsmith logs on to the Win2K Pro machine, he'll see a Word shortcut on the Start menu, because the installer engine has placed an icon that points to the MSI package for Word (not the full application) on Jsmith's desktop. The Word MSI package, which can reside on a network server, contains the local machine (e.g., binary files in the Program Files directory and Registry changes to HKEY_LOCAL_MACHINE) and user profile changes.

When Jsmith executes Word, the Explorer shell sees that the application isn't installed and goes to the AD to get more information. The AD points the shell at the MSI package for Word on the server. The installer service reads the MSI package and performs the installation process that requires the elevated security privileges. The installer copies the necessary binary files and Registry settings to the local machine. (The installer can copy files and settings because it runs under the Local System service account.) Because Jsmith initiated the installation after logging on, a separate client portion of the installer engine makes changes to the user profile. Figure 1 illustrates the process of installing Word 2000 on a user machine.

   Prev. page   [1] 2 3     next page