Pxe Server Windows 10

admin 25.12.2020 25.12.20

a1abama4ree.netlify.app › ▲ Pxe Server Windows 10

Summary

Windows 10 Pxe Boot Server
Create Pxe Server Windows 10
Pxe Server Windows 10 Versions

Devices that start up using Preboot Execution Environment (PXE) images from Windows Deployment Services (WDS) or System Center Configuration Manager (SCCM) may fail to start with the error 'Status: 0xc0000001, Info: A required device isn't connected or can't be accessed' after installing an affected update on a WDS server.

Running a PXE Server in Windows 10 in less than 10 minutes February 16, 2018 Dynamically assign MDT’s DeployRoot rule based on IPAddress001’s 2nd or 3rd octet. Step by step tutorial how to boot and install Windows 10 over the network from other host machine running Windows 10 as well. The software used to create a PXE server is SERVA Community Edition. After the tutorial on booting up Linux Mint over the network, I decided to write one also for Windows 10. So here it goes. Run the PXE-WIN32 installer file on the Windows machine you plan to install the PXE/TFT server. Select the language in which you want to run the installer and click Next.

Deployment Steps: When we boot our computer, we will use the PXE technology on our Network Interface Card (NIC) to locate the WDS server. The WDS server then sends the boot image to the client. After the client chooses the install image. This image will be copied from the install image on the WDS server to the client computer. NOTE: The traditional method to UEFI over PXE is to have Server 2012 (Server 2008 WDS does not support UEFI boot) and Windows Deployment Services setup; this article will allow a non-server OS to allow UEFI PXE boot.

Workaround

To mitigate this issue on an SCCM server:

Verify Variable Window Extension is enabled. (This setting is not available on Windows Server 2008 SP2 or Windows Server 2008 R2 SP1)
Set the values of TFTP block size to 4096 and TFTP window size to 1. For guidance on how to configure them, see Customize the RamDisk TFTP block and window sizes on PXE-enabled distribution points. pnach files for pcsx2 download with bios

Note Try the default values for TFTP block size and TFTP window size first but depending on your environment and overall settings, you may need to adjust them for your setup. You can also try the Enable a PXE responder without Windows Deployment Service setting. For more information on this setting, see Install and configure distribution points in Configuration Manager.

To mitigate this issue on a WDS server without SCCM:

In WDS TFTP settings, verify Variable Window Extension is enabled. (This setting is not available on Windows Server 2008 SP2 or Windows Server 2008 R2 SP1)
In the Boot Configuration Data (BCD) of the imported image, set RamDiskTFTPBlockSize to 1456.
In the BCD of the imported image, set RamDiskTFTPWindowSize to 4.

Note Try the default values for RamDiskTFTPBlockSize and RamDiskTFTPWindowSize first but depending on your environment and overall settings, you may need to adjust them for your setup.

Next steps

This issue is resolved in the following latest cumulative update (LCU) or Preview of Monthly Rollups released on June 16, 2019 or later:

KB4512941 LCU for Windows Server, version 1903.
KB4512534 LCU for Windows Server, version 1809 and Windows Server 2019.
KB4512509 LCU for Windows Server, version 1803.
KB4512494 LCU for Windows 10, version 1709.
KB4512495 LCU for Windows Server, version 1607 and Windows Server 2016.
KB4512478 Preview of Monthly Rollup for Windows Server 2012 R2.
KB4512512 Preview of Monthly Rollup for Windows Server 2012.
KB4512514 Preview of Monthly Rollup for Windows Server 2008 R2 SP1.
KB4512499 Preview of Monthly Rollup for Windows Server 2008 SP2

We are working on a resolution and will provide an update in an upcoming release for the platforms not already resolved.

Affected updates

Any latest cumulative update (LCU) or Monthly Rollups released on June 11, 2019 or later for the affected platforms may experience this issue:

KB4503293 LCU for Windows Server, version 1903.
KB4503327 LCU for Windows Server, version 1809 and Windows Server 2019.
KB4503286 LCU for Windows Server, version 1803.
KB4503284 LCU for Windows 10, version 1709.
KB4503267 LCU for Windows Server, version 1607 and Windows Server 2016.
KB4503276 Monthly Rollup for Windows Server 2012 R2.
KB4503285 Monthly Rollup for Windows Server 2012.
KB4503292 Monthly Rollup for Windows Server 2008 R2 SP1.
KB4503273 Monthly Rollup for Windows Server 2008 SP2

Windows 10 Pxe Boot Server

The following Security Only released on June 11, 2019 for the affected platforms may experience this issue:

KB4503290 Security-only update for Windows Server 2012 R2.
KB4503263 Security-only update for Windows Server 2012 and Windows Embedded 8 Standard.
KB4503269 Security-only update for Windows Server 2008 R2 SP1
KB4503287 Security-only update for Windows Server 2008 SP2

So I needed to install Windows 10 on some laptop - without optical drive - here. I downloaded the iso from Microsoft, used dd to copy it to an SD card and tried to boot from it - without success. After various attempts to fix booting from SD (or USB) on that laptop with that (non-damaged) iso I decided to go a bit further:

Overview

The approach I ended up with needs some systems / servers to play nicely together. First of all, I connected the laptop directly per an ethernet cable to a NixOS machine.

What happens at boot?

The laptop boots, PXE (“network boot”) selected as primary boot option.
The BIOS tries to get an IP address and a “boot-filename” via DHCP.
The BIOS tries to connect to a TFTP server and download a file with the boot-filename. It then boots that file.
That file should be a special bootloader, pxelinux in my case, which uses TFTP to load further program modules, especially the memdisk module.
The bootloader boots the memdisk module. This loads a special minimalistic windows operating system called “Windows PE” or short “WinPE” into main memory (over TFTP) and boots it.
WinPE runs wpeinit to detect hardware, followed by ipconfig to get network settings via DHCP.
WinPE can now access a SMB network drive which contains the files from the Windows install iso and run setup.exe to start the installation.

