Guida completa all’aggiornamento di SCCM 2103

L’aggiornamento di SCCM 2103 non si affronta come una semplice patch: è un cambio di piattaforma che tocca console, site server, componenti distribuiti e spesso anche dipendenze esterne come SQL Server, WSUS e i ruoli di sistema operativo sottostanti. La differenza tra un upgrade lineare e un intervento che lascia code di distribuzione, console incoerenti o ruoli in stato degradato sta quasi sempre nella preparazione. Se il sito gestisce ambienti di produzione, il punto non è “se” aggiornare, ma come farlo senza interrompere inventario, distribuzione software e compliance.

Perché l’upgrade di SCCM 2103 va trattato come un cambio controllato

SCCM 2103 appartiene a una famiglia di aggiornamenti in cui il comportamento del sito dipende da più strati: il site server, il database SQL, eventuali remote provider, i distribution point, gli management point e i SUP/WSUS. Se uno di questi elementi è fuori standard, l’upgrade può completarsi solo in parte oppure rallentare in modo anomalo. In pratica, il rischio principale non è il fallimento totale, ma la degradazione silenziosa: console che si apre ma mostra dati vecchi, distribuzioni che restano in coda, ruoli che non ricevono configurazione nuova.

La regola utile è questa: prima si verifica lo stato del sito, poi si mette in sicurezza il rollback, poi si avvia l’aggiornamento. Il contrario è il modo più rapido per trasformare un change pianificato in un incidente di produzione.

Prerogative tecniche da verificare prima di toccare il sito

Prima di aprire il wizard di upgrade, conviene raccogliere evidenze minime e non fidarsi della sola console. L’obiettivo è capire se il sito è già sano. Se non lo è, l’upgrade va rimandato o fatto solo dopo aver chiuso il problema di base.

Controlli essenziali:

• Versione attuale del prodotto e build effettiva del site server.
• Stato dei servizi principali di Configuration Manager.
• Spazio libero su disco sul server del sito e sul volume SQL.
• Salute della replica/connessione verso SQL Server.
• Stato di WSUS se il site usa Software Update Point.
• Presenza di backup recente e verificabile del database e della configurazione critica.

Per la verifica rapida lato server, i servizi e i log sono più affidabili della sola interfaccia. Su un site server Windows, i servizi e i log da controllare in prima battuta sono quelli legati a SMS Executive, componenti del provider e agenti di manutenzione del sito.

Esempio di controllo rapido dei servizi:

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, SMS_DISTRIBUTION_MANAGER, W3SVC | Select Name, Status

Se uno di questi servizi è fermo o in restart continuo, l’upgrade va considerato a rischio. Non è il momento di “provare comunque”.

Backup e rollback: cosa mettere in sicurezza davvero

Il rollback in SCCM non è sempre un pulsante magico. In molti casi il ripristino più realistico è tornare a una situazione supportata usando backup del database, snapshot coerenti della VM o procedure di recovery del sito. Per questo il backup va pensato in modo operativo, non teorico.

Minimo sindacale prima dell’upgrade:

1. Backup completo del database SQL del site.
2. Backup della configurazione del site server e dei file customizzati.
3. Verifica che l’eventuale snapshot sia coerente con la policy interna e con il supporto del vendor.
4. Esportazione o documentazione delle personalizzazioni critiche: boundary, boundary groups, client settings, deployment collections, maintenance windows.

Se il sito è in macchina virtuale e la tua procedura ammette snapshot come parte del rollback, va chiarito prima il punto più fragile: coerenza applicativa. Uno snapshot preso a metà di un’importante attività di maintenance può non essere un rollback affidabile. In alternativa, il piano di rientro va appoggiato al backup SQL e alla reinstallazione del site server secondo la procedura supportata.

Se non sai indicare il punto di ritorno in caso di upgrade fallito, non hai ancora un rollback: hai solo speranza.

Prerequisiti di compatibilità: dove si rompe più spesso

Gli upgrade di SCCM falliscono spesso non per il pacchetto in sé, ma per il contesto. 2103 richiede attenzione a sistema operativo, SQL Server, componenti di terze parti e stato della console. Un ambiente “quasi supportato” è il candidato perfetto per errori ambigui durante la fase di prerequisito o di finalizzazione.

