Con SCCM l’aggiornamento a Windows 11 25H2 va trattato come un change controllato, non come un semplice “click e via”. La differenza la fanno tre cose: come prepari il pacchetto, come limiti il blast radius e come leggi i segnali di errore prima di allargare il rollout.
Se l’obiettivo è portare i client alla 25H2 senza sorprese, il punto non è solo distribuire il contenuto. Devi sapere in anticipo quali device sono eleggibili, quali prerequisiti bloccano l’upgrade, come monitorare l’esito e quale rollback hai pronto se il ring pilota mostra un’anomalia.
Quando ha senso usare SCCM per 25H2
SCCM ha senso quando vuoi governare il rilascio con precisione: finestre di manutenzione, collection mirate, reporting centralizzato e possibilità di fermare il rollout se una metrica peggiora. In ambienti misti o con hardware non uniforme, questa granularità evita di trasformare un feature update in un incidente diffuso.
La logica corretta è questa: prima verifichi che l’ecosistema regga l’upgrade, poi distribuisci in anelli progressivi. Non il contrario. Se parti da tutta la base installata, il problema non è più tecnico ma operativo.
Prerequisiti da controllare prima del deployment
Prima di creare il task o la feature update rule, controlla almeno questi elementi:
- Versione attuale dei client e compatibilità hardware con Windows 11.
- Spazio libero su disco sufficiente per il download e l’installazione.
- BitLocker, Secure Boot e TPM 2.0, se richiesti dalla tua baseline.
- Stato del client SCCM e capacità di ricevere policy e content.
- Eventuali software di sicurezza che possono bloccare il setup o il riavvio.
Un controllo rapido sul lato client ti evita di inseguire errori generici nel deployment. Se il device non riceve policy, il problema non è 25H2: è la salute del client SCCM o la connettività verso management point e distribution point.
Per una verifica veloce puoi usare il Configuration Manager Client e i log locali. I file più utili, in condizioni standard, sono CAS.log, ContentTransferManager.log, DataTransferService.log, UpdatesDeployment.log e SMSTS.log se stai passando da task sequence. Se non sai dove guardare, parti da lì invece di cambiare subito la configurazione.
Scelta del metodo: Feature Update, Task Sequence o Servicing Plan
Per Windows 11 25H2 ci sono tre strade tipiche. La più lineare è la distribuzione come feature update, utile quando vuoi portare i client a una build specifica con meno complessità. La task sequence conviene se devi fare pre-check, remediation o passaggi aggiuntivi. Il servicing plan è comodo in teoria, ma nella pratica spesso è meno prevedibile del controllo manuale del rollout.
Se l’ambiente è eterogeneo, la feature update gestita in anelli è di solito il compromesso migliore: meno moving parts, più leggibilità nel reporting. Se invece hai requisiti di compliance, driver particolari o script di preparazione, la task sequence resta la scelta più robusta.
Preparare il contenuto in SCCM senza sporcare l’ambiente
La regola pratica è semplice: tieni il contenuto versionato e separa il materiale di test da quello di produzione. Se usi un package o un deployment package, dai un nome che identifichi chiaramente versione, ring e data. Un naming ambiguo è il modo più rapido per distribuire la build sbagliata.
Se stai importando l’immagine o i file di setup, verifica che il distribution point abbia replicato il contenuto prima di aprire il deployment. Il sintomo classico di un errore qui è un client che vede la policy ma fallisce il download con messaggi di content not found o access denied.
Un controllo utile è confrontare il contenuto distribuito con il pacchetto atteso direttamente dalla console SCCM, oppure con i log sul DP se il problema sembra di replica. Non andare a tentativi: in un rollout OS, un contenuto incoerente si traduce in ore perse sui client.
Anelli di rollout: la parte che riduce il rischio
La struttura più pulita è sempre la stessa: pilot, pre-produzione, produzione. Il ring pilota deve essere piccolo ma rappresentativo, non composto solo da macchine “facili”. Se testi soltanto dispositivi perfetti, il rollout reale ti presenterà i problemi che hai evitato di vedere.
Un buon ring pilota include almeno un device per profilo hardware importante: notebook, desktop, postazione con VPN, macchina con periferiche critiche e, se presente, un endpoint gestito da policy di sicurezza più aggressive. Così intercetti i conflitti prima di allargare il deployment.
In SCCM puoi usare collection dinamiche o statiche. Le collection dinamiche sono più eleganti, ma richiedono query corrette e testate. Le statiche sono più manuali, ma nel change controllato hanno un vantaggio: sai esattamente quali device stai toccando.
Distribuzione della feature update 25H2
Se scegli la feature update, la sequenza operativa deve restare sobria: importa il contenuto, distribuiscilo ai DP, crea il deployment verso la collection pilota, imposta deadline coerente con la finestra di manutenzione e monitora i client nelle prime ore. La fretta qui è un difetto, non un vantaggio.
Il punto critico è distinguere tra download riuscito e installazione riuscita. Un client può scaricare tutto e fallire al momento del setup per spazio insufficiente, driver incompatibile, software di protezione o riavvio bloccato. Per questo il monitoraggio deve includere sia la fase di content acquisition sia quella di installazione.
Se il target è Windows 11 25H2, verifica anche che la baseline di sicurezza e i criteri di update siano allineati. Un device “compatibile” a livello hardware può comunque essere fermato da policy locali o da una configurazione difforme su WSUS/SUP.
Task sequence: quando serve controllo fine sul pre-check
La task sequence è la strada giusta se vuoi introdurre controlli espliciti prima dell’upgrade. Ad esempio: verificare spazio disco, stato BitLocker, versione minima del BIOS, presenza di software noto per creare conflitti, o eseguire una remediation preliminare.
In questo scenario la sequenza non deve diventare un labirinto. Le azioni essenziali stanno prima dell’upgrade, non dopo. Più la task sequence è lunga, più diventa difficile capire dove si è fermata e più complesso sarà il supporto agli utenti.
Se usi SMSTS.log, concentrati sul primo errore utile, non sull’ultima riga rumorosa. Il log spesso registra molte azioni ripetitive: il vero guasto di solito è uno o due step prima del crash visibile.
Verifiche rapide lato client prima di aprire il rollout
Su un client pilota puoi fare un controllo base dalla console o via strumenti locali. L’obiettivo è capire se il dispositivo è pronto, non dimostrare che “forse andrà bene”.
wmic logicaldisk get caption,freespace,size,volumenameQuel comando ti dice subito se il disco ha margine sufficiente. Se il free space è troppo basso, fermati prima del deployment. In un upgrade OS, il disco pieno non è un dettaglio: è una causa concreta di rollback o fallimento del setup.
Per il lato SCCM, il check fondamentale è che il client riceva policy e scarichi il contenuto dal DP corretto. Se vuoi una verifica più diretta, i log di download e deployment ti dicono in quale fase si blocca il processo. Quando il problema è di connettività o autenticazione, il failure appare spesso prima dell’installazione vera e propria.
Monitoraggio: cosa guardare nelle prime ore
Le metriche utili non sono molte, ma vanno lette con disciplina: tasso di successo del deployment, percentuale di client in download, percentuale in installazione, rate di errori per codice e tempo medio di completamento. Se una metrica peggiora all’aumentare del ring, hai un segnale chiaro per fermarti.
Il controllo manuale sui primi device è più utile di cento grafici belli. Cerca pattern ripetuti: stesso codice errore, stessa fase di blocco, stesso modello hardware. Se il guasto si concentra su una famiglia di device, la causa è spesso driver, firmware o policy locale.
Una buona abitudine è annotare per ogni ring: numero di device target, numero di device riusciti, numero di device falliti e motivo prevalente. Questa disciplina rende il change ripetibile e ti evita di ricostruire tutto a posteriori.
Errore comune: confondere upgrade fallito con client SCCM rotto
Molti ticket nascono da una lettura superficiale: l’utente vede il client fermo e conclude che SCCM non funzioni. In realtà il problema può essere nel setup di Windows, nello storage, nella policy di riavvio o in un conflitto software. La distinzione è importante perché cambia completamente la remediation.
Se il client scarica il contenuto ma non avvia l’upgrade, il problema è quasi sempre post-download. Se invece non scarica nulla, il focus torna su policy, DP, boundary group o salute del client. L’ordine di indagine deve seguire questa logica, non il contrario.
Rollback: cosa preparare prima di toccare la produzione
Un rollback credibile non è “vediamo dopo”. Prima del change devi avere chiaro almeno uno di questi piani: sospensione del deployment, esclusione della collection, riduzione del ring, oppure ripristino del precedente stato del device se il processo aziendale lo prevede. Il rollback va pensato prima del primo client pilota.
La misura più semplice è bloccare l’espansione del deployment: se il ring pilota mostra un problema sistemico, interrompi la distribuzione e correggi il punto di rottura. In molti casi è sufficiente a evitare impatti inutili.
Se il tuo processo include snapshot, backup o strumenti di reimaging, il dettaglio operativo deve essere scritto e verificato. Non basta sapere che “si può tornare indietro”: devi sapere chi lo fa, con quali tempi e su quali device.
Procedura pratica consigliata
Una sequenza ragionevole per aggiornare Windows 11 25H2 con SCCM è questa:
- Verifica prerequisiti hardware, spazio disco e salute del client SCCM sui device pilota.
- Importa e distribuisci il contenuto ai distribution point, poi conferma la replica.
- Crea una collection pilota piccola ma rappresentativa.
- Applica il deployment con deadline e finestra di manutenzione coerenti.
- Controlla i log client e il reporting SCCM nelle prime ore.
- Espandi al ring successivo solo se non emergono errori ripetitivi.
Questa sequenza è volutamente conservativa. Nel change controllato, la velocità utile è quella che non ti costringe a riparare dopo. Se il primo ring va bene, il secondo e il terzo sono un’estensione del controllo, non una scommessa.
Dettagli operativi che fanno la differenza
Tre dettagli vengono spesso sottovalutati. Primo: la comunicazione agli utenti, soprattutto se è previsto un riavvio. Secondo: la manutenzione delle collection, perché device obsoleti o duplicati falsano il reporting. Terzo: la chiarezza dei nomi, che deve permettere a chiunque del team di capire al volo cosa stai distribuendo.
Un altro punto utile è separare il problema tecnico dal problema organizzativo. Se il deployment è corretto ma gli utenti rimandano il reboot per giorni, non hai un guasto di SCCM: hai una policy di finestra o una comunicazione da correggere.
Infine, conserva una traccia del change: data, ring, numero di target, esito, errore prevalente e decisione presa. È la documentazione che ti evita di rifare le stesse analisi al prossimo aggiornamento.
Un approccio sobrio vale più di un rollout aggressivo
Aggiornare a Windows 11 25H2 con SCCM non richiede magie. Richiede ordine: prerequisiti chiari, ring piccoli, log letti nel punto giusto e rollback già pensato. Se fai bene questi passaggi, il deployment diventa ripetibile e molto meno fragile.
La regola finale è semplice: prima osserva, poi distribuisci, poi allarghi. In un ambiente gestito con SCCM, questa sequenza è il modo più pulito per trasformare un feature update in un change prevedibile.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.