Configuration Manager No Longer Responding To PXE Boot

Dan Kingsbury 20 Reputation points
2026-03-11T16:25:29.76+00:00

I'm having issues with PXE booting to our distribution points. We're running version 2509, which we updated on January 21st, 2026. After the update we've been able to run unknown computer deployments without issue up until a few weeks ago. Now, anytime we deploy a UCD, the devices do not boot to PXE.

I've confirmed the following:

  • Enable PXE Support for clients - checked
  • Allow this distribution point to respond to incoming PXE requests - checked
  • Enable unknown computer support - checked
  • We currently use WDS for PXE.

I thought perhaps the boot image simply needed to be updated on the DPs, so I selected our boot image and updated distribution points. However, I received the following error:

Error: Failed to import the following drivers: • Intel(R) Ethernet Connection I217-LM - Failed to inject a ConfigMgr driver into the mounted WIM file

Error: The wizard detected the following problems when updating the boot image. • Failed to inject a ConfigMgr driver into the mounted WIM file The SMS Provider reported an error.: ConfigMgr Error Object: instance of SMS_ExtendedStatus { • Description = "Failed to register to status manager"; • ErrorCode = 2152205056; • File = "F:\\dbs\\sh\\cmgm\\0926_074307\\cmd\\18\\src\\SiteServer\\SDK_Provider\\SMSProv\\sspbootimagepackage.cpp"; • Line = 5539; • ObjectInfo = "CSspBootImagePackageInst::PreRefreshtPkgSourceHook"; • Operation = "ExecMethod"; • ParameterInfo = "SMS_BootImagePackage.PackageID=\"NAZ00005\""; • ProviderName = "WinMgmt"; • StatusCode = 2147749889; };

Since I assume I now had a corrupt or otherwise unusable boot image file and neglected to snapshot before doing so, I restored my environment from backup the previous day. However, I saw no change in the issue.

I thought this may have started after the January Windows updates were deployed in late February. We tried removing the update KB4489899 but after attempting removal, it would auto-install again on before the next reboot, so we couldn't remove it.

After confirming that our last successful UCD was done within the last few weeks, I decided to restore the environment back to February 13th, which was before the Windows update was done, and before our last known successful UCD. Regardless, I'm still unable to perform a UCD.

I even tried rebuilding the boot image from scratch, thinking that was corrupt. I utilized the WIM file in the C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us directory as my source and uploaded the latest driver pack from Dell for our end points, distributed it and updated my TS to point to the new boot image and it still doesn't seem to allow PXE boot to work.

I tried researching through copilot which didn't turn out to be too fruitful. It references the SMSPXE log on the DP, but that log doesn't exist there, nor does it exist on the site server. Any other logs to consider searching through to pinpoint a cause? I'm currently at a loss on what else to check.

