Come configurare l'inventario hardware in Configuration Manager

Inventario hardware in Configuration Manager: cosa raccogli davvero

L’inventario hardware in Microsoft Configuration Manager non è una semplice fotografia del PC: è una pipeline. Il client legge classi WMI locali, le comprime, le invia al Management Point, il site server le normalizza e il database le rende interrogabili da report, collection e query. Se questa catena si rompe in un punto qualunque, il sintomo cambia: dati vecchi, classi mancanti, cicli troppo lunghi, database gonfio o client che sembrano sani ma non aggiornano nulla.

La configurazione corretta parte da una domanda pratica: quali dati ti servono davvero? Più estendi l’inventario, più aumenti traffico, tempo di processing e volume SQL. In ambiente enterprise conviene ragionare per classi, non per “voglio tutto”: BIOS, chassis, storage, RAM, TPM, firmware, periferiche, software installato e, solo se serve, attributi custom da WMI o registry.

Il punto da non sottovalutare è che Configuration Manager non “scopre” magicamente l’hardware: raccoglie ciò che il client espone. Se una classe WMI non c’è, è vuota o viene rigenerata male dal vendor, l’inventario sarà coerente con quel difetto. Prima di toccare la console, verifica quindi il dato alla fonte.

Verifica la fonte: WMI prima della console

Su un client Windows, il primo controllo è capire se le classi esistono e restituiscono valori. Per l’inventario hardware classico, le classi più usate stanno in root\cimv2. Se un campo non arriva in Configuration Manager, spesso il problema è già qui.

Usa PowerShell in locale sul client:

Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model, TotalPhysicalMemory
Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion, SerialNumber, ReleaseDate
Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors
Get-CimInstance Win32_PhysicalMemory | Select-Object Capacity, Speed, Manufacturer, PartNumber

Se questi comandi restituiscono dati coerenti, la sorgente locale è buona. Se invece trovi campi vuoti o oggetti mancanti, il problema non è ConfigMgr ma il provider WMI o il driver/firmware del vendor. In quel caso la soluzione va chiusa alla fonte: aggiornamento BIOS/firmware, reinstallazione provider OEM, oppure correzione della classe custom.

Per le classi custom, controlla anche il namespace specifico. Un esempio tipico è un vendor che espone dati in un namespace non standard:

Get-CimClass -Namespace root
amespaceOEM

Se il namespace non esiste sul client, non ha senso inseguire il problema dentro la console di Configuration Manager.

Come si abilita l’inventario hardware nella console

La configurazione si fa nel client settings, non nel singolo dispositivo. La logica è: definisci una policy, la assegni a una collection, poi il client la riceve tramite policy machine. In ambienti misti è comune avere un set base e uno o più set personalizzati per gruppi specifici.

Percorso tipico nella console:

1. Apri Administration → Client Settings.
2. Modifica il profilo Default Client Settings oppure creane uno dedicato.
3. Vai su Hardware Inventory e imposta Enable hardware inventory on clients su Yes.
4. Configura il schedule: intervallo troppo aggressivo aumenta carico, troppo lento rende i dati inutili.
5. Aggiungi o rimuovi classi in Set Classes.

Se devi operare con il minimo rischio, evita di toccare il profilo di default in produzione. Crea invece un client setting dedicato, assegnalo a una collection pilota e verifica il risultato su 10–20 macchine rappresentative. Il blast radius, in questo caso, è il numero di client che riceveranno la nuova policy; il rollback è il disassociazione del client setting o il ripristino della versione precedente.

Aggiungere o rimuovere classi hardware senza fare danni

La parte delicata non è abilitare l’inventario, ma scegliere cosa entra. Ogni classe aggiunta produce record, e alcuni attributi generano un volume sproporzionato se il parco macchine è grande. Per esempio, inventariare in modo indiscriminato dettagli di tutte le memorie o di tutti i dispositivi PnP può far crescere il database più del previsto.

In console, usa Set Classes e limita la raccolta alle classi realmente utili. Un criterio sensato è:

• Base asset: BIOS, sistema, CPU, memoria, disco, chassis.
• Compliance: TPM, Secure Boot, firmware, modello macchina.
• Supporto: controller, storage serial, NIC, docking station, batteria su portatili.
• Custom: solo attributi che alimentano report o automazioni reali.

Se devi inventariare una classe custom, conviene prima testarla in locale con PowerShell e poi esporla a ConfigMgr. Un esempio di classe WMI custom già disponibile:

Get-CimInstance -Namespace root
amespaceOEM -ClassName Vendor_SystemInfo | Format-List *

Se i campi sono presenti ma inconsistenti, non correggerli in Configuration Manager: il sistema di inventario non è un motore di normalizzazione. Serve un fix lato provider o uno strato intermedio, ad esempio una classe WMI pulita esposta da uno script di provisioning locale.

Estendere l’inventario con MOF e regole personalizzate

Quando la GUI non basta, la strada classica è l’estensione del file MOF del client. È un’operazione sensata solo se hai un motivo tecnico chiaro e un piano di rollback. Il punto non è “si può fare”, ma “ha senso mantenere questa estensione nel tempo?”.

In molti ambienti moderni è preferibile usare la console per le classi standard e riservare il MOF a casi specifici, ad esempio una classe WMI custom già stabilizzata. Se devi intervenire, lavora con backup del file originale e modifica tracciata. Il file tipico lato client è il repository locale del policy agent, ma per la definizione della classe il riferimento operativo resta la configurazione del client setting o l’estensione distribuita dal site server.

Un esempio di ragionamento corretto non è “aggiungo tutto il namespace”, ma “aggiungo solo questi attributi perché alimentano questo report”. In pratica:

