SCCM 2006: rollup KB4575789 sostituisce KB4578605

KB4575789 e KB4578605: cosa cambia davvero in SCCM 2006

Su Configuration Manager 2006, il punto non è solo “installare l’ultimo rollup”. Il fatto operativo è che KB4575789 sostituisce KB4578605: se stai pianificando l’aggiornamento, la sequenza corretta va letta come supersedence, non come somma di patch indipendenti. In pratica, il pacchetto più recente incorpora le correzioni già presenti nel precedente e ne aggiunge altre, quindi il rischio principale non è tecnico ma procedurale: applicare il livello sbagliato, nel momento sbagliato, su un sito già parzialmente aggiornato.

Per chi gestisce ambienti SCCM in produzione, questa distinzione conta più di quanto sembri. Un rollup che sostituisce un altro cambia la gestione del change, la lettura della console, la verifica dei prerequisiti e il modo in cui si documenta il rollback. Se il sito è già stato portato a un livello che include KB4575789, reinstallare KB4578605 non aggiunge valore; al contrario, può creare confusione in audit, ticket e controllo delle versioni.

Come leggere la sostituzione: supersedence, non duplicazione

In un contesto Microsoft, la sostituzione tra hotfix o rollup significa che il pacchetto più nuovo è la linea da seguire. Il pacchetto precedente resta utile solo come riferimento storico o per capire quale problema è stato introdotto e poi corretto. Per l’operatore, la domanda giusta non è “li installo entrambi?”, ma “qual è il più recente compatibile con la mia build e con il mio livello di precondizioni?”.

Nel caso specifico di SCCM 2006, la lettura pratica è questa: KB4575789 è il target, KB4578605 diventa il contesto. Se la tua baseline di conformità cita il vecchio KB, va aggiornata. Se hai script di controllo o report che cercano esattamente il numero KB, vanno allineati per non segnalare falsi negativi. Se usi un processo di change con approvazione formale, il ticket dovrebbe riportare il pacchetto effettivamente installato, non quello precedentemente sostituito.

Prima di toccare il sito: cosa verificare in 5 minuti

La verifica minima è tutta sullo stato del sito e sulla salute della replica. Non serve andare subito a tentativi con il setup. Conviene raccogliere tre evidenze: versione del prodotto, stato della replicazione e presenza di errori nei log principali. Se una di queste tre aree è già degradata, il rollup va trattato come change a rischio e non come routine.

Controlli rapidi utili:

• Versione del site server e dei componenti principali nella console: verifica che il sito sia davvero su 2006 e non su una CU o baseline diversa.
• Stato della replication link se hai un hierarchy multi-sito: qualsiasi backlog anomalo va risolto prima del rollout.
• Log del site server e del setup: cerca errori di prerequisiti, accessi mancanti, problemi di database o scrittura su disco.

Se preferisci il controllo da file, i log da guardare sono quelli del server di sito e del setup del componente che stai aggiornando. Il nome preciso può cambiare in base al ruolo, ma la logica no: prima guardi il motivo per cui il sistema potrebbe fallire, poi esegui l’upgrade. Un errore frequente è partire dal presupposto che il rollup si applichi “da solo” perché è una correzione cumulativa. Non è così: il prerequisito operativo resta il sito sano.

Sequenza corretta di rollout in ambiente SCCM

Se il tuo ambiente è stabile e non ci sono incidenti aperti, la regola è semplice: fai un change controllato, non un intervento improvvisato. Il rollout va pianificato a partire dal primario, con attenzione a eventuali CAS, secondary site e componenti remote. L’obiettivo è evitare che un sito secondario o un punto di distribuzione resti in uno stato incoerente rispetto al primario.

1. Conferma la baseline corrente e annota il numero esatto del pacchetto che risulta installato in console.
2. Esporta o salva la configurazione critica del sito e verifica che il backup del database sia recente e recuperabile.
3. Controlla spazio disco sul site server e sul volume che ospita i log: un setup che si interrompe per spazio insufficiente è un classico errore evitabile.
4. Applica il rollup più recente, cioè KB4575789, secondo la procedura standard del tuo ambiente.
5. Attendi la completa propagazione e controlla che la console mostri lo stato di aggiornamento coerente su tutti i ruoli interessati.

