Guida all'aggiornamento di Windows ADK su server SCCM

Su un server SCCM, l’aggiornamento di Windows ADK non è un semplice “next-next-finish”. Se si cambia ADK senza verificare compatibilità, versione di WinPE e dipendenze delle boot image, il rischio reale è rompere OSD, task sequence e la distribuzione delle immagini di avvio. La regola pratica è questa: prima si allinea la versione supportata da Configuration Manager, poi si prepara un rollback, infine si sostituisce ADK e ADK WinPE in modo pulito.

Perché l’ADK conta in SCCM

L’ADK fornisce gli strumenti che SCCM usa per creare e gestire le boot image, soprattutto quando fai bare metal deployment, refresh o imaging di workstation e server. La parte davvero sensibile non è tanto l’installazione del pacchetto principale, quanto l’allineamento con WinPE add-on, perché è lì che finiscono i componenti usati nelle immagini di avvio. Se la boot image resta legata a una versione vecchia o se i binari non sono coerenti, gli effetti tipici sono PXE che parte ma fallisce, task sequence che si ferma presto, o ambienti WinPE che non vedono rete e storage come previsto.

Il punto da non saltare è la matrice di supporto. Microsoft lega le versioni di Configuration Manager alle versioni di ADK supportate; quindi l’aggiornamento va pianificato in base alla release SCCM effettivamente in uso, non al desiderio di “portarsi avanti”. Se non hai sotto mano la matrice, il modo corretto di chiudere il gap è verificarla nel console path di documentazione del prodotto e annotare la build attuale di ConfigMgr prima di procedere.

Prerequisiti e controlli prima di toccare il server

Prima di disinstallare o sostituire ADK, conviene raccogliere tre informazioni: versione di Configuration Manager, versione attuale di ADK/WinPE e stato delle boot image distribuite. Senza questi dati si lavora al buio. Su un server SCCM, il controllo minimo lato console è la versione del site in Administration e la presenza delle boot image in Software Library. Lato sistema, la presenza di ADK si vede anche dai percorsi standard di installazione e dai componenti installati nel pannello programmi.

Una verifica rapida da shell, utile quando vuoi capire cosa c’è davvero installato, è questa:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Kits\Installed Roots' | Select-Object KitsRoot10
Get-ChildItem 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit' -ErrorAction SilentlyContinue

Se il primo comando non restituisce un percorso coerente oppure la cartella ADK non esiste, non assumere nulla: significa che il server è già in uno stato non standard, oppure ADK è stato installato altrove o rimosso solo parzialmente. In quel caso il rollback va basato su evidenze, non su memoria operativa.

Conviene anche verificare se le boot image sono state personalizzate con driver aggiuntivi, moduli PowerShell, storage o NIC specifiche. Più la boot image è “ritoccata”, più l’aggiornamento va trattato come change controllato, non come manutenzione banale.

Sequenza corretta di aggiornamento ADK su server SCCM

La sequenza più pulita è quasi sempre: esportazione o annotazione dello stato attuale, rimozione dei componenti ADK vecchi, installazione della nuova coppia ADK + WinPE add-on, aggiornamento delle boot image, redistribuzione e test. Saltare l’uninstall della vecchia versione è una scorciatoia che in ambiente SCCM spesso crea residui e comportamenti ambigui.

1. Congela il cambiamento

Se il server gestisce produzione, sospendi finestre OSD e assicurati che nessun deployment critico sia programmato mentre fai il cambio. Il blast radius non è solo il server SCCM: riguarda client nuovi, rebuild e refresh di macchine che dipendono dalle boot image. In pratica, il rischio è operativo su tutte le task sequence che usano WinPE.

Prima del cambio, esporta almeno la configurazione delle boot image dalla console, oppure annota i driver e i pacchetti aggiunti. Non è un backup completo, ma riduce il tempo di ripristino se qualcosa si rompe. Se vuoi una traccia minima, salva anche la lista dei componenti installati con i nomi esatti della versione attuale.

