1 11/10/2026 11 min

Se devi capire dove finiscono i log di SCOM e come interpretarli, conviene partire da un punto semplice: SCOM non usa un solo archivio centrale “magico”. Una parte delle tracce vive sul server di management, una parte sugli agent Windows, e un’altra passa dai log applicativi di Windows, dai registri operativi di SCOM e dai file testuali dell’agent o del setup. Se cerchi nel posto sbagliato, perdi tempo e rischi di confondere un problema di raccolta con un problema di visualizzazione o di alerting.

La regola pratica è questa: prima identifichi il layer che ti interessa, poi apri il log giusto. Per troubleshooting su SCOM, i layer tipici sono: Management Server, Agent, Console, Gateway, Database e Operations Manager event channel. I sintomi cambiano molto: un agente che non comunica genera errori diversi da una console che non mostra i monitor, e un problema di connettività SQL lascia tracce diverse da un problema di discovery o di management pack.

Dove cercare i log di SCOM

In una installazione standard di Microsoft System Center Operations Manager, i punti di lettura principali sono questi.

  1. Event Viewer sul Management Server: qui trovi gli eventi di SCOM più utili per errori di configurazione, comunicazione, workflow e health service.
  2. Event Viewer sugli agent Windows: qui vedi problemi di discovery, raccolta dati, script, monitor e canale di comunicazione verso il management group.
  3. File dell’agent: nel percorso dell’installazione dell’agente ci sono log testuali del setup e, in alcuni casi, file utili per il tracing.
  4. Log della console e dei componenti locali: utili se la console non si apre, non aggiorna la vista o fallisce il rendering di un management pack.
  5. SQL Server: se SCOM vede dati incoerenti, lentezza o code, il problema può stare nel database OperationsManager, non nell’agent.

Il punto da non sbagliare è che Event Viewer è quasi sempre il primo posto giusto. Nei sistemi Windows moderni, molti componenti SCOM scrivono nel registro eventi anziché in file testuali sparsi. I file restano comunque importanti quando devi verificare il setup, i pacchetti di installazione o un tracing più granulare.

Event Viewer: i canali più utili

Apri eventvwr.msc e guarda soprattutto Applications and Services Logs e Windows Logs. In SCOM i canali più interessanti cambiano in base al ruolo della macchina, ma in pratica ti servono questi riferimenti.

  1. Operations Manager: canale applicativo principale per eventi SCOM sul server o sull’agent.
  2. Health Service: utile per errori del motore di monitoraggio locale.
  3. SDK Service e componenti correlati: utili se la console o le API non rispondono.
  4. System e Application: per problemi di servizio Windows, dipendenze, crash o errori SQL/AD/permessi che impattano SCOM indirettamente.

Se vuoi filtrare in modo efficace, non leggere tutto. Parti da Critical, Error e Warning, poi restringi per intervallo temporale. Se l’alert nasce alle 10:14, controlla i log tra le 10:00 e le 10:30: è il modo più veloce per trovare il primo errore e non il rumore successivo.

Dal lato CLI, puoi estrarre gli eventi recenti con PowerShell:

Get-WinEvent -LogName 'Operations Manager' -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | Format-List

Se il canale non esiste sul sistema, non forzare ipotesi: può voler dire che il ruolo SCOM non è installato, che il logging è su un altro nodo, o che stai guardando una macchina che non è un management server né un agent. In quel caso verifica il ruolo con i servizi Windows presenti o con la console di SCOM.

File di log dell’agent: dove stanno davvero

Quando il problema riguarda l’agent, i file più utili sono quelli del setup e quelli legati al tracing dell’installazione. Il percorso esatto può variare in base alla versione, ma i riferimenti più comuni sono sotto C:\Program Files\Microsoft Monitoring Agent\ oppure sotto il vecchio namespace di Operations Manager sugli host legacy.

  1. C:\Program Files\Microsoft Monitoring Agent\Agent\Logs\: log operativi e diagnostici dell’agent, quando presenti.
  2. C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\: non è un log puro, ma è utile per capire lo stato locale del motore di monitoraggio.
  3. C:\Windows\Temp\ o cartelle temporanee del setup: spesso contengono tracce dell’installazione o dell’upgrade dell’agent.
  4. %LOCALAPPDATA% o profili utente della console: utili se il problema è lato console, snap-in o componenti UI.

