This document is part of Unattended, a Windows
deployment system.
To use Unattended to perform an automated installation of Windows, you need to:
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.
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:
unattend.txt
unattend.txt
instead of dialog
boxesThese 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.
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.
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.
(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:
unattend.txt
file here, its settings will
override the defaults. More advanced customization is possible; see
the advanced configuration document for
details.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.
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
.
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:
Z:\os\winxp
to
Z:\os\winxpsp2
. This name is not accurate yet, but it
will be in a few minutes.WindowsXP-KB835935-SP2-ENU.exe
.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.
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
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.
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.
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.
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.
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
.
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.
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.
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.
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.
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)
.
The installation script will offer to format the C:
drive. Answer "yes".
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.
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").
The script will ask you for the computer's name. Entering "*" will cause Windows Setup to pick a random name.
The script will ask you for the organization name and user name for this machine. Provide them.
The script will ask you for the local administrator password for the machine. This value will echo (sorry).
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.
If you choose not to join a domain, the system will offer to let you join a workgroup.
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.
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.