8. Betriebssystem- und Serveranalyse

8.1 Windows-Prozesse und Dienste gezielt untersuchen

Kurzbeschreibung

Wenn ein Windows-System langsam reagiert, eine Anwendung nicht startet, ein Dienst ausfällt oder ein Prozess ungewöhnliche Ressourcen verbraucht, muss der verursachende Prozess einschließlich seiner Abhängigkeiten untersucht werden.

Windows-Bordmittel und die Microsoft-Sysinternals-Werkzeuge ermöglichen unter anderem die Analyse von:

Ein auffälliger Prozess ist nicht automatisch die eigentliche Ursache. Er kann selbst auf eine Datei, eine Sperre, einen Treiber, eine Datenbank, das Netzwerk oder einen anderen Dienst warten.

1. Typische Symptome

2. Mögliche Auswirkungen

3. Sicherheits- und Betriebswarnung

Sysinternals-Werkzeuge können tiefgehende Informationen über Prozesse, Benutzer, Dateien und Netzwerkverbindungen anzeigen. Diagnoseergebnisse können enthalten:

Besondere Vorsicht gilt bei:

Ein vollständiges Speicherabbild kann sensible Daten wie Kennwörter, Tokens, Schlüssel oder Anwendungsdaten enthalten. Dump-, ETL- und PML-Dateien müssen deshalb geschützt gespeichert und nach Abschluss der Analyse kontrolliert gelöscht werden.

Werkzeuge sollten nur aus der offiziellen Microsoft-Quelle bezogen werden. Vor dem Einsatz auf einem Produktivsystem sind Auswirkung, benötigter Speicherplatz und mögliche Leistungseinflüsse zu prüfen.

4. Werkzeugauswahl

Fragestellung Geeignetes Werkzeug
Welcher Prozess benötigt CPU oder RAM? Task-Manager, Ressourcenmonitor, PowerShell, Process Explorer
Welcher Dienst gehört zu einem Prozess? Task-Manager, tasklist /svc, Process Explorer
Welcher Prozess hat eine Datei geöffnet? Ressourcenmonitor, Handle, Process Explorer
Welche DLLs hat ein Prozess geladen? Process Explorer, ListDLLs
Warum erhält eine Anwendung „Zugriff verweigert“? Process Monitor, AccessChk
Welcher Prozess stellt eine Netzwerkverbindung her? TCPView, Get-NetTCPConnection
Was wird beim Systemstart automatisch geladen? Autoruns
Warum stürzt eine Anwendung ab? Ereignisanzeige, Zuverlässigkeitsverlauf, ProcDump, WinDbg
Warum reagiert ein Prozess nicht mehr? Process Explorer, ProcDump, Wait-Chain-Analyse
Welcher Prozess erzeugt Registry- oder Dateisystemzugriffe? Process Monitor
Warum ist das System zeitweise langsam? Leistungsüberwachung, WPR und WPA
Wie hängen Prozesse zusammen? Process Explorer
Welche Prozesse sind signiert? Process Explorer, Sigcheck
Welche Berechtigung besitzt ein Benutzer oder Dienst? AccessChk, whoami

5. Benötigte Informationen

Vor der Diagnose sollten mindestens folgende Informationen vorliegen:

Computer:
Betriebssystem und Build:
betroffene Anwendung:
betroffener Dienst:
Prozessname:
Prozess-ID:
Benutzerkonto des Prozesses:
Beginn des Problems:
exakte Fehlermeldung:
Fehlercode oder Event-ID:
reproduzierbar:
letzter funktionierender Zeitpunkt:
letzte Änderung:
betroffene Benutzer:
Auswirkung:
bereits durchgeführte Maßnahmen:

Zusätzlich hilfreich:

6. Ausgangszustand sichern

Vor einem Neustart oder dem Beenden eines Prozesses sollten flüchtige Informationen dokumentiert werden.

Get-Date

Get-ComputerInfo |
    Select-Object WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber,
                  OsLastBootUpTime

Laufende Prozesse sichern:

Get-Process |
    Sort-Object ProcessName |
    Select-Object ProcessName,
                  Id,
                  CPU,
                  WorkingSet64,
                  Handles,
                  Threads

Laufende Dienste sichern:

Get-Service |
    Where-Object Status -eq 'Running' |
    Sort-Object Name

Aktive TCP-Verbindungen sichern:

Get-NetTCPConnection |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Ereignisse der letzten zwei Stunden:

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

Die Ausgabe kann bei Bedarf kontrolliert in Dateien exportiert werden. Dabei sind Datenschutz und Speicherort zu beachten.

7. Sichere Schnellprüfung

  1. Exakte Fehlermeldung und Uhrzeit dokumentieren.
  2. Prozess- und Dienststatus prüfen.
  3. CPU, Arbeitsspeicher, Handles und Threads vergleichen.
  4. System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen.
  5. Mit Process Explorer Prozessbaum und Eigenschaften prüfen.
  6. Mit Process Monitor nur den betroffenen Prozess aufzeichnen.
  7. Netzwerkverbindungen mit TCPView oder PowerShell prüfen.
  8. Erst nach gesicherter Diagnose eine kontrollierte Maßnahme durchführen.

8. Prozesse mit PowerShell untersuchen

Alle Prozesse anzeigen:

Get-Process

Prozesse nach CPU-Gesamtzeit sortieren:

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            CPU,
                            WorkingSet64,
                            Handles,
                            Threads

Prozesse nach Arbeitsspeicher sortieren:

Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            WorkingSet64,
                            PagedMemorySize64,
                            VirtualMemorySize64

Prozesse mit vielen Handles:

Get-Process |
    Sort-Object Handles -Descending |
    Select-Object -First 15 ProcessName,
                            Id,
                            Handles

Bestimmten Prozess untersuchen:

Get-Process -Id <PID> |
    Format-List *

Prozess mit CIM einschließlich Befehlszeile und Elternprozess:

Get-CimInstance Win32_Process |
    Where-Object ProcessId -eq <PID> |
    Select-Object Name,
                  ProcessId,
                  ParentProcessId,
                  ExecutablePath,
                  CommandLine,
                  CreationDate

Der Wert CPU bei Get-Process ist die seit dem Prozessstart verbrauchte Prozessorzeit und keine momentane prozentuale CPU-Auslastung.

9. Prozess-ID und Dienst zuordnen

Eine Prozess-ID kann sich nach jedem Neustart des Prozesses ändern. Bei der Dokumentation müssen deshalb PID, Zeitpunkt und Prozessstart zusammen betrachtet werden.

Windows-Befehl:

tasklist /svc

Bestimmte PID suchen:

tasklist /svc /fi "PID eq <PID>"

Dienste einschließlich Prozess-ID:

Get-CimInstance Win32_Service |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  ProcessId,
                  StartName

Dienst zu einer PID suchen:

Get-CimInstance Win32_Service |
    Where-Object ProcessId -eq <PID> |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName

Mehrere Windows-Dienste können innerhalb desselben svchost.exe-Prozesses ausgeführt werden. Der Prozessname allein reicht deshalb nicht zur eindeutigen Zuordnung.

10. Dienste untersuchen

Alle Dienste:

Get-Service |
    Sort-Object Status, Name

Automatisch startende, aber nicht laufende Dienste:

Get-CimInstance Win32_Service |
    Where-Object {
        $_.StartMode -eq 'Auto' -and
        $_.State -ne 'Running'
    } |
    Select-Object Name,
                  DisplayName,
                  State,
                  StartMode,
                  StartName,
                  ExitCode

Bestimmten Dienst prüfen:

Get-Service -Name <Dienstname>

Ausführliche Dienstkonfiguration:

sc.exe qc <Dienstname>

Aktuellen Dienststatus:

sc.exe queryex <Dienstname>

Abhängigkeiten anzeigen:

Get-Service -Name <Dienstname> -DependentServices
Get-Service -Name <Dienstname> -RequiredServices

Zu prüfen sind:

Ein Dienst darf nicht allein deshalb gestartet werden, weil sein Starttyp auf „Automatisch“ steht. Verzögert gestartete Dienste, Triggerstart, Clustersteuerung oder bewusst deaktivierte Komponenten müssen berücksichtigt werden.

11. Ereignisanzeige untersuchen

Wichtige Protokollbereiche:

Fehler und Warnungen der letzten zwei Stunden:

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

Ereignisse eines bestimmten Anbieters:

Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = '<Provider>'
    StartTime    = (Get-Date).AddHours(-2)
}

Ereignisse eines bestimmten Zeitraums:

$Start = Get-Date '2026-08-02 09:00:00'
$Ende  = Get-Date '2026-08-02 10:00:00'

Get-WinEvent -FilterHashtable @{
    LogName   = 'System', 'Application'
    StartTime = $Start
    EndTime   = $Ende
}

Wichtige Grundregel:

Zuerst nach Zeitpunkt, betroffener Komponente und technischer Wirkung filtern. Nicht jeder Fehler oder jede Warnung in der Ereignisanzeige gehört zur untersuchten Störung.

12. Dienstfehler im Systemprotokoll

Der Service Control Manager protokolliert Start-, Stopp- und Dienstfehler im Systemprotokoll.

Beispielhafte Abfrage:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    StartTime    = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Häufig relevante Ereignisarten betreffen:

Event-IDs dürfen nicht ohne Prüfung von Provider, Windows-Version und vollständigem Ereignistext interpretiert werden.

13. Process Explorer verwenden

Process Explorer zeigt Prozesse hierarchisch in einem Prozessbaum an.

Wichtige Informationen:

Empfohlene Vorgehensweise:

  1. Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen.
  2. View → Show Process Tree verwenden.
  3. Unter View → Select Columns benötigte Spalten aktivieren.
  4. Betroffenen Prozess markieren.
  5. Eigenschaften des Prozesses öffnen.
  6. Image, Performance, Threads, TCP/IP und Security prüfen.
  7. Prozesspfad und digitale Signatur kontrollieren.
  8. Eltern- und Kindprozesse dokumentieren.
  9. Auffällige Threads oder Handles untersuchen.
  10. Prozess erst nach Sicherung der Ergebnisse verändern.

Hilfreiche Markierungen im Prozessbaum können auf unterschiedliche Prozessarten oder Lebenszyklen hinweisen. Die Farbdarstellung ist konfigurierbar und darf nicht ohne Prüfung der eingestellten Farblegende interpretiert werden.

14. Threads untersuchen

Ein Prozess kann insgesamt unauffällig erscheinen, obwohl ein einzelner Thread dauerhaft einen CPU-Kern beansprucht.

In Process Explorer:

  1. Prozess öffnen.
  2. Registerkarte Threads auswählen.
  3. Threads nach CPU-Auslastung sortieren.
  4. Thread-ID und Startadresse dokumentieren.
  5. bei verfügbaren Symbolen den Stack untersuchen.
  6. geladenes Modul oder zugehörige DLL bestimmen.

Mögliche Befunde:

Befund Mögliche Bedeutung
ein Thread dauerhaft stark ausgelastet Endlosschleife oder Single-Thread-Engpass
viele Threads entstehen fortlaufend Thread-Leak oder fehlerhafte Parallelisierung
Thread wartet lange Datei, Netzwerk, Lock oder externe Komponente
Startadresse gehört zu Drittanbieter-DLL Anwendung oder Erweiterung untersuchen
Startadresse gehört zu Sicherheitssoftware Scan oder Filtertreiber als mögliche Beteiligung prüfen
Prozess hat ungewöhnlich viele Threads Worker-Konfiguration, Deadlock oder fehlerhafte Anwendung

Das Beenden eines einzelnen Threads kann den Prozess beschädigen und ist keine sichere Standardmaßnahme.

15. Nicht reagierende Anwendungen und Wait Chains

Eine Anwendung kann als „Keine Rückmeldung“ erscheinen, wenn ihr Oberflächenthread nicht rechtzeitig auf Windows-Nachrichten reagiert.

Mögliche Ursachen:

Im Ressourcenmonitor kann über die CPU-Ansicht bei einem Prozess die Warteschlange beziehungsweise Wait Chain analysiert werden.

Ein möglicher Deadlock liegt vor, wenn mehrere Threads oder Prozesse gegenseitig auf Ressourcen warten. Die Wait-Chain-Analyse liefert einen Hinweis, aber nicht immer einen vollständigen Ursachennachweis.

Vor dem Beenden eines wartenden Prozesses sollten Dump, Ereignisse und Anwendungslogs gesichert werden.

16. Geöffnete Dateien und Handles untersuchen

Eine Datei kann nicht gelöscht oder umbenannt werden, wenn ein Prozess ein passendes Handle geöffnet hält.

Process Explorer:

  1. Find → Find Handle or DLL öffnen.
  2. Teil des Datei- oder Verzeichnisnamens eingeben.
  3. gefundenen Prozess und Handle-Typ prüfen.
  4. Anwendung möglichst regulär schließen.
  5. erst danach einen kontrollierten Prozess- oder Dienstneustart erwägen.

Handle als Kommandozeilenwerkzeug:

handle.exe "<Dateiname-oder-Pfad>"

Nach PID filtern:

handle.exe -p <PID>

Das direkte Schließen eines Handles kann:

Ein Handle sollte deshalb nicht als erste Maßnahme erzwungen geschlossen werden.

17. Geladene DLLs untersuchen

Process Explorer kann im unteren Fensterbereich Handles oder geladene DLLs anzeigen.

Umschalten:

View → Lower Pane View → DLLs

Zu prüfen sind:

ListDLLs:

listdlls.exe <Prozessname>

Nach einer bestimmten DLL suchen:

listdlls.exe -d <DLL-Name>

Eine unbekannte oder nicht signierte DLL ist nicht automatisch Schadsoftware. Sie muss anhand von Pfad, Hersteller, Signatur, Hash, Installationszusammenhang und Sicherheitsprüfung bewertet werden.

18. Process Monitor verwenden

Process Monitor zeichnet in Echtzeit unter anderem folgende Ereignisse auf:

Da sehr viele Ereignisse entstehen können, muss die Aufzeichnung gefiltert und zeitlich begrenzt werden.

Empfohlener Ablauf:

  1. Process Monitor starten.
  2. Aufzeichnung zunächst anhalten.
  3. vorhandene Ereignisse leeren.
  4. Filter für den betroffenen Prozess setzen.
  5. nur benötigte Ereignisklassen aktivieren.
  6. Aufzeichnung starten.
  7. Fehler genau einmal reproduzieren.
  8. Aufzeichnung sofort anhalten.
  9. Ereignisse rund um den Fehlerzeitpunkt untersuchen.
  10. Aufzeichnung geschützt speichern oder nach Abschluss löschen.

Beispielhafte Filter:

Process Name is <Anwendung.exe> then Include

oder:

PID is <PID> then Include

Zusätzliche Filter können beispielsweise betreffen:

Result is ACCESS DENIED
Result is NAME NOT FOUND
Result is PATH NOT FOUND
Operation is CreateFile
Operation is RegOpenKey

19. Process-Monitor-Ergebnisse bewerten

Häufige Ergebnisse:

Ergebnis Bedeutung
SUCCESS Operation wurde erfolgreich ausgeführt
NAME NOT FOUND Objekt mit diesem Namen wurde nicht gefunden
PATH NOT FOUND Teil des Pfades wurde nicht gefunden
ACCESS DENIED Zugriff wurde durch Berechtigung oder Sicherheitsmechanismus verweigert
SHARING VIOLATION Objekt wird in nicht kompatibler Weise verwendet
BUFFER OVERFLOW häufig normaler Teil einer Größenabfrage
NO MORE FILES Verzeichnisaufzählung ist beendet
REPARSE Pfad wurde über einen Reparse Point weitergeleitet

Nicht jeder rote oder fehlgeschlagene Eintrag ist ein Fehler. Anwendungen prüfen häufig mehrere mögliche Pfade, Registry-Schlüssel oder Dateinamen, bevor sie den tatsächlich vorhandenen Eintrag verwenden.

Ein relevanter Befund entsteht erst, wenn:

20. „Zugriff verweigert“ untersuchen

Mögliche Ursachen:

Aktuelle Identität:

whoami

Gruppen und Sicherheitskennungen:

whoami /groups

Privilegien:

whoami /priv

Effektive NTFS-Berechtigungen sollten mit den Windows-Sicherheitseinstellungen oder einem kontrollierten Werkzeug geprüft werden.

AccessChk-Beispiel:

accesschk.exe -nobanner -v "<Benutzer>" "<Pfad>"

Die genaue Syntax ist vor dem produktiven Einsatz anhand der aktuellen Microsoft-Dokumentation zu prüfen.

Die dauerhafte Ausführung einer Anwendung als Administrator ist keine fachgerechte Standardlösung. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.

21. Netzwerkverbindungen einem Prozess zuordnen

PowerShell:

Get-NetTCPConnection |
    Sort-Object State, RemoteAddress |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Verbindungen eines bestimmten Prozesses:

Get-NetTCPConnection |
    Where-Object OwningProcess -eq <PID>

Prozess zuordnen:

Get-Process -Id <PID>

TCPView zeigt:

Zu prüfen sind:

Eine unbekannte Verbindung ist nicht automatisch bösartig. DNS, CDN, Update-, Telemetrie-, Lizenz- und Cloud-Dienste können externe Ziele verwenden. Der Zusammenhang muss geprüft werden.

22. Listener und Portkonflikte untersuchen

Lauschende TCP-Ports:

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress,
                  LocalPort,
                  OwningProcess

Prozess zu einem Port suchen:

Get-NetTCPConnection -LocalPort <Port> |
    Select-Object LocalAddress,
                  LocalPort,
                  State,
                  OwningProcess

Mit klassischem Windows-Befehl:

netstat -ano

Mögliche Befunde:

Befund Mögliche Bedeutung
erwarteter Port fehlt Dienst läuft nicht oder bindet nicht
Port nur an 127.0.0.1 gebunden nur lokaler Zugriff möglich
Port an unerwartete Adresse gebunden Konfiguration prüfen
andere PID verwendet den Port Portkonflikt
viele Verbindungen in SYN_SENT Ziel oder Netzwerk antwortet nicht
viele Verbindungen in TIME_WAIT hohe Verbindungsrate oder fehlendes Connection-Reuse
viele Verbindungen in CLOSE_WAIT Anwendung schließt empfangene Verbindungen nicht korrekt
Listener vorhanden, Zugriff scheitert Firewall, TLS, Anwendung oder Rückweg prüfen

23. Autostarts mit Autoruns untersuchen

Autoruns zeigt deutlich mehr Autostartorte als der Task-Manager.

Zu den möglichen Kategorien gehören:

Empfohlene Vorgehensweise:

  1. Autoruns als Administrator starten.
  2. vollständige Erfassung abwarten.
  3. Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen.
  4. nach nicht vorhandenen Dateien suchen.
  5. Publisher und Signatur prüfen.
  6. Eintrag, Pfad und Kategorie dokumentieren.
  7. verdächtigen Eintrag zunächst deaktivieren statt löschen.
  8. Neustart- oder Anmeldetest kontrolliert durchführen.
  9. bei ausbleibender Wirkung Eintrag wieder aktivieren.

Ein nicht signierter Autostarteintrag ist nicht automatisch Schadsoftware. Herkunft, Pfad, Hash, Installationszeitpunkt und Sicherheitsmeldungen müssen gemeinsam bewertet werden.

24. Digitale Signaturen mit Sigcheck prüfen

Beispiel:

sigcheck.exe -nobanner -a -h "<Pfad-zur-Datei>"

Mögliche Prüfpunkte:

Eine gültige Signatur beweist, dass die Datei seit der Signierung nicht unbemerkt verändert wurde und zu welchem Zertifikat sie gehört. Sie beweist nicht automatisch, dass die Software erwünscht, fehlerfrei oder für den konkreten Einsatzzweck sicher ist.

Online-Prüfungen oder Uploads zu externen Diensten dürfen nur unter Beachtung von Datenschutz, Geheimhaltung und Unternehmensrichtlinien durchgeführt werden.

25. Abstürze und Hänger mit ProcDump erfassen

ProcDump kann Speicherabbilder unter bestimmten Bedingungen erzeugen, beispielsweise bei:

Manuelles vollständiges Speicherabbild:

procdump.exe -accepteula -ma <PID> "<Zielverzeichnis>"

Dump bei unbehandelter Ausnahme:

procdump.exe -accepteula -e -ma <Prozessname.exe> "<Zielverzeichnis>"

Dump bei nicht reagierendem Fenster:

procdump.exe -accepteula -h -ma <Prozessname.exe> "<Zielverzeichnis>"

Vor dem Einsatz muss geprüft werden:

Ein Dump ist noch keine Fehlerdiagnose. Er muss mit Symbolen und geeigneten Debugwerkzeugen analysiert werden.

26. Windows Performance Recorder und Analyzer

Für komplexe oder nur zeitweise auftretende Leistungsprobleme können Windows Performance Recorder und Windows Performance Analyzer eingesetzt werden.

WPR erfasst ETW-Ereignisse. WPA stellt die erfassten Daten als Tabellen und Diagramme dar.

Typische Analysebereiche:

Grundsätzlicher Ablauf:

  1. geeignetes WPR-Profil auswählen.
  2. Speicherplatz und Aufzeichnungsmodus prüfen.
  3. Aufzeichnung starten.
  4. Problem reproduzieren.
  5. Aufzeichnung unmittelbar danach stoppen.
  6. ETL-Datei geschützt speichern.
  7. Datei mit WPA öffnen.
  8. Zeitraum des Fehlers markieren.
  9. Prozess, Thread und Ressource korrelieren.
  10. Aufzeichnung nach Abschluss kontrolliert archivieren oder löschen.

Eine ETW-Aufzeichnung kann groß werden und das System zusätzlich belasten. Profil, Dauer und Detailgrad müssen deshalb begrenzt werden.

27. Prozesse sicher beenden oder neu starten

Ein Prozess darf erst beendet werden, wenn geklärt wurde:

Kontrolliertes Beenden ohne Erzwingen:

Stop-Process -Id <PID> -WhatIf

-WhatIf zeigt nur die geplante Aktion.

Erst nach Prüfung:

Stop-Process -Id <PID>

Erzwungenes Beenden:

Stop-Process -Id <PID> -Force

-Force erhöht das Risiko von Datenverlust oder inkonsistenten Zuständen und sollte nur bei begründetem Bedarf verwendet werden.

Bei Diensten ist ein kontrollierter Dienstneustart in der Regel besser als das direkte Beenden des zugehörigen Prozesses:

Restart-Service -Name <Dienstname> -WhatIf

Danach:

Restart-Service -Name <Dienstname>

28. Befundmatrix

