1 15/04/2026 9 min

Su Windows Server 2012 e 2012 R2 non esiste un solo posto da controllare per “i log”: il punto di partenza è quasi sempre Visualizzatore eventi, ma i dettagli utili cambiano in base al componente che sta dando problema. Se cerchi un errore generico del sistema, parti dai registri Windows Logs; se stai lavorando su IIS, Active Directory, DNS, Remote Desktop o attività di sicurezza, devi scendere nei canali specifici di Applications and Services Logs.

La regola pratica è semplice: prima identifichi il layer, poi il log. Cercare a caso dentro Event Viewer porta spesso a perdere tempo, soprattutto su server con molti eventi di routine. Qui sotto trovi il percorso operativo, i file fisici dove Windows conserva i log, i comandi utili per leggerli da shell e qualche criterio per capire subito se stai guardando il posto giusto.

Il punto di partenza: Event Viewer

Apri Event Viewer con eventvwr.msc oppure da Server Manager tramite gli strumenti amministrativi. Su Windows Server 2012/2012 R2 la struttura è quella classica:

Event Viewer → Windows Logs → Application, Security, Setup, System, Forwarded Events.

Questi sono i registri che devi controllare per primi quando il problema è generico o non hai ancora isolato il servizio coinvolto.

Application raccoglie eventi delle applicazioni e di molti servizi in user mode: crash di servizi, errori .NET, problemi applicativi, componenti installati. System è il log più utile per driver, servizi di sistema, storage, rete, time service, reboot inattesi. Security contiene gli eventi di audit, quindi accessi, fallimenti di autenticazione, modifiche a oggetti protetti, se l’auditing è attivo. Setup registra installazioni, aggiornamenti e operazioni di setup. Forwarded Events serve se il server riceve eventi inoltrati da altri host.

I log specifici che contano davvero in produzione

Quando il problema riguarda un ruolo preciso, il registro giusto spesso non è nei log principali ma sotto Applications and Services Logs. È qui che Windows e molti ruoli server scrivono gli eventi più utili per il troubleshooting serio.

  1. IIS: controlla Applications and Services Logs > Microsoft > Windows > IIS-* e anche il log applicativo, perché i crash di worker process o gli errori ASP.NET si riflettono spesso lì.
  2. Remote Desktop Services: cerca in Microsoft > Windows > TerminalServices-* per problemi di sessione, autenticazione, licensing e gateway.
  3. DNS Server: usa Microsoft > Windows > DNS-Server per errori di servizio, query, zone e dinamiche di replica.
  4. Active Directory: per Domain Controller e servizi correlati guarda Directory Service, DNS Server, System e i canali sotto Microsoft > Windows > ActiveDirectory_* quando presenti.
  5. Failover Cluster: i problemi di cluster si vedono in Microsoft > Windows > FailoverClustering oltre che in System.
  6. Hyper-V: se il ruolo è installato, i canali Microsoft > Windows > Hyper-V-* sono spesso più utili di un controllo generico del sistema.

Un errore comune è guardare solo Application e System e ignorare i canali del ruolo. Se il server è un DNS, un controller di dominio o un host RDS, il dettaglio spesso sta nei log del componente, non nel registro generale.

Dove sono i file fisici dei log

Se devi copiare i log, archiviarli o analizzarli offline, i file fisici sono in genere sotto C:\Windows\System32\winevt\Logs\. I file hanno estensione .evtx.

Esempi tipici:

C:\Windows\System32\winevt\Logs\System.evtx
C:\Windows\System32\winevt\Logs\Application.evtx
C:\Windows\System32\winevt\Logs\Security.evtx

Per i canali sotto Applications and Services Logs la corrispondenza non è sempre intuitiva, perché Windows usa una struttura interna gestita dal servizio Event Log. In pratica, conviene esportare dal Visualizzatore eventi invece di andare a caccia del file a mano, soprattutto per i canali più profondi o quando devi preservare il contesto completo dell’evento.

Se vuoi esportare da GUI, il percorso è:

Event Viewer → seleziona il log → Action → Save All Events As...

Usa .evtx se devi riaprire il file in Event Viewer. Usa .txt o .csv solo se ti serve un formato di lettura o import rapido, sapendo che perdi parte della struttura nativa.

Come leggere i log da riga di comando

Su Windows Server 2012/2012 R2 puoi usare wevtutil per interrogare o esportare i registri senza passare dalla GUI. È utile quando lavori in RDP limitata, su server remoti, o quando vuoi costruire una raccolta ripetibile.

Per elencare i log disponibili:

wevtutil el

Per leggere gli ultimi eventi del registro System:

wevtutil qe System /c:20 /f:text

Per esportare un log in formato nativo:

wevtutil epl System C:\Temp\System.evtx

Per filtrare rapidamente eventi critici e di errore del registro Application:

wevtutil qe Application /q:"*[System[(Level=1 or Level=2)]]" /f:text /c:50

Se preferisci PowerShell, puoi usare Get-WinEvent. Su 2012 R2 funziona bene e spesso è più comodo per filtrare per provider, ID evento o intervallo temporale.

Get-WinEvent -LogName System -MaxEvents 20 | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Per cercare un ID specifico in Application:

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000} | Select-Object TimeCreated, ProviderName, Id, Message

Quali eventi guardare per primi

