1 03/11/2026 9 min

Prima di toccare SCCM 1602: verifica stato, prerequisiti e finestra di manutenzione

L’aggiornamento di SCCM 1602 non va trattato come un semplice click in console. Se l’ambiente gestisce distribuzione software, inventory, compliance e deployment su più siti, un upgrade eseguito senza verifiche preliminari può lasciare in errore componenti che magari sembrano sani solo in superficie. La regola pratica è semplice: prima si conferma lo stato del sito, poi si controllano prerequisiti e dipendenze, infine si procede con l’upgrade in una finestra in cui sia possibile osservare log e servizi senza fretta.

Questa guida assume un sito SCCM 1602 già funzionante, con accesso amministrativo alla console e al server del site server. Se il tuo ambiente è distribuito o include CAS, primary site, remote SQL o boundary group complessi, il principio non cambia, ma aumenta il numero di punti da verificare prima di avviare il setup. In caso di dubbio, conviene fermarsi e raccogliere i dati minimi: versione esatta del sito, stato della replication, spazio libero su disco e salute di SQL Server.

Prerequisiti tecnici da confermare prima dell’upgrade

Il punto più importante è distinguere tra ambiente pronto all’aggiornamento e ambiente che “sembra pronto”. SCCM è molto sensibile allo stato dei componenti sotto il cofano: SQL, site control, componenti di distribuzione, management point, distribution point e servizi correlati. Prima di iniziare, controlla almeno questi elementi.

  • Spazio disco sul site server e sul volume che ospita i file temporanei del setup.
  • Stato SQL Server, con database SCCM online e senza errori recenti nel log applicativo.
  • Backup recenti del database SCCM e del sistema, con possibilità reale di ripristino.
  • Permessi amministrativi sulla console e sul server, inclusa la possibilità di leggere i log di installazione.
  • Finestra di manutenzione sufficiente per osservare la propagazione dei componenti e i possibili riavvii dei servizi.

Se vuoi una verifica rapida da server, una prima ispezione del sistema può partire da spazio disco e servizi principali. Non è un controllo esaustivo, ma spesso basta per intercettare il problema più banale prima di avviare l’upgrade.

Get-PSDrive -PSProvider FileSystem
Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, SMS_SQL_MONITORING

Se uno di questi servizi è fermo o il disco di sistema è vicino alla saturazione, non è prudente procedere. Il rischio è di aggiungere un upgrade a una situazione già instabile, complicando diagnosi e rollback.

Verifiche preliminari dentro la console SCCM

In console, il primo obiettivo non è avviare il setup, ma capire se l’installazione corrente è in uno stato coerente. Vai in Administration e controlla la sezione relativa agli aggiornamenti e al servicing. Se esistono alert o prerequisiti non soddisfatti, conviene risolverli prima di andare oltre.

  1. Apri la console SCCM con un account amministrativo.
  2. Vai in Administration > Updates and Servicing.
  3. Verifica se il pacchetto di aggiornamento 1602 risulta disponibile, in download, in prerequisito fallito o già installato.
  4. Apri i dettagli del pacchetto e controlla eventuali errori sui prerequisite check.
  5. Se il pacchetto non compare, verifica il connettore al servizio di aggiornamento e la sincronizzazione del servicing.

Il comportamento atteso è netto: il pacchetto deve risultare visibile e lo stato deve essere leggibile senza errori di connessione o di catalogo. Se la console mostra dati incompleti o non aggiorna lo stato, il problema può essere nel componente di sincronizzazione, non nell’upgrade in sé.

Se il sito è già instabile prima dell’upgrade, il rischio non è solo tecnico ma operativo: un aggiornamento avviato in quelle condizioni può rallentare o bloccare distribuzioni, policy e reporting proprio nel momento in cui servono di più.

Log da leggere prima di confermare il via

Per SCCM i log sono la parte che evita supposizioni. Prima di avviare l’aggiornamento, conviene leggere i file più utili per capire se esistono errori già presenti. I percorsi possono variare leggermente in base all’installazione, ma in genere si lavora sotto la cartella Logs del site server.

  • hman.log per la salute dell’assetto del sito e la gerarchia.
  • mpcontrol.log per i management point.
  • distmgr.log per la distribuzione dei pacchetti.
  • smsexec.log per il servizio principale.
  • cmupdate.log o log analoghi del servicing per la fase di aggiornamento.

Un controllo semplice è cercare errori recenti, warning ricorrenti e time-out. Se trovi già problemi di replica, componenti in retry o errori SQL, l’upgrade va rimandato fino a stabilizzazione. Non è un formalismo: è il modo più veloce per evitare di confondere un problema preesistente con un problema introdotto dall’update.

Get-Content C:\Program Files\Microsoft Configuration Manager\Logs\cmupdate.log -Tail 80
Get-Content C:\Program Files\Microsoft Configuration Manager\Logs\hman.log -Tail 80

Se il tuo site server usa un path diverso, recuperalo dalla console o dalla configurazione locale. Il valore da osservare non è il nome del file in sé, ma la presenza di errori ripetuti e il loro timestamp rispetto alla finestra di manutenzione.

Sequenza operativa consigliata per l’aggiornamento di SCCM 1602

