This document is part of Unattended, a Windows deployment system.


Overview

To use Unattended to perform an automated installation of Windows, you need to:

  1. Understand what you are really doing
  2. Make sure your network infrastructure is sufficient
  3. Create the OS distribution point
  4. Create the DOS network boot disk
  5. Boot from it, answer a bunch of questions, and go get a snack while the OS installs itself

If you are installing multiple systems, you will probably get tired of answering the same questions over and over. You can customize this process for your site to avoid as many questions as you like; this is described in the advanced configuration document.

Understanding the goal: unattend.txt

Windows Setup is the program which installs Windows on a new computer. To do this, it needs to ask lots of questions: What is your name? What is your product key? What is your time zone? And so on.

When you install Windows by hand, Windows Setup will stop and put up a dialog box for every question to which it needs an answer.

To perform an unattended installation, we need to provide an "answer file" with pre-recorded answers to all of the questions. The traditional name for this file is unattend.txt, and its creation is our main goal. Another way of describing the overall unattended installation process is:

  1. Obtain access to the OS installation media
  2. Obtain access to the destination hard drive
  3. Generate unattend.txt
  4. Run Windows Setup with appropriate switches to make it get answers from unattend.txt instead of dialog boxes

These are the steps which Unattended automates. It uses DOS to provide access to the OS installation media and hard drive; it uses a Perl script to create the unattend.txt file; and it knows how to invoke Windows Setup appropriately.

You do not need to understand the contents of unattend.txt to use Unattended, but you should learn about it eventually anyway. See the advanced configuration document for information and references.

Make sure your network infrastructure is sufficient

Unattended is designed to run mostly, or entirely, off of the network.

You will need a DHCP server, because that is how the boot disk obtains an IP address, WINS server, and default gateway. Any reasonable network already has a DHCP server; if yours does not, I suggest you get one. (Yes, you could modify the system.ini and protocol.ini files on the boot disk to have a fully static IP configuration, but you do not want to.)

You do not need administrative access to the DHCP server, as long as it already provides the necessary information to the machine you are installing.

You will need a Windows file server (or a Unix box running Samba).

Initiating an installation by booting directly from the network (optional) requires some more infrastructure; namely, a TFTP server and the ability to configure the DHCP server itself. See below for details.

Create the OS distribution point

In principle, the OS distribution point could be a CD-ROM or a local disk directory, but we are going to use a network share.

Create the install share (Z: drive)

(You have downloaded the Unattended distribution already, right? If not, now would be a good time.)

Copy the install directory tree from the Unattended distribution to the file server, and export it read-only with guest access permitted. When you later boot from the boot disk, it will ask you for the full Windows UNC name of this share; the default it assumes is \\ntinstall\install. The boot disk maps this share as the Z: drive, and that is how we will refer to it from now on.

This procedure relies on the following files and directories from the Z: drive:

djgpp
Contains parts of DJGPP, a collection of Unix tools for DOS. DJGPP is required because the master installation script is written in Perl. This one is too big to bundle, so you will need to download it yourself; see below for instructions.
dosbin
Directory containing DOS utility programs (like fdisk) from the FreeDOS project. Also contains install.pl, the master installation script.
lib
Directory containing helper files for the master installation script. This includes the default unattend.txt file and the helper modules Unattend::FoldHash, Unattend::Promise, Unattend::IniFile, and Unattend::WinMedia.
site
Directory containing your site-specific customizations. If you place an unattend.txt file here, its settings will override the defaults. More advanced customization is possible; see the advanced configuration document for details.
os
Directory containing Windows installation media (i.e., copies of the CD-ROMs). You need to populate this with one or more copies of Windows; see below.

Download DJGPP

DJGPP is a port of the Unix environment to DOS. You will need to download the following components:

Simply unzip all of them under Z:\djgpp.

Unix users please note: Use the -L switch to unzip when you extract these. Otherwise, you may find that some files extract under bin while others extract under BIN, and this will cause all sorts of trouble when the system tries to access them from DOS. Windows users do not need to worry about this, because Windows (like DOS) is not case-sensitive.

Copy the Windows CD-ROM to the share

Create a subdirectory under Z:\os to hold a copy of your Windows CD. You should probably give the directory a meaningful name like winxp or win2ksp4, and you probably want to limit the name to eight characters lest it look strange when viewed from DOS. (The name does not matter much because install.pl will scan the contents to figure out what it is. However, you should limit the name to 8 characters or fewer, especially if you are using the Linux-based boot disk.)

Next, copy the i386 folder from your Windows CD-ROM to the new directory. For example, for Windows XP, you would copy the i386 folder to Z:\os\winxp, thus creating Z:\os\winxp\i386.

Integrate the service pack (optional)

This step is optional; you can apply a service pack just like you apply any other hotfix later. But combining the service pack into the distribution point now will make installation faster.