2. Disinstalla ADK e WinPE add-on precedenti

Su Windows recenti, la rimozione si gestisce meglio dai Programmi e funzionalità o da Impostazioni > App, cercando i componenti Windows ADK e Windows PE add-on. Se preferisci il controllo da CLI, usa PowerShell per verificare che il sistema abbia effettivamente rimosso i pacchetti prima di installare la nuova versione.

Get-WmiObject Win32_Product | Where-Object { $_.Name -match 'Assessment and Deployment Kit|Windows PE add-on' } |
Select-Object Name, Version

Attenzione: Win32_Product non è il metodo più elegante per inventariare software, ma in un intervento puntuale e controllato può aiutare a capire se l’installazione è ancora presente. Se vuoi evitare effetti collaterali, meglio usare chiavi di registro o la console software inventario del tuo endpoint management, se disponibile.

3. Installa la nuova versione di ADK e il WinPE add-on corrispondente

Scarica la versione supportata dalla tua release SCCM e installala con privilegi amministrativi. L’ordine corretto è ADK, poi WinPE add-on. Il secondo punto viene spesso sbagliato: senza add-on, SCCM non riesce a rigenerare correttamente le boot image basate su WinPE.

In installazioni manuali, il parametro silenzioso dipende dalla build del pacchetto scaricato, quindi non conviene inventare switch a memoria. Il controllo serio è verificare il supporto ufficiale del pacchetto specifico e, dopo l’installazione, confermare la presenza dei binari nel percorso previsto. Se il setup lascia log, salva sempre il path del log prima di chiudere la sessione; se il pacchetto fallisce, quel log è la prima fonte utile per capire se c’è conflitto di versione o prerequisito mancante.

4. Aggiorna le boot image in SCCM

Una volta installato il nuovo ADK, entra nella console SCCM e apri le boot image usate nelle task sequence. In genere il percorso è Software Library > Operating Systems > Boot Images. Qui non basta “vedere” la boot image: va aggiornata con i nuovi componenti WinPE e poi redistribuita ai distribution point.

Se la boot image è personalizzata, il controllo da fare è semplice: conferma che driver, componenti opzionali e eventuali script aggiunti siano ancora presenti dopo l’update. Il punto debole è proprio qui, perché una boot image apparentemente aggiornata può perdere un driver NIC e sembrare sana finché non avvii una macchina reale.

Un buon criterio di verifica è confrontare la data di modifica e lo stato di distribuzione della boot image prima e dopo l’update. Se il pacchetto non si ridistribuisce, o se la console mostra errori di content validation, il problema è a valle dell’installazione ADK e va trattato come issue di content management, non di setup ADK.

Verifica tecnica: cosa controllare subito dopo l’update

Dopo l’aggiornamento, la verifica non si limita a “la console si apre”. Va testato il percorso reale di boot. Il minimo sindacale è avviare una macchina di test via PXE o media, verificare che entri nel WinPE corretto e che veda rete, storage e connettività verso il management point o distribution point, secondo il tuo scenario.

Dal lato server, controlla i log di SCCM relativi alla distribuzione dei contenuti e al caricamento delle boot image. I nomi esatti possono variare in base al componente, ma il controllo utile è sempre lo stesso: assenza di errori di mount, fallimenti di aggiornamento immagine o problemi di accesso ai file ADK. Se usi log di site server o componenti distribuzione, cerca eventi legati al rebuild della boot image e alla copia verso i DP.

Un test rapido lato client, se la rete lo consente, è osservare se PXE riceve l’IP e scarica il NBP senza fermarsi su errori di boot file. Se il problema compare prima del caricamento WinPE, il collo di bottiglia potrebbe essere ancora il layer DHCP/PXE/DP e non l’ADK in sé. Questo evita di attribuire all’ADK colpe che sono altrove.