Befund Bedeutung Nächster Test
Prozess beansprucht dauerhaft einen Kern einzelner Thread möglicherweise ausgelastet Threads und Stack in Process Explorer prüfen
Working Set hoch, aber stabil möglicherweise normaler Cache Private Bytes und zeitliche Entwicklung prüfen
Private Bytes wachsen dauerhaft mögliches Speicherleck Verlauf erfassen und Dump erstellen
Handle-Anzahl wächst dauerhaft mögliches Handle-Leak Handle-Typen und geöffnete Objekte prüfen
Thread-Anzahl wächst dauerhaft mögliches Thread-Leak Threaderzeugung und Anwendung untersuchen
viele ACCESS DENIED unmittelbar vor Fehler Berechtigungsproblem möglich Identität und effektive Rechte prüfen
NAME NOT FOUND, danach SUCCESS normale Suchlogik möglich erfolgreichen Zielpfad bestimmen
PATH NOT FOUND ohne erfolgreichen Ersatz fehlender Pfad oder fehlerhafte Konfiguration Anwendungskonfiguration prüfen
Datei ist gesperrt Prozess hält Handle offen Handle-Suche durchführen
Dienst beendet sich wiederholt Anwendung, Abhängigkeit oder Dienstkonto Ereignisse und Anwendungslog prüfen
Dienst bleibt bei „Wird gestartet“ Initialisierung oder Abhängigkeit hängt Wait Chain, Netzwerk und Logs prüfen
Port wird von anderer PID verwendet Portkonflikt Prozess und Konfiguration identifizieren
viele Verbindungen in CLOSE_WAIT Anwendung schließt Verbindungen nicht Anwendung und Verbindungspool prüfen
unbekannte DLL geladen Erweiterung oder mögliche Manipulation Pfad, Signatur, Hash und Herkunft prüfen
Fehler nur nach Anmeldung Autostart oder Benutzerkonfiguration Autoruns und Benutzerprofil prüfen
Fehler nur nach Update Versions- oder Kompatibilitätsproblem Änderungsverlauf und Herstellerhinweise
Prozess stürzt ohne sichtbare Meldung ab Ausnahme oder externe Beendigung Ereignisse, WER und ProcDump
Problem nur unter Dienstkonto Berechtigung oder Benutzerumgebung Identität, Rechte und Pfade vergleichen
Anwendung funktioniert nur erhöht fehlende Berechtigung oder falscher Speicherort Process Monitor und AccessChk
mehrere Prozesse gleichzeitig auffällig gemeinsame Abhängigkeit Storage, Netzwerk, Sicherheitssoftware
nach Neustart vorübergehend behoben Zustand zurückgesetzt, Ursache unbekannt Langzeitmessung und Dump-Trigger

29. Typische Ursachen und passende Maßnahmen

Ursache: fehlerhafter oder blockierter Prozess

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende Berechtigung

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende Datei oder fehlerhafter Pfad

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafte Erweiterung oder DLL

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Autostarteintrag

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: Portkonflikt

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

Ursache: Ressourcen- oder Handle-Leak

Nachweis:

Mögliche Maßnahme:

Rollback:

Verifikation:

30. Nachkontrolle

Nach einer Maßnahme sind dieselben Kriterien erneut zu prüfen:

31. Dokumentation

Beispiel:

Symptom:
Der Dienst „Beispieldienst“ wurde nach dem Start innerhalb
weniger Sekunden wieder beendet.

Zeitpunkt:
02.08.2026, 09:42 Uhr MESZ

Nachweis:
Das Anwendungsprotokoll zeigte den Fehler zum gleichen Zeitpunkt.
Process Monitor zeigte unmittelbar davor einen relevanten Zugriff
auf C:\ProgramData\Beispiel\config.json mit ACCESS DENIED.

Ursache:
Das verwendete Dienstkonto besaß nach einer Änderung keine
Leseberechtigung mehr für die Konfigurationsdatei.

Maßnahme:
Die erforderliche Leseberechtigung wurde ausschließlich für
das vorgesehene Dienstkonto wiederhergestellt.

Rollback:
Dokumentierte Berechtigungsänderung kann entfernt werden.

Verifikation:
Dienst startet erfolgreich.
Anwendungsport ist erreichbar.
Keine neuen Fehler im Ereignisprotokoll.
Funktionstest erfolgreich.

Prävention:
Berechtigungen des Anwendungsverzeichnisses werden künftig
vor und nach Änderungen automatisiert verglichen.

32. Entscheidungsbaum

Windows-Anwendung oder Dienst funktioniert nicht
        ↓
Läuft der erwartete Prozess?
        ├── Nein
        │   ↓
        │   Dienststatus, Ereignisse, Autostart,
        │   Datei, Dienstkonto und Abhängigkeiten prüfen
        │
        └── Ja
            ↓
Reagiert der Prozess?
        ├── Nein
        │   ↓
        │   Wait Chain, Threads, Dump und Abhängigkeiten prüfen
        │
        └── Ja
            ↓
Sind Ressourcen auffällig?
        ├── Ja
        │   ↓
        │   CPU, RAM, Handles, Threads und I/O untersuchen
        │
        └── Nein
            ↓
Fehler bei Datei oder Registry?
        ├── Ja
        │   ↓
        │   Process Monitor, Pfade und Berechtigungen prüfen
        │
        └── Nein
            ↓
Netzwerk oder externer Dienst beteiligt?
        ├── Ja
        │   ↓
        │   TCPView, Port, DNS und Zielsystem prüfen
        │
        └── Nein
            ↓
Anwendungslog, Erweiterungen, DLLs und Dump untersuchen

33. Typische Prüfungsfragen

Warum ist ein Prozess mit hoher CPU-Auslastung nicht automatisch die Fehlerursache?

Antwort anzeigen

Die CPU-Auslastung kann für die ausgeführte Aufgabe normal sein oder als Folge eines anderen Problems entstehen. Zeitpunkt, Threadaktivität, Anwendungssymptom und weitere Abhängigkeiten müssen gemeinsam untersucht werden.

Worin unterscheiden sich Task-Manager und Process Explorer?

Antwort anzeigen

Der Task-Manager bietet eine grundlegende Übersicht über Prozesse, Leistung, Benutzer und Autostarts. Process Explorer zeigt zusätzlich unter anderem Prozesshierarchie, Befehlszeilen, Signaturen, Handles, DLLs, Threads, Sicherheitsinformationen und detaillierte Prozesseigenschaften.

Wofür wird Process Monitor verwendet?

Antwort anzeigen

Process Monitor zeichnet Datei-, Registry-, Prozess-, Thread- und DLL-Aktivitäten auf. Damit können beispielsweise fehlende Dateien, fehlerhafte Pfade und verweigerte Zugriffe untersucht werden.

Warum ist NAME NOT FOUND in Process Monitor nicht automatisch ein Fehler?

Antwort anzeigen

Anwendungen prüfen häufig mehrere mögliche Namen oder Pfade. Wenn anschließend ein alternativer Zugriff erfolgreich ist, kann der fehlgeschlagene Versuch zum normalen Programmablauf gehören.

Warum sollte ein blockierendes Handle nicht sofort geschlossen werden?

Antwort anzeigen

Das erzwungene Schließen kann Datenverlust, Programmabstürze oder inkonsistente Anwendungszustände verursachen. Zuerst muss die zugehörige Anwendung identifiziert und möglichst regulär beendet werden.

Warum kann ein vollständiges Speicherabbild sicherheitsrelevant sein?

Antwort anzeigen

Der Prozessspeicher kann Kennwörter, Tokens, Schlüssel, personenbezogene Daten und vertrauliche Anwendungsinhalte enthalten. Dumps müssen daher wie sensible Daten behandelt werden.

Warum darf ein Programm nicht dauerhaft nur als Administrator ausgeführt werden, um „Zugriff verweigert“ zu umgehen?

Antwort anzeigen

Dadurch erhält das Programm weitreichendere Rechte als erforderlich. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.

Wofür wird Autoruns eingesetzt?

Antwort anzeigen

Autoruns zeigt zahlreiche automatische Startpunkte von Windows, beispielsweise Anmeldeeinträge, Dienste, Treiber, geplante Aufgaben und Erweiterungen. Es hilft bei Problemen, die nach dem Start oder der Anmeldung auftreten.

Was ist der Unterschied zwischen WPR und WPA?

Antwort anzeigen

Windows Performance Recorder zeichnet ETW-Ereignisse auf. Windows Performance Analyzer öffnet und analysiert die erzeugten ETL-Dateien mithilfe von Tabellen und Diagrammen.

Warum sollte vor dem Neustart eines Prozesses ein Dump erstellt werden?

Antwort anzeigen

Der Neustart beseitigt den aktuellen Prozesszustand. Ein Dump kann Informationen über Threads, Aufrufstapel, Speicher und Sperren erhalten, die für die Ursachenanalyse benötigt werden.

34. Prüfungsfallen

35. Checkliste

36. Schnellreferenz

Beobachtung Nächstes Werkzeug
Prozess verbraucht viel CPU Process Explorer, Leistungsüberwachung
nur ein Kern ausgelastet Process Explorer → Threads
Arbeitsspeicher wächst PowerShell, Process Explorer, ProcDump
Handles wachsen Process Explorer, Handle
Datei ist gesperrt Process Explorer oder Handle
DLL-Konflikt vermutet Process Explorer oder ListDLLs
Zugriff verweigert Process Monitor, AccessChk
Datei oder Pfad fehlt Process Monitor
Dienst startet nicht Ereignisanzeige, sc.exe, PowerShell
Dienst hängt beim Start Ereignisanzeige, Wait Chain, ProcDump
Prozess reagiert nicht Ressourcenmonitor, Process Explorer, ProcDump
Anwendung stürzt ab Ereignisanzeige, WER, ProcDump
unbekannte Netzwerkverbindung TCPView
erwarteter Port fehlt Get-NetTCPConnection, TCPView
Port ist bereits belegt Get-NetTCPConnection, netstat -ano
Fehler nach Anmeldung Autoruns
langsamer Systemstart Autoruns, WPR und WPA
unbekannte Datei Sigcheck
zeitweises Leistungsproblem WPR und WPA
Problem nur unter Dienstkonto whoami, AccessChk, Process Monitor
Anwendung funktioniert nur erhöht Process Monitor und Berechtigungsprüfung

Merksatz

Windows-Prozesse und Dienste werden nicht allein anhand ihres Namens oder eines einzelnen Messwerts bewertet. Entscheidend sind Prozesshierarchie, Benutzerkonto, Threads, Speicher, Handles, Dateien, Registry-Zugriffe, Netzwerkverbindungen, Ereignisse und externe Abhängigkeiten. Vor dem Beenden oder Neustarten wird der flüchtige Zustand gesichert. Anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut geprüft.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

8.2 Active Directory, Gruppenrichtlinien und Kerberos analysieren

Active Directory Domain Services bilden in vielen Windows-Netzwerken die Grundlage für:

Eine scheinbar einfache Meldung wie „Anmeldung nicht möglich“, „Zugriff verweigert“ oder „Gruppenrichtlinie wird nicht angewendet“ kann deshalb unterschiedliche Ursachen haben:

Die Komponenten müssen gemeinsam und in einer festen Reihenfolge untersucht werden.

1. Lernziele

Nach dieser Seite kannst du:

2. Vereinfachte Abhängigkeitskette

Benutzer oder Computer
        ↓
IP-Konnektivität
        ↓
DNS-Auflösung und SRV-Einträge
        ↓
Erreichbarer Domänencontroller
        ↓
Zeitsynchronisation
        ↓
Secure Channel und Computerkonto
        ↓
Kerberos oder NTLM
        ↓
Active-Directory-Replikation
        ↓
Gruppenmitgliedschaften und Berechtigungen
        ↓
Gruppenrichtlinien und Anwendungszugriff

Ein Fehler weiter oben kann zahlreiche Folgefehler auslösen.

Beispiele:

3. Sicherheits- und Betriebsregeln

Vor Änderungen müssen mindestens folgende Informationen gesichert werden:

Nicht als erste Maßnahme durchführen:

Solche Maßnahmen verändern oder vernichten den Zustand, der für die Ursachenanalyse benötigt wird.

4. Fehlerbild exakt erfassen

Wichtige Fragen:

Ein Client, ein Benutzer und eine konkrete Zielressource sollten als kontrollierter Testfall verwendet werden.

5. Grundinformationen auf dem Client erfassen

Identität:

whoami

Benutzer-Domäne:

echo %USERDOMAIN%

Anmeldeserver:

echo %LOGONSERVER%

Vollständige Benutzerinformationen:

whoami /all

Computername:

hostname

Domänenzugehörigkeit:

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name,
                  Domain,
                  PartOfDomain,
                  UserName

IP-Konfiguration:

ipconfig /all

Dabei sind besonders zu prüfen:

Domänenmitglieder sollten grundsätzlich die für die AD-Domäne zuständigen internen DNS-Server verwenden. Ein öffentlicher DNS-Server kennt die internen AD-SRV-Einträge normalerweise nicht.

6. Verwendeten Domänencontroller bestimmen

Anmeldeserver:

echo %LOGONSERVER%

Domänencontroller für die Domäne suchen:

nltest /dsgetdc:<Domänenname>

Beispiel:

nltest /dsgetdc:ad.example.local

Domänencontroller auflisten:

nltest /dclist:<Domänenname>

Aktuellen DC über PowerShell bestimmen:

Get-ADDomainController -Discover

Alle bekannten Domänencontroller:

Get-ADDomainController -Filter * |
    Select-Object HostName,
                  Site,
                  IPv4Address,
                  IsGlobalCatalog,
                  OperationMasterRoles

Die PowerShell-Befehle des Active-Directory-Moduls erfordern die entsprechenden RSAT-Komponenten oder die Ausführung auf einem geeigneten Verwaltungsserver.

Zu dokumentieren sind:

7. DNS als erste technische Abhängigkeit prüfen

Hostauflösung:

nslookup <Domänencontroller>

Vollqualifizierten Namen prüfen:

nslookup <DC-Name>.<DNS-Domäne>

Domänencontroller über LDAP-SRV-Einträge suchen:

nslookup -type=SRV _ldap._tcp.dc._msdcs.<DNS-Domäne>

Kerberos-Dienste suchen:

nslookup -type=SRV _kerberos._tcp.<DNS-Domäne>

Global Catalog suchen:

nslookup -type=SRV _gc._tcp.<DNS-Gesamtstruktur>

Standortspezifische Domänencontroller:

nslookup -type=SRV _ldap._tcp.<Standort>._sites.dc._msdcs.<DNS-Domäne>

PowerShell:

Resolve-DnsName -Type SRV `
    _ldap._tcp.dc._msdcs.<DNS-Domäne>

Zu prüfen sind:

Ein erfolgreicher Ping auf eine IP-Adresse beweist keine funktionierende AD-DNS-Struktur.

8. Erreichbarkeit benötigter Dienste prüfen

Grundlegende Verbindung:

Test-NetConnection <Domänencontroller>

DNS:

Test-NetConnection <Domänencontroller> -Port 53

Kerberos:

Test-NetConnection <Domänencontroller> -Port 88

LDAP:

Test-NetConnection <Domänencontroller> -Port 389

SMB für SYSVOL und NETLOGON:

Test-NetConnection <Domänencontroller> -Port 445

RPC Endpoint Mapper:

Test-NetConnection <Domänencontroller> -Port 135

Global Catalog:

Test-NetConnection <Domänencontroller> -Port 3268

LDAPS, sofern verwendet:

Test-NetConnection <Domänencontroller> -Port 636

Global Catalog über TLS, sofern verwendet:

Test-NetConnection <Domänencontroller> -Port 3269

Wichtige Dienste und Ports können unter anderem sein:

Funktion Typischer Port
DNS TCP/UDP 53
Kerberos TCP/UDP 88
RPC Endpoint Mapper TCP 135
LDAP TCP/UDP 389
SMB TCP 445
Kerberos-Kennwortänderung TCP/UDP 464
LDAPS TCP 636
Global Catalog TCP 3268
Global Catalog über TLS TCP 3269
dynamisches RPC konfigurationsabhängiger TCP-Portbereich

Ein erfolgreich getesteter TCP-Port beweist nur, dass eine Verbindung zu diesem Port hergestellt werden konnte. Er beweist nicht, dass Authentifizierung, LDAP-Abfrage, Replikation oder Gruppenrichtlinienverarbeitung funktionieren.

9. SYSVOL und NETLOGON prüfen

Freigaben des Domänencontrollers:

net view \\<Domänencontroller>

SYSVOL öffnen:

dir \\<Domänencontroller>\SYSVOL

NETLOGON öffnen:

dir \\<Domänencontroller>\NETLOGON

Direkter Domänenpfad:

dir \\<DNS-Domäne>\SYSVOL

Zu prüfen sind:

Eine GPO besteht aus zwei zusammengehörigen Teilen:

Bestandteil Speicherort
Group Policy Container Active Directory
Group Policy Template SYSVOL

Sind die beiden Teile oder ihre Versionsstände nicht konsistent, kann die Gruppenrichtlinienverarbeitung fehlschlagen.

10. Zeitsynchronisation prüfen

Aktueller Status:

w32tm /query /status

Zeitquelle:

w32tm /query /source

Konfiguration:

w32tm /query /configuration

Domänenhierarchie überwachen:

w32tm /monitor

Vergleich mit einem bestimmten Domänencontroller:

w32tm /stripchart /computer:<Domänencontroller> /samples:10 /dataonly

Windows-Zeitdienst:

Get-Service W32Time

Zu prüfen sind:

Kerberos reagiert empfindlich auf Zeitabweichungen. Der konkrete Fehler muss jedoch anhand von Ereignissen, Ticketstatus und Zeitmessung nachgewiesen werden.

Eine manuelle Änderung der Uhrzeit beseitigt nicht automatisch die Ursache einer falschen Zeitquelle.

11. Secure Channel des Computers prüfen

Der Secure Channel ist die geschützte Beziehung zwischen einem Domänenmitglied und der Domäne.

Prüfung mit PowerShell:

Test-ComputerSecureChannel -Verbose

Prüfung mit NLTEST:

nltest /sc_verify:<DNS-Domäne>

Verwendeten sicheren Kanal anzeigen:

nltest /sc_query:<DNS-Domäne>

Mögliche Symptome eines gestörten Secure Channels:

Mögliche Ursachen:

Eine Reparatur des Secure Channels ist eine Änderung und darf erst nach Sicherung der Diagnoseergebnisse erfolgen.

Mögliche kontrollierte Reparatur auf einem Domänenmitglied:

Test-ComputerSecureChannel -Repair `
    -Credential <Domäne>\<Administratorkonto>

Vorher müssen geprüft werden:

Test-ComputerSecureChannel ist vor allem für Domänenmitglieder vorgesehen. Bei Domänencontrollern müssen DC-spezifische Diagnose- und Reparaturverfahren verwendet werden.

12. Benutzer- und Computerkonto prüfen

Benutzerkonto:

Get-ADUser -Identity <Benutzername> -Properties * |
    Select-Object SamAccountName,
                  UserPrincipalName,
                  Enabled,
                  LockedOut,
                  PasswordExpired,
                  PasswordLastSet,
                  LastBadPasswordAttempt,
                  BadLogonCount,
                  AccountExpirationDate

Computerkonto:

Get-ADComputer -Identity <Computername> -Properties * |
    Select-Object Name,
                  Enabled,
                  DNSHostName,
                  PasswordLastSet,
                  LastLogonDate,
                  DistinguishedName

Gruppenmitgliedschaften:

Get-ADPrincipalGroupMembership <Benutzername> |
    Select-Object Name,
                  GroupScope,
                  GroupCategory

Aktuelles Benutzer-Token:

whoami /groups

Zu unterscheiden sind:

Eine neu hinzugefügte Gruppenmitgliedschaft ist nicht automatisch im bereits bestehenden Benutzer-Token enthalten. Ab- und erneute Anmeldung kann erforderlich sein. Bei bestimmten Dienstkonten kann ein Dienstneustart notwendig sein.

13. Kontosperrung untersuchen

Zu prüfen sind:

Benutzerstatus:

