Aggiornare SCCM alla versione 1906 in 6 passaggi

Se devi portare Configuration Manager (SCCM) alla build 1906, la scelta giusta non è “cliccare avanti” e basta: prima si mette in sicurezza il sito, poi si controlla la catena di prerequisiti, infine si esegue l’aggiornamento dal console con verifica puntuale dei componenti. Il punto non è solo arrivare alla 1906, ma arrivarci senza rompere client management, distribution point, reporting e automazioni già in produzione.

La versione 1906 è un aggiornamento di ramo Current Branch e va trattata come un change controllato. In pratica: finestra di manutenzione, backup valido, spazio disco sufficiente, stato sano del sito primario e attenzione particolare ai ruoli che spesso vengono dimenticati finché non smettono di replicare. Il vantaggio è che l’upgrade è abbastanza lineare; il rischio reale sta quasi sempre nei prerequisiti ignorati o nei componenti già in sofferenza prima del cambio versione.

Prima di toccare l’update: cosa va verificato davvero

Il primo errore tipico è partire senza fare una fotografia dello stato del sito. Prima dell’upgrade conviene verificare almeno quattro aree: salute del database SQL, stato dei componenti del sito, spazio libero sulle partizioni usate da SCCM e coerenza della distribuzione contenuti. Se uno di questi punti è già degradato, la 1906 non “aggiusta” nulla: al massimo rende più evidente il problema.

Controlla anche la versione esatta in uso. Dal console puoi leggerla in Administration > Site Configuration > Sites, oppure via file di setup e log. I riferimenti utili sono il log \Program Files\Microsoft Configuration Manager\Logs\CMUpdate.log e, se stai valutando il prerequisito di un pacchetto di update, anche \Program Files\Microsoft Configuration Manager\Logs\ConfigMgrPrereq.log. Se il sito ha già warning ripetuti lì dentro, non ignorarli: l’upgrade li riporterà solo più in alto nella pila dei problemi.

In parallelo, verifica che il backup del site server sia realmente ripristinabile. Non basta avere una copia “da qualche parte”: serve sapere dove sono database, content library, file di sito e certificati eventualmente usati dai ruoli. Se non hai ancora una procedura formalizzata, questa è la sede per chiuderla, non per improvvisare dopo il reboot del server.

I 6 passaggi per aggiornare SCCM alla 1906

1) Metti il sito in condizioni di upgrade

Il primo passaggio non è l’installer, ma la pulizia del contesto. Ferma operazioni concorrenti pesanti: distribuzioni massive, task sequence critiche, manutenzioni SQL o modifiche infrastrutturali sullo stesso host. L’obiettivo è ridurre il rumore mentre il sito elabora prerequisiti, replica e aggiornamenti di componenti. Se il sito è già sotto carico, l’upgrade si allunga e i falsi positivi aumentano.

Se usi un percorso standard, prepara un backup del database e una snapshot solo se coerente con la policy della tua infrastruttura. La snapshot non sostituisce il backup applicativo, ma può aiutare in un rollback rapido del server se il change è stato pianificato correttamente. Il blast radius resta comunque alto: tocchi il site server e potenzialmente il flusso di gestione di tutti i client.

2) Scarica e valida l’aggiornamento dalla console

L’aggiornamento 1906 si gestisce dalla console di Configuration Manager, nel ramo Administration, sotto Updates and Servicing. Se il pacchetto non compare, il problema non è “l’installazione bloccata”, ma quasi sempre la baseline del sito o la connessione ai canali Microsoft per il download metadati/pacchetti. In questo caso conviene controllare i log di aggiornamento e la sincronizzazione con il service connection point.

Quando il pacchetto è disponibile, aprilo e avvia la verifica dei prerequisiti. Questa è la fase dove emergono le incompatibilità vere: versioni unsupported di SQL, .NET mancanti, problemi di AD schema, ruoli con configurazioni non allineate o componenti di terze parti che interferiscono con il setup. Il file di log da leggere è ConfigMgrPrereq.log, perché lì trovi il motivo esatto del blocco o del warning. Non andare avanti finché non distingui tra warning tollerabile e errore bloccante.

Se un prerequisito fallisce, la correzione va fatta a monte. Per esempio: spazio disco insufficiente sul volume di staging, componenti Windows non allineati, o SQL patchato in modo non compatibile. L’approccio corretto è “falsifica il problema prima di modificare”: verifica il singolo vincolo, correggilo, rilancia la prereq e solo dopo procedi.

3) Avvia l’upgrade e monitora i log giusti

Una volta superata la prerequisita, l’upgrade si avvia dalla console. Da qui in poi il rischio non è più teorico: il sito può restare operativo ma con funzionalità parziali mentre i componenti si aggiornano in sequenza. Non confondere “setup in corso” con “problema”. La differenza la fanno i log e il tempo di avanzamento.

I file più utili sono CMUpdate.log e, a seconda del punto di blocco, i log del componente interessato. Se il setup non progredisce, cerca eventi di download, estrazione, installazione prerequisiti o attivazione componenti. Se l’upgrade sembra partito ma la console non riflette il nuovo stato, il problema può essere solo di refresh o di replication delay, non per forza di fallimento. Anche qui conviene distinguere: stato console, stato log e stato reale del servizio non coincidono sempre nel medesimo minuto.

In questa fase evita di fare altri cambiamenti sul sito. Un upgrade SCCM non è il momento per ridefinire boundary group, cambiare client settings o ristrutturare distribuzioni. Ogni modifica aggiunge variabili e rende più difficile capire cosa ha rotto cosa.

