Hotfix KB36419072 per Configuration Manager: aggiornamento feedback of

Hotfix KB36419072: quando ha senso applicarlo

Su Configuration Manager, un hotfix non va trattato come un aggiornamento “di routine”. Va letto come una correzione mirata che chiude un problema preciso del prodotto, spesso legato a behavior anomali del sito, del client, della console o di un componente di integrazione. KB36419072 rientra in questa logica: prima di installarlo bisogna capire se il problema che stai inseguendo è davvero dentro il perimetro della correzione, oppure se stai usando un hotfix per mascherare un guasto di base, come replica SQL in ritardo, boundary group incoerenti, certificati scaduti o un management point non sano.

La domanda giusta non è “posso installarlo?”. La domanda giusta è “quale sintomo sto correggendo, su quale layer, e come verifico che l’hotfix sia la misura minima reversibile?”. Se non hai ancora una correlazione chiara tra sintomo e patch, fermati e raccogli evidenze prima di toccare il sito.

Classificazione operativa: change controllato, non troubleshooting cieco

Questo tipo di intervento va trattato come change controllato. L’obiettivo non è improvvisare una riparazione, ma applicare una correzione con blast radius noto: il sito primario, eventuali CAS, i management point coinvolti, i componenti di reporting e, in alcuni casi, i client che dipendono dal flusso aggiornato.

Stato atteso vs osservato: ti aspetti che il sito resti stabile, che la console completi i task senza errori, che i componenti critici restino green e che i log non mostrino nuove eccezioni dopo l’update. Se invece osservi errori di installazione, componenti in stato critical o regressioni nei task di distribuzione, il problema non è “l’hotfix in sé”, ma l’ambiente che lo ospita o il prerequisito mancante.

Prima di installare: il layer da controllare è quello del sito

Con Configuration Manager, gli incidenti vengono spesso letti troppo presto come problemi applicativi. In realtà il primo filtro è il layer del sito: replica SQL, spazio disco, servizi SCCM, health degli endpoint interni e stato della gerarchia. Un hotfix può fallire anche se il prodotto è nominalmente “su”, ma uno dei prerequisiti è degradato.

Tre ipotesi da mettere in ordine di probabilità:

1. Prerequisiti incompleti o ambiente non allineato: versione base non compatibile, update precedente non pienamente installato, o componente del sito in errore. Falsificazione rapida: controlla la versione corrente della console e del sito, e verifica che il precedente update abbia completato l’installazione.
2. Servizi o SQL non in stato sano: componenti di site server, SQL Agent, replica o storage instabile. Falsificazione rapida: controlla i log del sito e lo stato dei servizi, più i messaggi di errore nel viewer log o nei log applicativi del prodotto.
3. Problema specifico del fix già noto nel tuo scenario: il tuo sintomo rientra davvero nel perimetro KB36419072. Falsificazione rapida: confronta il comportamento con i prerequisiti e con il dettaglio del problema che il fix dichiara di risolvere, non con una percezione generica di “instabilità”.

Verifiche immediate: cosa guardare prima di lanciare l’update

La verifica minima deve essere osservabile e ripetibile. Non serve una checklist da laboratorio, ma almeno questi punti:

1. Controlla lo stato del sito dalla console: component status, site status e eventuali alert recenti. Se qualcosa è già rosso prima del change, annotalo: il rollback dovrà distinguere tra regressione del fix e problema preesistente.
2. Verifica il livello del prodotto e l’ultimo aggiornamento applicato. Se hai accesso alla console, apri la sezione degli aggiornamenti e controlla che non ci siano installazioni interrotte o in pending.
3. Esamina i log principali del site server. I nomi variano in base al componente, ma devi cercare errori di replica, accesso file, fallimenti di prerequisiti e timeout. Il punto non è collezionare log, è trovare un segnale coerente con il sintomo.
4. Controlla SQL e storage. Se il server è quasi pieno, l’update può completarsi parzialmente e poi lasciare il sito in stato ambiguo. Anche un collo di bottiglia I/O è sufficiente a rendere il change più rischioso del necessario.

Se vuoi una verifica rapida da shell sul server, il minimo sindacale è controllare servizi e spazio:

systemctl --type=service --state=running | grep -Ei 'mssql|sms|config|wmi|sql' || true
df -h

Il risultato atteso è assenza di servizi critici fermi e margine disco sufficiente nelle partizioni coinvolte dal sito e da SQL. Se il disco è vicino alla saturazione, non forzare l’hotfix: libera spazio o sposta il change.

Applicazione controllata: azione minima reversibile

La regola pratica è semplice: prima prepari il rollback, poi esegui l’update, poi verifichi. Non il contrario. Se l’hotfix viene distribuito dalla console, la via più sicura è seguire il percorso nativo del prodotto, perché riduce gli errori operativi rispetto a procedure manuali sparse tra share, pacchetti e script.

1. Backup o snapshot coerente del server del sito e del database, se la tua policy lo consente. Non serve congelare tutto il datacenter, ma serve una via di ritorno credibile.
2. Esporta o documenta lo stato corrente: versione del sito, build della console, componenti con warning, coda dei deployment in corso. Senza questo, il rollback è più politico che tecnico.
3. Avvia l’installazione dell’hotfix dalla console o dal metodo ufficiale previsto dalla tua versione. Non mischiare metodi diversi nello stesso change.
4. Monitora in tempo reale i log dell’installazione e i log del site server. Se compare un errore di prerequisito, fermati subito: non insistere con retry a caso.
5. Concludi solo quando il pacchetto risulta installato e la console mostra lo stato atteso del componente aggiornato.

