Distribuire Windows 10 2004 con SCCM e Configuration Manager

Distribuire Windows 10 2004 con SCCM: la parte che conta davvero

Quando si parla di Windows 10 2004 in SCCM, l’errore più comune è trattarlo come un normale aggiornamento di funzionalità. In realtà è un cambio di piattaforma con impatto su compatibilità applicativa, driver, spazio su disco, tempi di deploy e comportamento del client durante il reboot. Se lo si spinge in produzione senza una cerniera di controlli, il risultato tipico non è un fallimento “pulito”, ma una distribuzione a metà: device che scaricano, installano, si riavviano e poi restano bloccati in una delle fasi intermedie.

La strada corretta è semplice da definire ma va eseguita con disciplina: validare l’immagine o l’upgrade package, restringere il pilot, misurare prerequisiti e solo dopo allargare la ring. SCCM/Configuration Manager è adatto a questo lavoro proprio perché consente di controllare collezioni, maintenance window, distribuzione dei contenuti e reporting. Il punto non è “lanciare l’upgrade”, ma costruire un percorso reversibile.

Prima decisione: in-place upgrade o task sequence

Per Windows 10 2004, nella maggior parte degli ambienti enterprise conviene l’in-place upgrade tramite Operating System Upgrade Package o task sequence dedicata. La reinstallazione pulita ha senso solo se l’ambiente è già fragile, il livello di standardizzazione è scarso o si vuole azzerare il debito tecnico locale. In tutti gli altri casi l’upgrade in-place riduce tempi, preserva profilo utente e abbassa il costo operativo.

La task sequence resta utile quando serve governare in modo stretto precheck, driver, BitLocker, partizioni e sequenze di post-action. L’upgrade package è più diretto, ma lascia meno spazio a logica condizionale. Se hai endpoint eterogenei, la task sequence ti dà più controllo; se hai una base omogenea e già pulita, l’upgrade package è più rapido da mantenere.

Prerequisiti operativi prima di toccare la collection

Il primo errore è partire dalla console e non dall’inventario. Prima di distribuire 2004, conviene avere chiari almeno questi punti: versione di partenza supportata, spazio libero su disco, compatibilità di antivirus ed endpoint protection, stato del client SCCM, e presenza di driver che non hanno una storia pulita su quel build. Su macchine con poco margine, l’upgrade può fallire non per il setup in sé, ma per la fase di staging dei file temporanei.

Un controllo rapido utile è verificare che i device target abbiano almeno qualche decina di gigabyte liberi, che il client sia sano e che il contenuto sia correttamente distribuito ai Distribution Point. In ambienti dove la rete è lenta o i DP sono geograficamente distribuiti, il problema non è solo il download iniziale: è anche la resilienza del trasferimento quando il client deve recuperare i pacchetti di setup e i file di compatibilità.

Se hai BitLocker attivo, non dare per scontato che tutto proceda senza interventi. Alcune organizzazioni preferiscono sospendere la protezione prima dell’upgrade e riattivarla dopo il reboot finale. È una scelta operativa, non un dogma: il punto è che questa decisione va definita prima, non quando il deployment è già partito.

Preparare il contenuto in SCCM senza creare rumore

In Configuration Manager, il contenuto va trattato come un oggetto da versionare mentalmente, anche se la console non ti obbliga a farlo. Se importi il media di Windows 10 2004, controlla che il package sia distribuito su tutti i DP necessari e che il pre-cache o il boundary group non stiano introducendo colli di bottiglia. Un errore classico è avere il content distribuito solo sul DP “centrale” e poi scoprire che le sedi remote scaricano tutto da un link WAN poco adatto a un upgrade di massa.

Se usi una task sequence, mantienila essenziale: precheck, eventuale sospensione BitLocker, upgrade, reboot, verifica post-upgrade. Ogni step superfluo aumenta il rischio di debug inutile. Meglio spostare la logica accessoria in script piccoli e leggibili, con log chiaro, piuttosto che costruire una sequenza lunga e fragile.

