1 13/10/2026 9 min

Nel client Microsoft Configuration Manager, le azioni del client sono i cicli operativi che controllano come il dispositivo parla con il site, riceve criteri, aggiorna inventario, scarica contenuti e applica le istruzioni di gestione. In pratica, sono il punto di controllo più utile quando un endpoint non si allinea ai dati attesi in console, quando una policy non arriva, quando l’inventario è vecchio o quando serve verificare se il client sta davvero eseguendo il lavoro previsto.

La logica da tenere in testa è semplice: la console mostra lo stato desiderato, il client esegue cicli periodici per riallinearsi. Se il risultato non torna, prima si osserva quale ciclo è coinvolto, poi si verifica il canale di comunicazione, infine si forzano le azioni solo quando serve. Forzare tutto a caso non aiuta: aumenta rumore nei log, carico sul management point e confonde la diagnosi.

Come leggere le azioni del client

Ogni azione del client ha uno scopo preciso: alcune raccolgono dati dal dispositivo, altre chiedono configurazioni al site, altre ancora scaricano contenuti o valutano l’applicabilità di aggiornamenti e deployment. Il client le esegue in base a schedule interni, ma l’amministratore può richiamarle manualmente per test, troubleshooting o sincronizzazione immediata.

Le azioni più note si gestiscono dal pannello Control Panel del client, nella scheda Actions. Da lì si possono avviare i cicli principali senza passare dalla console Configuration Manager. È il percorso più utile quando devi verificare velocemente se un endpoint risponde o se il problema è lato client.

Prima di forzare un’azione, conviene sapere cosa stai cercando di dimostrare: una policy mancante? Un inventario fermo? Un’applicazione non valutata? Un deployment software che non compare? La scelta del ciclo dipende dalla risposta. Questo evita il classico errore di lanciare 4 o 5 azioni insieme e poi non capire quale abbia prodotto l’effetto osservato.

Elenco delle principali azioni del client Configuration Manager

Le etichette possono variare leggermente tra versioni e configurazioni, ma il concetto resta quello. Sotto trovi le azioni più comuni e il loro uso pratico.

  1. Machine Policy Retrieval & Evaluation Cycle
    Scarica dal site le policy assegnate al dispositivo e le rivaluta. È il primo ciclo da forzare quando una configurazione o un deployment non arriva al client.
  2. User Policy Retrieval & Evaluation Cycle
    Recupera e rivaluta le policy legate all’utente connesso. Serve soprattutto in scenari con deployment user-targeted o impostazioni applicate al contesto utente.
  3. Hardware Inventory Cycle
    Raccoglie l’inventario hardware del dispositivo e lo invia al site. Utile quando in console mancano CPU, RAM, disco, seriale o altri attributi hardware.
  4. Software Inventory Cycle
    Raccoglie informazioni su file e software secondo la configurazione dell’inventario. Va usato con criterio: può essere più pesante dell’hardware inventory e non sempre è necessario abilitarlo in modo aggressivo.
  5. Discovery Data Collection Cycle
    Invia i dati di discovery del client, inclusi elementi utili per l’aggiornamento delle informazioni di base in console.
  6. Application Deployment Evaluation Cycle
    Rivaluta le applicazioni distribuite al client, controllando requisiti, supersedence, dipendenze e stato di compliance. È il ciclo giusto quando un’app non compare come disponibile o non parte l’installazione.
  7. Software Updates Deployment Evaluation Cycle
    Rivaluta gli update assegnati al dispositivo. Se una patch non compare, non si valuta o resta in stato incoerente, questo è il ciclo da richiamare.
  8. Software Updates Scan Cycle
    Esegue la scansione per determinare la conformità rispetto agli aggiornamenti. È separato dalla deployment evaluation: uno verifica, l’altro valuta cosa è stato assegnato.
  9. Compliance Evaluation Cycle
    Rivaluta le baseline di compliance e i relativi controlli. Serve quando una baseline non aggiorna lo stato o quando vuoi accelerare la verifica di una remediation.
  10. File Collection Cycle
    Raccoglie i file definiti per la collection. È un’azione meno usata, ma utile in casi mirati di diagnostica o telemetria personalizzata.
  11. Software Metering Usage Report Cycle
    Invia i dati di utilizzo raccolti dal client per il software metering. È rilevante se usi il metering per capire l’effettivo consumo delle applicazioni.
  12. Endpoint Protection / antimalware policy cycles
    Se l’ambiente integra funzioni di protezione endpoint, il client esegue cicli di aggiornamento e rivalutazione delle policy di sicurezza.