Get-ADUser <Benutzername> `
    -Properties LockedOut,
                LastBadPasswordAttempt,
                BadLogonCount,
                PasswordLastSet

Gesperrte Konten suchen:

Search-ADAccount -LockedOut -UsersOnly

Relevante Sicherheitsereignisse können unter anderem betreffen:

Ein Konto lediglich wiederholt zu entsperren beseitigt die Quelle der falschen Anmeldedaten nicht.

14. Domänencontroller grundsätzlich prüfen

Ausführliche Diagnose:

dcdiag /v

Ausgabe in Datei:

dcdiag /v /c /d /e > C:\Temp\dcdiag.txt

DNS-Test:

dcdiag /test:dns /v

Replikationstest:

dcdiag /test:replications /v

SYSVOL-Test:

dcdiag /test:sysvolcheck /v

Werbungsstatus des Domänencontrollers:

dcdiag /test:advertising /v

NETLOGON-Freigabe:

Zu prüfen sind:

Nicht jede Warnung in einer umfangreichen dcdiag-Ausgabe erklärt das untersuchte Symptom. Der Befund muss zeitlich und technisch zum Fehler passen.

15. AD-Replikation prüfen

Gesamtübersicht:

repadmin /replsummary

Eingehende Replikation eines DCs:

repadmin /showrepl <Domänencontroller>

Gesamtstrukturweite Anzeige:

repadmin /showrepl * /csv

PowerShell-Auswertung:

repadmin /showrepl * /csv |
    ConvertFrom-Csv |
    Out-GridView

Replikationsfehler über PowerShell:

Get-ADReplicationFailure `
    -Target * `
    -Scope Forest

Status der Replikationspartner:

Get-ADReplicationPartnerMetadata `
    -Target * `
    -Scope Forest |
    Select-Object Server,
                  Partner,
                  Partition,
                  LastReplicationAttempt,
                  LastReplicationSuccess,
                  LastReplicationResult

Replikationswarteschlange:

repadmin /queue

Zu dokumentieren sind:

16. Replikationsfehler richtig bewerten

AD-Replikation hängt unter anderem ab von:

Befund Mögliche Ursache
Fehler 1722 RPC-Server nicht verfügbar, DNS, Firewall oder Dienstproblem
Fehler 5 Zugriff verweigert, Authentifizierung oder Berechtigung
Zielprinzipalname ist falsch Kerberos-, SPN- oder Computerkonto-Problem
letzter Erfolg lange her dauerhafte oder standortbezogene Störung
nur eine Partition betroffen partitions- oder DNS-bezogenes Problem
nur ein Partner betroffen Verbindung, DNS oder Zustand dieses Partners
Änderungen fehlen nur auf einem DC eingehende Replikation dieses DCs prüfen
verschiedene Kennwörter funktionieren je nach DC Kennwortreplikation oder allgemeine Replikation prüfen
GPO fehlt nur auf einem DC AD- und SYSVOL-Replikation gemeinsam prüfen

Eine erzwungene Synchronisation ist keine erste Diagnosemaßnahme. Sie kann zusätzliche Last erzeugen und verdeckt möglicherweise die Richtung oder den ursprünglichen Zustand des Fehlers.

17. FSMO-Rollen prüfen

netdom query fsmo

PowerShell:

Get-ADForest |
    Select-Object SchemaMaster,
                  DomainNamingMaster

Get-ADDomain |
    Select-Object PDCEmulator,
                  RIDMaster,
                  InfrastructureMaster

Die Rollen sind:

Rolle Ebene Wichtige Funktion
Schema-Master Gesamtstruktur Schemaänderungen
Domänennamen-Master Gesamtstruktur Domänen und Partitionen
RID-Master Domäne RID-Pools für Sicherheitskennungen
PDC-Emulator Domäne Zeit, Kennwortpriorität und weitere Funktionen
Infrastruktur-Master Domäne domänenübergreifende Objektbezüge

Der Ausfall eines FSMO-Rolleninhabers erklärt nicht automatisch jede Anmeldestörung. Die betroffene Funktion und die Ausfalldauer müssen berücksichtigt werden.

18. Gruppenrichtlinien-Grundlagen

Die normale Verarbeitungsreihenfolge lautet:

Lokal → Site → Domäne → OU → untergeordnete OU

Diese Reihenfolge wird häufig mit LSDOU bezeichnet.

Grundsätzlich gilt:

Mögliche Ursachen für eine nicht angewendete GPO:

19. Gruppenrichtlinienergebnis erfassen

Kurzübersicht:

gpresult /r

Computerrichtlinien mit erhöhten Rechten:

gpresult /scope computer /r

Benutzerrichtlinien:

gpresult /scope user /r

Ausführlicher HTML-Bericht:

gpresult /h C:\Temp\gpresult.html

Bericht für einen bestimmten Benutzer:

gpresult /user <Domäne>\<Benutzer> /h C:\Temp\gpresult-benutzer.html

Ausführliche Textausgabe:

gpresult /z

Resultant Set of Policy:

rsop.msc

Im Bericht sind besonders zu prüfen:

gpresult muss im passenden Benutzer- und Berechtigungskontext ausgeführt werden. Ein Bericht aus einem anderen Konto kann ein anderes Ergebnis zeigen.

20. Gruppenrichtlinien kontrolliert aktualisieren

Standardaktualisierung:

gpupdate

Erneute Verarbeitung aller Einstellungen:

gpupdate /force

Nur Computerrichtlinien:

gpupdate /target:computer /force

Nur Benutzerrichtlinien:

gpupdate /target:user /force

Eine erzwungene Aktualisierung kann:

gpupdate /force ist ein Test beziehungsweise Auslöser, aber noch keine Ursachenanalyse. Danach müssen Ergebnisbericht und Ereignisprotokolle geprüft werden.

21. Gruppenrichtlinien-Ereignisse prüfen

Wichtiger Protokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ GroupPolicy
→ Operational

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-GroupPolicy/Operational'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich prüfen:

Nicht nur die Event-ID verwenden. Provider, vollständiger Text, Zeitpunkt, Benutzer, Computer und Verarbeitungsschritt müssen gemeinsam bewertet werden.

22. GPO-Verknüpfung und Filterung prüfen

In der Gruppenrichtlinienverwaltung sind zu kontrollieren:

Sicherheitsfilterung benötigt grundsätzlich die passenden Berechtigungen zum Lesen und Anwenden der Gruppenrichtlinie.

Typische Fehlinterpretation:

Ein Benutzer ist Mitglied einer Gruppe, die „Gruppenrichtlinie übernehmen“ besitzt. Im aktuellen Anmeldetoken fehlt diese neue Gruppenmitgliedschaft jedoch noch.

Deshalb müssen AD-Mitgliedschaft und aktuelles Token getrennt geprüft werden.

23. Loopbackverarbeitung verstehen

Loopbackverarbeitung wird für Computer verwendet, bei denen die Benutzerumgebung vom verwendeten Computer abhängen soll, beispielsweise:

Modi:

Modus Wirkung
Zusammenführen Benutzerrichtlinien des Benutzerobjekts werden verarbeitet, danach kommen die für den Computer ermittelten Benutzerrichtlinien hinzu
Ersetzen Benutzerrichtlinien des Benutzerobjekts werden durch die für den Computer ermittelten Benutzerrichtlinien ersetzt

Wenn Benutzereinstellungen nur auf bestimmten Computern unerwartet sind, muss Loopback geprüft werden.

24. Kerberos-Grundprinzip

Vereinfacht:

Benutzeranmeldung
        ↓
Authentication Service Request
        ↓
Ticket Granting Ticket
        ↓
Ticket Granting Service Request
        ↓
Dienstticket für einen SPN
        ↓
Zugriff auf den Zieldienst

Wichtige Begriffe:

Begriff Bedeutung
KDC Key Distribution Center auf einem Domänencontroller
TGT Ticket Granting Ticket
Dienstticket Ticket für einen konkreten Dienst
SPN eindeutiger Dienstbezeichner eines Kontos
Realm Kerberos-Sicherheitsbereich, in AD meist zur Domäne zugeordnet
PAC enthält unter anderem Autorisierungsinformationen
Delegierung Weitergabe von Anmeldeinformationen unter definierten Bedingungen

Kerberos benötigt insbesondere:

25. Kerberos-Tickets prüfen

Tickets des aktuellen Anmeldekontexts:

klist

TGT anzeigen:

klist tgt

Zwischengespeicherte Tickets auflisten:

klist tickets

KDCs anzeigen:

klist query_bind

Zu prüfen sind:

Das Löschen des Ticketcaches verändert den Diagnosezustand:

klist purge

klist purge sollte erst eingesetzt werden, wenn:

Nach dem Löschen kann ein erneuter Zugriff auf die Zielressource ein neues Ticket auslösen.

26. Service Principal Names prüfen

SPNs eines Kontos anzeigen:

setspn -L <Kontoname>

Bestimmten SPN suchen:

setspn -Q <Dienst>/<Hostname>

Beispiel:

setspn -Q HTTP\webserver.ad.example.local

Doppelte SPNs domänen- beziehungsweise gesamtstrukturweit suchen:

setspn -X

Mögliche SPN-Probleme:

SPNs dürfen nicht ohne vorherige Suche, Dokumentation und Prüfung verändert werden. Ein falsches Entfernen kann andere Dienste oder Benutzer beeinträchtigen.

27. Kerberos und NTLM unterscheiden

Anmeldesitzungen:

klist sessions

Tickets:

klist

Für bestimmte Verbindungen können zusätzlich Ereignisprotokolle, Dienstprotokolle oder geeignete Netzwerkaufzeichnungen erforderlich sein.

Mögliche Hinweise auf NTLM statt Kerberos:

Ein funktionierender Zugriff beweist deshalb nicht automatisch, dass Kerberos verwendet wurde.

28. Zugriff über IP-Adresse und Hostname vergleichen

Beispiel:

\\192.0.2.10\Freigabe
\\server01\Freigabe
\\server01.ad.example.local\Freigabe

Unterschiedliche Ergebnisse können auf Folgendes hinweisen:

Der Zugriff per IP-Adresse ist kein allgemeiner Ersatz für korrekte Namensauflösung. Bei Kerberos ist der verwendete Zielname für die SPN-Zuordnung entscheidend.

29. Kerberos-Ereignisse untersuchen

Relevante Protokolle können sein:

PowerShell-Beispiel für aktuelle Sicherheitsereignisse:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object {
        $_.Id -in 4768, 4769, 4771, 4776
    } |
    Select-Object TimeCreated,
                  Id,
                  Message

Typische Ereigniskategorien:

Kategorie Mögliche Bedeutung
TGT wurde angefordert Benutzer- oder Computerauthentifizierung
Dienstticket wurde angefordert Zugriff auf einen bestimmten SPN
Kerberos-Vorauthentifizierung fehlgeschlagen Kennwort, Zeit, Kontostatus oder anderer Authentifizierungsfehler
Anmeldeinformationen wurden validiert häufig NTLM-bezogene Prüfung
Kontosperrung wiederholte fehlerhafte Authentifizierung

Event-IDs müssen mit dem vollständigen Ereignistext und dem jeweiligen System ausgewertet werden.

30. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Domäne kann nicht gefunden werden DNS oder DC-Erreichbarkeit ipconfig /all, SRV-Abfrage, nltest /dsgetdc
Anmeldung funktioniert offline, aber nicht im Firmennetz DC-, DNS-, Zeit- oder Secure-Channel-Problem DC-Suche, Zeit und Secure Channel
Vertrauensstellung fehlgeschlagen Computerkennwort oder Computerkonto inkonsistent Test-ComputerSecureChannel, Replikation
neues Kennwort funktioniert nur manchmal unterschiedliche DC-Daten verwendeten DC und Replikation prüfen
Benutzer bleibt trotz Entsperrung gesperrt gespeicherte alte Anmeldedaten Sperrquelle und Sicherheitsereignisse
GPO wird nicht angezeigt falsche OU, Filterung oder Link gpresult, GPMC
GPO wird angezeigt, Einstellung fehlt Überschreibung oder Erweiterungsfehler Detailbericht und GroupPolicy-Protokoll
Computerrichtlinie fehlt Computerobjekt, Neustart oder Computerbereich gpresult /scope computer
Benutzerrichtlinie fehlt Benutzerobjekt, Token oder Benutzerbereich gpresult /scope user
GPO funktioniert nur an einem Standort nicht Site, DC, Replikation oder Netzwerk DC-Zuordnung und Replikation
SYSVOL nicht erreichbar DNS, SMB, DC oder DFSR Port 445, Freigabe und DC-Protokolle
Kerberos-Ticket fehlt SPN, DNS, KDC oder Anwendung klist, setspn -Q
Kerberos scheitert nur über Alias fehlender SPN für Alias verwendeten Namen und SPN prüfen
Zugriff funktioniert per IP, nicht per Name DNS, SPN oder Zertifikat Namen einzeln prüfen
Zugriff funktioniert per Name, nicht per IP Kerberos- oder Anwendungsanforderung Ticket und Zielkonfiguration
Dienst funktioniert nur mit NTLM SPN oder Delegierung Dienstkonto und SPNs
Replikation meldet RPC-Fehler DNS, Firewall, RPC oder Partner offline Namensauflösung und Ports
Benutzer hat neue Gruppe, aber keinen Zugriff altes Anmeldetoken whoami /groups, erneute Anmeldung
Fehler nur auf einem Client lokaler DNS-, Cache-, Konto- oder Profilfehler Vergleichsclient und lokale Konfiguration
Fehler auf vielen Clients zentrale AD-, DNS-, GPO- oder Netzwerkstörung DCs, Replikation und Änderungen
Fehler nach VM-Snapshot Secure Channel oder Zeit zurückgesetzt Zeit, Computerkonto und Secure Channel

31. Vorgehensweise bei einer nicht angewendeten GPO

  1. Betroffenen Benutzer und Computer bestimmen.
  2. Prüfen, ob Benutzer- und Computerobjekt in den erwarteten OUs liegen.
  3. Verwendeten Domänencontroller dokumentieren.
  4. DNS- und DC-Erreichbarkeit prüfen.
  5. SYSVOL-Zugriff prüfen.
  6. gpresult als HTML-Bericht erstellen.
  7. angewendete und abgelehnte GPOs prüfen.
  8. Sicherheitsfilterung und WMI-Filter prüfen.
  9. Verknüpfung, Reihenfolge und Vererbung prüfen.
  10. Loopbackverarbeitung berücksichtigen.
  11. GroupPolicy-Operational-Protokoll auswerten.
  12. AD- und SYSVOL-Replikation prüfen.
  13. genau eine kontrollierte Korrektur durchführen.
  14. Richtlinien erneut verarbeiten.
  15. Ergebnisbericht und Benutzerfunktion erneut prüfen.

32. Vorgehensweise bei einer fehlgeschlagenen Anmeldung

  1. Exakte Meldung und Zeitpunkt erfassen.
  2. Lokale und Domänenanmeldung unterscheiden.
  3. Netzwerkverbindung prüfen.
  4. DNS-Server und DNS-Suffix prüfen.
  5. Domänencontroller über SRV-Einträge suchen.
  6. verwendeten DC bestimmen.
  7. Zeit und Zeitquelle prüfen.
  8. Benutzerkonto auf Sperre, Ablauf und Deaktivierung prüfen.
  9. Secure Channel des Clients prüfen.
  10. Replikationsstatus der DCs prüfen.
  11. Sicherheits- und Kerberos-Ereignisse auswerten.
  12. gespeicherte Anmeldedaten, Dienste und Aufgaben berücksichtigen.
  13. genau eine Maßnahme durchführen.
  14. Anmeldung und Ressourcenabruf erneut testen.

33. Vorgehensweise bei Kerberos-Problemen

  1. verwendeten Zielnamen dokumentieren.
  2. DNS-Auflösung dieses Namens prüfen.
  3. Zeit von Client, Server und DC vergleichen.
  4. KDC beziehungsweise DC-Erreichbarkeit prüfen.
  5. vorhandene Tickets mit klist dokumentieren.
  6. nach passendem Dienstticket suchen.
  7. erwarteten SPN bestimmen.
  8. SPN mit setspn -Q suchen.
  9. Dienstkonto und tatsächlichen Dienstprozess vergleichen.
  10. doppelte SPNs prüfen.
  11. Sicherheits- und Kerberos-Ereignisse korrelieren.
  12. Vertrauensstellung und Delegierung berücksichtigen.
  13. Ticketcache nur kontrolliert leeren.
  14. Zugriff erneut auslösen.
  15. neues Ticket und Funktion prüfen.

34. Maßnahmen und Rückwege

Ursache: falscher DNS-Server am Client

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Secure Channel

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: GPO durch Sicherheitsfilterung ausgeschlossen

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: doppelter SPN

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: AD-Replikationsfehler

Nachweis:

Maßnahme:

Rollback:

Verifikation:

35. Nachkontrolle

Nach jeder Maßnahme sind mindestens folgende Punkte erneut zu prüfen:

36. Dokumentationsbeispiel

Symptom:
Die Laufwerkszuordnung aus der Gruppenrichtlinie wurde auf einem
Client nicht erstellt.

Zeitpunkt:
02.08.2026, 10:18 Uhr MESZ

Betroffener Benutzer:
max.mustermann

Betroffener Computer:
CLIENT-17

Verwendeter Domänencontroller:
DC02.ad.example.local

Nachweis:
DNS-Auflösung, Zeit und SYSVOL-Zugriff waren erfolgreich.
Der gpresult-Bericht zeigte die GPO als abgelehnt.
Als Ablehnungsgrund wurde die Sicherheitsfilterung angegeben.
Die erforderliche Benutzergruppe war im Active Directory eingetragen,
fehlte aber im aktuellen Anmeldetoken.

Ursache:
Die Gruppenmitgliedschaft wurde erst nach Beginn der bestehenden
Benutzersitzung hinzugefügt.

Maßnahme:
Der Benutzer meldete sich kontrolliert ab und erneut an.
An der GPO und ihren Berechtigungen wurde nichts verändert.

Rollback:
Nicht erforderlich, da keine Konfiguration geändert wurde.

Verifikation:
whoami /groups zeigt die vorgesehene Gruppe.
gpresult zeigt die angewendete GPO.
Das Laufwerk wurde verbunden.
Keine neuen Fehler im GroupPolicy-Protokoll.

Prävention:
Bei Änderungen an Gruppenmitgliedschaften wird künftig berücksichtigt,
dass bestehende Anmeldetoken nicht automatisch vollständig erneuert werden.

37. Entscheidungsbaum

Domänenanmeldung, GPO oder Ressourcenzugriff gestört
        ↓
Stimmen IP-Konfiguration und interne DNS-Server?
        ├── Nein
        │   ↓
        │   Netzwerk- und DNS-Konfiguration korrigieren
        │
        └── Ja
            ↓
Werden AD-SRV-Einträge und DCs gefunden?
        ├── Nein
        │   ↓
        │   DNS-Zone, SRV-Einträge und DC-Dienste prüfen
        │
        └── Ja
            ↓
Sind DC und benötigte Ports erreichbar?
        ├── Nein
        │   ↓
        │   Routing, Firewall, Standort und Dienste prüfen
        │
        └── Ja
            ↓
Stimmen Zeit und Secure Channel?
        ├── Nein
        │   ↓
        │   Zeitquelle oder Vertrauensbeziehung untersuchen
        │
        └── Ja
            ↓
Ist die AD-Replikation fehlerfrei?
        ├── Nein
        │   ↓
        │   Replikationsfehler nach Code und Richtung analysieren
        │
        └── Ja
            ↓
Betrifft der Fehler Gruppenrichtlinien?
        ├── Ja
        │   ↓
        │   gpresult, SYSVOL, Filter, OU und Ereignisse prüfen
        │
        └── Nein
            ↓
Betrifft der Fehler Kerberos oder einen Dienst?
        ├── Ja
        │   ↓
        │   Tickets, SPNs, Zielname und Dienstkonto prüfen
        │
        └── Nein
            ↓
Konto, Gruppen, Berechtigungen und Anwendung untersuchen

38. Typische Prüfungsfragen

Warum ist DNS für Active Directory besonders wichtig?

Antwort anzeigen

Active Directory verwendet DNS und insbesondere SRV-Einträge, damit Clients Domänencontroller, Kerberos-Dienste und Global Catalogs finden. Eine reine Auflösung externer Internetnamen reicht für eine funktionierende Domänenumgebung nicht aus.

Warum kann ein neues Kennwort an einem Client funktionieren und an einem anderen nicht?

Antwort anzeigen

Die Clients können unterschiedliche Domänencontroller verwenden. Bei einer Replikationsstörung ist das neue Kennwort möglicherweise noch nicht auf allen benötigten Domänencontrollern verfügbar.

Wozu dient gpresult?

Antwort anzeigen

gpresult zeigt die resultierenden Gruppenrichtlinien für einen Benutzer oder Computer. Es kann angewendete und abgelehnte GPOs, Sicherheitsgruppen, Filter und weitere Verarbeitungsinformationen darstellen.

Warum ist gpupdate /force noch keine Fehlerbehebung?

Antwort anzeigen

Der Befehl löst eine erneute Verarbeitung der Gruppenrichtlinien aus. Er erklärt jedoch nicht, warum eine GPO zuvor nicht angewendet wurde. Dafür müssen Ergebnisbericht, Ereignisse, Filterung, Verknüpfung und Abhängigkeiten geprüft werden.

Warum kann eine neue Gruppenmitgliedschaft trotz korrektem AD-Eintrag noch wirkungslos sein?

Antwort anzeigen

Das aktuelle Anmeldetoken wurde möglicherweise vor der Gruppenänderung erzeugt. Die neue Mitgliedschaft ist dann noch nicht im Token enthalten und wird häufig erst nach erneuter Anmeldung wirksam.

Welche drei grundlegenden Abhängigkeiten benötigt Kerberos besonders?

Antwort anzeigen

Kerberos benötigt insbesondere funktionierende DNS-Auflösung, ausreichend genaue Zeitsynchronisation und korrekte beziehungsweise eindeutige Dienstidentitäten in Form von SPNs.

Was ist ein SPN?

Antwort anzeigen

Ein Service Principal Name identifiziert eine konkrete Dienstinstanz und ist einem Active-Directory-Konto zugeordnet. Der KDC verwendet ihn, um ein Dienstticket für den richtigen Dienst auszustellen.

Warum kann ein doppelter SPN die Kerberos-Authentifizierung verhindern?

Antwort anzeigen

Der KDC kann den Dienst nicht eindeutig einem Konto zuordnen. Dadurch kann kein korrektes Dienstticket für die erwartete Dienstidentität ausgestellt werden.

Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?

Antwort anzeigen

Dadurch wird der für die Diagnose wichtige Zustand verändert. Außerdem kann die Maßnahme zusätzliche Probleme mit Computerkonto, Profilen, Berechtigungen, Zertifikaten und verwalteter Konfiguration erzeugen.

Worin unterscheiden sich AD- und SYSVOL-Replikation bei einer GPO?

Antwort anzeigen

Der Group Policy Container mit den Verzeichnisinformationen liegt im Active Directory. Das Group Policy Template mit den dateibasierten Richtlinieninhalten liegt in SYSVOL. Beide Bestandteile müssen verfügbar und konsistent sein.

39. Prüfungsfallen

40. Checkliste

41. Schnellreferenz

Beobachtung Nächstes Werkzeug
Domäne wird nicht gefunden ipconfig /all, nslookup, nltest /dsgetdc
falscher DNS-Server Adapter-, DHCP- und DNS-Konfiguration
DC wird nicht gefunden SRV-Abfragen und nltest
Anmeldung nur offline möglich DC-Erreichbarkeit, Zeit, Secure Channel
Vertrauensstellung fehlgeschlagen Test-ComputerSecureChannel, nltest
neues Kennwort funktioniert nicht überall repadmin, verwendeten DC bestimmen
Replikationsfehler repadmin /replsummary, repadmin /showrepl
DC-Zustand unklar dcdiag /v
DNS auf DC fehlerhaft dcdiag /test:dns /v
GPO fehlt gpresult, GPMC
GPO abgelehnt gpresult /h, Sicherheitsfilterung
GPO-Einstellung fehlt Detailbericht und GroupPolicy-Protokoll
SYSVOL nicht erreichbar DNS, SMB-Port und Freigaben
Gruppenänderung wirkt nicht whoami /groups, erneute Anmeldung
Konto wird wiederholt gesperrt Sicherheitsprotokoll und gespeicherte Anmeldedaten
Kerberos-Ticket fehlt klist, DNS, Zeit
Dienstticket fehlt klist, setspn -Q
doppelter SPN vermutet setspn -X
Fehler nur über Alias DNS- und SPN-Zuordnung
Zugriff nur über IP möglich DNS, Zielname, SPN und Kerberos
Fehler nur an einem Standort AD-Site, DC-Auswahl und Replikation
Fehler nur auf einem Client lokale DNS-, Konto-, Token- oder Profilprüfung

Merksatz

Active-Directory-Fehler werden von unten nach oben analysiert: Netzwerk, DNS, Domänencontroller, Zeit, Secure Channel, Replikation, Konten, Gruppenrichtlinien und Kerberos. Erst wenn die Abhängigkeiten nachweislich funktionieren, wird die betroffene Richtlinie, Berechtigung oder Anwendung verändert. Jede Änderung benötigt einen Rückweg und eine erneute Funktionsprüfung.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

8.3 Datei-, Freigabe-, Rechte- und Druckdienste analysieren

Datei- und Druckdienstfehler entstehen häufig nicht durch eine einzelne Komponente. Namensauflösung, Netzwerk, Authentifizierung, Freigabeberechtigungen, Dateisystemrechte, Gruppenmitgliedschaften, SMB-Einstellungen, DFS, Speicherplatz und Druckwarteschlangen wirken zusammen.

Grundregel:

Zuerst feststellen, ob bereits die Verbindung, die Authentifizierung, die Freigabe, die Datei oder erst die konkrete Aktion fehlschlägt.

1. Diagnosekette bei Dateizugriffen

Client
  ↓
DNS-Auflösung
  ↓
Netzwerk und TCP 445
  ↓
SMB-Dienst
  ↓
Authentifizierung
  ↓
Freigabeberechtigung
  ↓
NTFS-Berechtigung
  ↓
Datei, Ordner, Sperre oder Anwendung
  ↓
Datenträger und Backend

Jede Stufe muss getrennt geprüft werden.

Prüfschritt Typische Frage
Namensauflösung Zeigt der Servername auf die richtige IP-Adresse?
Netzwerk Ist der Server über den vorgesehenen Pfad erreichbar?
SMB-Port Ist TCP 445 erreichbar?
SMB-Dienst Nimmt der Server SMB-Verbindungen an?
Authentifizierung Mit welchem Konto erfolgt der Zugriff?
Freigaberecht Darf das Konto die Freigabe verwenden?
NTFS-Recht Darf das Konto den Ordner oder die Datei verwenden?
Objektzustand Existiert die Datei und ist sie verfügbar?
Sperre Wird die Datei von einem Prozess blockiert?
Speicher Sind Datenträger, Quota und Backend funktionsfähig?

2. Fehler exakt aufnehmen

Zu dokumentieren sind:

Beispiele für unterschiedliche Aktionen:

Ein Benutzer kann einen Ordner möglicherweise öffnen, aber keine Datei erstellen oder löschen. Deshalb genügt die Aussage „Zugriff funktioniert nicht“ nicht.

3. UNC-Pfad und Ziel bestimmen

Typischer UNC-Pfad:

\\fileserver01\Daten

Mit FQDN:

\\fileserver01.ad.example.local\Daten

Über DFS:

\\ad.example.local\Daten\Abteilung

Zu unterscheiden sind:

Ein Netzlaufwerk wie H: verdeckt den tatsächlichen UNC-Pfad. Dieser kann beispielsweise mit folgendem Befehl geprüft werden:

net use

PowerShell:

Get-SmbMapping

4. DNS-Auflösung prüfen

Resolve-DnsName fileserver01

Resolve-DnsName fileserver01.ad.example.local

nslookup fileserver01

Zusätzlich prüfen:

ping fileserver01

Der Ping dient hier hauptsächlich dazu, den aufgelösten Namen und die Zieladresse zu sehen. Er beweist nicht, dass SMB funktioniert.

Zu vergleichen sind:

Unterschiedliche Ergebnisse können auf Folgendes hinweisen:

5. SMB-Port prüfen

Windows:

Test-NetConnection fileserver01 -Port 445

Ausführlicher:

Test-NetConnection fileserver01 `
    -Port 445 `
    -InformationLevel Detailed

Linux:

nc -vz fileserver01 445

Ein erfolgreicher Test auf TCP 445 zeigt:

Er beweist noch nicht:

6. SMB-Clientverbindungen prüfen

Aktuelle SMB-Verbindungen:

Get-SmbConnection

Ausgewählte Informationen:

Get-SmbConnection |
    Select-Object ServerName,
                  ShareName,
                  UserName,
                  Credential,
                  Dialect,
                  NumOpens

SMB-Zuordnungen:

Get-SmbMapping

Klassische Anzeige:

net use

Dabei sind besonders zu prüfen:

7. Konflikt durch unterschiedliche Anmeldedaten

Windows verwendet für Verbindungen zu einem Server nicht beliebig viele verschiedene Anmeldeinformationen innerhalb desselben Benutzerkontexts.

Typisches Fehlerbild:

Mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource
von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig.

Bestehende Verbindungen anzeigen:

net use

Gespeicherte Anmeldeinformationen anzeigen:

cmdkey /list

Mögliche Ursachen:

Verbindungen dürfen nicht pauschal gelöscht werden, ohne ihre Verwendung zu prüfen. Ein Trennen kann geöffnete Dateien oder Anwendungen unterbrechen.

Gezieltes Trennen einer Zuordnung:

net use Z: /delete

Gezieltes Trennen eines UNC-Ziels:

net use \\fileserver01\Daten /delete

8. Freigaben auf dem Server prüfen

Vorhandene SMB-Freigaben:

Get-SmbShare

Bestimmte Freigabe:

Get-SmbShare -Name Daten

Wichtige Eigenschaften:

Get-SmbShare -Name Daten |
    Select-Object Name,
                  Path,
                  Description,
                  ScopeName,
                  FolderEnumerationMode,
                  EncryptData,
                  ConcurrentUserLimit

Klassische Anzeige:

net share

Zu prüfen sind:

Administrative Freigaben wie C$ benötigen normalerweise administrative Berechtigungen und sind kein geeigneter allgemeiner Funktionstest für normale Benutzer.

9. Freigabeberechtigungen prüfen

Get-SmbShareAccess -Name Daten

Beispielausgabe:

Name   AccountName                AccessControlType   AccessRight
----   -----------                -----------------   -----------
Daten  AD\GG-Dateidienst-Lesen    Allow               Read
Daten  AD\GG-Dateidienst-Ändern   Allow               Change

Wichtige Freigaberechte:

Freigaberecht Grundsätzliche Wirkung
Lesen Inhalte anzeigen und Dateien lesen
Ändern zusätzlich erstellen, ändern und löschen
Vollzugriff zusätzlich Freigabeberechtigungen verwalten

Die genaue wirksame Berechtigung ergibt sich nicht allein aus dieser Tabelle. Verweigerungen, Gruppenmitgliedschaften und NTFS-Berechtigungen müssen zusätzlich berücksichtigt werden.

10. NTFS-Berechtigungen prüfen

PowerShell:

Get-Acl 'D:\Freigaben\Daten' |
    Format-List

Einzelne Zugriffsregeln:

(Get-Acl 'D:\Freigaben\Daten').Access |
    Select-Object IdentityReference,
                  FileSystemRights,
                  AccessControlType,
                  IsInherited,
                  InheritanceFlags,
                  PropagationFlags

Kommandozeile:

icacls D:\Freigaben\Daten

Rekursives Auslesen kann bei großen Verzeichnisstrukturen sehr umfangreich und belastend sein. Es sollte nur gezielt eingesetzt werden.

Zu prüfen sind:

11. Freigabe- und NTFS-Rechte gemeinsam bewerten

Bei einem SMB-Zugriff wirken grundsätzlich beide Ebenen:

wirksames Freigaberecht
        +
wirksames NTFS-Recht
        ↓
restriktivere wirksame Kombination

Beispiele:

Freigabe NTFS Ergebnis über SMB
Lesen Ändern Lesen
Ändern Lesen Lesen
Vollzugriff Ändern Ändern
Vollzugriff Vollzugriff Vollzugriff
Ändern keine Berechtigung kein Zugriff

Beim lokalen Zugriff auf den Serverpfad gelten die Freigabeberechtigungen nicht. Dort werden nur die Dateisystemberechtigungen ausgewertet.

Deshalb kann ein lokaler Test auf dem Server funktionieren, während der Zugriff über SMB fehlschlägt.

12. Lesen, Ändern und Vollzugriff unterscheiden

Typische NTFS-Rechte:

Recht Bedeutung
Ordnerinhalt anzeigen Ordner durchsuchen und Inhalte auflisten
Lesen Inhalte und Eigenschaften lesen
Schreiben Dateien oder Daten erstellen beziehungsweise schreiben
Lesen und Ausführen Dateien lesen und ausführbare Dateien starten
Ändern lesen, schreiben, ausführen und löschen
Vollzugriff zusätzlich Berechtigungen und Eigentum verwalten

Für normale gemeinsame Datenordner reicht häufig Ändern. Vollzugriff sollte nicht ohne fachlichen Grund vergeben werden.

13. Löschen benötigt besondere Beachtung

Zum Löschen eines Objekts kann abhängig von der ACL eines der folgenden Rechte entscheidend sein:

Dadurch können scheinbar widersprüchliche Situationen entstehen:

Die Berechtigungen müssen deshalb auf dem betroffenen Objekt und dem übergeordneten Ordner geprüft werden.

14. Vererbung kontrollieren

(Get-Acl 'D:\Freigaben\Daten\Abteilung').AreAccessRulesProtected

Mögliche Zustände:

Typische Fehler:

Berechtigungen sollten nicht rekursiv ersetzt werden, bevor Umfang, Vererbung und Rückweg vollständig geklärt sind.

15. Gruppenmitgliedschaften prüfen

AD-Mitgliedschaften eines Benutzers:

Get-ADPrincipalGroupMembership max.mustermann |
    Select-Object Name

Aktuelle Gruppen im Anmeldetoken:

whoami /groups

Aktuelles Konto:

whoami

Benutzer-SID:

whoami /user

Berechtigungen des aktuellen Tokens:

whoami /priv

Wichtige Unterscheidung:

Mitgliedschaft im Active Directory
              ≠
Mitgliedschaft im bereits erzeugten Anmeldetoken

Wurde ein Benutzer gerade einer Gruppe hinzugefügt, kann eine erneute Anmeldung erforderlich sein. Eine bloße Sperrung und Entsperrung des Bildschirms erzeugt normalerweise kein vollständig neues interaktives Anmeldetoken.

16. Effektive Berechtigungen bewerten

Die grafische Registerkarte befindet sich üblicherweise unter:

Eigenschaften
→ Sicherheit
→ Erweitert
→ Effektiver Zugriff

Dabei muss der richtige Benutzer beziehungsweise Sicherheitsprinzipal ausgewählt werden.

Zu berücksichtigen sind:

Die Anzeige der effektiven NTFS-Rechte ersetzt nicht die Prüfung der Freigabeberechtigungen.

17. Zulassen und Verweigern

Eine explizite Verweigerung kann ein ansonsten gewährtes Recht blockieren. Trotzdem darf nicht vereinfacht angenommen werden, dass jede sichtbare Verweigerung immer sämtliche Zulassungen überschreibt.

Die Auswertung hängt unter anderem ab von:

Verweigerungen sollten sparsam verwendet werden. Eine saubere Gruppen- und Ordnerstruktur ist häufig leichter zu analysieren.

18. Access-Based Enumeration

Access-Based Enumeration kann Ordner vor Benutzern ausblenden, die darauf keine Berechtigung besitzen.

Einstellung anzeigen:

Get-SmbShare -Name Daten |
    Select-Object FolderEnumerationMode

Mögliche Folge:

Ein ausgeblendeter Ordner wurde daher nicht zwangsläufig gelöscht oder nicht repliziert.

19. Geöffnete Dateien und SMB-Sitzungen prüfen

Auf dem Dateiserver:

Get-SmbSession

Geöffnete Dateien:

Get-SmbOpenFile

Gefiltert nach Pfad:

Get-SmbOpenFile |
    Where-Object {
        $_.Path -like '*\Daten\*'
    }

Wichtige Informationen:

Eine Sitzung oder Datei darf nicht ungeprüft geschlossen werden. Nicht gespeicherte Daten können verloren gehen.

20. Dateisperren untersuchen

Typische Meldungen:

Mögliche Ursachen:

Werkzeuge:

Nicht jede Meldung über eine „gesperrte Datei“ beweist eine technische SMB-Sperre. Anwendungen können eigene Sperrmechanismen verwenden.

21. SMB-Serverkonfiguration prüfen

Get-SmbServerConfiguration

Ausgewählte Werte:

Get-SmbServerConfiguration |
    Select-Object EnableSMB1Protocol,
                  EnableSMB2Protocol,
                  RequireSecuritySignature,
                  EncryptData,
                  EnableLeasing,
                  EnableOplocks,
                  AuditSmb1Access

Clientkonfiguration:

Get-SmbClientConfiguration

Zu prüfen sind:

SMB 1 darf nicht pauschal als Problemlösung aktiviert werden. Das Protokoll ist veraltet und besitzt erhebliche Sicherheitsnachteile. Bei Altgeräten ist eine Aktualisierung, Segmentierung oder Ablösung zu prüfen.

22. Verwendeten SMB-Dialekt bestimmen

Get-SmbConnection |
    Select-Object ServerName,
                  ShareName,
                  Dialect,
                  Signed,
                  Encrypted

Mögliche Beobachtungen:

Die tatsächlich verwendete Verbindung muss geprüft werden. Eine allgemeine Servereinstellung beweist noch nicht, welcher Dialekt in einer bestimmten Sitzung ausgehandelt wurde.

23. Kerberos und NTLM bei SMB

Tickets prüfen:

klist

Für SMB ist typischerweise ein Dienstticket für einen SPN nach folgendem Muster relevant:

cifs/fileserver01

SPN suchen:

setspn -Q cifs/fileserver01

Mit FQDN:

setspn -Q cifs/fileserver01.ad.example.local

Mögliche Ursachen für NTLM statt Kerberos:

Ein erfolgreicher SMB-Zugriff beweist nicht automatisch, dass Kerberos verwendet wurde.

24. Zugriff über Alias prüfen

Beispiel:

\\fileserver01\Daten
\\datenserver\Daten

Beide Namen können auf dieselbe IP-Adresse zeigen, aber für Kerberos unterschiedliche Dienstidentitäten darstellen.

Zu prüfen sind:

Ein zusätzlicher DNS-CNAME allein stellt noch nicht sicher, dass Kerberos über den Alias funktioniert.

25. DFS-Namespace untersuchen

Ein DFS-Pfad kann Benutzer auf einen oder mehrere tatsächliche Zielserver verweisen:

\\ad.example.local\Daten\Abteilung

DFS-Namespace-Informationen:

Get-DfsnRoot

Ordner und Ziele:

Get-DfsnFolder

Get-DfsnFolderTarget

Clientseitige DFS-Informationen:

dfsutil /pktinfo

DFS-Cache anzeigen:

dfsutil /pktinfo

Zu prüfen sind:

26. DFS-Namespace und DFS-Replikation unterscheiden

Funktion Aufgabe
DFS Namespace stellt einen einheitlichen logischen Pfad bereit
DFS Replication repliziert Ordnerinhalte zwischen Servern

Ein funktionierender Namespace beweist nicht, dass die Daten repliziert wurden. Umgekehrt kann die Replikation funktionieren, während ein Namespace-Ziel falsch konfiguriert oder nicht erreichbar ist.

Typisches Fehlerbild:

27. DFS-Replikation prüfen

Relevanter Ereignisprotokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ DFS Replication

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'DFS Replication'
    StartTime = (Get-Date).AddHours(-4)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Replikationsgruppen:

Get-DfsReplicationGroup

Mitgliedschaften:

Get-DfsrMembership

Verbindungen:

Get-DfsrConnection

Zu dokumentieren sind:

Eine manuell erzwungene Synchronisation ist keine erste Diagnosemaßnahme.

28. Offline Files und Clientcache

Windows kann Netzwerkdateien lokal zwischenspeichern. Dadurch können Benutzer zeitweise mit einer lokalen Kopie arbeiten.

Mögliche Fehlerbilder:

Zu prüfen sind:

Der Offlinecache darf nicht ungeprüft zurückgesetzt werden. Nicht synchronisierte Benutzerdaten könnten verloren gehen.

29. Quotas und freier Speicherplatz

Freien Speicherplatz prüfen:

Get-Volume

Dateisystemlaufwerke:

Get-PSDrive -PSProvider FileSystem

FSRM-Quotas:

Get-FsrmQuota

Mögliche Symptome:

Zu unterscheiden sind:

30. Lange Pfade und Dateinamen

Mögliche Ursachen:

Typische reservierte Namen unter Windows sind beispielsweise:

CON
PRN
AUX
NUL
COM1
LPT1

Die Unterstützung langer Pfade hängt nicht nur vom Betriebssystem ab. Auch Anwendung, API und Konfiguration müssen sie unterstützen.

31. Eigentümer und ACL-Zustand

Eigentümer anzeigen:

(Get-Acl 'D:\Freigaben\Daten').Owner

Mögliche Probleme:

Nicht auflösbare SIDs beweisen allein keinen Fehler. Sie können noch wirksame Sicherheitskennungen ehemaliger oder nicht erreichbarer Domänenkonten darstellen und müssen vor einer Entfernung zugeordnet werden.

32. Ereignisprotokolle für SMB prüfen

Wichtige Protokollpfade können sein:

Microsoft
→ Windows
→ SMBClient
→ Connectivity

Microsoft
→ Windows
→ SMBClient
→ Security

Microsoft
→ Windows
→ SMBServer
→ Operational

Microsoft
→ Windows
→ SMBServer
→ Security

PowerShell-Beispiel:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-SMBClient/Connectivity'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich können relevant sein:

Event-ID, Provider, Zeitpunkt, Server, Client und vollständiger Ereignistext müssen gemeinsam bewertet werden.

33. SMB-Netzwerkverkehr untersuchen

Bei unklarem Netzwerk- oder Protokollfehler kann ein Paketmitschnitt erforderlich sein.

Typische Filter:

tcp.port == 445

smb2

ip.addr == 192.0.2.20 && tcp.port == 445

Zu untersuchen sind:

Ein Paketmitschnitt kann Datei- und Benutzernamen sowie weitere vertrauliche Informationen enthalten und muss geschützt gespeichert werden.

34. Druckpfad verstehen

Anwendung
   ↓
Druckertreiber
   ↓
Windows-Druckwarteschlange
   ↓
Spooler
   ↓
Druckserver oder direkter TCP/IP-Port
   ↓
Netzwerk
   ↓
Drucker
   ↓
Druckwerk, Papier und Verbrauchsmaterial

Die Meldung „Drucker druckt nicht“ kann daher verursacht werden durch:

35. Druckerfehler exakt eingrenzen

Zu dokumentieren sind:

Diese Tests trennen Anwendung, Benutzer, Client, Treiber, Queue, Server und Gerät voneinander.

36. Drucker und Warteschlangen anzeigen

PowerShell:

Get-Printer

Ausgewählte Eigenschaften:

Get-Printer |
    Select-Object Name,
                  ComputerName,
                  DriverName,
                  PortName,
                  Shared,
                  ShareName,
                  PrinterStatus,
                  JobCount

Bestimmter Drucker:

Get-Printer -Name 'Drucker-01'

Druckaufträge:

Get-PrintJob -PrinterName 'Drucker-01'

Druckerkonfiguration:

Get-PrintConfiguration -PrinterName 'Drucker-01'

37. Print Spooler prüfen

Get-Service Spooler

Ausführlicher:

Get-CimInstance Win32_Service `
    -Filter "Name='Spooler'" |
    Select-Object Name,
                  State,
                  StartMode,
                  StartName,
                  ProcessId