Per leggere rapidamente i file testuali, usa strumenti standard. Esempio:

Get-ChildItem 'C:\Program Files\Microsoft Monitoring Agent\Agent\Logs' -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 10 Name, LastWriteTime, Length

Se non trovi nulla in quella cartella, non significa che SCOM non stia registrando eventi. Spesso la diagnostica vera passa dal registro eventi, mentre i file locali servono più come supporto per setup, update o componenti specifici. È un errore comune cercare solo file .log e ignorare i registri di Windows.

Come leggere i log senza perdere tempo

La lettura efficace dei log di SCOM non è “aprire e scorrere”. Serve un metodo. Il più solido è questo: timestamp, componente, ID evento, messaggio, correlazione. Se mancano questi cinque elementi, stai guardando frammenti e non una sequenza diagnostica.

  1. Parti dall’orario del sintomo: alert, blackout, agent down, console lenta, discovery fallita.
  2. Individua il primo errore: non quello più rumoroso, ma quello che compare per primo nella finestra temporale.
  3. Segui il componente: se il messaggio parla di HealthService, non saltare subito a SQL; se parla di SDK, non guardare l’agent remoto.
  4. Verifica la ripetizione: un errore singolo può essere transitorio; una sequenza ripetuta indica un guasto stabile o una dipendenza mancante.
  5. Cerca il codice evento: l’ID è spesso più utile del testo libero, che può cambiare tra versioni e lingue.

Una lettura corretta distingue tre casi: errore di trasporto, errore di elaborazione e errore di persistenza. Se l’agent non parla con il management server, il log mostra timeout, certificati, name resolution o auth. Se il trasporto funziona ma il workflow fallisce, trovi errori di script, monitor, regole o moduli. Se il dato arriva ma non viene salvato o visualizzato, il sospetto si sposta su SQL, code o problemi di reporting.

Un buon filtro PowerShell per eventi recenti e errori:

Get-WinEvent -FilterHashtable @{LogName='Operations Manager'; Level=2; StartTime=(Get-Date).AddHours(-4)} | Select-Object TimeCreated, Id, ProviderName, Message

Se il messaggio è troppo generico, incrocia con il servizio Windows coinvolto. Per esempio, un problema di comunicazione verso il management group spesso si vede insieme a errori del servizio Microsoft Monitoring Agent o HealthService. Un problema di console può invece comparire senza impatto sugli agent, quindi leggere solo lato server porta fuori strada.

Log del Management Server: cosa controllare per primo

Sul Management Server il focus cambia. Qui vuoi capire se il problema è nel motore centrale, nel database, nelle dipendenze o nei workflow che aggregano gli eventi. I servizi da verificare sono quelli SCOM installati localmente, insieme a SQL connectivity e al canale di comunicazione con gli agent e con gli eventuali gateway.

  1. Stato dei servizi SCOM: verifica che i servizi principali siano in esecuzione.
  2. Event Viewer: cerca errori di SDK, HealthService, configuration service e workflow.
  3. SQL Server connectivity: controlla latenza, autenticazione e disponibilità del database OperationsManager.
  4. Spazio disco: un volume pieno può bloccare log, cache e scritture temporanee.

Comandi utili per una verifica rapida:

Get-Service | Where-Object { $_.DisplayName -match 'Operations|Monitoring|Health' } | Select-Object Status, Name, DisplayName

Se un servizio è fermo, non riavviarlo alla cieca prima di capire il motivo. Prima controlla il log eventi e l’ultimo errore con timestamp coerente. Un restart senza contesto può solo spostare il problema di qualche minuto e cancellare il pattern utile alla diagnosi.

Gateway server e agent remoti: log e sintomi tipici

I gateway sono spesso il punto dove si inceppa la comunicazione tra ambienti separati o segmenti di rete. Qui i log ti servono soprattutto per distinguere un problema di certificato, un problema di reachability o un problema di trust.

  1. Certificato scaduto o non fidato: eventi di TLS, trust chain, enrollment fallito.
  2. Firewall o ACL: il log dice timeout o connessione rifiutata, ma la causa è rete.
  3. Hostname o DNS errato: il gateway parla con il nome sbagliato e il trust non si chiude.

