Windows Server: controlli su Event Log, cluster e storage

Quando un server Windows mostra rallentamenti, disconnessioni o comportamenti instabili, la causa spesso non è unica. Prima di intervenire in modo invasivo, conviene fare una verifica ordinata di Event Log, stato del cluster, spazio disco e latenza dello storage. In pochi minuti puoi capire se il problema è locale, di rete o legato alle dipendenze del servizio.

Questa checklist è pensata per amministratori che vogliono un controllo rapido ma solido, utile sia su macchine singole sia in ambienti virtualizzati o ad alta disponibilità.

Da dove iniziare: il segnale più recente

Il primo passo è cercare l’errore più vicino all’orario del problema. In Visualizzatore eventi conviene filtrare per:

• Error e Critical
• origine del servizio coinvolto
• Eventi di storage, rete, cluster e applicazioni

Se il guasto è intermittente, controlla anche i warning ripetuti: spesso anticipano il blocco vero e proprio.

Un errore isolato conta poco; una sequenza di warning nello stesso intervallo di tempo racconta quasi sempre la causa reale.

Comandi utili per una prima lettura

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2} -MaxEvents 50 | Select-Object TimeCreated, Id, ProviderName, Message

Se vuoi restringere il campo, sostituisci System con Application o con il log del servizio interessato.

Verifica dello storage: spazio, latenze e code

Molti problemi apparentemente “applicativi” nascono in realtà da dischi pieni o lenti. Controlla subito:

• spazio libero sulle unità di sistema e dati
• latenza media del volume
• presenza di errori nel controller o nel file system
• eventuali snapshot o backup che stanno saturando I/O

Se il server usa dischi virtuali, verifica anche la salute dell’hypervisor e del datastore. Un volume con spazio sufficiente può comunque rispondere male se la coda I/O è troppo alta.

Indicatori da osservare

• tempo di risposta sopra la norma
• picchi di utilizzo disco senza carico applicativo evidente
• errori di timeout verso database o share di rete

In caso di dubbio, confronta l’ora dell’anomalia con l’avvio di backup, antivirus o job pianificati.

Cluster e ruoli: il problema è davvero sul nodo?

Se il server fa parte di un cluster, il nodo può sembrare sano mentre il ruolo è instabile. Verifica lo stato delle risorse e la presenza di failover recenti. Un ruolo che migra spesso indica un problema di dipendenza, rete o storage condiviso.

Controlla inoltre se:

• il nodo è in Paused o Draining
• esistono risorse offline
• il quorum è stabile
• ci sono disallineamenti tra nodo e storage condiviso

Get-ClusterNode

Get-ClusterGroup

Get-ClusterResource | Where-Object {$_.State -ne 'Online'}

Se un ruolo continua a spostarsi senza motivo, il log del cluster è spesso più utile del log di sistema.

Rete e dipendenze: timeout, DNS e autenticazione

Molti servizi Windows non falliscono per un crash, ma per una dipendenza che risponde in ritardo. Le cause più frequenti sono DNS lento, autenticazione interrotta, share SMB non raggiungibili o firewall che blocca una porta necessaria.

Prima di toccare la configurazione, verifica:

• risoluzione nome verso host interni
• raggiungibilità delle porte usate dal servizio
• latenza verso controller di dominio o database
• eventi di timeout nel log applicativo

Se noti problemi solo in orari precisi, controlla eventuali saturazioni di rete o manutenzioni pianificate.

Servizi e dipendenze: il riavvio non basta sempre

Un servizio che riparte manualmente ma poi si ferma di nuovo spesso dipende da un componente esterno. Prima di riavviare in loop, annota:

• account usato dal servizio
• dipendenze dichiarate
• cartelle temporanee e directory di log
• certificati scaduti o permessi cambiati

Se l’avvio fallisce subito, il problema può essere un permesso negato o una libreria mancante dopo un aggiornamento.

Controllo veloce dei servizi critici

Get-Service | Where-Object {$_.Status -ne 'Running'} | Select-Object Name, Status, StartType

Per i servizi più importanti, valuta anche il tipo di avvio automatico e la risposta ai restart.

Quando serve approfondire subito

Se il problema coinvolge più nodi, più servizi o si ripresenta dopo ogni riavvio, non fermarti al sintomo. In quel caso conviene raccogliere:

• ora esatta del primo errore
• eventi correlati nei 10-15 minuti precedenti
• stato di storage e cluster
• modifiche recenti su patch, driver o policy

Questi dati riducono molto il tempo di diagnosi e aiutano a distinguere tra guasto temporaneo e configurazione difettosa.

Checklist finale in 60 secondi

1. leggi gli ultimi errori in Event Log
2. controlla spazio e latenza del disco
3. verifica stato di cluster e risorse
4. testa rete, DNS e dipendenze
5. conferma che servizi e account siano corretti

Un controllo ordinato evita interventi casuali e ti porta più velocemente alla causa reale. In ambito server, la diagnosi migliore è quasi sempre quella che parte dai segnali più vicini al guasto e risale con metodo.