/mazda-6-haynes-manual-download.html. What’s needed?

A DHCP server supporting PXE. (ISC-)dhcpdworks but dnsmasq is a much better choice in my case because it also has a builtin TFTP server. It also supports being a proxy DHCP server if there’s already a DHCP server on the network which doesn’t support PXE.
A TFTP server. dnsmasq does this for me, but there’s also tftp-hpa.
pxelinux and memdisk. Both are often part of syslinux packages.
A compatible WinPE iso. This can be created from the Windows install iso using wimlib.
A SMB/CIFS server. I use Samba on the NixOS machine, but a Windows server would do, too.

The firewall

Fighting against the my own firewall on the NixOS machine is unnecessary, I just allow any traffic from the laptop:

The DHCP server

With nothing configured (except the BIOS of the laptop for network boot) and the two systems connected by the ethernet cable it is possible to check that the BIOS is actually looking for a DHCP server by running tcpdump -ttttnnvvS -i eno1 (where eno1 is the - unconfigured - ethernet network interface on the NixOS machine):

This is a BOOTP/DHCP request (with a DHCPDISCOVER inside) from 20:6a:8a:0f:74:75 with no IP address assigned (thus 0.0.0.0) to the broadcast address 255.255.255.255. It’s sending from port 67 (client side DHCP) to port 68 (server side DHCP) and asking for various network parameters, including BF (the so called boot filename) and TFTP.

Starting dnsmasq -C dnsmasq.conf with

results in the NixOS machine answering:

This offers an IP address (192.168.42.17 here) to the laptop (mac 20:6a:8a:0f:74:75), sends DNS information, the default gateway and some other stuff. But the BIOS ignores it and keeps sending DHCPDISCOVER requests. That’s because the reply - the DHCPOFFER - doesn’t include a boot-filename. After some seconds the BIOS on the laptop thus announces:

PXE-E53 no boot filename received

To fix this, I need to tell dnsmasq to send a boot filename by adding this to the config:

Then, the exchange between the machines reads as follows:

The replies from the NixOS DHCP server notably now contain the BF option. Moreover the complete Discover, Offer, Request, ACK cycle is now complete - thus the laptop now has IP address 192.168.42.17.

The TFTP server, pxelinux and memdisk

Next, the BIOS asks (via ARP) who’s 192.168.42.1 (the DHCP server, probably because it doesn’t know better) and sends a TFTP RRQ resource request for the boot filename. The NixOS machine blocks the request because there’s (currently) no TFTP server running on it:

After numerous tries the BIOS then fails with the error message:

PXE-E32: TFTP open timeout

So I add this to dnsmasq.conf:

Also I create a file /tmp/win-pxe/tftp/boot/pxelinux.cfg/default:

Turning the laptop on again now boots pxelinux with the menu, given that the required files are in /tmp/win-pxe-tftp/:

Wait … `winpe.iso`?

This is where wimlib comes into play. That’s a library (and set of programs) that work with Windows Imaging files. It contains mkwinpeimg which allows to create a (even customized) WinPE iso from either a Windows install iso or a “Windows Automated Installation Kit (WAIK)”. I use a Windows install iso. I mount the iso to be able to access its contents:

I also create a start.cmd script to define what’s happening once Windows PE boots:

Then I can create the WinPE iso:

This first failed with an unexpected error (I have lots of free disk space):

An educated guess later I decided to explicitly specify a temporary directory on my disk (with much of free space) by adding --tmp-dir=/home/mustersel/temporary to the mkwinpeimg command line. This gives me a winpe.iso file with a size of about 316M, which I place in /tmp/win-pxe/boot/.

Booting WinPE

On the laptop, I select “Boot Windows PE from network”. This causes the memdisk module to be sent via TFTP:

Then on the laptop memdisk shows:

Loading winpe.iso

Looking at the NixOS machine reveals that memdisk loads winpe.iso also via TFTP (which is a rather slow protocol, so this takes some time):

The laptop then greets me with some Windows loading screen, followed by a command line.

On WinPE in `cmd.exe`

According to the ArchWiki page on Windows PE I need to run the following once I’m on the Windows command line:

According to some Microsoft pagewpeinit “[.] installs Plug and Play devices, [.], and loads network resources”. ipconfigseems to be the equivalent to ifconfig, run without arguments it probably set up networking. After running these commands I could see on the NixOS machine how the laptop running WinPE requested an IP via DHCP. Note the hostname minint-t10cd8a that is logged - it’s no longer the BIOS doing the DHCP but the WinPE environment:

For the next steps WinPE needs access to all of the Windows install iso.

Setting up a SMB/CIFS network drive with Samba is pretty easy. I use the following config, but most of it is actually unnecessary:

I can then “mount” this network drive from within WinPE with:

This should make the contents of the Windows install iso (which is mounted to /tmp/win10iso on the NixOS machine) available under I: from WinPE. But I ran into the following issue: On the NixOS machine I got:

Basically Samba just died. On the WinPE side the error message read:

The solution is unintuitive but simple. I just need to access the network share with some username and password (doesn’t matter which, can be just random strings):

Create Pxe Server Windows 10

I actually spent quite a lot of time searching for this solution, even though it’s right in the ArchWiki page down at the bottom…

This starts the Windows install setup, which is guided and thus easy to follow … until it complained with a mysterical message that I couldn’t use the partitions I just created and formatted:

We couldn’t create a new partition or locate an existing one. For more information, see the Setup log files.