Se l’installazione non parte o si blocca, la prima mitigazione non è “riprovare finché passa”. La mitigazione corretta è ridurre il rischio: chiudere task concorrenti, verificare spazio e salute SQL, e solo dopo rilanciare una volta. Se il prodotto espone un task o un flag di manutenzione, usalo con cautela e documenta l’impatto sugli operatori.

Come leggere i log senza perdere tempo

La maggior parte degli errori in questi casi si divide in tre famiglie: prerequisiti mancanti, accessi negati e dipendenze non disponibili. Cerca prima i messaggi che indicano fallimento del setup o della registrazione del pacchetto, poi quelli che segnalano problemi verso SQL o verso il file system.

Se usi log testuali, fai una ricerca mirata per timestamp del change:

find /var/log -maxdepth 2 -type f 2>/dev/null | grep -Ei 'config|sms|mecm|site|setup|update'

Su Windows, il principio è lo stesso: apri i log del prodotto e filtra sul timestamp dell’avvio dell’hotfix. Non serve leggere dieci giorni di rumore. Serve trovare il primo errore dopo l’azione.

Il segnale buono è questo: installazione completata, nessun nuovo warning critico, componenti tornati healthy dopo il refresh della console. Il segnale cattivo è un update che sembra riuscito ma lascia il sito in uno stato incoerente, con componenti degradati o console che mostra dati parziali. In quel caso non considerare il change chiuso.

Impatto operativo: dove può colpire davvero

Un hotfix di Configuration Manager può impattare più di quanto sembri, perché il prodotto orchestra distribuzione contenuti, raccolta inventario, policy, reporting e gestione dispositivi. Il blast radius non è solo “il server”: può toccare i client che attendono policy nuove, i DP che ricevono contenuti, i manager che leggono report e gli operatori che usano la console.

Per questo devi definire una metrica obiettivo prima del change. Esempi pratici:

• tempo di completamento dell’installazione dell’hotfix;
• assenza di errori nuovi nei log del site server nelle prime 2 ore;
• nessun incremento del tasso di fallimento nelle distribuzioni o nei task di policy;
• stato healthy dei componenti critici dopo il refresh della console.

Se non hai una baseline, non puoi sostenere che l’hotfix abbia migliorato o peggiorato il sistema. Al massimo puoi dire che “non è esploso subito”, che è una metrica pessima.

Rollback: quello che devi poter fare prima di iniziare

Il rollback in un ambiente SCCM non è sempre banale, quindi va pensato prima. Se la procedura ufficiale prevede il revert del pacchetto o il ripristino del backup, devi sapere in anticipo quale combinazione è supportata dalla tua versione e dalla tua topologia.

In pratica, il rollback deve essere una decisione tecnica, non un atto di panico. I casi in cui lo attivi sono chiari: installazione incompleta con errori ripetuti, regressione funzionale su console o site server, o peggioramento dei tempi di elaborazione e della salute dei componenti. Se il problema è preesistente e l’hotfix non cambia nulla, non chiamarlo rollback: è semplicemente un change non risolutivo.

Prima di procedere, tieni pronto questo schema mentale:

1. Se il sito è instabile prima dell’update, non attribuire automaticamente il danno all’hotfix.
2. Se il sito peggiora subito dopo il change, sospendi ulteriori modifiche e ripristina la condizione precedente secondo la tua procedura approvata.
3. Se il change è riuscito ma il sintomo resta, la causa è probabilmente altrove: query SQL lente, replica, boundary, certificati, DNS interno o un componente esterno.

Controlli finali: cosa deve tornare verde

Dopo l’installazione, i controlli finali non devono essere cosmetici. Non basta aprire la console e vedere che “si avvia”. Devi verificare almeno tre cose: stato del sito, assenza di nuovi errori e ripresa delle attività normali.

1. Controlla che i componenti del sito risultino healthy e che non ci siano warning nuovi rispetto alla baseline raccolta prima del change.
2. Verifica che la console non mostri errori di caricamento o incoerenze nella visualizzazione degli oggetti gestiti.
3. Esegui un test funzionale minimo: una policy, una distribuzione contenuti o un refresh di stato, a seconda del sintomo che ti ha portato all’hotfix.
4. Osserva i log per un intervallo ragionevole dopo il cambio. Se il problema era intermittente, è qui che spesso riemerge.

Assunzione: l’intervento è su un ambiente di produzione o assimilabile, quindi ogni modifica va considerata potenzialmente impattante fino a prova contraria.

Quando l’hotfix non basta

Se dopo KB36419072 il sintomo resta identico, non insistere sulla patch come spiegazione universale. A quel punto devi tornare al layer sottostante: storage, SQL, rete interna, servizi di sistema, limiti di capacità o configurazioni errate. L’hotfix può correggere un bug reale, ma non può sanare un ambiente già rotto.

Il criterio corretto è questo: se hai applicato la correzione, hai verificato il perimetro del problema e non vedi miglioramenti misurabili, apri il campo diagnostico invece di allargare a caso il rischio operativo. Nel mondo Configuration Manager, la differenza tra fix e incidente è spesso solo una buona disciplina nel leggere i segnali giusti al momento giusto.