Microsoft ha ufficializzato quello che molti amministratori di sistema temevano da tempo: Windows Deployment Services (WDS), insieme al suo motore PXE (Preboot Execution Environment), è stato dichiarato deprecato a partire dalla prossima release di Windows Server. Non si tratta di una rimozione immediata — il ruolo resta funzionante su Windows Server 2016, 2019, 2022, 23H2 e 2025 — ma la direzione è chiara, e chi gestisce infrastrutture di imaging bare-metal farebbe bene a iniziare a pianificare la migrazione già ora, prima che la finestra di manovra si riduca.

In questo articolo vediamo cosa cambia esattamente, perché Microsoft ha preso questa decisione, e quali sono le alternative concrete indicate dalla documentazione ufficiale, con relativi pro e contro per chi deve scegliere il percorso di migrazione.

Cosa viene deprecato, nel dettaglio

La deprecazione non riguarda un singolo componente, ma l’intero stack WDS:

• Il ruolo server WDS e i suoi componenti Deployment Server / Transport Server
• La funzionalità di PXE boot e network bootstrap fornita da WDS
• Gli strumenti di gestione, le CLI (wdsutil), le API e i percorsi di attivazione del servizio
• Il trasporto multicast e i flussi di deployment che ne dipendono
• I componenti WinPE-WDS-Tools usati per costruire immagini di boot personalizzate

Non è una novità improvvisa: già nel 2021 Microsoft aveva deprecato i flussi di boot.wim basati su WDS per Windows 11 e versioni successive, e ad aprile 2026 gli scenari di deployment “hands-free” tramite WDS sono stati disabilitati di default nelle installazioni più recenti. La deprecazione formale del ruolo server è quindi l’ultimo tassello di un percorso iniziato da anni.

Perché ora?

WDS si appoggia su un’architettura di rete e boot (BIOS/PXE legacy, multicast, protocolli TFTP non cifrati) che non si allinea più con i requisiti di sicurezza moderni: niente autenticazione del client prima del trasferimento dell’immagine, nessuna cifratura del traffico di boot, e una superficie di attacco che include il classico problema del “server DHCP/PXE non autorizzato in rete”. Con l’adozione crescente di UEFI Secure Boot, TPM 2.0 e gestione cloud-first dei dispositivi, mantenere un componente legacy come WDS come via principale di provisioning ha sempre meno senso per Microsoft.

Le alternative raccomandate

1. Configuration Manager PXE responder (senza WDS)

È l’alternativa che Microsoft raccomanda in modo più esplicito per chi già usa (o può adottare) Microsoft Configuration Manager (ConfigMgr/MECM). Il PXE responder di ConfigMgr può funzionare in modalità standalone, senza dipendere dal ruolo WDS sottostante, gestendo direttamente le richieste di boot di rete. La distribuzione del sistema operativo tramite ConfigMgr (task sequence, immagini, driver package) resta una capacità pienamente supportata e non deprecata: cambia solo il livello di trasporto della fase di boot iniziale.

Per chi ha già un’infrastruttura ConfigMgr consolidata, questa è generalmente la strada a minor attrito: la migrazione richiede di riconfigurare il ruolo di distribuzione point per gestire il PXE senza il servizio WDS legacy sottostante, verificando compatibilità di firmware e switch di rete (in particolare per IP helper/DHCP relay).

2. Soluzioni PXE di terze parti

Esistono implementazioni PXE non Microsoft, sia commerciali sia open source, che restano ovviamente non toccate dalla deprecazione. Tra le più note in ambito Linux/eterogeneo:

# Esempio: avvio di un server PXE minimale con dnsmasq su Linux
sudo apt install dnsmasq
cat <<EOF > /etc/dnsmasq.d/pxe.conf
interface=eth0
dhcp-range=192.168.10.100,192.168.10.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp
EOF
sudo systemctl restart dnsmasq

Soluzioni come netboot.xyz, iPXE o piattaforme MDM/deployment di terze parti offrono spesso funzionalità più moderne (boot via HTTP/HTTPS, script di boot dinamici, interfacce web) rispetto al vecchio WDS, ma richiedono comunque un progetto di migrazione: mappatura delle immagini esistenti, retraining del personale, e in alcuni casi costi di licenza.

3. UEFI HTTP(S) Boot

Per i dispositivi con firmware UEFI moderno, il boot via HTTP(S) è un’alternativa nativa al PXE tradizionale, con il vantaggio di poter cifrare il trasferimento dell’immagine di boot. Microsoft è però esplicita nel dire che non è un sostituto diretto del PXE responder di ConfigMgr: si tratta di un meccanismo di trasporto complementare, utile in scenari specifici (ad esempio boot attraverso reti che non supportano bene il multicast/broadcast PXE), ma che da solo non copre tutte le funzionalità di un flusso di OS deployment completo.

4. Windows Autopilot per i nuovi dispositivi

Per chi acquista hardware nuovo, Microsoft continua a spingere verso Windows Autopilot: il provisioning avviene “out of the box”, senza immagine personalizzata da distribuire via rete, con il dispositivo che si registra e si configura da cloud (Entra ID/Intune) al primo avvio. Non è un rimpiazzo 1:1 di WDS per il re-imaging di parco macchine esistente, ma per il ciclo di vita dei nuovi PC riduce drasticamente (o azzera) la necessità di un’infrastruttura PXE.

Come pianificare la migrazione

Prima di scegliere una strada, la documentazione Microsoft raccomanda alcuni passi di analisi che vale la pena seguire alla lettera:

1. Censire tutte le implementazioni WDS attive nell’organizzazione, comprese quelle “nascoste” in filiali o laboratori
2. Verificare le dipendenze da Configuration Manager, immagini WinPE personalizzate e utilizzo di wdsutil in script di automazione
3. Valutare l’impatto sulla capacità di deployment unicast se oggi si fa affidamento sul multicast di WDS per grandi rollout simultanei
4. Validare le alternative in condizioni realistiche di rete e firmware, non solo in laboratorio: switch, VLAN, IP helper e compatibilità UEFI vanno testati sul campo

Per organizzazioni di medie e grandi dimensioni, la combinazione più pragmatica nel breve-medio termine è spesso: ConfigMgr PXE responder per il parco macchine esistente da re-immaginare, e Windows Autopilot per tutto l’hardware di nuovo acquisto. Le soluzioni di terze parti restano un’opzione valida soprattutto per ambienti eterogenei Linux/Windows che già non dipendevano fortemente da WDS.

Conclusione

Non c’è ancora una data di rimozione definitiva per WDS, ma il messaggio di Microsoft è inequivocabile: è il momento di uscire dalla comfort zone del vecchio PXE responder integrato in Windows Server. Chi gestisce infrastrutture di imaging dovrebbe iniziare subito il censimento delle dipendenze e un piccolo pilot su una delle alternative disponibili, per evitare di trovarsi a rincorrere la migrazione quando il supporto verrà effettivamente ritirato.

Fonte: Microsoft Support e 4sysops