Configuration and Control Management capabilities
Microsoft began talking seriously about lowering total cost of ownership (TCO) more than a year ago, when the company announced its plans for Zero Administration for Windows (ZAW). This set of technologies helps administrators centrally control a large number of desktops in their enterprise. The technologies include some existing tools (such as system policies in Windows NT 4.0, Windows 95, and Win98), and some evolving tools, such as Systems Management Server (SMS). In addition, Configuration and Control Management (CCM) is an important set of ZAW features that will appear in NT 5.0. Microsoft uses the term CCM to describe the parts of the overall ZAW initiative.
CCM originally consisted of several technologies and a set of guidelines for independent software vendors (ISVs). CCM emerged out of the hope that Microsoft could solve some of its clients' common administration problems. A year of discussion with those clients has helped Microsoft improve those ideas, leading to a vision of CCM that is less grandiose than the original ZAW concept but more feasible. (To read about earlier ZAW concepts, see "Zero Administration for Windows," December 1997.)
CCM, the revised ZAW, focuses on solving three problems: Installing an operating system (OS) on a new computer or a new hard disk in an existing computer, deploying applications from central servers to the desktop, and distributing modifications or upgrades to those applications by means of IntelliMirror.
Installing Operating Systems
CCM can help you wipe the hard disk on an existing system and rebuild the OS. You need a remote installation server and either a NetPC-compatible system or a boot disk that makes your garden-variety PC behave like a NetPC for the duration of the OS install. NT 5.0 includes tools to build a boot disk of this type. You can make a remote installation server by installing the remote installation service on an NT 5.0 server. The NetPC or the NetPC boot image contains Dynamic Host Configuration Protocol (DHCP) and the Trivial File Transfer Protocol (TFTP). A remote installation server downloads a program called OSChooser (the client installation wizard) to your desktop. That program lets you log on with your name, password, and domain. Then OSChooser passes that information to the remote installation server, which looks you up in the Active Directory (AD) to see what OS your systems administrator has assigned to you.
The remote installation server will download programs to your workstation based on the OS information in the AD. Currently, you have three options with NT 5.0 and the remote installation service: the standard NT Setup program, a scripted version of Setup, or a SysPrep image. SysPrep is a new NT 5.0 feature that lets administrators prebuild installed images of NT systems and distribute them. You'll see these choices when you run OSChooser. This option is different from ghosting a drive image out to a workstation because SysPrep adjusts security IDs (SIDs) to make sure they are unique. As currently envisioned, remote installation servers will support installs only for NT 5.0.
Deploying and Upgrading New Applications
Once you have an OS on a PC, you'll need applications. One goal from the beginning of the ZAW initiative has been to simplify the process of putting applications on a workstation. From the outlined plans of just a year ago, Microsoft has made great strides in this area--much of the code to try out deployment is in place in NT 5.0 beta 2.
You can deploy an application by getting or creating a package file with an .msi extension and placing that file and any other necessary setup files on a central server. You assign an application to a user via the AD. (For definitions of terms, see "Zero Administration for Windows," December 1997.) When you do this, the user will see the application on the Start menu as if the application is already installed on the local hard disk. The first time the user clicks that application's icon, a new NT 5.0 service, called Installer, runs. Using the information in the .msi file, Installer does a hands-off installation of the application on the user's machine in a few seconds. Deploying upgrades is simple. You deassign the old version and assign the new version. For example, if you use Word 97, you click Start/Programs/Microsoft Word, and Word 97 opens. If Word 97 is deassigned and Word 2000 is assigned, Installer will automatically install Word 2000 the next time you run Word.
Many applications will ship with .msi files, and I assume all the big vendors will provide them. But .msi files are more than just program installation information; they also contain customization information such as what organization name to insert and whether to do a typical or complete installation. Administrators can customize an .msi file to an enterprise in different ways. First, tools from InstallShield and Seagate (WinINSTALL) will be able to take an .msi file apart and put it back together to add or remove customization information. Because this task is difficult, many applications will include some kind of administrative setup routine. This routine will ask the creator of the original network distribution point questions about overall configuration and then write an installer transform file (.mst). Second, administrators can simply create their own .msi files using WinINSTALL, which is similar to (and an improvement on) sysdiff. WinINSTALL learns how to install an application by taking snapshots of a reference system before and after installing the application. NT 5.0 will ship with a free reduced-function (though still powerful) version of WinINSTALL.
If .msi files simplify deploying applications, how do they perform with simpler tasks, such as delivering a single new .dll file? For example, earlier this year, Microsoft distributed a replacement .dll file as a fix for a Word bug. CCM could simplify the replacement process by letting Microsoft use a tool such as WinINSTALL. By simply recording a reference system before and after copying the replacement .dll file, WinINSTALL produces an .msi to do the job. From there, putting the .msi in a logon script and copying the .dll file is easy.
Another goal of the ZAW initiative is to keep ISVs from overwriting system .dll files. ZAW provides two ways to prevent an .msi package from overwriting a system .dll file. Shortly after NT 5.0's release, ISVs will not qualify for the Ready for Windows logo if their products overwrite system files or put anything in the system directories. Also, before putting a new application on the distribution server, an administrator can use WinINSTALL to pick apart an ISV's .msi file and look for undesired copy commands. The administrator can modify the .msi to remove the copy command, or send the application back to the vendor and suggest that the vendor rethink releasing software that makes a mess when it's installed.
Prev. page
[1]
2
next page 
