1 27/10/2026 9 min

Classificazione dell’intervento: change controllato

Qui non si tratta di “sbloccare” un’opzione a caso, ma di impostare un percorso di distribuzione coerente per gli aggiornamenti feature pre-release di Windows 10 dentro Configuration Manager. Il punto operativo è semplice: devi far sì che il client riceva la build giusta, nel momento giusto, con un anello di test separato dalla produzione e con una via di ritorno se qualcosa non regge su driver, software line-of-business o VPN.

Prima di toccare il parco macchine, conviene chiarire il risultato atteso: i device scelti nel collection di pilot devono vedere la feature update pre-release come disponibile in Software Center o come deployment mirato, mentre il resto della flotta resta escluso. Se osservi che l’update compare ovunque, oppure non compare da nessuna parte, il problema è quasi sempre in uno di questi tre punti: criterio di selezione errato, sincronizzazione del catalogo/servicing non allineata, oppure policy client non ancora recepita.

Prerequisiti minimi da verificare prima del rollout

Serve una baseline pulita. In un ambiente SCCM/MECM aggiornato, la gestione dei feature update pre-release dipende dalla versione corrente della console, dal livello di integrazione con Windows Update for Business o con il servicing in console, e dalla corretta classificazione del contenuto nel punto di distribuzione. Se questi elementi non sono allineati, il comportamento diventa imprevedibile e il troubleshooting si allunga inutilmente.

  • Verifica che il site sia supportato per la gestione dei feature update della versione che vuoi distribuire.
  • Controlla che i client target ricevano policy e inventario recenti.
  • Assicurati che il gruppo di pilot sia una collection dedicata e non una collezione “mista” usata anche per altro.
  • Prima di procedere, salva lo stato attuale del deployment e dei criteri di servicing, così da poter tornare indietro senza interpretazioni.

Se non hai certezza sulla build della console o del site, il primo dato da raccogliere è la versione esatta di Configuration Manager e il canale di servicing già in uso. Non improvvisare: un feature update pre-release su una base non allineata rischia di essere solo un test di sopportazione per il team desktop.

Abilitazione del servicing per feature update pre-release

Il flusso corretto parte dalla console. In genere il percorso è quello del nodo Software Library, dove si lavora sul ramo di Windows Servicing o della gestione degli aggiornamenti di prodotto, a seconda della release della console. L’obiettivo è rendere visibile il feature update pre-release nel catalogo e poi distribuirlo solo alla collection di pilot.

  1. Apri la console di Configuration Manager e vai in Software Library.
  2. Entra nel nodo dedicato a Windows Servicing oppure nell’area degli aggiornamenti software, in base alla versione installata.
  3. Avvia una sincronizzazione del catalogo se il feature update non è ancora comparso. L’evidenza attesa è che il nuovo update diventi visibile con stato Available o equivalente.
  4. Seleziona il feature update pre-release desiderato e verifica i metadati: versione, architettura, lingua, canale e eventuali note di supersedence.
  5. Crea un deployment mirato solo alla collection di test/pilot, evitando collection dinamiche troppo ampie.

La parte delicata non è “cliccare su deploy”, ma scegliere il target giusto. Un errore classico è usare una collection di validazione troppo permissiva, magari ereditata da un vecchio progetto. Il risultato è che il pre-release finisce su dispositivi non pronti, con impatto immediato su help desk e produttività.

Se il feature update pre-release non compare, la falsificazione più rapida è questa: forza una sincronizzazione del catalogo e controlla i log del site server e del ruolo software update point. Se dopo la sync non cambia nulla, il problema è a monte: canale non abilitato, metadati non disponibili, oppure prerequisito di versione mancante.

Creazione di un anello di pilot davvero reversibile

La buona pratica è separare il parco in almeno tre anelli: pilot tecnico, pilot esteso e produzione. Per i feature update pre-release, il primo anello deve essere piccolo, esplicito e composto da device che rappresentano il caso reale: stessa versione di Windows, stessi driver base, stesso tipo di software critico e, se possibile, stessa modalità di connettività remota.

  1. Raccogli 5–20 endpoint rappresentativi e inseriscili in una collection dedicata.
  2. Escludi esplicitamente la collection di pilot da tutte le policy di produzione che potrebbero sovrapporsi.
  3. Imposta un maintenance window o un orario di installazione coerente con i tempi di osservazione.
  4. Definisci un criterio di successo misurabile: ad esempio, installazione completata su almeno l’80% dei device pilot senza aumento di errori applicativi o ticket legati al boot.

Il rollback non è solo “disinstallare l’update”, perché per un feature update il ritorno indietro può essere lungo o non pratico. La vera reversibilità si costruisce prima: anello piccolo, esclusione netta, snapshot dei dati critici se l’ambiente lo richiede, e soprattutto assenza di estensione automatica verso collezioni più ampie.

Verifiche lato client: cosa vedere davvero sul dispositivo

Una volta pubblicato il deployment, la verifica non deve fermarsi alla console. Sul client vuoi vedere tre cose: policy ricevuta, update diventato eleggibile e installazione partita nel tempo previsto. Se una di queste manca, il problema è localizzato e puoi restringere il campo senza cambiare tutto il resto.

  1. Controlla in Software Center la presenza del feature update e lo stato di disponibilità.
  2. Verifica che il client abbia scaricato le policy recenti e che il record del dispositivo appartenga davvero alla collection pilot.
  3. Controlla i log del client relativi a valutazione policy e update scan: l’evidenza utile è la comparsa del titolo dell’update, il suo stato di compliance e l’eventuale motivo di esclusione.
  4. Se non compare nulla, forza un ciclo di machine policy retrieval e un nuovo scan degli aggiornamenti, poi ricontrolla lo stato entro pochi minuti.