Un accorgimento che evita molte ore di analisi è definire subito la metrica di successo. Non basta “il PC si riavvia”. La metrica utile è: percentuale di device che arrivano a Windows 10 2004, tempo medio di completamento, percentuale di fallimenti per fase e tasso di rollback. Se non misuri queste quattro cose, stai solo osservando un lotto di installazioni, non un rollout.

Pilot ristretto: la ring che ti salva il weekend

La collezione di pilot deve essere piccola ma rappresentativa. Non prendere solo i laptop dell’IT: includi almeno una combinazione di hardware recente, hardware datato, device remoti, device in sede e, se possibile, un paio di macchine con profili d’uso intensivo. Il pilot non serve a dimostrare che tutto funziona in laboratorio; serve a far emergere gli attriti reali.

Una buona pratica è separare il pilot per anelli: primo anello tecnico molto ristretto, secondo anello operativo con utenti fidati, terzo anello più ampio. In ogni anello, tieni fermo il deployment finché i log e i report non mostrano stabilità. Se un anello fallisce in modo ripetibile, non allargare “per vedere se va meglio”: è il momento di capire se il problema è nel contenuto, nei prerequisiti o in un’applicazione incompatibile.

In SCCM, il vantaggio della gradualità è che puoi leggere l’andamento dei deployment senza confondere il rumore di fondo con un vero problema di piattaforma. Se il pilot mostra errori concentrati su uno specifico modello di laptop o su una specifica linea di driver, hai già una pista concreta. Se invece i fallimenti sono sparsi e casuali, il problema è più spesso di distribuzione contenuti, spazio disco o prerequisiti mancanti.

Log da guardare prima di cambiare una sola impostazione

