Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

May 09, 2000 11:55 AM

Unattended Installs in a Perfect World

Windows IT Pro
InstantDoc ID #8722
Rating: (0)
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.

Related Content:

ARTICLE TOOLS

Comments
  • Rakesh
    8 years ago
    Jun 21, 2004

    My computer shows tftp failed after geting ip address from dhcp at ris istallation time

  • Jef
    9 years ago
    Apr 30, 2003

    To get started you can use Bart's network boot disk. This allows you to have a disk that can get on the network with several different NICs. For post install you can use Winbatch for the final touches.

  • Robin Pengilley
    10 years ago
    Jan 06, 2002

    Good article,

    I am a network manager for an educational establishment, and its easy to do, and NIC vendors give you the tools to do it.....I've done it with 4 batch files, fdisk.exe, format.exe and a win98 startup disk

  • Richard
    12 years ago
    Sep 21, 2000

    Be aware that some manufacturers no longer support DOS drivers for their NICs. In our case that caused a bit of a scramble for the QA Servers we Ghosted. We then created a FAT32 partition to contain the SysPrep'ed *.gho image, booted to DOS from floppy and then restored to the system partition. Naturally we added the SCSI drivers to the DOS boot floppy and made sure all the Hardware Raid was previously setup. But the recover time was great! 11 Minutes. Note: One can even dispense with a FAT32 partition, if you burn the *.gho image to a CD-ROM. Ghost let us "highly" compress the image to LT 650MB. -

  • Mark Minasi
    12 years ago
    Aug 08, 2000

    I don't know the answer to your question, but here's what you can do to find out: The next time you do a fresh reinstall of your system, start setting things up but stop at Outlook Express setup. Run Sysdiff to take a "before" picture. Then, install Outlook Express, set it up, and reboot. Next, run Sysdiff again to create a "differences" file. You can then examine that file for any Registry changes and create a regedit /s script to reproduce those settings.


    --­Mark Minasi

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.