NOTE: You cannot do this with certain OEM versions of Windows XP (I am unsure about Windows 2000). The process will appear to work, but after the first reboot the installer will abort saying, "The file vga.sys is corrupted". For an OEM installation of XP, your only option is to apply the service pack after installing the OS; see the winxp-updates.bat script and the application installation document for more information.

If you are using a retail or volume-licensed OS, read on.

To apply the service pack to the installation point, use the "slipstreaming" feature. You can find details in Microsoft's Windows 2000 Service Pack 4 Installation and Deployment Guide or Windows XP Service Pack 1 Installation and Deployment Guide.

The procedure is the same for Windows 2000 and XP. Using Windows XP Service Pack 2 as an example:

  1. Copy or rename Z:\os\winxp to Z:\os\winxpsp2. This name is not accurate yet, but it will be in a few minutes.
  2. Download the service pack (network installation) from Microsoft. This will be a package file, say WindowsXP-KB835935-SP2-ENU.exe.
  3. Run
        WindowsXP-KB835935-SP2-ENU.exe /u /x:c:\xpsp2
    

    This will extract the service pack files to the folder c:\xpsp1. Any folder will do.

  4. Run
        c:\xpsp2\i386\update\update.exe /s:Z:\os\winxpsp2
    

    This applies the service pack to the distribution point Z:\winxpsp2, creating an integrated ("slipstreamed") WinXP SP2 tree. Due to a bug, you must be a local administrator for this command to work, even if you have write access to the target folder. Also, you must be running XP to use the XP service pack installer.

Starting with SP2 for WindowsXP, you can do not need to extract the files from the service pack. Simply type

    WindowsXP-KB835935-SP2-ENU.exe -s:c:\os\winxpsp2

Integrate other hotfixes (very optional)

Ever since Microsoft introduced slipstreaming for service packs, people have asked if they could do the same thing with hotfixes. And until mid-2003, the official answer from Microsoft was no.

Times have changed. Microsoft now documents how to integrate hotfixes into Windows 2000 and into Windows XP. (See also KB articles 814847, 824994, and especially 828930.) It is a messy procedure, but it is supported.

Since the procedure is messy, and since Unattended was written before it existed, we expect to install hotfixes after the OS installation has completed. This works fine and is much cleaner. However, it does leave the system temporarily vulnerable to any exploits which the hotfixes correct. So if you are installing on an insecure network, you may need to integrate certain hotfixes directly into the OS distribution point. In particular, you probably want the fixes for the remotely-exploitable flaws. As of April 2004, they are 828741, 828035, 828749 (2000 only), and 835732.

See this message from the mailing list for one user's experience.

Add device drivers

This step may be optional, depending on your hardware and which version of Windows you are trying to install. Each release of Windows ships with a fairly rich collection of drivers, supporting most of the hardware which was current at the time. However, if you are installing an older OS on a recent system, especially a laptop, you may find that the OS lacks built-in support for some or all of your hardware.

You can add device drivers after the OS is installed, of course. But if you want to automate both OS and application installation, and your version of Windows lacks built-in support for your network card, you will need to provide proper network drivers on the OS distribution point. Here is how to do it.

First, download the driver package from the hardware vendor and expand it. There should be a collection of .inf files in the top-level directory; that is the directory you need to copy to the OS distribution point.

To where should you copy it, exactly? That is a long story...

Under the i386 folder on the distribution point, create a folder named $oem$. Under that folder, create a folder named $1. Yes, really. Windows Setup will copy everything below the $1 folder to the %SystemDrive% (normally C:) during installation. See Microsoft's description of the distribution share for the gory details.

You may put your driver folder anywhere you like under the $1 folder, and you may add as many driver folders as you like. The install.pl script will automatically scan for all driver folders and offer to add them to the OemPnPDriversPath setting in the unattend.txt file for you.

NOTE: The total absolute length of any file name, including the leading \os\...\$oem$ portion, must not exceed 64 characters or winnt.exe will get an error when it tries to copy the file.

Create the bootdisk

The goal here is very simple: To boot to DOS so we can mount the install share as the Z: drive and run the master installation script. There are three ways to do this: By booting from a floppy, by booting from a CD-ROM, or by booting directly from the network.

The bootdisk directory from the Unattended distribution holds all of the disk images and the tools needed to re-create them.

Booting from a floppy

The images subdirectory has one compressed 1.44M floppy disk image for each supported network driver. For example, e100b.imz is the floppy image with support for the Intel Pro/100 family of network cards. The DRIVERS.txt file lists all of the supported drivers. The driver names are a little weird because each is derived from the corresponding DOS network driver filename; you may as well get used to them in case you ever find yourself creating a DOS networking disk from scratch.

