Aggiornare Windows 10 1903 con SCCM 1902: guida pratica

Aggiornare Windows 10 1903 con SCCM 1902 senza farsi male

Se devi portare una base Windows 10 1903 a una build più recente usando SCCM 1902, il punto non è “lanciare l’aggiornamento”. Il punto è evitare che il task sequence, il contenuto o i prerequisiti ti facciano perdere mezza giornata tra client bloccati, download incompleti e distribuzioni che sembrano sane solo nella console.

Con Windows 10 feature update il comportamento cambia molto meno di quanto sembri, ma i fallimenti tipici restano sempre gli stessi: spazio disco insufficiente, boundary group non coerenti, content distribution parziale, policy non ancora arrivata al client, oppure un requisito hardware che si scopre troppo tardi. In SCCM 1902 conviene lavorare per fasi: preparazione del contenuto, validazione dell’anello pilota, osservazione dei log, poi estensione graduale.

Prima domanda: stai facendo in-place upgrade o refresh controllato?

Per una macchina già in produzione, quasi sempre parliamo di in-place upgrade. È la strada più lineare quando vuoi mantenere applicazioni, profilo utente e configurazione locale. Il refresh con wipe-and-load ha senso solo se devi standardizzare una base sporca o stai già pianificando una migrazione più ampia.

Con SCCM 1902 l’approccio pratico è questo: distribuisci il feature update come oggetto controllato, limiti il target a un collection pilota, verifichi che il client scarichi davvero i file dal DP corretto e poi allarghi il perimetro. Se salti l’anello pilota e vai dritto alla massa, il problema non è “se” troverai errori, ma “quanti” e quanto saranno difficili da distinguere da difetti di rete, storage o policy.

Prerequisiti da verificare prima della distribuzione

La parte noiosa è quella che salva il rollout. Prima di pubblicare il pacchetto o il feature update, controlla almeno questi punti: versione del client SCCM, spazio libero su disco, stato del servizio client, accesso al management point, e coerenza dei boundary group. Sembra banale, ma gran parte dei failure di upgrade nasce da uno di questi livelli, non dal setup di Windows in sé.

Lo spazio libero è il primo filtro. Per un upgrade in-place io considero prudente avere margine reale, non il minimo teorico. Se il sistema è già vicino al limite, il setup può partire e fermarsi quando deve espandere file temporanei o gestire rollback. La verifica più rapida è locale sul client:

fsutil volume diskfree c:

Se il valore libero è risicato, non forzare. Prima pulisci i file temporanei o sposta il client fuori dal rollout. Se il rischio è accettabile e devi procedere, documenta il rollback: sospensione dell’upgrade per quella collection e rimozione del deployment dal gruppo interessato.

Il secondo punto è la connettività verso il Distribution Point. Se il contenuto non è coerente o il boundary non indirizza il client al DP atteso, vedrai download lenti, tentativi ripetuti o errori del tipo contenuto non disponibile. Qui la verifica minima è lato client e lato console: il client deve vedere policy e contenuto, la console deve mostrare distribuzione completata sull’oggetto.

Come impostare il feature update in SCCM 1902

In SCCM 1902 il modo più pulito è usare l’aggiornamento delle funzionalità come oggetto gestito, non come installazione manuale sul client. Questo ti permette di controllare target, scadenza, reporting e soprattutto di avere una traccia chiara di chi è stato incluso e quando. La logica resta semplice: prepari il contenuto, lo distribuisci, lo associ a una collection ristretta, osservi, poi allarghi.

La parte importante è non confondere la pubblicazione del contenuto con l’effettiva esecuzione sul client. In console puoi vedere tutto “verde”, ma se il client non ha ancora ricevuto policy o non riesce a scaricare il payload, l’upgrade non parte. In altre parole, la console ti dice che il piano è pronto; il client ti dice se il piano è eseguibile.

Per ridurre l’errore operativo, usa una collection di test con macchine rappresentative: almeno un portatile, un desktop in LAN e, se presente, un client fuori sede che passa da boundary diversi. Se il pilota funziona solo in ufficio, non hai validato il rollout: hai validato solo la rete interna.

Log da guardare quando qualcosa non parte

