Rolling Out the Hard Way

Murphy's Law rules

Just when you thought the world was moving from a 32-bit universe to a 64-bit universe, the 16-bit specter rears its ugly head. We know what you're thinking: "What the heck would I be doing with 16-bit apps? I got rid of those years ago. And I've got Windows on Windows to handle anything that I might need from the 16-bit past."

Well, that's pretty much what we thought, too. Until it was time to roll out 50 identical new computers for our network test bed. Because the future of this kind of bulk deployment obviously belongs to the tools that let you clone systems, we thought we'd give those tools a try.

Cloning the systems was easy. Our new computers are bare-bones boxes, with a 350MHz AMD-K6-2, 64MB of RAM, basic ATI 2MB video, a 4.3GB ATA drive, and Adaptec 10/100 Ethernet adapters. All the leading cloning products we used created basic images of the disks and made the necessary SID changes with no trouble. But when the time came for us to distribute the images to the networked machines, which had no local OS, we were stymied.

You see, at this point we needed to use MS-DOS to boot the machines on the network and log on to the network so that we could write a disk image out to each computer. Although creating MS-DOS LAN Manager boot disks is never a pleasant task, in this case it was impossible. The new-to-the-market Adaptec Ethernet controllers in our new computers had all the drivers for the latest state-of-the-art 32-bit OSs but no drivers for plain old MS-DOS. Without MS-DOS drivers, we couldn't automate our network rollout. When each computer had an OS, we wouldn't have any problem making upgrades to the OS or to the network drivers; the trick was getting an OS on each system in the first place.

Our goal was to put two OSs on each machine: Windows 2000 Professional (Win2K Pro) and Windows NT Workstation 4.0. We also wanted to keep images of each installation available to blast out to the system so that we could always return the machines to a known state between test projects, should that be necessary. Although in most cases we'll be using these systems as network clients to generate loads against network server hardware and server-side applications, we occasionally test software that we need to install on multiple network clients. The ability to shoot a standard disk image onto any system lets us use our network test bed much more efficiently.

Unfortunately, when we were setting up the test bed, no simple way existed for us to implement a remote boot. (When Windows 2000—Win2K— ships, the OS might make possible, with proper support, a remote boot followed by remote OS installation.) So we ended up doing the installations the hard way. We installed a standard image that we wanted to apply to each machine onto a prototypical system. We then hand-carried that system's hard disk to each computer in the test bed, installed the disk on the IDE controller, and booted the computer. In this way, we installed an image on each of the 50 machines we were adding to our network. The image consisted of four partitions: first, a small DOS-bootable partition, then one partition each for Win2K and NT 4.0. The final partition contained the Win2K and NT 4.0 disk-image files. Booting to MS-DOS lets us run the image software and rewrite either the Win2K or NT partitions with a virgin image.

This operation was time-consuming—two Lab Guys worked on it full time. We can only imagine the level of aggravation similar operations present to corporate rollouts of hundreds of machines. However, our experience taught us a valuable lesson that we should already have known: Just because you expect something to work right doesn't mean it will work right. Planning based on expectations is always a bad idea.