1 31/10/2026 4 min

KB14978429 su Connected Cache: quando serve davvero

Questo hotfix va trattato come un change controllato, non come una correzione “al volo”. Il punto non è solo applicare un aggiornamento: bisogna prima capire se l’ambiente usa davvero Connected Cache in ConfigMgr, se il componente è sano e se l’aggiornamento è coerente con la versione corrente del sito. In pratica: si parte dall’evidenza, non dall’ipotesi.

Lo scenario atteso è semplice: il sito ConfigMgr è operativo, i Distribution Point con Connected Cache rispondono, i client scaricano contenuti senza errori ricorrenti e non ci sono segnalazioni di saturazione anomala del disco o di cache “bloccata”. Se invece osservi errori di download, cache non popolata, problemi dopo un aggiornamento di site server o comportamenti incoerenti tra DP diversi, l’hotfix può essere pertinente. Prima di toccare nulla, però, conviene delimitare il blast radius: sito primario, eventuali secondary site, DP coinvolti e finestra di manutenzione.

Verifica preliminare della versione e del perimetro

La prima cosa da fare è confermare quale versione di ConfigMgr stai usando e se l’hotfix è effettivamente applicabile a quel ramo. Non assumere che un KB pubblicato sia installabile ovunque: in ConfigMgr la compatibilità dipende dalla build del site server e, in alcuni casi, da prerequisiti già presenti nel console update. Se non hai questi dati, il rischio è semplice: perdi tempo, oppure applichi un pacchetto non corretto per il tuo ambiente.

Controlli minimi da fare subito:

  • Apri la console di ConfigMgr e verifica Administration > Site Configuration > Sites per la versione del sito.

  • Controlla Administration > Updates and Servicing per capire se l’hotfix è già presente, in stato Installed, Available o in errore.

  • Se hai più site system, identifica i DP che usano Connected Cache e annota i nomi esatti dei server coinvolti.

    • Se vuoi una verifica rapida lato server, il punto utile non è cercare “il KB” in astratto, ma incrociare la build del sito con lo stato del componente. In assenza di un dato certo, la cosa corretta è fermarsi e recuperare la build esatta dalla console o dai log del site server, invece di procedere per analogia.

    Diagnosi probabile

    Classificazione dell’intento: change controllato. Lo scenario tipico è un aggiornamento mirato per Connected Cache, con impatto potenziale sui Distribution Point e, indirettamente, sui client che scaricano contenuti da quei nodi.

  • Versione non compatibile o prerequisito mancante. È l’ipotesi più probabile quando l’hotfix non compare come installabile o fallisce in fase di applicazione. Falsifica in meno di 5 minuti verificando versione del sito, stato in Updates and Servicing e presenza di eventuali prerequisiti già installati.

  • Problema locale sul DP o sul servizio Connected Cache. Se l’hotfix è installato ma il comportamento non cambia, il problema può essere nel singolo server: servizio non avviato, cache corrotta, spazio disco insufficiente o configurazione incoerente. Falsifica controllando stato servizio, log del DP e disponibilità disco.

  • Interferenza con distribuzione contenuti o manutenzione in corso. Se il sito è in piena attività di distribution o ha task di manutenzione sovrapposti, l’effetto percepito può sembrare un problema dell’hotfix. Falsifica verificando il workload del sito, i job in corso e gli errori temporanei nei log di distribuzione.

    • Verifiche immediate

    Qui l’obiettivo è raccogliere evidenza minima prima di modificare altro. Non serve una diagnosi “a sensazione”: servono segni concreti di stato del sito e del componente. Se hai accesso ai log, guarda prima quelli; se hai la console, usa quella per confermare l’assetto. L’ordine corretto è: stato componente, log, spazio disco, poi eventuale installazione.

  • Verifica che il DP interessato sia Online e senza alert evidenti nella console.

  • Controlla i log del Distribution Point e del site server per errori relativi a Connected Cache, download content, WMI o installazione update.

  • Conferma che il volume usato per la cache abbia spazio libero sufficiente e non sia vicino alla saturazione.

    • Un controllo pratico, lato server, può essere fatto con i log tipici del ruolo. I percorsi possono variare in base alla versione e alla configurazione, ma in genere i riferimenti utili sono sotto C:\Program Files\Microsoft Configuration Manager\Logs\. Se il tuo ambiente usa percorsi personalizzati, recupera quelli reali dalla console o dalla documentazione interna del sito.

    Get-Content