Verifiche da fare con precisione:

• Versione supportata del sistema operativo del site server.
• Versione e patch level di SQL Server.
• Presenza di aggiornamenti pendenti sul server che potrebbero imporre restart.
• Versione della console amministrativa e delle estensioni eventualmente installate.
• Antivirus o EDR con esclusioni adeguate per cartelle e processi del site.

Quando manca un dato, non si indovina: si chiude il gap. Per esempio, se non hai la build esatta del site server, la ricavi dalla console o dai log di setup; se non sai quale SQL build stia gestendo il database, lo verifichi direttamente sul motore SQL con la vista di sistema. Questo evita di partire con un upgrade che poi si ferma per un prerequisito banale.

Un controllo utile lato SQL, se hai accesso amministrativo:

SELECT @@VERSION;

Non serve per fare tuning, ma per capire subito se il motore rientra nel perimetro atteso.

Sequenza pratica dell’aggiornamento di SCCM 2103

La sequenza corretta è: osservare, preparare, eseguire, verificare. Saltare i primi due passi è il modo più comune per dover rincorrere problemi dopo il riavvio.

1. Apri la console SCCM e controlla lo stato generale del sito, con particolare attenzione a component status e replication if presente.
2. Verifica che non ci siano code bloccate o errori persistenti nei componenti di manutenzione.
3. Scarica o prepara il media di aggiornamento secondo la tua procedura interna o la distribuzione prevista dal canale ufficiale.
4. Avvia l’installazione dal nodo primario del sito, non da ambienti non allineati o console remote non certificate per il cambio.
5. Monitora il file di log dell’installazione del site, tipicamente `ConfigMgrSetup.log`, e i log di stato del sito durante tutta la fase di setup.
6. Non forzare riavvii manuali se non richiesti: alcuni passaggi di finalizzazione hanno bisogno di completarsi prima del reboot.

Il punto operativo importante è che il wizard non basta. Durante l’upgrade, i log sono la fonte di verità. Se qualcosa si blocca, il messaggio in console è spesso troppo generico; il dettaglio tecnico è nel log.

Se vuoi monitorare il progresso in modo semplice, cerca queste condizioni:

• Il sito passa da stato di installazione a stato operativo senza errori critici.
• La versione riportata dalla console cambia coerentemente con la build attesa.
• I servizi principali tornano stabili dopo eventuali restart pianificati.
• Le attività di distribuzione e inventario riprendono senza accumulo anomalo di backlog.

Log e segnali da leggere per primi

Durante un upgrade SCCM, la lettura dei log non va fatta in modo casuale. Ci sono alcuni punti che rispondono subito alla domanda: “dove si è fermato davvero il processo?”. Se li ignori, rischi di interpretare un sintomo secondario come causa primaria.

File e segnali utili:

• `ConfigMgrSetup.log` per la fase di installazione e prerequisiti.
• Log di manutenzione e componenti del site per errori di configurazione o timeout.
• Event Viewer di Windows per restart, errori service control manager e problemi di accesso ai file.
• Log SQL se il problema sembra legato a query lente, lock o connectività.

Se il setup segnala un prerequisito mancante, non andare a tentativi. Individua il requisito preciso, correggilo e riparti. Se invece il setup termina ma la console resta incoerente, la priorità diventa capire se il problema è di replica, di cache della console o di un componente che non ha riallineato la propria versione.

Un esempio di approccio utile è cercare nel log parole chiave come prerequisite, failed, restart required e access denied. Sono segnali diversi e portano a cause diverse: mancanza di spazio, permessi, file bloccati o dipendenze non aggiornate.

Convivere con WSUS, SUP e componenti periferici

Se SCCM 2103 gestisce aggiornamenti software, il Software Update Point merita un’attenzione specifica. Il legame con WSUS è una delle fonti più frequenti di upgrade “apparente” riuscito ma poi pieno di anomalie di sincronizzazione. Il site può salire, ma la catena update non necessariamente è sana.

Controlli da fare sul lato update management:

1. Verifica che WSUS sia aggiornato e in stato coerente con la versione del site.
2. Controlla la sincronizzazione del catalogo e gli ultimi errori dei componenti software update.
3. Se usi un SUP remoto, conferma che la connettività e i permessi siano rimasti invariati dopo l’upgrade.
4. Esamina eventuali code di approvazione o deployment che si siano bloccate.

