Microsoft said this is "an early notice to help organizations identify dependencies and begin migration planning." The company said it will deprecate the Windows Deployment Services (WDS) server role starting with the next Windows Server release, then stop active development and eventually remove it. Microsoft published the early notice, KB 5129631, on September 21, 2026, and said it applies to Windows Server 2016, 2019, 2022, version 23H2 and 2025.
What this means for your business
The inbox WDS server role and associated WDS functionality remain available on all currently supported Windows Server releases, Windows Server 2025 and earlier.
What WDS does today
Windows Deployment Services is a revised version of Remote Installation Services. It lets IT administrators remotely install Windows operating systems on fleets of dozens or hundreds of computers over a network using PXE boot.
Why Microsoft is phasing it out
Microsoft has narrowed WDS for years, and its deprecation notice lays out the timeline. In 2021, Windows Setup workflows that use boot.wim from installation media in WDS mode were deprecated for Windows 11 and later, though custom-image PXE scenarios stayed available. Hands-free deployment was then disabled by default and became unsupported after customers installed Windows updates released on or after April 14, 2026. After those changes, Microsoft restricted WDS to deploying Windows Server or booting custom deployment environments rather than standard desktop operating systems through its native setup engine.
What the deprecation covers
According to Microsoft’s notice, the next Windows Server release is planned to deprecate the inbox WDS role and the functionality tied to it, including the server role and its Deployment Server and Transport Server role services, WDS-provided PXE boot and network bootstrap, management tools, command-line interfaces and APIs, multicast transport and WDS-dependent multicast workflows, and WinPE-WDS-Tools. Microsoft put the status plainly: "Deprecated products are supported until they are eventually removed from a future OS version." It also flagged HTTP(S) Boot as a separate firmware and deployment capability that may suit some solutions but is not a replacement for Configuration Manager PXE-based operating system deployment.
What stays the same
WDS continues to work on all currently supported Windows Server releases, Windows Server 2025 and earlier, according to their published servicing lifecycles, and the announcement does not change its availability or support on those releases. Independent PXE implementations and non-Microsoft deployment products that do not rely on the inbox WDS role are unaffected. Microsoft said "Microsoft Configuration Manager operating system deployment is not being affected," though it told administrators to begin migrating Configuration Manager environments that still use WDS-backed PXE or WDS-dependent multicast away from those dependencies.
A good moment to reduce what your deployment server exposes
Planning a move is also a chance to review the security of an on-premises deployment server. A security analysis published on securityarsenal.com describes WDS as a long-standing soft target and stresses that this is a configuration and architecture risk rather than a patch event, with no CVE tied to the announcement. Its points are worth checking with your IT team:
- WDS delivers boot images over TFTP on UDP port 69, which has no authentication and no encryption, so the analysis says any host that can reach the server on that segment can request boot image (.wim) files without credentials.
- Unattend answer files such as unattend.xml and Autounattend.xml, stored under the REMINST share (C:\RemoteInstall by default), often contain domain-join credentials in cleartext or reversible base64, a pattern the analysis maps to the MITRE ATT&CK technique for unsecured credentials (T1552.001).
- WDS responds to PXE boot requests through DHCP options 66/67 or ProxyDHCP on UDP port 4011, where the analysis warns a rogue PXE server on the same segment can push attacker-controlled images to endpoints before the operating system loads, below the visibility of most endpoint tooling.
The same analysis notes the Microsoft Deployment Toolkit (MDT), the longtime companion to WDS, was already deprecated earlier, which closes out the classic on-premises imaging stack.
What to do now
- Inventory your WDS deployments: identify any server with the WDS role or its role services installed, and note which imaging, recovery or network-boot workflows depend on them.
- Find indirect dependencies: Microsoft advises reviewing Configuration Manager, custom Windows PE images, scripts, automation, WDS APIs, WDSUTIL usage and multicast workflows that touch WDS components.
- If you run Configuration Manager, begin migrating environments that still use WDS-backed PXE or WDS-dependent multicast off those dependencies, which Microsoft says it will keep supporting for OS deployment.
- Validate a replacement: Microsoft points to Configuration Manager for deploying Windows images, and the notice suggests testing it against your real device firmware, network conditions, security controls, image sizes and deployment volumes.
- Plan capacity changes: the notice advises planning for capacity changes if you move from multicast to unicast.
FAQ
What is Windows Deployment Services?
It is a Microsoft server role, a revised version of Remote Installation Services, that lets administrators remotely install Windows on many computers over a network using PXE boot.
Which Windows Server releases still include WDS?
The inbox WDS role remains available on Windows Server 2025 and all earlier supported releases, according to their published servicing lifecycles. The next Windows Server release is planned to deprecate it.
What does Microsoft recommend using instead of WDS?
Microsoft advises planning a migration to Microsoft Configuration Manager, which it says provides a more flexible experience for deploying Windows images. Configuration Manager itself is not affected, but environments using WDS-backed PXE or WDS-dependent multicast should move off those dependencies.