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.

With MSI, however, the process is much simpler. You just need to answer several questions to create a setup package and then save it as an MSI file. The setup file format will most likely be the same in all vendors' applications because Microsoft created a unified table-driven method for answering setup questions. Microsoft developed this method with other software developers, so most new applications will be MSI compliant.

Why are independent software vendors supporting MSI? Because MSI supports ZAW, and a lot of big clients want ZAW. In addition, vendors' applications won't qualify for the Designed for Windows logo without MSI support.

Besides using MSI for self-healing applications, you can use MSI for installing and removing programs. Suppose you want to distribute a new word processor, WordBlaster, to your users, but you want to spend as little time and shoe leather as possible. With MSI, all you do is assign the application to an NT group, such as Everyone.

What does assign mean? Under NT 5.0, you can centrally modify the Start Programs menus of all your users to include particular applications, even if those applications aren't on those users' systems. (Currently, you can centrally control people's Start Programs menus with system policies. Just like many other ZAW features, the assign feature is just an enhancement of existing technologies.) When users log on, they'll see a menu option for WordBlaster even though you have not installed WordBlaster on their systems. When they try to start WordBlaster, the operating system realizes that WordBlaster isn't properly installed and the self-healing application process kicks in.

At this point, you might be wondering about what permissions you'll have to give users--after all, users must have a fair amount of power over their workstations to install applications, right? Not quite, because the user doesn't install the software, MSI does. But don't be surprised if a whole new class of NT security holes develops once hackers figure out how to build a command prompt that runs in MSI space.

Besides assigning an application, you can get an application into the ZAW world in two other ways. You can make an application generally available by publishing it in the Active Directory (AD). The application doesn't go into the AD. Rather, the AD contains the instructions about where to find it. When users start the Install New Programs wizard in the Control Panel, they'll see that list of programs. Another way to make an application generally available is through the Class Store. For information on how the Class Store works, see my article "NT 5.0 Gets Better and Better--Mostly," page 124.

Removing a program is as simple as installing one. Suppose you want to discard a current application of Word because you want new settings. But if you remove and then reinstall an application, it remembers all your settings from the first installation. Clearly, the removal process doesn't include cleaning out the Registry settings relevant to Word.

With MSI, this situation changes. When removing a program, MSI will delete all files relevant to an application and all Registry entries.

MSI and IntelliMirror work well together. Suppose Sally, a WordBlaster user, tries to run WordBlaster, but it's not yet on her machine. NT 5.0 uses the MSI package you prepared to install WordBlaster quickly and silently. You set up WordBlaster with a network installation option, so no files go on Sally's machine. Instead, they're all on her space on the network, so the data can roam with her more easily. Despite working on the network, WordBlaster runs quickly for Sally because her workstation is running from the program files in the local IntelliMirror cache. Furthermore, if the server's down, Sally can still get work done because her workstation is using the local cache. In the meantime, you can update and install patches on WordBlaster more easily because the application is on the server.

SIS: A Smart Idea
If 2000 users all install WordBlaster and it's a network install, will you end up with 2000 copies of WordBlaster on the server? Don't run to your stockbroker to buy Seagate stock just yet. ZAW avoids having 2000 copies with the Server Intelligent Storage (SIS) server-side program. With SIS, you designate a section of a server's storage as an SIS area. When a user saves a file to that server, the server checks the file against the other files in the SIS area. If that new file is identical to an existing file, SIS doesn't save a second copy of the file. Rather, SIS just stores a directory entry for that file.

SIS sounds like a very cool technology, but I wonder about how CPU intensive it'll be. My guess is that adjusting SIS sizes will be one of the great tuning pastimes of NT 5.0 Server administrators.

What does SIS mean for laptops? Suppose you are a PowerPoint user and you set up PowerPoint to run from the network. What happens when you take your PowerPoint on the road?

In theory, SIS will work effectively because when you run PowerPoint on the network, IntelliMirror copies the PowerPoint program files into the local IntelliMirror cache. So when you're on the road, the program files will be available. In reality, however, you can run into trouble two ways.

If you've never used PowerPoint's Rehearse Timings feature before, you might get into trouble the first time you use PowerPoint on the road. PowerPoint will request the file rehearse.dll--and it will not be in the cache because your system never requested the file before. Your laptop will respond by trying to reinstall (i.e., self-heal) PowerPoint because you originally installed the application from the network. From this point, the problems will escalate.

Another way in which you might get into trouble is if you used numerous network files before leaving the office, causing IntelliMirror to flush the PowerPoint files from the cache. (If you use more files from the server than you have hard disk space for, IntelliMirror determines which files are important. It keeps the important files and lets the others expire out of the cache.)

You can avoid both problems by pinning PowerPoint in the cache. If you know that you're going to need a particular application, you pin it, which tells IntelliMirror to collect all the files that the application might need and keep those files in the cache. In other words, pinning a file tells IntelliMirror not to let that particular file expire out of the cache.

BIOS: The Pièce de Résistance
With ZAW, you can perform clever client-side caching (IntelliMirror), easily install and remove applications (MSI), and minimize the amount of space used on the server (SIS), all from a central location. Could it get any better? What if you could install an entire operating system from a central location? Microsoft envisions that ZAW will be able to provide this capability. Consider the following scenario:

It's 8:00 a.m. You come to work and turn on your computer, Sparky. A funny noise comes from the hard disk, and smoke comes out the back. A quick inspection of the melted SIMMs and cratered CPU inside leads you to believe that Sparky's computing days are over. You were planning to get some work done, but installing and configuring NT Workstation, the Office Suite, and assorted other applications will now occupy most of your day.

With ZAW, the day will proceed differently. After your quick inspection of Sparky, you tell your network administrator about the casualty. You then say good-bye to Sparky and search for a computer that no one is using. You find a vacant computer and log on. Because all your applications are ZAW compliant and you keep your data in My Documents, all of your applications and data are available. MSI performs a couple of silent installs, and you are back in business in a half-hour.

Meanwhile, the network administrator takes a new computer out of the box and assigns it to you. She tells the network that you have a new computer, identifying it to the network. She then brings this computer to your office, plugs it into Sparky's old Ethernet jack, and turns it on.

The new computer is either a NetPC or a regular PC that follows the PC98 specification, so it has a smarter BIOS than most PCs have. The PC BIOS includes support for network cards, the Dynamic Host Configuration Protocol (DHCP), and the Trivial File Transfer Protocol (TFTP). When the PC powers up, the BIOS knows enough about the network card to use it to get the PC an IP address via the DHCP. With the other DHCP information, the new computer gets the address of an install server. The new computer then sends a request for configuration to the install server. The install server checks a database to determine which operating and system applications this computer needs and assembles the necessary files. The install server then uses TFTP to transfer the files to the new PC. In no time, the new computer works as well as old Sparky did, maybe even better.

How did the install server know that this new computer was your computer? PCs with the improved BIOS have a globally unique ID (GUID), which an administrator can use to identify that PC to the install server. With GUID, you can configure systems on a user-specific basis. For example, instead of specifying that a particular machine gets Windows 98 (Win98), you specify that a particular user gets Win98. When that user logs on, the system installs Win98.

In fact, each time users log on to a system, that system will do a fresh install of their operating system and applications. A fresh install might sound like a lot of work, but 999 out of 1000 of these installations will take almost no time because all the files will already be in the local IntelliMirror cache.

Fortunately, you don't need new PCs to run the improved BIOS. You just need a bootstrap floppy to get the process rolling the first time.

Good Things Come to Those Who Wait
Computer support specialists have waited a long time for an initiative such as ZAW. But ZAW will be worth the wait because it includes some terrific and exciting capabilities. Central control of machine and application installation and configuration is just plain wonderful.

But central control and all of ZAW's other features will work only if the applications vendors go along with ZAW. More important, ZAW will work only with one operating system. For ZAW to work, you must be running NT 5.0 on all your desktops.