4) Controlla la salute dei ruoli dopo il primo completamento

Quando il pacchetto risulta installato, non considerare il lavoro concluso. Il sito può aver accettato la nuova versione ma avere ruoli ancora in fase di allineamento. Controlla management point, distribution point, software update point, reporting services point e component status. Se uno di questi ruoli è in errore, spesso lo vedi prima nei log del ruolo che nella console.

Per i distribution point, verifica che i contenuti siano ancora distribuiti e che la content library non abbia anomalie. Un upgrade riuscito ma con contenuti non raggiungibili si traduce in fallimenti lato client, e l’effetto pratico è peggiore di un setup che si ferma subito. La metrica da osservare è semplice: percentuale di distribuizioni OK, code di replicazione, error rate dei client e tempo di risposta del management point.

Se usi reporting, apri anche i collegamenti a SQL Reporting Services e conferma che i report standard si aprano. È un controllo banale, ma utile: la parte reporting è una delle prime a mostrare incoerenze quando il sito si aggiorna, soprattutto se l’ambiente ha personalizzazioni o permessi non standard.

5) Aggiorna i client e verifica la compatibilità dei componenti

Dopo il site server, il passo successivo è il mondo client. Non tutti i client si aggiornano nello stesso momento, quindi la domanda giusta non è “la 1906 è installata?”, ma “i client stanno ricevendo policy e nuove funzionalità senza degrado?”. Verifica il deployment del client push, i boundary group e le eventuali esclusioni che impediscono il rollout automatico.

Se hai script, task sequence o integrazioni che dipendono da versioni specifiche del client, questa è la fase in cui vanno controllati. Molti ambienti si rompono non per il sito, ma per un automation layer costruito su assunzioni vecchie. Un esempio classico: report, script di inventario o remediation che leggono campi o comportamenti cambiati di versione e non vengono aggiornati insieme al site.

Il controllo minimo è su un piccolo campione di client rappresentativi: un desktop in LAN, un laptop remoto, una macchina in una boundary secondaria, e se presente un client con scenario VPN. Se tutti e quattro si comportano bene, hai una copertura pratica migliore di un test generico sul solo server.

6) Consolida, documenta e lascia un rollback credibile

La parte finale è quella che spesso manca: consolidamento e rollback. Documenta la versione effettiva, i log con esito positivo, i componenti aggiornati e gli eventuali warning rimasti accettati. Se qualcosa è stato lasciato in stato “deferred”, va scritto chiaramente con la motivazione, altrimenti diventa debito tecnico invisibile.

Per il rollback, la regola è semplice: deve essere possibile tornare indietro al punto precedente senza affidarsi alla memoria. In pratica significa avere backup del database, immagine coerente del server se prevista dalla tua policy, e una nota precisa sul tempo di ripristino stimato. Se il change è stato eseguito in finestra ridotta, il rollback deve essere più rapido del tempo che impiegheresti a inseguire un problema aperto su più ruoli.

Una buona upgrade policy su SCCM non si misura dal fatto che “l’installazione è finita”, ma dal fatto che i client continuano a ricevere policy, i contenuti restano distribuiti e i log non mostrano regressioni nei minuti successivi.

Errori che valgono quasi sempre un blocco o un rallentamento

Ci sono alcuni difetti ricorrenti che fanno perdere tempo più degli altri. Il primo è il disco quasi pieno sul site server o sul volume del database; il secondo è una prerequisita SQL o .NET trascurata; il terzo è una console che mostra uno stato “in progress” mentre il servizio sotto non si è mai allineato. A questi si aggiunge il caso classico dei permessi: account di servizio con privilegi insufficienti o modificati in precedenza senza documentazione.

Un altro punto sottovalutato è la replica tra siti o tra componenti interni. Se hai un hierarchy complesso, la 1906 può essere installata ma gli oggetti non propagarsi come previsto nei tempi attesi. Qui la verifica non è solo visiva: guarda i log di replica, i tempi di consegna dei pacchetti e lo stato degli oggetti nel livello secondario o nei ruoli remoti. È il classico posto dove il problema sembra “l’upgrade”, ma in realtà era una coda già sporca prima del cambio.

Checklist operativa da usare sul campo

Prima di partire, conferma questi punti in ordine:

• backup del database e del site server verificato;
• spazio disco sufficiente su volumi di sistema, staging e content library;
• prerequisiti letti in ConfigMgrPrereq.log senza errori bloccanti;
• canale di update visibile in Updates and Servicing;
• ruoli principali sani prima del change;
• piano di rollback scritto e testato almeno a livello procedurale.

Dopo l’upgrade, conferma invece:

• versione 1906 visibile in console;
• assenza di errori ricorrenti in CMUpdate.log;
• management point e distribution point operativi;
• client campione che riceve policy e contenuti;
• reporting e console accessibili senza degrado evidente.

Quando fermarsi e non andare avanti

Fermati se il prerequisito segnala un errore che non capisci, se il database mostra segnali di sofferenza, se i ruoli critici sono già instabili o se non hai un rollback realistico. In questi casi la scelta più professionale non è “tentare comunque”, ma chiudere il gap prima di toccare la versione. SCCM è tollerante su molte cose, ma non sulla cattiva preparazione del change.

Se invece hai controllato log, stato dei ruoli, spazio e backup, l’upgrade alla 1906 è un’operazione gestibile e ripetibile. Il vero valore non è la procedura in sé, ma l’ordine con cui la esegui: prima osservi, poi correggi, poi aggiorni, poi verifichi. È il modo più semplice per evitare che un update di piattaforma diventi un incidente di produzione.