Windows Server 2025 / Diagnosticare eventi del server e guasti dei servizi

Per diagnosticare un guasto del server, colleghi il problema dell'utente e il suo orario agli eventi pertinenti e allo stato del servizio. Un singolo ID evento o un elenco di servizi arrestati non dimostra la causa. Confronti il comportamento con il normale funzionamento prima di modificare impostazioni.

Registrare sintomo, orario e modifiche recenti

Se una condivisione non è accessibile, annoti client, account, percorso esatto, messaggio di errore e ora. Verifichi se sono coinvolti tutti gli utenti o una sola identità e se falliscono altri servizi sul computer. Registri aggiornamenti e modifiche senza considerarli già la causa. Esegua le query seguenti in Windows PowerShell sul server interessato, per esempio FS1, evitando di interrogare per errore il computer di amministrazione:

hostname
Get-Date
Get-TimeZone
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime

hostname identifica il computer della console; Get-Date e Get-TimeZone aiutano a interpretarne orologio e fuso, mentre LastBootUpTime indica l'ultimo avvio del sistema. Allinei gli orari riferiti dall'utente con gli eventi, soprattutto confrontando più computer, senza cambiare subito l'ora. Controlli anche il computer selezionato in ogni console remota. Un avviso isolato durante l'avvio non equivale a un errore ripetuto nel momento dell'incidente.

Restringere l’intervallo nel Visualizzatore eventi

1. Apra eventvwr.msc e confermi il computer nell'albero. Esamini Registri di Windows → Sistema e Applicazione in base al sintomo.
2. Selezioni il registro e filtri un intervallo prima e dopo l'incidente. Scelga livelli pertinenti senza escludere definitivamente gli eventi informativi dal contesto.
3. Legga insieme provider, ID, ora e messaggio. Lo stesso numero da un provider diverso può avere altro significato; apra anche Dettagli per i dati specifici.
4. Per il ruolo coinvolto, esamini Registri applicazioni e servizi → Microsoft → Windows e i canali appropriati. Domain Name System (DNS) per i nomi di dominio, GroupPolicy per i criteri di gruppo e SMBServer per i file condivisi sono esempi; il canale esatto dipende dai componenti installati.
5. Confronti gli eventi prima e dopo il guasto. Dal riquadro delle azioni salvi quelli pertinenti in EVTX, il formato dei registri eventi di Windows, conservando computer, provider e intervallo. Una schermata ritagliata non sostituisce i dati originali.

Il numero di errori non misura da solo l'impatto sul servizio. Gli eventi informativi possono spiegare sequenze di avvio e modifica e restano utili anche se il filtro iniziale privilegia avvisi ed errori. Non cancelli i registri per far sparire messaggi storici: eliminerebbe prove senza risolvere la causa. Per gli accessi ai file negati, distingua autorizzazioni e negoziazione seguendo la diagnosi di firma e crittografia SMB. SMB significa Server Message Block, il protocollo di condivisione dei file.

Usare query PowerShell con limiti precisi

Il seguente esempio in Windows PowerShell con privilegi elevati sul server legge al massimo i 50 eventi più recenti di livello critico, errore o avviso da System, a partire da un'ora prima dell'assegnazione del filtro. La documentazione dei filtri di Get-WinEvent descrive FilterHashtable. Filtri al momento della raccolta senza leggere prima tutti i registri del computer:

$eventFilter = @{
    LogName = 'System'
    StartTime = (Get-Date).AddHours(-1)
    Level = 1,2,3
}
Get-WinEvent -FilterHashtable $eventFilter -MaxEvents 50 |
    Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message

L'output contiene ora, provider, ID, livello e messaggio. Level=1,2,3 esclude gli eventi informativi; MaxEvents=50 può tralasciare l'inizio del guasto se nell'ora vi sono molti eventi. Adatti StartTime e, se deve delimitare la fine dell'intervallo, EndTime nella tabella filtro in modo mirato. L'assenza di eventi corrispondenti non dimostra un guasto del servizio eventi. La distingua da accesso negato o nome di registro errato. Conservi il file EVTX originale; per esportazioni testuali mantenga codifica e interruzioni di riga dei messaggi, non soltanto i frammenti visibili nella tabella della console.