Il punto importante è non trattare la sostituzione come un dettaglio cosmetico. Se il change management interno prevede finestre separate per infrastruttura e applicazione, il rollup SCCM va messo nella seconda, ma solo dopo che storage, rete e replica sono stati verificati. In ambienti grandi, il collo di bottiglia non è il file di update: è la propagazione del cambiamento nei componenti distribuiti.

Effetto sui controlli di conformità e sugli script

La sostituzione di un KB con un altro crea spesso un problema laterale: gli script di compliance continuano a cercare il vecchio identificativo. Questo succede con inventari, report PowerShell, baseline di Configuration Manager, checklist di audit e documentazione operativa. Il sintomo non è un guasto del sito, ma un falso allarme che fa perdere tempo e porta qualcuno a ripetere una patch già presente.

Il modo corretto di chiudere il gap è aggiornare i controlli. Se hai un report che interroga il catalogo delle hotfix installate, modifica il filtro in modo che riconosca il nuovo KB. Se il monitoraggio è basato su query SQL o su inventario software, allinea la regola al pacchetto supersedente. Se il controllo è manuale via console, aggiorna la procedura operativa e la schermata di riferimento nel runbook.

Un esempio pratico: un team che considera “non conforme” tutto ciò che non ha KB4578605 potrebbe segnalare errore anche dopo aver installato KB4575789. In quel caso il sito è corretto, il controllo è sbagliato. La correzione non è reinstallare nulla, ma riallineare la regola di verifica alla nuova realtà del prodotto.

Quando il rollout non va: segnali da non ignorare

Se il setup si ferma, i segnali che contano sono pochi e concreti: codice di errore, punto esatto del log, stato del servizio e integrità del database. Non serve inseguire decine di messaggi secondari. Nei rollout SCCM, gli errori più interessanti sono quelli che bloccano prerequisiti, accesso al file system, comunicazione con SQL o registrazione del componente in console.

Tre scenari tipici meritano attenzione:

• Prerquisiti mancanti: il setup si ferma prima di applicare il pacchetto. Qui la verifica è sul log del prerequisito e sulle dipendenze del sito.
• Problemi di replica: il primario si aggiorna, ma gli altri nodi non si allineano. Qui la verifica è sul backlog e sullo stato dei componenti remoti.
• Risorse insufficienti: disco o memoria sotto soglia. Qui la verifica è sullo spazio libero, sui servizi in esecuzione e sugli eventi di sistema.

La mitigazione migliore resta sempre minima e reversibile: fermarsi, raccogliere i log, correggere la causa e riprendere il cambio solo quando il sito torna in uno stato prevedibile. Forzare avanti un aggiornamento su un ambiente già instabile allunga il fermo, non lo riduce.

Rollback: cosa ha senso fare e cosa no

Il rollback in SCCM non va improvvisato come se fosse un semplice uninstall di pacchetto. Se il rollup ha modificato componenti, schema o stato del sito, la strategia di ritorno deve essere definita prima del change. Per questo il backup del database, la documentazione della baseline e l’export della configurazione non sono formalità: sono il piano di recupero.

Se il problema emerge subito dopo l’installazione e il sito è ancora in una finestra di change controllato, la scelta più prudente è interrompere la propagazione, verificare l’impatto e valutare il ripristino dello snapshot o del backup secondo le policy aziendali. Se invece il rollup è già stato assorbito dal sito e i componenti si sono allineati, il rollback va trattato come attività di recovery, non come semplice reversibilità del pacchetto.

Qui il blast radius è chiaro: stai toccando il control plane della piattaforma di management, quindi il rischio non è solo sul server di sito ma anche sulla capacità di distribuire software, raccogliere inventario, gestire compliance e servire i client. Il rollback deve riportare il sito a uno stato documentato, non a una versione “più o meno simile”.

Decisione operativa consigliata

Se stai preparando l’aggiornamento di SCCM 2006, la lettura corretta è questa: considera KB4575789 come il riferimento attivo e KB4578605 come il precedente sostituito. Aggiorna il piano change, i controlli di compliance e la documentazione interna di conseguenza. Prima del rollout, verifica stato del sito, replica, spazio e log; durante il rollout, monitora i segnali di blocco; dopo, conferma che console, servizi e reporting siano allineati al nuovo KB.

Se il tuo ambiente ha già il vecchio KB nei report o nei controlli automatici, il lavoro vero non è reinstallare nulla: è pulire la catena operativa. In piattaforme come Configuration Manager, la qualità del change si vede spesso più nella precisione dei controlli che nella patch in sé.