Abhängigkeiten:

Get-Service Spooler -DependentServices

Ein Neustart des Spoolers:

Restart-Service Spooler

verändert den Zustand und kann alle lokalen beziehungsweise serverseitigen Druckaufträge beeinflussen. Vorher sind zu prüfen:

38. Druckaufträge kontrollieren

Get-PrintJob -PrinterName 'Drucker-01' |
    Select-Object ID,
                  DocumentName,
                  UserName,
                  SubmittedTime,
                  JobStatus,
                  Size

Einzelnen Auftrag entfernen:

Remove-PrintJob `
    -PrinterName 'Drucker-01' `
    -ID 17

Vor dem Entfernen prüfen:

Nicht sofort die gesamte Warteschlange leeren, wenn ein einzelner Auftrag die Ursache sein könnte.

39. Druckerport prüfen

Get-PrinterPort

Bestimmter Port:

Get-PrinterPort -Name 'IP_192.0.2.50'

Zu prüfen sind:

Porttest für RAW Printing:

Test-NetConnection 192.0.2.50 -Port 9100

Mögliche weitere Protokolle hängen vom Drucksystem ab, beispielsweise IPP, IPPS, LPR oder SMB.

40. SNMP-Statusfehler

Ein Drucker kann erreichbar und druckfähig sein, aber in Windows als offline erscheinen, wenn die SNMP-Statusabfrage fehlschlägt.

Mögliche Ursachen:

Das Deaktivieren des SNMP-Status kann als kontrollierter Diagnosetest dienen. Es ist jedoch keine allgemeine Lösung, weil dadurch echte Gerätestatusinformationen verloren gehen können.

41. Druckertreiber untersuchen

Installierte Treiber:

Get-PrinterDriver

Mögliche Treiberprobleme:

Treiber dürfen nicht ungeprüft auf einem produktiven Druckserver ersetzt werden. Dadurch können mehrere Warteschlangen und Benutzer betroffen sein.

42. Windows-Testseite verwenden

Eine Testseite trennt die Anwendung teilweise vom restlichen Druckpfad.

PowerShell über WMI/CIM:

Invoke-CimMethod `
    -ClassName Win32_Printer `
    -MethodName PrintTestPage `
    -Arguments @{} `
    -Filter "Name='Drucker-01'"

Bewertung:

Ergebnis Wahrscheinlicher Bereich
Testseite funktioniert, Anwendung nicht Anwendung, Dokument, Format oder anwendungsspezifische Einstellungen
Testseite bleibt in Queue Spooler, Treiber, Port oder Druckserver
Auftrag verlässt Queue, Drucker reagiert nicht Port, Netzwerk, Protokoll oder Gerät
Auftrag wird gedruckt, Ausgabe fehlerhaft Treiber, Druckersprache, Gerätekonfiguration oder Hardware
alle Drucker betroffen Spooler, Server, Richtlinie oder gemeinsamer Dienst
nur ein Drucker betroffen Queue, Port, Treiber oder Gerät

43. Druckereignisse prüfen

Wichtiger Protokollpfad:

Ereignisanzeige
→ Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ PrintService
→ Operational

Das Operational-Protokoll muss je nach System zunächst aktiviert werden.

PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-PrintService/Operational'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  Message

Zusätzlich prüfen:

44. CUPS unter Linux und macOS prüfen

Druckerstatus:

lpstat -t

Standarddrucker:

lpstat -d

Warteschlange:

lpq

Druckaufträge:

lpstat -o

Auftrag abbrechen:

cancel <Auftrags-ID>

Alle Aufträge eines Druckers abbrechen:

cancel -a <Druckername>

CUPS-Dienst unter systemd:

systemctl status cups

Protokoll:

journalctl -u cups

Je nach System können die CUPS-Protokolle zusätzlich unter folgendem Pfad liegen:

/var/log/cups/

Zu prüfen sind:

45. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Servername nicht erreichbar DNS oder Netzwerk Resolve-DnsName, Test-NetConnection
IP funktioniert, Name nicht DNS, Alias oder SPN Kurzname, FQDN und DNS-Einträge vergleichen
TCP 445 nicht erreichbar Firewall, Routing oder SMB-Dienst Porttest und Serverstatus
Freigabe nicht gefunden falscher Name oder Freigabe fehlt Get-SmbShare, net share
Freigabe öffnet sich, Unterordner nicht NTFS-Rechte oder ABE ACL und effektiven Zugriff prüfen
Datei lesbar, aber nicht änderbar fehlendes Schreib- oder Änderungsrecht Share- und NTFS-Rechte
Datei änderbar, aber nicht löschbar Löschrecht oder Eltern-ACL Datei- und Ordner-ACL prüfen
Zugriff lokal möglich, über SMB nicht Freigaberecht oder SMB-Pfad Get-SmbShareAccess
neuer Gruppeneintrag wirkt nicht altes Anmeldetoken whoami /groups, erneute Anmeldung
Zugriff verweigert trotz Gruppenmitgliedschaft Verweigerung, falsches Token oder NTFS-Recht effektiven Zugriff prüfen
Datei angeblich in Verwendung offenes Handle oder Anwendungssperre Get-SmbOpenFile
Zugriff über Alias schlägt fehl SPN oder Kerberos klist, setspn -Q
DFS-Pfad zeigt alte Daten falsches Ziel oder DFS-R-Störung dfsutil /pktinfo, DFS-R-Ereignisse
Dateien unterscheiden sich je nach Client unterschiedliche DFS-Ziele Zielserver und Replikation vergleichen
Speichern schlägt ab bestimmter Größe fehl Quota oder freier Speicher Volume und FSRM prüfen
Drucker für alle Benutzer offline Netzwerk, Port oder Gerät Porttest und Druckerstatus
nur ein Benutzer kann nicht drucken Berechtigung oder Benutzerprofil Druckerrechte und Vergleichsbenutzer
nur eine Anwendung druckt nicht Anwendung oder Dokument Windows-Testseite
alle Drucker eines Servers betroffen Spooler oder Druckserver Dienst und Ereignisse
nur eine Queue betroffen Auftrag, Treiber oder Port Queue, Treiber und Port
Auftrag bleibt in Warteschlange Spooler, Treiber oder Port PrintService-Protokoll
Auftrag verschwindet, kein Ausdruck Protokoll, Gerät oder Druckersprache Druckerprotokoll und Port
Drucker fälschlich offline SNMP-Statusabfrage SNMP-Konfiguration prüfen
Spooler stürzt wiederholt ab Treiber oder Print Processor Ereignisse und Treiberzuordnung

