FOG Project or WDS: deploying Windows images over the network (PXE)

Key takeaways

• Windows 11 no longer installs from the installation media boot.wim through WDS: that workflow is blocked. PXE booting custom WinPE images still works.
• Since April 2026, WDS hands-free deployment is disabled by default (CVE-2026-0386); in September 2026, Microsoft announced the deprecation of the WDS role after Windows Server 2025.
• WDS installs Windows through Windows Setup; FOG Project clones a reference machine with Partclone. FOG is therefore not affected by those blocks.
• Before moving to FOG, check three things: Secure Boot (one certificate to enroll per machine), BitLocker encryption on the reference machine, and DHCP option 60 left over from WDS.
• FOG for identical rooms you reimage often, Configuration Manager for large Windows fleets, Autopilot for new devices: the deciding question is who installs Windows, not which PXE server.

It usually starts the same way. You add the boot.wim from the Windows 11 installation media to your WDS server, PXE boot a machine, and instead of the setup wizard you get a message: "Windows Deployment Services client functionality is being partly deprecated". On a WDS server running Windows Server 2025, you may get a missing media driver error instead, with no further explanation.

Nothing is broken: it is by design. And it is only the first of several decisions Microsoft has made about WDS. The latest one, announced in September 2026, covers the whole role.

What Microsoft actually changed

Three changes have piled up, and they often get mixed together.

Windows 11 no longer installs from the installation media boot.wim. The classic workflow — PXE boot, boot.wim from the DVD, Windows Setup in WDS mode — is blocked for Windows 11, whichever version the boot.wim comes from. WDS PXE boot itself is not affected: it can still load a custom WinPE image, from which you run setup off a network share. On the client side, the only end-to-end workflow still supported, Windows 10, targets an operating system whose support ended on October 14, 2025 for the Home and Pro editions.

Hands-free deployment has been off by default since April 2026. The answer file (unattend.xml) travelled over an unauthenticated channel, which exposed its contents, credentials included, to anyone on the network (CVE-2026-0386). Since the April 14, 2026 updates, the feature is disabled by default. A registry value, AllowHandsFreeFunctionality, turns it back on — and reopens the hole.

The WDS role is deprecated. Announced on September 21, 2026: starting with the Windows Server release that follows Windows Server 2025, the role, its tools, its PXE boot and its multicast transport are deprecated. Microsoft has not given a removal date yet.

On top of that comes MDT, the toolkit that supplied the custom boot images used with WDS: Microsoft announced its immediate retirement in January 2026. Existing installations keep working, but get no more fixes or support, and the download packages may disappear.

What FOG Project is, and why it is not WDS

The two get compared as interchangeable PXE servers. They do not work the same way.

WDS installs Windows. It is a Windows Server role built on Microsoft's setup components: WinPE, WIM images, Windows Setup. It needs an Active Directory domain (or standalone mode), a DHCP server, DNS and an NTFS volume for the image store. It can multicast and add driver packages to deployments.

FOG clones disks. FOG Project is free, open-source software released under the GPLv3, and the FOG server runs on Linux. You prepare a reference machine; FOG captures its contents with Partclone as a compressed image, then deploys that image to other machines, one at a time or over multicast. Around that core: a web interface, hardware inventory, and a client installed on the machines that renames them, joins them to the domain and installs applications afterwards ("snapins").

What they share: in both cases, a Windows image meant for several machines must be generalized with Sysprep before capture. That is what strips the reference machine's own details, such as its security identifier (SID) and installed drivers.

The direct consequence: FOG goes through neither Windows Setup nor the WDS role. The blocks described above do not apply to it, and Microsoft states that non-Microsoft deployment products that do not depend on WDS are not affected by the deprecation.

What FOG image deployment brings