La lista esatta dipende dalla versione del client, dal tipo di workload gestito e dalle funzionalità abilitate nel site. Se non trovi una voce attesa, il primo controllo è nella scheda Actions del client e nei log locali, non nella console, perché il problema potrebbe essere solo di esposizione o di registrazione del ciclo sul dispositivo.

Quale azione usare in base al sintomo

Qui sta l’errore più frequente: trattare tutte le azioni come equivalenti. Non lo sono. Ogni ciclo risolve un problema diverso e il tempo di propagazione cambia molto.

  1. Policy mancante o vecchia → avvia Machine Policy Retrieval & Evaluation Cycle o, se il problema riguarda un utente, User Policy Retrieval & Evaluation Cycle.
  2. Inventario non aggiornato → avvia Hardware Inventory Cycle o Software Inventory Cycle a seconda del tipo di dato mancante.
  3. Applicazione non disponibile o non valutata → avvia Application Deployment Evaluation Cycle.
  4. Patch non visibili o compliance update ferma → avvia Software Updates Scan Cycle e poi Software Updates Deployment Evaluation Cycle.
  5. Baseline di compliance non aggiornata → avvia Compliance Evaluation Cycle.
  6. Problema di raccolta dati o diagnostica personalizzata → usa Discovery Data Collection Cycle o File Collection Cycle se configurato.

Un esempio concreto: se in console hai assegnato un’applicazione ma il client non la vede, non ha senso partire dall’inventario hardware. Prima controlli la policy machine o user, poi l’application evaluation. Se invece l’app compare ma non si installa, allora guardi log e prerequisiti, perché il problema è già passato dalla fase di discovery della policy ed è probabilmente legato a detection, requirement, contenuto o permessi.

Come eseguire le azioni dal client

Il metodo più rapido è aprire il pannello del client sul dispositivo interessato. Il percorso classico è Control Panel → Configuration Manager → scheda Actions. Da lì selezioni l’azione e premi Run Now.

In ambienti gestiti a distanza, puoi anche usare strumenti amministrativi o script, ma conviene farlo solo se hai bisogno di ripetibilità o di operare su più endpoint. Il vantaggio del pannello è che riduce gli errori: vedi immediatamente se il client è registrato, quali azioni espone e se la richiesta parte davvero.

Se vuoi verificare che il client stia lavorando, osserva i log locali. I nomi possono variare, ma i punti di attenzione sono tipicamente questi:

  • C:\Windows\CCM\Logs\PolicyAgent.log per il recupero e la valutazione delle policy.
  • C:\Windows\CCM\Logs\InventoryAgent.log per inventario hardware e software.
  • C:\Windows\CCM\Logs\AppEnforce.log per enforcement delle applicazioni.
  • C:\Windows\CCM\Logs\UpdatesDeployment.log e log correlati per gli aggiornamenti software.
  • C:\Windows\CCM\Logs\CIAgent.log o log di compliance per baseline e valutazioni di configurazione.

Il punto non è memorizzare ogni file a memoria, ma sapere quale famiglia di log consultare in base all’azione avviata. Se l’azione parte ma non produce effetto, i log locali sono il primo posto da leggere. Se invece l’azione non compare proprio, il problema è più profondo e riguarda installazione client, registrazione, policy o comunicazione con il site.