In questi casi la verifica minima è sempre doppia: log e connettività. Per esempio:

Test-NetConnection managementserver.fqdn.local -Port 5723

Se la porta non risponde, il log da solo non basta. Devi verificare il percorso di rete, le regole firewall e l’eventuale proxy o appliance intermedia. Se la porta risponde ma il trust fallisce, il problema è più probabilmente lato certificati o configurazione del gateway.

Se la console SCOM non mostra ciò che ti aspetti

Quando la console è lenta, vuota o mostra errori di caricamento, il problema non è per forza nel backend. Può essere un profilo utente corrotto, una cache locale incoerente, un management pack problematico o un SDK non raggiungibile. Qui i log da guardare sono quelli della console, del sistema e del Management Server.

  1. Controlla Event Viewer sul client console per errori applicativi.
  2. Verifica se il problema segue l’utente o la macchina: se cambia PC, è più probabile un profilo o una cache locale.
  3. Se il problema è generalizzato, passa al server e controlla SDK, SQL e servizi SCOM.

Una traccia utile è la presenza di errori di timeout verso l’SDK. In quel caso la console è solo il sintomo finale: il punto da correggere può essere il servizio centrale o la latenza del database. Se invece il log parla di rendering o componenti locali, il problema è più vicino alla workstation o al profilo utente.

Metodo rapido di triage: dal sintomo alla causa

Quando hai pochi minuti, usa questa sequenza. È semplice ma evita il classico errore di aprire dieci log insieme senza una direzione.

  1. Definisci il sintomo: agent down, alert mancante, console lenta, discovery fallita, report incompleto.
  2. Identifica il layer: agent, management server, gateway, database, rete, storage.
  3. Apri il registro giusto: Event Viewer locale prima dei file sparsi.
  4. Recupera il primo errore nel tempo: non l’ultimo.
  5. Correla con servizio e connettività: stato servizio, porta, DNS, spazio disco, account di servizio.

Se vuoi una verifica di base sulla disponibilità dell’agent o del management server, usa sempre strumenti banali prima di ipotesi complesse. Un Test-NetConnection o un controllo del servizio spesso ti dicono subito se stai inseguendo un falso problema applicativo.

Buone pratiche per non perdere la traccia giusta

I log di SCOM diventano davvero utili quando il sistema è configurato per essere leggibile. Alcune abitudini fanno risparmiare ore.

  • Sincronizza l’orario tra agent, management server e gateway: senza time sync i log diventano poco correlabili.
  • Documenta i ruoli dei server: sapere se una macchina è agent, gateway o management server evita letture sbagliate.
  • Conserva una baseline degli eventi normali: ti aiuta a distinguere il rumore dagli errori reali.
  • Versiona le modifiche ai management pack e alle configurazioni: molti problemi si capiscono solo confrontando prima e dopo.
  • Riduci il rumore degli alert duplicati: meno rumore nei log, più velocità nel trovare la causa.

Se devi fare troubleshooting ricorrente, conviene anche preparare un piccolo set di query PowerShell o una checklist operativa. Il vantaggio non è estetico: è che ogni volta parti dagli stessi punti e confronti sempre gli stessi indicatori. In ambienti grandi, questo fa la differenza tra diagnosi rapida e caccia al messaggio giusto per tentativi.

In pratica: la lettura corretta dei log di SCOM

Se devi ricordarti una sola cosa, è questa: SCOM si legge per correlazione, non per curiosità. Aprire il log giusto è importante, ma ancora più importante è collegarlo al layer corretto e al momento esatto del guasto. In quasi tutti i casi reali la causa emerge incrociando tre elementi: evento, servizio e connettività.

Per questo, quando cerchi i file di log di SCOM, non fermarti al percorso fisico. Guarda il canale Event Viewer, identifica il ruolo della macchina, controlla i servizi coinvolti e usa i file testuali solo quando servono davvero. È il modo più veloce per capire se stai davanti a un problema di agent, di management server, di gateway o di infrastruttura sottostante.

Se il dato manca, non inventarlo: il campo o il canale giusto va verificato sul sistema specifico, perché versioni diverse di SCOM e installazioni personalizzate possono spostare nomi, percorsi e dettagli di logging. La chiusura del gap è semplice: controlla Event Viewer, servizi installati e cartelle dell’agent sul nodo interessato.