This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Within the IT department imaging devices for end users is something that we’ve probably all had to do at some point, either manually or with an automation product such as Windows Deployment Services (WDS), Microsoft Deployment Toolkit (MDT) or System Centre Configuration Manager (SCCM).
There are a lot of moving parts to imaging devices using one of the tools mentioned above, and there can be a lot of pain points in the process. When you are trying to image a device you are usually trying to interact with it before the pre-installed Operating System (OS) launches or interact it when it doesn’t have an OS installed on it. And to do that we want to interact with the Preboot Execution Environment or PXE as its commonly referred to. And this is often the part that can cause a lot of pain.
The PXE environment in its simplest form is the process of having your device boot from its network card. For the device to boot into the PXE environment it needs to receive the relevant instructions. The most common way of trying to do this is to configure your Dynamic Host Configuration (DHCP) server to store and serve this information.
PXE Boot Process
Using your DHCP server to store and serve this information looks like this:
- The device sends out a DHCP broadcast and states that it needs to PXE boot (you’ve often initiated this request by hitting F12 on the device as it starts up)
- The DHCP server picks up this broadcast and replies with a suggested IP address to use. If the server has the information on how to PXE boot, that information is included in its reply
- The device then replies to the server and uses the provided address
- Then the device contacts the PXE boot server (traditional a WDS server or SCCM server) and requests the boot file (also known as the Network Boot Program (NBP)) that it was told to look for from the DHCP server
- The file is then loaded and launched on the client
Within your DHCP server, Option 66 or Option 67 are the ones that you set within your scope options with the required information. Option 66 specifies which server to contact and 67 is the name of the file to request. This method can work fine when your clients are on the same part of your network as your servers and if you are only utilising one type of device architecture.
However, when your devices are on another part of the network from your servers, or you have a mix of BIOS, UEFI, 32-bit, 64-bit, ARM devices, it all gets a bit messy.
Especially as each of those device types need a different boot file delivered to them and DHCP only allows you to specify one boot file. Over the years I’ve learnt the hard way that each device needs a specific boot file and I know colleagues that have also fallen foul to this issue as well.
IP Helpers
The ultimate answer and supported method is to use IP helpers. These are options that are specified within your networking equipment. Using IP helpers tells your device where to go for the boot file then your PXE/WDS/SCCM server dynamically delivers the correct boot file for the device architecture/firmware. Utilising the IP helper method also allows you to specify more than one server so you can build multiple within your environment, then if one is offline the device should just use the next available one rather than fail, so you have a loose “load balanced/redundancy” solution in place.
Network Administrator
My advice, if you are someone who is involved in building devices for your end users, is befriend your network administrator and ask them to configure the necessary IP helpers for you.
A little solution like this can save you a lot of time.
Happy device building!