Microsoft is withdrawing the role that serves PXE. Its own documentation for the replacement says the protocol is not secure
The Windows Deployment Services notice of 21 September moves network imaging to Configuration Manager. That product serves the same boot protocol over the same VLAN, and the Microsoft page describing how carries a warning that has been there for years.
By Parminder Kumar Sharma · · 6 min read
The notice, and the date before it
Microsoft published KB 5129631 on 21 September 2026: Windows Deployment Services will be deprecated in the next Windows Server release. The notice is unusually specific about what goes with it. The server role and both its role services, Deployment Server and Transport Server. WDS-provided PXE boot and network bootstrap. The management tools, command line interfaces, APIs and service activation paths. The multicast transport and every deployment workflow that depends on it. And the Windows Preinstallation Environment components used to build WDS clients, including WinPE-WDS-Tools.
The recommended replacement is Microsoft Configuration Manager, which the notice says "provides a better, more flexible, and feature-rich experience for deploying Windows images".
The same notice records two earlier reductions, and the second is the one worth stopping on.
In 2021, Windows Setup workflows using boot.wim from installation media in WDS mode were deprecated for Windows 11 and later. Then, in Microsoft's own words, WDS hands-free deployment scenarios "were disabled by default and became unsupported after installation of Windows updates released on or after April 14, 2026".
That is 160 days before the deprecation notice. The capability stopped working, by default, five months before anybody was told the role was going away, and it stopped through a cumulative update rather than a product announcement. If your change process tracks deprecation notices but not default-behaviour changes inside monthly updates, you learned about this in April, by something breaking.
What that does not establish. It does not establish a removal date. Microsoft is explicit that removal "can happen in the next Long-Term Servicing Channel release, or it can be several releases away". It does not mean WDS stops working: it remains available and supported on currently supported Windows Server releases according to their published servicing lifecycles. It does not establish that Configuration Manager is available to you at no additional cost, because licensing depends on your agreement and the notice does not address it at all. And nothing in any of these documents reports an incident. No part of this is a response to an exploited flaw.
What the migration actually moves, and what it does not
Read the two Microsoft pages together and the shape of the change becomes clear. WDS provides a PXE responder. Configuration Manager also provides a PXE responder, and has had one that runs without Windows Deployment Services for years, complete with its own registry settings for coexisting with DHCP on the same server.
So the product serving the boot image changes. The protocol does not. The VLAN does not. The devices that will boot from the network without a person touching them do not.
The same page is equally plain about the behaviour that makes this a control question rather than a build question. A required deployment "uses PXE without any user intervention" and the user cannot bypass the boot. And where a device has its network adapter set as the first boot device, it "can automatically start an OS deployment task sequence without user interaction", which Microsoft warns puts the device at greater risk of accidental reimage and which its deployment verification does not manage.
There is also a routing note that quietly describes the reachability problem. To support multiple subnets from one PXE-enabled distribution point, Microsoft says to configure IP helpers on the routers so the network forwards client PXE requests. That is the correct instruction. It is also, precisely, the mechanism by which an imaging service becomes reachable from networks it does not serve.
What changes, and what a deprecation cannot change
The WDS components listed in the notice, against what actually moves. Only one column describes a reduction in exposure.
| What the notice withdraws | Where it goes | Does the exposure change |
|---|---|---|
| The WDS server role and its two role services | Configuration Manager distribution point | No. A different product serves the same function |
| WDS-provided PXE boot and network bootstrap | The Configuration Manager PXE responder | No. Same protocol, same unauthenticated boot |
| WDS multicast transport and its workflows | Configuration Manager multicast | No. An on-premises distribution point is required for it |
| WinPE-WDS-Tools and the WDS management interfaces | Configuration Manager tooling | Yes, for anyone who scripted against the WDS APIs |
What to do about it
Take this with you
In the order worth doing
- Find every PXE responder on your network before you plan any migration, including responders that are not WDS. Configuration Manager can run one without it, and a deprecation inventory built by searching for the WDS role will miss those.
- Check which networks can reach the imaging service. If IP helpers were configured on routers to forward PXE requests across subnets, list exactly which subnets that covers and whether all of them still need it.
- Treat the April 2026 default change as an answer, not a surprise. If hands-free deployment stopped working earlier this year and was logged as an unexplained fault, close it against this notice.
- Review the documented controls on whichever responder you end up with: the MAC exclusion list, the duplicate hardware identifier settings, and whether any device fleet has the network adapter as its first boot device.
- Get the licensing answer before the migration plan. The recommended replacement is a separately licensed product, and the notice says nothing about cost.
- Add default-behaviour changes in cumulative updates to whatever you monitor for deprecation notices. This one arrived five months ahead of the announcement.
The question this leaves
Deprecation notices are read as security news, and mostly they are not. This one withdraws a free server role in favour of a licensed product, on no published timetable, for a capability that will keep working for years. Treated as a security event it is close to nothing.
Treated as an inventory event it is useful, because it forces a question most estates have not asked recently: what on this network will hand an operating system to a machine that just turned on, and who can reach it. The answer does not change when the role does. It changes when somebody looks at the VLAN.
So the question: when your imaging service moves to a different product, which of your controls moves with it, and which were properties of the network the old one happened to sit on?
Sources
- PrimaryWindows Deployment Services deprecation in the next Windows Server release, KB 5129631, 21 September 2026, used for the component list, the support position and the earlier reductionsMicrosoftaccessed 2026-09-26
- PrimaryUse PXE for OS deployment over the network, Configuration Manager, used for the PXE responder without WDS, the security warning and the documented controlsMicrosoft Learnaccessed 2026-09-26
- PrimaryFeatures removed or no longer developed in Windows Server, used to show how deprecations are published without datesMicrosoft Learnaccessed 2026-09-26
