WDS boot images always load

[Surowa]

I followed the guide completely, but whatever I try I get a boot setup menu.

If I continue booting, it will always boot WDS. I have made sure option 60 is not set anywhere, and iPXE Configuration and Deliver iPXE are the only active policies. Enabling "Do not listen on DHCP ports" in the WDS settings now prevent anything from booting at all, instead, the boot setup menu appears directly. Any idea what else I can try? It's mind boggling how complex WDS can be to disable.

[Surowa]

I think it does not go past "Downloading NPD file"

[Surowa]

Is it maybe related to the iPXE infinite loop? Like here: https://ipxe.org/howto/msdhcp#pxe_chainloading

[mintsoft]

Hmmm, first things first: you are definitely using UEFI netboot and not legacy (i.e. BIOS) PXE?

I suppose the underlying assumption in the instructions I have is that the DHCP server and WDS server are on the same machine, is that the case for you?

Do you see any part of the iPXE boot process actually work? I.e. do you see iPXE pull in the iPXE.conf file?

You can enable WDS TFTP logging in event viewer, that might help you see if it's actually getting the right requests etc.

[Surowa]

Yeap, I'm using vSphere with UEFI netboot activated.

Nah, that's not the case: my DHCP server runs on a different server than WDS, and I think it would be very hard to change that (as I would have to install WDS on my DCs).

No, it seems the boot process immediately jumps to load WDS, even with all DHCP options on server and/or policy level pointing towards the ipxe boot file. I wonder if there are other ways WDS can hijack the request aside from option 60?

I will get back to you regarding the event logging. Have enabled it but can't test until next week.

[mintsoft]

Hmm, if I remember correctly WDS will respond to DHCP requests unless you disable it (i.e. tick the UDP 67 option thing). When you do that, your DHCP server will respond instead, however nothing will be able to netboot WDS.

So once you're in the state that nothing netboots, "all" you need to do is make that work; you do that by setting the DHCP option 66 to point to the WDS server and (by default) you'd set option 67 to be Boot\x64\wdsmgfw.efi. Without all the options that have been discussed in the instructions; you should then have a working WDS configuration that will EFI netboot, but doesn't use the WDS to respond to DHCP.

Now if you layer on the DHCP policies you should get the best of both worlds.

If that doesn't work, then I'm not sure what's going on; be interesting to see the actual DHCP packets that are being sent through traffic captures etc as that might shine a light on what's happening.

[Surowa]

I disabled WDS with the 67 option ticked, but I still am quite ablazed by the fact that this window is the first thing to load:

In the event viewer logs under I can find this kind of errors:

The Following Client failed TFTP Download: 

Client IP: 10.122.7.2
Filename: \SMSBoot\boot.sdi
ErrorCode: 1460
File Size: 3170304
Client Port: 10058
Server Port: 57154
Variable Window: false

However, as seen in the boot image, WDS still seems to boot. When I press enter the .wim file loads just like normal.

I will install nmap shortly and check if I can get my hands on some DHCP packets send.

[mintsoft]

Hmm, that is interesting; that means that something is responding to the DHCP request and responding with option 67 pointing at the WDS EFI net loader. That's the only explanation I can think of. Presumably it's 10.122.0.43 that's doing it.

[Surowa]

Oddly enough, that is the WDS server itself! So it responds despite the DHCP options not being explicitly set. Is there any other way a WDS server might load itself? Multicasting is enabled, for instance...I have not idea if that may have any influence?

[mintsoft]

Hmmmmm, I'm pretty sure that PXE option is only how WDS will respond when it's asked about providing content to clients via TFTP (i.e. after the first DHCP exchange) and not whether WDS will respond to DHCP requests. AFAIK, WDS will never respond to broadcasted DHCP requests itself, it relies on your actually DHCP server to do it.

Do you definitely only have 1 DHCP server running on the network?

Multicast sessions should be a totally separate thing, they're negotiated later on in the process if they're being used.

[Surowa]

Okay, so I think I figured this out. We have SCCM running in our environment, and it has the capability to work completely without DHCP if needed, it only needs WDS. If WDS is disabled or SCCM's pxe loader and its broadcasting ability, as well as the DHCP options are emptied, then SCCM's internal DHCP intercept functionality still points you to the location of the SCCM WIM boot files. If DHCP options are populated towards the WDS server again, the network uses normal DHCP, but because the traffic is always routed through SCCM, setting a different bootfile for SCCM does not load the ipxe.efi but instead only boots the wim image loader directly... I would need to figure out how to disable SCCM's internal PXE functionality (and how it is called at all) Thanks for all your help! ;)