Good day, dear Habr residents!
The purpose of this article is to provide a brief overview of the capabilities for deploying various systems through WDS (Windows Deployment Services)
The article will include short instructions for deploying Windows 7 x64, Windows XP x86, Ubuntu x64 and adding useful tools like Memtest and Gparted to network boot.
The story will unfold in the order of ideas that come to mind. It all started with Microsoft...
And now the actual story:
Not long ago, I had a sensible idea to deploy systems at work using WDS. If someone else does the work for us, it's nice. And if we learn something new in the process, that's even better. I won't go into too much detail about installing the WDS role — Microsoft simplifies it to Next-Next-Next and there are plenty of articles on this topic. I'll briefly discuss working with Windows images, focusing on the moments that caused me difficulties. The non-Microsoft systems will be described in more detail (which is the reason for writing this article).
Let's get started.
The server acting as the image repository and action coordinator runs Windows Server 2008 R2. For this service to work correctly, roles such as DHCP and DNS are required. And AD — for adding machines to the domain. (These roles do not necessarily have to reside on one machine; they can be spread across the entire infrastructure. The key is that they work correctly.)
1. Configuring WDS
We add the necessary roles and quickly dive into the WDS console, initialize our server and see the following:
- Install Images — installation images. Configured, beautiful systems that we will be deploying. For convenience, we can add several groups based on system types: Windows 7, XP, or by task types — IT Dept, Client Dept, Servers.
- Boot Images — boot images. What loads onto the machine first and allows various actions. The very first image here is the one found on the installation disk (for Windows 7 — this is the sources folder and the files install.wim or boot.wim.
And from there, we can do all sorts of interesting things:- Capture Image or Record Image — our main tool, allows us to make a copy of a configured system that has been previously processed with sysprep and serves as our template.
- Discovery Image — allows you to upload images of configured systems to computers that do not support network booting.
- Pending Devices — devices waiting for administrator approval for installation. We want to know who is installing our beauty on their computer.
- Multicast Transmissions — multicast distribution. Used for installing a single image to a large number of clients.
- Drivers — drivers. Help add necessary drivers to the server images and avoid similar errors:
After adding drivers to the WDS server, they need to be added to the desired boot image.
Yes, and also — for each system architecture, separate boot loaders and installers need to be created. Variety in the zoo comes at a cost.
Essentially, our WDS is already ready. We can boot over the network from the machine and see a selection window with our boot images.
I won’t describe all the steps to prepare the perfect image, just leaving a link to the article on which I based it: (for some reason I had an old version of WAIK installed — 6.1.7100.0, it was not possible to create the answer file for Windows 7 SP1. The latest one currently is — 6.1.7600.16385)
And here instructions for preparing Windows XP for WDS. We won’t go into details — the most interesting is in the second part!
2. Universal Boot Loader
It’s great that we now have such a system. Using it is a pleasure. But can’t we make our life even easier?
I want to install Linux through it!
First of all, as many of you remember — installing Windows and Ubuntu in parallel does not end well for the Windows boot loader. It gets overridden by the universal GRUB.
It’s the same here. We need a universal boot loader, meet — it’s
1) Download the latest version (at the time of writing this article it’s
We are interested in these files:
corepxelinux.0
com32menuvesamenu.c32 (you can use menu.c32 for a text interface during boot)
com32chainchain.c32
In all guides for using this boot loader, they say it works with these three files. I had to add ldlinux.c32, libcom.c32, and libutil_com.c32 as well. You can do it this way — copy the recommended ones and run. If it complains about a file — copy that one to the folder.
We also need the memdisk file for loading the iso. Let’s put it in this folder.
2) Place them in the folder where all your WDS images are stored. Specifically here — RemoteInstallBootx64 (we will only be installing 64, for 86 place the same files in that folder as well.)
3) Rename pxelinux.0 to pxelinux.com
4) Let's create a folder pxelinux.cfg for the configuration file and the file itself (of course, inside this folder) — default (without extension!) with the following content:
DEFAULT vesamenu.c32
PROMPT 0
NOESCAPE 0
ALLOWOPTIONS 0
# Timeout in units of 1/10 s
TIMEOUT 300
MENU MARGIN 10
MENU ROWS 16
MENU TABMSGROW 21
MENU TIMEOUTROW 26
MENU COLOR BORDER 30;44 #20ffffff #00000000 none
MENU COLOR SCROLLBAR 30;44 #20ffffff #00000000 none
MENU COLOR TITLE 0 #ffffffff #00000000 none
MENU COLOR SEL 30;47 #40000000 #20ffffff
MENU BACKGROUND pxelinux.cfg/picture.jpg #picture 640×480 for background
MENU TITLE Choose your destiny!LABEL wds
MENU LABEL Windows Deployment Services (7, XP, Boot images)
KERNEL pxeboot.0LABEL local
MENU DEFAULT
MENU LABEL Boot from Harddisk
LOCALBOOT 0
Type 0x80
5) Make a copy of the file pxeboot.n12 and name it pxeboot.0
6) After that, we need to teach our WDS to boot specifically with the universal loader. In 2008, this was done through the GUI, in 2008 R2 — through the command line. Open it and enter:
- wdsutil /set-server /bootprogram:bootx64pxelinux.com /architecture:x64
- wdsutil /set-server /N12bootprogram:bootx64pxelinux.com /architecture:x64
Command line output:
That's it, let's boot and see the desired screen:
This is the basic config, it can be adjusted to your requirements (company logo, boot order, etc. For now, it can only transfer control to WDS and boot again from the hard disk. Let's teach it to boot Ubuntu!
3. Teaching the eaglet to fly
What did we need there? Ubuntu, Gparted? Let's add memtest for good measure.
Let's start with the simplest:
Memtest
Create a separate folder for Linux files in the Boot/x64 WDS, for example, Distr. And subfolders in it for our respective systems:
Download and add the following lines to our boot config (default file):
label MemTest
menu label MemTest86+
Kernel memdisk iso raw
initrd Linux/mt420.iso
This will load our small image into memory and run from there. Unfortunately, that didn't work for me with larger images.
Gparted
Download , extract the iso image and take three files — /live/vmlinuz, /live/initrd.img, and /live/filesystem.squashfs
What are these files? (I may be mistaken in the terminology, I kindly ask readers to correct me if I'm wrong)
- vmlinuz (you might also see it as vmlinux) — compressed kernel file
- initrd.img — image of the root filesystem (minimum necessary for booting)
- filesystem.squashfs — the actual files used during operation
We place the first two files in the upload folder (in my case, this is Bootx64DistrGparted) and the third one on the IIS server (fortunately, it’s already set up for WSUS).
A lyrical digression — unfortunately, I couldn’t get the method of loading the ISO image into memdisk with large distributions to work. If you happen to know the secret to success — that would be a great solution, allowing for quick booting of any system from an ISO image.
We add filesystem.squashfs on IIS so it can be read over the network (don’t forget to add the MIME type for this extension).
Now we add a record to our pxelinux.cfg/default:
LABEL GParted Live
MENU LABEL GParted Live
KERNEL Distr/Gparted/vmlinuz
APPEND initrd=Distr/Gparted/initrg.img boot=live config union=aufs noswap nopromt vga=788 fetch=http://192.168.10.10/Distr/Gparted/filesystem.squashfs
We check — it works!
Ubuntu 12.04
I added two possible installation options — fully automated (thanks to user for and manual mode)
We download the file with alternate installation and extract two files from it (as before) — initrd.gz and linux, and place them in Distr/Ubuntu.
We add the following lines to our pxelinux.cfg/default:
for fully manual installation
LABEL Ubuntu
KERNEL Distr/Ubuntu/linux
APPEND priority=low vga=normal initrd=Distr/Ubuntu/initrd.gz
For automated installation, we need a file with response settings (you can read about it ) and we'll place it on our web server. My line in the bootloader looks like this:
LABEL Ubuntu Auto Install
KERNEL Distr/Ubuntu/linux
APPEND initrd=Distr/Ubuntu/initrd.gz ksdevice=eth0 locale=ru_RU.UTF-8 console-setup/layoutcode=ru url=http://192.168.10.10/Distr/Ubuntu/preseed.txt
Future utility
While reviewing material on the topic and seeking answers to my questions, I discovered a from describing how to boot Kaspersky Rescue Disk over the network. Unfortunately, it didn’t work for me. But the tool is indeed useful (sometimes, overly zealous users might grab something unusual… It’s handy to have such a tool at hand).
Conclusion
This article provides an overview of the capabilities offered by the WDS role from Microsoft. When I started writing this article, the plans were grand: a detailed HOWTO on all aspects of booting the systems mentioned above... But as I started accumulating material specifically on WDS, the narrative led me into some depths that probably no one will encounter... Therefore, I decided to share brief information about what is possible, along with links to good articles. If readers are interested or if I suddenly desire fame and money to add to my Khabrahabr contributions with more articles, I can delve deeper into each stage of configuring a multi-purpose WDS server.
I would like to thank the authors again and for their material, which will be interesting to everyone without exception.
Naturally, there have already been articles on this topic on Khabr, I tried to shed light on the issue from a different perspective or to complement it: and
Thank you for your attention.
Glory to the robots!
Source: habr.com
