1 13/04/2026 4 min

Forzare un inventario hardware completo nei client SCCM serve quando il dato in console è vecchio, incompleto o incoerente rispetto alla macchina reale. Il punto non è “far partire qualcosa”, ma capire quale layer sta bloccando il flusso: client, policy, schedule, WMI, cache locale o MP. Se salti la diagnosi, rischi di vedere un aggiornamento in console che in realtà è solo un tentativo fallito o un inventario parziale.

In pratica, l’obiettivo è portare il client a eseguire subito il ciclo di hardware inventory, generare il file MIF o il report di inventario, recapitarlo al Management Point e farlo processare dal site server. Il comportamento atteso è semplice: il client produce un nuovo inventario, i log locali lo confermano e la console si aggiorna nel giro di poco tempo. Se invece il dato resta fermo, il problema è quasi sempre uno di questi tre: il ciclo non parte, parte ma fallisce in raccolta, oppure parte e non viene accettato dal backend.

Quando ha senso forzarlo davvero

Non forzare l’inventario hardware come prima reazione a ogni discrepanza. Se il client è appena stato installato, se la policy non è ancora arrivata o se il problema è chiaramente di discovery nel database, stai solo aggiungendo rumore. Ha senso quando:

  • la console mostra dati hardware vecchi rispetto allo stato reale della macchina;
  • hai appena sostituito RAM, disco, scheda di rete o BIOS e vuoi validare la nuova configurazione;
  • stai verificando una baseline di conformità o una raccolta custom in WMI;
  • un report dipende da attributi hardware aggiornati e i tempi standard sono troppo lunghi.

Se il tuo obiettivo è “vedere subito la modifica”, l’inventario completo è la leva corretta. Se invece vuoi solo accelerare la visibilità in console, spesso basta un trigger manuale del ciclo e una verifica dei log, senza toccare altro.

Cosa succede sotto il cofano

Il client SCCM esegue il ciclo di hardware inventory secondo la schedule configurata nella policy. Durante l’esecuzione, il componente di inventory interroga le classi WMI abilitate, raccoglie i dati e li serializza in un file di output che verrà spedito al site. La parte che spesso viene sottovalutata è che “forzare” non significa bypassare le regole: il client continua a rispettare classi, namespace, limiti di dimensione e stato della policy ricevuta.

Questa distinzione conta perché un inventario forzato può comunque essere incompleto se la classe WMI non risponde, se il provider è rotto o se l’oggetto è troppo grande e viene troncato. In altre parole: il trigger manuale accelera il ciclo, non corregge la qualità della sorgente.

Metodo corretto: trigger del ciclo dal client

Il modo più pulito per avviare un inventario hardware completo è usare il client SCCM stesso, non manipolare file a mano. Se hai accesso alla GUI del client, il percorso è più sicuro; se devi automatizzare o operare in massa, usa PowerShell/WMI con criterio.

  1. Verifica che il client sia online e registrato. Un controllo rapido è il servizio SMS Agent Host e l’ultimo heartbeat in console. Se il client è offline o non riceve policy, il trigger non risolve.

  2. Avvia la raccolta dell’inventario hardware dal client. In ambiente Windows puoi usare lo strumento locale del client oppure richiamare la schedule via WMI. Se usi la console del client, cerca la voce di inventario hardware e l’opzione per eseguire il ciclo. Se usi PowerShell, il trigger tipico passa dalla classe SMS_Client.

  3. Monitora il log locale InventoryAgent.log per confermare che il ciclo sia partito e che la raccolta sia stata completata senza errori. Se il ciclo non compare nel log, il trigger non ha avuto effetto.

  4. Controlla ClientIDManagerStartup.log e PolicyAgent.log se il client sembra ignorare il comando. Se la policy non è aggiornata, l’inventory schedule potrebbe non essere presente o essere corrotta.

Se operi da shell sul client, un esempio comune è questo:

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command