Windows Server 2025 / Serverereignisse und Dienstfehler diagnostizieren

Ordnen Sie bei Serverfehlern das beobachtete Problem und seinen Zeitpunkt den passenden Ereignissen und dem Dienstzustand zu. Eine einzelne Ereignisnummer oder eine Liste beendeter Dienste beweist keine Ursache. Vergleichen Sie mit dem normalen Betrieb, bevor Sie Einstellungen verändern.

Symptom, Zeitpunkt und letzte Änderungen festhalten

Notieren Sie bei einer nicht erreichbaren Freigabe Client, Konto, genauen Pfad, Fehlermeldung und Zeitpunkt. Prüfen Sie, ob alle Benutzer oder nur eine Identität betroffen sind und ob weitere Dienste des Computers ausfallen. Halten Sie Updates und Konfigurationsänderungen fest, ohne sie schon zur Ursache zu erklären. Führen Sie die folgenden Abfragen auf dem untersuchten Server, etwa FS1, mit Windows PowerShell aus und nicht versehentlich auf dem Verwaltungscomputer:

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

hostname benennt den Computer dieser Konsole; Get-Date und Get-TimeZone helfen bei der Zeiteinordnung, LastBootUpTime zeigt den letzten Betriebssystemstart. Gleichen Sie Benutzer- und Ereigniszeiten ab, insbesondere bei mehreren Computern, ohne als ersten Schritt die Uhr zu verstellen. Prüfen Sie auch den ausgewählten Zielcomputer jeder Remotekonsole. Eine einzelne Warnung während des Starts ist nicht dasselbe wie ein wiederholter Fehler zum aktuellen Vorfallszeitpunkt.

Den Zeitraum in der Ereignisanzeige eingrenzen

1. Öffnen Sie eventvwr.msc und bestätigen Sie den Zielcomputer im Baum. Untersuchen Sie je nach Problem Windows-Protokolle → System und Anwendung.
2. Wählen Sie das Protokoll und filtern Sie einen Zeitraum vor und nach dem Vorfall. Wählen Sie passende Stufen, ohne Informationsereignisse dauerhaft aus der Untersuchung auszuschließen.
3. Lesen Sie Anbieter, Ereigniskennung, Zeit und Meldung zusammen. Dieselbe Nummer kann bei einem anderen Anbieter etwas anderes bedeuten. Öffnen Sie auch Details für die spezifischen Daten.
4. Prüfen Sie für die betroffene Rolle Anwendungs- und Dienstprotokolle → Microsoft → Windows und die passenden Kanäle. Das Domain Name System (DNS), GroupPolicy für Gruppenrichtlinien und SMBServer für Dateifreigaben sind Beispiele; der genaue Kanal hängt vom installierten Bestandteil ab.
5. Vergleichen Sie die Ereignisse vor und nach dem Fehler. Speichern Sie relevante Ereignisse über den Aktionsbereich als EVTX, das Windows-Ereignisprotokollformat, mit Computer, Anbieter und Zeitraum. Ein zugeschnittener Screenshot ersetzt die Originaldaten nicht.

Die Zahl der Fehler allein beschreibt nicht den Dienstausfall. Informationsereignisse können Start- und Änderungsabläufe erklären und bleiben als Kontext wichtig, auch wenn Sie zunächst Warnungen und Fehler filtern. Löschen Sie keine Protokolle, um historische Meldungen verschwinden zu lassen: Das beseitigt Belege statt Ursachen. Unterscheiden Sie bei Dateizugriffsfehlern Berechtigungen und Sicherheitsverhandlungen wie in der Diagnose von SMB-Signierung und Verschlüsselung. SMB steht für Server Message Block, das Protokoll der Dateifreigabe.

PowerShell-Abfragen gezielt begrenzen

Das folgende Beispiel in einer erhöhten Windows PowerShell des Servers liest höchstens die 50 neuesten kritischen, Fehler- oder Warnereignisse aus System seit einer Stunde vor der Filterzuweisung. Die Get-WinEvent-Filterreferenz erklärt FilterHashtable. Filtern Sie bereits bei der Abfrage, statt zunächst sämtliche Protokolle einzulesen:

$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

Die Ausgabe enthält Zeit, Anbieter, Kennung, Stufe und Meldung. Level=1,2,3 schließt Informationen aus; MaxEvents=50 kann bei vielen Meldungen den Beginn des Fehlers innerhalb der Stunde auslassen. Passen Sie StartTime und bei einem abgeschlossenen Zeitraum EndTime in der Filtertabelle gezielt an. „Keine passenden Ereignisse“ beweist keinen Fehler des Ereignisdienstes. Unterscheiden Sie dies von verweigertem Zugriff oder einem falschen Protokollnamen. Bewahren Sie die ursprüngliche EVTX-Datei auf. Erhalten Sie bei Textexporten Kodierung und Zeilenumbrüche der Meldungen, nicht nur die sichtbaren Ausschnitte einer Konsolentabelle.

