Aggiornare Windows 11 24H2 con SCCM: guida pratica

Aggiornare Windows 11 24H2 con SCCM senza trasformare il deployment in un terno al lotto

Se devi portare una base installata di Windows 11 a 24H2 usando SCCM, il punto non è “spingere l’update”. Il punto è farlo passare attraverso un percorso prevedibile: hardware compatibile, contenuto corretto, policy di distribuzione sensata, metriche chiare e un piano di ritorno. In pratica, il lavoro vero è prima del click su Deploy e continua dopo il primo client che termina l’installazione.

Con 24H2 il rischio tipico non è solo l’errore di download o il client che non vede il pacchetto. Il problema più frequente è la differenza tra ciò che l’amministratore pensa di aver pubblicato e ciò che il client riesce davvero a validare: requisiti, spazio disco, versione di partenza, anello di manutenzione, finestra di manutenzione, stato del servizio SCCM e salute del content distribution. Se uno di questi anelli cede, l’aggiornamento sembra “non partire” o parte e poi si ferma a metà.

Prima di tutto: capire se stai facendo servicing, feature update o task sequence

In SCCM esistono più strade per arrivare a 24H2, ma non sono equivalenti. La scelta cambia la visibilità, il controllo e il rollback. Se usi Servicing Plan, lavori sul flusso di Windows Update for Business mediato da Configuration Manager; se distribuisci un Feature Update come oggetto standalone, hai più controllo sul targeting; se passi da Task Sequence, hai un percorso più rigido ma anche più verboso e più adatto a scenari complessi o a macchine che richiedono step aggiuntivi.

Per una migrazione a 24H2 in produzione io tratto quasi sempre il caso come change controllato, non come semplice patching. Questo significa: anello pilota, anello esteso, esclusioni esplicite, verifica di compatibilità e osservazione dei fallimenti prima di aprire il rubinetto su tutta la collezione.

Prerequisiti che evitano il 70% dei falsi problemi

Prima di pubblicare il deployment, controlla questi punti. Non sono teoria: sono i motivi per cui i client restano in Unknown, scaricano contenuto a singhiozzo o falliscono con codici che sembrano casuali.

• Versione di partenza supportata per il salto a 24H2.
• Spazio libero sufficiente sul disco di sistema, meglio con margine reale e non “al limite”.
• Client SCCM aggiornato e sano, con policy ricevute correttamente.
• Content library e Distribution Point coerenti, senza pacchetto parziale o replicazione in ritardo.
• Impostazioni di maintenance window e deadline compatibili con il tempo necessario al feature update.
• Eventuali blocchi di compatibilità hardware o software già verificati in anello pilota.

Se vuoi chiudere il gap in modo rapido, dal lato client verifica almeno versione, spazio e policy. Su una macchina pilota puoi partire con questi controlli basilari:

winver

Per lo spazio disco, non basta una stima astratta: controlla il volume di sistema e lascia margine per download, estrazione temporanea e rollback. Se il device è vicino al limite, l’update può fallire anche quando il pacchetto è corretto.

La colonna portante: anelli di distribuzione e collezioni ben costruite

La parte più sottovalutata è la segmentazione. Non distribuire 24H2 su una collezione enorme “per vedere cosa succede”. Crea almeno tre livelli: pilota tecnico, pilota business, produzione estesa. Ogni anello deve avere criteri di ingresso e di uscita, altrimenti il deployment diventa un gesto impulsivo travestito da automazione.

Nel mondo reale i problemi emergono nelle differenze di profilo: notebook con VPN, desktop in sede con proxy, sistemi con software legacy, device con poco spazio residuo, macchine che non hanno ricevuto aggiornamenti da settimane. Un anello piccolo e rappresentativo ti restituisce segnali utili; un anello casuale ti restituisce rumore.

Se usi collezioni dinamiche, verifica che le query non includano dispositivi fuori target per errore. Se usi membership manuale, controlla che i device di test siano davvero quelli giusti. Un deployment ben progettato può essere rovinato da una collezione sporca più facilmente di quanto si creda.

Distribuire 24H2 come Feature Update in SCCM

La strada più lineare, nella maggior parte dei casi, è importare il Feature Update di Windows 11 24H2 e distribuirlo come oggetto di aggiornamento. Il vantaggio è che SCCM mantiene visibilità su detection, stato di compliance e avanzamento. Il rovescio è che devi avere il contenuto disponibile e sincronizzato correttamente.

1. Sincronizza il catalogo degli aggiornamenti e verifica che 24H2 compaia correttamente nella console.
2. Controlla che il pacchetto sia scaricato e distribuito ai Distribution Point necessari.
3. Crea una raccolta pilota con pochi dispositivi rappresentativi.
4. Imposta un deployment iniziale con deadline prudente e finestra di manutenzione coerente.
5. Osserva gli stati di compliance e i codici di errore prima di allargare il target.

Il punto chiave è non confondere la presenza del titolo in console con la reale disponibilità del contenuto. Se il DP non ha completato la distribuzione, il client può mostrare il deployment ma fallire al momento del download. In quel caso il problema non è il client: è la catena di contenuto.

Verifiche lato client: dove guardare quando “non succede niente”

Quando il client sembra immobile, la tentazione è rifare il deploy. Prima no. Prima guarda gli artefatti. I log principali ti dicono quasi sempre se il nodo è in discovery, download, installazione o attesa di policy.