Quando l’upgrade non parte, il tempo si perde quasi sempre perché si guarda il log sbagliato. Per il lato SCCM i riferimenti classici sono i log del client in `C:\Windows\CCM\Logs\`, mentre per il setup di Windows il riferimento operativo è `C:\$WINDOWS.~BT\Sources\Panther\`. Non serve memorizzare ogni file: serve sapere dove andare quando la catena si rompe.

Una sequenza utile è questa: prima controlli se il client ha ricevuto policy, poi se ha scaricato il contenuto, infine se il setup ha iniziato davvero. Se il download non c’è, il problema è a monte. Se il download c’è ma il setup fallisce, il problema è nel sistema locale o nei prerequisiti. Se il setup parte e poi torna indietro, allora ti servono i log Panther e il motivo preciso del rollback.

Per una verifica rapida puoi aprire il log del client con CMTrace e cercare parole chiave come download, failed, content, policy e setup. Non è elegante, ma in troubleshooting veloce funziona meglio di mille supposizioni. Se trovi errori di contenuto, torna a boundary group e distribuzione del DP. Se trovi errori del setup, passa ai prerequisiti del sistema operativo e al disco.

Sequenza pratica di rollout

La sequenza che regge meglio in ambienti misti è questa: preparazione, validazione, distribuzione limitata, osservazione, estensione. Saltare uno di questi step sposta il rischio dal server al client, che è il posto peggiore dove scoprirlo perché il danno diventa distribuito e più difficile da correggere.

1. Verifica che il contenuto sia distribuito ai DP corretti e che lo stato della distribuzione sia completo.
2. Limita il deployment a una collection pilota con macchine rappresentative.
3. Forza il recupero policy sul client e conferma che l’oggetto compaia nel Software Center o nel meccanismo di aggiornamento previsto.
4. Monitora i log del client e il consumo di disco durante il download e l’installazione.
5. Solo dopo esito positivo estendi il deployment alla collection successiva.

In questa fase il controllo più utile non è la percentuale di successo “globale”, ma il numero di client che mostra comportamento uniforme. Se un solo gruppo geografico fallisce, il problema è spesso boundary, rete o DP. Se falliscono tutti in modo simile, guarda il pacchetto, il contenuto o il prerequisito comune.

Errori tipici e come interpretarli senza perdere tempo

Un errore frequente è il download che sembra avviarsi ma non completa mai. In quel caso non partire subito dal setup di Windows: controlla prima spazio su disco, cache del client e raggiungibilità del DP. Un’altra trappola è il client che riceve la policy ma non mostra alcuna azione nel Software Center: spesso il problema è la valutazione della collection o la scadenza del deployment, non l’upgrade in sé.

Se il sistema riavvia durante l’upgrade e poi torna alla build precedente, il rollback di Windows ha fatto il suo lavoro. Questo non è un successo, ma è un segnale utile: il setup ha trovato un blocco serio. I candidati più comuni sono driver incompatibili, antivirus troppo invasivo, storage insufficiente o un’applicazione che interferisce con la fase di migrazione. Qui il fix non è “riprovare a caso”: serve leggere il motivo nel log Panther e correggere la causa prima di rilanciare.

Quando il problema è il boundary, il sintomo è molto più subdolo: tutto sembra pronto, ma il client scarica da un punto non ottimale o non trova il contenuto. In reti distribuite questo si traduce in tempi lunghi e failure intermittenti. La correzione è quasi sempre di design: boundary group coerenti, DP vicini al segmento e una verifica reale del path usato dal client.

Rollback e piano di sicurezza

Ogni aggiornamento di feature dovrebbe avere un rollback operativo prima ancora di iniziare. Nel caso di SCCM, il rollback più semplice è bloccare l’espansione del deployment e togliere il target dalla collection se emergono errori sistematici. Se l’upgrade è già partito sul client, il rollback vero è il ripristino della build precedente tramite il meccanismo di Windows, ma non va considerato una strategia normale: è una rete di sicurezza, non una procedura da usare con leggerezza.

Se stai lavorando su ambienti con dati sensibili o applicazioni critiche, valuta anche la finestra di manutenzione e l’impatto sul supporto. Un client che riavvia fuori orario può essere un problema minore in laboratorio, ma non in una postazione di produzione con sessioni aperte o processi locali. Qui il blast radius non è il server SCCM: sono gli utenti finali e le applicazioni che dipendono dalla continuità del sistema.

Prima di allargare il rollout, conserva almeno questi elementi: la collection pilota, lo stato della distribuzione, i log di un client riuscito e di uno fallito, e la versione esatta del build target. Senza questi riferimenti, quando qualcosa va storto ti ritrovi a discutere di impressioni invece che di evidenze.

Quando conviene fermarsi e correggere il design

Se più del previsto fallisce per motivi diversi, non stai davanti a un problema di singolo client: stai vedendo un problema di processo. In quel caso conviene fermare il rollout, analizzare la distribuzione del contenuto, la qualità dei boundary, la salute del client SCCM e la compatibilità delle macchine coinvolte. Continuare ad allargare il deployment mentre i sintomi aumentano significa solo moltiplicare il rumore.

Un buon criterio pratico è questo: se il fallimento è ripetibile su una classe di macchine, correggi il design; se è isolato e legato a una singola postazione, correggi il client; se è legato alla rete o al DP, correggi il percorso di distribuzione. È una distinzione semplice, ma evita di spendere ore su ipotesi sbagliate.

In sintesi, aggiornare Windows 10 1903 con SCCM 1902 funziona bene quando tratti il rollout come un processo osservabile, non come un click in console. Il successo sta nel controllo dei prerequisiti, nella qualità del contenuto distribuito e nella capacità di fermarti appena i log dicono che qualcosa non torna.