This page contains a shortened version of all of my OS Deployment articles. As I add articles, I’ll update this page to include only the specific instructions outlined in each article. Consider this the short-hand version, and a work-in-progress.
Here’s how I finally got architecture auto-detection for Windows PE working – using two separate TFTP servers, though, so it’s far from ideal.
Start by cloning your tftpboot directory and configuration to a new TFTP server. Next, get a copy of syslinux-3.86 (while the syslinux website is apparently down, and has been for a few months, googling for syslinux-3.86.tar.bz2 should make it show up on a mirror somewhere). You’ll need a working gcc toolchain, and a relatively recent version of nasm. Unpack the syslinux source somewhere, copy tftpboot; change your DHCP server’s Option 67 to gpxelinux.0 instead of pxelinux.0.
This article assumes that you have already read and completed the instructions from my previous PXE-related posts. You might want to read them first.
Of all of the network boot stuff I’ve done, setting up Windows PE to PXE boot using non-Microsoft solutions was by far the most challenging. Most of the instructions I found online were either incomplete, or too specific to the user’s setup to be of much use. After a lot of trial and error (and much swearing), I finally have everything working the way it’s supposed to – although it’s a far cry away from being as flexible as I’d like.
You can find the files required to get Windows PE to PXE boot in winpe.wim included with the Windows Automated Installation Kit 2.0 (WAIK 2.0). You’ll also want to install the Microsoft Deployment Toolkit and all of its dependencies somewhere (preferably a Windows Server 2003 SP2 system, but it should run fine on XP or later). Luckily, WAIK is a dependency of MDT, so if you’re installing MDT somewhere, then you’ll also have a copy of WAIK 2.0.
This article assumes that you have already read and completed the instructions from my previous PXE-related posts. You might want to read them first.
Note: these instructions assume that you have setup a TFTP server using the instructions in my previous post. You might want to go read that first.
Configuring your DHCP server to support PXE booting is pretty straight-forward, especially for Microsoft DHCP servers. I’ll describe how to setup ISC DHCPD as well.
With either server, you need to add two options, typically referred to as the boot server and boot filename.
Two things are needed to get a system to PXE boot: a DHCP server and a TFTP server. This can be the same system, or it can be two separate systems. If you’re integrating a new TFTP server into an existing network that already has a DHCP server, it’s probably better if you keep the systems separate; otherwise, I’d recommend setting up a single Linux system with both the DHCP server and TFTP server.
At work, I’ve managed to wedge myself into a pretty wicked and useful niche: operating system deployments. The place I work is a multi-platform software development company, doing R&D in the healthcare software arena. In simpler terms, we make healthcare software that runs on Linux, Windows, Solaris, and OS X – so pretty much all of the major operating systems that I know of.
I started off with the company about 7 years ago in the software testing department, and one of the biggest hassles we had at the time was what we call staging. We’d get a new build of a product from the development team, and have to test it from installation through to migration to the next release. We found that, over time, our Windows installations on the test machines would get to the point where we’d be reporting bugs that upon investigation would turn out to be artifacts of a previous installation, so we started reinstalling the entire operating system from scratch every time we got a new build.
Now, here’s the situation: you’ve got a group of around 40 testers. Only a handful of them have any real IT experience, or any software background for that matter (myself included). We had no support from the IT group for many different reasons, not the least of which was because we demanded the freedom to do anything we needed to do with the test equipment. So, inevitably, any time a new build showed up, we’d fumble around, looking for the right OS media, and – in the case of Windows – a valid license key that we could use to reinstall the OS.
Needless to say, this was a major hassle.