Zero Administration for Windows

Have you ever grumbled about how hard reinstalling Windows NT is? Have you ever noticed that Windows 95's Briefcase is a great idea trapped in a poorly implemented program? Have you ever wanted to remotely install applications on users' desktops with just a few mouse clicks and no programming? If so, you'll be happy to learn about new developments in the Zero Administration for Windows (ZAW) initiative.

After years of indifference, Microsoft has finally decided to make supporting its operating systems easier. Microsoft is making many support changes under the ZAW umbrella. At first glance, ZAW seems like a huge, all-encompassing change to how NT works, but ZAW really rests on just a few key technologies: a new caching system, better application installers, intelligent storage, and PCs with a mildly smarter BIOS.

IntelliMirror: A Network Caching System
A keystone of ZAW is IntelliMirror, a new caching system built into NT 5.0. Instead of the common disk cache found on all modern desktop operating systems, IntelliMirror is a network cache. Here is how network caching works: Accessing a file on a network is typically slower than accessing a file on a local hard disk, so NT 5.0's network redirector keeps a copy of often-used network files on the local hard disk. Suppose you want to access a file on the network. The redirector checks whether the copy on the hard disk is the same as the copy on the network. If the copies match, the redirector simply accesses the local hard disk copy, saving time. If the copies don't match, the redirector updates the appropriate file and then accesses the hard disk copy.

If IntelliMirror detects that the server is no longer accessible because the network failed or you disconnected your laptop from the network, the file seamlessly works out of the cache. If you've ever lost a Word document because the network hiccuped, you'll love this feature.

You might also learn to love other IntelliMirror features because of the convenience they offer. For example, with IntelliMirror, your users can roam and keep their data handy. Microsoft suggests you set up the system so that applications store users' data in the My Documents folder. (You can, however, store your data anywhere you want. The My Documents folder is just the default). Because My Documents resides on the server, any machine you log on to can access those documents. Once the server and a machine connect, the NT 5.0 network redirector copies the documents onto the machine's local hard disk. Thus, users can quickly access those documents. Updating the documents is a bit slower because IntelliMirror is a write-through cache. When you modify and save a file, the redirector immediately writes the modified version to both the hard disk and the network.

IntelliMirror can make working with network-based files easier when you're on the road. Suppose you connect your laptop to the network so that you can work on a file located on a server named PUBSERVER. The file's universal naming convention (UNC) is \\pubserver\finance\oct97.xls. Once you're on the road, you just start up the laptop and open the file \\pubserver\finance\oct97.xls. Although you are no longer connected to PUBSERVER, the file oct97.xls is in your IntelliMirror cache and IntelliMirror recalls its original UNC. You can then work on the file and save it to the network (which is actually the IntelliMirror cache). When you reconnect to the network, NT 5.0 will detect that you changed oct97.xls and will automatically overwrite the copy on the server with the newer version on your laptop. If someone changed the version on the server while you were gone, IntelliMirror asks you what to do. As one Microsoft employee wryly explained to me at TechEd last June, IntelliMirror is "just like the Briefcase, except it works."

IntelliMirror not only caches files ordinarily found on the network, but also caches their network names, which again helps laptop users. Before I go on the road, I must remember to copy those files I need onto my laptop. Then, when I start up Word and try to access one of those documents, I have to hunt around my laptop's hard disk to find that file. What was once \\server1\books\chapter2.doc is now d:\ontheroad\chapter2.doc, so I can't just pull down the File menu and select from that menu's Most Recently Used list. After returning to the office, I have to remember to reconnect my laptop to the network and copy the modified files onto the server. Finally, I delete the copies on the laptop's hard disk because I don't want several versions of a file floating around. With IntelliMirror I don't need to worry about any of that.

