1 13/05/2026 9 min

Il recupero dei criteri client in SCCM non è un “refresh” generico: il client deve contattare il Management Point, scaricare le policy aggiornate e poi applicarle nei tempi previsti dal ciclo di valutazione. Quando questo passaggio si inceppa, il problema può stare nel client, nella connettività verso il MP, nella registrazione di Windows Management Instrumentation, oppure in una policy corrotta che il client continua a trascinarsi dietro. Se l’obiettivo è forzare il recupero in modo ripetibile, VBScript resta utile quando non vuoi dipendere da PowerShell o quando devi integrarlo in vecchi task, logon script o strumenti di automazione già esistenti.

Qui il punto non è “far partire uno script”, ma capire quale layer stai toccando: il client SCCM espone interfacce WMI, riceve istruzioni dal servizio locale e scrive evidenza nei log. Se il recupero non avviene, lo script è solo il grilletto; la diagnosi vera è nei log e nello stato del client.

Quando ha senso usare VBScript

Usa VBScript se devi avviare il recupero criteri su macchine dove il runtime cscript è disponibile e vuoi un file semplice, senza dipendenze esterne. È una scelta ancora pratica in ambienti con script legacy, accesso remoto limitato o automazioni che devono funzionare anche su sistemi datati. Non è la strada migliore per orchestration moderna, ma è spesso la più compatibile.

Il recupero dei criteri lato client passa in genere dalla classe WMI del namespace root\ccm o root\ccm\policy\machine, a seconda del metodo usato. In pratica, il VBScript chiama il client SCCM tramite WMI e gli chiede di eseguire il ciclo di Machine Policy Retrieval & Evaluation. Se il namespace non risponde, il problema non è il trigger: è l’accessibilità WMI o l’integrità del client.

Primo controllo: il client è sano?

Prima di lanciare qualsiasi script, verifica questi punti minimi. Sono rapidi e ti evitano di inseguire un falso problema di automazione quando il client è già rotto.

  1. Il servizio SMS Agent Host è in esecuzione. Su Windows lo vedi come CcmExec.

  2. La macchina raggiunge il Management Point e non ha problemi DNS o proxy.

  3. I log del client mostrano attività recente, non un blocco persistente su WMI o policy store.

Comando utile per un check rapido del servizio:

sc query ccmexec

Atteso: STATE con valore RUNNING. Se è fermo, lo script può anche partire, ma non risolverà il problema alla radice.

Per la connettività verso il MP, un test minimale è una richiesta HTTP/HTTPS verso l’endpoint previsto nella tua infrastruttura. Se non hai il path esatto, recuperalo dalla console o dalla documentazione interna del sito SCCM. Un errore qui falsifica subito l’ipotesi “problema di policy”: il client non riesce proprio a parlare con l’infrastruttura.

Script VBScript per forzare il recupero policy

Lo script sotto invoca il ciclo di Machine Policy Retrieval & Evaluation tramite WMI. È essenziale mantenerlo minimale: meno logica dentro lo script, meno punti di errore. Non inserire segreti, credenziali o percorsi sensibili in chiaro. Se devi distribuirlo, trattalo come qualsiasi altro artefatto di automazione: versionato, commentato e con un owner chiaro.

Set objWMI = GetObject("winmgmts:\\.\root\ccm")
Set objSMSClient = objWMI.Get("SMS_Client")

ReturnValue = objSMSClient.TriggerSchedule("{00000000-0000-0000-0000-000000000021}")

WScript.Echo "TriggerSchedule returned: " & ReturnValue

Questo esempio usa il GUID comunemente associato al recupero policy macchina. Se nel tuo ambiente è documentato un metodo diverso o una classe diversa, segui la tua baseline operativa. Il punto non cambia: devi raggiungere l’oggetto WMI del client e richiamare il ciclo corretto.

Se preferisci un file eseguibile da prompt, salva il contenuto come RefreshSCCMPolicy.vbs e lancialo con:

cscript.exe //nologo RefreshSCCMPolicy.vbs

Atteso: output con un codice di ritorno. 0 in genere indica che la chiamata è stata accettata; un valore diverso o un errore COM/WMI richiedono verifica del client, non un semplice retry cieco.

Versione più difensiva con gestione errori

In produzione o in un parco macchine eterogeneo conviene una variante che riporti errori leggibili. Questo aiuta a distinguere tra namespace WMI assente, accesso negato e oggetto non disponibile.

On Error Resume Next

Set objWMI = GetObject("winmgmts:\\.\root\ccm")
If Err.Number <> 0 Then
  WScript.Echo "Errore accesso WMI root\\ccm: " & Err.Number & " - " & Err.Description
  WScript.Quit 1
End If

Set objSMSClient = objWMI.Get("SMS_Client")
If Err.Number <> 0 Then
  WScript.Echo "Errore oggetto SMS_Client: " & Err.Number & " - " & Err.Description
  WScript.Quit 2
End If

ReturnValue = objSMSClient.TriggerSchedule("{00000000-0000-0000-0000-000000000021}")
If Err.Number <> 0 Then
  WScript.Echo "Errore TriggerSchedule: " & Err.Number & " - " & Err.Description
  WScript.Quit 3
End If

WScript.Echo "Trigger avviato, ReturnValue=" & ReturnValue

Qui la logica è semplice: se fallisce l’accesso al namespace, sei davanti a un problema di WMI o di registrazione del client; se fallisce la chiamata al metodo, il client è presente ma non risponde correttamente. Questa distinzione è utile perché cambia completamente il tipo di fix.

Dove guardare nei log del client

