Se stai valutando l’aggiornamento di Configuration Manager 1902 con l’hotfix KB4500571, il punto non è tanto “installarlo o no”, quanto capire come si incastra con KB4500232 e con lo stato reale del tuo site. In ambienti SCCM, gli hotfix non sono quasi mai pezzi isolati: toccano console, site server, componenti di distribuzione e, in alcuni casi, il comportamento del client. Il rischio vero non è l’update in sé, ma applicarlo senza verificare prerequisiti, baseline e dipendenze già presenti.
Per questo conviene leggerlo come un cambio controllato: prima si fotografa lo stato del sito, poi si verifica se KB4500232 è già stato applicato o se la build di partenza lo rende necessario, infine si pianifica la finestra di manutenzione con rollback chiaro. In SCCM, la differenza tra un aggiornamento lineare e una notte persa sta spesso in tre cose: salute della replica, stato dei componenti e coerenza fra console e site server.
KB4500571 e KB4500232: perché vanno letti insieme
KB4500571 è un hotfix per SCCM 1902; KB4500232 è il riferimento che spesso compare come prerequisito o come correzione correlata nel percorso di aggiornamento. In pratica, il comportamento atteso è questo: il site deve poter assorbire il pacchetto senza cambiare lo stato operativo dei ruoli, la console deve continuare a connettersi al site server, i client devono ricevere policy e deployment come prima, e i componenti distribuiti non devono entrare in stato degradato.
Se il tuo ambiente è fermo a una build iniziale di 1902, la prima domanda non è “qual è l’hotfix più recente?”, ma “qual è la sequenza supportata per arrivare lì?”. Con SCCM è facile confondere il numero di KB con la reale catena di upgrade: alcune correzioni sono cumulative, altre sono dipendenti dalla CU già installata, altre ancora si applicano solo se un componente specifico è stato introdotto o aggiornato. Il risultato pratico è che due ambienti entrambi “1902” possono comportarsi in modo diverso se uno ha già una CU e l’altro no.
Stato atteso vs stato osservato prima di toccare il site
Stato atteso: console raggiungibile, site server in stato healthy, component status senza errori persistenti, coda dei messaggi sotto controllo, database SQL rispondente, e nessun segnale di backlog su distribution point o management point.
Stato osservato da verificare: errori nel file di log del site, componente in warning, aggiornamento che resta in “installing”, console che mostra versioni non allineate, oppure client che smettono di ricevere policy dopo l’update. Se uno di questi segnali esiste già prima dell’hotfix, non attribuirlo all’update a priori: spesso l’update lo rende solo più visibile.
Verifiche minime prima dell’installazione
Prima di lanciare l’aggiornamento, conviene raccogliere prove che ti dicano se il sito è in grado di reggere il cambio. Le verifiche sotto sono volutamente rapide: servono a falsificare le ipotesi più probabili in pochi minuti, non a fare audit completo.
Verifica versione e baseline del site. Nella console controlla Administration > Updates and Servicing e annota build, stato e prerequisiti. Se hai accesso al server, verifica la presenza dei log di aggiornamento in percorsi tipici come
C:\Program Files\Microsoft Configuration Manager\Logs\.Controlla lo stato dei componenti. In Monitoring > System Status > Component Status cerca warning o errori su
SMS_SITE_COMPONENT_MANAGER,SMS_EXECUTIVE,SMS_DISTRIBUTION_MANAGERe componenti legati a replication o content distribution. Il segnale utile non è “qualche warning storico”, ma un errore ripetuto con timestamp vicino all’update.Verifica SQL e spazio disco. Il database deve rispondere senza latenza anomala e i volumi del site server devono avere margine. Un update SCCM che parte con disco quasi pieno o SQL sotto stress è un candidato naturale a restare sospeso o a fallire in fase di post-installazione.
Leggi i log giusti. I primi da guardare sono di solito
hman.log,cmupdate.log,sitecomp.loge, se il problema è lato client o policy,PolicyAgent.logeClientIDManagerStartup.log. L’obiettivo è trovare un errore coerente, non una singola riga fuori contesto.
Se non hai accesso diretto al file system del site server, la stessa verifica si può fare in parte dalla console: stato degli update, component status, e messaggi di errore nei nodi di monitoring. Se invece hai il server, il controllo sui log è il modo più rapido per capire se il problema è di prerequisiti, di installazione o di post-processing.
Ipotesi più probabili quando KB4500571 non si applica pulitamente
Quando un hotfix SCCM si blocca o si installa a metà, le cause ricorrenti sono quasi sempre tre. La priorità qui non è la teoria, ma la capacità di falsificarle rapidamente.
Prerequisito mancante o build non allineata. Se KB4500232 è richiesto o atteso nella catena, l’installazione può fermarsi o completarsi solo parzialmente. Si falsifica in meno di 5 minuti controllando la versione del site, lo stato dell’hotfix precedente e l’eventuale messaggio in
cmupdate.log.Problema di salute del site o dei componenti. Un componente già degradato può far sembrare l’update la causa principale, ma spesso è solo il primo processo a fallire quando il sito è già instabile. Si falsifica controllando
Component Status,sitecomp.loge l’eventuale backlog dei messaggi.Vincoli infrastrutturali: spazio, SQL, permessi, repository WMI. Se il site server ha poco spazio o il servizio non ha i permessi corretti sui percorsi di lavoro, l’update può impallarsi in modi poco eleganti. Si falsifica verificando spazio libero, stato dei servizi e presenza di errori di accesso nei log di installazione.
Procedura pratica di aggiornamento: approccio prudente
La strada più pulita è trattare l’hotfix come un change controllato. Niente salti diretti se non hai già confermato che il tuo ambiente è nella baseline corretta. L’obiettivo è ridurre il blast radius: un site primario sano, backup recente, finestra di manutenzione e un piano di rollback che non richieda improvvisazione.
Fai un backup verificabile. Al minimo: backup del database SCCM, snapshot coerente se la tua infrastruttura lo consente, e copia dei file di configurazione o dei log utili alla diagnosi. Il rollback senza backup è spesso solo una speranza.
Congela i cambi non necessari. Evita di introdurre contemporaneamente nuovi deployment, modifiche ai boundary, aggiornamenti client o cambi ai distribution point. Se qualcosa si rompe, devi poter attribuire l’effetto all’hotfix e non al rumore di fondo.
Installa da console seguendo la sequenza supportata. L’update va applicato dal percorso standard di Updates and Servicing, non con workaround manuali se non hai una necessità documentata. Se il pacchetto richiede KB4500232 o un livello specifico, rispettalo prima di procedere.
Monitora l’installazione in tempo reale. Tieni aperti i log di aggiornamento e la vista Monitoring. Se l’update passa in errore, fermati e raccogli evidenza: non forzare retry continui senza capire il punto di rottura.
Verifica la propagazione. Dopo il completamento, controlla che la console mostri la nuova versione, che i componenti tornino verdi e che i client ricevano policy senza ritardi anomali.
Un dettaglio spesso sottovalutato: in SCCM l’update “installato” non significa “operativo”. Il passaggio davvero importante è la fase post-installazione, quando il site aggiorna schemi, componenti, regole interne e oggetti gestiti. È lì che emergono gli errori più insidiosi, perché la console può sembrare già allineata mentre qualche processo secondario resta indietro.
Cosa controllare subito dopo l’update
Dopo l’installazione, il controllo non deve limitarsi al “semaforo verde” della console. Serve una verifica a livelli, dal management point al client, passando per la distribuzione contenuti e la replica. Se salti questo passaggio, rischi di scoprire il problema quando gli utenti segnalano che le policy non arrivano o che i deployment restano bloccati.
Conferma la versione della console e del site. La versione visualizzata deve essere coerente con l’hotfix applicato. Se la console è aggiornata ma il site no, sei in una zona grigia da indagare subito.
Controlla i componenti critici. Nessun errore persistente in
Component Status, nessun backlog anomalo, nessun loop di restart dei servizi SCCM. Se un componente torna in warning subito dopo il riavvio, cerca prima il log, poi la causa.Valida policy e content distribution. Un client pilota deve ricevere policy e aggiornamenti normalmente; un distribution point deve continuare a servire contenuti senza errori di accesso o hash mismatch.
Osserva i tempi, non solo gli stati. Se il sistema è “verde” ma le policy impiegano molto più del solito, c’è probabilmente una regressione di performance o un problema di coda.
Rollback realistico: quando ha senso e cosa ripristinare
Il rollback in SCCM non è sempre un semplice “disinstalla hotfix”. Dipende da quanto avanti è andata la post-installazione. Se l’update ha solo modificato lo stato del pacchetto ma non ha completato i passaggi successivi, spesso il recupero passa da log, retry controllato o ripristino del backup del site. Se invece sono stati toccati componenti strutturali, il rollback vero deve essere supportato da snapshot o backup coerenti.
In pratica: se il problema è individuato subito e il sistema non è ancora stabile, il rollback più sicuro è ripristinare lo stato precedente verificato e non tentare correzioni creative sul vivo. Se invece l’hotfix è stato applicato ma il sito funziona, il rollback può essere più costoso dell’errore stesso: a quel punto conviene spesso correggere il difetto puntuale e mantenere la baseline aggiornata.
Osservazioni operative che evitano falsi positivi
Ci sono tre errori di lettura che vedo spesso in ambienti SCCM. Il primo è attribuire ogni warning all’ultimo hotfix: in realtà molte code di errore sono vecchie e si riaccendono solo quando il site viene toccato. Il secondo è ignorare il gap tra console e backend: un’interfaccia verde non garantisce che il server abbia finito davvero. Il terzo è non distinguere tra problema di installazione e problema di propagazione; sono due cose diverse e vanno diagnosticate con log diversi.
Un altro punto pratico: se il tuo ambiente ha più site, replica o integrazioni con strumenti esterni, il test non va fermato al primary site. Devi verificare anche i punti di confine, perché spesso l’hotfix non rompe il core ma rende visibile un disallineamento già presente su secondary, DP o console remote.
Decisione finale: quando procedere e quando fermarsi
Procedi con KB4500571 e la catena correlata solo se hai confermato la baseline, la salute del site e la possibilità di tornare indietro. Fermati se trovi errori ripetuti nei log di update, componenti già degradati, spazio insufficiente o una versione non coerente con KB4500232. In SCCM la prudenza non è lentezza: è il modo più veloce per evitare una correzione d’emergenza su un sistema di management che dovrebbe restare prevedibile.
Se vuoi un criterio semplice: l’aggiornamento è pronto quando puoi rispondere con un sì documentato a tre domande — il site è sano, la sequenza di patch è corretta, il rollback è disponibile. Se una di queste tre risposte manca, non è ancora il momento di premere “install”.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.