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 registra-tions for globally unique identifiers (GUIDs), or keeping software installed and updated in a way that does not 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) 1.2 begins to tackle management issues, but some key pieces are missing or are difficult to implement in a support 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 NT 5.0, Microsoft attempts to take ZAW from theory to reality. For example, NT 5.0 will provide services to enhance application management. In this article, I'll show you how Microsoft plans to help you better manage your desktop applications and how that plan fits into the overall 5.0 picture. All the pieces I discuss in this article are based on what's available in NT 5.0 beta 1.
The Problem
If you have hundreds or thousands of workstations spanning the country or the world, making physical visits to workstations to install applications is not an option. Further, if you need to manually, or even via script, touch each workstation to update or fix those applications, and then 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, Registry entries specific to the workstation (e.g., HKEY_LOCAL_MACHINE), Registry entries specific to the user (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 NT 5.0, Microsoft has made great strides toward easing this administrative burden with several features that are built into the operating system and are collectively referred to as application management: the Active Directory (AD), Group Policy Editor (GPE), Microsoft Installer (MSI) APIs, and Installer service.
The Application Management Pieces in NT 5.0
AD plays a key application management role in NT 5.0. 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 application objects. In previous versions of NT, you needed to ensure that you had class registrations on every machine where an application was installed. But in NT 5.0, you can use AD to make class registrations available regardless of machine state or physical location. 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 to which they are entitled.
GPE is the tool that you use to enable the application management features in the directory. GPE is a Microsoft Management Console (MMC) snap-in that lets you advertise applications to AD for clients to use. You can use GPE to update applications that were previously advertised or remove applications from further use. (MMC 1.0 is shipping now with BackOffice products such as Internet Information Server--IIS--4.0 and will be the de facto management tool for the BackOffice suite.) In addition, GPE is a multifunction tool that lets you define logon and logoff scripts and define policies similar to NT 4.0-style system policies.
MSI is new technology that lets you package applications for deployment via AD. MSI is a set of APIs that independent software vendors (ISVs) can use to write ZAW-aware setups. MSI packages address the thorny issue of separating user-specific pieces of an installation from machine-specific pieces. MSI packages work with the new Installer service that ships with NT 5.0 Workstation 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.
The Installer service runs on every NT 5.0 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 who is running the application is unable to 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.
I've introduced the pieces of NT 5.0 that help you manage your application deployment. Now let's look at how they all work together to provide portable, self-installing, self-upgrading applications that can be portable to user or machine.
Published vs. Assigned
Using NT 5.0 Application Management features, you have two options for making applications available to the user's desktop. You can assign or publish an application. Think of assigned applications as applications that you always want the user to have access to. 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 lets users access only the application that they really need. 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.
When you assign an application for a given set of users using AD and GPE, 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. The Installer service copies an Application Advertise Script (*.aas) from a location specified in AD to the user's profile in the %userprofile%\msi folder. The machine processes this script at logon time to build an application presence on the system. On their Start menu, users will see a new icon corresponding to the assigned application. The system also creates a file extension association in the Registry for that application, and registers any Object Linking and Embedding (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 service that requires the assigned application, the system checks the Registry to see whether the application has been installed yet. If not, the Installer service starts. It 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's and user's configuration.
Publishing an application is different from assignment only in how the system presents the application to the user. When you publish an application, an Application Advertise Script processed at user logon time creates only the file association and OLE registrations. No icon for the application exists on the desktop. If a user activates a file or OLE service that requires a published application that has not yet been installed, the system will run the application's MSI installation process before running the application. In addition, in the Control Panel, a user can manually install an application with the new Programs Wizard you see in Screen 1. This wizard lets the user install a published application, repair or update an existing application, or remove an application that was previously installed. When you add a published application from the wizard, the Installer service adds an icon for the application into the user's profile, just as if the application were assigned. The next time the user clicks the icon, if the application hasn't been installed, the MSI package runs. When you publish new applications in AD via GPE, these applications appear immediately in the Programs Wizard. With published applications, users do not need to log off the see the new applications, as they do with assigned applications.
Managing Applications
Now that I've described how application management works in NT 5.0, let's look at an example of how to implement it. At the September Professional Developers Conference, Microsoft released some sample MSI packages to demonstrate this technology. I'll use these packages in my example AD domain, Drugco.com. Drugco.com is the Domain Name System (DNS) name of the collection of objects I've created in my NT 5.0 AD.
Drugco contains an OU called Finance. Within AD, domains can contain sites, OUs, users, and other objects. An OU is a way of containerizing objects into discrete management units. For example, to a given OU, you can apply a single policy that is automatically applied to all objects contained within. In the Drugco container, I've created a user called ZAW1. Under Finance, I've created another user called ZAW2. First, I need to launch MMC and load the GPE snap-in.
When I loaded the snap-in, I needed to apply my group policy to a given domain, site, or OU. (NT 5.0 beta 1 does not extend policy granularity down to the user group level. This capability is desirable for applying a single policy to users that cross multiple OUs.) In this case, I assigned a group policy to the entire Drugco domain and to the Finance OU. I enabled the application management extensions to GPE so that I could assign or publish applications into these containers. Next, I right-clicked the Drugco Policy and added my applications. For this example, I assigned two applications at the domain level, called Red and Green, as Screen 2 shows. Next, I published two applications, called Black and White, to the Finance OU policy, as Screen 3, page 160, shows. When you add an application to a policy, the default installation mode is Published. If I right-click one of the applications I've just installed at the Drugco domain level, I can adjust the properties of the application to Assigned, as I did in Screen 4. You can have an application appear in the Programs Wizard, which is the default for published applications. The path to the application is absolute. The workstation needs this path information to correctly find the MSI package.
On the workstation side, I logged on using the ZAW1 user ID that I created under the Drugco domain and the ZAW2 user ID that exists in the Finance OU. As ZAW1, when I logged on, the Application Advertise Script was read from the directory, and the Installer service made the appropriate icon and Registry changes to create the assigned application skeleton for the Red and Green apps. Screen 5 shows that when I opened the Start menu for ZAW1, icons for these two applications appeared. As soon as I clicked one of these icons, the Installer service ran the MSI script to install the application, and the application started. When I logged on as ZAW2, in the Finance OU, I also got the Red and Green applications on my Start menu, because I inherited them from the Drugco domain policy. I also had access to the published applications, Black and White, via the Programs Wizard you see in Screen 6. When I added these programs, they appeared on ZAW2's Start menu (i.e., part of the user profile) and were available to be installed and run just as Red and Green are. I'm curious to see how Microsoft handles the installation of larger applications via the Installer service. For example, if a large application such as Visio is installed as a function of clicking on a drawing file, the operation might take a long time to complete. Ideally, the Installer service could provide the user with an estimated time to complete the install, with the option to cancel the install if it's too time consuming.
Application Maintenance
Application installation is only part of the challenge. Over time, you will most likely 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, version control information is written to the workstation's Registry to allow for version-based updating. When you choose to update an existing application in the directory, the workstation-based Application Advertise Script 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. If you remove a previously assigned application from the group policy, the next time the user logs on, that application will not appear in the Start menu. I noticed that in NT 5.0 beta 1, the icon is removed from the Start Menu, but the executable is not removed from the hard drive.
Lowering TCO
As I spent more time working with the application management pieces in NT 5.0, I realized how powerful they will be for lowering total cost of ownership (TCO). Many application management problems that plague large enterprises are easier to handle with the tools I've discussed in this article. However, Microsoft clearly has some work to do to prepare these features for final release. For example, the NT 5.0 beta 1 offers no way to assign or publish applications at a more granular level than OU. This configuration is fine for commonly used applications, but I'd like to be able to assign or publish applications down to the user group or even user level, for departmental or workgroup-specific application needs. In any case, this technology far exceeds what is available today.