1. Identifica il campo richiesto dal business o dall’operatività.
2. Verifica che il dato esista in WMI locale.
3. Controlla la cardinalità: un campo per device o centinaia di istanze per device?
4. Aggiungi la classe solo se il rapporto utilità/costo è favorevole.

Se una classe genera molte istanze, il rischio principale è il carico sul DB e sui processi di inventory processing. Prima di generalizzare, fai un test su un campione reale di hardware eterogeneo: desktop, notebook, workstation e modelli di vendor diversi.

Schedule, delta e tempi di aggiornamento

L’inventario hardware non deve girare “più veloce possibile”. Deve essere abbastanza fresco da essere utile e abbastanza lento da non disturbare la rete, il client e SQL. Il compromesso dipende da quanto cambiano i dati: un server statico può stare su un intervallo più ampio, un parco laptop con docking, periferiche e upgrade frequenti richiede una cadenza più stretta.

In generale, la prima scelta da valutare è la differenza tra inventario completo e delta. Il delta riduce traffico e tempo, ma se la macchina perde più cicli o il client ha problemi di stato, il full inventory periodico resta il meccanismo di riallineamento. La regola pratica è: usa il delta per l’operatività, il full per la correzione di deriva e per la riconciliazione periodica.

Per verificare che il client stia rispettando la policy, controlla il log locale del client. I nomi possono variare leggermente per versione, ma il riferimento utile è il file di inventario hardware, tipicamente nella cartella CCM\\Logs. Il contenuto deve mostrare l’avvio del ciclo, le classi processate e l’invio del report. Se non trovi eventi recenti, il problema è sul client; se trovi invio ma non aggiornamento nel DB, il problema è a monte o lato site server.

dir C:\\Windows\\CCM\\Logs\\*inv*.log

Se il client è gestito ma non aggiorna, il log ti dice anche se la policy è stata ricevuta, se la classe è stata letta e se il report è stato accodato. Questo ti evita di cambiare a caso il schedule quando in realtà il client non ha mai applicato la configurazione.

Verificare lato site server e database

Quando il client sembra corretto ma i dati non arrivano, il collo di bottiglia si sposta sul site server o sul database. Qui il sintomo tipico è la discrepanza tra ciò che vedi nel client e ciò che compare nelle viste di inventario. Il controllo minimo è capire se il report è stato ricevuto e processato.

Su SQL, la verifica dipende dal tuo livello di accesso e dal modello di reporting usato, ma la logica è sempre la stessa: controlla che i record nuovi entrino nelle tabelle/viste di inventario e che non ci siano code o errori di processing. Se il DB cresce troppo rapidamente, misura prima di ottimizzare: quante righe per device, quante classi, quanto pesa una raccolta completa.

Un approccio semplice è correlare tre punti:

1. timestamp del client nel log di inventario;
2. timestamp di arrivo sul site server o sul management point;
3. visibilità del dato nei report o nelle query SQL.

Se il primo c’è e il terzo no, hai una perdita nella pipeline. Se il secondo e il terzo ci sono ma con ritardo eccessivo, il problema è di capacity o di code. In quel caso la soluzione strutturale non è “forzare più spesso il client”, ma ridurre le classi inutili, distribuire meglio i cicli e verificare la salute del site database.

Una procedura pratica che funziona in produzione

Se devi mettere ordine in un ambiente già vivo, il percorso più sicuro è questo:

1. Seleziona una collection pilota con hardware rappresentativo.
2. Duplica il client setting esistente e abilita solo le classi necessarie.
3. Applica la policy al gruppo pilota e forza un cycle di policy sul client.
4. Verifica il log locale e confronta i dati WMI con quelli in console.
5. Se tutto torna, estendi gradualmente la distribuzione.

Il vantaggio di questo approccio è che il rollback è banale: rimuovi l’assegnazione del client setting o ripristina la versione precedente. Non tocchi i dati già raccolti e non rompi i client che non sono nel perimetro del test.

Se devi intervenire durante un problema in corso, evita di aggiungere nuove classi per “vedere meglio”. Prima chiudi il cerchio con i dati già disponibili. Aggiungere inventario mentre stai diagnostica un mismatch può introdurre rumore e ritardare la lettura del problema vero.

Errori ricorrenti e come evitarli

Il primo errore è trattare l’inventario come una checkbox da attivare una volta per tutte. In realtà va governato: ogni classe ha un costo. Il secondo errore è fidarsi della console senza verificare la sorgente locale. Il terzo è aumentare la frequenza di raccolta quando il problema è la qualità del dato, non la freschezza.

Un altro punto che crea confusione è il confine tra hardware inventory e discovery. La discovery ti dice che un device esiste; l’inventario ti dice come è fatto. Se una macchina è scoperta ma non inventariata correttamente, non hai un problema di presenza nel parco, ma di raccolta o normalizzazione.

Infine, non ignorare la manutenzione del lato SQL. Se il database è già saturo, aggiungere classi o aumentare la frequenza di raccolta peggiora il sintomo. Prima si misura il carico, poi si decide se ottimizzare le classi, il schedule o l’infrastruttura di reporting.

Check finale: cosa deve risultare vero

Alla fine della configurazione, dovresti poter dimostrare quattro cose senza ambiguità:

• il client riceve il client setting corretto;
• le classi WMI richieste esistono e restituiscono dati;
• il log locale mostra il ciclo di inventario completato;
• i dati compaiono nei report o nelle query entro il tempo atteso.

Se uno di questi punti manca, non hai ancora una configurazione affidabile. La parte buona è che il problema è quasi sempre isolabile con strumenti semplici: WMI locale, log del client, stato della policy e verifica del dato nel database. È proprio questa catena di controlli che rende l’inventario hardware utile in ambienti grandi: se lo imposti bene, non è solo una raccolta dati, ma una base solida per compliance, lifecycle e troubleshooting operativo.