Una volta confermato che il sito è in condizioni accettabili, l’upgrade va eseguito con una logica progressiva: prima si avvia il pacchetto, poi si monitora l’installazione, infine si controllano i componenti che devono riallinearsi da soli. La tentazione di saltare direttamente al “finito” è il modo più rapido per perdersi un errore intermedio.

  1. Apri Administration > Updates and Servicing.
  2. Seleziona l’aggiornamento 1602 e avvia il processo di installazione.
  3. Conferma solo dopo aver letto i prerequisiti e accettato la finestra di impatto prevista.
  4. Lascia lavorare il setup senza aprire sessioni parallele inutili sulla stessa macchina.
  5. Monitora il log di servicing e la console per lo stato di avanzamento.

Durante questa fase non conviene fare altre modifiche infrastrutturali sul sito: niente cambi massivi ai boundary, niente redistribuzioni non necessarie di content, niente manutenzioni SQL programmate nello stesso slot. Il blast radius dell’upgrade è già abbastanza ampio da solo.

Se il setup fallisce nei prerequisiti, la strada corretta non è riprovare più volte alla cieca. Prima si legge il motivo preciso, poi si corregge il blocco e solo dopo si rilancia. In un ambiente SCCM, “retry” senza diagnosi è quasi sempre rumore.

Cosa controllare mentre l’upgrade è in corso

Il monitoraggio va fatto su tre livelli: console, log e servizi. Se uno dei tre diverge, è lì che si nasconde il problema. Ad esempio, la console può mostrare lo stato “in progress” mentre il log è fermo da minuti; in quel caso non bisogna assumere che tutto stia procedendo normalmente.

  • Console: stato del pacchetto, eventuali errori di prerequisito o installazione.
  • Log: progressione coerente delle attività, senza loop o errori ripetuti.
  • Servizi: nessun arresto anomalo di SMS_EXECUTIVE o componenti correlati.

Se il processo si blocca, il primo passo è capire se si tratta di un semplice ritardo o di un errore reale. Un intervallo breve di inattività non è per forza un guasto; un log che non avanza e un servizio in errore sì. La differenza si vede osservando timestamp e stato dei servizi, non andando a intuito.

Post-upgrade: validazioni da eseguire subito

Finito l’aggiornamento, non si chiude la finestra e basta. Vanno verificati i componenti che hanno il maggiore impatto operativo: console, distribuzione contenuti, management point, reporting e client policy. È il momento in cui ci si accorge se l’upgrade è davvero andato a buon fine o se ha lasciato una code di problemi secondari.

  1. Riapri la console e controlla che la versione del sito sia aggiornata correttamente.
  2. Verifica che i componenti principali risultino OK o comunque senza errori persistenti.
  3. Controlla la distribuzione di un contenuto di test verso un distribution point noto.
  4. Verifica che il management point risponda e che i client ricevano policy.
  5. Se usi reporting, controlla che i report principali si aprano senza errori di connessione.

Il criterio di successo non è solo “il setup è terminato”, ma “i servizi del sito tornano operativi e coerenti con la configurazione attesa”. Se la console funziona ma la distribuzione dei contenuti no, hai un successo solo parziale. Meglio scoprirlo subito che dopo la prima richiesta urgente del team desktop.

Problemi tipici dopo l’aggiornamento e come isolarli

Dopo un upgrade di SCCM, gli intoppi più frequenti non sono quasi mai “misteriosi”. In genere rientrano in tre famiglie: componenti non riallineati, SQL o performance degradate, servizi che non ripartono correttamente. La diagnosi migliore è sempre partire dall’effetto osservabile e risalire al layer responsabile.

  1. Console lenta o incompleta: controlla il sito e i log della console, poi verifica il carico SQL.
  2. Distribuzioni ferme: analizza distmgr.log e lo stato dei distribution point.
  3. Client non aggiornati: controlla policy, boundary, MP e tempi di refresh.

Se il problema è lato SQL, la correzione non è quasi mai “riavviare tutto e sperare”. Serve capire se il collo di bottiglia è CPU, I/O, memoria o crescita anomala dei database. Se invece il problema è un componente SCCM che non parte, il focus si sposta su servizio, permessi e dipendenze.

Rollback essenziale se l’upgrade non è sostenibile

Il rollback completo di un aggiornamento SCCM non è sempre banale, quindi va pianificato prima di partire. Il punto non è promettere che tutto si possa annullare in pochi minuti, ma avere una via di uscita chiara se l’upgrade introduce instabilità che non puoi assorbire in produzione.

  • Blast radius: site server, database, componenti di distribuzione, console amministrative e flussi client.
  • Rollback minimo: ripristino da backup del database e della macchina, se l’ambiente lo consente.
  • Verifica di ritorno: versione del sito, stato dei servizi, log senza errori ricorrenti.

In pratica, prima di aggiornare devi sapere quale backup useresti, quanto tempo impiega il ripristino e quali dati o configurazioni rischi di perdere. Se non hai questa risposta, non hai un rollback: hai solo una speranza.

Checklist finale rapida prima di chiudere la manutenzione

Se vuoi ridurre gli errori operativi, usa questa sequenza finale come controllo di coerenza:

  • Versione del sito aggiornata e visibile in console.
  • Nessun errore critico nei log principali nelle ultime ore.
  • Servizi core attivi, in particolare il componente esecutivo del sito.
  • Distribuzione contenuti e policy client verificati su un set di test.
  • Backup e procedura di rollback ancora validi e documentati.

Assunzione operativa: il sito è singolo o comunque gestibile da un team con accesso completo a console, server e SQL, e l’aggiornamento viene eseguito in una finestra di manutenzione con logging disponibile in tempo reale.