Come installare l’hotfix SCCM KB4578605 su ConfigMgr 2206

KB4578605 va trattato come un change controllato, non come una patch da applicare a occhi chiusi. Su ConfigMgr 2206 il punto non è solo avviare l’installazione: conta soprattutto capire se l’hotfix è davvero applicabile al tuo ambiente, se il sito è in uno stato sano e se hai un rollback credibile prima di toccare il primario.

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

La sequenza corretta è lineare: prima verifiche stato e prerequisiti, poi installi dal nodo giusto della console, infine confermi che il sito abbia completato i post-processing e che la build risultante sia coerente con quanto atteso. Se salti la preparazione, il rischio non è solo un setup fallito: puoi ritrovarti con console incoerente, componenti del sito in degrado o una finestra di manutenzione che si allunga senza motivo.

Nota pratica: se nel tuo ambiente esiste già un aggiornamento cumulativo o un hotfix successivo che include la correzione che ti serve, KB4578605 può essere superfluo. Prima di procedere, confronta sempre il build attuale con le note di rilascio del pacchetto e con la tua baseline interna.

Quando ha senso installare KB4578605

Su ConfigMgr 2206 un hotfix va applicato quando risolve un problema già osservato oppure quando rientra in una policy di manutenzione che richiede l’allineamento a una correzione specifica. I casi tipici sono bug che impattano client, console, distribuzione contenuti, reporting o co-management. Se non hai un incidente attivo, il criterio operativo è semplice: leggi le note del pacchetto, verifica la tua versione e valuta se il beneficio supera il rischio del change.

La verifica più utile, prima ancora di aprire la console, è identificare con precisione la build del sito. Se il tuo ambiente non è realmente su 2206, oppure è già stato aggiornato con un livello più recente che ingloba la correzione, l’hotfix può risultare non applicabile o ridondante.

Per controllare la versione del prodotto puoi usare la console oppure un file di versione locale sul server del sito. Se stai documentando il change, salva anche la data di installazione e l’eventuale CU/hotfix già presente: ti evita ambiguità quando dovrai verificare la compatibilità con i passaggi successivi.

Prerequisiti da controllare prima del change

Prima di aprire la console, verifica questi punti minimi. Non sono formalità: sono la differenza tra un change reversibile e un ticket di emergenza.

• Accesso amministrativo alla console ConfigMgr e permessi adeguati sul sito primario.
• Stato sano dei ruoli core: Management Point, Distribution Point, SMS Provider e SQL Server.
• Spazio libero sufficiente sul volume che ospita file di installazione, log e cache del sito.
• Finestra di manutenzione concordata, perché l’operazione può richiedere riavvii di servizi o una breve indisponibilità della console.
• Backup recente del database e, se la piattaforma lo consente, snapshot della VM del server del sito prima dell’installazione.

Se il sito è apparentemente sano ma il database è sotto pressione, l’hotfix può comunque fallire o restare bloccato in post-processing. In pratica: code SQL, storage lento, errori su SMS_EXECUTIVE o componenti in restart loop sono segnali da correggere prima del change. L’installazione non è il momento giusto per “vedere se regge”.

Per una verifica rapida lato server, controlla lo stato dei servizi principali e i log recenti. Un controllo iniziale utile è questo:

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, SMS_DATABASE_NOTIFICATION_MONITOR, CcmExec | Select-Object Name, Status, StartType

Se uno di questi servizi è fermo o continua a riavviarsi, fermati e identifica la causa prima di procedere. Il punto non è far partire il setup, ma evitare di installare l’hotfix su un ambiente già degradato.

Dove si installa davvero l’hotfix in console

In ConfigMgr gli aggiornamenti di questo tipo si gestiscono dalla console, nell’area dedicata agli aggiornamenti del sito. Il percorso può variare leggermente in base alla build, ma la logica è sempre la stessa: apri la console, vai nella sezione di amministrazione del sito e individua l’aggiornamento disponibile. Da lì puoi valutarlo, avviarlo e monitorarne lo stato.

Il punto importante è non confondere un aggiornamento della console con un aggiornamento di sito. Se il pacchetto è un hotfix site-wide, l’effetto non si limita al client locale: può coinvolgere ruoli, componenti server e, in alcuni casi, prerequisiti per il rollout su hierarchy o console secondarie. Per questo va trattato come una modifica infrastrutturale, non come una patch ordinaria del sistema operativo.