• Independence from Microsoft's roadmap for the deployment step: capture and deploy depend neither on Windows Setup nor on a Windows Server role.
• Multicast: FOG uses UDPcast to send one image to many machines using only slightly more bandwidth than a single unicast transfer. A session can be started from a group of hosts, as a named session that machines join, or straight from the boot menu.
• A Linux server instead of Windows Server: the project recommends a long-term support distribution (Ubuntu, Debian, Rocky, Alma) and suggests installing FOG in a virtual machine, for instance on Proxmox, to make backups and upgrades easier.
• Post-deployment management: renaming, domain join, printers and application installs go through the FOG client. Everything after that is handled by Group Policy, as for any domain-joined machine.

FOG pitfalls to know before you migrate

Secure Boot. An old thread on the official forum answers "Currently FOG does not support secure boot". That is out of date: the documentation now covers network booting with Secure Boot enabled. FOG signs its own kernels with a key generated at install time, and each machine has to enroll FOG's certificate once — at the console, one machine at a time. FOG 1.6 documents an unattended method, but it has only been tested in a virtual machine so far. On the 1.5 branch, Secure Boot only works over HTTP, not HTTPS. 32-bit UEFI machines must keep Secure Boot disabled.

BitLocker and automatic encryption. FOG refuses to capture an encrypted partition, and suspending BitLocker is not enough: the reference machine must be fully decrypted before Sysprep, with no Windows Hello PIN enrolled. One more trap: recent Windows 11 builds turn on device encryption automatically at first sign-in on supported hardware. A reference machine can end up encrypted without anyone asking for it.

DHCP option 60 left over from WDS. On a Windows DHCP server, option 060 set to PXEClient blocks UEFI network boot to FOG. Remove it, unless WDS runs on that same server.

Multicast and switches. Multicast may require specific switch configuration, and by default a session waits until every machine is ready before it starts. Test on one room before rolling it out.

The version. As of late October 2026, the stable branch is 1.5.10, which moves forward in successive builds (1.5.10.2518 on October 11), while 1.6.0 is at the release candidate stage — yet it is the one the download page presents as the latest release. Upgrading from 1.5 to 1.6 is one-way: it changes the database schema. Test it on a lab server, not in production.

What WDS still has going for it

WDS has not lost all its value. It stays integrated with the Windows Server ecosystem: Microsoft console, command line and PowerShell, prestaged computers, driver packages. And it still PXE boots custom WinPE images: that is the path Microsoft leaves open for Windows 11, with setup launched from a network share.

If your fleet already runs Configuration Manager, the question changes: that is the tool Microsoft is steering customers towards, and it has a PXE responder that works without WDS — unicast only.

As for Windows Autopilot, it does not reimage: it turns the manufacturer's preinstalled Windows into a business-ready device, and builds on Microsoft Entra ID and automatic enrollment into a management service such as Intune. It is designed for devices assigned to users and managed from the cloud; it does not replace an image when what you need is to reset a whole room to an identical state without depending on an online service.

How to choose

Keep WDS, without investing further, if it works today with a custom WinPE image on Windows Server 2022 or 2025 and your needs are stable. It remains supported on those versions. Use that time to prepare what comes next rather than to expand it.

Move to FOG if you regularly reimage rooms of identical machines — schools, training centers, labs — without Configuration Manager, and you are fine running a Linux server. That is the use case it was built for: one golden image, one multicast, one room back to a clean state.

Move to Configuration Manager if you already have it, or if your fleet is large and Windows-centric enough to justify its cost and complexity.

Look at Autopilot for new machines assigned to users, if you already run Intune.

Either way, the useful question is not "which PXE server?" but "who installs Windows: Windows Setup, or a disk copy?". That is what determines how exposed you are to Microsoft's next decisions.

For a step-by-step FOG Project install — the installfog.sh script, DHCP options 66 and 67, your first capture — see the FOG Project tutorial. If your rooms are spread across several VLANs, each segment needs its own DHCP and boot options: that is one of the pitfalls covered in the article on VLAN segmentation.