You need to select the floppy image with the right DOS driver for your network card. If you are not sure which driver is right, you may need to try them all. (But see below about booting directly from the network, for which this is not an issue.)

Once you have chosen the correct floppy image, you will need to write it to a floppy. How you do this depends on your operating system.

For Linux, a command like "zcat images/e100b.imz | dd of=/dev/fd0" will do the trick.

For Windows, you will need to obtain a utility for writing images to floppy disks. One option is rawwritewin, which is free, although you will have to unzip the floppy image first. WinImage is prettier and has more features (e.g., it can handle compressed images directly), but it is shareware.

Booting from CD-ROM

This section is optional; you can kick off the installation process just using a floppy. But a CD-ROM is faster, and all of the floppy images fit on a single piece of media.

The bootdisk.iso file is an ISO-9660 image of a bootable CD-ROM. Simply burn it to a CD, which you can do with just about any CD recording utility. Consult your utility's documentation and search for ISO-9660 or just ISO.

Booting from the network

This section is also optional, although "nothing but net" installs are my favorite. Walking into a coworker's office and rebuilding their machine using nothing more than your hands and your brain is pretty fun. Also, when you boot from the network, you do not need to select any network driver for your card! 3com has kindly written a "universal" DOS network driver which works on any PXE implementation, meaning one floppy image can support any PXE-compatible network card. (This also means that any newly-released network card is more likely to work with DOS than with any other operating system, including Windows or Linux. I find this mildly amusing.)

However, booting from the network does require the most support from your infrastructure.

First, you will need a TFTP server. Copy the files and folders from the tftpboot directory to the TFTP server's root directory. Tftpd32 is a good TFTP server for Windows which has been reported to work.

Second, you will need to configure your DHCP server. Most modern network cards support booting directly from the network following Intel's Preboot eXecution Environment (PXE) specification. If you are a masochist, you can obtain the entire PXE specification from Intel's WFM site. But the basic idea is pretty simple: Configure your DHCP server to provide next-server and filename DHCP options identifying your TFTP server and the pxelinux.0 file, respectively. (Do not let the name fool you; pxelinux.0 has nothing to do with Linux. It comes from the SYSLINUX package, an excellent general-purpose boot loader.)

Finally, you will need to convince your machine to boot from the network. Even if your machine has PXE support, actually enabling it can take some work. Many network cards have a configuration BIOS of their own which you must access to enable booting via PXE. For motherboards with integrated network hardware, the system BIOS itself may have a configuration option named "Enable on-board network" with three settings called something like "Off", "On", and "On w/ MBA".

NOTE: Historically (meaning as recently as 2002), many vendors' PXE implementations were extremely buggy. Always update the firmware on your network card to the latest version before attempting a network boot. For network hardware integrated on the motherboard, this means updating the system BIOS.

Once you have enabled PXE in the network card BIOS, reboot the machine and enter the system BIOS again. Examine the "boot order" option. There should be a new entry, with a name like "MBA slot 1" or "IBA slot 3". Note that many BIOSes have a "Network" entry here which does not work; you may need to experiment. Configure the boot order to put the network device ahead of the hard disk, and you should be good to go.

Some systems, including most Dells and IBM Thinkpads, will respond to F12 during power-up to let you initiate a network boot. This is convenient if you only want to boot from the network once or twice to install the OS, but you want all later boots to be from the hard drive.

If all else fails, contact your vendor and ask them how to perform a PXE network boot. If they say you cannot, shake your head in disgust and boot from floppy or CD-ROM instead.

Modifying the boot disk

This section is definitely optional. If it makes no sense to you, feel free to skip it.

The boot disk is just a DOS floppy, so you can edit its files like those on any other floppy. But that is not how I do it, because I want to generate new floppy images for every driver, not to mention new ISO and PXE images.

Modifying the boot disk "correctly" requires a Unix system with the appropriate utilities installed. Basic utilities like GNU Make go without saying. To create the floppy disk images, you will also need the Mtools suite. To update the ISO image, you will need the mkisofs utility. Modern Linux systems generally provide all of the required tools.

In the bootdisk directory, typing make images will generate the floppy disk images. Typing make iso will create the ISO image. Typing make tftpboot will populate the tftpboot directory. And simply typing make will do all these.

The DRIVERS.txt file defines the supported network drivers and the drivers subdirectory contains them. To add a new driver, put it in the drivers directory, update DRIVERS.txt, and type make.

The template subdirectory contains the files on the boot disk itself. For example, if you want to change autoexec.bat or config.sys, just edit them under template and run make.

For the record, most of the binaries on the bootdisk are from Microsoft's MSCLIENT distribution. The exceptions are random.com and nset.com, very handy utilities from Horst Schaeffer's nice collection.

The CD-ROM boot loader is ISOLINUX from the SYSLINUX package. We use memdisk, also from SYSLINUX, to allow us to chain-boot to a "virtual floppy".