Se più persone amministrano l’ambiente, concorda in anticipo chi esegue il change e chi osserva i log. Eviti il classico doppio click in due console diverse o l’interpretazione sbagliata di uno stato “in progress” che in realtà è già un errore bloccante.

Installazione passo-passo dell’hotfix KB4578605

La sequenza seguente riduce il rischio senza allungare inutilmente la finestra operativa. È il modo più lineare per arrivare a una verifica pulita.

1. Apri la console ConfigMgr con un account che abbia diritti amministrativi sul sito.
2. Vai nell’area degli aggiornamenti del sito e seleziona KB4578605.
3. Controlla prerequisiti, note e dipendenze. Se il pacchetto segnala componenti mancanti o versioni non compatibili, fermati.
4. Avvia l’installazione solo se il sito è stabile e il backup è già stato completato.
5. Monitora lo stato dell’update fino al completamento. Non chiudere la console se vuoi vedere eventuali errori di pre-check o di post-processing.

Durante il setup osserva sempre tre cose: progressione del pacchetto, warning sui prerequisiti e stato finale del sito. Se qualcosa si blocca, non fare retry a caso. Prima individua il log corretto e il messaggio preciso; poi decidi se correggere la causa o annullare il change.

I log più utili, lato server, sono quelli del sito e del componente di installazione. In una installazione ConfigMgr conviene controllare i log standard presenti nella cartella \Microsoft Configuration Manager\Logs sul server del sito, oltre ai file specifici del setup dell’update. Se vuoi aprire rapidamente gli ultimi eventi rilevanti, questo approccio è più utile di un controllo generico:

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

Tra i file da leggere per primi, cerca quelli che descrivono download, prerequisiti, installazione e aggiornamento dei componenti del sito. Se il tuo ambiente usa percorsi diversi, usa il percorso effettivo configurato sul server invece di assumere quello predefinito.

Verifiche dopo l’installazione

Quando il setup termina, non considerare il change chiuso finché non hai verificato che il sito abbia completato tutte le attività di post-processing. Il fatto che la console mostri l’update come completato non basta: il sito può essere ancora impegnato nell’aggiornamento dei componenti interni o nella propagazione delle modifiche.

1. Controlla che lo stato dell’aggiornamento sia completato senza errori o warning bloccanti.
2. Verifica la versione del prodotto dalla console o dal file di versione del sito.
3. Controlla i log principali del sito per confermare che non restino code di errore o componenti in retry.
4. Apri la console da una postazione amministrativa e verifica che non compaiano anomalie di schema, provider o connessione al sito.
5. Se l’ambiente è gerarchico, controlla anche l’allineamento dei componenti secondari o dei ruoli che ricevono l’aggiornamento in cascata.

Un buon criterio operativo è questo: se i servizi core restano stabili, la console si apre senza errori e i log non mostrano nuove eccezioni dopo il completamento, il change è verosimilmente andato a buon fine. Se invece restano warning persistenti, non archiviare il ticket solo perché il setup è arrivato al 100%.

Rollback e blast radius

Il blast radius di un hotfix ConfigMgr non è limitato alla singola console: può coinvolgere sito primario, componenti server, provider, reporting e, indirettamente, i flussi di distribuzione e gestione client. Per questo il rollback va definito prima del change, non dopo il primo errore.

Il rollback realistico dipende dal punto in cui l’installazione si è fermata. Se il pacchetto non ha ancora modificato componenti critici, può bastare interrompere il processo e ripristinare il contesto operativo. Se invece il setup ha già applicato cambiamenti al sito, la strada più sicura è tornare al backup del database e alla snapshot della VM, se disponibili e coerenti con il tuo piano di recovery.

Prima di usare qualsiasi rollback, verifica sempre che il backup sia coerente con il momento del change e che non siano stati introdotti altri aggiornamenti nel frattempo. In assenza di una strategia di ritorno testata, il rischio è peggiorare la situazione invece di correggerla.

Errori tipici da evitare

• Applicare l’hotfix senza aver verificato la build esatta del sito.
• Ignorare warning su prerequisiti, dipendenze o componenti mancanti.
• Procedere con servizi core già degradati o con il database in sofferenza.
• Non avere un backup recente o una snapshot utilizzabile prima del change.
• Chiudere la console troppo presto e perdere gli errori di post-processing.

Assunzione operativa: l’ambiente è in produzione o comunque trattato come tale, quindi ogni modifica va eseguita con osservabilità, backup e possibilità di ritorno. Se manca uno di questi tre elementi, prima chiudi il gap e poi installa l’hotfix.