Info2soft use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
Windows Deployment Services (WDS) handles network-based OS deployment, but its default PXE setup only supports Windows installation images.
Adding Syslinux as an intermediary bootloader lets you extend the same infrastructure to deploy Linux, with IIS serving Ubuntu installation files over HTTP. BIOS and UEFI clients need separate configurations, but both can be managed from a single WDS server.
Yes — but not out of the box. WDS is a Windows Server role built for network-based Windows deployment, and its default PXE workflow only supports Windows boot images. To deploy Linux through WDS, you need to configure an intermediary bootloader.
Common reasons to extend WDS this way include:
The most common approach uses three components together:
At boot time, the PXE client contacts WDS, which delivers Syslinux as the network boot program. Syslinux then displays a menu where the user can select Windows or Linux. Selecting Linux loads the Ubuntu kernel and initrd directly; selecting Windows chainloads back to the standard WDS workflow.
Before configuring Linux deployment, verify that the following components are in place: a working WDS installation, a reachable DHCP server, a web server to host installation files, and a compatible Ubuntu ISO.
| Component | Requirement | Purpose |
|---|---|---|
| Windows Server | 2016, 2019, 2022, or 2025 | Hosts the WDS role and PXE boot services |
| WDS | Installed and configured | Provides the initial network boot workflow |
| DHCP | Reachable from client network | Assigns IP addresses and directs clients to the TFTP server |
| IIS or equivalent | HTTP access from client network | Hosts the Ubuntu kernel, initrd, and installation files |
| Syslinux | Version matched to target firmware | Provides the Linux boot menu and kernel-loading functions |
| Ubuntu Server ISO | 22.04 LTS or 24.04 LTS | Supplies the Linux installer and installation files |
PXE clients need to reach both the DHCP server and the WDS server during startup. If clients and the server are on different subnets, DHCP relay or IP Helper configuration is required. Client firmware also affects which Syslinux files are needed — legacy BIOS and UEFI clients require different boot executables, and UEFI systems with Secure Boot enabled may need additional compatibility checks.
Extract the Ubuntu ISO contents to a directory on the web server before starting the WDS configuration — for example, E:\web\ubuntu\24.04\. Verify that PXE clients can reach those files over HTTP before proceeding, as a working WDS PXE boot does not guarantee that the Linux installer can reach its separate installation source.
Complete these three steps before introducing Syslinux or any Linux configuration. The goal is a working WDS environment with a verified Windows PXE boot as the baseline.
WDS handles the PXE boot workflow; IIS hosts the Ubuntu installation files over HTTP. Install both roles in a single PowerShell command:
Install-WindowsFeature -Name WDS,Web-Server -IncludeManagementTools
To confirm the installation, run:
Get-WindowsFeature -Name WDS,Web-Server
Both roles should show Installed in the Install State column.
Before changing any boot files, confirm that PXE clients can reach both the DHCP server and WDS.
69), and PXE traffic. Note that TFTP uses dynamically negotiated transfer ports after the initial request, so allowing port 69 alone may not be sufficient.At this stage, a test client should be able to reach WDS and begin the Windows PXE workflow.
Step 1. Open Server Manager, select Tools, and launch Windows Deployment Services. Right-click the server and select Configure Server. Follow the wizard to set the RemoteInstall directory (for example, D:\RemoteInstall), configure Active Directory integration if required, and set the PXE response policy.
Step 2. In the WDS console, right-click Boot Images and select Add Boot Image. Browse to the Windows installation media and select boot.wim. Complete the wizard and confirm the image appears under Boot Images.
Step 3. Boot a test machine from the network and verify that it reaches the WDS boot menu and loads the Windows deployment environment successfully.
Resolve any Windows PXE issues before proceeding. Introducing Syslinux into an unverified WDS configuration makes troubleshooting significantly harder.
Syslinux provides the boot menu and Linux kernel-loading functions that WDS cannot handle natively. The required files depend on the target firmware — select and verify them before changing any WDS settings.
Use a Syslinux 4.x PXELINUX package. The three files needed for this configuration are:
pxelinux.0 — starts PXELINUX over the networkvesamenu.c32 — provides the graphical boot menuchain.c32 — handles chainloading back to the WDS Windows boot pathAll files should come from the same Syslinux release. Do not mix files from different versions.
UEFI network boot requires an EFI executable compatible with the client firmware architecture. Syslinux 6.x includes EFI components, but UEFI support varies by build, architecture, and firmware implementation. Relevant files may include syslinux.efi, ldlinux.c32, libutil.c32, and libmenu.c32, depending on the package.
Verify the actual package contents, module dependencies, and config file paths for the target hardware. Also check Secure Boot status — an EFI executable that works with Secure Boot disabled may not load when it is enabled.
Step 1. Copy the verified Syslinux BIOS files into the WDS architecture directories. Assuming the RemoteInstall path is D:\RemoteInstall:
D:\RemoteInstall\Boot\x86\D:\RemoteInstall\Boot\x64\Back up the original WDS boot files before making any changes.
Step 2. Rename the following files in the target directories:
pxelinux.0 → pxelinux.compxeboot.n12 → pxeboot.0abortpxe.com → abortpxe.0Step 3. Point WDS to Syslinux for BIOS clients. Run the following from an elevated Command Prompt:
wdsutil /Set-Server /BootProgram:Boot\x86\pxelinux.com /Architecture:x86
wdsutil /Set-Server /BootProgram:Boot\x64\pxelinux.com /Architecture:x64
Step 4. For UEFI clients, do not substitute /Architecture:x64UEFI into the commands above — that is not a valid parameter for wdsutil /Set-Server /BootProgram. UEFI boot file assignment depends on the WDS version and network infrastructure. Verify how the target environment selects EFI boot executables, and confirm the following before enabling UEFI clients:
Test BIOS and UEFI clients separately — a successful BIOS PXE boot does not confirm that the UEFI path works.
After configuring Syslinux, create a PXE boot menu with entries for Windows deployment, Ubuntu installation, and local disk startup. Set up the menu structure and verify Windows chainloading before adding any Linux entries.
pxelinux.cfg Directory and Default Config FileStep 1. Under the PXELINUX boot directory, create a folder named pxelinux.cfg and a file named default inside it (no file extension). For example:
D:\RemoteInstall\Boot\x64\pxelinux.cfg\default
Verify the actual config lookup path for your Syslinux version — not all builds search the same directory when loaded through WDS.
Step 2. Add the following starting configuration to the default file:
DEFAULT menu.c32
PROMPT 0
TIMEOUT 100
ONTIMEOUT local
MENU TITLE Network Boot Menu
LABEL local
MENU LABEL Boot from local disk
LOCALBOOT 0
LABEL abort
MENU LABEL Abort PXE boot
LOCALBOOT -1
TIMEOUT is in tenths of a second, so 100 gives the user 10 seconds before the default entry runs. Copy menu.c32 and its dependencies from the same Syslinux package if you use this configuration.
vesamenu.c32. This example uses menu.c32. Use whichever module you actually have, and keep the config consistent with that choice.Step 1. Add a Windows entry to the default file:
LABEL windows
MENU LABEL Windows Deployment Services
KERNEL chain.c32
APPEND pxeboot.0
Step 2. Confirm that chain.c32 and pxeboot.0 exist at the paths the configuration expects. If the files are in different directories, adjust the paths accordingly.
Step 3. Boot a test BIOS client and verify that the Syslinux menu appears. Select Windows Deployment Services and confirm the client completes the full chainload back to WDS and loads the Windows boot image successfully.
Do not add the Ubuntu entry until this test passes. A menu that displays correctly is not enough — the Windows return path needs to work end to end before introducing Linux configuration.
Once the Syslinux menu and Windows chainloading path work, add Ubuntu as a separate boot option. This involves hosting the Ubuntu installation files over HTTP, referencing the correct kernel and initrd in the PXE menu, and verifying that the installer can reach its installation source from the client network.
Step 1. Create a directory for the Ubuntu release on the web server. For example:
E:\web\ubuntu\24.04\
Use a separate directory for each Ubuntu release to avoid mixing files.
Step 2. In IIS Manager, create a virtual directory or website pointing to the folder above. To enable directory browsing for testing, select the site, open Directory Browsing, and click Enable in the Actions pane.
Step 3. Confirm the HTTP URL for the directory — for example:
http://wds-server/ubuntu/24.04/
From a client on the PXE subnet, verify that the URL is reachable. If it is not, check IIS permissions, firewall rules, and DNS or hostname resolution before proceeding.
Step 1. Right-click the Ubuntu Server ISO in Windows Explorer and select Mount. Copy the ISO contents into the IIS directory, for example E:\web\ubuntu\24.04\.
Step 2. Locate vmlinuz and initrd in the extracted files. Their paths vary by Ubuntu release — use the files from the ISO you are deploying, and reference the correct paths in the menu entry.
Step 3. Add the Ubuntu entry to the pxelinux.cfg\default file. Ubuntu Server 22.04 and 24.04 use the Subiquity installer — do not reuse older Debian Installer parameters such as preseed/url, as they are not compatible with these releases.
The example below assumes the kernel and initrd are served over TFTP and IIS hosts the Ubuntu Server ISO:
LABEL ubuntu2404
MENU LABEL Install Ubuntu Server 24.04
KERNEL ubuntu2404/vmlinuz
INITRD ubuntu2404/initrd
APPEND ip=dhcp url=http://wds-server/ubuntu/24.04/ubuntu-24.04-live-server-amd64.iso cloud-config-url=/dev/null
Replace wds-server with the actual hostname or IP address, and adjust the ISO filename and paths to match your deployment. Refer to Canonical’s Ubuntu Server network boot documentation for the full list of supported kernel parameters.
Ubuntu Server 22.04 and 24.04 support unattended installation via Subiquity’s autoinstall mechanism. The installer reads a YAML user-data file at boot time and applies the specified settings without manual input.
Step 1. Create a directory on the IIS site to host the autoinstall files, for example E:\web\ubuntu\autoinstall\. Add two files: user-data and meta-data. The meta-data file can be left empty for a basic NoCloud data source.
A minimal user-data example:
#cloud-config
autoinstall:
version: 1
identity:
hostname: ubuntu-server
username: admin
password: "$6$REPLACE_WITH_A_VALID_HASH"
Replace the password value with a valid hash. A production configuration should also define storage layout, network settings, and SSH access. See Canonical’s autoinstall reference for all supported options.
Step 2. Add the autoinstall parameters to the Ubuntu kernel command line:
autoinstall ds=nocloud-net;s=http://wds-server/ubuntu/autoinstall/
The directory URL requires a trailing slash. Note that some Syslinux versions require the semicolon in ds=nocloud-net;s=... to be quoted or escaped — verify this against your Syslinux build.
Step 3. Boot a test machine and confirm the installer retrieves both user-data and meta-data over HTTP. Test the full storage and credential configuration on a disposable machine before deploying to systems with existing data.
Linux PXE failures can occur at different stages — DHCP discovery, TFTP transfer, Syslinux menu loading, or Ubuntu installation. Identify where the process stops before changing any configuration.
If the Syslinux menu appears but the Windows entry does not start WDS, check the following:
chain.c32 is present and from the same Syslinux release as the other boot files.pxeboot.0.pxelinux.cfg\default and confirm the target path matches the actual file location.A menu that displays correctly does not confirm that chainloading works — test the full Windows return path before adding Linux entries.
Work through these in order:
Test the UEFI path independently. A working BIOS configuration does not mean UEFI is correctly set up.
These are distinct errors with different causes — do not treat them as interchangeable.
NBP file too large: The assigned bootfile may not match the client firmware type. Verify that the network boot program is compatible with the client’s architecture, and check for known firmware-specific PXE issues if the configuration looks correct.
TFTP Error: access violation: Check the requested bootfile path against the RemoteInstall directory structure. Confirm the file exists and that WDS has permission to serve it.
If the Ubuntu installer starts but cannot reach its installation source:
If using autoinstall, also confirm that both user-data and meta-data are accessible at the configured URL.
If PXE works on the server’s local subnet but fails across VLANs:
Setting up WDS for Linux PXE boot requires a working baseline before each stage can build on the previous one: WDS and IIS installed, DHCP and PXE connectivity verified, Syslinux configured for the target firmware, and Windows chainloading confirmed before any Linux entries are added.
If something breaks, work backwards through the stages rather than adjusting multiple components at once. Most failures trace back to a file path mismatch, a missing Syslinux module, or a network configuration issue that was present before Linux was introduced.
For a production environment, make sure the Windows Server hosting WDS is protected with a reliable backup before making system-level changes. Info2soft provides enterprise data protection solutions covering physical servers, virtual machines, and mixed OS environments.
· Enterprise & Mid-market Customers Worldwide
· Support team available to assist you throughout your trial
· Start a 60-day free trial or view demo to see how Info2Soft protects enterprise data.
