1 14/10/2026 8 min

SCCM 1810 e KB4490575: cosa risolve davvero

La correzione KB4490575 per SCCM 1810 nasce per sistemare un difetto nel flusso degli aggiornamenti e nel comportamento della console durante l’applicazione di hotfix e cumulative update. In ambienti reali il punto non è solo “installare la patch”, ma capire se la site server, la console, i componenti di servicing e il catalogo aggiornamenti stanno lavorando in modo coerente prima e dopo il rilascio.

Su Configuration Manager, quando un hotfix corregge gli aggiornamenti, l’errore tipico non è spettacolare: spesso si manifesta con sincronizzazioni che sembrano andare a buon fine ma non rendono disponibili i pacchetti corretti, console che non mostrano lo stato atteso, oppure componenti che restano in una condizione intermedia. Per questo va trattato come un change controllato, non come una semplice installazione “click and forget”.

Prima di applicarlo: stato atteso contro stato osservato

Stato atteso: la console SCCM 1810 mostra gli aggiornamenti disponibili, la site server elabora il servicing in modo regolare e i log del provider non evidenziano errori legati al download, al prerequisito o alla registrazione del pacchetto.

Stato osservato quando il problema c’è: il pacchetto di hotfix risulta scaricato o parzialmente installato, ma la UI non riflette correttamente lo stato, oppure i log mostrano un errore che blocca la pipeline di update e impedisce di completare il ciclo di manutenzione.

Perché KB4490575 è rilevante in un ambiente SCCM 1810

In un site Configuration Manager, il servicing è delicato perché coinvolge più livelli: database, site control file, componenti server-side, console, e spesso anche prerequisiti lato .NET e Windows Update Agent. Un hotfix che corregge gli aggiornamenti ha valore soprattutto quando il difetto colpisce la visibilità o l’applicazione delle release successive. In pratica, se lasci il problema aperto, il costo cresce con ogni update successivo perché ti ritrovi a diagnosticare sintomi sovrapposti.

Il punto operativo è semplice: prima di fidarti dello stato mostrato in console, devi incrociare la UI con i log. Se la console dice una cosa e i log ne suggeriscono un’altra, la console non basta. Questo vale soprattutto in ambienti con più admin, maintenance window strette e site server con carico alto.

Verifiche minime da fare prima dell’installazione

La prima verifica è il livello di salute generale del site. Non serve fare un audit completo, ma servono almeno tre controlli: spazio disco, stato dei servizi principali e presenza di errori recenti nei log di servicing. Se uno di questi tre punti è fuori scala, applicare l’hotfix senza capire la causa è solo un modo elegante per spostare il problema più avanti.

Su una site server tipica conviene controllare almeno i log legati all’installazione degli update e al component processing. I nomi e i percorsi possono variare con la build e con la topologia, ma la logica resta la stessa: cercare errori di prerequisito, failure di download e mismatch di versione tra componenti. Se hai accesso alla console, verifica anche che il nodo non sia già in uno stato di provisioning o manutenzione incompleta.

Controlli pratici

Una sequenza ragionevole è questa:

  1. Controlla lo spazio libero sul volume che ospita site server, database locale, cache e cartelle temporanee.
  2. Verifica lo stato dei servizi SCCM e di SQL Server se coabitano sulla stessa macchina.
  3. Apri i log di installazione update e cerca errori ripetuti o una sospensione del processo.
  4. Confronta la versione riportata dalla console con quella attesa per 1810 e con l’eventuale hotfix già presente.

Se uno di questi punti fallisce, non procedere a tentativi. Prima chiudi il gap: libera spazio, riavvia solo i servizi coinvolti, o risolvi il prerequisito che blocca l’update. In un change ben fatto, il rollback va sempre pensato prima di cliccare “Install”.

Sequenza consigliata per applicare KB4490575

L’obiettivo è ridurre il blast radius. L’hotfix deve essere trattato come una modifica al controllo del sistema, non come una patch qualsiasi. Se il site è critico, conviene lavorare in finestra di manutenzione e avere pronto il piano di rientro: snapshot della VM, backup della configurazione del site, e almeno una nota chiara sullo stato iniziale.

  1. Documenta la versione corrente del site e lo stato dei componenti principali prima di fare qualsiasi cosa.
  2. Scarica l’hotfix solo dal canale previsto per l’ambiente, evitando copie non verificate o file passati tra colleghi senza tracciamento.
  3. Avvia l’installazione dal percorso previsto dalla console o dal servicing node e non interrompere il processo finché il setup non conclude.
  4. Monitora i log in tempo reale per intercettare errori di prerequisito, timeout o problemi di registrazione del pacchetto.
  5. Al termine, non limitarti al messaggio di successo: fai una verifica funzionale della console e del ciclo update.

