Distribuire Windows 10 1909 con SCCM: guida pratica

Windows 10 1909 con SCCM: quando la distribuzione va trattata come un change, non come un click

Distribuire Windows 10 1909 con SCCM non è solo “pubblicare un’immagine” e lasciare che i client facciano il resto. Se l’obiettivo è portare una base omogenea, ridurre gli errori manuali e mantenere il controllo sul rollout, la parte delicata sta quasi sempre prima del deployment: raccolta dei requisiti, contenuti corretti, driver coerenti, task sequence pulita e una verifica seria del comportamento in fase di prestart e post-installazione.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

La versione 1909, in particolare, va considerata una release incrementale rispetto alla 1903, ma in ambiente SCCM il dettaglio conta poco: quello che conta è che il pacchetto OS, il boot image e i driver siano allineati al tuo hardware reale. Se un solo pezzo è fuori posto, il sintomo tipico non è sempre un errore esplicito: può essere un task sequence che si ferma, un client che non vede il contenuto, una partizione che viene creata male o un setup che parte ma poi fallisce nella fase di applicazione del driver pack.

Prima decisione: immagine completa o installazione standardizzata

Con SCCM hai due approcci principali: distribuire una reference image già preparata oppure usare una task sequence basata sul media ufficiale di Windows 10 1909 e costruire il resto con passaggi controllati. Nella pratica, la seconda strada è quella che regge meglio nel tempo. Una reference image “pesante” tende a invecchiare male, specialmente quando cambiano driver, aggiornamenti cumulativi o requisiti di sicurezza. Una task sequence ben progettata è più trasparente, più facile da debuggare e più semplice da ripetere su hardware diverso.

Se il parco macchine è eterogeneo, la scelta non è solo tecnica ma operativa: conviene standardizzare il minimo indispensabile e lasciare che SCCM faccia il lavoro di orchestrazione. In altre parole, il sistema operativo deve essere il più vicino possibile al media Microsoft, mentre personalizzazioni, applicazioni e configurazioni devono arrivare dopo, in modo tracciabile.

Prerequisiti che evitano metà dei problemi

Prima di toccare la console, verifica questi punti. Sono noiosi, ma sono anche quelli che fanno risparmiare ore di troubleshooting:

• Site SCCM sano e con Distribution Point raggiungibile dal segmento dei client.
• Boot image aggiornato con supporto WinPE coerente rispetto all’hardware da gestire.
• Driver pack organizzati per modello, non un unico archivio ingestibile.
• Spazio sufficiente sul DP e sui boundary group corretti.
• Account e permessi per l’accesso ai contenuti, senza usare credenziali condivise in chiaro.

La parte dei boundary group viene spesso sottovalutata. Se il client non trova il DP giusto, il problema sembra un errore di OSD, ma in realtà è un problema di distribuzione contenuti o di rete. Lo stesso vale per il boot image: se WinPE non ha i driver di rete o storage necessari, la task sequence fallisce prima ancora di arrivare all’installazione vera e propria.

Importare Windows 10 1909 in SCCM senza sporcare il contenuto

Il punto di partenza è il file `install.wim` del media originale. Non conviene lavorare su copie non controllate o su ISO modificate a mano senza una tracciabilità minima. Monta il media, importa l’immagine di installazione e assegna un nome che dica subito cosa contiene. Un nome chiaro evita errori banali quando, mesi dopo, ci sono più versioni della stessa famiglia in console.

In SCCM, il flusso corretto è: importare il sistema operativo, distribuire il contenuto ai DP, attendere la replica e solo dopo referenziare l’immagine nella task sequence. Se salti questo ordine, il risultato più comune è una task sequence che appare valida ma poi non scarica i file necessari durante l’esecuzione.

Per controllare che il contenuto sia effettivamente disponibile, verifica lo stato di distribuzione nella console e, lato client, osserva i log di OSD quando il dispositivo tenta di recuperare i pacchetti. Il nome del pacchetto, l’ID e il DP di destinazione devono combaciare con quanto hai previsto.

