1 20/10/2026 10 min

SCCM 1802 e KB4339794: cosa cambia davvero sui client

In ConfigMgr 1802, KB4339794 non è un dettaglio cosmetico: serve a portare i client a un livello più stabile, soprattutto quando l’ambiente mostra sintomi intermittenti su policy, inventario, deployment o comunicazione con il management point. Nella pratica, il punto non è “installare una patch”, ma capire se il parco client è omogeneo, se il sito è sano e se l’aggiornamento può essere spinto senza introdurre rumore operativo. In un’infrastruttura SCCM, la parte fragile non è quasi mai il pacchetto in sé: è la combinazione tra versioni miste, client già degradati, boundary non coerenti e finestre di manutenzione gestite male.

Prima di toccare i client, conviene inquadrare il problema con un criterio semplice: stato atteso vs stato osservato. L’atteso è un client ConfigMgr 1802 allineato alla baseline supportata dal sito, capace di ricevere policy, inventario hardware e software, conformità e deployment senza retry anomali. L’osservato, quando KB4339794 serve davvero, è spesso un insieme di segnali deboli: client che restano su versioni vecchie, coda di policy che non si svuota, errori nel log del client, oppure differenze di comportamento tra subnet o boundary group.

Quando vale la pena applicare KB4339794

Non tutte le installazioni 1802 richiedono la stessa urgenza. Il pacchetto ha senso quando devi correggere comportamenti lato client che impattano la gestione quotidiana: valutazioni di compliance incoerenti, inventory che arrivano a singhiozzo, distribuzioni che falliscono senza un pattern chiaro, o client che faticano a rinnovare l’assegnazione al site. Se l’ambiente è già in fase di aggiornamento verso una release successiva, il valore della KB cambia: può essere utile come step intermedio, ma non va trattata come una cura universale. Se il problema è architetturale, ad esempio boundary errati o MP sovraccarico, la patch da sola non risolve.

Un punto spesso trascurato è che il client ConfigMgr non vive isolato. Dipende da servizi Windows locali, da connettività verso MP e DP, da certificati se l’ambiente è HTTPS, da WMI, da spazio disco sufficiente e da una certa pulizia nel repository locale. Se uno di questi elementi è già compromesso, l’aggiornamento può riuscire formalmente ma lasciare il client in uno stato peggiore: versione aggiornata, comportamento ancora instabile. Per questo, la sequenza corretta è osservare prima, modificare dopo.

Verifiche preliminari sul sito e sul parco client

La parte più utile non è il download della KB, ma la fotografia iniziale. Prima di distribuire, controlla il sito e alcuni client campione. L’obiettivo è capire se il problema è diffuso o circoscritto. I file di log da guardare dipendono dal ruolo, ma lato client i riferimenti più frequenti sono ccmexec.log, ClientLocation.log, LocationServices.log, PolicyAgent.log, DataTransferService.log e InventoryAgent.log. Sul server, se il problema è di propagazione o distribuzione, i log del site server e del management point aiutano a distinguere un difetto di contenuto da un difetto di comunicazione.

Una verifica rapida del client può partire da PowerShell o dal prompt amministrativo. Non serve fare tuning: serve capire se il client vede il sito, se parla col MP e se il repository locale è in uno stato coerente. Un controllo minimo può essere questo:

Get-Service CcmExec
Get-WmiObject -Namespace root\ccm -Class SMS_Client
Get-Content C:\Windows\CCM\Logs\ClientIDManagerStartup.log -Tail 50
Get-Content C:\Windows\CCM\Logs\LocationServices.log -Tail 50

Se CcmExec è fermo, la KB non è il primo intervento: prima va chiarito perché il servizio non parte. Se il namespace root\ccm non risponde o il log mostra errori di registrazione, il problema potrebbe essere nel client stack, non nell’aggiornamento. Se invece i log mostrano una comunicazione regolare ma comportamenti applicativi erratici, allora il pacchetto ha più senso.

Distribuzione del pacchetto: approccio prudente e reversibile