Un dettaglio che spesso viene sottovalutato: se il sito è distribuito su più server, il fatto che il primo nodo abbia completato l’installazione non significa che l’intero ambiente sia pronto. Va verificata la propagazione dello stato e l’allineamento tra server, console e database. In ambienti con replica o gerarchie complesse, questo è il punto in cui molti si fermano troppo presto.

Comandi utili per una verifica rapida

Se sei sul site server Windows e vuoi una fotografia rapida dello stato del sistema, puoi partire da controlli elementari. Non sostituiscono i log SCCM, ma aiutano a capire se il problema è infrastrutturale o applicativo.

Get-Service | Where-Object {$_.Status -ne 'Running'}

Questo ti dice subito se c’è un servizio fermo in modo anomalo. Se il risultato è vuoto, non vuol dire che tutto sia sano; vuol dire solo che non hai un guasto evidente lato service control manager.

Get-ChildItem 'C:\Program Files\Microsoft Configuration Manager\Logs' | Sort-Object LastWriteTime -Descending | Select-Object -First 10

Serve per individuare i log toccati più di recente. Se i file non cambiano durante l’installazione dell’hotfix, c’è un problema di processo o di percorso. Se cambiano ma contengono errori ripetuti, hai almeno un punto di partenza concreto.

Per chi preferisce un approccio più conservativo, è utile anche raccogliere uno screenshot o un export della console prima del change. Non è burocrazia: è il modo più rapido per distinguere un effetto collaterale nuovo da un difetto già presente prima della patch.

Come leggere i sintomi dopo l’aggiornamento

Dopo l’applicazione, il primo segnale da guardare non è “la console si apre”, ma se gli aggiornamenti risultano coerenti nello stato e se il servicing continua a processare correttamente. Se la console mostra il nuovo livello ma i componenti downstream non si allineano, il problema non è finito: si è solo spostato di livello.

I sintomi più comuni da tenere d’occhio sono questi: installazione apparentemente completata ma stato update non coerente, errori di sincronizzazione, ritardo nella comparsa del pacchetto, oppure anomalie nel caricamento di alcune sezioni della console. Quando succede, la priorità è capire se il difetto è nel provider, nel database, nel servicing engine o in una dipendenza esterna.

Se il problema è lato console, la verifica più utile è aprire la console da un client diverso o da un profilo diverso per escludere una corruzione locale della cache. Se il problema segue il sito e non la postazione, allora va cercato nel server. Questa distinzione, banale ma fondamentale, evita ore di diagnosi fuori strada.

Rollback e ripristino: cosa preparare prima del change

Un rollback perfetto di un hotfix SCCM non è sempre realistico, ma un piano di rientro sì. Prima di installare KB4490575, prepara almeno un punto di ripristino della macchina virtuale o un backup consistente del server, più una nota dello stato dei componenti aggiornabili. Se il site è fisico, il backup applicativo e del database diventa ancora più importante.

Il rollback operativo non dovrebbe mai essere improvvisato a caldo. Se l’update introduce una regressione, la decisione va presa sul sintomo reale: errori di servicing persistenti, console inutilizzabile, o update chain bloccata. In quel caso il ripristino del snapshot o il ritorno alla baseline precedente ha più valore di un tentativo di “riparazione” a mano senza una traccia chiara.

Assunzione operativa: l’ambiente è di produzione o assimilabile a produzione, quindi ogni modifica va trattata come potenzialmente impattante per gli utenti e per il ciclo di gestione client.

Una nota pratica che vale più della teoria

Con SCCM, gli update vanno sempre letti in relazione alla salute del sito, non isolatamente. KB4490575 non è solo “una patch in più”: è una correzione che ha senso se stai già governando bene log, prerequisiti e manutenzione. Se il tuo processo è debole, la patch non lo rende robusto; al massimo riduce un difetto specifico. La differenza tra un ambiente stabile e uno fragile, in questi casi, la fa la disciplina operativa: verifiche prima, osservabilità durante, conferma dopo.