Boot image: il vero collo di bottiglia nelle installazioni PXE

Molti problemi che sembrano “Windows 10 non parte” sono in realtà problemi del boot image. WinPE deve poter vedere la rete, parlare con il DP e, se necessario, accedere allo storage del dispositivo. Per questo il boot image non va trattato come un file statico: va mantenuto, aggiornato e testato sul hardware reale che devi supportare.

Se usi PXE, il boot image deve contenere i driver minimi necessari, non un set casuale di driver accumulati negli anni. Troppi driver nel boot image aumentano il rischio di conflitti e rendono il troubleshooting più ambiguo. Meglio partire con poco, aggiungere solo ciò che serve e documentare ogni modifica.

Un controllo rapido consiste nel verificare che il client arrivi al menu di task sequence e che riesca a contattare il management point. Se la macchina ottiene l’ambiente WinPE ma non trova contenuti o non riceve policy, il problema è quasi sempre a monte: rete, boot image, boundary o distribuzione incompleta.

Driver: meglio per modello che per “cartella unica”

La gestione driver è il punto in cui molte installazioni diventano fragili. Mettere tutto in un solo repository e sperare che SCCM scelga “quello giusto” è un approccio che funziona finché il parco macchine è piccolo. Quando iniziano le differenze tra revisioni hardware, il risultato è spesso un sistema che installa ma poi presenta periferiche sconosciute, rete instabile o sospensioni in fase di primo avvio.

La strategia più solida è organizzare i driver per modello e usare criteri di applicazione basati su WMI o query equivalenti. In questo modo la task sequence può richiamare il pacchetto corretto senza dover filtrare manualmente ogni volta. È un lavoro un po’ più lungo all’inizio, ma riduce drasticamente gli errori durante il rollout.

Un’osservazione pratica: se il vendor fornisce un driver pack ufficiale, usa quello come base e non una collezione di singoli driver reperiti in modo disordinato. I pack ufficiali sono più facili da versionare e da sostituire quando esce un aggiornamento.

Task sequence: la struttura che fa la differenza

La task sequence deve essere leggibile. Se dopo tre mesi non capisci più perché un passaggio è lì, hai già perso. La struttura minima sensata è: preparazione disco, applicazione immagine, configurazione OS, applicazione driver, installazione applicazioni, applicazione aggiornamenti, dominio, policy e verifica finale.

Le variabili della task sequence vanno usate con disciplina. Se ogni reparto o ogni modello di PC introduce eccezioni non documentate, il comportamento diventa imprevedibile. Conviene mantenere pochi punti di personalizzazione e spostarli in raccolte dedicate o in condizioni chiare, non dentro passaggi opachi.

Nel caso di Windows 10 1909, è utile distinguere tra personalizzazioni di base e componenti che possono essere rimandati al primo avvio utente. Non tutto deve passare per la task sequence. Meno roba fai durante l’OSD, meno tempo perdi se qualcosa va storto. Il principio è semplice: l’installazione deve portare il sistema a uno stato affidabile, non a uno stato “perfetto” già al minuto zero.

Applicazioni e aggiornamenti: non mischiare i livelli

Un errore comune è far entrare nella stessa fase applicazioni, patch cumulative e configurazioni di sicurezza, come se fossero equivalenti. Non lo sono. Le applicazioni di base che servono subito possono stare nella task sequence, ma gli aggiornamenti cumulativi e la manutenzione post-installazione spesso rendono meglio se gestiti in una fase separata, tramite ADR o deployment successivi.

Questo approccio ha un vantaggio pratico: se un aggiornamento rompe qualcosa, separi il problema dall’installazione OS. Altrimenti finisci a inseguire un guasto che sembra un difetto di Windows ma è solo una patch applicata nel momento sbagliato.