ipconfig /all
wpeutil initializenetwork
ping -n 1 <management-point-o-fqdn>

Se wpeutil initializenetwork fallisce o la rete resta assente in WinPE, la causa più probabile è un driver mancante nella boot image oppure un mismatch con il nuovo ambiente. Se invece la rete c’è ma il download dei contenuti non parte, il problema si sposta su DP, boundary, distribuzione o policy SCCM.

Problemi tipici dopo l’aggiornamento e come leggerli

Il primo errore classico è aggiornare ADK ma dimenticare WinPE add-on. In quel caso SCCM può mostrare una boot image apparentemente valida, ma il rebuild non produce un ambiente realmente operativo. Il secondo errore è non ridistribuire i contenuti ai distribution point: la console mostra la boot image aggiornata, ma i DP servono ancora una copia vecchia. Il terzo è ignorare i driver: il boot va avanti, ma la macchina non ha rete o storage.

Un altro caso frequente è il conflitto con task sequence o script che si aspettano path o componenti presenti solo in una certa release di WinPE. Qui la soluzione non è “forzare” la vecchia struttura, ma verificare i componenti richiesti e aggiornare gli script in modo esplicito. Se uno script chiama un percorso hardcoded, il cambio di ADK può far emergere un debito tecnico che era già lì.

Se il server è anche punto di integrazione con antivir, EDR o software di hardening, considera l’interferenza con i file di boot e con gli eseguibili del kit. Non è raro che una policy troppo aggressiva blocchi il processo di rebuild o l’accesso a cartelle temporanee durante la generazione delle immagini. Qui il controllo minimo è il log del prodotto di sicurezza e l’eventuale esclusione temporanea solo se prevista dal change e con rollback definito.

Rollback pratico se qualcosa va storto

Il rollback va pensato prima dell’installazione. La strada più pulita è conservare i dettagli della versione ADK precedente e, se necessario, reinstallare quella release insieme al relativo WinPE add-on. Non affidarti a “ripristino magico” della console: se la boot image è stata rigenerata con un ambiente nuovo, il rollback reale passa per reinstallazione della versione corretta e nuova ridistribuzione dei contenuti.

Se il problema è limitato alle boot image e non al server intero, puoi anche ripristinare una copia esportata della boot image o una versione precedente dei driver integrati. Però il rollback va fatto con criterio: prima riporti la piattaforma a una base supportata, poi ricrei la boot image, poi validi PXE e task sequence. Ripristinare solo il file immagine senza riallineare ADK spesso lascia il sistema in uno stato ibrido.

# Esempio di verifica post-rollback: la versione installata deve tornare coerente con la release supportata
reg query "HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots" /v KitsRoot10

Il rollback ha un blast radius limitato se hai separato bene i componenti: server SCCM, content library e boot image. Se invece hai personalizzazioni diffuse e script sparsi, il rientro può coinvolgere più team. Per questo conviene sempre tenere un diff delle modifiche alle boot image e una nota della versione precedente di ADK/WinPE.

Checklist operativa da usare in produzione

Prima del cambio, conferma: versione SCCM, versione ADK supportata, presenza di WinPE add-on, elenco boot image coinvolte, stato dei DP e finestra di manutenzione. Durante il cambio, conserva log e non modificare insieme altri componenti del site. Dopo il cambio, testa una sola boot image alla volta e verifica PXE, rete, storage e download contenuti.

Se vuoi ridurre al minimo il rischio, applica questo ordine mentale: osserva, aggiorna, rigenera, distribuisci, valida. È una sequenza semplice, ma in ambienti SCCM evita la maggior parte dei guasti autoindotti. Il punto non è fare l’update più veloce possibile, ma farlo in modo che sia reversibile e misurabile.

Assunzione operativa: il server SCCM è in produzione o comunque serve task sequence usate da utenti reali; ogni modifica a ADK/WinPE va trattata come change controllato con verifica su boot image e distribution point.