Hotfix per SCCM 2012 R2: KB2905002 e KB2907591

In SCCM 2012 R2 gli hotfix non si gestiscono bene con la logica del “metto l’ultima patch e basta”. KB2905002 e KB2907591 sono un caso tipico: due aggiornamenti che vanno letti come parte di una catena di correzioni, non come interventi isolati. Se l’obiettivo è tenere stabile la console, la site server chain e i componenti di distribuzione, il punto non è solo installare il pacchetto, ma capire quale sintomo risolve, su quale componente agisce e come verificare che il sito non sia entrato in uno stato incoerente.

La regola pratica è semplice: prima si identifica il problema osservabile, poi si controlla la baseline del sito, quindi si applica l’hotfix con una finestra di modifica minima. In SCCM i guasti “silenziosi” sono più pericolosi dei crash evidenti: una console che si apre ma non sincronizza, un provider WMI che risponde a intermittenza, un componente di distribuzione che resta in retry, una replica che sembra attiva ma non aggiorna correttamente le informazioni. KB2905002 e KB2907591 entrano in questo quadro come correzioni che hanno senso solo se il contesto è già chiaro.

Quando ha senso parlare di KB2905002 e KB2907591

Se SCCM 2012 R2 mostra errori di console, comportamenti anomali del management point, problemi di sincronizzazione o effetti collaterali dopo un aggiornamento cumulativo, il primo controllo non è il pacchetto in sé ma lo stato del sito. Devi distinguere tra errore di applicazione, errore di prerequisito e errore di compatibilità. In pratica: l’hotfix può essere corretto, ma installato nel momento sbagliato o su un ambiente già degradato produce solo rumore.

KB2905002 e KB2907591 vengono normalmente trattati in ambito amministrativo come fix da applicare con attenzione alla versione esatta del ramo SCCM 2012 R2, al livello del CU già presente e alla salute del site server. Il dettaglio importante è che su Configuration Manager i numeri KB non dicono tutto: conta anche l’ordine di installazione, la presenza di prerequisiti e l’eventuale necessità di riavvio o di aggiornamento della console client/server. Ignorare questi aspetti porta al classico scenario “installato ma non risolto”.

Verifiche da fare prima di toccare il sito

Prima di applicare un hotfix su SCCM 2012 R2, la priorità è raccogliere evidenza minima. Non serve fare archeologia del sistema: bastano pochi controlli mirati per capire se il problema è davvero nell’area coperta dal fix.

Controlli utili:

• versione esatta del prodotto in Console > Administration > Site Configuration > Sites oppure nelle proprietà del site;
• stato dei servizi sul site server, in particolare quelli legati a SMS Executive, Provider e componenti SQL correlati;
• log recenti in \<site server>\SMS_<site code>\logs, con attenzione a errori ripetuti e non a eventi isolati;
• presenza di snapshot o backup validi prima del change;
• eventuali modifiche recenti a IIS, SQL, antivirus o policy di hardening che possano falsare il risultato.

Se il sistema è già instabile, la lettura dei log deve essere selettiva. Non inseguire ogni warning: cerca ripetizioni, timestamp allineati al problema e messaggi che indicano fallimento di un componente specifico. Un hotfix non cura un database saturo, un disco quasi pieno o una replica rotta. Se uno di questi fattori è presente, va risolto prima, altrimenti il cambio è solo cosmetico.

Ordine operativo: prima baseline, poi hotfix

Su SCCM conviene procedere sempre nello stesso modo, perché riduce gli errori di interpretazione. La sequenza corretta è: verificare la baseline, raccogliere i log, confermare i prerequisiti, applicare l’hotfix, controllare la propagazione dei componenti. Saltare un passaggio rende difficile capire se il problema è stato davvero risolto o solo mascherato.

1. Verifica la versione del site e annota il build corrente.
2. Controlla che il database e il disco del site server abbiano margine operativo.
3. Esporta o documenta la configurazione critica del sito, almeno per i componenti coinvolti.
4. Chiudi le attività di modifica parallele: niente altri update, niente change su IIS o SQL nello stesso slot.
5. Applica prima l’hotfix che risolve il prerequisito o il difetto di base, poi l’altro se richiesto dalla sequenza ufficiale del tuo ramo.
6. Riavvia solo se il pacchetto o il sistema lo richiedono davvero, non per abitudine.
7. Verifica console, log e componenti distribuiti prima di dichiarare chiuso il change.

Un dettaglio che spesso si sottovaluta: la console può aprirsi normalmente anche quando il backend non è allineato. Quindi il test non è “si avvia”, ma “legge correttamente siti, collections, deployment status e oggetti amministrativi”. Se una vista rimane vuota o rallenta in modo anomalo, il problema non è risolto.

