Software Installation in Windows 2000

Another step toward Change and Configuration Management

Today's Windows NT desktop is a nightmare to manage in a large—or even moderately sized—environment. If you're not dealing with issues of DLL conflicts, lack of registrations for globally unique IDs (GUIDs), or keeping software installed and updated in a way that doesn't require user intervention, you're trying to figure out how to build a different desktop for each user class. Microsoft's Systems Management Server (SMS) 2.0 begins to tackle management issues, but some key pieces are missing or are difficult to implement in a large environment.

This systems management problem is Microsoft's biggest challenge. Recognition of the problem, and the tremendous costs associated with solving the problem, resulted in the Zero Administration for Windows (ZAW) initiative. In Windows 2000 (Win2K), Microsoft attempts to take ZAW from theory to reality and has even renamed the set of technologies Change and Configuration Management (CCM)—a much more realistic goal than ZAW! For example, Win2K will provide services to enhance software installation and configuration. In this article, I show you how Microsoft plans to help you better manage your desktop applications and how that plan fits into the overall Win2K picture.

The Problem
If you have hundreds or thousands of workstations spanning the country or the world, physically visiting workstations to install applications isn't an option. Furthermore, if you need to manually (or even through a script) touch each workstation to update or fix those applications and report on the results of those operations in a useful way, the cost to maintain such an environment quickly spirals out of control.

The problem becomes more difficult when you consider how you install most Windows applications. Most applications contain binary application files (e.g., DLLs, EXEs, OLE custom controls—OCXs) that can or must reside on a server or in the local workstation's System directories, shared components that multiple applications use, workstation-specific Registry entries (e.g., HKEY_LOCAL_MACHINE), user-specific Registry entries (e.g., HKEY_CURRENT_USER), shared data, and user-specific data (e.g., Home directories).

In addition, many of these elements require administrative access to a workstation's file system or Registry to complete the install. Managing these elements across Microsoft's products is challenging, without considering third-party applications. In Win2K, Microsoft eases this administrative burden with several features that facilitate software installation, including Active Directory (AD), Group Policy Objects (GPOs), and the Windows Installer engine.

The Software Installation Pieces in Windows 2000
AD plays a key software installation role in Win2K. AD is the repository for information about applications that you want to make available to your users. You can use AD to define which groups of users can use which applications. Finally, AD is a class store for COM objects. In previous versions of NT, you needed to ensure that you had COM-related registrations on every machine that an application was installed on. But in Win2K, you can use AD to make class registrations available regardless of machine state or physical location. Through Group Policy's software installation features, the class store represents COM objects that you want to make available to a client application. In the event that an application calls one of these objects, its registration information from the class store installs on the local client. This feature is powerful and provides the foundation for true user portability. That is, users can go to any workstation in the domain and access directory-based application classes to quickly and easily download applications and application functionality that they're entitled to.

You use Group Policy to enable the software installation features in the directory. Group Policy is a Microsoft Management Console (MMC) snap-in that lets you publish or assign applications to AD for clients to use. You can use Group Policy's software installation features to update previously assigned or published applications and remove applications from further use. In addition, the Group Policy snap-in is a multifunction tool that lets you define logon and logoff scripts and administrative templates (which are similar to NT 4.0-style system policies).