Dienstzustand, Startverhalten und Abhängigkeiten trennen

Öffnen Sie services.msc und suchen Sie den konkreten Dienst. Prüfen Sie in Eigenschaften Zustand, Starttyp, Anmeldekonto und Wiederherstellungsoptionen; notieren Sie die Ausgangswerte. Starten Sie nicht jeden beendeten Dienst: Manche laufen bei Bedarf oder durch Trigger, andere existieren nur mit einer installierten Rolle. Verwenden Sie den internen Namen, der vom Anzeigenamen abweichen kann. Hier dient W32Time, der Windows-Zeitdienst, ausschließlich als Abfragebeispiel:

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

Die Klasse Win32_Service unterscheidet State als aktuellen Zustand, StartMode als Startmodus und StartName als ausführendes Konto. StartName ist kein Computername und zeigt kein Kennwort an. Die Auswahl zeigt nicht sämtliche Details zu verzögertem Start, Triggern oder Wiederherstellungsaktionen. Prüfen Sie diese gegebenenfalls, bevor Sie aus „beendet“ auf einen erforderlichen Dauerbetrieb schließen. Auch eine erfolgreiche W32Time-Abfrage diagnostiziert nicht die gesamte Zeitsynchronisierung der Domäne.

Diese Befehle lesen W32Time aus, ohne ihn zu starten oder zu verändern. RequiredServices liefert Dienste, die W32Time benötigt; DependentServices liefert Dienste, die von W32Time abhängen. Die Get-Service-Referenz unterscheidet diese Richtungen. Leere Listen können korrekt sein. Vergleichen Sie Status mit State aus der Konfigurationsabfrage; Running bedeutet einen laufenden Dienst, nicht automatisch eine funktionierende Benutzeraktion.

Ein anderer Starttyp ist nicht dasselbe wie ein einmaliger Start oder Neustart. Stoppt ein Dienst sofort wieder, gleichen Sie den Zeitpunkt mit Konto-, Konfigurations-, Rechte- und Abhängigkeitsfehlern ab, statt ohne Diagnose wiederholt neu zu starten. Wiederherstellungsaktionen können selbst neue Versuche auslösen und die beobachtete Reihenfolge beeinflussen. Ein gemeinsam genutztes Dienstkennwort kann weitere Computer oder Aufgaben betreffen; sein ungeprüftes Zurücksetzen kann den Ausfall vergrößern. Stoppen Sie W32Time nicht als Demonstration in einer Domäne.

Vor einer gezielten Änderung Belege sichern

1. Sichern Sie Protokolle und ursprüngliche Diensteinstellungen einschließlich Start, Identität und Wiederherstellung. Prüfen Sie vor externer Weitergabe interne Namen, Pfade, Konten und Meldungsdaten; bewahren Sie das Original geschützt auf und erstellen eine bereinigte Kopie.
2. Bestimmen Sie, welche Hypothese ein Start oder Neustart prüft, welche Benutzer und abhängigen Dienste betroffen sind und wann der Eingriff möglich ist. Ohne bekannten Umfang oder Wiederherstellungsweg untersuchen Sie weiter, bevor Sie ändern.
3. Ändern Sie nur den begründet betroffenen Dienst und vergleichen Sie Zustand sowie Ereignisse desselben Zeitraums. Ändern Sie nicht gleichzeitig Starttyp, Anmeldedaten, Abhängigkeiten und Zugriffsregeln.
4. Wiederholen Sie die ursprüngliche Aktion am selben Client mit demselben Konto, zum Beispiel das Lesen derselben Freigabedatei. Running allein beweist den Erfolg dieses Zugriffs nicht.
5. Bestätigt sich die Hypothese nicht, setzen Sie nur die selbst geänderten und dokumentierten Werte zurück und prüfen das Ergebnis. Grenzen Sie den nächsten Schritt anhand neuer Belege ein, statt sämtliche Optionen auf angenommene Standardwerte zu setzen.

Änderungen an Windows Remote Management (WinRM), der Windows-Remoteverwaltung, oder anderen Zugangsdiensten können Ihre Sitzung trennen. Halten Sie vor einem Eingriff Konsolenzugang und den dokumentierten Rückweg bereit. Beginnen Sie nicht mit Protokolllöschung, Neustarts aller Dienste oder einem Serverneustart. Der Abschlussnachweis ist die ursprüngliche Aktion mit demselben Client, Konto und Pfad: Sie muss erwartungsgemäß funktionieren, und zusammengehörige Fehler dürfen nicht einfach erneut auftreten. Eine fehlerfrei aussehende Konsole genügt nicht.