Come leggere il rischio operativo

Il blast radius di un hotfix SCCM non è teorico. Tocca il site server, i servizi di management, il database, la console amministrativa e potenzialmente i flussi verso i client. Anche quando il pacchetto è “piccolo”, l’impatto può essere ampio perché SCCM è un sistema a catena: se un componente resta fuori sync, gli effetti si vedono dopo, non subito.

Per questo il rollback va pensato prima del click. Il rollback realistico non è sempre “disinstalla e torna indietro” — in molti ambienti Microsoft il rollback completo non è così pulito — ma può essere: ripristino della VM, snapshot se approvati dalla policy, restore del site server in finestra controllata, oppure ritorno alla baseline pre-change con sospensione del rollout. Va deciso prima, non quando il sito è già degradato.

Se il sito è in produzione, il criterio corretto è conservativo: meglio rimandare il change di un giorno che entrare in una situazione in cui la console funziona ma i client non ricevono policy. In SCCM questo tipo di degrado è più costoso di un downtime netto, perché può sembrare tutto “quasi ok” mentre i problemi si accumulano in background.

Verifica post-installazione: cosa controllare davvero

Dopo l’installazione, non basta vedere il wizard completato. Bisogna dimostrare che il sistema è tornato coerente. I controlli essenziali sono pochi ma devono essere mirati.

• apertura della console senza errori di caricamento o timeout;
• lettura corretta dei nodi principali del sito e delle collezioni;
• assenza di errori ripetuti nei log del site server nelle ore successive;
• stato dei componenti in Monitoring > System Status senza nuovi critical;
• aggiornamento dell’eventuale reporting o sincronizzazione dei dati verso i punti di integrazione;
• assenza di retry anomali su componenti di distribuzione, management point o provider.

Se hai accesso ai log, il criterio è cercare stabilità, non solo assenza di errori gravi. Un fix riuscito tende a ridurre sia il numero di warning sia la ripetizione dei messaggi. Se gli errori cambiano forma ma non spariscono, probabilmente hai corretto il sintomo e lasciato aperta la causa.

In un ambiente ordinato, la conferma finale arriva da tre livelli: interfaccia, servizi e log. Se la console è accessibile, i servizi sono in stato atteso e i log non mostrano nuove anomalie nell’area interessata, il change può essere chiuso. Se uno dei tre non torna, il fix va considerato incompleto.

Una sequenza pratica per chi deve intervenire adesso

Se devi gestire questo scenario in modo operativo, la sequenza più pulita è quella che minimizza le sorprese. Prima raccogli i dati, poi fai un change reversibile, poi validi. La tentazione di “provare e vedere” su SCCM è pessima: il costo dell’ambiguità è alto.

1. Annota build e stato del sito.
2. Fai un backup o una snapshot approvata secondo la tua policy.
3. Verifica i log del site server e identifica il componente davvero coinvolto.
4. Applica KB2905002 e KB2907591 nell’ordine richiesto dal tuo ramo e dalla documentazione ufficiale interna o Microsoft.
5. Controlla servizi, console e system status.
6. Lascia osservazione attiva per un intervallo sufficiente a intercettare errori ritardati.

Se durante l’installazione compare un errore di prerequisito, non forzare. Fermati, identifica il componente mancante o la versione non allineata, e chiudi il gap con il dato che ti manca: file di log, schermata del wizard, versione del site, stato del database. È meglio avere una prova in più che una correzione approssimativa.

Nota operativa su documentazione e supportabilità

Nel mondo SCCM la documentazione ufficiale e la realtà del campo non coincidono sempre al primo colpo. Per questo conviene conservare traccia del change: versione prima e dopo, orario di applicazione, esito del wizard, eventuali riavvii, e log di verifica. Senza questi elementi, a distanza di giorni è difficile distinguere un fix riuscito da una semplice coincidenza temporale.

Se stai lavorando in team, condividi anche il punto di rollback. Non è un dettaglio amministrativo: è la differenza tra un problema gestibile e un incidente che si allunga perché nessuno sa come tornare indietro in modo pulito. Su sistemi di management centralizzati, la disciplina del change vale più dell’eroismo del singolo intervento.

Conclusione pratica

KB2905002 e KB2907591 vanno trattati come hotfix da applicare con metodo, non come semplice manutenzione ordinaria. Il valore reale non sta nel numero KB, ma nella capacità di inserirli in una sequenza sicura: baselining, change minimo, verifica dei log, controllo della console, osservazione post-change. In SCCM 2012 R2 è questo il modo corretto di evitare il classico falso positivo: “installato” non significa “risolto”.