The Windows installer is a set of technologies that Microsoft first introduced in Office 2000. The Windows installer lets you package applications in an intelligent, self-healing, component-oriented way. (For more information about the Windows installer service, see "Windows Installer Takes Control," June 1999.) The installer includes a set of APIs that independent software vendors (ISVs) can use to write installer-aware application setups—often called Microsoft Installer (MSI) packages because of their .msi extension. MSI packages address the thorny problem of separating user-specific pieces of an installation from machine-specific pieces. MSI packages work with the new Installer service that ships with Win2K to allow machine-specific pieces of an installation package to run in a higher security context than the currently logged-on user has. This setup lets the Installer service deliver and install an MSI package when the user needs it. (You can find the Installer service for NT 4.0 and Windows 9x at http://msdn.microsoft.com/ downloads/sdks/platform/wininst.asp.)

The Installer service runs on every Win2K workstation or server. It interacts with an MSI package to install the pieces of an application that require file or Registry changes that the user running the application can't perform because of security restrictions. The Installer service runs in the security context of Local System, so it can perform most changes that your application requires. (To read about another way to leverage AD and Group Policy to make applications available to your users, see the sidebar "ZAP It!")

I've introduced the pieces of Win2K that help you manage your application deployments. Now let's look at how these pieces work together to provide portable, self-installing, upgradeable applications.

Assigned vs. Published
Using the Win2K software installation features that are part of Group Policy, you have two options for making applications available to the user's desktop. You can either assign or publish an application. Assignments can happen per user or per machine. Published applications occur only per user. Think of assigned applications (e.g., antivirus software) as applications that are mandatory for a given user or machine population. For example, you might want users in your Finance Organizational Unit (OU) to always have access to your accounting application and Microsoft Excel. In AD, you can assign these applications to those users, and the users will always have access to them. Publishing an application to AD makes the application available to users if they choose to use it. Publishing is ideal for applications that your enterprise supports but that you don't want to install on every desktop because most users won't need them. For example, everyone in your accounting department might not need Visio's illustration program, but one or two people might occasionally need to create a drawing. In this case, you can publish the application to AD, and these users can get the application when they need it—by going to the Control Panel Add/Remove Programs applet and selecting the application.

When you assign an application for a given set of users or machines using AD and Group Policy, you are placing a skeleton of that application on the user's desktop, ready for installation when the user activates some component of the application. The system processes assigned applications when a user logs on (or on machine startup in per-machine assignments). On their Start menu, users will see a new icon corresponding to the assigned application. If the MSI package has so defined it, the system creates a file extension association in the Registry for that application and registers any OLE class identifiers for that application. If the user clicks the Start menu icon, double-clicks a file with an extension that corresponds to the assigned application, or invokes an OLE/COM application that requires the assigned application, the system checks the Registry for an installer token—a special value that signals that you need to install the package. The installer service then reads the Registry to determine where the MSI package is for that application and runs the install. The system installs the application on demand, and it becomes part of that machine or user's configuration. These presences—file association, shortcut, and OLE registrations—are called advertisements and are defined within an application's MSI package.

Publishing an application is different from assignment only in how the system presents the application to the user. No icon needs to be present on the user's desktop. If a user activates a file extension (e.g., myfile.doc) or OLE object that requires a published application that has not yet been installed, the system will run the application's MSI installation process before it runs the application. In Control Panel, a user can manually install an application with the new Add/Remove Programs applet that Screen 1 shows. This applet lets the user install a published application, repair or update an existing application, or remove an application that was previously installed. When you use Group Policy to publish new applications in AD, these applications appear almost immediately in the Add/Remove Programs applet. With published applications, users don't need to log off to see the new applications, as they do with assigned applications.

Managing Applications
Now that I've described how software installation works in Win2K, let's look at an example of how to implement it. In my example AD domain, mycompany.com is the DNS name of the collection of objects I've created in my Win2K AD.

Mycompany contains an OU called Finance. Within AD, domains can contain sites, OUs, users, and other objects. In particular, an OU lets you group objects into discrete management units, to which you can then delegate administrative rights that are a subset of the full domain rights. You can apply GPOs to an OU, just as you can to a domain or site. For example, to a given OU, you can apply a single policy that is automatically applied to all objects contained within. In the Mycompany domain, I've created a user called test1. Under Finance, I've created another user called test2. To associate software installation policy to these users, I need to launch MMC and load the Group Policy snap-in, which I can accomplish in several ways. The easiest method is to start the Active Directory Users and Computers snap-in (dsa.msc) focused on your domain. Right-click the domain or OU object for which you want to create a GPO. (In my example, I want to create a GPO for the entire mycompany domain and to the Finance OU.) Choose Properties from the context menu, then select the Group Policy tab.

To create a new GPO, select New. Then, name your GPO and click Edit to open the newly created GPO in a separate Group Policy snap-in window. You need to decide whether you want to create an assigned or published application. If you want to create a published application, you must publish per user; you can't publish per machine. For this example, I want to assign applications by user. In the Group Policy snap-in window, select User Configuration, Software Settings, Software Installation. Right-click the Software Installation node, and select New, Package. You'll see a File Open dialog box, where you can select a path to the MSI file for your application. Note that you need to enter a relative path, rather than an absolute path. For example, if your MSI packages reside on a server named Servera under a share called msi_apps, then you need to enter the path to the application files as \servera.mycompany.commsi_appsmyapp.msi. Don't use an absolute path such as C:msi_appsmyapp.msi because when a workstation looks for the package, it won't know whether to look on its own or the server's C drive. After you choose the package, you can publish, assign, or configure package properties. The latter option lets you configure package properties other than its advertisement state. For example, from here you can select a transform to apply to this package or put applications in categories within the ARP applet to make them easier to search on. (For a description of transforms, see "Windows Installer Takes Control," June 1999.)

I assigned two applications (Adobe Acrobat Reader and Visio) at the domain level, as Screen 2 shows. I repeated the process on the Finance OU and published two applications (Microsoft Excel and PowerPoint) to the Finance OU policy, as Screen 3 shows.

On the workstation side, I logged on using the test1 user ID that I created under the mycompany.com domain and the test2 user ID that exists in the Finance OU. When I logged on as test1, the installer service made the appropriate icon and Registry changes to create the assigned application skeleton for Visio and Acrobat Reader. Screen 4 shows that when I opened the Start menu for test1, icons for these two applications appeared. As soon as I clicked one of these icons, the installer service processed the MSI package to install the application, and the application started. When I logged on as test2 in the Finance OU, I also received Acrobat Reader and Visio on my Start menu because I inherited them from the mycompany.com domain policy. When I opened Control Panel's Add/Remove Programs applet, I could see the two applications—Excel and PowerPoint—that were published to the Finance OU, as Screen 5 shows. When you start the installation process for larger applications, a progress bar appears and estimates the installation time. If you decide you don't want to wait for the installation to complete, the system rolls back the current state of the installation and restores any files that the new application replaced.

Application Maintenance
Application installation is only part of the challenge. Over time, you'll probably need to remove or update applications with newer versions. The tools that I describe in this article allow for all these operations. When you create an MSI package, the system writes version control information to the workstation's Registry to allow for version-based updating. When you choose to update an existing application in the directory, the workstation captures this information at the next logon time. If you access an application that has been marked for update, your system will run the new updated installation package before running the application. When you're updating an application, you have the option of updating the existing application code that was installed or removing the existing application and installing the updated application from scratch. If you remove a previously published or assigned application from a GPO, you have the option of letting the user continue using the application or forcing a removal on the next machine startup or logon. When you need to update only a few files within an application, Microsoft will provide a facility to patch existing applications using the Windows installer technology. All of these mechanisms will make managing application life cycles in a Windows environment much easier. You'll even be able to update the Win2K OS using the software installation features and an MSI package for the OS.

Lowering TCO
As I spent more time working with Win2K's software installation pieces, I realized how powerful they will be for lowering total cost of ownership (TCO). Many software installation problems that plague large enterprises are easier to handle with the tools I've discussed in this article. The first release of Win2K will help you deploy and maintain applications over time. You still might need to supplement these features with other systems management tools to provide a truly enterprise-ready software distribution and configuration management solution. However, building a strategy that leverages AD's software installation features will take you a long way toward gaining control of your Windows environment.

[Editor's Note: This article is a revised and updated version of an article that first appeared in the April 1998 issue of Windows NT Magazine.]