Distinguere stato, avvio e dipendenze del servizio

Apra services.msc e trovi il servizio preciso. In Proprietà controlli stato, tipo di avvio, account di accesso e opzioni di ripristino, annotando i valori iniziali. Non avvii tutti i servizi arrestati: alcuni funzionano su richiesta o tramite trigger, altri esistono solo con un ruolo installato. Usi il nome interno, che può differire dal nome visualizzato. Qui W32Time, il servizio Ora di Windows, è solo un esempio di interrogazione:

Get-Service -Name W32Time
Get-Service -Name W32Time -RequiredServices
Get-Service -Name W32Time -DependentServices
Get-CimInstance Win32_Service -Filter "Name='W32Time'" | Select-Object Name,State,StartMode,StartName

La classe Win32_Service distingue State, stato corrente, StartMode, modalità di avvio, e StartName, account che esegue il servizio. StartName non è il nome del computer e non mostra la password. Questa selezione non include tutti i dettagli di avvio ritardato, trigger o azioni di ripristino. Li verifichi prima di concludere che un servizio arrestato debba essere sempre attivo. Una query W32Time riuscita non diagnostica da sola tutta la sincronizzazione oraria del dominio.

I comandi leggono W32Time senza avviarlo o modificarlo. RequiredServices restituisce i servizi necessari a W32Time; DependentServices quelli che dipendono da W32Time. La documentazione di Get-Service distingue le due direzioni. Un elenco vuoto può essere corretto. Confronti Status con State della query di configurazione: Running indica un servizio in esecuzione, non il successo automatico dell'operazione dell'utente.

Cambiare il tipo di avvio è diverso dall'avviare o riavviare una volta il servizio. Se si arresta subito, colleghi l'orario a errori di account, configurazione, autorizzazioni o dipendenze invece di ripetere riavvii senza diagnosi. Le azioni nella scheda Ripristino possono generare nuovi tentativi e influire sulla sequenza osservata. Una password di servizio condivisa può essere usata da altri computer o attività; reimpostarla senza controllare gli utilizzatori può ampliare il guasto. Non arresti W32Time in un dominio solo per dimostrare questi concetti.

Conservare le prove prima di una modifica mirata

1. Salvi registri e impostazioni iniziali del servizio, inclusi avvio, identità e ripristino. Prima della condivisione esterna controlli nomi interni, percorsi, account e dati dei messaggi; protegga l'originale e prepari una copia con i dati riservati oscurati.
2. Definisca quale ipotesi verrà verificata con avvio o riavvio, utenti e servizi dipendenti coinvolti e momento dell'intervento. Se non conosce impatto o percorso di ripristino, continui l'indagine prima di cambiare.
3. Applichi solo la modifica motivata al servizio pertinente e confronti stato ed eventi dello stesso intervallo. Non cambi insieme avvio, credenziali, dipendenze e regole di accesso.
4. Ripeta l'operazione originale dallo stesso client e account, per esempio la lettura dello stesso file condiviso. Running da solo non dimostra che l'accesso sia riuscito.
5. Se l'ipotesi non è confermata, ripristini solo i valori modificati e registrati e ne verifichi l'effetto. Delimiti il passo successivo con nuove prove, senza riportare tutte le opzioni a valori predefiniti presunti.

Modificare Windows Remote Management (WinRM), la gestione remota di Windows, o altri servizi di accesso può interrompere la propria sessione. Prima dell'intervento disponga di accesso alla console e di un percorso documentato per tornare ai valori iniziali. Non inizi cancellando registri, riavviando tutti i servizi o riavviando il server. La verifica conclusiva è ripetere l'operazione originale con client, account e percorso uguali: deve funzionare come previsto, senza continuare a produrre gli errori correlati. Una console apparentemente priva di errori non basta.