Skip to main content.

Integrate a service pack into the OS distribution point

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 and let the OS have a smaller footprint on the harddisk of your computer.

NOTE: You cannot do this with certain OEM versions of Windows XP (we are 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.

NOTE: On 2005-06-28, Microsoft published a rollup package for Windows 2000 SP4. Although it is possible to slipstream this package into Windows 2000 with Service Pack 4, we do not recommend it. The problem is that this package contains fixes for Internet Explorer 6 SP1 which is not included in Windows 2000 and installed after the Windows installation by Unattended. Windows update will demand that package again. For more information, see here (sorry, only in german).

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:\xpsp2. 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 SP 2 for Windows XP, you can do not need to extract the files from the service pack. Simply type:

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

Integrate other hotfixes

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.

Modifying the boot disk

DOS boot disks

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 we do it, because we 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 tftpbootdirectory. 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.

Linux boot disk (CD-ROM)

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.

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. For Linux you could use atftpd which also works fine, under debian for example, you can get it with "apt-get install atftpd". be sure that you edit your config (especially the tftproot) right!

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. But the basic idea is pretty simple: Configure your DHCP server to provide next-server and filename DHCP options (options number 066 and 067 under windows) 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.) Get the package and extract pxelinux.0 to your tftproot.

You can find a bit more info here: Setting up a server for PXE network booting

How it could look like, using DNSmasq (don't let the name fool you, it's a dhcp-server) and atfpd: Additional/modified lines for dnsmasq.conf: 

        dhcp-option=13,25 //Size of pxelinux.0 in bytes, divided by 512
        dhcp-option=66,192.168.0.20 // IP of the tftp-server
        dhcp-boot=pxelinux.0,ntinstall,192.168.0.20 // Bootfilename, dns & IP of the tftp-server
Line for atftpd @ inetd.conf: 
  tftp dgram   udp     wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 
--retry-timeout 5     --mcast-port 1758 --mcast-addr 192.168.0.0-255 --mcast-ttl 1 --maxthread 100 
--verbose=5  /home/christof/unattended-4.7/linuxboot/tftpboot

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.