Per confermare che il recupero è stato richiesto e preso in carico, i log restano la fonte più affidabile. I percorsi possono variare leggermente in base alla versione del client, ma in genere trovi evidenza in C:\Windows\CCM\Logs\. I file più utili sono quelli legati a policy agent, WMI provider e attività del client.

  1. PolicyAgent.log per il ciclo di recupero e valutazione policy.

  2. CCMExec.log per il comportamento generale del servizio.

  3. WMIProvider.log se sospetti problemi di provider o namespace.

Se vuoi verificare velocemente che il trigger sia passato, cerca nel log parole chiave come Machine policy retrieval, policy assignments o riferimenti al ciclo schedulato. Un controllo rapido da prompt può essere questo:

findstr /i "policy retrieval policy assignment" C:\Windows\CCM\Logs\PolicyAgent.log

Atteso: righe che mostrano l’avvio o la valutazione delle policy dopo il trigger. Se il log non cambia, il problema è prima del motore policy: lo script non ha raggiunto il client o il client non ha accettato il comando.

Se il trigger fallisce: lettura per layer

Un errore in questa fase non va trattato come un unico blocco. La diagnosi utile è per layer.

  1. WMI locale: namespace root\ccm assente o corrotto. Falsifica con wmic /namespace:\\root\ccm path SMS_Client get /value o con un test equivalente da PowerShell/WMI.

  2. Client SCCM: servizio CcmExec fermo o registrazione incompleta. Falsifica con sc query ccmexec e controllo di CCMExec.log.

  3. Policy store: il client riceve il trigger ma non completa l’elaborazione. Falsifica con timestamp nel log e confronto tra richiesta e applicazione effettiva.

Se il namespace WMI è rotto, la correzione non è nello script. Devi ripristinare il client o ricostruire la registrazione WMI secondo la tua procedura aziendale. Se invece il servizio è vivo ma la policy non arriva, il problema si sposta verso il Management Point, il boundary group, il certificato del client o la connettività di rete.

Distribuzione controllata dello script

Se devi eseguirlo su più macchine, evita di spararlo ovunque senza filtro. Il blast radius è basso solo se limiti il target a un gruppo di test o a sistemi già in diagnosi. Un approccio prudente è: una macchina campione, verifica log, poi estensione graduale.

Per un’esecuzione remota controllata, puoi usare una share amministrativa o un tool di gestione interna, ma la scelta dipende dalle policy del sito. Se il contesto lo consente, copia il file e lancialo localmente con privilegi adeguati. In alternativa, integra lo script in un task pianificato temporaneo con durata limitata e rimozione finale. Non lasciare automazioni di debug attive più del necessario.

Se vuoi un controllo ancora più rigoroso, crea un log locale dell’esecuzione. Per esempio:

cscript.exe //nologo RefreshSCCMPolicy.vbs > C:\Temp\RefreshSCCMPolicy.log 2>&1

Così separi l’output dello script dai log SCCM. È un dettaglio semplice, ma ti evita di perdere il codice di ritorno quando esegui la procedura in modo massivo.

Verifica dopo il recupero

Il controllo non è “lo script è finito”, ma “il client ha ricevuto e applicato policy nuove”. Verifica almeno tre segnali:

  1. Nel log compare il ciclo di retrieval con timestamp coerente.

  2. Le policy attese compaiono nel client o nella console come già ricevute.

  3. Eventuali deployment o impostazioni nuove diventano visibili nel tempo previsto.

Se vuoi un controllo più operativo, confronta l’ora del trigger con l’ora dell’ultima elaborazione nel log. Se il delta resta invariato, il client non ha preso in carico la richiesta. Se il delta cambia ma la policy non si applica, devi andare a verificare contenuto, dipendenze applicative o stato del deployment.

Problemi tipici e lettura corretta

Tre errori ricorrenti meritano una lettura separata.

  1. “Access denied” su WMI: spesso è un problema di privilegi o hardening locale. Verifica con quale account stai eseguendo lo script e se l’accesso al namespace è consentito.

  2. ReturnValue valido ma nessun effetto visibile: il trigger è partito, ma il client non ha completato il ciclo. Controlla i log e la connettività verso il Management Point.

  3. Client fermo o instabile: il recupero criteri è un sintomo, non la causa. Prima di insistere con il refresh, stabilizza CcmExec, WMI e lo stato generale della macchina.

In ambienti con problemi ricorrenti, conviene documentare una procedura standard: check del servizio, check dei log, trigger VBScript, conferma applicazione, e solo dopo eventuale repair del client. In questo modo il refresh policy non diventa un rituale cieco ma un passaggio misurabile.

Quando non basta il refresh

Ci sono casi in cui forzare il recupero policy è inutile o addirittura fuorviante. Se il client è corrotto, se il namespace WMI è incoerente, se il boundary group è sbagliato o se il Management Point non è raggiungibile, il trigger non corregge nulla. Serve prima ripristinare il canale di gestione. Solo dopo ha senso chiedere al client di riallinearsi alle policy.

La regola pratica è questa: prima osserva, poi triggera. Un VBScript di recupero criteri è uno strumento di controllo, non un sostituto della diagnosi. Se lo usi bene, ti fa risparmiare tempo; se lo usi come scorciatoia, nasconde il problema fino al prossimo giro di policy.

In un ambiente maturo, la procedura dovrebbe essere tracciata: versione dello script, contesto di esecuzione, esito, log consultati e rollback previsto. Il rollback qui non è un ripristino dati, ma la rimozione del task temporaneo, del file script e di eventuali schedulazioni di prova. Se hai distribuito lo script su più host, disattivalo appena terminata la verifica.

Assunzioni: il client SCCM è già installato e il lettore ha accesso amministrativo locale o equivalente per eseguire script e leggere i log.