The PXE boot loader is PXELINUX, also from the SYSLINUX package. It also uses memdisk to boot from a virtual floppy, this time directly over the network. The universal DOS network driver is undis3c.dos from 3com's MBA Utility disk.

Boot from the boot disk

The boot disk's entire purpose in life is to obtain access to the network, then hand off control to the more powerful tools available there. Specifically, the boot disk loads the network drivers, mounts the install share as the Z: drive, and then executes the Perl script Z:\dosbin\install.pl. This script will ask you a bunch of questions, generate unattend.txt, and launch Windows Setup.

Follow along in autoexec.bat if you like.

Mounting Z:

After loading the network stack, the boot disk asks whether you want to Override bootdisk defaults for user name, password, and install share. The defaults are guest, guest, and \\ntinstall\install, respectively.

Next, the boot disk uses the user name and password to invoke NET LOGON, which initializes the MSCLIENT file sharing stack.

Next, the boot disk invokes NET USE to map the install share as the Z: drive.

Finally, the boot disk passes control to the installation script Z:\dosbin\install.pl. This script is a lot more complicated, but you do not need to understand it in order to use it.

Partitioning

The installation script begins by helping you partition the hard drive.

This can be complicated for two reasons. First, any change to the partition table requires rebooting the system. Second, DOS cannot access NTFS partitions, but NTFS is almost certainly the file system you want to use.

The installation script hides this complexity from you by offering a simple menu of several automated partitioning schemes. If none of the automated schemes appeals to you, one of the menu options is to run fdisk interactively to let you partition by hand.

Whether you pick an automated scheme or partition by hand, you need to make sure that the C: drive is an active 2G FAT partition. The automatic choices do this by first creating the NTFS partitions, then deleting the first one and replacing it with a 2G FAT partition, then activating it. (If you choose to partition by hand, you will need to perform this procedure by hand.)

If any actual changes are made to the partition table, the script will reboot the machine so that 2G FAT partition will become the C: drive, which is where Windows will be installed. During OS installation, Windows Setup will convert the FAT partition to NTFS and expand it as far as possible without clobbering other partitions.

Note that the OS is always installed on the first active partition of the drive. If this is a problem for you, let me know and maybe I will change it in a future release.

After rebooting, the installation script will again start by offering to partition the drive. Simply choose the same partitioning scheme again, and the script will notice that the partition table is unchanged and continue. Or you can manually select the menu option to Do nothing (continue).

Formatting

The installation script will offer to format the C: drive. Answer "yes".

Choosing the operating system

The installation script will ask you which operating system you want to install. It derives the list of choices from scanning the directories under Z:\os looking for Windows media. To add a new operating system to the list, simply create its distribution point.

Product key

The installation script will ask you for your 25-character product key. Enter it exactly as it appears on your software license, with a dash between every block of five characters (like "12345-6789A-BCDEF-GHIJK-LMNOP").

Computer name

The script will ask you for the computer's name. Entering "*" will cause Windows Setup to pick a random name.

Organization and User name

The script will ask you for the organization name and user name for this machine. Provide them.

Local Administrator password

The script will ask you for the local administrator password for the machine. This value will echo (sorry).

Joining a domain

The script will ask to what domain you wish to join the system. If you do not want to join the system to a domain during OS installation, just press Enter.

If you do provide a domain, the script will ask you for an account name and password to use to join the system to the domain. You may use a fully qualified domain\user name, or just the user name. The password will echo (sorry again).

Also, if you provide a domain, the script will ask you for a list of domain accounts to add to the local Administrators group. Many organizations add the machine's "owner" to the local Administrators group. If you do not wish to add any extra users to the Administrators group, just press Enter.

Joining a workgroup

If you choose not to join a domain, the system will offer to let you join a workgroup.

Choosing the application suite

Next, the installation script will ask you which script to run, if any, after the OS installation is finished. This is the hook to start the automated application installation process. The scripts live in the Z:\scripts directory, and are discussed on the application installation page.

Final edits

Finally, the installation script will generate the unattend.txt, postinst.bat, and doit.bat scripts, and offer to let you edit them. This is your chance to make any manual alterations to the scripts before the installation begins.

The unattend.txt file is described above. The postinst.bat script runs when OS installation is finished, unless you edit the default GuiRunOnce section in unattend.txt. The doit.bat script runs when you select "Continue"; it is a one-liner which fires off the unattended Windows Setup process.

When you have finished making your changes, if any, select the "Continue" option.

And that is all! Your OS installation should be on its way. You probably want to automate installing the applications next.

If you get tired of answering all these questions (or editing unattend.txt) by hand, you can create a site configuration to provide as many of the answers as you like. See the advanced configuration page for details.


Patrick J. LoPresti patl@users.sourceforge.net