Comandi utili e verifica lato sistema

In alcuni casi conviene verificare stato del servizio client e connettività di base prima di forzare azioni. Su Windows, il servizio principale del client è quello di Configuration Manager. Un controllo rapido può essere questo:

sc query ccmexec

Se il servizio non è in esecuzione, il client non potrà completare i cicli. Se è in esecuzione ma le azioni falliscono, il passo successivo è leggere i log e verificare la comunicazione con il management point o con il distribution point, a seconda del problema.

Per un controllo base della raggiungibilità dei sistemi di gestione, puoi usare anche un test di rete semplice verso il management point o verso gli endpoint noti dell’infrastruttura. Ad esempio:

Test-NetConnection mgmtpoint.example.local -Port 443

Se il test fallisce, la causa potrebbe non essere il client ma la rete, il firewall, il proxy o la configurazione TLS. In quel caso forzare di nuovo le azioni non cambia nulla: prima si risolve il trasporto.

Ordine pratico di troubleshooting

Quando una funzione non si aggiorna, segui sempre una sequenza stabile. È la parte che fa risparmiare più tempo perché evita tentativi casuali.

  1. Verifica che il client sia installato e online.
  2. Controlla che il servizio ccmexec sia attivo.
  3. Conferma che il dispositivo sia assegnato al site corretto.
  4. Individua il ciclo corrispondente al sintomo.
  5. Forza una sola azione alla volta.
  6. Leggi il log relativo e cerca errori di policy, download, detection o scan.
  7. Solo dopo, valuta se il problema è di infrastruttura, configurazione o contenuto.

Questa sequenza è importante anche in ambienti grandi. Se lanci più azioni insieme su centinaia di endpoint, puoi generare picchi inutili sul management point o sui server di contenuto. La verifica progressiva riduce il blast radius e ti dà un punto di osservazione pulito.

Quando le azioni non bastano

Le azioni del client non sono una cura universale. Se il dispositivo non riceve policy perché non comunica col site, se il contenuto non è raggiungibile, se il boundary group è errato o se il client è corrotto, il problema va risolto a monte. Forzare il ciclo serve solo a mostrare meglio il guasto, non a rimuoverlo.

Ci sono anche casi in cui il client esegue l’azione ma la console non si aggiorna in tempo reale. Qui non c’è bug da “ripetere”: c’è latenza di elaborazione lato site, c’è un ritardo nella replica dei dati o c’è una finestra di polling ancora in corso. In questi casi bisogna distinguere tra azione completata sul device e dato visibile in console.

Per questo è utile tenere separati tre livelli: esecuzione locale, trasporto verso il site e visualizzazione in console. Molti falsi allarmi nascono dal confondere questi passaggi.

Buone pratiche operative

In produzione conviene usare le azioni del client con una disciplina semplice:

  • forza solo il ciclo coerente con il sintomo;
  • non attivare più cicli contemporaneamente se stai cercando una causa;
  • leggi sempre il log prima e dopo l’azione;
  • se tocchi configurazioni o remediation, documenta il rollback;
  • se il problema è diffuso, valida su un campione piccolo prima di estendere.

Un approccio pulito ti permette di capire se il client è davvero il punto debole o se sta semplicemente riflettendo un problema più in alto nella catena. Nel mondo Configuration Manager, questa distinzione fa risparmiare ore di analisi.

Conclusione operativa

Le azioni del client Configuration Manager non sono un elenco da memorizzare a forza: sono strumenti di diagnosi e riallineamento. Se conosci il ciclo giusto per policy, inventario, applicazioni, update o compliance, riesci a separare rapidamente il problema di presentazione da quello reale di gestione. La regola pratica è sempre la stessa: osserva, identifica il ciclo corretto, forzalo una volta, leggi il log giusto e solo dopo decidi se il guasto è nel client, nella rete o nel site.