Non tutti gli eventi hanno lo stesso peso. Se il server ha un problema reale, in genere la sequenza utile è questa:

  1. Error e Critical nel periodo del guasto.
  2. Eventi immediatamente precedenti, anche di livello Warning, perché spesso anticipano il crash o il timeout.
  3. Event ID ripetuti in modo ciclico, che indicano retry o dipendenze instabili.
  4. Eventi di avvio e arresto del servizio, per capire se il processo è stato riavviato, terminato o bloccato.

Per esempio, se IIS restituisce 500 o pagina bianca, non fermarti al messaggio lato browser. Guarda Application per errori ASP.NET o del worker process, poi i log di IIS e infine System per problemi di servizio W3SVC, WAS o dipendenze come rete e disco.

Se un server sembra “vivo ma lento”, cerca eventi di storage, timeout di rete, problemi con il controller RAID o warning di memoria. Un sintomo applicativo spesso nasce sotto un livello più in basso.

Log di Windows non significa solo Event Viewer

In pratica operativa, i log di Windows Server 2012 e 2012 R2 non finiscono nel Visualizzatore eventi. A seconda del ruolo, devi affiancare altri file e percorsi.

  • IIS: C:\inetpub\logs\LogFiles\ per i log HTTP, più i log del sito o dell’applicazione se configurati diversamente.
  • DNS: oltre al registro eventi, puoi avere log diagnostici se abilitati nelle proprietà del server DNS.
  • RDP: gli eventi di sessione stanno nei canali TerminalServices, ma lato rete può essere utile anche il firewall log se attivo.
  • PowerShell / script: se hai automazioni, conviene scrivere log applicativi in un path dedicato invece di dipendere solo dagli eventi di sistema.

Il punto è questo: Event Viewer è il centro di raccolta, ma non sempre contiene il dettaglio finale. Per fare troubleshooting serio devi correlare almeno due fonti: eventi di sistema e log del servizio coinvolto.

Filtri pratici per non annegare negli eventi

Su un server usato davvero, aprire il registro senza filtri è quasi sempre una cattiva idea. Meglio restringere subito per livello, data e sorgente.

In GUI:

  1. Apri il log interessato.
  2. Usa Filter Current Log....
  3. Imposta il periodo temporale vicino al guasto.
  4. Se lo conosci, limita per Event sources o Event IDs.

Con PowerShell, un filtro per ultime 24 ore sul log System può essere più rapido della GUI:

$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} |
  Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message

Quando hai un orario preciso del problema, usa quel timestamp come ancora. È il modo più veloce per collegare sintomo, causa e servizio coinvolto.

Permessi e accesso ai log

Non tutti i log sono leggibili da qualsiasi account. Security richiede privilegi adeguati, spesso membership nel gruppo Event Log Readers o diritti amministrativi a seconda del contesto e della policy locale. Anche altri canali protetti possono essere limitati.

Se un operatore “non vede nulla” ma il log esiste, il problema può essere banalmente di autorizzazione. Prima di inseguire falsi guasti, verifica i permessi dell’account che sta aprendo Event Viewer o lanciando PowerShell.

In ambienti gestiti, conviene separare i ruoli: chi fa troubleshooting base legge Application e System; chi gestisce sicurezza e auditing accede a Security e ai canali correlati. È una scelta più pulita anche lato audit.

Una traccia operativa rapida quando il server ha un problema

Se devi aprire un caso in fretta, questa sequenza riduce il rumore:

  1. Annota l’orario preciso del sintomo.
  2. Apri System e Application e filtra sull’intervallo temporale.
  3. Controlla i canali specifici del ruolo: IIS, DNS, RDS, AD, Hyper-V, Cluster.
  4. Esporta gli eventi rilevanti in .evtx per conservarne la struttura.
  5. Se serve correlazione, affianca i log applicativi o HTTP in C:\inetpub\logs\LogFiles\ o nei path del software coinvolto.

Questo approccio evita il classico errore di leggere dieci minuti di eventi inutili e perdere l’unico messaggio che conta. Se il problema è intermittente, conserva almeno gli ultimi eventi prima e dopo il guasto: spesso la causa sta nel warning che tutti ignorano.

Quando il log giusto non c’è

Può capitare che il log che ti aspetti non registri nulla. In quel caso non dare per scontato che “non ci sia stato errore”: potrebbe essere disabilitato, troppo piccolo, sovrascritto, o il servizio potrebbe scrivere altrove.

Le verifiche minime sono queste:

  1. Controlla se il canale è attivo in Event Viewer.
  2. Verifica dimensione e retention del log.
  3. Controlla se il servizio ha log applicativi propri in un path dedicato.
  4. Se il problema è recente ma i log sono vuoti, confronta l’ora di sistema e il fuso orario del server.

Un orario sballato o una retention troppo aggressiva rendono il troubleshooting quasi cieco. Su server vecchi o poco curati è una causa più comune di quanto sembri.

Conclusione operativa

Se stai cercando i log di Windows Server 2012 e 2012 R2, il punto giusto non è “un percorso unico”, ma una gerarchia: Event Viewer per la visione generale, i canali sotto Applications and Services Logs per i ruoli specifici, e i file fisici o i log applicativi quando ti serve preservare o correlare i dati. In troubleshooting vero, la differenza la fa la capacità di passare rapidamente dal sintomo al layer giusto, non la quantità di eventi letti a mano.