Microsoft Security | Intune | Configuration Manager | Deployment

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-03-11T16:26:05.1666667+00:00

    Focus on PXE itself first, then on the boot image and policy side. Use the built‑in PXE/OSD logs and the standard PXE troubleshooting flow.

    1. Verify network path and IP Helpers
    • Confirm that the DHCP server, PXE‑enabled DP/WDS, and clients are either on the same subnet/VLAN or that IP Helpers are correctly configured on the routers to forward PXE broadcasts to both DHCP and the WDS/PXE DP.
    • Ensure DHCP options 60/66/67 are not configured at server or scope level. These options are not supported for ConfigMgr PXE and can cause intermittent or complete PXE failure.
      • Only exception: if DHCP and WDS are on the same server, option 60 may be set; 66 and 67 should still not be set.

    References for this step:

    • IP Helpers are required when DHCP, client, and PXE DP are on different subnets/VLANs.
    • Using DHCP options instead of IP Helpers is not supported and can break PXE.
    1. Confirm PXE/WDS health on the DP Because SMSPXE.log is missing, first confirm that PXE is actually installed and active on the DP:
    1. On the DP properties in ConfigMgr:
      • Ensure Enable PXE support for clients and Allow this distribution point to respond to incoming PXE requests remain checked.
      • Ensure at least one x64 and one x86 boot image are distributed and have Deploy this boot image from the PXE‑enabled distribution point enabled.
    2. On the DP server itself:
      • In Server Manager, verify that Windows Deployment Services (WDS) is installed and the service is started.
      • Check that C:\RemoteInstall exists and contains:
        • SMSBoot
        • SMSImages
        • SMSTemp
        • SMSTEmpBootFiles
      • Under C:\RemoteInstall\SMSBoot, verify that both x86 and x64 subfolders exist and are populated, and that Boot.sdi exists in C:\RemoteInstall\SMSBoot.
      • Under C:\RemoteInstall\SMSImages, verify that the boot image package IDs in use (for example, NAZ00005 and any new boot image) have corresponding folders.

    If WDS or the RemoteInstall structure is missing or incomplete, PXE will not respond and SMSPXE.log may not be created.

    1. If PXE/WDS looks broken: reinstall PXE on the DP If the above checks show WDS/PXE is not healthy or SMSPXE.log never appears, follow the supported “reinstall PXE” sequence on the DP:
    1. On the DP in ConfigMgr, clear Enable PXE support for clients. When prompted to remove Windows Deployment Services, select Yes.
    2. Use the DP logs to verify PXE uninstall completed:
      • For a DP on a site server: check Distmgr.log.
      • For a standalone DP: check Smsdpprov.log. Do not proceed until PXE is fully uninstalled.
    3. In Server Manager, confirm WDS is uninstalled and that a restart is pending; restart the server.
    4. After restart, delete the C:\RemoteInstall folder if it still exists.
    5. In DP properties, change the date on the self‑signed PXE certificate (not applicable if the DP is HTTPS) and wait for a new certificate to be created.
    6. Re‑enable PXE by checking Enable PXE support for clients again. Monitor Distmgr.log or Smsdpprov.log to confirm the DP installs PXE successfully.
    7. Confirm a new C:\RemoteInstall folder is created and that the SMS subfolders listed above are present.
    8. Ensure at least one x64 and one x86 boot image are distributed to this DP and that PXE is enabled on each boot image.
    9. Confirm the WDS service is started.
    10. Try PXE boot again.

    This sequence addresses many “PXE stopped responding” scenarios after changes or updates.

    1. Validate boot images and drivers The earlier error about injecting the Intel I217‑LM driver indicates a problem updating a boot image, but that alone does not usually stop PXE advertising entirely; it mainly affects WinPE startup on specific hardware.

    After PXE is healthy:

    • Confirm both x86 and x64 boot images exist on the DP under C:\RemoteInstall\SMSImages\<PackageID> and that they are marked to deploy from PXE‑enabled DPs.
    • If WinPE starts but has no network, check SMSTS.log in X:\Windows\Temp\SMSTS (or C:\Windows\Temp\SMSTS after failure) for entries showing whether the NIC gets an IP address. If no valid IP is logged and ipconfig shows no NIC, add only the required NIC and storage drivers to the boot image and redistribute.
    1. Check task sequence deployment and unknown computer support If PXE now responds but aborts before loading a task sequence:
    • Verify the device is in a collection that has a PXE‑available task sequence deployment.
    • If using unknown computer deployments, ensure Enable unknown computer support is checked on the DP and that the device is not already present in the ConfigMgr database as a known client.
    • If a device is in the database but the TS is only deployed to unknown computers, PXE will abort with “no available policy” in SMSPXE.log.
    1. Logs to use once PXE is responding Once SMSPXE.log is present (on the PXE‑enabled DP):
    • Use it to trace PXE requests, policy lookup, and boot image selection.
    • Use Distmgr.log and Smsdpprov.log to validate DP content and PXE role installation.
    • Use SMSTS.log on the client during WinPE to troubleshoot network and storage driver issues.

    Summary of next actions in this environment

    1. Confirm IP Helpers are correctly configured and DHCP options 60/66/67 are not set (except 60 when DHCP+WDS share a host).
    2. Verify WDS and C:\RemoteInstall structure; if broken or missing, perform a full PXE/WDS reinstall on the DP as outlined.
    3. Redistribute at least one x86 and one x64 boot image with PXE enabled.
    4. Once SMSPXE.log appears, use it plus SMSTS.log to narrow down whether the failure is at PXE response, policy assignment, or WinPE startup.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Dan Kingsbury 20 Reputation points
    2026-03-13T16:55:44.3266667+00:00

    Update: Issue is resolved. I was able to locate the SMSPXE logs. I inherited this environment, so wasn't around for the original build. I found that they were housed off the main drive an a custom directory. Once I found the SMSPXE log I was able to determine that the DP certificates had expired. Once we updated the certs, I was able to boot to PXE again as normal and the issue resolved.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.