La distinzione importante è tra “non visibile” e “visibile ma non installabile”. Nel primo caso stai ancora lavorando su targeting o sincronizzazione; nel secondo il problema può essere un requisito mancante, una release non ancora supportata dal dispositivo, oppure una supersedence che nasconde il pacchetto corretto. Sono casi diversi e vanno trattati in modo diverso.

Gestione dei log: dove cercare quando il deployment non si muove

Quando il flusso si inceppa, i log sono più utili di qualunque tentativo di “refresh” a occhi chiusi. Sul site server e sul server del ruolo di aggiornamento, cerca eventi relativi alla sincronizzazione del catalogo, alla pubblicazione del metadata e alla creazione del deployment. Sul client, invece, controlla la catena di valutazione della policy e dell’update scan.

  • Log del site/server di aggiornamento: verifica che l’update sia stato importato e classificato correttamente.
  • Log del client: verifica che la policy della collection sia arrivata e che l’update sia stato valutato come applicabile.
  • Console: controlla lo stato del deployment e il numero di dispositivi in Unknown, Required o Error.

Se il numero di device in errore cresce subito dopo la pubblicazione, il segnale più utile è il pattern dell’errore, non il singolo endpoint. Un errore uniforme su molti client indica un problema di policy o di contenuto; errori sparsi su pochi device suggeriscono invece incompatibilità locali, driver o prerequisiti mancanti.

Rischi operativi e impatto sul blast radius

L’impatto potenziale di un feature update pre-release è alto perché può toccare shell, driver, stack di rete, applicazioni legacy e criteri di sicurezza. Il blast radius va quindi trattato come quello di un change di sistema, non come una normale patch mensile. In pratica: la collection deve essere stretta, la finestra temporale definita e il piano di comunicazione già pronto prima del deploy.

Se l’ambiente usa VPN, filtri web, proxy o soluzioni di security posture, il test deve includere almeno un endpoint in ciascuna condizione rappresentativa. Molti problemi emergono solo fuori rete interna: download lento del contenuto, riavvio che rompe il tunnel, o applicazioni che falliscono al primo login dopo l’upgrade.

Rollback pratico: cosa fare se il pilot mostra regressioni

Se emergono regressioni, la prima mossa è bloccare l’estensione del deployment. In console, sospendi o rimuovi il target delle collection più ampie, poi lascia in osservazione solo il pilot per raccogliere dati utili. Non allargare il rollout per “vedere se si stabilizza”: è il modo più rapido per trasformare un test in un incidente di produzione.

  1. Disabilita il deployment verso le collection non ancora coinvolte.
  2. Se il feature update è già in fase di installazione, valuta il blocco delle macchine che non hanno ancora riavviato.
  3. Raccogli evidenze: device affected, versione build, applicazioni impattate, errori nei log e timing del guasto.
  4. Decidi se rimuovere il deployment, correggere i prerequisiti o sostituire il feature update con una release successiva più stabile.

Il rollback completo di un feature update di Windows 10 non è sempre immediato e non va dato per scontato. Per questo il vero rollback deve essere progettato come prevenzione: gruppo pilota ristretto, contenuto separato, nessuna promozione automatica, e documentazione chiara di ciò che cambia tra una release e l’altra.

Sequenza consigliata in produzione controllata

Se devi fare il cambio in modo ordinato, la sequenza più solida è questa: preparazione del catalogo, creazione della collection pilota, deployment limitato, osservazione, estensione graduale. Ogni passaggio deve avere un criterio di stop. Se una metrica peggiora — error rate, ticket, tempi di avvio, crash applicativi — ti fermi prima di allargare il raggio d’azione.

  1. Verifica versione di SCCM/MECM e stato del servicing.
  2. Sincronizza il catalogo e conferma la visibilità del feature update pre-release.
  3. Pubblica il deployment solo sulla collection di pilot.
  4. Osserva per almeno un ciclo operativo completo: installazione, riavvio, login, app critiche.
  5. Solo dopo esito positivo, estendi a un secondo anello con criteri identici ma popolazione più ampia.

Assunzione operativa: il tuo ambiente usa una collection dedicata per il pilot, i client ricevono policy entro tempi normali e hai accesso ai log del site e del client per verificare ogni fase del flusso.

Controlli finali prima di promuovere il rollout

Prima di promuovere il rollout oltre il pilot, controlla che il feature update pre-release sia stato installato senza regressioni sui device campione e che non ci siano segnali di saturazione sul punto di distribuzione o sul canale di download. Se il contenuto non è stabile, il problema non è il client: è la distribuzione del pacchetto o il dimensionamento del percorso scelto.

  • Stato del deployment in console: nessun errore sistemico, nessun aumento anomalo di Unknown.
  • Client pilota: build corretta, app principali testate, riavvio completato.
  • Log: nessun errore ricorrente di scaricamento, valutazione policy o installazione.
  • Rollback pronto: deployment sospendibile e collection di pilot ancora separata dal resto della flotta.

Se devi chiudere il lavoro con un criterio semplice, usa questo: il feature update pre-release è abilitato correttamente quando compare solo dove previsto, si installa solo sui device del pilot e lascia dietro di sé una traccia di log coerente dall’importazione al riavvio. Tutto il resto è rumore operativo.