46. Vorgehensweise bei „Zugriff verweigert“

  1. vollständigen UNC-Pfad dokumentieren.
  2. Benutzer und Client bestimmen.
  3. konkrete fehlgeschlagene Aktion erfassen.
  4. verwendetes Konto mit whoami prüfen.
  5. aktuelle Gruppen mit whoami /groups prüfen.
  6. Servername und Zieladresse prüfen.
  7. SMB-Verbindung und verwendete Anmeldedaten prüfen.
  8. Freigabeberechtigungen auslesen.
  9. NTFS-Berechtigungen des betroffenen Objekts prüfen.
  10. Vererbung und Eigentümer berücksichtigen.
  11. Berechtigungen des übergeordneten Ordners prüfen.
  12. explizite Verweigerungen untersuchen.
  13. Test mit einem funktionierenden Benutzer durchführen.
  14. genau eine kontrollierte Korrektur umsetzen.
  15. Zugriff mit der ursprünglichen Aktion erneut testen.
  16. Rechte nach dem Minimalprinzip dokumentieren.

47. Vorgehensweise bei „Datei ist gesperrt“

  1. Dateiname und vollständigen Pfad erfassen.
  2. Benutzer, Client und Anwendung bestimmen.
  3. prüfen, ob Lesen oder nur Bearbeiten fehlschlägt.
  4. Get-SmbOpenFile auf dem Dateiserver auswerten.
  5. Anwendungssperrdateien berücksichtigen.
  6. Serverprozesse mit Handle oder Process Explorer prüfen.
  7. Virenscanner, Backup und Synchronisation berücksichtigen.
  8. Rechte zum Ändern und Löschen prüfen.
  9. Benutzer kontaktieren, der die Datei geöffnet hält.
  10. ungespeicherte Daten ausschließen.
  11. erst danach gezielt das Handle oder die Sitzung schließen.
  12. Datei erneut öffnen, ändern und speichern.
  13. Ursache und Auswirkung dokumentieren.

48. Vorgehensweise bei DFS-Problemen

  1. logischen DFS-Pfad dokumentieren.
  2. Client und Benutzer bestimmen.
  3. DFS-Referral des Clients prüfen.
  4. tatsächlichen Zielserver dokumentieren.
  5. Zielserver per DNS und TCP 445 prüfen.
  6. direkten UNC-Pfad zum Zielserver testen.
  7. Namespace-Ordner und Ziele prüfen.
  8. AD-Site und Zielpriorität berücksichtigen.
  9. Rechte auf allen Zielen vergleichen.
  10. Dateistände und Zeitstempel vergleichen.
  11. DFS-R-Ereignisse prüfen.
  12. Replikationsrichtung und Backlog untersuchen.
  13. nur die nachgewiesene Ursache korrigieren.
  14. Clientzugriff und Replikation erneut prüfen.

49. Vorgehensweise bei Druckproblemen

  1. Drucker, Queue, Server und Port dokumentieren.
  2. genaue Meldung und Zeitpunkt erfassen.
  3. Umfang bestimmen: ein Benutzer, Client, Drucker oder alle.
  4. Warteschlange und Auftragsstatus prüfen.
  5. Windows-Testseite auslösen.
  6. Spoolerstatus prüfen.
  7. PrintService-Ereignisse auswerten.
  8. Druckername und IP-Adresse prüfen.
  9. tatsächlichen Druckerport testen.
  10. SNMP-Status kontrollieren.
  11. Treibername und Version prüfen.
  12. Berechtigungen der Queue prüfen.
  13. Gerätestatus und Verbrauchsmaterial prüfen.
  14. genau eine kontrollierte Maßnahme durchführen.
  15. Testseite und ursprüngliches Dokument erneut drucken.
  16. Ereignisse und Queue nachkontrollieren.

50. Maßnahmen und Rückwege

Ursache: falsche Freigabeberechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlende NTFS-Berechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: altes Anmeldetoken

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falsches DFS-Ziel

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: fehlerhafter Druckerport

Nachweis:

Maßnahme:

Rollback:

Verifikation:

51. Nachkontrolle

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

52. Dokumentationsbeispiel

Symptom:
Der Benutzer konnte Dateien in der Freigabe lesen, aber keine neue Datei
im Unterordner „Projekte“ erstellen.

Zeitpunkt:
02.08.2026, 11:26 Uhr MESZ

Benutzer:
max.mustermann

Client:
CLIENT-17

Pfad:
\\fileserver01.ad.example.local\Daten\Projekte

Nachweis:
DNS-Auflösung und TCP 445 waren erfolgreich.
Die SMB-Verbindung verwendete das vorgesehene Domänenkonto.
Die Freigabeberechtigung gewährte der zuständigen Gruppe „Ändern“.
Die NTFS-Auswertung zeigte jedoch nur Leserechte auf dem Unterordner.
Die Vererbung war an diesem Unterordner deaktiviert worden.

Ursache:
Bei einer früheren manuellen ACL-Änderung wurde die Vererbung auf dem
Unterordner unterbrochen. Dadurch fehlte der vorgesehenen Gruppe das
Änderungsrecht.

Maßnahme:
Nach Sicherung der bestehenden ACL wurde die freigegebene
Berechtigungsstruktur des übergeordneten Ordners wiederhergestellt.

Rollback:
Die zuvor exportierte ACL kann wieder eingespielt werden.

Verifikation:
Der Benutzer kann Dateien lesen, erstellen, ändern und löschen.
Er kann keine Berechtigungen verändern.
Andere Abteilungsordner bleiben weiterhin unzugänglich.
Es wurden keine zusätzlichen administrativen Rechte vergeben.

Prävention:
Berechtigungsänderungen erfolgen künftig ausschließlich über dokumentierte
Sicherheitsgruppen und werden durch einen Test des effektiven Zugriffs geprüft.

53. Entscheidungsbaum

Datei- oder Freigabezugriff gestört
        ↓
Wird der richtige Servername aufgelöst?
        ├── Nein
        │   ↓
        │   DNS, Alias und DFS-Namen prüfen
        │
        └── Ja
            ↓
Ist TCP 445 erreichbar?
        ├── Nein
        │   ↓
        │   Routing, Firewall und SMB-Dienst prüfen
        │
        └── Ja
            ↓
Existiert die Freigabe und zeigt sie auf den richtigen Pfad?
        ├── Nein
        │   ↓
        │   Freigabe- und Serverkonfiguration prüfen
        │
        └── Ja
            ↓
Wird das vorgesehene Benutzerkonto verwendet?
        ├── Nein
        │   ↓
        │   bestehende Verbindungen und Anmeldedaten prüfen
        │
        └── Ja
            ↓
Sind Freigabeberechtigungen ausreichend?
        ├── Nein
        │   ↓
        │   Freigabe-ACL kontrolliert korrigieren
        │
        └── Ja
            ↓
Sind NTFS-Berechtigungen ausreichend?
        ├── Nein
        │   ↓
        │   ACL, Vererbung, Gruppen und Token prüfen
        │
        └── Ja
            ↓
Ist nur eine Datei oder Aktion betroffen?
        ├── Ja
        │   ↓
        │   Sperre, Einzel-ACL, Pfad, Quota und Anwendung prüfen
        │
        └── Nein
            ↓
DFS, Storage, Serverzustand und zentrale Abhängigkeiten prüfen

54. Typische Prüfungsfragen

Warum reicht ein erfolgreicher Ping zum Dateiserver nicht als Funktionsnachweis?

Antwort anzeigen

Ein Ping prüft eine bestimmte ICMP-Kommunikation. Er beweist weder die Erreichbarkeit von TCP 445 noch eine erfolgreiche SMB-Authentifizierung oder ausreichende Freigabe- und NTFS-Berechtigungen.

Welche Berechtigungen wirken bei einem SMB-Zugriff auf einen NTFS-Ordner?

Antwort anzeigen

Es wirken sowohl die Freigabe- als auch die NTFS-Berechtigungen. Für den Zugriff über das Netzwerk ergibt sich die wirksame Berechtigung aus der restriktiveren Kombination beider Ebenen.

Warum kann der lokale Zugriff auf einen Serverordner funktionieren, während der SMB-Zugriff fehlschlägt?

Antwort anzeigen

Beim lokalen Zugriff werden keine SMB-Freigabeberechtigungen ausgewertet. Über das Netzwerk wirken zusätzlich zu den NTFS-Rechten auch die Freigabeberechtigungen und die SMB-Authentifizierung.

Warum kann eine neue Gruppenmitgliedschaft noch nicht wirksam sein?

Antwort anzeigen

Die Gruppe kann bereits im Active Directory eingetragen sein, aber im aktuellen Anmeldetoken fehlen. Häufig ist eine erneute Benutzeranmeldung erforderlich, damit ein neues Token erzeugt wird.

Worin unterscheiden sich DFS Namespace und DFS Replication?

Antwort anzeigen

DFS Namespace stellt einen einheitlichen logischen Zugriffspfad bereit. DFS Replication synchronisiert Ordnerinhalte zwischen mehreren Servern. Beide Funktionen können unabhängig voneinander gestört sein.

Warum sollte eine geöffnete SMB-Datei nicht sofort zwangsweise geschlossen werden?

Antwort anzeigen

Die zugehörige Anwendung kann noch nicht gespeicherte Änderungen besitzen. Ein erzwungenes Schließen kann Datenverlust oder beschädigte Anwendungszustände verursachen.

Warum beweist ein erfolgreicher Zugriff über einen Alias nicht automatisch die Verwendung von Kerberos?

Antwort anzeigen

Fehlt ein passender CIFS-SPN für den Alias, kann der Zugriff abhängig von der Umgebung über NTLM erfolgen. Tickets und SPN-Zuordnung müssen gesondert geprüft werden.

Welche Funktion besitzt der Print Spooler?

Antwort anzeigen

Der Print Spooler nimmt Druckaufträge entgegen, verarbeitet beziehungsweise zwischenspeichert sie und übergibt sie über die konfigurierte Warteschlange und den Druckerport an das Ziel.

Warum kann ein Drucker fälschlich als offline angezeigt werden?

Antwort anzeigen

Die eigentliche Druckverbindung kann funktionieren, während die SNMP-Statusabfrage fehlschlägt. Ursachen können eine falsche Community, blockiertes UDP 161 oder eine fehlerhafte SNMP-Konfiguration sein.

55. Prüfungsfallen

56. Checkliste

57. Schnellreferenz

Beobachtung Nächstes Werkzeug
Servername zeigt auf falsche IP Resolve-DnsName, nslookup
SMB-Port nicht erreichbar Test-NetConnection -Port 445
bestehende Netzlaufwerke unklar net use, Get-SmbMapping
verwendetes SMB-Konto unklar Get-SmbConnection
Freigabe fehlt Get-SmbShare, net share
Freigaberecht unklar Get-SmbShareAccess
NTFS-Recht unklar Get-Acl, icacls
aktuelle Gruppen unklar whoami /groups
Datei gesperrt Get-SmbOpenFile, Handle
SMB-Sitzung unklar Get-SmbSession
SMB-Version unklar Get-SmbConnection
Alias funktioniert nicht klist, setspn -Q
DFS-Ziel unklar dfsutil /pktinfo
DFS-Konfiguration unklar Get-DfsnFolderTarget
DFS-R-Störung DFS-Replication-Protokoll
Speicherplatz unklar Get-Volume, Get-PSDrive
Quota vermutet Get-FsrmQuota
Druckerstatus unklar Get-Printer
Druckaufträge hängen Get-PrintJob
Spoolerstatus unklar Get-Service Spooler
Druckerport unklar Get-PrinterPort
Treiber unklar Get-PrinterDriver
Druckereignis gesucht PrintService/Operational
CUPS-Status unklar lpstat -t, journalctl -u cups

Merksatz

Bei Datei- und Freigabefehlern wird vom Namen über TCP 445, SMB-Sitzung und Authentifizierung bis zu Freigabe- und NTFS-Rechten geprüft. Bei Druckfehlern wird der Weg von Anwendung und Treiber über Queue, Spooler und Port bis zum physischen Drucker verfolgt. Rechte, Sitzungen, Dateien und Druckaufträge werden erst verändert, wenn Ursache, Auswirkung und Rückweg geklärt sind.

Quellen und weiterführende Dokumentation

Offizielle Microsoft-Dokumentation

Offizielle CUPS-Dokumentation

8.4 Linux-Server – Dienste, Prozesse, Protokolle, Ressourcen und Speicher

1. Ziel dieser Seite

Diese Seite beschreibt die strukturierte Fehleranalyse auf Linux-Servern.

Typische Störungen betreffen:

Das Ziel ist nicht, einen Dienst möglichst schnell neu zu starten. Zuerst werden Fehlerzustand, Ursache, Auswirkungen und Rückweg dokumentiert.

2. Diagnosegrundsatz

Symptom erfassen
        ↓
Umfang bestimmen
        ↓
Systemzustand und Zeitpunkt prüfen
        ↓
Dienst, Prozess und Port untersuchen
        ↓
Protokolle auswerten
        ↓
Abhängigkeiten prüfen
        ↓
Konfiguration und Berechtigungen prüfen
        ↓
Ressourcen und Storage prüfen
        ↓
Ursache nachweisen
        ↓
Eine kontrollierte Maßnahme durchführen
        ↓
Funktion und Nebenwirkungen kontrollieren

Ein erfolgreicher Prozessstart beweist noch keine funktionierende Anwendung. Ebenso beweist ein offener Port nicht, dass die Anwendung korrekte Antworten liefert.

3. Fehlerbild exakt erfassen

Zu dokumentieren sind:

Wichtige Abgrenzungsfragen:

4. System identifizieren

Hostname:

hostnamectl

Kurzer Hostname:

hostname

Betriebssysteminformationen:

cat /etc/os-release

Kernelversion und Architektur:

uname -a

Nur Kernelversion:

uname -r

Architektur:

uname -m

Systemlaufzeit und Last:

uptime

Letzter Systemstart:

who -b

Aktuelle Zeit und Zeitzone:

timedatectl

Diese Informationen sind wichtig, weil Befehle, Dateipfade, Paketmanager, Sicherheitsmodule und Protokollierung je nach Distribution und Version unterschiedlich sein können.

5. Letzte Änderungen bestimmen

Mögliche Ursachen kurz vor Beginn einer Störung:

Anmeldehistorie:

last

Fehlgeschlagene Anmeldungen, sofern unterstützt und berechtigt:

lastb

Letzte Neustarts:

last reboot

Zeitstempel einer Datei:

stat /etc/example/application.conf

RPM-basierte Systeme:

dnf history

Debian- und Ubuntu-Systeme:

grep -E ' install | upgrade | remove ' /var/log/dpkg.log

Rotierte Protokolle müssen gegebenenfalls zusätzlich geprüft werden.

6. systemd-Gesamtzustand prüfen

Fehlgeschlagene Units:

systemctl --failed

Systemzustand:

systemctl is-system-running

Alle geladenen Dienste:

systemctl list-units --type=service --all

Installierte Unit-Dateien:

systemctl list-unit-files --type=service

Abweichende oder lokal angepasste Units:

systemd-delta

Ein System kann als degraded angezeigt werden, obwohl die vom Benutzer benötigte Anwendung funktioniert. Deshalb müssen die fehlgeschlagenen Units einzeln bewertet werden.

7. Dienststatus untersuchen

Beispieldienst:

systemctl status example.service

Aktivitätsstatus:

systemctl is-active example.service

Autostartstatus:

systemctl is-enabled example.service

Fehlerzustand:

systemctl is-failed example.service

Ausgewählte Eigenschaften:

systemctl show example.service \
    -p ActiveState \
    -p SubState \
    -p Result \
    -p ExecMainCode \
    -p ExecMainStatus \
    -p MainPID \
    -p User \
    -p Group \
    -p FragmentPath

Zu unterscheiden sind:

enabled bedeutet nicht, dass der Dienst gerade läuft. active bedeutet nicht automatisch, dass er beim nächsten Systemstart wieder gestartet wird.

8. Dienstprotokoll mit journalctl prüfen

Aktuelles Dienstprotokoll:

journalctl -u example.service

Nur aktueller Systemstart:

journalctl -u example.service -b

Vorheriger Systemstart:

journalctl -u example.service -b -1

Letzte 100 Einträge:

journalctl -u example.service -n 100

Fortlaufende Anzeige:

journalctl -u example.service -f

Bestimmter Zeitraum:

journalctl -u example.service \
    --since "2026-08-02 10:00:00" \
    --until "2026-08-02 11:00:00"

Warnungen und schwerere Meldungen des aktuellen Starts:

journalctl -b -p warning

Kernelmeldungen des aktuellen Starts:

journalctl -k -b

Ausführliche Ausgabe:

journalctl -u example.service -o verbose

Zu dokumentieren sind:

Die letzte Fehlermeldung muss nicht die eigentliche Ursache sein. Häufig steht die erste relevante Meldung weiter oben.

9. Klassische Protokolldateien

Je nach Distribution und Dienst können zusätzlich relevant sein:

/var/log/syslog
/var/log/messages
/var/log/auth.log
/var/log/secure
/var/log/kern.log
/var/log/audit/audit.log
/var/log/dmesg
/var/log/cron
/var/log/maillog

Anwendungsprotokolle befinden sich häufig unter:

/var/log/<Anwendung>/

Letzte Zeilen anzeigen:

tail -n 100 /var/log/syslog

Fortlaufend beobachten:

tail -f /var/log/example/application.log

Komprimierte rotierte Protokolle durchsuchen:

zgrep -i 'error' /var/log/example/application.log*.gz

Nicht jede Distribution verwendet alle genannten Dateien. Auf ausschließlich journalbasierten Systemen können einzelne klassische Protokolldateien fehlen.

10. Unit-Datei und Überschreibungen prüfen

Wirksame Unit einschließlich Drop-ins anzeigen:

systemctl cat example.service

Pfad und Drop-ins:

systemctl show example.service \
    -p FragmentPath \
    -p DropInPaths

Abhängigkeiten:

systemctl list-dependencies example.service

Umgekehrte Abhängigkeiten:

systemctl list-dependencies --reverse example.service

Startreihenfolge und Abhängigkeiten können beeinflusst werden durch:

After= legt eine Reihenfolge fest, erzeugt allein aber keine Startabhängigkeit.

11. systemd-Konfiguration verifizieren

Unit-Dateien prüfen:

systemd-analyze verify example.service

Nach einer Änderung an Unit-Dateien:

systemctl daemon-reload

daemon-reload lädt die systemd-Konfiguration neu. Es startet den betroffenen Dienst nicht automatisch neu.

Vor einem Neustart des Dienstes sind zu prüfen:

12. Anwendungsidentität prüfen

Der Dienst kann unter einem anderen Benutzer laufen als erwartet.

systemd-Konfiguration:

systemctl show example.service \
    -p User \
    -p Group \
    -p SupplementaryGroups \
    -p DynamicUser

Prozessbenutzer:

ps -eo user,group,pid,ppid,stat,lstart,cmd

Bestimmter Prozess:

ps -o user,group,pid,ppid,stat,lstart,cmd -p <PID>

Benutzerinformationen:

id exampleuser

Gruppen eines Benutzers:

id -nG exampleuser

Kontoeintrag:

getent passwd exampleuser

Gruppeneintrag:

getent group examplegroup

getent berücksichtigt die konfigurierte Namensdienstauflösung und ist deshalb bei LDAP-, Active-Directory- oder SSSD-Umgebungen häufig aussagekräftiger als das alleinige Lesen von /etc/passwd.

13. Prozesse untersuchen

Alle Prozesse:

ps aux

Hierarchische Darstellung:

ps -ef --forest

Prozesse eines Benutzers:

ps -u exampleuser -f

Prozess anhand des Namens suchen:

pgrep -a example

Prozessbaum:

pstree -ap

Dynamische Anzeige:

top

Falls installiert:

htop

Zu prüfen sind:

14. Prozesszustände bewerten

Wichtige Zustände in ps:

Zustand Bedeutung
R läuft oder ist ausführbar
S unterbrechbarer Schlafzustand
D nicht unterbrechbarer Schlafzustand, häufig I/O-bezogen
T angehalten oder verfolgt
Z Zombieprozess
I inaktiver Kernelthread

Ein Prozess im Zustand D kann häufig nicht sofort beendet werden, weil er auf eine Kernel- oder I/O-Operation wartet.

Ein Zombie verbraucht normalerweise kaum Ressourcen. Er zeigt jedoch, dass der Elternprozess den Beendigungsstatus des Kindprozesses noch nicht abgeholt hat.

15. Signale und Prozessbeendigung

Normale Beendigungsanforderung:

kill -TERM <PID>

Standardsignal von kill:

kill <PID>

Erzwungene Beendigung:

kill -KILL <PID>

Signale anzeigen:

kill -l

SIGTERM erlaubt einem Prozess eine kontrollierte Beendigung. SIGKILL kann nicht abgefangen werden und verhindert eine geordnete Bereinigung.

Vor einer Prozessbeendigung prüfen:

Ein von systemd verwalteter Prozess sollte normalerweise über die zuständige Unit und nicht ausschließlich über seine PID gesteuert werden.

16. Offene Dateien und Arbeitsverzeichnisse prüfen

Offene Dateien eines Prozesses:

lsof -p <PID>

Prozesse mit Zugriff auf eine Datei:

lsof /var/lib/example/data.db

Alternativ:

fuser -v /var/lib/example/data.db

Prozesse auf einem Mountpoint:

fuser -vm /mnt/data

Gelöschte, aber weiterhin geöffnete Dateien:

lsof +L1

Eine gelöschte Datei kann weiterhin Speicherplatz belegen, solange ein Prozess sie geöffnet hält. Der Speicher wird normalerweise erst nach dem Schließen des Deskriptors freigegeben.

17. Ausführbare Datei und Bibliotheken prüfen

Verwendete Binärdatei:

readlink -f /proc/<PID>/exe

Arbeitsverzeichnis:

readlink -f /proc/<PID>/cwd

Kommandozeile:

tr '\0' ' ' < /proc/<PID>/cmdline

Umgebungsvariablen, nur mit erforderlicher Berechtigung:

tr '\0' '\n' < /proc/<PID>/environ

Bibliotheksabhängigkeiten:

ldd /usr/local/bin/example

ldd sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Je nach Datei und Implementierung kann dabei ein Sicherheitsrisiko entstehen.

18. Anwendungskonfiguration prüfen

Zu prüfen sind:

Datei anzeigen:

sed -n '1,200p' /etc/example/application.conf

Dateieigenschaften:

stat /etc/example/application.conf

Viele Dienste besitzen einen eigenen Syntaxprüfer. Beispiele:

sshd -t

nginx -t

apachectl configtest

Der passende Prüfbefehl muss zur tatsächlich installierten Anwendung und Version passen.

19. Dateirechte prüfen

Lange Darstellung:

ls -la /var/lib/example

Numerische IDs:

ls -lan /var/lib/example

Alle Bestandteile eines Pfades prüfen:

namei -l /var/lib/example/data/file.db

Dateistatus:

stat /var/lib/example/data/file.db

ACL anzeigen:

getfacl /var/lib/example/data/file.db

Zu prüfen sind:

Für das Betreten eines Verzeichnisses wird das Ausführungsrecht benötigt. Ausreichende Rechte auf der Datei allein genügen nicht, wenn ein übergeordnetes Verzeichnis nicht durchlaufen werden darf.

20. Zugriff als Dienstbenutzer testen

Kontrollierter Lesetest:

sudo -u exampleuser -- test -r /var/lib/example/data/file.db

Schreibbarkeit eines Verzeichnisses:

sudo -u exampleuser -- test -w /var/lib/example/data

Pfadzugriff:

sudo -u exampleuser -- namei -l /var/lib/example/data/file.db

Ein Test sollte möglichst dieselbe Identität, denselben Pfad und dieselbe Aktion wie die Anwendung verwenden.

Keine produktiven Dateien ungeprüft verändern oder überschreiben. Für Schreibtests ist eine dafür vorgesehene Testdatei zu verwenden.

21. SELinux prüfen

Status:

getenforce

Ausführlicher Status:

sestatus

Dateikontext:

ls -lZ /var/lib/example

Prozesskontext:

ps -eZ

Aktuelle AVC-Meldungen:

ausearch \
    -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR \
    -ts recent

Auswertung, sofern setroubleshoot installiert ist:

sealert -a /var/log/audit/audit.log

Sollkontext eines Pfades prüfen:

matchpathcon /var/lib/example/data

Kontext anhand der Richtlinie wiederherstellen:

restorecon -Rv /var/lib/example

SELinux darf nicht pauschal deaktiviert werden, nur um eine Anwendung zum Laufen zu bringen. Eine Ablehnung weist häufig auf einen falschen Pfad, falsches Label, eine unpassende Dienstkonfiguration oder eine fehlende gezielte Richtlinie hin.

Ein Wechsel in den permissiven Modus verändert den Sicherheitszustand des gesamten Systems und ist keine harmlose Standarddiagnose.

22. AppArmor prüfen

Status:

aa-status

Kernel- und Auditmeldungen:

journalctl -k | grep -i apparmor

Je nach System:

grep -i apparmor /var/log/syslog

Mögliche Ursachen:

Ein Profil sollte nicht ungeprüft deaktiviert werden. Zuerst sind Ablehnung, betroffener Pfad und notwendige Mindestberechtigung zu bestimmen.

23. Port und Socket prüfen

Lauschende TCP- und UDP-Sockets:

ss -tulpn

Nur lauschende TCP-Sockets:

ss -ltnp

Bestimmter Port:

ss -ltnp 'sport = :443'

Bestehende TCP-Verbindungen:

ss -tanp

Unix-Sockets:

ss -lxnp

Zu unterscheiden sind:

24. Portkonflikt untersuchen

Belegung eines Ports:

ss -ltnp 'sport = :8080'

Alternativ:

lsof -nP -iTCP:8080 -sTCP:LISTEN

Mögliche Ursachen:

Ein Prozess darf nicht allein deshalb beendet werden, weil er den gewünschten Port belegt. Zuerst muss seine Funktion und Zuständigkeit geklärt werden.

25. Lokale Anwendungsfunktion prüfen

TCP-Verbindung:

nc -vz 127.0.0.1 8080

HTTP-Abfrage:

curl -v http://127.0.0.1:8080/

HTTPS einschließlich Zertifikatsprüfung:

curl -v https://server.example.local/

TLS-Verbindung untersuchen:

openssl s_client \
    -connect server.example.local:443 \
    -servername server.example.local

Bewertung:

Ergebnis Wahrscheinlicher Bereich
lokal kein Listener Dienst, Konfiguration oder Startfehler
lokal erreichbar, remote nicht Firewall, Routing, Bind-Adresse oder Netzwerk
TCP funktioniert, HTTP fehlerhaft Anwendung, Reverse Proxy oder Backend
HTTP über IP funktioniert, Name nicht DNS, Virtual Host, SNI oder Zertifikat
TLS schlägt fehl Zertifikat, Schlüssel, Protokoll oder Cipher
Antwort langsam Anwendung, Backend, DNS, Storage oder Ressourcen

26. Netzwerkkonfiguration prüfen

Adressen:

ip address show

Kurzform:

ip -br address

Links:

ip -br link

Routingtabelle:

ip route show

IPv6-Routen:

ip -6 route show

Route zu einem konkreten Ziel:

ip route get 192.0.2.20

Nachbarn:

ip neigh show

Netzwerkstatistik:

ip -s link show

Zu prüfen sind:

27. Namensauflösung prüfen

Resolverkonfiguration:

cat /etc/resolv.conf

Auf systemd-resolved-Systemen:

resolvectl status

Namensauflösung über NSS:

getent hosts server.example.local

DNS-Abfrage:

dig server.example.local

Bestimmten DNS-Server abfragen:

dig @192.0.2.53 server.example.local

Reverse Lookup:

dig -x 192.0.2.20

Zu unterscheiden sind:

28. Firewall prüfen

Je nach System können unterschiedliche Werkzeuge verwendet werden.

firewalld:

firewall-cmd --get-active-zones

firewall-cmd --list-all

nftables:

nft list ruleset

iptables-Kompatibilitätsansicht:

iptables -S

Zu prüfen sind:

Ein geöffneter Port in der Hostfirewall beweist nicht, dass vorgelagerte Firewalls, Routing oder die Anwendung funktionieren.

29. Paketmitschnitt

Beispiel für TCP-Port 443:

tcpdump -ni any tcp port 443

Bestimmter Host und Port:

tcpdump -ni any \
    host 192.0.2.20 and tcp port 443

In Datei schreiben:

tcpdump -ni any \
    -s 0 \
    -w /tmp/example-443.pcap \
    tcp port 443

Zu untersuchen sind:

Paketmitschnitte können vertrauliche IP-Adressen, Hostnamen, Nutzdaten, Tokens und Anmeldeinformationen enthalten und müssen geschützt gespeichert sowie kontrolliert gelöscht werden.

30. CPU und Load prüfen

Überblick:

uptime

Dynamische Prozessansicht:

top

Logische Prozessoren:

nproc

CPU-Informationen:

lscpu

Falls sysstat installiert ist:

mpstat -P ALL 1 5

Prozessbezogene Statistik:

pidstat 1 5

Load Average beschreibt nicht ausschließlich CPU-Auslastung. Je nach Linux-Zustand können auch Tasks in nicht unterbrechbarem Zustand zur Last beitragen.

Zu unterscheiden sind:

31. Arbeitsspeicher prüfen

Speicherübersicht:

free -h

Detaillierte Kernelwerte:

cat /proc/meminfo

Prozesse nach Speicherverbrauch:

ps aux --sort=-%mem | head

Falls verfügbar:

vmstat 1 5

Wichtige Unterscheidungen:

32. OOM Killer untersuchen

Kernelmeldungen:

journalctl -k -b | grep -Ei 'out of memory|oom|killed process'

Systemweites Journal:

journalctl -b | grep -Ei 'out of memory|oom|killed process'

Mögliche Ursachen:

Zu dokumentieren sind:

Ein automatischer Dienstneustart kann den OOM-Kill verdecken. Der Dienst erscheint anschließend wieder aktiv, obwohl die Ursache weiter besteht.

33. Swap prüfen

Aktive Swap-Bereiche:

swapon --show

Speicherübersicht:

free -h

Aktivität:

vmstat 1 10

Bei vmstat sind insbesondere zu beachten:

Swap darf nicht ungeprüft mit swapoff deaktiviert werden. Der Inhalt muss in den Arbeitsspeicher übernommen werden können; andernfalls drohen starke Last oder Fehler.

34. Speicherplatz prüfen

Dateisysteme:

df -hT

Bestimmter Pfad:

df -hT /var/lib/example

Verzeichnisgrößen:

du -xhd1 /var

Größte Unterverzeichnisse:

du -xhd1 /var |
    sort -h

Zu unterscheiden sind:

df und du können unterschiedliche Werte zeigen, beispielsweise wegen gelöschter, aber geöffneter Dateien oder wegen Mounts innerhalb des untersuchten Verzeichnisbaums.

35. Inodes prüfen

Inode-Nutzung:

df -ih

Ein Dateisystem kann freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr aufnehmen, wenn keine freien Inodes vorhanden sind.

Typische Ursachen:

Anzahl der Einträge in einem kontrollierten Verzeichnisbaum:

find /var/tmp/example -xdev -type f |
    wc -l

Bei sehr großen Verzeichnisbäumen kann bereits das Zählen erhebliche I/O-Last verursachen.

36. Mounts prüfen

Aktuelle Mounts:

findmnt

Bestimmter Pfad:

findmnt -T /var/lib/example

Blockgeräte und Dateisysteme:

lsblk -f

Persistente Konfiguration:

cat /etc/fstab

fstab-Konfiguration ohne tatsächliches Mounten prüfen:

findmnt --verify

systemd-Mount-Units:

systemctl list-units --type=mount --all

Zu prüfen sind:

Eine Anwendung kann scheinbar korrekt in einen lokalen Ordner schreiben, obwohl das vorgesehene Netzwerk- oder Datenvolume nicht eingehängt ist.

37. Schreibgeschütztes Dateisystem

Mountoptionen:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'read-only|I/O error|filesystem|ext4|xfs'

Mögliche Ursachen:

Ein ungeprüftes Remount als rw kann eine bestehende Storage- oder Dateisystemstörung verschärfen. Zuerst müssen Kernelmeldungen und Datenträgerzustand bewertet werden.

38. Datenträger- und I/O-Fehler prüfen

Blockgeräte:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'I/O error|blk_update|reset|timeout|nvme|ata|scsi|ext4|xfs'

Falls sysstat installiert ist:

iostat -xz 1 5

S.M.A.R.T.-Informationen, sofern unterstützt:

smartctl -a /dev/sda

NVMe-Informationen, sofern das Werkzeug installiert ist:

nvme smart-log /dev/nvme0

Zu prüfen sind:

S.M.A.R.T.-Tests und Reparaturwerkzeuge können Last oder Zustandsänderungen verursachen. Sie sind nicht ungeprüft auf produktivem Storage auszuführen.

39. Dateisystemprüfung sicher planen

Dateisystemtyp feststellen:

findmnt -no FSTYPE,SOURCE,TARGET /var/lib/example

Ein klassisches fsck darf normalerweise nicht auf einem schreibend eingehängten Dateisystem ausgeführt werden.

Vor einer Reparatur sind zu klären:

Bei XFS, ext4, Btrfs und anderen Dateisystemen unterscheiden sich Diagnose- und Reparaturwerkzeuge erheblich.

40. LVM prüfen

Übersicht:

pvs

vgs

lvs

Ausführlicher:

lvs -a -o +devices

Zu prüfen sind:

Ein vergrößertes Logical Volume bedeutet nicht automatisch, dass auch das darin enthaltene Dateisystem vergrößert wurde.

41. Software-RAID prüfen

Status:

cat /proc/mdstat

Detailinformationen:

mdadm --detail /dev/md0

Zu prüfen sind:

Ein Rebuild erhöht die I/O-Last und ersetzt kein Backup. Ein zweiter Fehler während der Wiederherstellung kann je nach RAID-Level zum Datenverlust führen.

42. Netzwerk-Mounts prüfen

NFS-Mounts:

findmnt -t nfs,nfs4

SMB-/CIFS-Mounts:

findmnt -t cifs

RPC-Dienste eines NFS-Servers:

rpcinfo -p <Server>

NFS-Exporte, sofern erreichbar:

showmount -e <Server>

Zu prüfen sind:

Ein hängender Netzwerk-Mount kann Befehle wie df, du, ls oder Anwendungen blockieren.

43. Paketverwaltung prüfen

Debian- und Ubuntu-Systeme:

apt update

Installierten Paketstatus prüfen:

dpkg -l

Unterbrochene Paketkonfiguration:

dpkg --audit

RPM-basierte Systeme:

dnf check

Installiertes Paket bestimmen:

rpm -q <Paketname>

Datei einem Paket zuordnen:

rpm -qf /usr/bin/example

Debian-Paket zuordnen:

dpkg -S /usr/bin/example

Mögliche Ursachen:

Paketdatenbanken und Lockdateien dürfen nicht ungeprüft gelöscht werden. Zuerst ist zu bestimmen, ob ein legitimer Paketprozess aktiv ist.

44. Paketdateien verifizieren

RPM-Paket:

rpm -V <Paketname>

Debian- und Ubuntu-Systeme, falls debsums installiert ist:

debsums <Paketname>

Abweichungen können entstehen durch:

Eine Abweichung beweist allein weder einen Defekt noch eine Manipulation. Dateityp und erwartete lokale Anpassung müssen berücksichtigt werden.

45. Cronjobs prüfen

Systemweite Crontab:

cat /etc/crontab

Systemverzeichnisse:

ls -la /etc/cron.d/

Benutzer-Crontab:

crontab -l

Crontab eines anderen Benutzers:

sudo crontab -u exampleuser -l

Cron-Dienst:

systemctl status cron

Je nach Distribution:

systemctl status crond

Cron-Protokoll:

journalctl -u cron

Oder:

journalctl -u crond

Typische Ursachen:

Ein erfolgreicher manueller Skriptstart beweist nicht, dass der Cronjob mit seiner reduzierten Umgebung funktioniert.

46. systemd-Timer prüfen

Timer anzeigen:

systemctl list-timers --all

Bestimmten Timer:

systemctl status example.timer

Zugehörigen Dienst:

systemctl status example.service

Protokolle:

journalctl -u example.timer -u example.service

Konfiguration:

systemctl cat example.timer

Zu prüfen sind:

Der Timer kann erfolgreich ausgelöst haben, obwohl die zugehörige Service-Unit fehlgeschlagen ist.

47. Zeit und Zeitsynchronisation prüfen

Systemzeit:

date --iso-8601=seconds

Status:

timedatectl

Bei chrony:

chronyc tracking

chronyc sources -v

Bei systemd-timesyncd:

timedatectl timesync-status

Mögliche Auswirkungen falscher Zeit:

Die Zeit darf auf produktiven Datenbank-, Cluster- oder Authentifizierungssystemen nicht ungeprüft sprunghaft verändert werden.

48. Zertifikate prüfen

Zertifikatsdatei:

openssl x509 \
    -in /etc/example/server.crt \
    -noout \
    -subject \
    -issuer \
    -dates \
    -fingerprint

Private-Key-Dateirechte:

stat /etc/example/server.key

Zertifikat und Schlüssel vergleichen, beispielhaft für RSA:

openssl x509 \
    -noout \
    -modulus \
    -in /etc/example/server.crt |
    openssl sha256

openssl rsa \
    -noout \
    -modulus \
    -in /etc/example/server.key |
    openssl sha256

Zu prüfen sind:

Private Schlüssel dürfen nicht in Diagnoseprotokolle oder Tickets kopiert werden.

49. Kernelmeldungen prüfen

Aktueller Systemstart:

journalctl -k -b

Warnungen und Fehler:

journalctl -k -b -p warning

Klassische Anzeige:

dmesg --level=emerg,alert,crit,err,warn

Mögliche relevante Meldungen:

Der dmesg-Puffer kann ältere Meldungen überschreiben. Das persistente Journal oder ein zentraler Logserver kann deshalb zusätzliche Informationen liefern.

50. Kernelmodule und Hardware prüfen

Geladene Module:

lsmod

Modulinformationen:

modinfo <Modulname>

PCI-Geräte und Treiber:

lspci -k

USB-Geräte:

lsusb

Hardwareübersicht:

lscpu

lsblk

Mögliche Ursachen:

Kernelmodule dürfen nicht ungeprüft entladen werden. Ein Modul kann von Netzwerk-, Storage- oder anderen produktiven Geräten verwendet werden.

51. Bootfehler untersuchen

Bootzeit analysieren:

systemd-analyze

Langsame Units:

systemd-analyze blame

Kritische Kette:

systemd-analyze critical-chain

Fehlgeschlagene Units:

systemctl --failed

Protokoll des aktuellen Starts:

journalctl -b

Protokoll des vorherigen Starts:

journalctl -b -1

Verfügbare Starts:

journalctl --list-boots

Zu prüfen sind:

52. Unerwarteten Neustart oder Absturz prüfen

Letzte Neustarts:

last reboot

Vorheriger Boot:

journalctl -b -1 -e

Kernelmeldungen des vorherigen Boots:

journalctl -k -b -1

Mögliche Ursachen:

Fehlende Abschlussmeldungen im Journal können auf einen abrupten Ausfall hinweisen, beweisen aber keine bestimmte Ursache.

53. Hängendes System und Hung Tasks

Nach Meldungen suchen:

journalctl -k |
    grep -Ei 'blocked for more than|hung task|soft lockup|hard lockup'

Mögliche Ursachen:

Magic SysRq kann in schweren Störungsfällen Diagnose- oder Notfallfunktionen auslösen. Die verfügbaren Funktionen hängen von Kernelkonfiguration und Systemwerten ab.

Status:

cat /proc/sys/kernel/sysrq

SysRq-Aktionen können erhebliche Auswirkungen bis hin zu Prozessbeendigung oder Neustart besitzen. Sie dürfen nur nach einem dafür vorgesehenen Notfallverfahren verwendet werden.

54. Strace als gezielte Tiefenanalyse

Systemaufrufe eines gestarteten Programms:

strace -f -o /tmp/example.strace <Befehl>

An laufenden Prozess anhängen:

strace -f -p <PID>

Nach Dateioperationen filtern:

strace -f -e trace=file <Befehl>

Nach Netzwerkoperationen filtern:

strace -f -e trace=network <Befehl>

Zu erkennen sind beispielsweise:

strace kann Leistung und Zeitverhalten beeinflussen sowie vertrauliche Dateinamen, Argumente und Daten sichtbar machen.

55. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Dienst startet nicht Syntax, Rechte, Abhängigkeit oder fehlende Datei systemctl status, journalctl -u
Dienst beendet sich sofort Anwendung meldet Fehler oder Prozess forkt anders als erwartet Journal und ExecMainStatus
Dienst ist active, Anwendung funktioniert nicht interner Fehler, falscher Port oder Backend gestört ss, curl, Anwendungslog
Dienst ist failed, Prozess läuft Prozess wurde außerhalb von systemd gestartet ps, systemctl show
Dienst startet nach Reboot nicht nicht aktiviert oder Boot-Abhängigkeit fehlerhaft is-enabled, Bootjournal
Dienst läuft als falscher Benutzer Unit oder Drop-in geändert systemctl cat, systemctl show
Konfigurationsänderung wirkt nicht falsche Datei oder kein Reload/Restart Prozessargumente und Unit prüfen
Port ist nicht geöffnet Dienststart oder Bind-Konfiguration ss -ltnp
Port ist nur lokal erreichbar Bind-Adresse oder Firewall ss, Firewall, Remote-Test
Port bereits belegt zweite Instanz oder anderer Dienst ss, lsof
Zugriff verweigert Unix-Rechte, ACL, SELinux oder AppArmor namei, getfacl, Auditlog
Datei nicht gefunden, obwohl sie existiert falscher Namespace, Mount oder Pfadbestandteil namei, findmnt, Prozessumgebung
Schreiben schlägt fehl Rechte, ro, Speicher oder Inodes test -w, findmnt, df -h, df -i
df zeigt voll, du nicht gelöschte offene Datei oder reservierter Bereich lsof +L1
du hängt Netzwerk-Mount oder Storageproblem findmnt, Prozesszustand, Kerneljournal
hohe Load bei geringer CPU I/O-Wait oder Tasks im Zustand D vmstat, iostat, ps
Prozess wurde unerwartet beendet OOM, Signal oder Crash Kernel- und Dienstjournal
Server nutzt Swap stark früherer oder aktueller Speicherdruck vmstat, free, Prozessspeicher
keine neuen Dateien trotz freiem Speicher Inodes erschöpft df -ih
Mount fehlt nach Neustart fstab, Abhängigkeit oder Gerät fehlt findmnt --verify, Bootjournal
Dateisystem plötzlich read-only I/O- oder Dateisystemfehler Kerneljournal
Cronjob läuft manuell, aber nicht automatisch Umgebung, Benutzer, Pfad oder Shell Cronlog und kontrollierter Umgebungstest
systemd-Timer löst aus, Aufgabe scheitert zugehörige Service-Unit fehlerhaft Journal beider Units
TLS-Zertifikat angeblich abgelaufen falsche Zeit oder altes geladenes Zertifikat timedatectl, openssl s_client
Paketupdate schlägt fehl Repository, DNS, Signatur oder Lock Paketmanager- und Prozessstatus
Server startet langsam Mount-, Netzwerk- oder Unit-Timeout systemd-analyze critical-chain
Netzwerk funktioniert nach IP, nicht nach Name DNS oder NSS getent hosts, dig

56. Vorgehensweise bei „Dienst startet nicht“

  1. Host, Dienstname und Zeitpunkt dokumentieren.
  2. systemctl status auswerten.
  3. systemctl show auf Ergebnis und Exit-Status prüfen.
  4. Dienstjournal seit dem letzten Startversuch lesen.
  5. erste relevante Fehlermeldung bestimmen.
  6. tatsächlich verwendete Unit und Drop-ins anzeigen.
  7. Startbenutzer und Gruppen prüfen.
  8. Anwendungskonfiguration mit dem vorgesehenen Syntaxprüfer testen.
  9. benötigte Dateien und Pfade prüfen.
  10. Unix-Rechte, ACL und alle Pfadbestandteile prüfen.
  11. SELinux- oder AppArmor-Ablehnungen prüfen.
  12. Portkonflikte prüfen.
  13. Mounts und externe Abhängigkeiten prüfen.
  14. Speicherplatz, Inodes, RAM und Limits kontrollieren.
  15. genau eine nachgewiesene Ursache korrigieren.
  16. Dienst kontrolliert starten.
  17. Journal, Prozess, Port und Anwendungsfunktion nachkontrollieren.
  18. Ursache, Maßnahme und Rückweg dokumentieren.

57. Vorgehensweise bei „Server ist langsam“

  1. Zeitraum und konkrete langsame Funktion erfassen.
  2. Vergleichswert oder normalen Zustand bestimmen.
  3. Load, CPU, RAM und Swap prüfen.
  4. Prozesse nach CPU- und Speicherverbrauch sortieren.
  5. Prozesszustände und blockierte Tasks prüfen.
  6. vmstat auswerten.
  7. I/O-Latenz und Datenträgerauslastung prüfen.
  8. Kernelmeldungen auf Storage- oder Treiberfehler untersuchen.
  9. Netzwerkfehler, Drops und Retransmissions berücksichtigen.
  10. DNS-Antwortzeiten prüfen.
  11. Anwendung und Backend getrennt testen.
  12. cgroup-, Container- oder Unit-Limits prüfen.
  13. geplante Jobs, Backups und Updates berücksichtigen.
  14. Engpass anhand von Messwerten nachweisen.
  15. eine kontrollierte Maßnahme durchführen.
  16. dieselbe Funktion mit denselben Messwerten erneut testen.

