Guida passo passo all'aggiornamento di SCCM 2111

Prima di toccare SCCM 2111: decide se stai facendo manutenzione o recupero

L’aggiornamento di Configuration Manager 2111 non va trattato come un semplice click in console. In pratica stai cambiando il comportamento del management point, del site server, dei componenti di distribuzione e, se hai gerarchie più articolate, anche della catena di replica e dei client. La differenza tra un cambio pulito e una giornata persa sta quasi sempre nella preparazione: stato della build di partenza, salute dei ruoli, spazio disco, backup e finestra di manutenzione reale.

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

Se l’obiettivo è portare il site alla release 2111, la regola è semplice: prima osservi, poi aggiorni, poi verifichi. Non fare affidamento sulla sola presenza del pulsante “Upgrade” in console. Se il sito è già instabile, l’upgrade amplifica il problema invece di risolverlo.

Questa guida assume un ambiente Microsoft Configuration Manager con site server on-premises e console amministrativa accessibile. Se hai prerequisiti non allineati, come SQL degradato, spazio insufficiente o componenti in errore, chiudi prima quei punti: l’aggiornamento non è il posto giusto per scoprire che il sito era già in sofferenza.

Controlli preliminari che evitano il 90% dei problemi

Prima di lanciare l’update, verifica almeno questi elementi: versione di partenza supportata, stato dei componenti principali, spazio libero sul volume di installazione e integrità della connettività verso SQL Server. In SCCM il vero rischio non è solo il fallimento del setup, ma una coda di componenti parzialmente aggiornati che poi richiede interventi manuali.

La verifica più utile è quella che ti dice se il site è già sano. Non basta che la console si apra: devi controllare i log del site server, il Data and Reporting Services point se presente, il management point e il distribution point. Un sito con warning ripetuti nei log di componenti chiave è un candidato cattivo per un upgrade diretto.

Se hai accesso al server, controlla anche lo spazio disco sul volume che ospita `CMTrace`, i log di installazione e la cartella di setup del product. Gli upgrade SCCM soffrono molto i sistemi “quasi pieni”: bastano pochi GB in meno del previsto per bloccare estrazioni, rollback e staging temporanei.

Un altro punto spesso sottovalutato è il backup. Non serve il backup “in teoria”: serve sapere dove si trova, quanto è recente e come ripristineresti il site in caso di errore. Se non hai un piano di restore testato, l’aggiornamento non è un change banale, è un rischio operativo.

Sequenza consigliata per l’aggiornamento di SCCM 2111

La sequenza sotto è pensata per ridurre il blast radius. Non è l’unico modo possibile, ma è quello che lascia più spazio alla verifica tra un passaggio e l’altro. Se qualcosa va storto, sai esattamente in quale fase si è rotto il flusso.

1. Conferma lo stato del site. In console vai su Monitoring e controlla Site Status, Component Status e Replication se hai più siti. Cerca errori ricorrenti, componenti in critical e backlog anomali. L’upgrade va iniziato solo con segnali di salute coerenti.
2. Verifica prerequisiti e spazio. Sul site server controlla il disco di sistema e il volume dei log. Se il margine è stretto, libera spazio prima del cambio. Il punto non è “avere abbastanza”, ma avere margine per file temporanei, log e rollback.
3. Salva la configurazione e fotografa lo stato. Esporta o annota i parametri importanti: ruoli installati, boundary group critici, client settings personalizzati, maintenance windows e impostazioni dei deployment più delicati. Non è documentazione cosmetica: è la rete di sicurezza se devi ricostruire la situazione.
4. Apri la console e controlla gli update disponibili. In Administration vai su Updates and Servicing. Se 2111 è presente, verifica che il prerelease o il baseline previsto sia quello corretto per la tua branch. Se l’update non compare, il problema non è il click: è il canale di servicing o lo stato del sito.
5. Avvia l’installazione. Seleziona l’update e lancia il wizard. Lascia attivi i controlli standard e non disattivare verifiche per “velocizzare”: quello che salti ora lo paghi dopo in troubleshooting.
6. Monitora la fase di prerequisiti. Durante l’installazione controlla i log del site server, in particolare i log di aggiornamento e prerequisiti. Se compare un blocco, fermati e correggi la causa prima di rilanciare. Non forzare un upgrade con prerequisiti in errore.
7. Completa il setup e aspetta la stabilizzazione. Anche quando il wizard termina con successo, il lavoro non è finito. Il site può impiegare tempo a riallineare componenti, console extension e servizi correlati.
8. Aggiorna prima il server, poi la console. Le console non allineate possono mostrare problemi fittizi o nascondere stati reali. Aggiorna le console amministrative solo dopo che il site server ha completato la transizione.
9. Valida i ruoli secondari. Controlla management point, distribution point, software update point e reporting point, se presenti. Spesso il problema non è il core site, ma un ruolo periferico che resta indietro.
10. Alza gradualmente il livello di fiducia. Prima verifica i componenti infrastrutturali, poi i deployment, infine il comportamento dei client. Non dichiarare l’upgrade riuscito solo perché il wizard è verde.

Log e segnali da guardare davvero

In SCCM la console è utile, ma i log restano la fonte più affidabile. Se vuoi capire dove sei bloccato, cerca prima il log del processo di update sul site server e poi i log dei componenti coinvolti. I nomi possono variare in base al ruolo, ma la logica è sempre la stessa: update orchestration, installazione prerequisiti, componenti del site, replica e client communication.

