Unattended Installs in a Perfect World

Automating hands-off configuration with Windows 2000 is still too hard

Windows 2000's (Win2K's) new rollout and deployment tools are a great improvement over those of Windows NT 4.0. But the new tools still don't do what I need them to do. I wipe my computer's hard disk and reinstall my OS and applications from scratch a few times a year. I'd like to automate this process but usually can't. Although scripting an OS installation has become easier (as I explain in Inside Out, "Unattended Installs with Windows 2000 Professional," page 175), application installs and the fine-tuning that I need to do to make my applications just right are difficult or impossible to script. What I call the Holy Grail of configuration—push a button, walk away for an hour, and return to find a freshly installed clone of my old system—is still just out of my grasp. Like Perceval in the Arthurian story, I sometimes think that I can glimpse the Grail from across the room, but I can't quite get my hands around it. With just a bit more work, however, I think a portable, hands-free setup and configuration service could be possible.

Traditional cloning tools such as Symantec's Norton Ghost, Microsoft Remote Installation Services (RIS), and PowerQuest's Drive Image Pro are useful, but those tools clone by storing unwieldy multigigabyte images. Using a traditional cloning tool seems inelegant because my configurations are fairly simple, requiring only a few thousand bytes rather than billions of bytes.

What information do you really need to have when you're installing an OS and a bunch of applications? Assume that the installs will be network-based, with installation files on a server. First, you need to know which server and share contain the installation files, and you need a user account name and password that can access that share. You need to know the command (and its parameters) that kicks off the installation. When you install an OS, the system usually asks you some questions, so you need to store the answers to those questions somewhere, as you do when you prebuild an installation script. Finally, you need the same information for each application that you want to install.

In a perfect world, individual application setup programs wouldn't exist. Your system would simply use a generic Setup program that could install the OS, the applications, or both. The Setup program would require as input a script for each application that would tell the program how to do a no-frills installation for that application, but Setup would also know the questions and possible answers that each application's installation routine requires. Setup could then read the answers to those questions in a standard format that works for all applications and OSs. You could give Setup a file telling it which applications and OS you wanted to install, where to find them, and what responses to give to the applications' installation questions. Then, you could leave, and Setup would configure your machine exactly the way you like it.

Building a script file for this über-Setup doesn't need to be difficult. When you run Setup manually, it could pay attention to your choices, then produce a script file to reproduce that configuration exactly on another machine. I can also imagine a program that could at any moment audit a PC and generate a script that could clone that system. Imagine being able to execute a simple command and receiving a few pages that completely describe a particular PC's configuration!

The perfect installation would need one more thing: a way to get started. Because an empty PC contains no code, how do you get to the network in the first place to invoke Setup? The RIS- or Preboot Execution Environment (PXE)-based model is a good start but supports only a limited set of computers. The model's main problem arises because every model of NIC requires a different driver. But NIC vendors could fix that problem by agreeing to always support a basic set of networking commands in a uniform manner with some kind of bare-bones network API (call it BBNAPI). Then, you could carry around one disk that contained just enough code to attach a new computer to a network so that you could kick off the generic Setup engine.