58. Vorgehensweise bei „Kein Speicherplatz“

  1. betroffenen Pfad dokumentieren.
  2. zugehöriges Dateisystem mit findmnt -T bestimmen.
  3. Speicherplatz mit df -hT prüfen.
  4. Inodes mit df -ih prüfen.
  5. Quotas und Storage-Limits berücksichtigen.
  6. Verzeichnisgrößen innerhalb desselben Dateisystems untersuchen.
  7. gelöschte offene Dateien mit lsof +L1 prüfen.
  8. Logs, Caches, temporäre Dateien und Containerdaten unterscheiden.
  9. LVM-Thin-Pool oder Snapshotbereich prüfen.
  10. Ursache des Wachstums bestimmen.
  11. Aufbewahrungs- und Löschregeln prüfen.
  12. keine unbekannten Dateien pauschal löschen.
  13. eine kontrollierte Bereinigung oder Erweiterung durchführen.
  14. Anwendung und Speicherzustand erneut prüfen.
  15. Präventionsmaßnahme wie Rotation, Monitoring oder Quota dokumentieren.

59. Vorgehensweise bei „Dateisystem oder Mount nicht verfügbar“

  1. betroffenen Mountpoint dokumentieren.
  2. findmnt und lsblk -f auswerten.
  3. Blockgerät, UUID und Dateisystemtyp bestimmen.
  4. /etc/fstab prüfen.
  5. findmnt --verify ausführen.
  6. systemd-Mount-Unit und Journal prüfen.
  7. Kernelmeldungen auf I/O-Fehler untersuchen.
  8. bei Netzwerk-Mounts DNS, Route, Port und Server prüfen.
  9. offene Prozesse und Abhängigkeiten berücksichtigen.
  10. Storage-, RAID-, LVM- oder Multipath-Zustand prüfen.
  11. Backup und Wartungsfenster klären.
  12. nur die nachgewiesene Ursache korrigieren.
  13. Mount kontrolliert herstellen.
  14. Lese- und Schreibfunktion entsprechend dem Sollzustand testen.
  15. Neustartverhalten gesondert verifizieren.

60. Maßnahmen und Rückwege

Ursache: Syntaxfehler in der Dienstkonfiguration

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falsche Dateiberechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falscher SELinux-Kontext

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: Portkonflikt

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: gelöschte offene Logdatei belegt Speicher

Nachweis:

Maßnahme:

Rollback:

Verifikation:

61. Nachkontrolle

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

62. Dokumentationsbeispiel

Symptom:
Der Dienst example-api ließ sich nach einem Konfigurationsupdate nicht mehr
starten. Clients erhielten „Connection refused“ auf TCP-Port 8443.

Zeitpunkt:
02.08.2026, 11:42 Uhr MESZ

Server:
linux-app-01.example.local

Dienst:
example-api.service

Nachweis:
systemctl status zeigte den Zustand „failed“.
Im Journal war unmittelbar nach dem Startversuch ein Berechtigungsfehler für
/etc/example-api/server.key dokumentiert.
Der Dienst lief als Benutzer example-api.
Ein kontrollierter Lesetest als example-api schlug fehl.
Die übergeordneten Verzeichnisse waren zugänglich.
Es gab keine passende SELinux- oder AppArmor-Ablehnung.
Die Schlüsseldatei war nach dem Austausch irrtümlich root:root mit Modus 0600
zugeordnet worden.

Ursache:
Die neue private Schlüsseldatei besaß nicht den vorgesehenen Gruppeneigentümer.
Der Dienstbenutzer konnte sie deshalb nicht lesen.

Maßnahme:
Nach Dokumentation des Ausgangszustands wurde die Datei der vorgesehenen
Dienstgruppe zugeordnet. Der Modus blieb auf das erforderliche Minimum
beschränkt.

Rollback:
Der ursprüngliche Eigentümer und die ursprüngliche Gruppe wurden dokumentiert
und können wiederhergestellt werden.

Verifikation:
Der Konfigurationstest war erfolgreich.
Der Dienst startete ohne neue Fehlermeldung.
TCP-Port 8443 wurde durch den vorgesehenen Prozess geöffnet.
Die lokale und externe HTTPS-Prüfung waren erfolgreich.
Der private Schlüssel ist weiterhin nicht für andere Benutzer lesbar.

Prävention:
Der Zertifikatsaustausch wird künftig durch einen dokumentierten Ablauf mit
Kontrolle von Eigentümer, Gruppe, Modus, Sicherheitskontext und anschließendem
Konfigurationstest durchgeführt.

63. Entscheidungsbaum

Linux-Dienst oder Anwendung gestört
        ↓
Ist das System erreichbar und die Zeit plausibel?
        ├── Nein
        │   ↓
        │   Boot, Netzwerk, Routing, DNS und Zeit prüfen
        │
        └── Ja
            ↓
Ist die Unit aktiv?
        ├── Nein
        │   ↓
        │   Status, Exit-Code und Dienstjournal prüfen
        │
        └── Ja
            ↓
Läuft der erwartete Prozess unter der richtigen Identität?
        ├── Nein
        │   ↓
        │   Unit, Drop-ins, Benutzer und Startmethode prüfen
        │
        └── Ja
            ↓
Lauscht die Anwendung auf der vorgesehenen Adresse und dem Port?
        ├── Nein
        │   ↓
        │   Konfiguration, Portkonflikt und Socket-Aktivierung prüfen
        │
        └── Ja
            ↓
Funktioniert die Anwendung lokal?
        ├── Nein
        │   ↓
        │   Anwendung, Backend, Rechte, Mounts und Ressourcen prüfen
        │
        └── Ja
            ↓
Funktioniert der Zugriff über das Netzwerk?
        ├── Nein
        │   ↓
        │   Bind-Adresse, Firewall, Route, DNS und Paketfluss prüfen
        │
        └── Ja
            ↓
Benutzerfunktion, Lastverhalten und abhängige Systeme prüfen

64. Typische Prüfungsfragen

Warum reicht der Zustand active eines systemd-Dienstes nicht als vollständiger Funktionsnachweis?

Antwort anzeigen

Der Zustand zeigt, dass systemd die Unit als aktiv betrachtet. Er beweist nicht, dass die Anwendung auf dem richtigen Port lauscht, ihre Backends erreicht oder korrekte Antworten auf Benutzeranfragen liefert.

Worin unterscheiden sich enabled und active?

Antwort anzeigen

enabled beschreibt die Einbindung für einen automatischen Start. active beschreibt den aktuellen Laufzeitzustand. Ein Dienst kann aktiv und gleichzeitig nicht aktiviert sein oder aktiviert, aber aktuell fehlgeschlagen sein.

Warum sollte zuerst SIGTERM und nicht sofort SIGKILL verwendet werden?

Antwort anzeigen

SIGTERM ermöglicht dem Prozess eine kontrollierte Beendigung, beispielsweise das Schreiben von Daten und Schließen von Dateien. SIGKILL kann nicht behandelt werden und verhindert eine geordnete Bereinigung.

Warum können df und du unterschiedliche Speicherbelegungen anzeigen?

Antwort anzeigen

Eine häufige Ursache sind gelöschte Dateien, die von einem laufenden Prozess weiterhin geöffnet gehalten werden. du findet sie nicht mehr im Verzeichnisbaum, während das Dateisystem den belegten Speicher weiterhin berücksichtigt.

Warum kann ein Dateisystem trotz freiem Speicherplatz keine neue Datei aufnehmen?

Antwort anzeigen

Die verfügbaren Inodes können erschöpft sein. In diesem Fall ist noch Datenkapazität frei, aber es können keine weiteren Dateisystemobjekte angelegt werden.

Warum beweist ein erfolgreicher manueller Skriptstart nicht, dass ein Cronjob funktioniert?

Antwort anzeigen

Cron verwendet häufig eine reduzierte Umgebung, einen anderen Benutzer, ein anderes Arbeitsverzeichnis und eine eingeschränkte PATH-Variable. Das Skript kann deshalb manuell funktionieren und automatisch scheitern.

Warum sollte SELinux nicht pauschal deaktiviert werden?

Antwort anzeigen

Dadurch wird eine wichtige Sicherheitsschicht für das gesamte System entfernt, ohne die eigentliche Ursache zu beheben. Stattdessen müssen Ablehnung, Pfad, Dateikontext und notwendige Mindestberechtigung untersucht werden.

Was bedeutet ein Prozess im Zustand D?

Antwort anzeigen

Der Prozess befindet sich in einem nicht unterbrechbaren Schlafzustand und wartet häufig auf eine I/O- oder Kerneloperation. Die zugrunde liegende Storage-, Mount- oder Treiberstörung muss untersucht werden.

Warum kann ein fehlender Mount zu Daten am falschen Ort führen?

Antwort anzeigen

Wenn der vorgesehene Mount fehlt, bleibt das lokale Mountpoint-Verzeichnis sichtbar. Eine Anwendung kann dann unbemerkt in das lokale Root-Dateisystem statt auf das vorgesehene Volume schreiben.

65. Prüfungsfallen

66. Checkliste

67. Schnellreferenz

Beobachtung Nächstes Werkzeug
Betriebssystemversion unklar cat /etc/os-release
Kernelversion unklar uname -r
Systemzustand unklar systemctl is-system-running
fehlgeschlagene Units gesucht systemctl --failed
Dienststatus unklar systemctl status
Exit-Code unklar systemctl show
Dienstprotokoll gesucht journalctl -u
vorheriger Boot relevant journalctl -b -1
tatsächliche Unit unklar systemctl cat
Drop-ins vermutet systemctl show -p DropInPaths
Unit-Syntax unklar systemd-analyze verify
Prozess gesucht pgrep -a, ps
Prozessbaum benötigt pstree -ap
offene Datei unklar lsof, fuser
gelöschte Datei belegt Speicher lsof +L1
Dienstbenutzer unklar systemctl show -p User -p Group
Benutzergruppen unklar id, getent
Pfadberechtigung unklar namei -l, stat
ACL unklar getfacl
SELinux-Status unklar getenforce, sestatus
SELinux-Ablehnung vermutet ausearch
AppArmor-Ablehnung vermutet aa-status, Kerneljournal
Listener unklar ss -ltnp
Portkonflikt vermutet ss, lsof
lokale HTTP-Funktion unklar curl -v
TLS-Fehler openssl s_client
IP-Konfiguration unklar ip -br address
Route unklar ip route get
DNS-Auflösung unklar getent hosts, dig
Firewallzustand unklar firewall-cmd, nft
Paketfluss unklar tcpdump
CPU-Last unklar top, mpstat, pidstat
RAM unklar free -h, vmstat
OOM vermutet journalctl -k
Swap unklar swapon --show, vmstat
Speicherplatz unklar df -hT
Verzeichnisgröße unklar du -xhd1
Inodes unklar df -ih
Mount unklar findmnt
Blockgerät unklar lsblk -f
fstab fehlerhaft vermutet findmnt --verify
I/O-Fehler vermutet Kerneljournal, iostat
LVM-Zustand unklar pvs, vgs, lvs
Software-RAID unklar /proc/mdstat, mdadm --detail
Paketdatei verändert rpm -V, debsums
Cronjob unklar Crontab und Cronjournal
systemd-Timer unklar systemctl list-timers --all
Zeitsynchronisation unklar timedatectl, chronyc
Boot langsam systemd-analyze critical-chain
Systemaufruf scheitert strace

Merksatz

Auf einem Linux-Server wird vom objektiven Symptom über Unit, Prozess, Protokoll, Identität, Port und Abhängigkeiten bis zu Berechtigungen, Sicherheitsrichtlinien, Ressourcen, Mounts und Kernel geprüft. Ein Dienst wird erst verändert oder neu gestartet, wenn der Fehlerzustand gesichert, die Auswirkung bewertet und ein Rückweg festgelegt wurde. active, ein offener Port und ein erfolgreicher lokaler Test sind jeweils nur Teilnachweise – entscheidend ist die ursprüngliche Benutzerfunktion.

Quellen und weiterführende Dokumentation

Offizielle systemd-Dokumentation

Offizielle Linux-Kernel-Dokumentation

Offizielle Red-Hat-Dokumentation

Offizielle Ubuntu-Dokumentation

Linux-Handbuchseiten

8.5 macOS – Prozesse, Dienste, Protokolle, Ressourcen und Speicher analysieren

Diese Seite beschreibt die systematische Fehleranalyse auf macOS. Im Mittelpunkt stehen Prozesse, launchd-Dienste, Protokolle, CPU, Arbeitsspeicher, APFS-Datenträger, Dateiberechtigungen, Datenschutzfreigaben und Startprobleme.

8.5.1 Ziel und Abgrenzung

Nach dieser Seite soll beurteilt werden können:

Eine laufende App, ein vorhandener Prozess oder ein registrierter Dienst beweist noch nicht, dass die ursprüngliche Benutzerfunktion funktioniert.

8.5.2 Besonderheiten der macOS-Systemarchitektur

Für die Fehleranalyse sind insbesondere folgende Komponenten wichtig:

Komponente Aufgabe Bedeutung für die Diagnose
Kernel Verwaltet Hardware, Speicher, Prozesse und Systemressourcen Kernel-Panics, Treiber- oder Hardwareprobleme können das gesamte System betreffen
launchd Startet und verwaltet Dienste, Agents und XPC-Dienste Ein Dienst kann dauerhaft oder nur bei Bedarf gestartet werden
LaunchDaemon Systemweiter Hintergrunddienst Wird gewöhnlich im system-Bereich verwaltet
LaunchAgent Benutzerbezogener Hintergrunddienst Wird gewöhnlich im gui/<UID>-Bereich verwaltet
Unified Logging Zentrales Protokollsystem von macOS Wird über „Konsole“ oder den Befehl log ausgewertet
APFS Standarddateisystem moderner macOS-Systeme Container, Volumes, Snapshots und gemeinsam genutzter Speicher müssen unterschieden werden
TCC Datenschutz- und Zugriffssteuerung Kann Zugriffe trotz korrekter Unix-Berechtigungen verhindern
Systemerweiterungen Erweiterungen für Netzwerk, Sicherheit, Treiber und andere Funktionen Fehlerhafte Erweiterungen können systemweite Auswirkungen verursachen
Aktivitätsanzeige Grafische Prozess- und Ressourcenanalyse Zeigt CPU, Speicher, Energie, Datenträger und Netzwerkaktivität

launchd-Dienste können bedarfsgesteuert arbeiten. Ein registrierter Dienst ohne aktuelle PID ist deshalb nicht automatisch fehlerhaft.

8.5.3 Typische Symptome

8.5.4 Kennzeichnung der Befehle

Kennzeichnung Bedeutung
[LESEND] Liest Informationen aus und verändert normalerweise keine Konfiguration
[LIVE] Beobachtet laufende Ereignisse bis zum Abbruch
[PRIVILEGIERT] Benötigt möglicherweise sudo oder Administratorrechte
[BELASTEND] Kann CPU, Datenträger oder Protokollsystem zusätzlich belasten
[VERÄNDERND] Verändert einen Prozess, Dienst oder eine Systemeinstellung
[NEUSTART] Unterbricht laufende Sitzungen oder Funktionen

Vor verändernden Maßnahmen müssen Befund, Konfiguration und Rückweg dokumentiert werden.

8.5.5 Sicherheits- und Betriebswarnungen

Beispiel:

man launchctl
man log
man diskutil

8.5.6 Benötigte Informationen

Vor der Diagnose sollten mindestens folgende Angaben erfasst werden:

8.5.7 Systemzustand und Basisdaten sichern

Die folgenden Befehle sind lesend. Systeminformationen können Seriennummern und andere vertrauliche Daten enthalten und müssen vor einer Weitergabe geprüft werden.

date
sw_vers
uname -a
uname -m
uptime
who
last reboot | head -n 10
system_profiler SPHardwareDataType SPSoftwareDataType

Wichtige Fragen:

Die Installationshistorie kann ergänzend geprüft werden:

system_profiler SPInstallHistoryDataType

Die zeitliche Übereinstimmung zwischen einer Installation und dem Beginn der Störung ist ein Hinweis, aber noch kein Ursachenbeweis.

8.5.8 Ungefährliche Schnellprüfung

df -h
df -ih
diskutil list
vm_stat
sysctl vm.swapusage
ps -axo pid,ppid,user,state,%cpu,%mem,etime,command | head -n 30
log show --last 15m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Zusätzlich in der grafischen Oberfläche prüfen:

  1. „Aktivitätsanzeige“ öffnen.
  2. CPU, Speicher, Energie, Festplatte und Netzwerk kontrollieren.
  3. Nach ungewöhnlich belastenden oder nicht reagierenden Prozessen suchen.
  4. „Konsole“ öffnen und den Fehlerzeitraum untersuchen.
  5. Unter „Systemeinstellungen → Allgemein → Speicher“ den verfügbaren Speicher prüfen.
  6. Unter „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ auffällige Hintergrundobjekte erfassen.
  7. Unter „Datenschutz & Sicherheit“ prüfen, ob die betroffene App die tatsächlich benötigten Freigaben besitzt.

Noch keine Prozesse beenden, Dienste neu starten oder Dateien löschen.

8.5.9 Prozesse systematisch untersuchen

Prozesse können über die Aktivitätsanzeige oder das Terminal untersucht werden.

Alle Prozesse anzeigen:

ps -axo pid,ppid,user,state,%cpu,%mem,etime,command

Mehrere Messungen der aktiven Prozesse durchführen:

top -l 3 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Nach einem Prozess suchen:

pgrep -fl "BeispielApp"

Einen bestimmten Prozess untersuchen, wobei 1234 durch die tatsächliche PID ersetzt wird:

ps -p 1234 \
  -o pid,ppid,user,state,%cpu,%mem,etime,command

Geöffnete Dateien und Verbindungen des Prozesses anzeigen:

lsof -nP -p 1234 | head -n 100

Einen Prozess für zehn Sekunden analysieren:

sample 1234 10 -file "$HOME/Desktop/BeispielApp-sample.txt"

Alternativ kann in der Aktivitätsanzeige ein Prozess ausgewählt und über „Mehr → Prozess analysieren“ untersucht werden.

Zu prüfen sind:

Ein hoher Messwert während eines kurzen Startvorgangs kann normal sein. Aussagekräftiger ist eine wiederholte oder dauerhaft hohe Auslastung im Fehlerzeitraum.

8.5.10 Prozesse kontrolliert beenden

Zuerst sollte die App regulär beendet werden. Reagiert sie nicht, kann die Aktivitätsanzeige verwendet werden.

Ein Prozess kann im Terminal zunächst mit SIGTERM zum geordneten Beenden aufgefordert werden:

kill -TERM 1234

Kennzeichnung: [VERÄNDERND]

Risiken:

SIGKILL beziehungsweise kill -9 beendet einen Prozess ohne geordnetes Aufräumen und ist nur die letzte Eskalationsstufe:

kill -KILL 1234

Kennzeichnung: [VERÄNDERND] [HOHES RISIKO]

Vorher müssen PID, Prozessname, Benutzer und Auswirkungen eindeutig geprüft werden.

8.5.11 Dienste und Agents mit launchd analysieren

Systemweite Dienste und benutzerbezogene Agents liegen in unterschiedlichen launchd-Bereichen.

Bereich Typische Verwendung
system Systemweite Daemons
user/<UID> Benutzerbereich ohne zwingenden Bezug zur grafischen Anmeldung
gui/<UID> Grafische Anmeldesitzung eines Benutzers

Systembereich anzeigen:

launchctl print system

Bereich des aktuell angemeldeten Benutzers anzeigen:

launchctl print gui/$(id -u)

Einen konkreten systemweiten Dienst prüfen:

launchctl print system/com.example.service

Einen konkreten Benutzer-Agent prüfen:

launchctl print gui/$(id -u)/com.example.agent

Deaktivierungszustände anzeigen:

launchctl print-disabled system
launchctl print-disabled gui/$(id -u)

Typische Speicherorte:

~/Library/LaunchAgents
/Library/LaunchAgents
/Library/LaunchDaemons
/System/Library/LaunchAgents
/System/Library/LaunchDaemons

Eine Drittanbieter-Property-List syntaktisch prüfen:

plutil -lint "/Library/LaunchDaemons/com.example.service.plist"

Zu untersuchen sind:

Ein nicht laufender On-Demand-Dienst kann sich im Normalzustand befinden. Entscheidend ist, ob der vorgesehene Auslöser den Dienst startet und die Benutzerfunktion anschließend funktioniert.

8.5.12 Dienst kontrolliert neu starten

Ein eindeutig identifizierter Drittanbieterdienst kann zu Diagnosezwecken neu gestartet werden.

Systemweiter Dienst:

sudo launchctl kickstart -k system/com.example.service

Benutzer-Agent:

launchctl kickstart -k gui/$(id -u)/com.example.agent

Kennzeichnung: [VERÄNDERND]

Vorher dokumentieren:

Ein erfolgreicher Neustart beweist nur, dass der Dienst erneut gestartet werden konnte. Danach muss die ursprüngliche Funktion getestet werden.

8.5.13 Unified Logging und Konsole

Die App „Konsole“ und der Befehl log greifen auf das zentrale macOS-Protokollsystem zu.

Fehler und Fault-Meldungen der letzten 30 Minuten:

log show --last 30m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Meldungen eines bestimmten Prozesses:

log show --last 30m --style compact \
  --predicate 'process == "BeispielApp"'

Bestimmten Zeitraum untersuchen:

log show \
  --start "2026-08-02 13:00:00" \
  --end "2026-08-02 13:30:00" \
  --style compact

Protokollmeldungen live verfolgen:

log stream --style compact --level info \
  --predicate 'process == "BeispielApp"'

Kennzeichnung: [LIVE]

Die Live-Ausgabe wird mit Ctrl-C beendet.

Ein Protokollarchiv der letzten 30 Minuten erstellen:

sudo log collect --last 30m \
  --output "$HOME/Desktop/macOS-30m.logarchive"

Kennzeichnung: [PRIVILEGIERT] [DATENSCHUTZRELEVANT]

Bei der Auswertung beachten:

8.5.14 Absturz-, Spin- und Diagnoseberichte

Die App „Konsole“ zeigt unter anderem:

Benutzerbezogene Diagnoseberichte können zusätzlich in folgendem Verzeichnis liegen:

ls -lt "$HOME/Library/Logs/DiagnosticReports" | head -n 20

Systemweite Diagnoseberichte:

sudo ls -lt "/Library/Logs/DiagnosticReports" | head -n 20

Wichtige Inhalte eines Absturzberichts:

Ein einzelner Absturzbericht beweist nicht automatisch einen dauerhaften Defekt. Entscheidend sind Reproduzierbarkeit, Häufigkeit und Übereinstimmung mit der beobachteten Störung.

8.5.15 CPU-Auslastung analysieren

Grafisch:

  1. Aktivitätsanzeige öffnen.
  2. Bereich „CPU“ auswählen.
  3. Nach % CPU sortieren.
  4. Messung während der Störung beobachten.
  5. Prozess analysieren oder Spindump erstellen.