La regola pratica è semplice: pilot prima, produzione dopo. In ambiente SCCM, un’onda iniziale su una collezione piccola e controllata vale più di una distribuzione globale fatta per comodità. Il motivo è banale: se la KB tocca componenti che interagiscono con boundary, policy o inventory, il bug non sempre emerge subito. Spesso si vede dopo il primo ciclo di policy o al primo inventario successivo. Quindi la finestra di osservazione deve essere sufficiente a coprire almeno un paio di check-in dei client.

Se distribuisci dal console di Configuration Manager, il percorso operativo tipico è quello della libreria software o dell’area di manutenzione del client, a seconda di come la KB è stata importata nel tuo ambiente. L’obiettivo non è solo “mandare il deployment”, ma farlo con criteri di controllo: collezione ristretta, maintenance window se disponibile, alerting sui fallimenti e baseline di confronto. Se hai più boundary group o siti secondari, evita di mischiare il pilot con client eterogenei: ti complichi l’interpretazione dei log.

Quando il pacchetto è distribuito correttamente, il comportamento atteso è lineare: il client scarica il contenuto, aggiorna i componenti interessati e riparte senza rompere la registrazione al sito. Il controllo successivo non è “l’installazione è finita”, ma “il client continua a ricevere policy, inventory e deployment con la stessa affidabilità di prima o migliore”.

Step numerati per l’aggiornamento dei client

Di seguito una sequenza operativa che riduce il rischio di interventi a cascata. Non è una procedura universale per ogni topologia, ma è il percorso più difendibile quando devi aggiornare client ConfigMgr 1802 con KB4339794 senza improvvisare.

  1. Verifica la versione del client e l’ambiente di riferimento. Controlla almeno un campione con wmic /namespace:\\root\ccm path sms_client get ClientVersion oppure da console nel dettaglio del device. L’atteso è una versione coerente con il ramo 1802; se trovi versioni miste, annota il segmento di rete o il boundary group associato.
  2. Controlla lo stato dei log chiave prima della modifica. In LocationServices.log e ccmexec.log cerca errori ripetuti, timeout o retry su MP e DPs. Se il client è già in errore prima della KB, non attribuire alla patch un problema preesistente.
  3. Conferma spazio libero e salute del servizio. Un client con disco quasi pieno o con servizi corrotti può fallire durante l’update. Un controllo minimo è Get-PSDrive C e Get-Service CcmExec. Se lo spazio è critico, libera prima una quota ragionevole o rimanda il rollout.
  4. Avvia il deployment su una collezione pilota. Scegli un gruppo piccolo ma rappresentativo: desktop, laptop, sedi diverse, e almeno un device sempre connesso e uno intermittente. Questo aiuta a intercettare problemi di reachability e cache locale.
  5. Osserva il primo ciclo post-update. Dopo l’installazione, verifica che il client riceva policy e completi un inventario. Il segnale utile è l’assenza di nuovi errori nei log e il ritorno a un comportamento normale entro il ciclo di policy successivo.
  6. Espandi per ondate solo se il pilot è pulito. Se compaiono errori sistematici, blocca l’estensione e isola la causa: contenuto, boundary, MP, WMI o servizi locali. Non forzare il rollout su tutta la base installata finché il pattern non è chiaro.

Questa sequenza è volutamente conservativa. In ambienti grandi, il costo di una distribuzione affrettata è superiore al costo di un pilot ben fatto. Se hai una finestra di change stretta, riduci il blast radius: aggiorna prima i client meno critici o una sola sede, non l’intera flotta.

Comandi utili per validare il comportamento del client

Se devi fare troubleshooting sul client dopo l’update, i comandi non devono essere decorativi: devono dirti se il client è sano, se ha un site assignment valido e se i componenti principali rispondono. Un set essenziale può essere questo:

Get-Service CcmExec | Select-Object Status,Name,DisplayName
Get-WmiObject -Namespace root\ccm -Class SMS_Client | Select-Object ClientVersion,AssignedSiteCode
Get-Content C:\Windows\CCM\Logs\PolicyAgent.log -Tail 80
Get-Content C:\Windows\CCM\Logs\DataTransferService.log -Tail 80

Se AssignedSiteCode è vuoto o incoerente, il client non è in uno stato affidabile. Se PolicyAgent.log mostra errori di elaborazione delle policy dopo la patch, il problema è da inseguire nel flusso di gestione, non nel semplice “update riuscito”. Se DataTransferService.log segnala errori di download, la pista è spesso legata a contenuto, connettività o cache locale danneggiata.

Snag ricorrenti: quando la KB non basta

Ci sono tre scenari che ricorrono spesso. Il primo è il client che sembra aggiornato ma continua a comportarsi male perché il problema è nel sito o nel management point. In quel caso, la KB ha fatto il suo lavoro ma non risolve il collo di bottiglia. Il secondo è il client con WMI o repository locale danneggiati: qui la patch può non completarsi correttamente o lasciare servizi in stato ambiguo. Il terzo è il client che vive dietro vincoli di rete o proxy non documentati: l’update funziona solo in alcune sedi e fallisce in altre, facendo sembrare la KB instabile quando invece è la connettività a essere incoerente.

In ambienti con certificate-based authentication o HTTPS end-to-end, la verifica dei certificati è parte del controllo, non un dettaglio. Se i certificati client sono scaduti, il problema si manifesta spesso come mancata registrazione o rinnovo incompleto. In questo caso, il fix non è forzare la KB, ma ripristinare la fiducia di base del client nel sito. Stesso discorso per firewall locali o policy di hardening troppo aggressive: se bloccano il traffico verso MP o DP, l’aggiornamento può diventare solo una variabile in più.

Rollback e criterio di stop

Il rollback in senso stretto dipende da come hai distribuito il pacchetto e da quale stato ha raggiunto il client. Se hai un pilot limitato, il rollback più sano è sospendere il deployment e impedire l’estensione alle collezioni successive. Se il pacchetto ha introdotto un comportamento anomalo su un gruppo ristretto, il primo passo non è disinstallare alla cieca: è fermare l’ondata, raccogliere i log e capire se il problema è riproducibile su altri client nello stesso segmento.

Per la parte operativa, conviene tenere a portata di mano almeno questi elementi: esportazione della collection interessata, snapshot dei log prima dell’update, e se possibile una baseline della versione client precedente. In caso di regressione, il criterio di stop deve essere chiaro: nuovi errori sistematici in ccmexec.log, fallimenti su policy o inventory su più client del pilot, oppure aumento del numero di device non gestiti correttamente. Quando uno di questi segnali appare, si blocca l’espansione e si torna alla diagnosi del layer colpito.

Se devi ripristinare il comportamento precedente, la strada più sicura è tornare al piano di controllo: disabilitare il deployment, verificare che il client continui a registrarsi e, solo se necessario, intervenire sul singolo endpoint con una remediation mirata. Non conviene trattare la KB come un pacchetto qualsiasi da rimuovere in massa senza capire cosa ha rotto. In SCCM, il costo di una rimozione indiscriminata può essere peggiore del problema iniziale.

Assunzione operativa: il sito 1802 è già in condizioni sane, i client sono gestiti in modo standard e il rollout avviene su una base Windows recente con accesso regolare a MP e DP.

Checklist finale prima della diffusione ampia

Prima di considerare chiuso il change, verifica che i client pilota abbiano completato almeno un ciclo di policy senza errori nuovi, che l’inventory torni regolare e che la versione client sia coerente con l’aggiornamento atteso. Un controllo sintetico utile è confrontare il numero di device in errore prima e dopo il rollout, insieme ai log di uno o due client rappresentativi. Se il dato migliora ma non è uniforme, non estendere ancora: cerca il fattore differenziale tra i client sani e quelli che continuano a fallire.

KB4339794 ha senso quando la applichi come parte di una gestione ordinata del parco client, non come gesto reattivo. In altre parole: osserva, limita il blast radius, aggiorna a blocchi e usa i log per confermare il risultato. È il modo più pulito per evitare di trasformare una correzione utile in un problema di produzione.