Qui il rischio è doppio: da un lato il problema tecnico, dall’altro il falso senso di sicurezza. La console può mostrare il site in salute mentre gli update non arrivano ai client. La verifica reale è sempre lato processo, non solo lato GUI.

Validazione post-upgrade: cosa deve tornare normale

Finito l’upgrade, non basta vedere la versione nuova nella console. Serve una validazione funzionale, altrimenti il change resta “formalmente riuscito” ma operativamente incompleto.

1. Apri la console da un client amministrativo e verifica che si connetta senza errori di compatibilità.
2. Controlla il numero di versione e la build del site.
3. Verifica che inventario hardware e software continuino a popolare i dati nel database.
4. Controlla la coda di distribuzione verso almeno un distribution point.
5. Se usi compliance o update management, verifica una sincronizzazione completa e l’assenza di errori nuovi nei log.

Una metrica pratica da osservare è il tempo di ritorno alla normalità: quanto impiega il site a riprendere la sua cadenza standard di inventario e distribuzione dopo il restart o dopo la finalizzazione dell’upgrade. Se il backlog cresce invece di scendere, c’è ancora qualcosa che non sta chiudendo correttamente.

Se trovi errori post-upgrade, non partire subito con modifiche invasive. Prima isola il layer: console, site server, SQL, WSUS o rete. L’errore di un solo layer può sembrare un problema generale, ma la correzione giusta è quasi sempre puntuale.

Errori tipici e lettura operativa del problema

Ci sono alcune famiglie di guasto che ricorrono spesso durante l’upgrade di SCCM 2103. Riconoscerle aiuta a ridurre il tempo di diagnosi.

• Prerquisiti non soddisfatti: versioni non supportate, spazio disco insufficiente, restart pendente, componenti non aggiornati.
• Timeout o blocchi: spesso legati a SQL lento, lock sul database o storage degradato.
• Incoerenza post-upgrade: console vecchie, cache locale, componenti periferici non allineati.
• Errori di sincronizzazione update: frequenti quando WSUS/SUP non è stato verificato prima del change.

La risposta corretta a questi problemi non è quasi mai “rifare tutto”. Prima si individua il layer difettoso, poi si applica la correzione minima reversibile. Per esempio: riavvio di un servizio specifico, riallineamento di un componente, pulizia di una coda bloccata, oppure rollback del change se il sito non è più affidabile.

Buone pratiche che evitano il secondo intervento

Un upgrade ben gestito lascia dietro di sé meno lavoro di follow-up. Alcune abitudini riducono molto il rischio di dover intervenire di nuovo il giorno dopo.

1. Esegui il cambio in una finestra in cui puoi osservare il sito per alcune ore dopo il completamento.
2. Documenta la versione iniziale e quella finale con evidenza del log.
3. Lascia traccia delle modifiche a esclusioni antivirus, firewall o account di servizio.
4. Conserva il pacchetto di upgrade e la documentazione di supporto per eventuale analisi successiva.
5. Valida non solo il site server, ma anche almeno un client e un point di distribuzione.

La parte meno glamour ma più utile è la disciplina: ogni upgrade dovrebbe produrre un piccolo dossier tecnico con stato iniziale, azioni svolte, anomalie osservate e verifiche finali. Quando qualcosa va storto, quel dossier vale più di dieci screenshot presi a posteriori.

Decisione finale: quando fermarsi e quando procedere

Se il sito è sano, i prerequisiti sono allineati, il backup è verificato e il rollback è realistico, l’upgrade di SCCM 2103 è un change controllato e gestibile. Se invece mancano evidenze su SQL, spazio, servizi o stato dei componenti, la scelta prudente è fermarsi e chiudere prima i gap. In un ambiente di produzione, il costo di una diagnosi in più è quasi sempre inferiore al costo di un upgrade fatto male.

In sintesi operativa: osserva prima di cambiare, cambia solo con rollback chiaro, e verifica dopo con log e comportamento reale del sistema. Con SCCM la differenza tra “aggiornato” e “operativo” è sottile solo sulla carta; in pratica la fa la qualità della preparazione.