Prima di modificare policy o rilanciare il deployment, apri i log giusti. Sul client, i riferimenti più utili sono `smsts.log` se usi task sequence, i log del setup di Windows nella cartella `C:\$WINDOWS.~BT\Sources\Panther\`, e i log del client SCCM per capire se il contenuto è stato scaricato e se il comando di upgrade è partito davvero. Sul server, controlla i report del deployment e lo stato dei Distribution Point.

Il pattern conta più del singolo errore. Se il client non scarica nulla, il problema è spesso di boundary, DP o policy. Se scarica e poi fallisce durante la preparazione, guarda spazio disco, antivirus e compatibilità. Se arriva al reboot e poi si ferma, il sospetto si sposta su driver, servizi di terze parti o blocchi post-setup. Questa lettura per layer evita di inseguire sintomi secondari.

Un buon test minimo è verificare dal client che il contenuto sia raggiungibile e che il deployment risulti applicato alla collezione giusta. Se la console dice “success”, ma il device non ha fatto niente, il problema è quasi sempre a monte: targeting, maintenance window o policy non ancora ricevuta.

Gestire i rischi tipici: spazio, driver, antivirus, BitLocker

Lo spazio su disco è il killer silenzioso. Un upgrade di funzionalità non ha bisogno solo del pacchetto, ma anche di spazio temporaneo per estrazione, staging e rollback. Se il disco è vicino al limite, il setup può partire e poi fallire in una fase avanzata, che è la peggiore per l’operatore perché lascia il device in un mezzo stato. La correzione non è “ritentare”: è liberare spazio o escludere temporaneamente i device troppo stretti dal rollout.

Gli antivirus e gli agent di sicurezza possono interferire in modo non ovvio. Non si tratta di disabilitare protezioni a caso, ma di verificare se il prodotto in uso ha note notevoli di compatibilità con il build target. Se esiste una policy vendor per l’upgrade, applicala nel pilot e misura l’impatto. Se non c’è una guida chiara, il problema va trattato come rischio aperto, non come dettaglio trascurabile.

Con BitLocker, la domanda non è solo se l’upgrade riesce, ma cosa succede nella finestra di reboot. In certi ambienti conviene sospendere la protezione con un passaggio controllato e riattivarla al termine. In altri, soprattutto dove il controllo compliance è stretto, bisogna usare il comportamento supportato dal vendor e verificare che il device non resti fuori policy dopo il passaggio di versione.

Sequenza pratica di distribuzione in SCCM

La sequenza più pulita è questa: importazione del media, distribuzione del contenuto ai DP, creazione del deployment verso una collezione pilot, verifica dei prerequisiti, esecuzione controllata, osservazione dei log, espansione graduale. Non saltare il controllo dei DP: molti rollout falliti sembrano problemi di setup ma nascono da contenuti non ancora replicati o boundary group configurati male.

Se usi una task sequence, inserisci uno step di preflight che controlli almeno spazio disco, versione OS, presenza di eventuali software incompatibili noti e stato di BitLocker. Il preflight non deve essere sofisticato; deve essere affidabile. Se il controllo fallisce, è meglio bloccare il device prima dell’upgrade che lasciare il setup tentare la sorte.

Nel deployment vero e proprio, preferisci una finestra di manutenzione quando gli utenti non sono operativi. Se l’upgrade impatta laptop mobili, tieni conto che molti device non saranno in rete esattamente quando li vorresti. In quel caso il vantaggio di SCCM è la persistenza della policy: il device riceve la richiesta quando torna raggiungibile, ma tu devi avere chiaro se questo comportamento è accettabile dal punto di vista del servizio.

Post-upgrade: quello che va verificato davvero

Dopo il passaggio a Windows 10 2004, non fermarti al desktop che compare. Verifica versione build, stato del client SCCM, connettività ai servizi interni, policy di sicurezza, stampa, VPN e le applicazioni business che hanno più probabilità di rompersi. Le applicazioni che parlano con driver, plugin o componenti legacy sono le prime da testare, non le ultime.

Se hai un sistema di monitoring o di inventory software, confronta il numero di device aggiornati con il numero atteso. Il mismatch tra “deployed” e “actually upgraded” è dove emergono i problemi veri. Un device può aver ricevuto il deployment ma non aver completato il ciclo, oppure aver completato l’upgrade ma non aver ancora riportato correttamente lo stato alla console.

Vale la pena controllare anche i servizi di base: rete, gestione remota, eventuale agent EDR, sincronizzazione oraria e accesso a risorse di dominio. Dopo un major feature update, alcuni sintomi sembrano applicativi ma sono in realtà effetti collaterali di driver o policy non perfettamente riallineate.

Rollback e piano di uscita: il pezzo che molti rimandano

Il rollback va definito prima del rollout. Per un upgrade in-place, il rollback reale può essere limitato nel tempo e dipende dallo stato del sistema dopo il passaggio. Per questo motivo conviene conservare una strada di uscita: collezione esclusa dal deployment, sospensione del rollout, eventuale reimaging per i casi irrecuperabili e comunicazione chiara agli utenti coinvolti.

Dal punto di vista operativo, il rollback non è solo tecnico. È anche la decisione di bloccare una ring se gli errori superano una soglia accettabile. Se il tasso di fallimento cresce su un modello specifico o su una branch office, fermarsi è una scelta di qualità, non di prudenza eccessiva. Il costo di una pausa breve è inferiore al costo di un’ondata di ticket.

Se devi tornare indietro, usa sempre una collezione di esclusione o una disabilitazione del deployment prima di fare qualsiasi altra modifica. Così riduci il blast radius e ti lasci aperta la possibilità di riprendere il rollout dopo correzione. Tenere traccia delle versioni di task sequence, dei package e delle policy applicate è la differenza tra un rollback gestito e una caccia al colpevole.

Il criterio giusto per dire che il rollout è andato bene

Un rollout di Windows 10 2004 con SCCM è riuscito quando i device arrivano alla nuova build, restano gestiti dal client, non rompono le applicazioni critiche e il tasso di incidenti non sale oltre la soglia che avevi definito prima. Il successo non è l’assenza totale di eventi: è la presenza di un processo che ti permette di distinguere un problema isolato da un difetto sistemico.

In pratica, il lavoro fatto bene si vede da tre segnali: i log raccontano una sequenza coerente, la console riflette lo stato reale dei device e il supporto utenti non vede un picco anomalo di chiamate. Se uno di questi tre segnali manca, non hai ancora finito: hai solo spostato il problema di fase.

Assunzione operativa: l’ambiente è enterprise, con SCCM già in uso, client gestiti e almeno un canale di pilot disponibile prima dell’estensione alla popolazione completa.