A device PXE boots, reaches out to the distribution point, and then just stops: no boot action, PXE Boot Aborted. Nine times out of ten this isn’t a PXE, DHCP, or TFTP problem at all. It’s that the task sequence sitting in Configuration Manager was never actually deployed as available to PXE and media, usually because it got deployed through the console’s graphical interface without that option ticked, or not deployed to the right collection at all.
Why PXE Boot Aborted Happens
Configuration Manager’s PXE responder only offers a task sequence to a booting device if a deployment exists that’s targeted at that device’s collection and explicitly marked available to PXE and media, not just to Configuration Manager clients. It’s easy to deploy a task sequence through the console’s wizard, target the right collection, and still end up with a deployment that’s client-only, because the availability option defaults to something narrower than what PXE needs. The device boots, checks in, finds no applicable PXE deployment, and aborts. Nothing about DHCP options 66/67, the boot image, or the distribution point has to be broken for this exact symptom to show up.
The fastest way to confirm this is the cause, before touching anything else, is checking whether the task sequence deployment to the target collection shows PXE and media in its availability setting. If it doesn’t, redeploying it correctly is the fix, not a DHCP or network trace.
Redeploy the Task Sequence with PowerShell
Open the Configuration Manager console, then Connect via Windows PowerShell from the console’s own menu, which opens a PowerShell session already connected to the site:
From that session, redeploy the task sequence with the collection and PXE/media availability explicit:
Start-CMTaskSequenceDeployment -PackageId "DTV000A1" -CollectionName "All Systems" -DeployPurpose available -ScheduleEvent Assoonaspossible -MakeAvailableTo mediaandpxeCode language: JavaScript (javascript)PS DTV:\> Start-CMTaskSequenceDeployment -PackageId "DTV000A1" -CollectionName "All Systems" -DeployPurpose available -ScheduleEvent Assoonaspossible -MakeAvailableTo mediaandpxe
WARNING: The cmdlet 'Start-CMTaskSequenceDeployment' has been deprecated and may be removed in a future release. Use the cmdlet 'New-CMTaskSequenceDeployment' may be used as a replacement.
WARNING: The parameter 'ScheduleEvent' has been ignored because the parameter 'DeployPurpose' was given a value of 'Required'.
PS DTV:\>Code language: JavaScript (javascript)
-MakeAvailableTo mediaandpxe is the parameter that actually fixes PXE Boot Aborted. It matches the cmdlet’s MediaAndPxe availability value, and it’s the piece most GUI deployments through the wizard leave off unless the PXE and media checkbox was specifically selected during that wizard. After this runs successfully, check the task sequence deployment’s status in the console to confirm it now shows the device’s collection with PXE and media availability, then retry the PXE boot.
Reading the Deprecation Warning
Start-CMTaskSequenceDeployment is officially deprecated. Microsoft’s own cmdlet reference page marks it with: “This cmdlet is deprecated. Use New-CMTaskSequenceDeployment instead.” It still runs and still fixes the immediate PXE Boot Aborted problem, which is why it shows up in real troubleshooting sessions like this one, but it’s worth switching new scripts and documentation over to New-CMTaskSequenceDeployment, since Microsoft can remove a deprecated cmdlet in a future Configuration Manager PowerShell module release without much further notice. The equivalent command on the current cmdlet looks like this:
$DeployTS = Get-CMTaskSequence -TaskSequencePackageId "DTV000A1"
New-CMTaskSequenceDeployment -InputObject $DeployTS -CollectionName "All Systems" -DeployPurpose Available -Availability MediaAndPxe -ScheduleEvent AsSoonAsPossibleCode language: PHP (php)-Availability is the current parameter name; -MakeAvailableTo still works as its alias, so existing muscle memory for that parameter name doesn’t need to change.
What That Second Warning Actually Means
The second warning is worth flagging because its wording doesn’t match the command that was actually run: the command above specifies -DeployPurpose available, yet the warning claims ScheduleEvent was ignored because DeployPurpose “was given a value of ‘Required.'” That’s not accurate to the input in this case, it’s a known inconsistency in how the deprecated cmdlet reports which parameter triggered the conflict, not a sign the deployment itself used the wrong purpose. The underlying rule it’s trying to describe is real on both cmdlets: -ScheduleEvent only applies to a Required deployment, since it controls when an unattended install triggers, and it’s silently irrelevant to an Available deployment where the end user or a PXE boot initiates install instead. If this warning shows up, verify the deployment’s actual purpose in the console afterward rather than trusting the warning text to describe what happened.
If the Console Won’t Let You Open PowerShell
A Software Restriction Policy that blocks script execution outside a specific path can stop Connect via Windows PowerShell from launching at all, since that menu option runs a PowerShell module from the console’s own installation folder. If that’s the symptom, add a path rule for the console’s bin folder under Local Group Policy Editor:
Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Additional Rules > New Path Rule, pointing at the Configuration Manager console’s AdminConsole\bin\ConfigurationManager path, with the security level set to Unrestricted:
Set the path to match wherever the console is actually installed on that machine (commonly under ...\AdminConsole\bin\ConfigurationManager), apply the policy, and reopen the console. This is a machine-level Group Policy setting, so on a domain-joined admin workstation it’s worth checking whether an existing domain-level Software Restriction Policy GPO is the actual source of the block before adding a local override that a later GPO refresh could overwrite.
Read more: Windows 11 25H2 and 26H2: What Is Actually Changing?
Does PXE Boot Aborted always mean a DHCP or TFTP problem?
No. It most often means no task sequence deployment exists for that device’s collection with PXE and media availability enabled, which is a deployment configuration issue, not a network service issue.
Is Start-CMTaskSequenceDeployment still usable even though it’s deprecated?
Yes, it still runs. Microsoft’s reference marks it deprecated in favor of New-CMTaskSequenceDeployment, so it’s worth moving scripts to the replacement cmdlet, but the deprecated one isn’t broken yet.
What does -MakeAvailableTo mediaandpxe actually do?
It sets the deployment’s availability to PXE and media rather than Configuration Manager clients only, which is the specific setting a PXE-booting device checks for when deciding whether to offer a task sequence.
Why would the Connect via Windows PowerShell option be blocked in the console?
A Software Restriction Policy that restricts script execution outside approved paths can block it, since that option launches a PowerShell module from the console’s own installation folder. Adding a path rule for that folder resolves it.
What’s the difference between DeployPurpose Available and Required?
Available lets the device or user initiate the install, which is what PXE boot relies on. Required triggers an unattended install at a scheduled time or event, and that’s the only mode where -ScheduleEvent actually applies.
References
Microsoft: Start-CMTaskSequenceDeployment (ConfigurationManager) https://learn.microsoft.com/en-us/powershell/module/configurationmanager/start-cmtasksequencedeployment
Microsoft: New-CMTaskSequenceDeployment (ConfigurationManager) https://learn.microsoft.com/en-us/powershell/module/configurationmanager/new-cmtasksequencedeployment