Per le applicazioni, privilegia quelle essenziali: agent di gestione, antivirus/EDR, strumenti di supporto. Il resto può arrivare dopo, quando il dispositivo è già in dominio e sotto controllo. In ambienti grandi, questa separazione aiuta anche a misurare meglio i tempi di OSD e il tasso di fallimento.

Verifiche pratiche prima di mandare tutto in produzione

Prima di estendere il deployment, fai test su almeno due casi reali: una macchina standard e una macchina “problematicamente normale”, cioè un modello meno recente o con una scheda di rete diversa. Le installazioni perfette su un solo laptop di laboratorio non valgono nulla se poi falliscono sul primo desktop del reparto amministrativo.

Le verifiche minime da fare sono queste:

• Il client parte in PXE o da media e riceve il menu corretto.
• La task sequence scarica i contenuti dal DP atteso.
• L’immagine viene applicata senza errori nella fase di apply OS.
• I driver corretti risultano installati dopo il primo boot.
• Il computer entra in dominio e riceve policy.
• Le applicazioni base partono senza dipendenze mancanti.

Se uno di questi punti fallisce, non andare subito a cambiare dieci cose insieme. Isola il layer: rete, contenuto, boot image, driver, dominio, applicazioni. SCCM è molto più facile da gestire quando il problema viene ridotto a una sola classe di causa.

Log utili da leggere davvero, non da collezionare

Il troubleshooting efficace in SCCM passa dai log giusti. Non serve aprirne venti a caso. Concentrati su quelli che raccontano il percorso reale della task sequence e del download contenuti. In genere, i file più utili sono quelli legati a OSD, contenuti e agent di configurazione sul client.

Se il problema avviene in WinPE, i log si trovano nell’ambiente temporaneo di avvio e non nel percorso finale del sistema installato. Se invece il sistema è già avviato, i log dell’agente client sono più indicativi. Sapere in quale fase si è fermato il deployment vale più di qualsiasi tentativo di “riavvia e spera”.

Quando un deployment si blocca, annota sempre tre cose: fase precisa, ultimo pacchetto scaricato e messaggio di errore completo. Senza questi tre elementi, il troubleshooting diventa una discussione astratta e perde tempo a tutti.

Rollout graduale: la parte che evita di trasformare un test in un incidente

Anche se la task sequence è pronta, non conviene distribuirla a tutto il parco in un colpo solo. Parti da una collezione pilota molto chiara: pochi dispositivi, modelli noti, utenti consapevoli. Solo dopo il primo giro positivo, allarga il target. Questo non è formalismo: è il modo più semplice per ridurre il blast radius quando qualcosa non è ancora stato visto in laboratorio.

Nel rollout graduale, il criterio più utile non è solo il numero di installazioni riuscite, ma anche la qualità dei casi riusciti: tempo totale, eventuali interventi manuali, driver mancanti, comportamento dopo il primo accesso e stabilità nelle prime ore. Se un’installazione “va a buon fine” ma richiede correzioni manuali dopo ogni macchina, il progetto non è ancora pronto.

Manutenzione dopo il rilascio: la parte che mantiene la distribuzione viva

Una distribuzione Windows 10 1909 con SCCM non finisce quando il pacchetto è pubblicato. Va mantenuta. I driver cambiano, i modelli si aggiornano, i DP si riempiono, i boot image diventano obsoleti e le task sequence si trascinano dietro scelte vecchie che nessuno vuole più toccare. Se non metti una revisione periodica, il sistema inizia a degradare in silenzio.

La manutenzione minima sensata include: verifica della salute dei DP, revisione dei driver pack, controllo dei contenuti distribuiti, test periodici del PXE e aggiornamento della documentazione operativa. Anche una nota semplice con la data dell’ultimo test su un modello reale vale più di una console teoricamente perfetta ma mai validata.

Se devi portare questa procedura in un ambiente più ampio, la regola è sempre la stessa: standardizza i passaggi ripetibili, lascia visibili le eccezioni e misura il risultato. SCCM dà il meglio quando lo usi come strumento di controllo, non come sostituto del buon senso operativo.