As these examples show, IntelliMirror is a local network cache that keeps copies of your server-based files on the local hard disk. Sounds good, but what about security? Suppose I log on to a common machine, work on a secure server-based file (such as a memo containing everyone's salaries), log off, and walk away from the machine. That memo is on the common machine's hard disk. Isn't that a security hole?

The answer is yes and no. First, files are person-specific because NT 5.0 relies on NTFS. So when Joe logs on to the common machine after I get off, he won't have file permissions to access the memo. In addition, files in the cache don't have ordinary names. Instead, they have names like M75%193746229127.CHC. So Joe isn't likely to just happen across a file named payroll memo.doc, even if Joe feels inclined to poke around the cache. However, if Joe has an administrator-level account on that workstation, he can certainly take ownership of the file and modify the permissions so that he could read the memo.

You have two ways to protect your NT 5.0 system against this type of security breach. First, don't freely hand out administrative accounts. Compared with previous NT versions, NT 5.0 administrative accounts let people do a lot more because NT 5.0 can do a lot more. Second, you can tell IntelliMirror not to cache a particular account's profile and other files. However, this solution is a bit troublesome because you must forgo all the benefits of IntelliMirror. IntelliMirror would have been better if Microsoft had designed it so that you could tag certain files as noncacheable.

At this point, you might be thinking that IntelliMirror offers convenience, but not really support. IntelliMirror's code-signing verification and self-healing applications might change your mind.

Installing and fixing applications cause many headaches for support specialists. You might need to fix an application for several reasons, but a common reason is overwritten DLLs. Most programs ship with not only an EXE file, but also at least one DLL. (Some programs have as many as 30 DLLs.) Applications should store their DLLs in their application directories (e.g., DLLs that Word uses ought to go in the Word program file directory), but many vendors, including Microsoft, are in the habit of dumping their DLLs into the system32 directory. As a result, if you load an application that needs a DLL named stuff.dll, the chances are good that the application will copy the DLL to the system32 directory. If you load another application that also happens to need a DLL called stuff.dll, the second application's installer will probably gleefully overwrite the first application's stuff.dll file. Consequently, the newer application will run perfectly, but the older application won't work.

Microsoft is trying to fix the overwritten DLL problem by asking vendors to keep their DLLs out of common areas. In fact, in about a year, any vendor wanting to put the Designed for Windows logo on its software must put its DLLs in the proper place.

In addition, Microsoft will offer code-signing verification to prevent intentional overwriting of DLLs. In code-signing verification, a public-key authentication method lets the operating system verify at runtime that the code about to run is the code signed by Microsoft, Lotus, or whomever. Code-signing verification is built-in protection from viruses and program file corruption. (Because code-signing verification will probably be a bit costly CPU-wise, this feature will probably be optional on NT 5.0.)

An erased file is another common cause of headaches for support specialists. For example, suppose that you accidentally erase a program file for Word, but you don't realize it. If users try to subsequently open Word with previous NT versions, they will get an error message. With NT 5.0, however, Word will just reinstall itself. Microsoft refers to this concept as self-healing applications. A new installer technology, the Microsoft Installer (MSI), makes self-healing applications possible.

MSI: A Better Installer
With MSI, applications will not only perform self-diagnoses to detect internal failures, but will also fix those failures through reinstallation. Based on your past experiences with reinstallation, you might expect a screen that says something like, "Welcome to Setup for Word for Windows" and then be bombarded with the usual 15 dialog boxes that accompany setup programs. Fortunately, the application performs a silent install. MSI doesn't assail you with the usual setup questions because you pre-answer all of them.

To be self-healing, applications will need to be MSI compatible. In other words, an application must include a file with the extension .msi that contains all the information necessary to install that application. MSI reads this information and reinstalls the application.

The MSI file is also called a package, a term familiar to Microsoft Systems Management Server (SMS) administrators. SMS administrators use packages for hands-free (i.e., installs without asking the user any questions) remote installation of applications.

With packages, however, you must write a script that automates the keystrokes and mouse clicks that a user ordinarily makes when installing the software. Most scripts are not much fun to write and tend to be fragile. A few vendors have made this task easier by designing their applications' setup programs to accept simple ASCII files that contain the answers to Setup program questions. Thus, you just create an ASCII file rather than messing around with scripting languages. But no two vendors use the same kinds of scripts, so if your enterprise uses 10 packages, the best you can hope for is learning 10 setup file formats so that you can create 10 application-specific ASCII files. The worst case is if none of the vendors use setup files, forcing you to write 10 different script programs.