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.
| ZAW provides two ways to prevent an .msi package from overwriting a system .dll file. |
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.
IntelliMirror Evolves
The CCM feature that lets you distribute modifications or upgrades is IntelliMirror. In its current implementation, IntelliMirror is a type of intelligent network cache program. It controls network data caching from both the server side and the client side.
On the server side, you can control whether a particular folder can be cached. The NT 5.0 default is that a server does not let its clients cache data. If you allow caching, you can cache a folder in three ways: automatic caching for programs, automatic caching for documents, and manual caching. Each method describes different directions a server gives to a workstation about what data to cache and for how long. With IntelliMirror, the server directs the client how to cache network data. This compatibility makes IntelliMirror unique.
Automatic caching for programs. Of the caching options, the simplest method is probably automatic caching for programs (caching for data that doesn't change). Suppose you have a shared folder containing fairly consistent data such as clip art. Many people might connect to that clip art over the network and use files from the folder, but no one writes data back to that directory. If no one updates the clip art folder regularly, the shared folder is a read-only resource. Automatic caching for programs improves efficiency in such cases by copying an accessed file to the IntelliMirror cache on the user's workstation. The file stays there (pinned in the cache) until the user clears the cache. Furthermore, whenever a user accesses that file, the workstation will pull it out of the local IntelliMirror cache and never ask the server if that version is the most recent version. The clip art file will never change, so there's no reason to waste network bandwidth rechecking with the server.
Automatic caching for documents. Automatic caching for documents works well for files that may change but need to be handy even when the network is down. A good example is a shared directory holding a copy of an employee handbook that changes every week or so. With this cache setting, the server directs the workstation to initially behave as it would with automatic caching for programs. It makes a copy of the file in the workstation's IntelliMirror directory. After the first time an employee accesses the document, a copy of it is on the employee's hard disk.
When the workstation notes that it has a copy of the file stored locally, it contacts the server to see whether the employee handbook file has changed. If so, the workstation goes out and gets the file from the server. The user works from the server's file. A copy of that latest version of the file goes into the IntelliMirror cache. If the user changes the employee handbook file and saves it, copies of this latest version immediately go to both the server and the local cache.
If the workstation is a laptop that the user has disconnected, a copy of the handbook will be on the local machine because it was automatically cached. If the user modifies the handbook file, IntelliMirror saves the revised copy in the laptop's cache. When the user returns to the office and reconnects the workstation to the server, two dissimilar copies of the file exist--the one on the server and the one in the laptop's cache. A program called Synchronization Manager resolves the differences.
This kind of caching can cause a problem. Once something is in the cache, it remains there until you remove it. The user's cache could fill up. The IntelliMirror cache doesn't throw out an old piece of data to free space as disk caches do. Because you use some files only occasionally, you won't want to cache them, and cleaning them out can be tiresome. Given that hard disk space is always at a premium, wouldn't it be better if you could choose which files to cache?
| IntelliMirror in its current incarnation is more like a well-designed version of the Briefcase than a cache. |
In some cases, caching can be dangerous. For example, if I look at a sensitive document on another user's workstation, that document will sit on the hard disk in the IntelliMirror cache after I leave--but only if several things occur. The first time I log on to another user's workstation, I will have the option to keep my settings on that workstation. If I select No, IntelliMirror won't cache anything that I access at that machine. If the sensitive document's directory isn't set for caching, or if the directory is set for manual caching and I don't tell NT to make a document available offline, IntelliMirror will not cache the file. But if I copy the document to the IntelliMirror cache, the user could find it. The file would not be immediately obvious because IntelliMirror would save it with a serial number tag instead of the original file name. Because IntelliMirror doesn't combine all of its cached data into one big file like the paging file does, only a little perseverance on the user's part would reveal that someone else looked at the sensitive file. Of course, if the user's drives are NTFS, the cached files will be secured to me, but that assignment would not be much of a detriment, because many users have local administrative accounts for their computer.
Potentially Powerful
IntelliMirror in its current incarnation is more like a well-designed version of the Briefcase than a cache. Microsoft is making its lower TCO promises more distinct by revealing a useful set of technologies that promise to help reduce some common administration problems. As with most of NT 5.0, CCM has the potential to be quite a powerful product.
