Quando Asset Intelligence in SCCM smette di dare risultati coerenti, il problema raramente è “solo un log”. Di solito il guasto sta in uno di questi punti: raccolta dati sul client, invio verso il management point, elaborazione lato site server, sincronizzazione del catalogo o report che leggono dati incompleti. La diagnosi efficace parte sempre da un fatto semplice: il log giusto cambia a seconda del layer che stai osservando.
La domanda utile non è “Asset Intelligence funziona?”, ma “dove si interrompe il flusso?”. Se il client raccoglie, ma il server non importa, vedrai un tipo di errore. Se il catalogo non si allinea, il sintomo è diverso. Se i dati ci sono ma i report mostrano vuoti, il problema è ancora un altro. In SCCM conviene leggere i log come una catena, non come file isolati.
Il flusso corretto di Asset Intelligence
In una configurazione sana, il client inventaria software e hardware, genera i dati utili ad Asset Intelligence, li invia al site, il site li elabora e li rende disponibili per console e report. In parallelo, il catalogo Asset Intelligence deve essere aggiornato e distribuito correttamente. Se uno di questi passaggi si rompe, il sintomo finale cambia.
Per questo motivo, prima di aprire i log, conviene classificare il problema in quattro categorie operative:
Questa distinzione evita di perdere tempo su file che non hanno nulla a che vedere con il guasto reale.
Log da controllare per primi
I log non sono tutti equivalenti. In Asset Intelligence i più utili, in pratica, sono quelli che mostrano il passaggio dei dati e l’elaborazione. A seconda del punto in cui ti trovi, i file più interessanti possono essere sul client o sul site server.
Se non hai già un elenco preciso dei log nella tua versione di Configuration Manager, la via più sicura è partire dalla console e dalla documentazione della build in uso. I nomi dei file e la posizione possono variare leggermente tra versioni e ruoli installati.
Un errore frequente è aprire subito il log “più famoso” e ignorare il contesto. In realtà, se il sintomo è un catalogo non aggiornato, il file giusto non è quello della raccolta client, ma quello della sincronizzazione del catalogo o del componente che importa i dati al site.
Diagnosi dal sintomo: cosa significa davvero l’errore
La lettura corretta parte dal messaggio nel log e dal punto della catena in cui compare. Alcuni pattern sono molto ricorrenti.
Dati assenti sul client
Se il client non produce dati o li produce in modo incompleto, il problema sta spesso nel ciclo di inventory, in una policy non arrivata, o in un componente del client disattivato. Qui il log utile mostra raccolta non avviata, inventory incompleta o errori di accesso a WMI o al provider locale.
Verifica rapida: controlla che la policy sia arrivata al client e che l’inventory sia stata eseguita di recente. Se il client non aggiorna nemmeno altri dati, il problema è più ampio del solo Asset Intelligence.
Dati presenti ma non importati dal site
Se sul client i dati ci sono, ma il site non li elabora, il log del server di solito mostra code bloccate, errori di parsing, problemi di accesso al database o fallimenti temporanei nel componente che gestisce l’import. In questo caso non serve toccare il client: va verificato il lato server, la coda di elaborazione e lo stato dei servizi coinvolti.
Segnale tipico: il numero di record ricevuti cresce ma i report non cambiano, oppure il backlog aumenta e non si svuota. Questa è una differenza importante, perché distingue un problema di trasporto da un problema di elaborazione.
Catalogo Asset Intelligence non sincronizzato
Quando il catalogo è vecchio, incompleto o non coerente con la console, i dati possono anche essere presenti nel database, ma le classificazioni non tornano. Qui il log di sincronizzazione del catalogo è spesso più utile di qualsiasi altro. Un fallimento in questa fase può dare l’impressione che i dati “mancano”, quando in realtà sono solo mappati male o non aggiornati.
Se il catalogo non si aggiorna, verifica anche la connettività verso la fonte del catalogo, eventuali proxy, certificati, filtri di rete e la riuscita della sincronizzazione precedente. In ambienti aziendali il problema nasce spesso da un cambiamento di rete più che da SCCM in sé.
Checklist di verifica rapida sul server
Prima di fare modifiche, conviene confermare lo stato dei servizi e la presenza di eventuali backlog. Le verifiche sotto sono prudenti e non invasive.
Se hai accesso al server, una verifica base dello stato dei servizi può essere utile. Il comando sotto è solo diagnostico e non modifica nulla.
Get-Service | Where-Object { $_.DisplayName -match 'Configuration Manager|SMS' } | Sort-Object Status, DisplayNameOutput atteso: servizi in stato Running, senza riavvii ripetuti o stati intermedi. Se un servizio è fermo, il primo passo non è riavviarlo alla cieca: prima va capito perché si è fermato, leggendo il log associato.
Verifica dal client: quando il problema nasce prima del site
Se il sospetto è che il client non stia producendo dati corretti, la verifica va fatta sul device interessato. Qui il punto non è solo controllare il log, ma capire se l’inventory è stata eseguita e se i dati sono coerenti con la macchina.
Il confronto tra un client sano e uno rotto spesso è più veloce di qualsiasi analisi teorica. Se il log su una macchina mostra un errore e sull’altra no, il pattern è già utile per capire se il problema è locale, di policy o di versione.
Verifica del catalogo: il caso che inganna più spesso
Un catalogo non aggiornato può fare sembrare rotto tutto il resto. In realtà, i dati possono essere stati raccolti correttamente, ma la classificazione non viene aggiornata o la console mostra informazioni vecchie. Qui bisogna verificare tre cose: sincronizzazione, continuità del processo e coerenza temporale tra catalogo e report.
Se il catalogo è gestito da una sincronizzazione periodica, controlla se l’ultimo run è andato a buon fine, se i tempi sono coerenti e se non ci sono stati cambi di rete o di credenziali. Anche un semplice problema DNS o un blocco proxy può interrompere il flusso senza produrre sintomi “ovvi” nella console.
In questi casi la soluzione non è rigenerare tutto alla cieca, ma identificare il singolo punto di rottura. Se la sincronizzazione fallisce sempre nello stesso punto, hai un indizio forte su rete, autenticazione o aggiornamento del catalogo.
Comandi utili per raccogliere evidenze
Quando serve un quadro minimo e ripetibile, conviene raccogliere evidenze sia dal sistema sia dai log. I comandi sotto non modificano lo stato del server.
# Stato servizi rilevanti sul server SCCM / site server (PowerShell)Get-Service | Where-Object { $_.Name -like 'SMS*' -or $_.DisplayName -like '*Configuration Manager*' } | Sort-Object Name | Format-Table -AutoAtteso: servizi attivi e stabili. Se un servizio compare in stop o in restart continuo, annota orario e correlalo al log prima di fare altro.
# Verifica spazio disco dove risiedono log e databaseGet-PSDrive -PSProvider FileSystem | Sort-Object Free -Ascending | Format-Table Name,Used,Free -AutoAtteso: spazio libero sufficiente sui volumi che ospitano log, coda e database. Se il disco è quasi pieno, un errore di Asset Intelligence può essere solo un sintomo secondario.
# Raccolta rapida delle ultime righe di un log, se conosci il pathGet-Content 'C:
uta o he ile.log' -Tail 100Usa il path reale del tuo ambiente. Se non lo conosci, recuperalo dalla console o dalla documentazione della build in uso.
Soluzione pratica: come intervenire senza fare danni
La regola è semplice: prima correggi il layer più basso che mostra un’anomalia evidente, poi risali. Se il problema è nel client, non serve toccare il catalogo. Se il catalogo è rotto, non serve rigenerare policy a cascata.
Se devi fare una modifica, falla nel modo più reversibile possibile: un servizio riavviato in finestra controllata, una policy rieseguita su un singolo client, una sincronizzazione manuale solo dopo aver salvato il contesto. Evita azioni massive finché non hai isolato il problema.
Blast radius: potenzialmente ampio se tocchi servizi di site o sincronizzazioni globali; basso se limiti la verifica a un singolo client o a un singolo log. Rollback: ripristino della configurazione precedente, annullamento di eventuali modifiche ai componenti e ritorno allo stato precedente del servizio, se hai cambiato qualcosa.
Errori tipici da non sottovalutare
Ci sono alcuni errori ricorrenti che rendono la diagnosi più lunga del necessario.
Un’altra trappola classica è la sincronizzazione ripetuta nel tentativo di “forzare” il risultato. Se la causa è un errore strutturale, stai solo moltiplicando i tentativi falliti e facendo crescere il rumore nei log.
Metodo rapido di lettura del log
Quando apri un log di Asset Intelligence, cerca nell’ordine: timestamp, componente, errore, codice, ripetizione del pattern. Se il messaggio compare una sola volta e poi tutto riparte, può essere un disturbo transitorio. Se compare a ogni run con la stessa firma, hai un problema riproducibile.
Questo approccio riduce gli errori di interpretazione. In SCCM la cronologia è spesso più importante della singola riga rossa.
Quando fermarsi e chiedere dati in più
Se non hai almeno questi tre elementi, non conviene improvvisare:
Con questi dati puoi distinguere un guasto di raccolta da un problema di sincronizzazione e scegliere il passo minimo corretto. Senza, il rischio è intervenire nel posto sbagliato e allungare il fermo invece di ridurlo.
Assunzioni: l’ambiente è un site SCCM in produzione, con log accessibili sul client e sul server, e l’obiettivo è isolare il punto di rottura senza modifiche invasive.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.