Im Terminal:

top -l 5 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Mögliche Befunde:

Befund Mögliche Bedeutung
Ein Prozess dauerhaft stark ausgelastet Endlosschleife, fehlerhafte Verarbeitung oder außergewöhnliche Arbeitslast
Viele Prozesse gleichzeitig ausgelastet Systemweite Last, Indizierung, Update oder konkurrierende Aufgaben
Hohe CPU mit normaler Benutzerfunktion Möglicherweise erwartete Verarbeitung
Niedrige CPU bei langsamer App Warten auf Datenträger, Netzwerk, Sperre oder externen Dienst
App reagiert nicht und CPU ist nahezu null Blockierter Thread oder Warten auf eine Ressource
Wiederkehrende kurze Lastspitzen Regelmäßiger Agent, Synchronisation oder geplanter Hintergrundprozess

Die CPU-Auslastung muss immer zusammen mit Prozesszustand, Benutzerfunktion, Protokollen und I/O-Aktivität bewertet werden.

8.5.16 Arbeitsspeicher analysieren

Apple empfiehlt, den Speicherdruck und nicht nur den freien Arbeitsspeicher zu bewerten.

Grafisch:

  1. Aktivitätsanzeige öffnen.
  2. Bereich „Speicher“ auswählen.
  3. Speicherdruck beobachten.
  4. Speicher, komprimierten Speicher und Swap-Nutzung prüfen.
  5. Nach Speicherverbrauch sortieren.

Terminalprüfung:

vm_stat
sysctl vm.swapusage

Mehrere Messungen im Abstand von zwei Sekunden:

vm_stat -c 5 2

Wichtige Werte:

Interpretation:

Befund Bewertung
Speicherdruck Grün Speicherverwaltung arbeitet derzeit ausreichend
Speicherdruck Gelb Ressourcen werden knapp; Verlauf und verursachende Prozesse prüfen
Speicherdruck Rot Akuter Speicherengpass wahrscheinlich
Hohe Komprimierung ohne Störung Kann normal sein
Wachsende Swap-Nutzung und Leistungseinbruch Speicherengpass oder übermäßiger Prozessverbrauch möglich
Einzelner Prozess wächst kontinuierlich Mögliches Speicherleck
Hohe historische Swap-Zahl ohne aktuelle Änderung Kein ausreichender Ursachenbeweis

Ein einmaliger Gesamtwert ist weniger aussagekräftig als die Veränderung während des reproduzierten Fehlers.

8.5.17 Datenträger, APFS und Speicherplatz analysieren

Dateisystembelegung:

df -h
df -h /System/Volumes/Data
df -ih

Datenträgerstruktur:

diskutil list
diskutil info /
diskutil apfs list

Lokale Time-Machine-Snapshots anzeigen:

tmutil listlocalsnapshots /

Speicherbelegung im Benutzerordner untersuchen:

du -x -h -d 1 "$HOME" 2>/dev/null | sort -h

Datenträgeraktivität beobachten:

iostat -w 2 -c 5

Dateisystem oder Datenträger-I/O für 15 Sekunden verfolgen:

sudo fs_usage -w -f diskio -t 15

Kennzeichnung: [PRIVILEGIERT] [LIVE] [BELASTEND] [DATENSCHUTZRELEVANT]

Ein Volume prüfen:

diskutil verifyVolume /

Kennzeichnung: [PRÜFEND] [POTENZIELL BELASTEND]

Bei APFS beachten:

Für Reparaturen sollte das Festplattendienstprogramm verwendet werden. Apple empfiehlt, „Erste Hilfe“ zuerst für die Volumes, anschließend für die Container und zuletzt für das physische Speichergerät auszuführen. Bei Problemen mit dem Startvolume kann die macOS-Wiederherstellung erforderlich sein.

8.5.18 Dateiberechtigungen, ACLs und erweiterte Attribute

Identität des aktuellen Benutzers prüfen:

id
groups

Datei oder Ordner untersuchen:

ls -ldeO@ "/Pfad/zum/Ordner"
stat -x "/Pfad/zum/Ordner"

Dabei werden unter anderem sichtbar:

Zu prüfen ist der gesamte benötigte Pfad. Schreibrechte auf eine Datei reichen beispielsweise nicht aus, wenn ein übergeordneter Ordner nicht betreten oder verändert werden darf.

Berechtigungen dürfen nicht pauschal mit chmod -R 777 geöffnet werden. Dadurch entstehen Sicherheitsprobleme, und bestehende ACLs oder Eigentümerfehler werden nicht zuverlässig behoben.

8.5.19 Datenschutzfreigaben und TCC

macOS schützt bestimmte Daten und Geräte zusätzlich zu den Unix-Berechtigungen.

Mögliche Freigaben sind unter anderem:

Ein Zugriff kann deshalb fehlschlagen, obwohl ls -l korrekte Unix-Berechtigungen anzeigt.

Prüfung:

  1. „Systemeinstellungen → Datenschutz & Sicherheit“ öffnen.
  2. Nur die für die App tatsächlich benötigte Kategorie auswählen.
  3. Prüfen, ob die richtige App oder das richtige Terminalprogramm eingetragen ist.
  4. Nach einer Änderung die betroffene App gegebenenfalls vollständig beenden und neu starten.
  5. Funktion erneut testen.

Festplattenvollzugriff sollte nicht pauschal vergeben werden. Die kleinste benötigte Freigabe ist vorzuziehen.

8.5.20 App-Signatur, Gatekeeper und Quarantäne prüfen

Eine App kann wegen einer beschädigten Signatur, einer nicht vertrauenswürdigen Herkunft oder einer unvollständigen Installation nicht starten.

Signatur einer Beispiel-App prüfen:

codesign --verify --deep --strict --verbose=2 \
  "/Applications/Beispiel.app"

Gatekeeper-Bewertung prüfen:

spctl --assess --type execute --verbose=4 \
  "/Applications/Beispiel.app"

Erweiterte Attribute anzeigen:

xattr -l "/Applications/Beispiel.app"

Diese Befehle sind lesend.

Ein negatives Ergebnis sollte durch eine unveränderte, signierte Installationsdatei des Herstellers behoben werden. Das Entfernen von Quarantäneattributen, das Ad-hoc-Signieren oder das Deaktivieren von Gatekeeper ist keine allgemeine Fehlerlösung.

8.5.21 Anmeldeobjekte, Hintergrunddienste und Erweiterungen

Grafische Prüfung:

  1. „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ öffnen.
  2. „Bei der Anmeldung öffnen“ erfassen.
  3. „Im Hintergrund erlauben“ erfassen.
  4. installierte Erweiterungen prüfen.
  5. unbekannte oder zeitlich zur Störung passende Drittanbieterkomponenten dokumentieren.

Systemerweiterungen anzeigen:

systemextensionsctl list

MDM-Registrierungsstatus prüfen:

profiles status -type enrollment

Sicherheitszustände können ergänzend gelesen werden:

fdesetup status
csrutil status
spctl --status

Diese Zustände dürfen nicht ohne begründete Anforderung verändert werden.

Wenn Anmeldeobjekte als Ursache vermutet werden:

  1. vollständige Liste sichern;
  2. verdächtige Drittanbieterobjekte kontrolliert deaktivieren;
  3. ab- und wieder anmelden oder neu starten;
  4. ursprüngliche Funktion testen;
  5. Objekte einzeln wieder aktivieren;
  6. den tatsächlich verursachenden Eintrag bestätigen.

8.5.22 Netzwerkabhängigkeiten kurz prüfen

Wenn eine App langsam ist oder einen Dienst nicht erreicht, muss zwischen lokalem Prozessproblem und externer Abhängigkeit unterschieden werden.

scutil --dns
route -n get default
netstat -rn
lsof -nP -iTCP -sTCP:LISTEN

Fragen:

Die ausführliche Netzwerkdiagnose erfolgt nach den Abläufen aus Kapitel 3.

8.5.23 Fehler auf Benutzer, System oder Hardware eingrenzen

Test Erkenntnis
Nur eine App betroffen App-Konfiguration, App-Daten oder Abhängigkeit wahrscheinlich
Mehrere Apps eines Benutzers betroffen Benutzerprofil, TCC, LaunchAgent oder Anmeldeobjekt möglich
Alle Benutzer betroffen Systemdienst, systemweite Konfiguration, Datenträger oder Hardware möglich
Fehler nur mit einem externen Gerät Gerät, Kabel, Adapter, Stromversorgung oder Treiber untersuchen
Fehler verschwindet nach App-Neustart Prozesszustand wahrscheinlich, Ursache aber noch nicht bewiesen
Fehler verschwindet nach Abmeldung Benutzerbezogener Agent oder Sitzungszustand möglich
Fehler verschwindet im sicheren Modus Drittanbietererweiterung, Anmeldeobjekt oder zusätzlich geladene Komponente möglich
Fehler bleibt im sicheren Modus bestehen Grundsystem, Benutzerdateien, Hardware oder weiterhin aktive Abhängigkeit untersuchen
Fehler tritt auch in der Wiederherstellung auf Hardware oder Datenträger wird wahrscheinlicher
Apple Diagnose meldet Referenzcode Hardwarebefund dokumentieren und nach Apple-Vorgabe weiterbearbeiten

8.5.24 Sicherer Modus

Der sichere Modus hilft zu prüfen, ob beim normalen Start zusätzlich geladene Software beteiligt ist.

Mac mit Apple-Chip:

  1. Mac vollständig ausschalten.
  2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  3. Startvolume auswählen.
  4. Umschalttaste gedrückt halten.
  5. „Im gesicherten Modus fortfahren“ auswählen.

Intel-Mac:

  1. Mac einschalten oder neu starten.
  2. Sofort die Umschalttaste gedrückt halten.
  3. Taste loslassen, wenn das Anmeldefenster erscheint.

Der sichere Modus ist ein Kreuztest. Wenn der Fehler dort nicht auftritt, ist damit noch keine einzelne Ursache bewiesen. Anschließend müssen Anmeldeobjekte, Agents, Erweiterungen und Drittanbietersoftware einzeln geprüft werden.

Ein normaler Neustart beendet den sicheren Modus.

8.5.25 Apple Diagnose und Wiederherstellung

Apple Diagnose prüft Hardwarekomponenten.

Mac mit Apple-Chip:

  1. Mac ausschalten.
  2. Nicht benötigte externe Geräte trennen.
  3. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
  4. Befehlstaste und D gedrückt halten, bis der Mac neu startet.
  5. Diagnoseanweisungen befolgen.
  6. angezeigte Referenzcodes dokumentieren.

Intel-Mac:

  1. Mac einschalten.
  2. Sofort D gedrückt halten.
  3. Falls erforderlich, beim Start Option-D verwenden.
  4. Diagnoseanweisungen befolgen.
  5. Referenzcodes dokumentieren.

Die macOS-Wiederherstellung wird benötigt, wenn beispielsweise das Startvolume nicht im laufenden System repariert werden kann.

Eine erfolgreiche Apple Diagnose schließt nicht jede denkbare Hardwarestörung aus. Sporadische Fehler, Kabelprobleme oder externe Geräte müssen weiterhin durch Kreuztests untersucht werden.

8.5.26 Systematischer Diagnoseablauf

  1. Störung aufnehmen
    Benutzer, App, Funktion, Zeitpunkt, Häufigkeit und genaue Meldung erfassen.

  2. Umfang bestimmen
    Eine App, ein Benutzer, alle Benutzer oder der gesamte Mac?

  3. Basiszustand sichern
    macOS-Version, Build, Architektur, Laufzeit, Installationshistorie und Speicherplatz dokumentieren.

  4. Fehler reproduzieren
    Zeitpunkt notieren und nur den erforderlichen Ablauf ausführen.

  5. Prozess prüfen
    Existenz, Benutzer, Elternprozess, Zustand, CPU, Speicher und offene Dateien untersuchen.

  6. Dienstzuordnung prüfen
    Richtiges launchd-Label und richtigen Bereich bestimmen.

  7. Protokolle korrelieren
    Meldungen unmittelbar vor, während und nach dem Fehler auswerten.

  8. Ressourcen untersuchen
    CPU, Speicherdruck, Swap, Datenträgerbelegung und I/O messen.

  9. Zugriff prüfen
    Unix-Berechtigungen, ACLs, TCC-Freigaben und App-Signatur unterscheiden.

  10. Abhängigkeiten prüfen
    Netzwerk, DNS, Server, API, Freigabe, Cloud-Dienst oder externes Gerät kontrollieren.

  11. Fehlerdomäne isolieren
    Anderer Benutzer, sicherer Modus, getrennte Peripherie oder Wiederherstellung verwenden.

  12. Hypothese formulieren
    Erwartetes Prüfergebnis und Gegenbeweis festlegen.

  13. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Messkriterium dokumentieren.

  14. Ursprüngliche Funktion verifizieren
    Nicht nur den Prozessstatus, sondern den realen Benutzerablauf testen.

  15. Nachkontrolle durchführen
    Protokolle und Ressourcen erneut prüfen sowie Rückfall ausschließen.

8.5.27 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
App-Prozess fehlt App wurde nicht gestartet oder beendet sich sofort Absturzbericht und zeitlich passende Logs prüfen
Prozess läuft, App reagiert nicht Thread blockiert oder wartet auf Ressource Prozessanalyse oder Spindump erstellen
Dienstlabel im system-Bereich nicht gefunden Falsches Label, falscher Bereich oder Dienst nicht geladen Property-List und tatsächliches Label prüfen
Agent fehlt im gui/<UID>-Bereich Falscher Benutzer oder keine grafische Sitzung UID und Anmeldesitzung prüfen
Dienst besitzt keine PID On-Demand-Zustand oder Startfehler Auslöser betätigen und Logs beobachten
Hohe CPU bei einem Prozess Schleife, hohe Last oder fehlerhafte Verarbeitung Mehrfach messen und Prozess analysieren
Niedrige CPU, App trotzdem langsam Warten auf I/O, Netzwerk oder Sperre fs_usage, Netzwerk und Prozessanalyse
Speicherdruck Gelb oder Rot Speicherengpass Speicherverbrauch und zeitliche Entwicklung prüfen
Swap wächst während der Störung Arbeitsspeicher reicht für aktuelle Last nicht aus verursachende Prozesse bestimmen
Startvolume fast voll Apps, Updates, Logs und Swap beeinträchtigt große Verzeichnisse und Snapshots prüfen
Viele lokale Snapshots Speicher wird durch Snapshots mitbelegt Time-Machine-Zustand und Richtlinie prüfen
Unix-Rechte korrekt, Zugriff trotzdem verweigert TCC- oder Sandbox-Einschränkung Datenschutzfreigabe der richtigen App prüfen
Signaturprüfung schlägt fehl App beschädigt oder verändert Originaldatei des Herstellers vergleichen
Nur ein Benutzer betroffen Benutzerprofil, LaunchAgent oder TCC anderes Benutzerkonto als Kreuztest
Fehler verschwindet im sicheren Modus zusätzliche Software beteiligt Drittanbieterkomponenten einzeln prüfen
Kernel-Panics treten wiederholt auf Treiber-, Erweiterungs- oder Hardwareproblem Panic-Berichte, Peripherietest und Apple Diagnose
Prozess und Port sind vorhanden, Funktion scheitert Abhängigkeit oder Anwendungsebene fehlerhaft vollständigen Benutzerpfad Ende zu Ende prüfen

8.5.28 Mögliche Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
Fehlerhafte App-Konfiguration Fehler ist mit gesicherter Standardkonfiguration reproduzierbar beziehungsweise verschwindet kontrolliert ohne diese Konfiguration
Beschädigte App-Installation Signatur- oder Integritätsprüfung schlägt fehl und eine unveränderte Herstellerinstallation funktioniert
Fehlerhafter LaunchAgent Fehler tritt nur im zugehörigen Benutzerkontext auf und verschwindet nach kontrollierter Deaktivierung
Fehlerhafter LaunchDaemon Systemweiter Fehler korreliert mit Dienststatus, Logs und reproduzierbarem Neustartverhalten
CPU-Engpass CPU ist während der Störung dauerhaft ausgelastet und der verursachende Prozess ist bestimmt
Speicherengpass Speicherdruck und Swap wachsen während der reproduzierten Störung
Voller Datenträger Freier Speicher ist kritisch niedrig und die Funktion arbeitet nach kontrollierter Freigabe wieder
APFS- oder Dateisystemfehler diskutil, Erste Hilfe oder Systemprotokolle melden konkrete Fehler
Berechtigungsfehler Zugriff scheitert mit konkretem Berechtigungsbefund und funktioniert nach minimaler Korrektur
TCC-Verweigerung Benötigte Datenschutzfreigabe fehlt und die Funktion arbeitet nach gezielter Freigabe
Netzwerkabhängigkeit Lokaler Prozess arbeitet, aber DNS, Verbindung oder Zielsystem scheitert reproduzierbar
Drittanbietererweiterung Fehler verschwindet im sicheren Modus und kehrt mit der einzeln aktivierten Erweiterung zurück
Hardwarefehler Apple Diagnose, wiederkehrende Panic-Berichte oder unabhängige Kreuztests belegen den Fehler

8.5.29 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg
App regulär beenden und neu öffnen Nicht gespeicherte Daten App erneut starten und gesicherte Daten öffnen
Prozess mit SIGTERM beenden Funktionsunterbrechung App oder Dienst kontrolliert neu starten
Drittanbieterdienst mit kickstart neu starten Kurzzeitiger Dienstausfall dokumentierten Ausgangszustand und Konfiguration wiederherstellen
Anmeldeobjekt vorübergehend deaktivieren Funktion steht nach Anmeldung nicht bereit Eintrag anhand der gesicherten Liste wieder aktivieren
TCC-Freigabe gezielt erteilen zusätzlicher Datenzugriff Freigabe nach Test wieder entziehen
Drittanbieter-App aktualisieren neue Version kann Konfiguration verändern Installationsdatei und Konfiguration der vorherigen Version sichern
App aus Originalquelle neu installieren lokale App-Bestandteile werden ersetzt Konfiguration und Benutzerdaten vorher sichern
Nicht benötigte Benutzerdaten verschieben Datei steht am alten Ort nicht mehr bereit Datei aus dem Sicherungsort zurückverschieben
Sicherer Modus eingeschränkte Funktionen normal neu starten
Erste Hilfe ausführen zusätzliche Datenträgerbelastung aktuelles Backup bereithalten; bei Fehler abbrechen und Befund sichern
Peripheriegerät trennen zugehörige Funktion steht nicht bereit Gerät nach Test wieder anschließen

Pro Maßnahme darf möglichst nur eine relevante Variable verändert werden.

8.5.30 Verifikation

Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen:

8.5.31 Präventionsmaßnahmen

8.5.32 Typische Fehler bei der Diagnose

8.5.33 Typische Prüfungsfragen

Warum beweist ein laufender Prozess noch keine funktionierende Anwendung?

Der Prozess kann blockiert sein, auf eine Ressource warten oder eine benötigte Abhängigkeit nicht erreichen. Entscheidend ist die vollständige Benutzerfunktion.

Was ist der Unterschied zwischen einem LaunchDaemon und einem LaunchAgent?

Ein LaunchDaemon arbeitet systemweit. Ein LaunchAgent arbeitet im Kontext eines Benutzers beziehungsweise einer Benutzeranmeldung.

Warum kann ein registrierter launchd-Dienst keine PID besitzen, ohne fehlerhaft zu sein?

Bedarfsgesteuerte Dienste werden möglicherweise erst gestartet, wenn ein definierter Auslöser eintritt.

Warum ist der Speicherdruck aussagekräftiger als nur der freie Arbeitsspeicher?

macOS nutzt freien Speicher unter anderem für Caches und Komprimierung. Der Speicherdruck zeigt besser, ob die Speicherverwaltung die aktuelle Last noch ausreichend bewältigt.

Warum sollte kill -9 nicht als erste Maßnahme verwendet werden?

Der Prozess erhält keine Möglichkeit, Dateien zu schließen, Daten zu speichern oder seinen Zustand geordnet zu bereinigen.

Warum können korrekte Unix-Berechtigungen trotzdem zu einer Zugriffsverweigerung führen?

Zusätzliche macOS-Schutzmechanismen wie TCC können den Zugriff auf Dateien, Geräte oder geschützte Daten verhindern.

Was bedeutet es, wenn ein Fehler im sicheren Modus nicht auftritt?

Zusätzlich geladene Software, Anmeldeobjekte oder Erweiterungen werden wahrscheinlicher. Eine konkrete Ursache ist dadurch noch nicht bewiesen.

Warum müssen Protokolle zeitlich mit der Störung korreliert werden?

Ein System erzeugt auch im Normalbetrieb Warnungen und Fehler. Erst die zeitliche und funktionale Übereinstimmung macht eine Meldung für den konkreten Vorfall relevant.

Warum ersetzt eine erfolgreiche Erste-Hilfe-Prüfung kein Backup?

Die Prüfung schützt nicht vor späterem Hardwareausfall, versehentlichem Löschen oder bereits beschädigten beziehungsweise fehlenden Benutzerdaten.

8.5.34 Checkliste

8.5.35 Schnellreferenz

Aufgabe Befehl oder Werkzeug
macOS-Version sw_vers
Prozessorarchitektur uname -m
Systemlaufzeit uptime
Hardware- und Softwarebericht system_profiler SPHardwareDataType SPSoftwareDataType
Prozesse ps -axo pid,ppid,user,state,%cpu,%mem,etime,command
Live-Ressourcen top oder Aktivitätsanzeige
Prozess suchen pgrep -fl "Prozessname"
offene Dateien eines Prozesses lsof -nP -p 1234
Prozess analysieren sample 1234 10 -file Bericht.txt
Systemweite launchd-Dienste launchctl print system
Benutzer-Agents launchctl print gui/$(id -u)
Property-List prüfen plutil -lint Datei.plist
letzte Protokolle log show --last 30m
Protokolle live log stream
Arbeitsspeicher vm_stat
Swap sysctl vm.swapusage
Speicherbelegung df -h
Datenträgerstruktur diskutil list
APFS-Struktur diskutil apfs list
lokale Snapshots tmutil listlocalsnapshots /
Datenträger-I/O iostat -w 2 -c 5
Dateiaktivität sudo fs_usage
Berechtigungen und ACLs ls -ldeO@ Pfad
Systemerweiterungen systemextensionsctl list
MDM-Status profiles status -type enrollment
App-Signatur codesign --verify
Gatekeeper-Bewertung spctl --assess
grafische Protokolle Konsole
CPU, Speicher und I/O Aktivitätsanzeige
Dateisystemprüfung Festplattendienstprogramm
Hardwareprüfung Apple Diagnose

8.5.36 Quellen

Offizielle Apple-Dokumentation

Befehlsreferenzen

Die maßgebliche Befehlsreferenz ist die jeweilige lokale macOS-Manpage:

man launchd
man launchctl
man log
man vm_stat
man diskutil
man fs_usage
man system_profiler

Der folgende Spiegel stellt aus Xcode extrahierte Manpages bereit, ist jedoch keine offizielle Apple-Supportseite. Bei Abweichungen gilt die lokale Manpage der installierten macOS-Version: