1 19/05/2026 8 min

Quando l’upgrade automatico del client SCCM resta disattivo

Se nel console di Configuration Manager l’upgrade automatico del client sembra “spento”, il primo errore è trattarlo come un singolo toggle. In realtà quella funzione è il punto finale di una catena: sito, hierarchy settings, boundary group, client settings, maintenance window, prerequisiti del client e, in alcuni casi, stato del deployment. Se uno di questi livelli non è coerente, il client non si aggiorna anche se l’impostazione appare corretta a monte.

La diagnosi utile non parte dal reinstallare il client. Parte dal capire dove si interrompe il flusso: il sito sta distribuendo la policy? Il client la riceve? Il client è eleggibile? L’upgrade è bloccato da una finestra di manutenzione o da una boundary errata? Solo dopo queste risposte ha senso toccare configurazioni o forzare azioni correttive.

Catena logica da verificare prima di cambiare qualcosa

Nel caso più comune, l’upgrade automatico del client SCCM non parte per uno di questi motivi:

  • la funzionalità è disabilitata a livello di hierarchy o site;
  • il client non riceve la policy corretta;
  • una client setting o una maintenance window impedisce l’installazione;
  • il client è già in uno stato non compatibile con l’upgrade automatico;
  • la distribuzione del package del client non è completa o non è raggiungibile dal boundary group.

La differenza pratica è importante: se il problema è di policy, il fix è lato console; se è di reachability, il problema sta nella distribuzione o nei boundary; se è di stato locale, serve leggere i log sul client prima di fare qualsiasi modifica globale.

Verifiche iniziali sul sito e sulla policy

Prima verifica che l’upgrade automatico sia davvero abilitato nel punto giusto della gerarchia. In console, controlla le impostazioni del client a livello di sito e confrontale con le impostazioni ereditate. In ambienti multi-site, un settaggio coerente sul primary non basta se esiste un override locale o una policy più specifica che lo annulla.

La verifica operativa minima è questa: il client riceve una policy che contiene l’opzione di upgrade? Se non hai visibilità immediata in console, sul client controlla il file di log della policy. I nomi esatti possono variare per versione, ma in genere i primi file da leggere sono quelli relativi a policy agent e client location. Cerca l’indicazione che la policy sia stata scaricata e applicata, non solo richiesta.

# Esempio di controllo locale sul client Windows
cd "C:\Windows\CCM\Logs"
findstr /i "policy upgrade client" PolicyAgent.log ClientLocation.log CCMSetup.log

Se nei log non compare alcuna policy che abilita l’upgrade, il problema non è il client: è la distribuzione della configurazione. In quel caso la falsificazione è semplice entro pochi minuti: forzi un ciclo di Machine Policy Retrieval & Evaluation e verifichi se compare un aggiornamento di policy nel log.

# Trigger policy retrieval dal client
Invoke-WmiMethod -Namespace root\ccm -Class SMS_Client -Name TriggerSchedule -ArgumentList '{00000000-0000-0000-0000-000000000021}'

Se dopo il refresh la policy arriva ma l’upgrade resta disattivo, il problema passa al livello successivo: eleggibilità del client o blocco locale.

Boundary group, contenuto e reachability del client source

L’upgrade automatico usa il contenuto del client package e deve poterlo raggiungere in modo affidabile. Se il boundary group non è associato al distribution point giusto, il client può ricevere la policy ma non il contenuto necessario per aggiornarsi. Questo è uno dei casi in cui la console sembra “verde” ma il client rimane fermo.

La verifica da fare è doppia: il boundary group del device è corretto e il distribution point contiene il package/client source aggiornato. Se il contenuto non è distribuito o è parzialmente replicato, il client può restare in attesa o fallire senza completare l’upgrade.

# Verifica rete e raggiungibilità del DP dal client
Test-NetConnection dp01.contoso.local -Port 80
Test-NetConnection dp01.contoso.local -Port 443

Dal lato console, controlla che il package del client sia distribuito ai DP corretti e che lo stato sia completato. Se il sito usa HTTPS o PKI, un errore di certificato o di trusted root può impedire il download senza rendere subito evidente il motivo. In quel caso i log del client mostrano tipicamente errori di handshake o di autenticazione del contenuto.

Maintenance window e client settings che bloccano l’upgrade

Un upgrade automatico può essere tecnicamente abilitato ma operativamente sospeso da una maintenance window. È il classico falso positivo: il sito è configurato bene, il client è eleggibile, ma l’orario corrente non consente l’installazione. Se la finestra è stretta o definita per collezioni sovrapposte, l’upgrade viene rimandato e spesso interpretato come disattivazione.

Controlla anche le client settings personalizzate. In ambienti maturi è frequente avere una baseline e poi eccezioni per collezioni specifiche. Una sola client setting più restrittiva può prevalere sulla configurazione generale e impedire l’upgrade in modo selettivo.

  1. Apri la collection target e verifica se ha una maintenance window attiva nel periodo in cui stai testando.
  2. Controlla se esistono client settings personalizzate assegnate a quella collection.
  3. Confronta i valori effettivi sul client con quelli attesi dalla baseline.

Se la finestra è la causa, la verifica è immediata: sposta il test in una fascia consentita oppure usa una collection di laboratorio senza maintenance window per confermare il comportamento.

Log del client: dove guardare per sapere perché non aggiorna

Quando il problema è locale, i log del client sono la fonte primaria. Non servono tutti: ne bastano pochi, letti nel giusto ordine. Cerca prima gli eventi di policy, poi quelli di download del contenuto, infine l’installazione vera e propria. Se uno di questi tre passaggi non compare, hai già isolato il layer che si rompe.

In pratica, i file da aprire sono quelli in C:\Windows\CCM\Logs e, se necessario, il setup log del client. Il segnale utile non è solo l’errore: è anche l’assenza di un passaggio atteso. Ad esempio, se vedi che il client riceve policy ma non prova nemmeno a scaricare il package, il problema è di eleggibilità o di configurazione, non di rete.

# Filtra i log più utili per il troubleshooting dell'upgrade client
findstr /i "upgrade install download policy error fail" C:\Windows\CCM\Logs\*.log

Se trovi errori di download, sposta l’attenzione su boundary, DP, certificati o proxy. Se trovi errori di installazione, controlla prerequisiti, spazio disco e stato del servizio client. Se non trovi alcun tentativo di upgrade, il problema è quasi sempre nella policy o nell’eleggibilità del dispositivo.

Stato del client e prerequisiti locali

Un client SCCM può non aggiornarsi anche se tutto il resto è corretto, semplicemente perché il sistema locale non è in uno stato sano. Disco quasi pieno, servizio client instabile, problemi di WMI o componenti corrotti sono sufficienti a bloccare un upgrade che altrimenti partirebbe.

Prima di pensare a reinstallazioni, controlla tre cose: spazio libero, stato del servizio e salute di WMI. Sono verifiche rapide e reversibili, e spesso bastano a distinguere un problema di piattaforma da un errore di configurazione SCCM.

# Verifiche rapide sul client
Get-Service CcmExec
Get-PSDrive C
winmgmt /verifyrepository

Se il repository WMI è incoerente, l’upgrade può fallire in modo intermittente o non partire affatto. Se il servizio CcmExec è fermo o in crash loop, il client non riesce ad applicare né policy né installazioni. In questi casi la correzione è locale e non va confusa con un problema di configurazione globale.

Sequenza consigliata di correzione senza fare danni

La correzione va fatta dal livello meno invasivo al più invasivo. L’obiettivo è sbloccare l’upgrade senza alterare più del necessario la configurazione di sito o la distribuzione del client.

  1. Forza un refresh della policy sul client e verifica nei log se la nuova impostazione arriva davvero.
  2. Controlla che il package del client sia distribuito al DP corretto e che il boundary group punti a quel DP.
  3. Verifica che non esistano maintenance window o client settings che impediscono l’installazione.
  4. Se il client è sano ma resta fermo, riavvia il servizio CcmExec e ripeti la verifica dei log.
  5. Solo se il client mostra corruzione locale o repository WMI incoerente, valuta una riparazione mirata del client.

Questo ordine riduce il blast radius. Non ha senso rifare il client su centinaia di macchine se il blocco è una policy non aggiornata o un boundary group sbagliato. Prima si dimostra il punto di rottura, poi si applica la correzione.

Controllo finale: come capire che il problema è davvero risolto

La verifica finale non è “il client è installato”, ma “il client è allineato alla versione attesa e continua a ricevere policy senza errori”. La conferma più utile arriva da tre segnali: versione del client aggiornata, log senza errori ricorrenti e contenuto distribuito correttamente al DP.

# Verifica versione e stato del client
Get-WmiObject -Namespace root\ccm -Class SMS_Client | Select-Object ClientVersion
Get-Service CcmExec | Select-Object Status,Name

Se il client è aggiornato ma il problema si ripresenta dopo poche ore o al refresh successivo, la causa non era locale: era un vincolo di policy, boundary o maintenance window. In quel caso conviene documentare il punto esatto della catena in cui l’upgrade si interrompe, perché è lì che va corretta la configurazione strutturale.

Assunzione operativa: l’ambiente usa Microsoft Configuration Manager con client Windows recenti e log standard in C:\Windows\CCM\Logs; se la versione o l’architettura sono diverse, va verificato il nome dei log e il percorso esatto nel client.

In pratica, l’upgrade automatico del client SCCM non è disattivo per magia: o non riceve la policy, o non può scaricare il contenuto, o non è autorizzato a installare in quel momento. Se segui la catena giusta, il problema smette di essere opaco e diventa un guasto localizzato, quindi correggibile senza interventi larghi e rischiosi.