PXE boot failing in Configuration Manager: SMSPXE.log, boundaries and the PXE responder

PXE failures look the same from the device side — a firmware error or "booting to next device" — but the cause can sit in the network, the distribution point, the boot image or the deployment. In this post I'll take a failing PXE boot in Configuration Manager through each stage in order, show what SMSPXE.log tells you at every step, and fix the usual culprits.

Symptoms#

• The firmware shows errors such as PXE-E51 (no DHCP offers), PXE-E53 (no boot filename), PXE-E55 or PXE-E78, and nothing appears in SMSPXE.log.
• The device gets an address, then the boot is aborted and it moves on to the next boot device.
• TFTP errors such as PXE-E32 (TFTP open timeout) while downloading boot files.
• WinPE loads, but restarts before the task sequence wizard appears.

Why it happens#

A PXE boot is a chain of four stages, and each fails differently:

SMSPXE.log lives on the PXE-enabled DP, normally in <drive>:\SMS_DP$\sms\logs.

How to fix it#

1. Prove the broadcast reaches the DP#

PXE boot the device and search SMSPXE.log for its MAC address. If it never appears, the problem is the network, not Configuration Manager:

• When the client, DHCP server and DP are on different subnets or VLANs, the router needs IP helpers that forward the client's broadcasts to both the DHCP server and the PXE DP.
• Open UDP 67 and 68 (DHCP), 69 (TFTP) and 4011 (BINL) between the client, DHCP and the DP.
• Remove DHCP options 60, 66 and 67 at server and scope level. Microsoft doesn't support controlling PXE with them, and they often push the boot down the wrong path. The only exception is WDS sharing a server with DHCP, which needs option 60 only.
• Test with the device on the DP's own subnet. If it boots there, fix the routing.

2. Check the DP's PXE settings#

Open Administration › Distribution Points, select the DP and choose Properties › PXE. Confirm:

• Enable PXE support for clients and Allow this distribution point to respond to incoming PXE requests are on.
• Enable unknown computer support is on if you image bare-metal devices.
• If Network interfaces is limited to specific interfaces, the listed MAC addresses are correct.
• If several PXE servers share a network, the PXE server response delay decides which one answers first.

With Enable a PXE responder without Windows Deployment Service, the DP uses the ConfigMgr PXE Responder Service (SccmPxe) instead of WDS. It supports IPv6, can share a server with DHCP, and is a good default unless you need multicast, which still requires WDS. Restart that service (or WDS) after changing network interfaces.

3. Make sure a PXE-enabled boot image is on the DP#

In Software Library › Operating Systems › Boot Images, open the boot image used by your task sequence and, on the Data Source tab, select Deploy this boot image from the PXE-enabled distribution point. Distribute it to the DP and confirm success under Monitoring › Distribution Status › Content Status. If a deployment targets only x64 BIOS computers, both the x64 and x86 boot images must be on the DP.

4. Read the boot decision in SMSPXE.log#

When the device is found but nothing is deployed to it, the log looks like this:

MP_LookupDevice succeeded: 16777299 1 16777299 1 0
00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: device is in the database.
00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: no advertisements found
00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: No boot action. Aborted.
00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: Not serviced.

5. WinPE starts but the task sequence doesn't#

Press F8 (command support must be enabled on the boot image) and run ipconfig. Then open X:\Windows\Temp\SMSTSLog\smsts.log and look for Found network adapter with a valid IP address. No address usually means a missing network driver; add only network and storage drivers to the boot image. If the network is fine but content can't be found, check that the imaging subnet is in a boundary group with a DP holding the task sequence content, or that fallback is configured. My smsts.log guide covers this stage in depth.

6. Last resort: reinstall PXE#

Clear Enable PXE support for clients, confirm the removal in distmgr.log (DP on the site server) or smsdpprov.log (remote DP), and — if you used WDS — remove WDS, restart and delete the RemoteInstall folder. Re-enable PXE and redistribute the boot images.

Verify the fix#

1. PXE boot the device. SMSPXE.log shows its MAC address, and the boot action reply now carries your deployment and boot image IDs instead of empty values.
2. The device downloads the boot image without TFTP errors and WinPE starts.
3. The task sequence wizard (or your required deployment) starts, and smsts.log shows the network adapter with a valid IP address.

Prevent it next time#

• Use IP helpers, never DHCP options, for PXE across subnets.
• Prefer the PXE responder on DPs that don't need multicast.
• After a Windows ADK update, refresh boot images and redistribute them before the next imaging day.
• Be careful with required PXE deployments: devices that boot from the network first can start a task sequence without anyone touching them.

References#

• Troubleshooting PXE boot issues in Configuration Manager
• Advanced troubleshooting for PXE boot issues in Configuration Manager
• Install and configure distribution points (PXE settings)