Un errore frequente è guardare solo il log “principale” e ignorare quello del componente che ha realmente fallito. Per esempio, se l’update sembra fermo, il problema può essere un prerequisito SQL, un servizio fermo, un permesso errato sulla cartella di staging o un problema di replica. Il sintomo è uno, la causa è spesso altrove.

Se hai CMTrace disponibile, usalo per leggere i log con timestamp e correlare gli eventi. In un upgrade SCCM la cronologia conta più della singola riga di errore. Una sequenza coerente di warning, retry e fallback vale più di un messaggio isolato preso fuori contesto.

CMTrace.exe

Se non hai accesso a CMTrace, puoi comunque aprire i log con un editor testuale, ma perdi la lettura ordinata delle righe. In quel caso annota l’orario esatto in cui hai avviato il cambio e incrocialo con l’evento nei log del site server e nei registri di sistema di Windows.

Quando l’upgrade si ferma a metà

Se l’aggiornamento rimane in stato intermedio, il primo passo non è riavviare tutto. Prima stabilisci se il blocco è dovuto a prerequisiti, a un servizio non rispondente o a un problema di storage. Riavviare senza diagnosi rischia di peggiorare il coordinamento interno del site.

Le cause più probabili sono tre. La prima è la mancanza di spazio o di risorse sul server. La seconda è un componente del site già degradato prima dell’update. La terza è un problema nel canale di distribuzione del pacchetto di aggiornamento, ad esempio download incompleto o file corrotti nel percorso temporaneo. In meno di cinque minuti puoi falsificare la prima ipotesi controllando disco e memoria, la seconda guardando lo stato dei componenti, la terza verificando la presenza dei file di staging e i messaggi di download nel log.

Se il blocco persiste ma non hai errori chiari, evita di tentare correzioni creative. Il vantaggio di un upgrade SCCM è che lascia tracce abbastanza precise: se le leggi con ordine, trovi il collo di bottiglia. Se invece fai ripartire servizi a caso, perdi il contesto e allunghi il recovery.

Verifiche post-aggiornamento che contano davvero

Dopo il completamento, la prima verifica non è estetica. Controlla che il site sia in stato operativo, che la console riporti la nuova versione e che i ruoli principali rispondano correttamente. Un upgrade apparso riuscito ma con componenti in errore è solo un successo parziale.

Le verifiche minime dovrebbero includere: ricezione dei client policy, distribuzione contenuti verso almeno un distribution point, stato del management point e accesso ai report se il reporting è in uso. Se uno di questi elementi non risponde, non considerare l’upgrade chiuso. Il problema potrebbe essere nel ruolo, non nel core site, e lasciarlo irrisolto crea un guasto differito.

Un buon criterio pratico è osservare il comportamento dei client pilota. Se i client test aggiornano policy, ricevono deployment e comunicano con il site senza errori, hai un segnale forte che l’infrastruttura è tornata stabile. Se invece i client iniziano a generare errori di registrazione, distribution o policy retrieval, devi tornare sui log e capire quale componente non ha completato la transizione.

Conferma anche che le maintenance window, i boundary group e le impostazioni di compliance non siano stati alterati indirettamente. Gli upgrade non dovrebbero cambiare la logica funzionale, ma ogni ambiente ha le sue eccezioni: vale la pena verificare i punti che hanno più impatto operativo.

Rollback e piano di rientro: cosa fare se 2111 non regge

Il rollback di un upgrade SCCM non è mai una scorciatoia da improvvisare. La vera protezione è il backup del site e la possibilità di ripristinare il server o l’ambiente secondo la tua procedura standard. Se non hai un piano di rientro documentato, il “rollback” diventa un esercizio di ricostruzione manuale con tempi imprevedibili.

Se il problema è limitato a un componente o a una console, la mitigazione può essere più semplice di un restore completo: ripristino del servizio, reinstallazione del ruolo o allineamento della console. Se invece il site server non si stabilizza e i log indicano corruzione della procedura di update, devi seguire il piano di recovery che hai predisposto prima del change.

Prima di qualsiasi azione drastica, conserva i log dell’installazione e i riferimenti temporali degli errori. Sono il materiale che userai per capire se il fallimento è dovuto a prerequisiti, a una dipendenza esterna o a un difetto del pacchetto applicato. Senza questi dati, il troubleshooting diventa una sequenza di ipotesi cieche.

Una lettura pratica del rischio

Il rischio reale di un upgrade SCCM 2111 non è solo l’interruzione del servizio, ma l’asimmetria tra ciò che la console mostra e ciò che l’infrastruttura sta davvero facendo. Puoi avere una UI apparentemente a posto e, sotto, un componente che continua a ritentare l’aggiornamento o a generare warning silenziosi. Per questo la procedura va sempre letta come una catena: controllo, cambio, verifica, stabilizzazione.

Se lavori in produzione, pensa all’upgrade come a un change controllato con osservabilità obbligatoria. Non è il tipo di attività che si fa “quando c’è tempo”. Va pianificata, monitorata e chiusa con criteri chiari. La differenza tra un cambio gestito bene e uno che diventa incidente è quasi sempre la qualità della verifica iniziale e del monitoraggio immediatamente successivo.

In sintesi operativa: entra nell’upgrade solo con un site sano, spazio sufficiente, backup verificato e log sotto controllo. Avvia il change, osserva i prerequisiti, completa l’installazione e valida il comportamento reale dei ruoli e dei client. Se qualcosa non torna, fermati sui dati, non sulle impressioni.