• C:\Windows\CCM\Logs\WUAHandler.log per la parte di Windows Update.
• C:\Windows\CCM\Logs\UpdatesDeployment.log per il flusso di deployment.
• C:\Windows\CCM\Logs\ContentTransferManager.log e DataTransferService.log per il download del contenuto.
• C:\Windows\CCM\Logs\LocationServices.log se il client non trova il DP corretto.

Un errore tipico è vedere il deployment assegnato ma senza progressi. In quel caso chiediti: il client ha ricevuto la policy? ha trovato il DP? ha spazio sufficiente? ha raggiunto il servizio di update? Se una sola risposta è no, il problema è già abbastanza chiaro da non richiedere ipotesi fantasiose.

Se vuoi un controllo veloce sul lato Windows Update, puoi anche forzare una scansione policy e osservare i log subito dopo. Non è una cura, è un test di visibilità.

gpupdate /force

Il comando non risolve problemi di contenuto o compatibilità, ma ti dice se le policy arrivano e se il client smette di essere “cieco” per semplice ritardo di aggiornamento.

Tre ipotesi che spiegano quasi tutti i fallimenti iniziali

Quando 24H2 non parte o si interrompe, nella pratica le cause più probabili sono queste.

1. Contenuto non disponibile o non replicato. Si falsifica in pochi minuti controllando stato del deployment sul DP e log di download sul client.
2. Prerequisito locale mancante, di solito spazio disco o build di partenza non compatibile. Si falsifica verificando versione e spazio libero sul dispositivo pilota.
3. Policy o finestra di manutenzione non coerenti con il deadline. Si falsifica confrontando assignment, maintenance window e orario di esecuzione del client.

Queste tre ipotesi coprono la maggior parte dei casi reali perché toccano la catena completa: distribuzione, host e orchestrazione. Se tutte e tre sono sane, allora ha senso scendere più in profondità su compatibilità applicativa, driver o blocchi specifici del dispositivo.

Rollback: non improvvisarlo dopo che hai già esteso il deployment

Un deployment di feature update va sempre pensato insieme al rollback. Non sempre il rollback è “tornare indietro” in senso stretto; spesso significa bloccare la propagazione, sospendere l’anello successivo e lasciare che solo il pilota completi o fallisca in modo controllato.

Se il problema è emerso in pilota, il rollback più sicuro è: disattivare il deployment, rimuovere il target dalle collezioni successive, attendere la stabilizzazione, poi correggere la causa. Se invece hai già investito un gruppo più ampio, la strategia cambia e devi valutare la reversibilità effettiva del feature update in quella build e in quella finestra temporale.

Regola pratica: se non hai ancora osservato un successo ripetibile su un anello piccolo, non allargare il blast radius. Il costo di aspettare un’ora è quasi sempre inferiore al costo di gestire centinaia di device in stato ambiguo.

Come leggere i risultati senza farsi ingannare dalla console

La console SCCM è utile, ma non basta da sola. Uno stato “In Progress” può nascondere un client bloccato in download, un altro in attesa della finestra, un altro ancora già fallito ma non ancora riportato come tale. Per questo conviene incrociare almeno tre livelli: stato deployment in console, log client e, se disponibile, metriche del DP o del boundary group.

Se noti che i fallimenti si concentrano su una sede specifica, il sospetto si sposta subito su boundary, distribution point o rete. Se invece i fallimenti sono trasversali ma solo su una certa build di partenza, allora il problema è più probabilmente compatibilità o prerequisito software. Questa distinzione ti evita di trattare come problema di rete ciò che è in realtà un problema di versione.

Quando serve una task sequence invece del semplice update

Ci sono casi in cui il feature update standard non è il percorso migliore. Penso a workstation con pre-check specifici, necessità di sospendere software critico, backup locale, remediation di spazio disco o sequenze di riavvio coordinate. In questi scenari una task sequence può offrire più controllo, a costo di maggiore complessità operativa.

La task sequence è più pesante da mantenere, ma ti dà un vantaggio importante: puoi inserire controlli espliciti prima del salto, gestire step di preparazione e fermarti in modo leggibile quando un prerequisito non è rispettato. Per ambienti eterogenei è spesso la scelta meno elegante e più affidabile.

Buone pratiche che fanno la differenza

• Documenta la versione di partenza e la versione target per ogni anello.
• Conserva uno screenshot o un export della configurazione del deployment prima di estenderlo.
• Monitora i codici di errore ricorrenti invece di limitarti al conteggio dei fallimenti.
• Usa finestre di manutenzione realistiche, non ottimistiche.
• Separare il pilota tecnico dal pilota business evita che un singolo problema venga interpretato come un fallimento generale.

La qualità del rollout non si misura solo con il numero di device aggiornati, ma con il numero di eccezioni che hai dovuto gestire manualmente. Se il processo richiede troppe eccezioni, il problema non è il pacchetto 24H2: è il modello di distribuzione.

Chiusura operativa: il flusso che userei davvero

Se dovessi impostarlo da zero, farei così: sincronizzazione del contenuto, verifica DP, collezione pilota piccola e rappresentativa, deployment con deadline prudente, osservazione dei log client e solo dopo estensione progressiva. Niente salto diretto alla produzione larga. Niente fiducia cieca nella console. Niente rollback “da decidere dopo”.

Il vantaggio di questo approccio è semplice: quando 24H2 incontra un ostacolo, sai già dove guardare e quanto si è esteso il problema. Ed è esattamente quello che vuoi in un aggiornamento di sistema operativo: non l’assenza di guasti, ma la capacità di contenerli e correggerli senza perdere il controllo del parco macchine.