# 5. Werkzeuge der Fehleranalyse
# 5.1 Windows – Integrierte Werkzeuge zur Fehleranalyse
Windows stellt zahlreiche grafische Werkzeuge, Befehlszeilenprogramme und PowerShell-Cmdlets zur systematischen Fehleranalyse bereit. Damit lassen sich unter anderem Ereignisprotokolle, Prozesse, Dienste, Ressourcen, Datenträger, Netzwerkverbindungen, Systemdateien und Abstürze untersuchen.
Die Werkzeuge liefern jedoch zunächst nur Befunde. Einzelne Warnungen, hohe Messwerte oder Ereignis-IDs beweisen noch keine Ursache. Ergebnisse müssen immer mit Fehlerzeitpunkt, Symptomen, Änderungen und weiteren Datenquellen abgeglichen werden.
---
**Kennzeichnung der Befehle**
| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | Nur lesender Befehl |
| `[TEST]` | Führt einen aktiven Test aus |
| `[CHANGE]` | Kann den Systemzustand verändern |
| `[PRIV]` | Erfordert möglicherweise administrative Rechte |
| `[SENS]` | Ausgabe kann sensible Informationen enthalten |
| `[RESTART]` | Neustart oder Unterbrechung möglich |
> Befehle mit `[CHANGE]`, `[RESTART]` oder `[SENS]` müssen vor ihrer Verwendung besonders sorgfältig geprüft werden.
---
1. Diagnosewerkzeuge gezielt auswählen
| Fragestellung | Geeignetes Werkzeug |
|---|---|
| Was geschah zum Fehlerzeitpunkt? | Ereignisanzeige, `Get-WinEvent` |
| Welcher Prozess belastet das System? | Task-Manager, Ressourcenmonitor, `Get-Process` |
| Welcher Dienst läuft nicht? | Diensteverwaltung, `Get-Service`, `sc.exe` |
| Welches Programm öffnet einen Port? | Ressourcenmonitor, `Get-NetTCPConnection`, `netstat` |
| Funktioniert die Namensauflösung? | `Resolve-DnsName`, `nslookup` |
| Ist ein TCP-Port erreichbar? | `Test-NetConnection` |
| Welche Route nimmt ein Paket? | `tracert`, `pathping` |
| Ist ein Datenträger voll? | Explorer, Datenträgerverwaltung, `Get-Volume` |
| Sind Windows-Systemdateien beschädigt? | SFC und DISM |
| Warum wurde Windows neu gestartet? | Ereignisanzeige, `Get-WinEvent` |
| Welche Treiber und Geräte sind vorhanden? | Geräte-Manager, `Get-PnpDevice`, `driverquery` |
| Wie entwickelt sich die Leistung über Zeit? | Leistungsüberwachung, Datenkollektorsätze |
| Welche Änderungen gingen der Störung voraus? | Zuverlässigkeitsverlauf, Updateverlauf, Ereignisprotokolle |
| Warum ist Windows abgestürzt? | Speicherabbild, WinDbg, Ereignisprotokolle |
**Grundregel**
1. Symptom und Zeitpunkt festhalten.
2. Umfang der Störung bestimmen.
3. Ereignisprotokolle zum betreffenden Zeitraum prüfen.
4. Ressourcen und betroffene Komponenten untersuchen.
5. Abhängigkeiten kontrollieren.
6. Erst danach Änderungen durchführen.
7. Ergebnis und Rückfallmöglichkeit dokumentieren.
2. Windows-Version und Systeminformationen erfassen
**Windows-Versionsdialog öffnen**
```cmd
[RO] winver
```
**Systeminformationen anzeigen**
```cmd
[RO][SENS] systeminfo
```
Die Ausgabe kann unter anderem Computername, Betriebssystemversion, Installationsdatum, Arbeitsspeicher, Domänenzugehörigkeit und installierte Hotfixes enthalten.
**Windows-Version mit PowerShell**
```powershell
[RO] Get-ComputerInfo |
Select-Object WindowsProductName,
WindowsVersion,
OsBuildNumber,
OsArchitecture
```
**Betriebssystem über CIM abfragen**
```powershell
[RO] Get-CimInstance Win32_OperatingSystem |
Select-Object Caption,
Version,
BuildNumber,
OSArchitecture,
LastBootUpTime
```
**Computer- und Hardwareinformationen**
```powershell
[RO][SENS] Get-ComputerInfo
```
**Systeminformationen grafisch öffnen**
```cmd
[RO] msinfo32
```
`msinfo32` enthält eine umfassende Übersicht über Hardware, Komponenten, Treiber, Ressourcen und die Softwareumgebung.
> Systeminformationen können Computername, Benutzerbezug, Netzwerkdaten und installierte Software offenlegen. Exporte müssen vor einer Weitergabe geprüft werden.
3. Ereignisanzeige verwenden
**Ereignisanzeige öffnen**
```cmd
[RO] eventvwr.msc
```
**Wichtige Windows-Protokolle**
| Protokoll | Typische Inhalte |
|---|---|
| Anwendung | Ereignisse von Programmen und Anwendungsdiensten |
| Sicherheit | Anmeldungen, Zugriffsprüfungen und Sicherheitsereignisse |
| Setup | Installation und Einrichtung von Windows-Komponenten |
| System | Treiber, Dienste, Hardware und Betriebssystemkomponenten |
| Weitergeleitete Ereignisse | Von anderen Computern empfangene Ereignisse |
Unter **Anwendungs- und Dienstprotokolle** befinden sich zusätzliche komponentenspezifische Protokolle, beispielsweise für PowerShell, Windows Defender, DNS, Gruppenrichtlinien oder Remotedesktopdienste.
**Ereignisstufen**
| Stufe | Bedeutung |
|---|---|
| Kritisch | Schwerwiegendes Ereignis, häufig mit Ausfall oder unerwartetem Neustart |
| Fehler | Eine Funktion oder Operation ist fehlgeschlagen |
| Warnung | Mögliches Problem oder auffälliger Zustand |
| Information | Regulärer Vorgang oder Statusmeldung |
| Ausführlich | Besonders detaillierte Diagnoseinformation |
**Wichtige Bewertungsregeln**
- Nicht jeder Fehler im Protokoll verursacht die untersuchte Störung.
- Eine hohe Zahl von Warnungen bedeutet nicht automatisch ein schwerwiegendes Problem.
- Ereignis-ID und Quelle müssen gemeinsam betrachtet werden.
- Derselbe Ereigniscode kann bei unterschiedlichen Quellen etwas anderes bedeuten.
- Der Zeitstempel muss zur tatsächlichen Störung passen.
- Folgefehler dürfen nicht mit der ursprünglichen Ursache verwechselt werden.
- Ereignisse vor dem sichtbaren Fehler sind häufig besonders wichtig.
- Ein unerwarteter Neustart kann ältere Protokolle oder flüchtige Zustände verändern.
**Benutzerdefinierte Ansicht erstellen**
1. **Ereignisanzeige** öffnen.
2. **Benutzerdefinierte Ansichten** auswählen.
3. **Benutzerdefinierte Ansicht erstellen** öffnen.
4. Zeitraum und Ereignisstufen festlegen.
5. Benötigte Protokolle oder Quellen auswählen.
6. Filter speichern und Ergebnisse chronologisch untersuchen.
> Das bloße Löschen eines Ereignisprotokolls behebt keine Ursache und vernichtet möglicherweise wichtige Diagnoseinformationen.
4. Windows-Ereignisse mit PowerShell untersuchen
**Verfügbare klassische Protokolle anzeigen**
```powershell
[RO] Get-WinEvent -ListLog * |
Select-Object LogName, RecordCount, IsEnabled
```
**Letzte 50 Systemereignisse**
```powershell
[RO][SENS] Get-WinEvent -LogName System -MaxEvents 50
```
**Fehler und kritische Ereignisse der letzten 24 Stunden**
```powershell
[RO][SENS] Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 1, 2
StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message
```
**Ereignisse einer bestimmten Quelle**
```powershell
[RO][SENS] Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Service Control Manager'
StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message
```
**Bestimmte Ereignis-ID suchen**
```powershell
[RO][SENS] Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 6008
StartTime = (Get-Date).AddDays(-7)
}
```
**Ergebnisse exportieren**
```powershell
[RO][SENS] Get-WinEvent -LogName System -MaxEvents 500 |
Export-Csv -Path ".\systemereignisse.csv" -NoTypeInformation -Encoding UTF8
```
> Exportierte Ereignisse können Benutzernamen, Computerbezeichnungen, Pfade, IP-Adressen und Anwendungsdaten enthalten.
**Vorteil von `FilterHashtable`**
Die Filterung erfolgt bereits beim Abruf. Das ist bei großen Ereignisprotokollen meist effizienter, als zunächst alle Ereignisse einzulesen und sie anschließend mit `Where-Object` zu filtern.
5. Häufig relevante Windows-Ereignisse einordnen
| Ereignis-ID | Typische Quelle | Grundsätzliche Bedeutung |
|---|---|---|
| `41` | Kernel-Power | Windows wurde ohne reguläres Herunterfahren neu gestartet |
| `1074` | User32 | Ein Prozess oder Benutzer leitete Herunterfahren oder Neustart ein |
| `6005` | EventLog | Ereignisprotokolldienst wurde gestartet |
| `6006` | EventLog | Ereignisprotokolldienst wurde regulär beendet |
| `6008` | EventLog | Vorheriges Herunterfahren war unerwartet |
| `7031` | Service Control Manager | Ein Dienst wurde unerwartet beendet |
| `7034` | Service Control Manager | Ein Dienst wurde unerwartet beendet |
| `7040` | Service Control Manager | Starttyp eines Dienstes wurde geändert |
| `7045` | Service Control Manager | Ein Dienst wurde im System installiert |
> Die Ereignis-ID allein ist kein vollständiger Befund. Quelle, Meldung, Zeitpunkt, betroffene Komponente und benachbarte Ereignisse müssen zusätzlich ausgewertet werden.
Ein Ereignis `Kernel-Power 41` bestätigt beispielsweise, dass Windows zuvor nicht ordnungsgemäß heruntergefahren wurde. Es beweist jedoch nicht, ob Stromverlust, Hardwarefehler, Absturz, erzwungenes Ausschalten oder eine andere Ursache verantwortlich war.
6. Zuverlässigkeitsverlauf auswerten
**Zuverlässigkeitsüberwachung öffnen**
```cmd
[RO] perfmon /rel
```
Der Zuverlässigkeitsverlauf stellt wichtige Ereignisse nach Tagen geordnet dar. Dazu können gehören:
- Anwendungsabstürze
- Windows-Fehler
- fehlgeschlagene Updates
- Treiberinstallationen
- Softwareinstallationen
- erfolgreiche Updates
- Hardwarefehler
**Sinnvolle Vorgehensweise**
1. Tag und Uhrzeit der Störung auswählen.
2. Kritische Ereignisse untersuchen.
3. Gleichzeitig installierte Updates oder Anwendungen beachten.
4. Technische Details öffnen.
5. Befund mit Ereignisanzeige und Anwendungsprotokollen vergleichen.
> Der Stabilitätsindex ist eine verdichtete Kennzahl. Er beweist nicht, welche Komponente die Ursache einer Störung ist.
7. Task-Manager zur ersten Eingrenzung verwenden
**Task-Manager öffnen**
```cmd
[RO] taskmgr
```
**Wichtige Bereiche**
| Registerkarte | Verwendung |
|---|---|
| Prozesse | Momentane CPU-, RAM-, Datenträger-, Netzwerk- und GPU-Nutzung |
| Leistung | Gesamtauslastung und zeitliche Kurzansicht |
| App-Verlauf | Ressourcennutzung unterstützter Apps |
| Autostart-Apps | Programme beim Benutzerstart |
| Benutzer | Ressourcen nach angemeldeten Benutzern |
| Details | Prozesse mit PID, Status, Benutzer und weiteren Spalten |
| Dienste | Dienststatus und zugehörige Informationen |
**Bei hoher Auslastung prüfen**
- Ist die Auslastung dauerhaft oder nur kurzfristig?
- Welcher Prozess verursacht sie?
- Gehört der Prozess zu einer Anwendung oder einem Windows-Dienst?
- Steigt der Speicherverbrauch fortlaufend?
- Liegt die Datenträgeraktivität bei hoher Antwortzeit?
- Wird ein Prozess mehrfach ausgeführt?
- Ist die Auslastung Folge eines Updates, Scans oder Backups?
- Stimmt der Fehlerzeitpunkt mit der Auslastung überein?
> Das sofortige Beenden eines unbekannten Prozesses kann Datenverlust verursachen oder Systemfunktionen unterbrechen.
8. Prozesse mit PowerShell untersuchen
**Prozesse anzeigen**
```powershell
[RO][SENS] Get-Process
```
**Prozesse nach CPU-Zeit sortieren**
```powershell
[RO][SENS] Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 15 Name, Id, CPU, WorkingSet64
```
`CPU` enthält die bisher verbrauchte Prozessorzeit und nicht unmittelbar die aktuelle prozentuale CPU-Auslastung.
**Prozesse nach Arbeitsspeicher sortieren**
```powershell
[RO][SENS] Get-Process |
Sort-Object WorkingSet64 -Descending |
Select-Object -First 15 Name,
Id,
@{Name='RAM_MiB';Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}
```
**Bestimmten Prozess anzeigen**
```powershell
[RO][SENS] Get-Process -Id
```
**Prozessdetails über CIM**
```powershell
[RO][SENS] Get-CimInstance Win32_Process -Filter "ProcessId=" |
Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine
```
Die Befehlszeile kann Pfade, Benutzerdaten, Servernamen oder sogar ungeschützt übergebene Zugangsdaten enthalten.
**Prozess kontrolliert beenden**
```powershell
[CHANGE] Stop-Process -Id
```
**Erzwungenes Beenden**
```powershell
[CHANGE] Stop-Process -Id -Force
```
> `-Force` darf nicht als allgemeine Fehlerbehebung verwendet werden. Nicht gespeicherte Daten können verloren gehen und abhängige Komponenten können ausfallen.
9. Ressourcenmonitor verwenden
**Ressourcenmonitor öffnen**
```cmd
[RO] resmon
```
Der Ressourcenmonitor zeigt detaillierte Informationen zu:
- CPU
- Arbeitsspeicher
- Datenträgeraktivität
- Netzwerkaktivität
- TCP-Verbindungen
- lauschenden Ports
- Prozessen und zugehörigen Dateien
**Typische Anwendungsfälle**
- Prozess mit hoher Datenträgeraktivität bestimmen
- Datei mit vielen Zugriffen ermitteln
- Prozess hinter einer TCP-Verbindung identifizieren
- lauschenden Port einer Anwendung feststellen
- Hard Faults und Speichernutzung untersuchen
- Abhängigkeiten eines angehaltenen Prozesses betrachten
> Ein Hard Fault ist nicht automatisch ein Hardwarefehler. Er bezeichnet in diesem Zusammenhang einen Speicherzugriff, bei dem benötigte Daten nicht im physischen Arbeitsspeicher vorlagen und aus einer anderen Speicherquelle geladen werden mussten.
10. Leistungsüberwachung und Performance Counter
**Leistungsüberwachung öffnen**
```cmd
[RO] perfmon
```
Die Leistungsüberwachung kann Messwerte in Echtzeit anzeigen oder über Datenkollektorsätze längerfristig erfassen.
**Verfügbare Leistungsindikatoren mit PowerShell anzeigen**
```powershell
[RO] Get-Counter -ListSet *
```
**Einzelne Messung durchführen**
```powershell
[TEST] Get-Counter '\Processor(_Total)\% Processor Time'
```
**Mehrere Messwerte erfassen**
```powershell
[TEST] Get-Counter `
'\Processor(_Total)\% Processor Time',
'\Memory\Available MBytes',
'\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' `
-SampleInterval 2 `
-MaxSamples 10
```
**Wichtige Kategorien**
| Kategorie | Beispiele |
|---|---|
| Processor | Gesamtauslastung und Prozessorzeit |
| Memory | verfügbarer Speicher und Paging |
| PhysicalDisk | Warteschlangen, Übertragungen und Latenz |
| Network Interface | übertragene und verworfene Daten |
| Process | Werte einzelner Prozesse |
| System | Prozesse, Threads und Systemaktivität |
**Bewertungsregeln**
- Einzelmessungen bilden nur einen kurzen Zeitpunkt ab.
- Grenzwerte hängen von Arbeitslast, Hardware und Anwendung ab.
- Durchschnittswerte können kurze Lastspitzen verdecken.
- Eine hohe Warteschlange beweist ohne Latenz- und Durchsatzwerte noch keinen Datenträgerdefekt.
- Prozessinstanzen können sich bei einem Neustart oder mehreren gleichnamigen Prozessen ändern.
- Messung und Fehler müssen zeitlich zusammenpassen.
11. Dienste untersuchen
**Diensteverwaltung öffnen**
```cmd
[RO] services.msc
```
**Alle Dienste mit PowerShell anzeigen**
```powershell
[RO] Get-Service
```
**Beendete Dienste anzeigen**
```powershell
[RO] Get-Service |
Where-Object Status -eq 'Stopped'
```
Ein beendeter Dienst ist nicht automatisch fehlerhaft. Viele Dienste werden nur bei Bedarf gestartet.
**Bestimmten Dienst prüfen**
```powershell
[RO] Get-Service -Name ""
```
**Ausführlichere Dienstinformationen**
```powershell
[RO][SENS] Get-CimInstance Win32_Service -Filter "Name=''" |
Select-Object Name,
DisplayName,
State,
StartMode,
StartName,
PathName,
ProcessId
```
**Dienstkonfiguration mit `sc.exe`**
```cmd
[RO] sc.exe qc ""
```
**Dienstabhängigkeiten**
```powershell
[RO] Get-Service -Name "" -RequiredServices
```
**Abhängige Dienste**
```powershell
[RO] Get-Service -Name "" -DependentServices
```
**Dienst starten**
```powershell
[CHANGE][PRIV] Start-Service -Name ""
```
**Dienst neu starten**
```powershell
[CHANGE][PRIV][RESTART] Restart-Service -Name ""
```
> Vor einem Dienstneustart müssen abhängige Anwendungen, aktive Benutzer, Transaktionen und Auswirkungen auf andere Systeme geprüft werden.
12. Netzwerkgrundlagen erfassen
**Vollständige IP-Konfiguration**
```cmd
[RO][SENS] ipconfig /all
```
**PowerShell-Netzwerkkonfiguration**
```powershell
[RO][SENS] Get-NetIPConfiguration
```
**IP-Adressen anzeigen**
```powershell
[RO][SENS] Get-NetIPAddress
```
**Netzwerkadapter anzeigen**
```powershell
[RO] Get-NetAdapter |
Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress
```
**Routingtabelle anzeigen**
```cmd
[RO][SENS] route print
```
Alternativ:
```powershell
[RO][SENS] Get-NetRoute |
Sort-Object InterfaceIndex, DestinationPrefix
```
**DNS-Server anzeigen**
```powershell
[RO][SENS] Get-DnsClientServerAddress
```
**Wichtige Prüfwerte**
- erwartete IPv4- oder IPv6-Adresse
- Präfix beziehungsweise Subnetzmaske
- Standardgateway
- DNS-Server
- DHCP-Status
- Adapterstatus
- Verbindungsgeschwindigkeit
- unerwartete virtuelle Adapter
- VPN- oder Hypervisor-Routen
- APIPA-Adresse aus `169.254.0.0/16`
> Eine APIPA-Adresse kann darauf hinweisen, dass keine erwartete IPv4-Konfiguration per DHCP bezogen wurde. Sie beweist jedoch nicht allein, warum der DHCP-Vorgang scheiterte.
13. Erreichbarkeit und Netzwerkpfad testen
**Lokalen TCP/IP-Stack testen**
```cmd
[TEST] ping 127.0.0.1
```
**Standardgateway testen**
```cmd
[TEST] ping
```
**Ziel testen**
```cmd
[TEST] ping
```
**Route zum Ziel verfolgen**
```cmd
[TEST][SENS] tracert
```
**Verlust und Laufzeit entlang des Pfades untersuchen**
```cmd
[TEST][SENS] pathping
```
**TCP-Port mit PowerShell testen**
```powershell
[TEST][SENS] Test-NetConnection -ComputerName "" -Port
```
Beispiel:
```powershell
[TEST][SENS] Test-NetConnection -ComputerName "server.example" -Port 443
```
**Erweiterte Verbindungsinformationen**
```powershell
[TEST][SENS] Test-NetConnection -ComputerName "" -DiagnoseRouting -InformationLevel Detailed
```
**Bewertungsregeln**
- Ein fehlgeschlagener Ping beweist nicht, dass das Ziel ausgefallen ist.
- ICMP kann gefiltert werden, während ein Anwendungsport erreichbar bleibt.
- Ein erfolgreicher Ping beweist nicht, dass die Anwendung funktioniert.
- Ein erfolgreicher TCP-Test bestätigt die Verbindung zum getesteten Port, aber nicht automatisch eine korrekte Anwendungssitzung.
- Zeitüberschreitungen bei `tracert` können durch gefilterte Antworten entstehen.
- Paketverlust an einem Zwischenknoten ist nur dann aussagekräftig, wenn er sich bis zum Ziel fortsetzt.
14. DNS-Auflösung untersuchen
**DNS-Abfrage mit PowerShell**
```powershell
[TEST][SENS] Resolve-DnsName ""
```
**Bestimmten DNS-Server abfragen**
```powershell
[TEST][SENS] Resolve-DnsName "" -Server ""
```
**Klassische DNS-Abfrage**
```cmd
[TEST][SENS] nslookup
```
**DNS-Clientcache anzeigen**
```powershell
[RO][SENS] Get-DnsClientCache
```
Alternativ:
```cmd
[RO][SENS] ipconfig /displaydns
```
**DNS-Clientcache leeren**
```powershell
[CHANGE][PRIV] Clear-DnsClientCache
```
Alternativ:
```cmd
[CHANGE][PRIV] ipconfig /flushdns
```
**Typische Fehlerquellen**
- falscher DNS-Server
- falscher oder abgelaufener DNS-Eintrag
- Suchsuffix fehlt
- Split-DNS liefert abhängig vom Standort andere Antworten
- VPN überschreibt DNS-Einstellungen
- lokaler Cache enthält einen alten Eintrag
- Hosts-Datei überschreibt DNS
- Firewall blockiert DNS-Abfragen
- IPv4- und IPv6-Antworten führen zu unterschiedlichen Pfaden
> Das Leeren des DNS-Caches sollte nur erfolgen, wenn ein veralteter lokaler Cache als Ursache infrage kommt. Es behebt keine falschen Einträge auf dem DNS-Server.
15. Ports und Verbindungen untersuchen
**TCP-Verbindungen anzeigen**
```powershell
[RO][SENS] Get-NetTCPConnection
```
**Lauschende TCP-Ports**
```powershell
[RO][SENS] Get-NetTCPConnection -State Listen |
Sort-Object LocalPort |
Select-Object LocalAddress, LocalPort, OwningProcess
```
**Zugehörigen Prozess bestimmen**
```powershell
[RO][SENS] Get-Process -Id
```
**Klassische Portübersicht**
```cmd
[RO][SENS] netstat -ano
```
**Lauschende Ports**
```cmd
[RO][SENS] netstat -ano | findstr LISTENING
```
**Ausführbare Programme einbeziehen**
```cmd
[RO][PRIV][SENS] netstat -abno
```
**UDP-Endpunkte**
```powershell
[RO][SENS] Get-NetUDPEndpoint |
Sort-Object LocalPort
```
**Wichtige Zustände**
| Zustand | Bedeutung |
|---|---|
| `Listen` | Prozess wartet auf eingehende TCP-Verbindungen |
| `Established` | TCP-Verbindung besteht |
| `TimeWait` | Verbindung wurde beendet und bleibt vorübergehend gespeichert |
| `SynSent` | Verbindungsaufbau wurde begonnen, Antwort steht noch aus |
| `CloseWait` | Gegenstelle hat beendet; lokaler Prozess muss noch schließen |
> Ein offener Hostport beweist noch nicht, dass die Anwendung fachlich korrekt arbeitet. Zusätzlich müssen Protokoll, Antwort und gegebenenfalls Authentifizierung getestet werden.
16. Windows-Firewall untersuchen
**Firewallprofile anzeigen**
```powershell
[RO] Get-NetFirewallProfile |
Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
```
**Aktivierte Firewallregeln anzeigen**
```powershell
[RO][SENS] Get-NetFirewallRule -Enabled True |
Select-Object DisplayName, Direction, Action, Profile
```
**Regeln anhand eines Namens suchen**
```powershell
[RO][SENS] Get-NetFirewallRule |
Where-Object DisplayName -Like '**'
```
**Firewallverwaltung öffnen**
```cmd
[RO] wf.msc
```
**Typische Prüfpunkte**
- aktives Netzwerkprofil
- Eingangs- oder Ausgangsrichtung
- erlaubende und blockierende Regeln
- lokaler Port und Remoteport
- lokales und entferntes Adressnetz
- zugeordnetes Programm oder Dienst
- Domänen-, privates oder öffentliches Profil
- zentral durch Gruppenrichtlinie verwaltete Regeln
> Die Firewall darf nicht pauschal deaktiviert werden, um ein Verbindungsproblem zu testen. Stattdessen muss die konkrete Verbindung mit passender Protokollierung und eng begrenzten Regeln untersucht werden.
17. Datenträger, Volumes und Speicherplatz prüfen
**Volumes anzeigen**
```powershell
[RO] Get-Volume |
Select-Object DriveLetter,
FileSystemLabel,
FileSystem,
HealthStatus,
SizeRemaining,
Size
```
**Datenträger anzeigen**
```powershell
[RO] Get-Disk
```
**Partitionen anzeigen**
```powershell
[RO] Get-Partition
```
**Freien Speicher übersichtlich berechnen**
```powershell
[RO] Get-Volume |
Where-Object DriveLetter |
Select-Object DriveLetter,
FileSystemLabel,
@{Name='Frei_GiB';Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}},
@{Name='Gesamt_GiB';Expression={[math]::Round($_.Size / 1GB, 2)}}
```
**Datenträgerverwaltung öffnen**
```cmd
[RO] diskmgmt.msc
```
**Dateisystem online prüfen**
```cmd
[TEST][PRIV] chkdsk C: /scan
```
**Wichtige Unterscheidungen**
- Freier Speicherplatz ist nicht dasselbe wie Datenträgerzustand.
- Ein Zustand `Healthy` schließt nicht jede Hardwarestörung aus.
- Ein voller Datenträger kann Updates, Protokollierung, Datenbanken und Benutzeranmeldungen beeinträchtigen.
- Eine hohe Datenträgerauslastung bedeutet nicht automatisch, dass das Laufwerk defekt ist.
- Dateisystemfehler, Hardwarefehler, Controllerprobleme und Anwendungs-I/O müssen getrennt untersucht werden.
> Reparaturoptionen wie `chkdsk /f` oder `/r` können lange Laufzeiten, exklusive Datenträgerzugriffe oder einen Neustart erfordern. Sie dürfen nicht ohne Sicherung und Wartungsplanung eingesetzt werden.
18. Arbeitsspeicher untersuchen
**Grundlegende Speicherinformationen**
```powershell
[RO] Get-CimInstance Win32_OperatingSystem |
Select-Object @{
Name='Gesamt_GiB'
Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)}
}, @{
Name='Frei_GiB'
Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)}
}
```
**Installierte Speichermodule**
```powershell
[RO][SENS] Get-CimInstance Win32_PhysicalMemory |
Select-Object BankLabel,
DeviceLocator,
Capacity,
Speed,
Manufacturer,
PartNumber
```
**Windows-Speicherdiagnose öffnen**
```cmd
[TEST][RESTART] mdsched.exe
```
Die Speicherdiagnose bietet normalerweise einen Test beim nächsten Neustart oder einen sofortigen Neustart mit anschließender Prüfung an.
> Ein Speicherdiagnosetest unter Last oder ein einzelner erfolgreicher Durchlauf schließt sporadische Hardwarefehler nicht zwingend aus.
19. Geräte und Treiber prüfen
**Geräte-Manager öffnen**
```cmd
[RO] devmgmt.msc
```
**Vorhandene Plug-and-Play-Geräte**
```powershell
[RO][SENS] Get-PnpDevice
```
**Geräte mit Fehlerstatus**
```powershell
[RO][SENS] Get-PnpDevice |
Where-Object Status -ne 'OK'
```
**Installierte Treiber**
```cmd
[RO][SENS] driverquery /v
```
**Signierte Treiber mit PowerShell**
```powershell
[RO][SENS] Get-CimInstance Win32_PnPSignedDriver |
Select-Object DeviceName,
DriverVersion,
DriverDate,
Manufacturer,
InfName
```
**Typische Prüfpunkte**
- Gerätestatus und Fehlercode
- Treiberversion und Treiberdatum
- kürzlich erfolgte Treiberänderung
- unbekannte oder deaktivierte Geräte
- Hardware-ID
- Herstellerfreigabe für die Windows-Version
- Zusammenhang zwischen Treiberinstallation und Fehlerzeitpunkt
> Ein neuerer Treiber ist nicht automatisch geeigneter. Entscheidend sind Hardwaremodell, Betriebssystemversion und Freigabe durch Hersteller oder Geräteanbieter.
20. Autostart, Aufgaben und Systemstart untersuchen
**Autostartprogramme über CIM anzeigen**
```powershell
[RO][SENS] Get-CimInstance Win32_StartupCommand |
Select-Object Name, Command, Location, User
```
**Aufgabenplanung öffnen**
```cmd
[RO] taskschd.msc
```
**Geplante Aufgaben anzeigen**
```powershell
[RO][SENS] Get-ScheduledTask |
Select-Object TaskPath, TaskName, State
```
**Aufgaben mit letztem Ergebnis**
```powershell
[RO][SENS] Get-ScheduledTask | ForEach-Object {
$info = $_ | Get-ScheduledTaskInfo
[PSCustomObject]@{
TaskPath = $_.TaskPath
TaskName = $_.TaskName
State = $_.State
LastRunTime = $info.LastRunTime
LastTaskResult = $info.LastTaskResult
NextRunTime = $info.NextRunTime
}
}
```
**Systemkonfiguration öffnen**
```cmd
[RO] msconfig
```
> Autostarteinträge und geplante Aufgaben dürfen nicht wahllos deaktiviert werden. Sie können zu Sicherheitssoftware, Backups, Updates, Treibern oder geschäftskritischen Anwendungen gehören.
21. Windows-Updates prüfen
**Installierte Hotfixes anzeigen**
```powershell
[RO] Get-HotFix |
Sort-Object InstalledOn -Descending
```
**Updateverlauf in den Einstellungen**
```text
Einstellungen
→ Windows Update
→ Updateverlauf
```
**Windows-Update-Ereignisse abrufen**
```powershell
[RO][SENS] Get-WinEvent -LogName `
'Microsoft-Windows-WindowsUpdateClient/Operational' `
-MaxEvents 100 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
```
**Typische Prüfpunkte**
- Zeitpunkt der Installation
- KB-Nummer
- erfolgreicher oder fehlgeschlagener Abschluss
- erforderlicher Neustart
- Treiberupdate
- bekannte Abhängigkeit zur betroffenen Anwendung
- wiederholt fehlgeschlagene Installation
- ausreichend freier Speicher
- Richtlinien oder Updateverwaltung im Unternehmen
> Ein zeitlicher Zusammenhang zwischen Update und Fehler ist ein wichtiger Hinweis, aber noch kein Ursachennachweis. Vor einer Deinstallation müssen bekannte Probleme, Sicherheitsfolgen und Herstellerangaben geprüft werden.
22. Windows-Systemdateien mit SFC prüfen
Der System File Checker überprüft geschützte Windows-Systemdateien und kann beschädigte Dateien ersetzen.
**Systemdateien prüfen und reparieren**
```cmd
[CHANGE][PRIV] sfc /scannow
```
**Nur eine bestimmte Datei prüfen**
```cmd
[TEST][PRIV] sfc /verifyfile=""
```
**Nur prüfen, ohne Reparatur**
```cmd
[TEST][PRIV] sfc /verifyonly
```
**Mögliche Ergebnisse**
- Keine Integritätsverletzungen gefunden
- Beschädigte Dateien gefunden und erfolgreich repariert
- Beschädigte Dateien gefunden, aber nicht alle repariert
- Prüfung konnte nicht ausgeführt werden
**SFC-Einträge aus dem CBS-Protokoll filtern**
```cmd
[RO][PRIV][SENS] findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log
```
> SFC ist kein universelles Reparaturprogramm. Es untersucht geschützte Windows-Systemdateien, nicht automatisch Anwendungsdateien, Benutzerdaten, Hardware oder sämtliche Konfigurationen.
23. Windows-Komponentenspeicher mit DISM prüfen
DISM kann den Zustand des Windows-Abbilds beziehungsweise Komponentenspeichers untersuchen und reparieren.
**Schnelle Statusprüfung**
```cmd
[RO][PRIV] DISM /Online /Cleanup-Image /CheckHealth
```
**Ausführliche Prüfung**
```cmd
[TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth
```
**Windows-Abbild reparieren**
```cmd
[CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth
```
**Bedeutung der Parameter**
| Parameter | Bedeutung |
|---|---|
| `/Online` | Aktuell laufendes Windows wird bearbeitet |
| `/Cleanup-Image` | Wartungsfunktion für das Windows-Abbild |
| `/CheckHealth` | Prüft, ob eine Beschädigung bereits erkannt wurde |
| `/ScanHealth` | Führt eine ausführlichere Prüfung durch |
| `/RestoreHealth` | Versucht erkannte Beschädigungen zu reparieren |
**Wichtige Hinweise**
- `/RestoreHealth` verändert den Systemzustand.
- Der Vorgang kann längere Zeit dauern.
- Eine Reparaturquelle kann erforderlich sein.
- Die Quelle muss zum installierten Windows passen.
- Fehler müssen anhand des DISM-Protokolls ausgewertet werden.
- Nach erfolgreicher Reparatur kann eine erneute SFC-Prüfung sinnvoll sein.
**DISM-Protokoll**
```text
C:\Windows\Logs\DISM\dism.log
```
**CBS-Protokoll**
```text
C:\Windows\Logs\CBS\CBS.log
```
> DISM und SFC dürfen nicht reflexartig bei jedem Windows-Problem ausgeführt werden. Zuerst sollte ein Zusammenhang mit beschädigten Windows-Komponenten oder Systemdateien begründet werden.
24. Gruppenrichtlinien und Richtlinienanwendung prüfen
**Angewendete Richtlinien anzeigen**
```cmd
[RO][SENS] gpresult /r
```
**Ausführlichen HTML-Bericht erzeugen**
```cmd
[RO][SENS] gpresult /h ".\gpresult.html"
```
**Resultant Set of Policy öffnen**
```cmd
[RO][SENS] rsop.msc
```
**Gruppenrichtlinien-Ereignisse**
```powershell
[RO][SENS] Get-WinEvent -LogName `
'Microsoft-Windows-GroupPolicy/Operational' `
-MaxEvents 100 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
```
**Gruppenrichtlinien aktualisieren**
```cmd
[CHANGE][PRIV] gpupdate /force
```
> `gpupdate /force` kann Richtlinien erneut anwenden, Anmelde- oder Neustartanforderungen auslösen und den Arbeitszustand beeinflussen. Der Befehl ist kein Ersatz für die Analyse einer fehlerhaften Richtlinie.
25. Anmeldungen und Benutzerkontext untersuchen
**Aktuellen Benutzer anzeigen**
```cmd
[RO] whoami
```
**Gruppen und Sicherheitskennungen anzeigen**
```cmd
[RO][SENS] whoami /groups
```
**Aktuelle Berechtigungen anzeigen**
```cmd
[RO][SENS] whoami /priv
```
**Angemeldete Sitzungen**
```cmd
[RO][SENS] query user
```
**Lokale Benutzer anzeigen**
```powershell
[RO][SENS] Get-LocalUser
```
**Lokale Gruppenmitgliedschaften**
```powershell
[RO][SENS] Get-LocalGroupMember -Group ""
```
**Kerberos-Tickets anzeigen**
```cmd
[RO][SENS] klist
```
**Typische Ursachen kontextabhängiger Fehler**
- anderer Benutzer
- fehlende Gruppenmitgliedschaft
- nicht aktualisiertes Zugriffstoken
- lokale statt Domänenanmeldung
- abgelaufenes oder fehlendes Kerberos-Ticket
- Dienst läuft unter anderem Konto
- unterschiedliche Umgebungsvariablen
- abweichendes Benutzerprofil
- erhöhte und nicht erhöhte Sitzung besitzen unterschiedliche Rechte
> Ein erfolgreicher Test als Administrator beweist nicht, dass die Funktion für den vorgesehenen Benutzer korrekt berechtigt ist.
26. Remotedienste und Freigaben prüfen
**SMB-Freigaben anzeigen**
```powershell
[RO][SENS] Get-SmbShare
```
**Bestehende SMB-Verbindungen**
```powershell
[RO][SENS] Get-SmbConnection
```
**Erreichbarkeit von SMB testen**
```powershell
[TEST][SENS] Test-NetConnection -ComputerName "" -Port 445
```
**Remotedesktopport testen**
```powershell
[TEST][SENS] Test-NetConnection -ComputerName "" -Port 3389
```
**WinRM-Konfiguration anzeigen**
```cmd
[RO][SENS] winrm get winrm/config
```
**WinRM-Verbindung testen**
```powershell
[TEST][SENS] Test-WSMan -ComputerName ""
```
**Wichtige Unterscheidung**
Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der getestete Port erreichbar ist. Sie bestätigt nicht automatisch:
- erfolgreiche Authentifizierung
- korrekte Freigabeberechtigung
- NTFS-Berechtigung
- funktionierende Remotedesktopsitzung
- gültiges Zertifikat
- erfolgreiche Anwendungskommunikation
27. Abstürze und Speicherabbilder untersuchen
Windows kann bei System- oder Anwendungsabstürzen Speicherabbilder erzeugen.
**Typische Speicherorte**
```text
C:\Windows\MEMORY.DMP
C:\Windows\Minidump\
%LOCALAPPDATA%\CrashDumps\
```
Die tatsächliche Konfiguration und der Speicherort können abweichen.
**Start- und Wiederherstellungseinstellungen öffnen**
```cmd
[RO] sysdm.cpl
```
Danach:
```text
Erweitert
→ Starten und Wiederherstellen
→ Einstellungen
```
**Typische Abbildarten**
| Typ | Inhalt |
|---|---|
| Kleines Speicherabbild | Begrenzte Informationen zum Absturz |
| Kernelspeicherabbild | Kernelbezogene Speicherbereiche |
| Automatisches Speicherabbild | Von Windows verwaltete Auswahl |
| Vollständiges Speicherabbild | Umfassender Inhalt des physischen Speichers |
| Aktives Speicherabbild | Für aktive Kernel- und Systembereiche optimiert |
**Wichtige Sicherheitsregel**
Speicherabbilder können enthalten:
- Benutzerdaten
- Dateiinhalte
- Prozessspeicher
- Schlüsselmaterial
- Tokens
- Passwörter oder andere Geheimnisse
- Netzwerk- und Sitzungsinformationen
> Speicherabbilder müssen wie sensible Diagnosedaten behandelt und dürfen nicht ungeprüft weitergegeben werden.
Zur detaillierten Analyse kann Microsoft WinDbg eingesetzt werden. WinDbg wird auf einer späteren Seite zusammen mit weiteren spezialisierten Werkzeugen behandelt.
28. Abgesicherter Modus und sauberer Systemstart
Der abgesicherte Modus startet Windows mit einer eingeschränkten Auswahl von Treibern und Diensten. Damit kann geprüft werden, ob ein Fehler durch zusätzliche Software, Treiber oder Autostartkomponenten beeinflusst wird.
Ein sauberer Systemstart deaktiviert gezielt nicht benötigte Dienste und Autostartprogramme, um Konflikte einzugrenzen.
**Systemkonfiguration öffnen**
```cmd
[CHANGE][RESTART] msconfig
```
**Wichtige Risiken**
- Sicherheits- oder Verwaltungssoftware kann vorübergehend deaktiviert werden.
- Geschäftsanwendungen oder Hintergrunddienste können ausfallen.
- Änderungen müssen dokumentiert und anschließend zurückgenommen werden.
- Abgesicherter Modus und sauberer Start sind Diagnosezustände, keine dauerhafte Lösung.
- In verwalteten Umgebungen kann eine Freigabe erforderlich sein.
**Geeignete Fragestellung**
```text
Tritt der Fehler auch mit einer minimalen Auswahl von Treibern,
Diensten und Autostartprogrammen auf?
```
Ein ausbleibender Fehler grenzt die Ursache ein, identifiziert aber noch nicht automatisch die verantwortliche Komponente.
29. Fernzugriff und Datensammlung sicher durchführen
Vor einer Ferndiagnose müssen geklärt werden:
- korrekter Zielcomputer
- berechtigte Person
- Wartungs- oder Diagnosefenster
- Auswirkungen auf aktive Benutzer
- erlaubte Werkzeuge
- Speicherort der Diagnosedaten
- Schutz sensibler Informationen
- Rückfallplan für Änderungen
**Computername prüfen**
```powershell
[RO] $env:COMPUTERNAME
```
**Benutzerkontext prüfen**
```powershell
[RO] whoami
```
**PowerShell-Remotesitzung testen**
```powershell
[TEST][SENS] Test-WSMan -ComputerName ""
```
**Befehl remote ausführen**
```powershell
[RO][SENS] Invoke-Command -ComputerName "" -ScriptBlock {
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, LastBootUpTime
}
```
> Remoteausgaben, Transkripte und Diagnosearchive können sensible Daten enthalten. Sie müssen zweckgebunden gespeichert, geschützt und nach den geltenden Vorgaben gelöscht werden.
30. Gefährliche Schnelllösungen vermeiden
| Maßnahme | Risiko |
|---|---|
| Unbekannten Prozess sofort beenden | Datenverlust oder Dienstausfall |
| Dienst ohne Prüfung neu starten | Unterbrechung abhängiger Anwendungen |
| Windows-Firewall vollständig deaktivieren | Schutzwirkung entfällt |
| Ereignisprotokolle löschen | Diagnosenachweise gehen verloren |
| Registrywerte auf Verdacht ändern | System oder Anwendung wird beschädigt |
| Treiber ungeprüft aktualisieren | Inkompatibilität oder Startfehler |
| Update sofort deinstallieren | Sicherheitslücke oder Folgefehler |
| `chkdsk /f` ungeplant ausführen | Neustart und lange Ausfallzeit |
| DISM oder SFC als Universallösung verwenden | Ursache bleibt ungeklärt |
| Autostart und Dienste wahllos deaktivieren | Sicherheits- und Geschäftsfunktionen fallen aus |
| Speicherabbild unredigiert weitergeben | Geheimnisse und Benutzerdaten werden offengelegt |
| Computer hart ausschalten | Daten- und Dateisystemschäden |
| Systemwiederherstellung ungeprüft starten | Neuere Änderungen können verloren gehen |
| „PC zurücksetzen“ verwenden | Anwendungen, Einstellungen oder Daten gehen verloren |
**Vor einer Änderung prüfen**
1. Ist die Ursache ausreichend eingegrenzt?
2. Welche Systeme und Benutzer sind betroffen?
3. Existiert eine aktuelle Sicherung?
4. Ist die Maßnahme reversibel?
5. Welche Abhängigkeiten bestehen?
6. Ist ein Neustart erforderlich?
7. Gibt es ein Wartungsfenster?
8. Wie wird die Funktion anschließend getestet?
9. Wie wird die Änderung dokumentiert?
31. Sichere Reihenfolge einer Windows-Fehleranalyse
1. Betroffenen Computer und Benutzer eindeutig bestimmen.
2. Originale Fehlermeldung und Fehlerzeitpunkt erfassen.
3. Umfang und Reproduzierbarkeit prüfen.
4. Windows-Version, Build und letzte Startzeit erfassen.
5. Änderungen, Updates und Installationen vor dem Fehler feststellen.
6. Ereignisanzeige und Zuverlässigkeitsverlauf zum Fehlerzeitpunkt prüfen.
7. Prozesse, Dienste und aktuelle Ressourcenbelastung untersuchen.
8. Freien Speicherplatz und Datenträgerzustand kontrollieren.
9. Netzwerk, DNS, Route und benötigte Ports getrennt testen.
10. Benutzerkontext, Berechtigungen und Richtlinien berücksichtigen.
11. Treiber, Geräte und Abhängigkeiten prüfen.
12. Erkenntnisse aus mehreren Datenquellen abgleichen.
13. Sicherung und Rückfallplan kontrollieren.
14. Kleinste geeignete Änderung durchführen.
15. Interne und externe Funktionsprüfung ausführen.
16. Ereignisse und Ressourcen nach der Maßnahme erneut prüfen.
17. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Schnelle Befehlsübersicht
| Aufgabe | Befehl |
|---|---|
| Windows-Version | `[RO] winver` |
| Systeminformationen | `[RO][SENS] systeminfo` |
| Ereignisanzeige | `[RO] eventvwr.msc` |
| Systemereignisse | `[RO][SENS] Get-WinEvent -LogName System -MaxEvents 50` |
| Zuverlässigkeitsverlauf | `[RO] perfmon /rel` |
| Task-Manager | `[RO] taskmgr` |
| Ressourcenmonitor | `[RO] resmon` |
| Leistungsüberwachung | `[RO] perfmon` |
| Prozesse | `[RO][SENS] Get-Process` |
| Dienste | `[RO] Get-Service` |
| Dienstkonfiguration | `[RO] sc.exe qc ""` |
| IP-Konfiguration | `[RO][SENS] ipconfig /all` |
| Adapter | `[RO] Get-NetAdapter` |
| Routingtabelle | `[RO][SENS] route print` |
| Erreichbarkeit | `[TEST] ping ` |
| Route | `[TEST][SENS] tracert ` |
| TCP-Port | `[TEST][SENS] Test-NetConnection "" -Port ` |
| DNS | `[TEST][SENS] Resolve-DnsName ""` |
| TCP-Verbindungen | `[RO][SENS] Get-NetTCPConnection` |
| Ports und PID | `[RO][SENS] netstat -ano` |
| Firewallprofile | `[RO] Get-NetFirewallProfile` |
| Volumes | `[RO] Get-Volume` |
| Datenträger | `[RO] Get-Disk` |
| Geräte | `[RO][SENS] Get-PnpDevice` |
| Treiber | `[RO][SENS] driverquery /v` |
| Geplante Aufgaben | `[RO][SENS] Get-ScheduledTask` |
| Gruppenrichtlinien | `[RO][SENS] gpresult /r` |
| Benutzerkontext | `[RO] whoami` |
| Systemdateien | `[CHANGE][PRIV] sfc /scannow` |
| Abbildprüfung | `[TEST][PRIV] DISM /Online /Cleanup-Image /ScanHealth` |
| Abbildreparatur | `[CHANGE][PRIV] DISM /Online /Cleanup-Image /RestoreHealth` |
33. Dokumentationsvorlage
```text
Ticket:
Datum und Uhrzeit:
Bearbeiter:
Computername:
Windows-Edition:
Windows-Version:
Build:
Architektur:
Letzter Systemstart:
Benutzerkontext:
Domäne oder Arbeitsgruppe:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Erstmals aufgetreten:
Reproduzierbar:
Betroffene Benutzer:
Betroffene Anwendung oder Funktion:
Umfang der Störung:
Letzte funktionierende Nutzung:
Letzte Änderung:
Installierte Updates:
Treiberänderung:
Softwareinstallation:
Richtlinienänderung:
Relevante Ereignisquellen:
Ereignis-IDs:
Zuverlässigkeitsverlauf:
Betroffene Prozesse:
Betroffene Dienste:
CPU:
Arbeitsspeicher:
Datenträger:
Freier Speicher:
IP-Konfiguration:
DNS:
Standardgateway:
Getestetes Ziel:
Getesteter Port:
Testergebnis:
Firewallprofil:
Firewallregel:
Gerätestatus:
Treiberversion:
Systemdateiprüfung:
DISM-Status:
Absturzabbild:
Sensible Daten redigiert:
Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Geplante Änderung:
Erwartete Auswirkung:
Rückfallplan:
Neustart erforderlich:
Ergebnis nach der Maßnahme:
Interne Funktionsprüfung:
Externe Funktionsprüfung:
Monitoring:
Weiterführende Maßnahmen:
```
---
**Merksatz**
> Windows stellt viele Diagnosewerkzeuge bereit, doch kein einzelnes Werkzeug liefert automatisch die Ursache. Eine belastbare Fehleranalyse verbindet Zeitpunkt, Ereignisse, Prozesse, Dienste, Ressourcen, Netzwerk, Änderungen und Benutzerkontext zu einem nachvollziehbaren Gesamtbild.
**Quellen und weiterführende Dokumentation**
- [Microsoft Learn – Windows-Problembehandlungsdokumentation](https://learn.microsoft.com/troubleshoot/windows/)
- [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent)
- [Microsoft Learn – Get-Process](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-process)
- [Microsoft Learn – Get-Service](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/get-service)
- [Microsoft Learn – Get-Counter](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter)
- [Microsoft Learn – Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
- [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection)
- [Microsoft Learn – Get-NetFirewallProfile](https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallprofile)
- [Microsoft Learn – Get-Volume](https://learn.microsoft.com/powershell/module/storage/get-volume)
- [Microsoft Learn – Get-PnpDevice](https://learn.microsoft.com/powershell/module/pnpdevice/get-pnpdevice)
- [Microsoft Learn – System File Checker](https://learn.microsoft.com/windows-server/administration/windows-commands/sfc)
- [Microsoft Learn – Windows-Abbild mit DISM reparieren](https://learn.microsoft.com/windows-hardware/manufacture/desktop/repair-a-windows-image)
- [Microsoft Learn – Chkdsk](https://learn.microsoft.com/windows-server/administration/windows-commands/chkdsk)
- [Microsoft Learn – GPResult](https://learn.microsoft.com/windows-server/administration/windows-commands/gpresult)
- [Microsoft Learn – Windows-Debuggingwerkzeuge](https://learn.microsoft.com/windows-hardware/drivers/debugger/)
# 5.2 Microsoft Sysinternals – Erweiterte Werkzeuge zur Fehleranalyse
Microsoft Sysinternals ist eine Sammlung spezialisierter Diagnose-, Analyse- und Verwaltungswerkzeuge. Die Programme ermöglichen einen wesentlich tieferen Einblick in Prozesse, Autostarts, Dateizugriffe, Registryzugriffe, Netzwerkverbindungen, Arbeitsspeicher, Berechtigungen, Active Directory und Systemereignisse als viele integrierte Windows-Werkzeuge.
Sysinternals-Werkzeuge können unter anderem helfen bei:
- nicht nachvollziehbaren Programmabstürzen
- blockierten Dateien und Verzeichnissen
- ungewöhnlich hoher CPU-, RAM- oder Datenträgerauslastung
- fehlgeschlagenen Datei- oder Registryzugriffen
- unbekannten Autostarteinträgen
- verdächtigen Prozessen und Netzwerkverbindungen
- DLL- und Abhängigkeitsproblemen
- Berechtigungsfehlern
- Speicherlecks
- sporadischen Programmabstürzen
- Active-Directory-Problemen
- detaillierter Sicherheitsüberwachung
> Sysinternals-Werkzeuge liefern technische Beobachtungen und Messdaten. Ein auffälliger Eintrag ist noch kein Beweis für Malware, einen Defekt oder die eigentliche Ursache einer Störung.
---
**Kennzeichnung der Befehle**
| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | Nur lesender beziehungsweise beobachtender Einsatz |
| `[TEST]` | Führt einen aktiven Test oder eine Aufzeichnung durch |
| `[CHANGE]` | Verändert Prozesse, Dateien, Konfigurationen oder Systemzustand |
| `[PRIV]` | Erhöhte Berechtigungen können erforderlich sein |
| `[RESTART]` | Kann einen Neustart oder eine Unterbrechung verursachen |
| `[REMOTE]` | Greift auf einen anderen Computer zu |
| `[SENS]` | Ausgabe kann sensible Informationen enthalten |
| `[DANGER]` | Hohes Risiko für Ausfall, Datenverlust oder Sicherheitsprobleme |
Die Kennzeichnungen sind Hinweise für den administrativen Einsatz. Ob eine Freigabe erforderlich ist, hängt zusätzlich von der jeweiligen Organisation, dem betroffenen System und den geltenden Sicherheitsvorgaben ab.
---
1. Was ist Microsoft Sysinternals?
Die Sysinternals-Werkzeuge wurden ursprünglich von Mark Russinovich und Bryce Cogswell entwickelt. Microsoft übernahm Sysinternals im Jahr 2006 und stellt die Werkzeuge weiterhin bereit.
Die Sammlung besteht überwiegend aus kleinen, spezialisierten Programmen. Viele davon müssen nicht klassisch installiert werden und können nach dem Entpacken direkt gestartet werden.
**Wichtige Werkzeuggruppen**
| Bereich | Beispiele |
|---|---|
| Prozesse | Process Explorer, ProcDump, PsList, PsKill |
| Systemaktivität | Process Monitor, Sysmon, DebugView |
| Autostart | Autoruns, Autorunsc |
| Netzwerk | TCPView, Tcpvcon, PsPing |
| Arbeitsspeicher | RAMMap, VMMap |
| Dateien und Objekte | Handle, ListDLLs, Streams, PendMoves |
| Sicherheit und Rechte | Sigcheck, AccessChk, AccessEnum, ShareEnum |
| Active Directory | AD Explorer, AD Insight, AD Restore |
| Datenträger | Disk2vhd, DiskMon, Disk Usage, NTFSInfo |
| Remotewerkzeuge | PsExec, PsService, PsInfo, PsLoggedOn |
| Kernelanalyse | LiveKd, WinObj |
| Systeminformation | Coreinfo, BgInfo, LogonSessions |
**Abgrenzung**
Sysinternals ist:
- keine automatische Reparatursuite
- kein Ersatz für ein Antiviren- oder EDR-System
- kein Ersatz für ein zentrales Monitoring
- kein vollständiger Debugger
- kein Beweiswerkzeug, das aus einer einzelnen Auffälligkeit automatisch die Ursache bestimmt
Die Werkzeuge ergänzen Ereignisanzeige, Task-Manager, Ressourcenmonitor, Leistungsüberwachung, PowerShell und spezialisierte Debuggingprogramme.
2. Sysinternals sicher beziehen
Sysinternals-Werkzeuge sollten ausschließlich aus vertrauenswürdigen Microsoft-Quellen bezogen werden.
**Offizielle Möglichkeiten**
1. Einzelwerkzeuge über Microsoft Learn herunterladen
2. vollständige Sysinternals Suite herunterladen
3. Sysinternals Suite aus dem Microsoft Store installieren
4. Werkzeuge über Sysinternals Live ausführen
**Sysinternals Suite**
Die Suite enthält einen großen Teil der Diagnosewerkzeuge in einem gemeinsamen Archiv. Für bestimmte Plattformen stellt Microsoft unterschiedliche Pakete bereit, darunter x64 und ARM64.
**Microsoft Store**
Bei der Store-Version werden grafische Programme im Startmenü eingetragen. Die Befehlszeilenprogramme können über App-Ausführungsaliase aufgerufen werden.
**Sysinternals Live**
Ein Werkzeug kann direkt von Sysinternals Live gestartet werden:
```cmd
[TEST][SENS] \\live.sysinternals.com\tools\procexp.exe
```
Beispiel für Process Monitor:
```cmd
[TEST][SENS] \\live.sysinternals.com\tools\procmon.exe
```
Dabei müssen Netzwerkzugriff, Proxy, Firewall, Namensauflösung und die Sicherheitsrichtlinien der Organisation berücksichtigt werden.
> In kontrollierten Unternehmensumgebungen sollte nicht ungeprüft eine ausführbare Datei direkt aus dem Internet gestartet werden. Besser ist häufig ein freigegebenes, geprüftes und versioniertes internes Werkzeugverzeichnis.
3. Integrität und Signatur prüfen
Vor dem Einsatz sollte geprüft werden:
- stammt die Datei von Microsoft?
- ist die digitale Signatur gültig?
- stimmt die erwartete Architektur?
- wurde die Datei aus einem freigegebenen Speicherort bezogen?
- ist die Werkzeugversion dokumentiert?
- wurde die Datei durch die Sicherheitssoftware geprüft?
**Digitale Signatur mit PowerShell kontrollieren**
```powershell
[RO] Get-AuthenticodeSignature ".\procexp.exe" |
Select-Object Status, StatusMessage, SignerCertificate
```
**Dateihash berechnen**
```powershell
[RO] Get-FileHash ".\procexp.exe" -Algorithm SHA256
```
Der Hash kann zur internen Dokumentation und zum Vergleich identischer Werkzeugstände verwendet werden. Ein Hash beweist allein jedoch nicht, dass eine Datei vertrauenswürdig ist.
**Sysinternals Sigcheck verwenden**
```cmd
[RO] sigcheck.exe -a -h -i ".\procexp.exe"
```
Typische Informationen können sein:
- Dateiversion
- Herausgeber
- digitale Signatur
- Zertifikatskette
- Zeitstempel
- kryptografischer Hash
- Dateibeschreibung
- Produktname
> Eine gültige Signatur bestätigt die signierte Herkunft und Dateiintegrität innerhalb der Signaturprüfung. Sie beweist nicht automatisch, dass jede ausgeführte Funktion im konkreten Einsatz sicher oder erwünscht ist.
4. Allgemeine Einsatzregeln
Vor dem Start eines Sysinternals-Werkzeugs sollte feststehen:
1. Welcher Fehler wird untersucht?
2. Welcher Computer ist betroffen?
3. Welcher Benutzerkontext ist betroffen?
4. Wann tritt der Fehler auf?
5. Welches Werkzeug kann die benötigte Beobachtung liefern?
6. Welche Daten können bei der Aufzeichnung entstehen?
7. Ist eine erhöhte Ausführung erforderlich?
8. Wie groß kann die Protokolldatei werden?
9. Wo wird sie geschützt gespeichert?
10. Wann wird die Aufzeichnung beendet?
11. Wie werden sensible Daten redigiert?
12. Welche Änderung muss anschließend zurückgenommen werden?
**Grundregeln**
- zuerst beobachten, dann verändern
- Filter vor längeren Aufzeichnungen vorbereiten
- Zeitpunkt und Reproduktionsschritte dokumentieren
- keine Prozesse oder Handles auf Verdacht beenden
- keine unbekannten Autostarts ungeprüft löschen
- keine Diagnosedateien öffentlich hochladen
- keine Remoteausführung ohne Freigabe
- nur den erforderlichen Berechtigungskontext verwenden
- Werkzeugversion und Befehlszeile dokumentieren
- nach jeder Änderung die betroffene Funktion erneut prüfen
5. Process Explorer – Prozesse und Abhängigkeiten analysieren
Process Explorer zeigt Prozesse hierarchisch an und liefert detaillierte Informationen zu:
- Prozessname und PID
- übergeordnetem Prozess
- Benutzerkonto
- CPU- und Speicherauslastung
- Handles
- geladenen DLLs
- Speicherabbildern
- Threads
- TCP/IP-Aktivität
- Dateipfad
- Befehlszeile
- digitaler Signatur
- Integritätsstufe
- Sicherheitskontext
- Prozessstartzeit
**Starten**
```cmd
[RO][SENS] procexp.exe
```
Für vollständige Informationen über Systemprozesse können erhöhte Rechte erforderlich sein:
```cmd
[RO][PRIV][SENS] procexp.exe
```
**Wichtige Funktionen**
| Funktion | Verwendung |
|---|---|
| Process Tree | Eltern-Kind-Beziehungen von Prozessen erkennen |
| Lower Pane – Handles | Geöffnete Dateien, Registryschlüssel und andere Objekte untersuchen |
| Lower Pane – DLLs | Geladene DLLs und speicherabgebildete Dateien anzeigen |
| Find Handle or DLL | Prozess zu einer Datei, einem Objekt oder einer DLL finden |
| Properties | Threads, Netzwerk, Sicherheit, Umgebung und Startparameter untersuchen |
| Verify Image Signatures | Signaturen ausführbarer Dateien prüfen |
| Save | Prozessübersicht für die Dokumentation speichern |
| Create Dump | Speicherabbild eines Prozesses erzeugen |
| Kill Process Tree | Prozess und untergeordnete Prozesse beenden |
**Typische Anwendungsfälle**
- Welcher Prozess hält eine Datei geöffnet?
- Welche Anwendung hat einen Unterprozess gestartet?
- Unter welchem Konto läuft ein Prozess?
- Welche DLL wurde aus einem unerwarteten Pfad geladen?
- Welcher Thread erzeugt hohe CPU-Last?
- Stimmen Dateiname, Pfad und Herausgeber zusammen?
- Ist ein Prozess mehrfach vorhanden?
- Läuft ein Prozess mit erhöhten Rechten?
**Prozessfarben**
Process Explorer kann unterschiedliche Prozesstypen farblich kennzeichnen. Die genaue Bedeutung hängt von der konfigurierten Farbauswahl ab und sollte über die Programmeinstellungen kontrolliert werden.
> Eine Farbe oder ein nicht verifizierter Signaturstatus ist kein automatischer Malware-Nachweis.
6. Blockierte Dateien mit Process Explorer finden
Wenn eine Datei nicht gelöscht, verschoben oder ersetzt werden kann, kann ein geöffneter Handle dafür verantwortlich sein.
**Vorgehensweise**
1. Process Explorer starten.
2. `Find` öffnen.
3. `Find Handle or DLL` auswählen.
4. eindeutigen Teil des Datei- oder Verzeichnisnamens eingeben.
5. Treffer und zugehörigen Prozess prüfen.
6. Anwendung möglichst regulär schließen.
7. Dateioperation erneut testen.
**Nicht als erste Maßnahme verwenden**
- Prozess sofort beenden
- Handle direkt schließen
- Dienst ungeprüft stoppen
- Systemprozess beenden
- Datei mit Gewalt löschen
Das direkte Schließen eines Handles kann den Zustand der Anwendung beschädigen, Datenverlust verursachen oder zu einem späteren Absturz führen.
> Die sichere Lösung besteht normalerweise darin, die verursachende Anwendung oder den zugehörigen Dienst kontrolliert zu beenden.
7. Handle – offene Dateien und Objekte per Befehlszeile
`Handle` zeigt offene Handles von Prozessen an. Damit kann unter anderem ermittelt werden, welcher Prozess eine bestimmte Datei oder ein Verzeichnis verwendet.
**Nach einem Dateinamen suchen**
```cmd
[RO][PRIV][SENS] handle.exe ""
```
**Beispiel**
```cmd
[RO][PRIV][SENS] handle.exe "datenbank.db"
```
**Handles eines bestimmten Prozesses anzeigen**
```cmd
[RO][PRIV][SENS] handle.exe -p
```
**Ausgabe ohne Banner**
```cmd
[RO][PRIV][SENS] handle.exe -nobanner ""
```
**Handle schließen**
```cmd
[CHANGE][PRIV][DANGER] handle.exe -c -p
```
> Das erzwungene Schließen eines Handles kann Daten beschädigen oder einen Prozess destabilisieren. Diese Funktion darf nur verwendet werden, wenn Objekt, Prozess, Abhängigkeiten und Auswirkungen eindeutig bekannt sind.
8. Process Monitor – Datei-, Registry- und Prozessaktivität erfassen
Process Monitor, kurz Procmon, zeichnet in Echtzeit unter anderem folgende Aktivitäten auf:
- Dateisystemzugriffe
- Registryzugriffe
- Prozessstarts und Prozessbeendigungen
- Threadaktivitäten
- Laden von DLLs und Images
- Profilierungsereignisse
- Prozess-, Benutzer- und Sitzungsinformationen
- zugehörige Aufrufstapel
**Starten**
```cmd
[TEST][PRIV][SENS] procmon.exe
```
Process Monitor beginnt normalerweise unmittelbar mit der Aufzeichnung. Deshalb sollte die Aufzeichnung zunächst angehalten und gezielt vorbereitet werden.
**Empfohlene Grundreihenfolge**
1. Process Monitor starten.
2. Aufzeichnung anhalten.
3. bestehende Ereignisse leeren.
4. passende Filter festlegen.
5. Aufzeichnung starten.
6. Fehler möglichst genau reproduzieren.
7. Aufzeichnung sofort wieder anhalten.
8. relevante Ereignisse untersuchen.
9. Aufzeichnung im nativen PML-Format sichern.
10. sensible Inhalte vor einer Weitergabe prüfen.
**Typische Filter**
| Feld | Bedingung | Beispiel |
|---|---|---|
| Process Name | is | `anwendung.exe` |
| PID | is | konkrete Prozess-ID |
| Path | contains | Verzeichnis oder Registrypfad |
| Operation | is | `CreateFile` |
| Operation | is | `RegOpenKey` |
| Result | is | `ACCESS DENIED` |
| Result | is | `NAME NOT FOUND` |
| User | is | betroffenes Benutzerkonto |
| Duration | greater than | auffällig langsame Operationen |
> Process Monitor zeichnet sehr viele normale und erwartete Vorgänge auf. Einzelne Meldungen wie `NAME NOT FOUND`, `PATH NOT FOUND` oder `ACCESS DENIED` sind nicht automatisch Fehlerursachen.
9. Process-Monitor-Ergebnisse richtig interpretieren
**Häufige Ergebnisse**
| Ergebnis | Grundbedeutung |
|---|---|
| `SUCCESS` | Operation wurde erfolgreich abgeschlossen |
| `NAME NOT FOUND` | Angefragter Name wurde nicht gefunden |
| `PATH NOT FOUND` | Ein Bestandteil des Pfades wurde nicht gefunden |
| `ACCESS DENIED` | Zugriff wurde im verwendeten Kontext verweigert |
| `SHARING VIOLATION` | Zugriff kollidiert mit einer bestehenden Freigabe oder geöffneten Datei |
| `BUFFER OVERFLOW` | Puffer war für die erste Abfrage zu klein; kann Teil eines normalen Abfragemusters sein |
| `NO MORE FILES` | Verzeichnisabfrage hat keine weiteren Ergebnisse |
| `REPARSE` | Verarbeitung über einen Reparse Point |
| `END OF FILE` | Dateiende erreicht |
| `FILE LOCKED WITH ONLY READERS` | Sperrzustand der Datei |
**Bewertungsfragen**
- Gehört das Ereignis zum betroffenen Prozess?
- Liegt es unmittelbar vor dem sichtbaren Fehler?
- Wird nach einem fehlgeschlagenen Zugriff ein anderer Pfad erfolgreich verwendet?
- Wiederholt sich das Ereignis ungewöhnlich häufig?
- Ist der Pfad laut Anwendung tatsächlich erforderlich?
- Welcher Benutzer führt den Zugriff aus?
- Welche Berechtigungen gelten für das Objekt?
- Handelt es sich um eine optionale Suche der Anwendung?
- Gibt es einen zugehörigen Stack oder Folgefehler?
- Tritt das Verhalten auf einem funktionierenden Vergleichssystem ebenfalls auf?
**Wichtiger Grundsatz**
Viele Programme suchen nacheinander an mehreren Stellen nach Dateien oder Registrywerten. Mehrere fehlgeschlagene Suchvorgänge können deshalb völlig normal sein, wenn anschließend ein erfolgreicher Treffer erfolgt.
10. Process Monitor per Befehlszeile einsetzen
Process Monitor unterstützt Befehlszeilenoptionen für reproduzierbare Aufzeichnungen.
**Lizenzdialog vorab akzeptieren**
```cmd
[CHANGE] procmon.exe /AcceptEula
```
**Aufzeichnung mit Sicherungsdatei starten**
```cmd
[TEST][PRIV][SENS] procmon.exe /AcceptEula /Quiet /BackingFile "C:\Diagnose\trace.pml"
```
**Laufende Process-Monitor-Instanz beenden**
```cmd
[CHANGE][PRIV] procmon.exe /Terminate
```
**Gespeicherte PML-Datei als CSV exportieren**
```cmd
[RO][SENS] procmon.exe /OpenLog "C:\Diagnose\trace.pml" /SaveAs "C:\Diagnose\trace.csv"
```
**Bootaufzeichnung**
Process Monitor besitzt eine Boot-Logging-Funktion, mit der Aktivitäten während des Systemstarts erfasst werden können. Diese muss über die Programmoberfläche oder passend geplante Optionen kontrolliert aktiviert und anschließend wieder beendet werden.
> Bootaufzeichnungen können sehr groß werden und sensible Systeminformationen enthalten. Sie dürfen nicht unbegrenzt aktiviert bleiben.
11. Autoruns – Autostarts vollständig untersuchen
Autoruns zeigt deutlich mehr Autostartorte als die einfache Autostartansicht des Task-Managers.
Dazu können gehören:
- Anmeldeautostarts
- Dienste
- Treiber
- geplante Aufgaben
- Explorer-Erweiterungen
- Winlogon-Komponenten
- Boot-Execute-Einträge
- Codecs
- AppInit-DLLs
- Image Hijacks
- Office-Erweiterungen
- Winsock-Komponenten
- bekannte Registry-Autostartorte
- Startordner verschiedener Benutzer
**Starten**
```cmd
[RO][PRIV][SENS] autoruns.exe
```
**Wichtige Funktionen**
| Funktion | Zweck |
|---|---|
| Hide Microsoft Entries | Microsoft-Einträge ausblenden |
| Hide Windows Entries | Windows-Einträge ausblenden |
| Verify Code Signatures | digitale Signaturen prüfen |
| Check VirusTotal | Hash beziehungsweise Datei über VirusTotal prüfen |
| Jump to Entry | Registry- oder Dateisystemeintrag öffnen |
| Jump to Image | zugehörige Datei öffnen |
| Process Explorer | laufenden Prozess in Process Explorer öffnen |
| Compare | aktuellen Zustand mit gespeicherter Ausgabe vergleichen |
| User | Autostarts anderer Benutzer auswählen |
**Sicheres Deaktivieren**
Ein Kontrollkästchen kann deaktiviert werden, um einen Autostart vorübergehend abzuschalten. Das ist in der Regel besser reversibel als das sofortige Löschen des Eintrags.
```text
Eintrag deaktivieren
→ System oder Anwendung kontrolliert testen
→ Ergebnis dokumentieren
→ Eintrag bei ausbleibender Wirkung wieder aktivieren
```
> Ein unbekannter oder nicht signierter Autostarteintrag ist nicht automatisch schädlich. Vor einer Änderung müssen Pfad, Herausgeber, Signatur, Zweck, Abhängigkeiten und betroffene Anwendung geprüft werden.
12. Autorunsc – Autostarts per Befehlszeile erfassen
`Autorunsc` ist die Befehlszeilenversion von Autoruns und eignet sich für dokumentierbare Bestandsaufnahmen.
**Grundlegende Ausgabe**
```cmd
[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s
```
Dabei können abhängig von der Werkzeugversion und den gewählten Optionen unter anderem Autostartkategorie, Pfad, Signatur und Hash ausgegeben werden.
**CSV-Datei erzeugen**
```cmd
[RO][PRIV][SENS] autorunsc.exe -a * -c -h -s > "C:\Diagnose\autoruns.csv"
```
**Nur Microsoft-Einträge ausblenden**
```cmd
[RO][PRIV][SENS] autorunsc.exe -a * -m -c -h -s
```
**Vor einer produktiven Erfassung prüfen**
```cmd
[RO] autorunsc.exe /?
```
> Die verfügbaren Parameter können sich mit Werkzeugversionen verändern. Vor automatisierter Verwendung muss die Hilfe der tatsächlich eingesetzten Version geprüft werden.
13. VirusTotal-Integration datenschutzgerecht verwenden
Mehrere Sysinternals-Werkzeuge können Hashwerte oder Dateien mit VirusTotal abgleichen.
Dabei muss unterschieden werden zwischen:
- Übermittlung eines Hashwertes
- Abfrage eines bereits bekannten Ergebnisses
- Hochladen einer unbekannten Datei
- automatischer Übermittlung unbekannter Dateien
**Mögliche Risiken**
- interne Dateinamen werden offengelegt
- proprietäre Anwendungen werden hochgeladen
- Konfigurationsdateien enthalten Geschäftsgeheimnisse
- Dateien enthalten personenbezogene Daten
- Skripte enthalten Servernamen oder Zugangsdaten
- Upload verstößt gegen Unternehmensrichtlinien
> Die Übermittlung einer internen Datei an einen externen Analysedienst darf nicht automatisch erfolgen. Vorher müssen Datenschutz, Geheimhaltung, Eigentumsrechte und Sicherheitsvorgaben geprüft werden.
Ein VirusTotal-Ergebnis ist außerdem kein alleiniger Beweis:
- einzelne Erkennung kann ein Fehlalarm sein
- keine Erkennung schließt Schadsoftware nicht aus
- Bewertung kann sich später ändern
- signierte Dateien können trotzdem missbraucht werden
14. TCPView – Netzwerkverbindungen Prozessen zuordnen
TCPView zeigt aktive TCP- und UDP-Endpunkte mit den zugehörigen Prozessen an.
**Starten**
```cmd
[RO][PRIV][SENS] tcpview.exe
```
**Typische Informationen**
- Prozessname
- PID
- Protokoll
- lokale Adresse
- lokaler Port
- entfernte Adresse
- Remoteport
- TCP-Zustand
- gesendete und empfangene Daten
- Erstellungszeitpunkt einer Verbindung
**Typische Anwendungsfälle**
- Welcher Prozess verbindet sich mit einem Server?
- Welcher Prozess lauscht auf einem Port?
- Warum existieren unerwartet viele Verbindungen?
- Welche Remoteadresse verwendet eine Anwendung?
- Ist der erwartete Dienstport geöffnet?
- Welche Verbindung wird beim Start einer Anwendung aufgebaut?
**Befehlszeilenversion**
```cmd
[RO][PRIV][SENS] tcpvcon.exe -a -c
```
Vor der Verwendung sollte die lokale Hilfe geprüft werden:
```cmd
[RO] tcpvcon.exe /?
```
> Eine Verbindung zu einer unbekannten IP-Adresse ist kein automatischer Sicherheitsvorfall. Content-Delivery-Netzwerke, Cloudplattformen, Telemetrie, Updates, Proxys und gemeinsam genutzte Infrastrukturen können die Zuordnung erschweren.
15. RAMMap – physischen Arbeitsspeicher analysieren
RAMMap zeigt, wie Windows den physischen Arbeitsspeicher verwendet.
**Starten**
```cmd
[RO][PRIV][SENS] rammap.exe
```
**Wichtige Ansichten**
| Ansicht | Inhalt |
|---|---|
| Use Counts | Speicher nach Verwendungsart |
| Processes | Speicherzuordnung nach Prozessen |
| Priority Summary | Speicher nach Prioritätsklassen |
| Physical Pages | einzelne physische Speicherseiten |
| Physical Ranges | physische Speicherbereiche |
| File Summary | im Speicher gehaltene Dateidaten |
| File Details | einzelne Dateiseiten |
| Page Table | Speicher für Seitentabellen |
**Wichtige Speicherbegriffe**
| Begriff | Bedeutung |
|---|---|
| Active | aktuell verwendete Speicherseiten |
| Standby | zwischengespeicherte Seiten, die bei Bedarf wiederverwendet werden können |
| Modified | veränderte Seiten, die vor Wiederverwendung geschrieben werden müssen |
| Free | unmittelbar freier Speicher |
| Zeroed | gelöschte und zur Wiederverwendung vorbereitete Seiten |
| Driver Locked | durch Treiber gesperrte Speicherseiten |
| Metafile | Dateisystem-Metadaten im Cache |
**Bewertungsregeln**
- Wenig vollständig freier RAM ist nicht automatisch problematisch.
- Windows nutzt freien Speicher gezielt als Cache.
- Ein großer Standby-Bereich kann normal sein.
- Hohe Commit-Nutzung muss zusammen mit Commit-Limit und Auslagerungsdatei bewertet werden.
- Ein ungewöhnlich großer nicht ausgelagerter Pool kann auf einen Treiberfehler hindeuten.
- Ein einzelner Snapshot beweist noch kein Speicherleck.
RAMMap enthält Funktionen zum Leeren bestimmter Speicherlisten. Diese verändern den Speicherzustand und können die Leistung vorübergehend verschlechtern.
> Speicherlisten dürfen nicht routinemäßig geleert werden, nur um eine niedrigere RAM-Anzeige zu erzeugen. Dadurch wird die Ursache eines Speicherproblems nicht behoben.
16. VMMap – virtuellen Speicher eines Prozesses untersuchen
VMMap analysiert den virtuellen und physischen Speicher eines einzelnen Prozesses.
**Starten**
```cmd
[RO][PRIV][SENS] vmmap.exe
```
Anschließend wird ein laufender Prozess ausgewählt oder eine Anwendung durch VMMap gestartet.
**Untersuchte Speicherarten**
- Image
- Heap
- Stack
- Private Data
- Shareable
- Mapped File
- Page Table
- Managed Heap
- reservierter Adressraum
- zugesicherter Speicher
- Working Set
**Typische Anwendungsfälle**
- wächst der private Speicher fortlaufend?
- welcher Heap wächst?
- besitzt der Prozess ungewöhnlich viele Speicherabbildungen?
- wird viel Adressraum nur reserviert?
- wie unterscheiden sich zwei Zustände desselben Prozesses?
- entsteht der Speicherverbrauch im nativen oder verwalteten Bereich?
**Sinnvolle Vorgehensweise bei vermutetem Speicherleck**
1. Anwendung in einem definierten Ausgangszustand starten.
2. ersten VMMap-Snapshot erfassen.
3. reproduzierbare Aktion mehrfach ausführen.
4. zweiten Snapshot erfassen.
5. Snapshots vergleichen.
6. wachsende Speichertypen identifizieren.
7. Ergebnis mit Prozessmetriken, Dumps und Anwendungsprotokollen abgleichen.
> Ein wachsender Working Set allein beweist kein Speicherleck. Caches und noch erreichbare, später freigegebene Daten können ebenfalls wachsen.
17. ProcDump – Speicherabbilder bei bestimmten Ereignissen erzeugen
ProcDump kann Speicherabbilder eines Prozesses erzeugen, wenn festgelegte Bedingungen eintreten.
Mögliche Auslöser sind unter anderem:
- unbehandelte Ausnahme
- Prozessabsturz
- hohe CPU-Auslastung
- niedrige CPU-Auslastung
- nicht reagierendes Fenster
- bestimmter Leistungsindikator
- manuell angeforderter Dump
- Prozessstart
**Hilfe der installierten Version anzeigen**
```cmd
[RO] procdump.exe -?
```
**Manuelles vollständiges Speicherabbild eines Prozesses**
```cmd
[TEST][PRIV][SENS] procdump.exe -ma "C:\Diagnose"
```
**Auf Prozessnamen warten und vollständigen Dump bei Ausnahme erzeugen**
```cmd
[TEST][PRIV][SENS] procdump.exe -ma -e -w "" "C:\Diagnose"
```
**Dump bei nicht reagierendem Fenster**
```cmd
[TEST][PRIV][SENS] procdump.exe -ma -h "" "C:\Diagnose"
```
**Überwachung beenden**
Die betreffende ProcDump-Instanz muss kontrolliert beendet werden, wenn die Diagnose abgeschlossen ist.
**Wichtige Planungsfragen**
- Wie viele Dumps dürfen entstehen?
- Wie groß kann jeder Dump werden?
- Ist ausreichend Speicherplatz vorhanden?
- Tritt der Fehler in einem sensiblen Prozess auf?
- Wer darf die Dumps lesen?
- Wie lange werden sie gespeichert?
- Welcher Debugger wird zur Analyse verwendet?
> Vollständige Prozessabbilder können Passwörter, Tokens, Schlüssel, Dokumentinhalte, Datenbanksätze und andere Geheimnisse enthalten. Sie müssen wie hochsensible Daten geschützt werden.
18. Sysmon – sicherheitsrelevante Systemereignisse protokollieren
System Monitor, kurz Sysmon, ist ein Windows-Systemdienst mit Gerätetreiber. Nach der Installation protokolliert er ausgewählte Systemaktivitäten in das Windows-Ereignisprotokoll.
Sysmon kann abhängig von Version und Konfiguration unter anderem erfassen:
- Prozessstarts
- Prozessbeendigungen
- Netzwerkverbindungen
- Erstellung von Dateien
- Änderung von Dateierstellungszeiten
- Laden von Treibern
- Laden von Images und DLLs
- Zugriffe auf Prozesse
- Registryereignisse
- Named Pipes
- DNS-Abfragen
- WMI-Aktivitäten
- Zwischenablageänderungen
- Dateilöschungen
- ausführbare Dateien in bestimmten Ereignissen
- Änderungen an Sysmon selbst
**Wichtiger Speicherort**
```text
Anwendungs- und Dienstprotokolle
→ Microsoft
→ Windows
→ Sysmon
→ Operational
```
**Sysmon mit Konfiguration installieren**
```cmd
[CHANGE][PRIV] sysmon.exe -accepteula -i "C:\Konfiguration\sysmon-config.xml"
```
**Konfiguration aktualisieren**
```cmd
[CHANGE][PRIV] sysmon.exe -c "C:\Konfiguration\sysmon-config.xml"
```
**Aktuelle Konfiguration anzeigen**
```cmd
[RO][PRIV][SENS] sysmon.exe -c
```
**Sysmon deinstallieren**
```cmd
[CHANGE][PRIV] sysmon.exe -u
```
> Sysmon besitzt keine automatische Alarmierungs- oder Bewertungslogik. Die Ereignisse müssen durch geeignete Regeln, ein SIEM, ein EDR-System oder eine kontrollierte manuelle Analyse ausgewertet werden.
19. Sysmon-Konfiguration fachgerecht planen
Eine Sysmon-Konfiguration bestimmt, welche Ereignisse einbezogen oder ausgeschlossen werden.
**Ziele einer guten Konfiguration**
- relevante Sicherheitsereignisse erfassen
- unnötige Ereignismengen begrenzen
- wichtige Systemprogramme nicht pauschal ausblenden
- Regeln dokumentieren
- Konfigurationsänderungen versionieren
- Speicherbedarf und Ereignisrate überwachen
- Auswertung durch SIEM oder Monitoring berücksichtigen
**Risiken einer ungeprüften Konfiguration**
- zu viele Ereignisse überlasten Sammlung und Auswertung
- zu breite Ausschlüsse erzeugen blinde Flecken
- sensible Befehlszeilen werden zentral gespeichert
- DNS-Abfragen offenbaren Benutzeraktivitäten
- Dateipfade enthalten personenbezogene Daten
- Regeländerungen beeinflussen Erkennungsmechanismen
- unterschiedliche Systeme benötigen unterschiedliche Filter
**Beispiel einer minimalen XML-Grundstruktur**
```xml
```
Die erforderliche Schemaversion und die unterstützten Ereignisse müssen mit der tatsächlich verwendeten Sysmon-Version geprüft werden.
**Konfigurationsschema anzeigen**
```cmd
[RO] sysmon.exe -s
```
> Eine fremde Sysmon-Konfiguration sollte nicht ungeprüft in einer produktiven Umgebung übernommen werden. Sie muss an Systeme, Anwendungen, Datenschutz, Ereignissammlung und Erkennungsziele angepasst werden.
20. Sigcheck – Signaturen, Versionen und Hashwerte untersuchen
Sigcheck zeigt Datei- und Signaturinformationen an.
**Einzelne Datei untersuchen**
```cmd
[RO][SENS] sigcheck.exe -a -h -i ""
```
**Verzeichnis rekursiv untersuchen**
```cmd
[RO][SENS] sigcheck.exe -s -a -h ""
```
**Nicht signierte Dateien suchen**
```cmd
[RO][SENS] sigcheck.exe -u -e ""
```
**CSV-Ausgabe**
```cmd
[RO][SENS] sigcheck.exe -c -h ""
```
**Typische Prüfungen**
- Herausgeber stimmt mit erwarteter Software überein
- Signaturstatus ist gültig
- Dateipfad ist plausibel
- Produkt- und Dateiversion passen zusammen
- Hash stimmt mit einer bekannten Referenz überein
- Datei wurde nicht aus einem temporären oder Benutzerverzeichnis nachgeladen
> Auch legitime Programme können unsignierte Komponenten besitzen. Umgekehrt kann eine gültig signierte Datei für unerwünschte Zwecke missbraucht oder mit einem kompromittierten Zertifikat signiert worden sein.
21. ListDLLs – geladene DLLs anzeigen
ListDLLs zeigt geladene DLLs und deren Pfade an.
**Alle geladenen DLLs anzeigen**
```cmd
[RO][PRIV][SENS] listdlls.exe
```
**DLLs eines bestimmten Prozesses**
```cmd
[RO][PRIV][SENS] listdlls.exe
```
Alternativ kann nach einem Prozessnamen gefiltert werden:
```cmd
[RO][PRIV][SENS] listdlls.exe ""
```
**Nach einer bestimmten DLL suchen**
```cmd
[RO][PRIV][SENS] listdlls.exe -d ""
```
**Typische Auffälligkeiten**
- DLL aus einem unerwarteten Benutzerverzeichnis
- mehrere Versionen derselben Komponente
- DLL aus einem temporären Verzeichnis
- fehlende oder ungültige Signatur
- Prozess lädt nicht die erwartete Bibliothek
- unerwartete Drittanbieter-Erweiterung
> Der Dateiname allein ist nicht ausreichend. Pfad, Version, Signatur, Hash, Ladegrund und Anwendungskontext müssen gemeinsam bewertet werden.
22. Strings – lesbare Zeichenfolgen in Dateien suchen
Strings extrahiert lesbare ANSI- und Unicode-Zeichenfolgen aus Binärdateien.
**Datei untersuchen**
```cmd
[RO][SENS] strings.exe ""
```
**Mindestlänge festlegen**
```cmd
[RO][SENS] strings.exe -n 8 ""
```
**Ausgabe nach einem Begriff filtern**
```cmd
[RO][SENS] strings.exe -n 8 "" | findstr /i ""
```
**Mögliche Anwendungsfälle**
- eingebettete URLs finden
- Fehlermeldungen erkennen
- Dateipfade finden
- Produkt- oder Debuginformationen erkennen
- verdächtige Befehlszeilen entdecken
- Hinweise auf eingebettete Konfigurationen erhalten
**Einschränkungen**
- komprimierte oder verschlüsselte Inhalte werden nicht automatisch verständlich
- gefundene Zeichenfolge muss nicht ausgeführt oder verwendet werden
- zufällige Bytefolgen können wie Text aussehen
- Ausgabe kann Zugangsdaten oder andere Geheimnisse enthalten
> Strings ist ein Hinweiswerkzeug und kein vollständiges Verfahren zur Malwareanalyse oder zum Reverse Engineering.
23. Streams – alternative NTFS-Datenströme untersuchen
NTFS-Dateien können neben dem normalen Dateiinhalt alternative Datenströme besitzen. Windows verwendet solche Datenströme unter anderem für Herkunftsinformationen heruntergeladener Dateien.
**Datenströme anzeigen**
```cmd
[RO][SENS] streams.exe ""
```
**Verzeichnis rekursiv untersuchen**
```cmd
[RO][SENS] streams.exe -s ""
```
**Alternative Datenströme löschen**
```cmd
[CHANGE][DANGER] streams.exe -d ""
```
> Das pauschale Löschen alternativer Datenströme kann Sicherheitskennzeichnungen wie Herkunftsinformationen entfernen und dadurch Schutzfunktionen beeinflussen. Vorher müssen Inhalt, Zweck und Auswirkungen geprüft werden.
PowerShell kann Datenströme ebenfalls anzeigen:
```powershell
[RO][SENS] Get-Item "" -Stream *
```
24. AccessChk – effektive Zugriffsrechte untersuchen
AccessChk zeigt Zugriffsrechte auf verschiedene Windows-Objekte an.
Dazu gehören unter anderem:
- Dateien
- Verzeichnisse
- Registryschlüssel
- Dienste
- Prozesse
- Kernelobjekte
- Freigaben
- benannte Pipes
**Hilfe anzeigen**
```cmd
[RO] accesschk.exe /?
```
**Verzeichnisrechte untersuchen**
```cmd
[RO][PRIV][SENS] accesschk.exe -d ""
```
**Rechte eines bestimmten Kontos prüfen**
```cmd
[RO][PRIV][SENS] accesschk.exe -d "" ""
```
**Dienstrechte untersuchen**
```cmd
[RO][PRIV][SENS] accesschk.exe -c ""
```
**Typische Anwendungsfälle**
- besitzt ein Benutzer tatsächlich Schreibzugriff?
- darf eine Gruppe einen Dienst konfigurieren?
- existieren übermäßig weitreichende Rechte?
- unterscheidet sich der Benutzerkontext vom Administratorkontext?
- ist ein sensibles Verzeichnis für normale Benutzer beschreibbar?
> AccessChk-Ausgaben müssen zusammen mit Vererbung, Gruppenmitgliedschaften, Integritätsstufe, Privilegien, Freigaberechten und dem tatsächlichen Benutzerkontext bewertet werden.
25. AccessEnum und ShareEnum
**AccessEnum**
AccessEnum stellt Berechtigungen für Dateien, Verzeichnisse und Registrybereiche übersichtlich dar. Es kann helfen, Abweichungen innerhalb größerer Strukturen zu finden.
```cmd
[RO][PRIV][SENS] accessenum.exe
```
Typische Verwendung:
- Verzeichnis oder Registrybereich auswählen
- Berechtigungen erfassen
- auffällige Abweichungen untersuchen
- Zustand speichern
- späteren Zustand vergleichen
**ShareEnum**
ShareEnum untersucht SMB-Freigaben und deren Sicherheitseinstellungen innerhalb erreichbarer Netzwerkbereiche.
```cmd
[RO][PRIV][REMOTE][SENS] shareenum.exe
```
**Zu prüfen sind unter anderem**
- unerwartete Freigaben
- zu breite Freigabeberechtigungen
- administrative Freigaben
- erreichbare Systeme
- Kombination aus Freigabe- und NTFS-Rechten
- nicht mehr benötigte Freigaben
> ShareEnum darf nur in ausdrücklich freigegebenen Netzwerkbereichen verwendet werden. Eine technische Erreichbarkeit ist keine Berechtigung zum Scannen.
26. PsTools – lokale und entfernte Administration
PsTools ist eine Sammlung von Befehlszeilenwerkzeugen für lokale und entfernte Windows-Systeme.
**Wichtige Werkzeuge**
| Werkzeug | Hauptfunktion |
|---|---|
| PsExec | Prozess lokal oder remote starten |
| PsInfo | Systeminformationen abrufen |
| PsList | Prozesse und Threads anzeigen |
| PsKill | Prozesse beenden |
| PsService | Dienste anzeigen oder steuern |
| PsLoggedOn | angemeldete Benutzer untersuchen |
| PsLogList | Ereignisprotokolle ausgeben |
| PsFile | remote geöffnete Dateien anzeigen |
| PsPing | Netzwerklatenz und Durchsatz testen |
| PsShutdown | Computer herunterfahren oder neu starten |
| PsSuspend | Prozesse anhalten oder fortsetzen |
| PsGetSid | SID eines Computers oder Kontos anzeigen |
**Systeminformationen lokal abrufen**
```cmd
[RO][SENS] psinfo.exe
```
**Systeminformationen remote abrufen**
```cmd
[RO][REMOTE][SENS] psinfo.exe \\
```
**Prozesse remote anzeigen**
```cmd
[RO][REMOTE][SENS] pslist.exe \\
```
**Angemeldete Benutzer untersuchen**
```cmd
[RO][REMOTE][SENS] psloggedon.exe \\
```
> PsTools können administrative Remoteaktionen ausführen. Authentifizierung, Firewall, administrative Freigaben, Sicherheitsrichtlinien, Protokollierung und Auswirkungen auf das Zielsystem müssen vorher geklärt werden.
27. PsExec sicher einsetzen
PsExec kann Prozesse lokal oder auf entfernten Windows-Systemen starten.
**Remote-Befehlszeile starten**
```cmd
[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\ cmd.exe
```
**Befehl remote ausführen**
```cmd
[CHANGE][PRIV][REMOTE][SENS] psexec.exe \\ ipconfig /all
```
**Prozess als lokales Systemkonto starten**
```cmd
[CHANGE][PRIV][DANGER] psexec.exe -s -i cmd.exe
```
Der letzte Befehl erzeugt einen besonders privilegierten Kontext und darf nur für klar begründete administrative Diagnosen verwendet werden.
**Sicherheitsregeln**
- keine Passwörter offen in der Befehlszeile übergeben
- nur eindeutig bestimmten Zielcomputer verwenden
- aktiven Benutzer und Auswirkungen prüfen
- keine interaktive Sitzung unbeaufsichtigt lassen
- erzeugte Dienste und Prozesse kontrollieren
- Remotezugriff protokollieren
- keine dauerhafte Umgehung regulärer Verwaltungswege
- Befehle zunächst lokal oder in einer Testumgebung prüfen
> Anmeldeinformationen in einer Befehlszeile können in Prozesslisten, Protokollen, Shellverläufen oder Diagnoseaufzeichnungen sichtbar werden.
28. PsPing – Netzwerkverbindungen und Leistung testen
PsPing erweitert einfache Ping-Tests um TCP-Verbindungs-, Latenz- und Durchsatzmessungen.
**ICMP-Test**
```cmd
[TEST][SENS] psping.exe
```
**TCP-Port testen**
```cmd
[TEST][SENS] psping.exe :
```
Beispiel:
```cmd
[TEST][SENS] psping.exe server.example:443
```
**Längere Messung**
```cmd
[TEST][SENS] psping.exe -n 20 server.example:443
```
Für Bandbreitenmessungen ist eine passende PsPing-Instanz als Empfänger erforderlich. Die genauen Parameter müssen anhand der Hilfe der eingesetzten Version gewählt werden:
```cmd
[RO] psping.exe /?
```
**Bewertungsregeln**
- TCP-Erreichbarkeit bestätigt nicht die korrekte Anwendung.
- Durchsatztests erzeugen zusätzliche Netzlast.
- Messergebnisse hängen von Gegenstelle, Route und Systemlast ab.
- kurze Tests können sporadische Störungen übersehen.
- Sicherheitssoftware kann Testverbindungen blockieren.
- Tests gegen fremde Systeme benötigen eine Freigabe.
29. AD Explorer – Active Directory untersuchen
AD Explorer ist ein grafischer Viewer und Editor für Active Directory.
Das Werkzeug kann:
- AD-Objekte durchsuchen
- Attribute anzeigen
- Objekteigenschaften untersuchen
- Suchabfragen speichern
- Snapshots einer AD-Datenbank erstellen
- zwei Snapshots vergleichen
- zugehörige Sicherheitsinformationen anzeigen
**Starten**
```cmd
[RO][PRIV][REMOTE][SENS] adexplorer.exe
```
**Typische Anwendungsfälle**
- Attribut eines Benutzers oder Computers prüfen
- Gruppenmitgliedschaften nachvollziehen
- Distinguished Name kontrollieren
- Replikations- oder Änderungsstände vergleichen
- Objekte anhand bestimmter Attribute suchen
- Zustand vor und nach einer administrativen Änderung vergleichen
**Risiken**
AD Explorer kann nicht nur lesen, sondern bei ausreichenden Rechten auch Objekte verändern. Ein versehentliches Ändern oder Löschen kann Domänendienste und Anwendungen beeinträchtigen.
> Für reine Diagnosezwecke sollte nach Möglichkeit ein Konto mit nur den notwendigen Leserechten verwendet werden.
Snapshots können enthalten:
- Benutzernamen
- Gruppenstrukturen
- Computernamen
- E-Mail-Adressen
- organisatorische Strukturen
- sicherheitsrelevante Attribute
- interne Server- und Domäneninformationen
Sie müssen entsprechend geschützt werden.
30. AD Insight und AD Restore
**AD Insight**
AD Insight überwacht LDAP-Clientaufrufe eines Prozesses und kann helfen, Active-Directory-Kommunikation einer Anwendung zu untersuchen.
Typische Fragen:
- Welche LDAP-Abfrage führt die Anwendung aus?
- Welcher Domänencontroller wird angesprochen?
- Welche Attribute werden angefordert?
- Welche LDAP-Fehler treten auf?
- Wiederholt eine Anwendung unnötig viele Abfragen?
```cmd
[TEST][PRIV][SENS] adinsight.exe
```
Die Aufzeichnung kann sehr viele interne Verzeichnisinformationen enthalten.
**AD Restore**
AD Restore kann gelöschte Active-Directory-Objekte untersuchen und in unterstützten Fällen wiederherstellen.
```cmd
[RO][PRIV][SENS] adrestore.exe
```
Eine tatsächliche Wiederherstellung verändert Active Directory:
```text
[CHANGE][PRIV][DANGER]
```
> AD Restore darf nicht ohne Kenntnis von AD-Papierkorb, Tombstone-Zustand, Replikation, Objektabhängigkeiten, Wiederherstellungsziel und organisatorischer Freigabe eingesetzt werden.
31. Coreinfo – CPU- und Virtualisierungsfunktionen prüfen
Coreinfo zeigt die Zuordnung logischer Prozessoren sowie unterstützte Prozessor- und Virtualisierungsfunktionen an.
**Starten**
```cmd
[RO] coreinfo.exe
```
**Virtualisierungsbezogene Informationen**
```cmd
[RO] coreinfo.exe -v
```
**Typische Anwendungsfälle**
- unterstützt die CPU benötigte Virtualisierungsfunktionen?
- sind Funktionen durch Firmware oder Hypervisor beeinflusst?
- wie sind logische Prozessoren, Kerne und NUMA-Knoten zugeordnet?
- stehen benötigte Befehlssatzerweiterungen zur Verfügung?
- unterscheidet sich ein System von einem funktionierenden Vergleichssystem?
> Die Anzeige einer CPU-Funktion beweist nicht automatisch, dass sie von Firmware, Betriebssystem, Hypervisor und Anwendung vollständig nutzbar ist.
32. BgInfo – Systeminformationen auf dem Desktop anzeigen
BgInfo kann technische Systeminformationen in den Desktophintergrund einblenden.
Mögliche Angaben:
- Computername
- IP-Adresse
- Betriebssystemversion
- Domäne
- Benutzer
- letzter Startzeitpunkt
- Prozessor
- Arbeitsspeicher
- freier Speicherplatz
- benutzerdefinierte Werte
**Starten**
```cmd
[RO][SENS] bginfo.exe
```
BgInfo eignet sich beispielsweise für:
- Schulungs- und Testsysteme
- Serverkonsolen
- virtuelle Maschinen
- schnelle Identifikation eines Zielsystems
- kontrollierte Supportumgebungen
**Datenschutz beachten**
Auf gemeinsam betrachteten Desktops dürfen keine unnötigen sensiblen Angaben angezeigt werden. Dazu gehören beispielsweise:
- öffentliche IP-Adressen
- interne Domänenstrukturen
- personenbezogene Benutzerdaten
- geheime Systemkennungen
- vertrauliche Inventarnummern
> BgInfo ist eine Anzeigehilfe und kein Werkzeug zur laufenden Zustandsüberwachung.
33. Disk2vhd – Datenträgerabbild als virtuelle Festplatte
Disk2vhd erstellt virtuelle Festplattendateien aus Volumes eines laufenden Windows-Systems. Dafür kann der Volumeschattenkopie-Dienst verwendet werden, um einen konsistenteren Zeitpunkt abzubilden.
**Starten**
```cmd
[TEST][PRIV][SENS] disk2vhd.exe
```
**Mögliche Anwendungsfälle**
- Testkopie eines Systems erstellen
- System für eine kontrollierte Analyse virtualisieren
- physisches System in eine virtuelle Testumgebung überführen
- Zustand eines Systems vor umfangreicher Analyse sichern
**Wichtige Grenzen**
- eine VHD- oder VHDX-Datei ist nicht automatisch ein vollständiges Backupkonzept
- laufende Anwendungen können zusätzliche Konsistenzanforderungen besitzen
- Datenbanken benötigen möglicherweise anwendungsspezifische Sicherung
- verschlüsselte Volumes müssen gesondert berücksichtigt werden
- Aktivierung und Lizenzierung können sich in einer VM verändern
- virtuelle Kopie darf nicht unkontrolliert parallel im produktiven Netzwerk starten
- gespeicherte Anmeldeinformationen bleiben möglicherweise enthalten
- die Datei kann nahezu alle Daten des Quellsystems enthalten
> Eine virtualisierte Kopie eines Produktivsystems muss isoliert gestartet werden, damit keine doppelten Computerkonten, IP-Adressen, Dienste oder automatischen Aufgaben das Produktivnetz beeinflussen.
34. LiveKd – laufenden Kernel mit Debugger untersuchen
LiveKd ermöglicht die Untersuchung eines laufenden Windows-Systems mit Microsoft-Kerneldebuggern, ohne die klassische Remote-Debuggingverbindung zu einem zweiten Computer aufzubauen.
**Starten**
```cmd
[TEST][PRIV][SENS] livekd.exe
```
Je nach Konfiguration wird ein kompatibler Microsoft-Debugger benötigt.
**Mögliche Anwendungsfälle**
- Kernelstrukturen untersuchen
- Treiberzustände betrachten
- Kernelstacks analysieren
- Speicher- und Objektinformationen prüfen
- Livezustand mit Debuggerbefehlen untersuchen
**Grenzen**
- das System verändert sich während der Untersuchung weiter
- Daten können zwischen Abfragen inkonsistent werden
- falsche Interpretation von Kernelstrukturen ist möglich
- Symbole müssen zur Systemversion passen
- Debuggerzugriff kann hochsensible Informationen offenlegen
> LiveKd ist ein spezialisiertes Werkzeug für fortgeschrittene Windows- und Treiberanalyse. Es sollte nicht ohne Debuggingkenntnisse auf produktiven Systemen eingesetzt werden.
35. WinObj – Windows-Objektmanager untersuchen
WinObj zeigt den Namensraum des Windows-Objektmanagers.
Darin können unter anderem sichtbar sein:
- Geräteobjekte
- symbolische Links
- Sessions
- Treiberobjekte
- Named Pipes
- BaseNamedObjects
- Dateisystemobjekte
- Kernelobjekte
**Starten**
```cmd
[RO][PRIV][SENS] winobj.exe
```
**Typische Anwendungsfälle**
- symbolische Objektverknüpfungen untersuchen
- Gerätedateien und Treiberobjekte nachvollziehen
- benannte Synchronisationsobjekte finden
- Unterschiede zwischen Sitzungen erkennen
- interne Objektpfade einer Anwendung prüfen
> WinObj zeigt interne Windows-Objekte. Die bloße Existenz eines unbekannten Objekts ist kein Beweis für einen Fehler oder eine Kompromittierung.
36. PendMoves und MoveFile – Dateioperationen beim Neustart
Wenn Dateien während des laufenden Betriebs nicht ersetzt oder gelöscht werden können, kann Windows Operationen für den nächsten Systemstart vormerken.
**Ausstehende Operationen anzeigen**
```cmd
[RO][PRIV][SENS] pendmoves.exe
```
**Datei beim nächsten Neustart verschieben**
```cmd
[CHANGE][PRIV][RESTART] movefile.exe "" ""
```
**Datei beim nächsten Neustart löschen**
```cmd
[CHANGE][PRIV][RESTART][DANGER] movefile.exe "" ""
```
**Risiken**
- falsche Systemdatei wird entfernt
- Anwendung startet nach Neustart nicht mehr
- Treiber oder Dienst fällt aus
- Abhängigkeiten werden erst nach Neustart sichtbar
- Rücknahme ist nach dem Start möglicherweise schwierig
> Vor dem Vormerken einer Löschung müssen Datei, Hersteller, Signatur, Anwendung, Wiederherstellungsweg und Auswirkungen eindeutig geklärt sein.
37. SDelete – sicher überschreiben
SDelete kann Dateien oder freien Speicherplatz überschreiben, um die Wiederherstellung gelöschter Daten zu erschweren.
**Hilfe anzeigen**
```cmd
[RO] sdelete.exe /?
```
**Datei sicher löschen**
```cmd
[CHANGE][PRIV][DANGER] sdelete.exe ""
```
**Freien Speicherplatz bearbeiten**
```cmd
[CHANGE][PRIV][DANGER] sdelete.exe -c
```
**Wichtige Einschränkungen**
- SSDs besitzen Wear-Leveling und interne Speicherverwaltung
- Speichercontroller können Daten umorganisieren
- virtuelle Datenträger besitzen zusätzliche Speicherschichten
- Snapshots und Backups bleiben unberührt
- Cloud- und SAN-Speicher abstrahieren die physische Ablage
- falscher Zielpfad kann nicht einfach rückgängig gemacht werden
> SDelete ist keine allgemeine Fehlerbehebungsmaßnahme. Vor dem Einsatz müssen Datenträgertyp, Sicherungen, Snapshots, Aufbewahrungspflichten und Löschkonzept geprüft werden.
38. NotMyFault nur in isolierten Testsystemen verwenden
NotMyFault kann absichtlich:
- Systemabstürze auslösen
- Systeme aufhängen
- Kernel-Speicherlecks erzeugen
- Treiberfehler simulieren
- hohe Last erzeugen
Das Werkzeug dient beispielsweise zum Testen von:
- Speicherabbildkonfiguration
- Überwachungssystemen
- Wiederanlaufverhalten
- Absturzanalysen
- Laborübungen
```cmd
[DANGER][PRIV][RESTART] notmyfault.exe
```
> NotMyFault darf niemals auf einem produktiven System, einem gemeinsam genutzten Schulungssystem oder einem nicht vollständig isolierten Testsystem ausprobiert werden. Es verursacht absichtlich schwerwiegende Störungen.
Vor einem Test müssen mindestens vorhanden sein:
- isolierte virtuelle Maschine
- aktueller Snapshot oder definierter Wiederherstellungsweg
- keine produktiven Daten
- kein Zugang zum Produktivnetz
- dokumentiertes Testszenario
- Kontrolle über Neustart und Speicherabbilder
- ausreichend Speicherplatz
- ausdrückliche Freigabe
39. Geeignetes Werkzeug nach Fehlerbild auswählen
| Fehlerbild | Geeignete Werkzeuge |
|---|---|
| Datei lässt sich nicht löschen | Process Explorer, Handle |
| Anwendung startet nicht | Process Monitor, Autoruns, Ereignisanzeige |
| Anwendung findet Datei nicht | Process Monitor |
| Zugriff verweigert | Process Monitor, AccessChk, AccessEnum |
| hohe CPU-Auslastung | Process Explorer, ProcDump, Leistungsüberwachung |
| wachsender RAM-Verbrauch | Process Explorer, VMMap, RAMMap, ProcDump |
| unbekannter Autostart | Autoruns, Sigcheck, Process Explorer |
| unbekannte Netzwerkverbindung | TCPView, Process Explorer, Sigcheck |
| sporadischer Absturz | ProcDump, Ereignisanzeige, WinDbg |
| unbekannte DLL | Process Explorer, ListDLLs, Sigcheck |
| verdächtige Datei | Sigcheck, Strings, Streams |
| Active-Directory-Abfrage fehlerhaft | AD Explorer, AD Insight |
| Remoteprozess untersuchen | PsList, PsInfo, PsLoggedOn |
| TCP-Latenz oder Durchsatz | PsPing |
| Kernel- oder Treiberproblem | LiveKd, WinDbg, Process Monitor |
| Startproblem durch Zusatzsoftware | Autoruns, Process Monitor Boot Logging |
| Speicheraufteilung unklar | RAMMap |
| Prozessspeicher im Detail | VMMap |
| ausstehende Dateilöschung | PendMoves |
| CPU-Funktion oder Virtualisierung | Coreinfo |
| Systemkopie für Laboranalyse | Disk2vhd |
40. Typischer Ablauf einer Sysinternals-Analyse
1. Originale Fehlermeldung erfassen.
2. Fehlerzeitpunkt dokumentieren.
3. betroffenen Computer und Benutzer bestätigen.
4. Reproduzierbarkeit prüfen.
5. integrierte Windows-Protokolle untersuchen.
6. kleinstes passende Sysinternals-Werkzeug auswählen.
7. Werkzeugquelle, Version und Signatur kontrollieren.
8. Berechtigungsbedarf prüfen.
9. mögliche sensible Daten berücksichtigen.
10. Aufzeichnung vorbereiten.
11. Filter möglichst eng festlegen.
12. Ausgangszustand dokumentieren.
13. Aufzeichnung starten.
14. Fehler einmal reproduzieren.
15. Aufzeichnung unmittelbar beenden.
16. Ereignisse zeitlich eingrenzen.
17. Prozess, Pfad, Benutzer, Operation und Ergebnis vergleichen.
18. normale Such- und Fehlversuche von relevanten Fehlern unterscheiden.
19. Befund mit Ereignisanzeige und Anwendungsprotokollen abgleichen.
20. Hypothese formulieren.
21. möglichst kleinen und reversiblen Test planen.
22. Sicherung und Rückfallplan prüfen.
23. Änderung durchführen.
24. Funktion erneut testen.
25. Diagnosewerkzeuge und temporäre Überwachung beenden.
26. Daten geschützt speichern oder ordnungsgemäß löschen.
27. Ursache, Maßnahme und Ergebnis dokumentieren.
41. Beispiel – Anwendung meldet „Datei nicht gefunden“
**Ausgangslage**
Eine Anwendung meldet beim Start, eine Konfigurationsdatei sei nicht vorhanden. Die Datei ist im erwarteten Verzeichnis sichtbar.
**Vorgehensweise**
1. tatsächlichen Anwendungsprozess bestimmen.
2. Process Monitor starten.
3. Aufzeichnung anhalten und leeren.
4. Filter auf den Prozessnamen setzen.
5. optional nach einem Teil des Dateinamens filtern.
6. Aufzeichnung starten.
7. Fehler reproduzieren.
8. Aufzeichnung beenden.
9. Operationen wie `CreateFile` untersuchen.
10. tatsächlich abgefragten Pfad prüfen.
11. Benutzerkontext kontrollieren.
12. Ergebnisse vor und nach dem Fehler vergleichen.
**Mögliche Befunde**
- Anwendung sucht in einem anderen Verzeichnis.
- Umgebungsvariable führt zu einem falschen Pfad.
- Dateiname oder Erweiterung weicht ab.
- Zugriff wird verweigert und als „nicht gefunden“ dargestellt.
- Anwendung läuft unter einem Dienstkonto.
- Datei wird zuerst gefunden, aber eine abhängige Datei fehlt.
- Registrywert enthält einen veralteten Pfad.
- 32-Bit- und 64-Bit-Dateisystemumleitung beeinflusst den Zugriff.
**Geeignete Ergänzungen**
- Process Explorer für Benutzer und Befehlszeile
- AccessChk für Berechtigungen
- Sigcheck für die Anwendungsdatei
- Ereignisanzeige für Folgefehler
42. Beispiel – Anwendung verbraucht immer mehr Arbeitsspeicher
**Vorgehensweise**
1. Ausgangswert im Task-Manager oder mit PowerShell erfassen.
2. Process Explorer zur Beobachtung verwenden.
3. Private Bytes, Working Set und Commit unterscheiden.
4. VMMap-Snapshot im Ausgangszustand speichern.
5. reproduzierbare Benutzeraktion mehrfach ausführen.
6. zweiten VMMap-Snapshot erstellen.
7. wachsende Speicherart bestimmen.
8. bei Bedarf ProcDump kontrolliert konfigurieren.
9. Speicherabbild mit geeignetem Debugger untersuchen.
10. Anwendungsversion und bekannte Fehler des Herstellers prüfen.
**Nicht ausreichend als Beweis**
- RAM-Anzeige steigt einmalig
- Working Set sinkt nicht sofort
- freier Speicher wird kleiner
- RAMMap zeigt großen Standby-Cache
- Prozess besitzt viele Speicherabbildungen
**Stärkerer Hinweis auf ein Leck**
Ein bestimmter Speicherbereich wächst bei wiederholbarer identischer Aktion fortlaufend, wird nicht wieder freigegeben und korreliert mit der Störung.
43. Beispiel – langsamer Anwendungsstart
**Geeignete Werkzeuge**
- Process Monitor
- Process Explorer
- Autoruns
- Ereignisanzeige
- Leistungsüberwachung
- ProcDump bei Hängern
**Vorgehensweise**
1. Startzeit reproduzierbar messen.
2. Process Monitor vorbereiten.
3. nur den Startvorgang aufzeichnen.
4. Ereignisse nach Dauer untersuchen.
5. wiederholte Datei- oder Registryzugriffe identifizieren.
6. Netzwerkpfade und Namensauflösung beachten.
7. untergeordnete Prozesse im Process Tree prüfen.
8. Signaturen und Pfade geladener Komponenten kontrollieren.
9. Ergebnis mit einem funktionierenden System vergleichen.
**Mögliche Ursachen**
- nicht erreichbarer Netzwerkpfad
- langsame DNS-Auflösung
- wiederholte Zertifikatsprüfung
- blockierende Sicherheitssoftware
- fehlende Datei mit wiederholten Suchversuchen
- langsame Benutzerprofilkomponente
- fehlerhafte Shell-Erweiterung
- veraltete Autostartkomponente
- stark ausgelasteter Datenträger
- Drittanbieter-DLL
- nicht erreichbarer Lizenzserver
44. Gefährliche Fehlinterpretationen vermeiden
| Beobachtung | Nicht automatisch bewiesen |
|---|---|
| Prozess ist nicht signiert | Prozess ist Schadsoftware |
| VirusTotal zeigt einen Treffer | Datei ist eindeutig schädlich |
| VirusTotal zeigt keinen Treffer | Datei ist sicher |
| Process Monitor zeigt `ACCESS DENIED` | Dieser Zugriff verursacht den Fehler |
| Process Monitor zeigt `NAME NOT FOUND` | Die Datei fehlt fehlerhaft |
| hohe Zahl offener Handles | Handle-Leck |
| viele TCP-Verbindungen | Angriff oder Schadsoftware |
| unbekannte Remote-IP | unberechtigter Datenverkehr |
| hoher Standby-Speicher | Arbeitsspeichermangel |
| Prozess besitzt hohen Working Set | Speicherleck |
| DLL liegt im Benutzerprofil | DLL ist bösartig |
| Autostarteintrag ist unbekannt | Eintrag darf gelöscht werden |
| Sysmon erzeugt kein Ereignis | Aktivität fand nicht statt |
| Prozess läuft als SYSTEM | Prozess ist legitim |
| Datei besitzt Microsoft im Namen | Datei stammt von Microsoft |
45. Diagnosedaten sicher speichern und weitergeben
Sysinternals-Ausgaben können enthalten:
- Benutzernamen
- Computer- und Domänennamen
- IP-Adressen
- Dateipfade
- Befehlszeilen
- Prozessumgebungen
- Registrywerte
- geöffnete Dokumente
- Netzwerkziele
- Sicherheitskennungen
- Anmeldesitzungen
- E-Mail-Adressen
- Tokens und Zugangsdaten
- Datei- und Speicherinhalte
- Active-Directory-Strukturen
**Vor der Weitergabe**
1. Empfänger und Zweck bestimmen.
2. erforderlichen Datenumfang begrenzen.
3. Datei auf Geheimnisse prüfen.
4. personenbezogene Daten redigieren.
5. verschlüsselten Übertragungsweg verwenden.
6. Zugriffsrechte beschränken.
7. Aufbewahrungsdauer festlegen.
8. Löschung dokumentieren.
9. öffentliche Uploadplattformen vermeiden.
10. Speicherabbilder besonders schützen.
**Besonders sensible Dateitypen**
| Dateityp | Risiko |
|---|---|
| PML-Aufzeichnung | Pfade, Registry, Prozesse, Benutzer und Aktivitäten |
| Prozessdump | vollständige Speicherinhalte des Prozesses |
| Kernel-Dump | umfangreiche System- und Speicherinformationen |
| AD-Explorer-Snapshot | Verzeichnisstruktur und Objektattribute |
| Autoruns-Export | Softwarebestand, Pfade und Autostarts |
| TCPView-Export | Netzwerkziele und Prozesszuordnung |
| Sysmon-Protokoll | Befehlszeilen, Hashwerte, DNS- und Netzwerkaktivität |
46. Schnelle Werkzeugübersicht
| Aufgabe | Werkzeug |
|---|---|
| Prozesshierarchie anzeigen | Process Explorer |
| offene Datei finden | Process Explorer, Handle |
| geladene DLLs prüfen | Process Explorer, ListDLLs |
| Datei- und Registryzugriffe verfolgen | Process Monitor |
| Bootaktivität aufzeichnen | Process Monitor |
| Autostarts untersuchen | Autoruns |
| Autostarts exportieren | Autorunsc |
| Netzwerkverbindungen zuordnen | TCPView |
| physische RAM-Nutzung analysieren | RAMMap |
| Prozessspeicher analysieren | VMMap |
| Prozessdump erstellen | ProcDump |
| dauerhafte Sicherheitsereignisse erfassen | Sysmon |
| Signatur und Hash prüfen | Sigcheck |
| lesbare Binärdateiinhalte finden | Strings |
| alternative NTFS-Datenströme anzeigen | Streams |
| Berechtigungen untersuchen | AccessChk |
| Berechtigungsabweichungen suchen | AccessEnum |
| Freigaben untersuchen | ShareEnum |
| Remoteprozesse starten | PsExec |
| Remoteprozesse anzeigen | PsList |
| Systeminformationen remote abrufen | PsInfo |
| angemeldete Benutzer prüfen | PsLoggedOn |
| Netzwerklatenz testen | PsPing |
| Active Directory durchsuchen | AD Explorer |
| LDAP-Aufrufe verfolgen | AD Insight |
| gelöschte AD-Objekte untersuchen | AD Restore |
| CPU-Funktionen anzeigen | Coreinfo |
| Systemdaten auf Desktop anzeigen | BgInfo |
| virtuelle Systemkopie erstellen | Disk2vhd |
| laufenden Kernel untersuchen | LiveKd |
| Objektmanager anzeigen | WinObj |
| ausstehende Dateioperationen anzeigen | PendMoves |
| Dateioperation für Neustart planen | MoveFile |
| Daten sicher überschreiben | SDelete |
| Absturz absichtlich erzeugen | NotMyFault – nur isoliertes Labor |
47. Dokumentationsvorlage
```text
Ticket:
Datum und Uhrzeit:
Bearbeiter:
Computername:
Windows-Version:
Build:
Architektur:
Benutzerkontext:
Betroffener Prozess:
PID:
Prozesspfad:
Befehlszeile:
Prozessherausgeber:
Signaturstatus:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Reproduktionsschritte:
Letzte funktionierende Nutzung:
Letzte Änderung:
Verwendetes Sysinternals-Werkzeug:
Werkzeugversion:
Bezugsquelle:
Hash des Werkzeugs:
Erhöht ausgeführt:
Startzeit der Aufzeichnung:
Endzeit der Aufzeichnung:
Verwendete Filter:
Verwendete Befehlszeile:
Speicherort der Diagnosedaten:
Relevanter Prozess:
Übergeordneter Prozess:
Benutzer:
Operation:
Objekt oder Pfad:
Ergebnis:
Zeitlicher Zusammenhang:
Vergleichssystem geprüft:
Normales Verhalten ausgeschlossen:
Autostarteintrag:
Signatur:
Hash:
VirusTotal verwendet:
Datei hochgeladen:
Freigabe für externen Dienst vorhanden:
Lokale Adresse:
Lokaler Port:
Remoteadresse:
Remoteport:
Verbindungsstatus:
Zugehöriger Prozess:
RAM-Ausgangswert:
RAM-Endwert:
Working Set:
Private Bytes:
Commit:
Wachsende Speicherart:
Dump erzeugt:
Dump-Typ:
Dump-Größe:
Dump geschützt gespeichert:
Sysmon-Konfiguration:
Sysmon-Ereignis-ID:
Ereignisquelle:
SIEM-Abfrage:
Vermutete Ursache:
Zusätzliche Datenquelle:
Geplante Änderung:
Sicherung geprüft:
Rückfallplan:
Änderung durchgeführt:
Neustart erforderlich:
Ergebnis nach Änderung:
Fehler erneut getestet:
Monitoring kontrolliert:
Temporäre Aufzeichnung beendet:
Diagnosedaten redigiert:
Aufbewahrungsfrist:
Abschluss:
```
---
**Merksatz**
> Sysinternals macht interne Windows-Abläufe sichtbar, bestimmt aber nicht automatisch deren Bedeutung. Erst die Verbindung aus Fehlerzeitpunkt, Prozess, Benutzerkontext, Pfad, Operation, Ergebnis, Systemzustand und Vergleichsdaten ermöglicht eine belastbare Ursachenanalyse.
**Quellen und weiterführende Dokumentation**
- [Microsoft Learn – Sysinternals](https://learn.microsoft.com/sysinternals/)
- [Microsoft Learn – Sysinternals Utilities](https://learn.microsoft.com/sysinternals/downloads/)
- [Microsoft Learn – Sysinternals Suite](https://learn.microsoft.com/sysinternals/downloads/sysinternals-suite)
- [Microsoft Learn – Sysinternals Live](https://learn.microsoft.com/sysinternals/)
- [Microsoft Learn – Sysinternals Suite im Microsoft Store](https://learn.microsoft.com/sysinternals/downloads/microsoft-store)
- [Microsoft Learn – Process Explorer](https://learn.microsoft.com/sysinternals/downloads/process-explorer)
- [Microsoft Learn – Process Monitor](https://learn.microsoft.com/sysinternals/downloads/procmon)
- [Microsoft Learn – Autoruns](https://learn.microsoft.com/sysinternals/downloads/autoruns)
- [Microsoft Learn – Handle](https://learn.microsoft.com/sysinternals/downloads/handle)
- [Microsoft Learn – TCPView](https://learn.microsoft.com/sysinternals/downloads/tcpview)
- [Microsoft Learn – RAMMap](https://learn.microsoft.com/sysinternals/downloads/rammap)
- [Microsoft Learn – VMMap](https://learn.microsoft.com/sysinternals/downloads/vmmap)
- [Microsoft Learn – ProcDump](https://learn.microsoft.com/sysinternals/downloads/procdump)
- [Microsoft Learn – Sysmon](https://learn.microsoft.com/sysinternals/downloads/sysmon)
- [Microsoft Learn – Sigcheck](https://learn.microsoft.com/sysinternals/downloads/sigcheck)
- [Microsoft Learn – ListDLLs](https://learn.microsoft.com/sysinternals/downloads/listdlls)
- [Microsoft Learn – Strings](https://learn.microsoft.com/sysinternals/downloads/strings)
- [Microsoft Learn – Streams](https://learn.microsoft.com/sysinternals/downloads/streams)
- [Microsoft Learn – AccessChk](https://learn.microsoft.com/sysinternals/downloads/accesschk)
- [Microsoft Learn – AccessEnum](https://learn.microsoft.com/sysinternals/downloads/accessenum)
- [Microsoft Learn – ShareEnum](https://learn.microsoft.com/sysinternals/downloads/shareenum)
- [Microsoft Learn – PsTools](https://learn.microsoft.com/sysinternals/downloads/pstools)
- [Microsoft Learn – PsExec](https://learn.microsoft.com/sysinternals/downloads/psexec)
- [Microsoft Learn – PsPing](https://learn.microsoft.com/sysinternals/downloads/psping)
- [Microsoft Learn – AD Explorer](https://learn.microsoft.com/sysinternals/downloads/adexplorer)
- [Microsoft Learn – AD Insight](https://learn.microsoft.com/sysinternals/downloads/adinsight)
- [Microsoft Learn – Coreinfo](https://learn.microsoft.com/sysinternals/downloads/coreinfo)
- [Microsoft Learn – BgInfo](https://learn.microsoft.com/sysinternals/downloads/bginfo)
- [Microsoft Learn – Disk2vhd](https://learn.microsoft.com/sysinternals/downloads/disk2vhd)
- [Microsoft Learn – LiveKd](https://learn.microsoft.com/sysinternals/downloads/livekd)
- [Microsoft Learn – WinObj](https://learn.microsoft.com/sysinternals/downloads/winobj)
- [Microsoft Learn – PendMoves und MoveFile](https://learn.microsoft.com/sysinternals/downloads/pendmoves)
- [Microsoft Learn – SDelete](https://learn.microsoft.com/sysinternals/downloads/sdelete)
- [Microsoft Learn – NotMyFault](https://learn.microsoft.com/sysinternals/downloads/notmyfault)
- [Microsoft Learn – Troubleshooting with the Windows Sysinternals Tools](https://learn.microsoft.com/sysinternals/resources/troubleshooting-book)
# 5.3 Windows Server, Active Directory und Gruppenrichtlinien
Windows-Server-Infrastrukturen bestehen häufig aus mehreren voneinander abhängigen Diensten. Eine Störung bei Anmeldung, Gruppenrichtlinien, Namensauflösung oder Dateizugriff kann deshalb ihre eigentliche Ursache in einem anderen Teilbereich haben.
Typische Abhängigkeiten sind:
- Active Directory Domain Services
- DNS
- Kerberos
- Netlogon
- Zeitsynchronisation
- AD-Replikation
- SYSVOL-Replikation
- Gruppenrichtlinien
- DHCP
- DFS und DFS-Replikation
- Zertifikatsdienste
- Netzwerkverbindungen und Firewalls
- Failovercluster
- Serverrollen und deren Datenbanken
Ein erfolgreicher Ping beweist weder eine funktionierende Domänenanmeldung noch eine fehlerfreie AD-Replikation. Ebenso beweist eine erfolgreiche Anmeldung nicht, dass alle Gruppenrichtlinien, DNS-Zonen oder Verzeichnisänderungen korrekt repliziert wurden.
---
**Kennzeichnung der Befehle**
| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | grundsätzlich nur lesende Diagnose |
| `[TEST]` | erzeugt Testzugriffe oder zusätzliche Protokolle |
| `[CHANGE]` | verändert Konfiguration, Cache oder Systemzustand |
| `[PRIV]` | erhöhte oder administrative Rechte erforderlich beziehungsweise sinnvoll |
| `[REMOTE]` | greift auf einen anderen Computer oder Dienst zu |
| `[SENS]` | Ausgabe kann interne oder personenbezogene Informationen enthalten |
| `[LOG]` | kann umfangreiche zusätzliche Protokolldaten erzeugen |
| `[DANGER]` | fehlerhafte Verwendung kann größere Störungen verursachen |
| `[RESTART]` | kann einen Neustart oder eine Dienstunterbrechung erfordern |
Die Kennzeichnungen sind Sicherheitshinweise dieser Dokumentation und nicht Bestandteil der eigentlichen Befehle.
---
1. Abhängigkeiten einer Windows-Domäne verstehen
Eine typische Domänenanmeldung umfasst mehrere Schritte:
1. Der Client ermittelt über DNS einen geeigneten Domain Controller.
2. Der DC-Locator berücksichtigt Domäne, Standort und verfügbare Dienste.
3. Client und Domain Controller prüfen ihre Vertrauensbeziehung.
4. Kerberos oder NTLM authentifiziert den Benutzer.
5. Active Directory liefert Benutzer-, Computer- und Gruppeninformationen.
6. SYSVOL stellt Gruppenrichtliniendateien und Anmeldeskripte bereit.
7. Der Gruppenrichtliniendienst ermittelt und verarbeitet passende GPOs.
8. Weitere Dienste stellen Profile, Laufwerke, Drucker oder Anwendungen bereit.
Daraus ergibt sich eine wichtige Diagnose-Reihenfolge:
1. lokaler Netzwerkzustand
2. IP-Konfiguration
3. DNS-Clientkonfiguration
4. DNS-Auflösung der Domänendienste
5. Erreichbarkeit eines geeigneten Domain Controllers
6. Uhrzeit und Zeitzone
7. Secure Channel
8. Kerberos-Tickets und SPNs
9. AD-Replikation
10. SYSVOL und DFS-Replikation
11. Gruppenrichtlinienverarbeitung
12. abhängige Serverrollen
> In Active Directory ist DNS Bestandteil der Dienstermittlung. Ein Client, der ausschließlich einen öffentlichen DNS-Server verwendet, kann zwar Internetnamen auflösen, aber normalerweise die internen Domänendienste nicht korrekt ermitteln.
2. Diagnosekontext und Ausgangslage dokumentieren
Vor der ersten Änderung müssen mindestens folgende Angaben erfasst werden:
- betroffener Benutzer
- betroffener Computer
- Domänenname
- Active-Directory-Standort
- verwendeter Domain Controller
- Zeitpunkt des Fehlers
- originale Fehlermeldung
- betroffene Anwendung oder Ressource
- einmalige oder wiederkehrende Störung
- Anzahl betroffener Systeme
- letzte bekannte funktionierende Nutzung
- letzte administrative Änderung
- kürzlich installierte Updates
- Netzwerksegment und VPN-Zustand
- Anmeldung lokal, zwischengespeichert oder gegen einen Domain Controller
- administrative oder normale Benutzersitzung
**Grundinformationen auf einem Client**
```cmd
[RO][SENS] hostname
[RO][SENS] whoami
[RO][SENS] whoami /upn
[RO][SENS] whoami /user
[RO][SENS] whoami /groups
[RO][SENS] systeminfo
[RO][SENS] ipconfig /all
```
**Domäneninformationen mit PowerShell**
```powershell
[RO][SENS] Get-CimInstance Win32_ComputerSystem |
Select-Object Name, Domain, PartOfDomain
```
**Anmelde- und Logonserver-Variablen**
```cmd
[RO][SENS] set LOGONSERVER
[RO][SENS] set USERDNSDOMAIN
[RO][SENS] set USERDOMAIN
```
> Die Variable `LOGONSERVER` ist ein nützlicher Hinweis, aber keine vollständige Aussage darüber, welcher Domain Controller bei allen späteren LDAP-, Kerberos-, DNS- oder GPO-Vorgängen verwendet wird.
3. Ereignisprotokolle gezielt untersuchen
Wichtige Protokolle befinden sich in der Ereignisanzeige unter:
```text
Ereignisanzeige
├── Windows-Protokolle
│ ├── Anwendung
│ ├── Sicherheit
│ └── System
└── Anwendungs- und Dienstprotokolle
└── Microsoft
└── Windows
```
Relevante Protokollbereiche können sein:
- ActiveDirectory_DomainService
- DNS-Server
- Directory Service
- DFS Replication
- GroupPolicy
- Kerberos
- KDC
- Netlogon
- Time-Service
- DHCP-Server
- FailoverClustering
- ServerManager
- CertificateServicesClient
- TerminalServices
- SMBClient und SMBServer
**GroupPolicy-Betriebsprotokoll**
```text
Anwendungs- und Dienstprotokolle
└── Microsoft
└── Windows
└── GroupPolicy
└── Operational
```
**Ereignisse per PowerShell abrufen**
```powershell
[RO][PRIV][SENS] Get-WinEvent -LogName System -MaxEvents 100
```
```powershell
[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100
```
**Nach Zeitraum und Ebene filtern**
```powershell
[RO][PRIV][SENS] Get-WinEvent -FilterHashtable @{
LogName = "System"
StartTime = (Get-Date).AddHours(-2)
Level = 2,3
}
```
**Verfügbare Protokolle suchen**
```powershell
[RO][SENS] Get-WinEvent -ListLog * |
Where-Object LogName -match "GroupPolicy|DNS|DFS|Kerberos|Netlogon|Failover"
```
> Ereignis-IDs dürfen nicht isoliert interpretiert werden. Quelle, Windows-Version, Ereignistext, Fehlercode, Zeitpunkt und begleitende Ereignisse müssen gemeinsam ausgewertet werden.
4. Domain Controller mit DCDiag prüfen
`dcdiag` führt verschiedene Tests für Domain Controller aus. Abhängig von den Parametern werden unter anderem Erreichbarkeit, DNS, Replikation, Dienste, Rolleninhaber und Verzeichnispartitionen geprüft.
**Grundprüfung des lokalen Domain Controllers**
```cmd
[TEST][PRIV][SENS] dcdiag
```
**Ausführliche Ausgabe**
```cmd
[TEST][PRIV][SENS] dcdiag /v
```
**Bestimmten Domain Controller prüfen**
```cmd
[TEST][PRIV][REMOTE][SENS] dcdiag /s:
```
**Alle Domain Controller des Unternehmensbereichs prüfen**
```cmd
[TEST][PRIV][REMOTE][SENS] dcdiag /e
```
**DNS-Tests ausführen**
```cmd
[TEST][PRIV][REMOTE][SENS] dcdiag /test:DNS /e /v
```
**Bestimmten Test ausführen**
```cmd
[TEST][PRIV][SENS] dcdiag /test:
```
**Ausgabe in Dateien schreiben**
```cmd
[TEST][PRIV][SENS] dcdiag /v /f:""
```
**Wichtige Bewertungsfragen**
- Welcher konkrete Test ist fehlgeschlagen?
- Welcher Domain Controller wurde geprüft?
- Welcher Partner oder Dienst war beteiligt?
- Handelt es sich um einen aktuellen oder historischen Fehler?
- Ist DNS korrekt konfiguriert?
- Sind notwendige Dienste gestartet?
- Funktioniert die Replikation aller Verzeichnispartitionen?
- Sind die FSMO-Rolleninhaber erreichbar?
- Ist SYSVOL freigegeben?
- Tritt der Fehler auf allen DCs oder nur auf einem DC auf?
> `dcdiag` liefert mehrere unabhängige Testergebnisse. Eine einzelne Warnung beweist nicht automatisch einen Gesamtausfall des Domain Controllers.
5. AD-Replikation mit Repadmin untersuchen
Active Directory ist ein Multi-Master-Verzeichnis. Änderungen werden zwischen Domain Controllern repliziert. Fehler können dazu führen, dass Benutzer, Gruppen, Kennwörter, Computerobjekte oder DNS-Daten auf verschiedenen DCs unterschiedliche Stände besitzen.
**Gesamtübersicht**
```cmd
[RO][PRIV][REMOTE][SENS] repadmin /replsummary
```
Die Ausgabe zeigt unter anderem:
- Quell- und Ziel-DCs
- Anzahl fehlgeschlagener Replikationen
- Fehlerquote
- größte Replikationsverzögerung
- Fehlercode
**Eingehende Replikationspartner anzeigen**
```cmd
[RO][PRIV][REMOTE][SENS] repadmin /showrepl
```
**Bestimmten Domain Controller untersuchen**
```cmd
[RO][PRIV][REMOTE][SENS] repadmin /showrepl
```
**Alle Domain Controller ausführlich untersuchen**
```cmd
[RO][PRIV][REMOTE][SENS] repadmin /showrepl * /csv
```
**Replikationswarteschlange anzeigen**
```cmd
[RO][PRIV][SENS] repadmin /queue
```
**Replikationsmetadaten eines Objekts untersuchen**
```cmd
[RO][PRIV][REMOTE][SENS] repadmin /showobjmeta ""
```
**Replikation anstoßen**
```cmd
[CHANGE][PRIV][REMOTE] repadmin /syncall /AdeP
```
Dieser Befehl darf nicht als erster Diagnoseschritt verwendet werden. Er verändert zwar keine AD-Objektinhalte direkt, löst aber Replikationsvorgänge aus und kann Netzwerk- sowie Systemlast erzeugen.
**Typische Fehlerbereiche**
| Fehler oder Beobachtung | Möglicher Prüfbereich |
|---|---|
| RPC-Server nicht verfügbar | DNS, Firewall, RPC, Routing, Dienste |
| Zugriff verweigert | Secure Channel, Kerberos, Berechtigungen, Zeit |
| Zielprinzipalname falsch | SPN, Computerkontokennwort, DNS, Kerberos |
| DNS-Nachschlagefehler | DNS-Client, Zonen, SRV-Records, Registrierung |
| große Replikationsverzögerung | Standortverbindungen, Zeitplan, Erreichbarkeit |
| nur eine Partition betroffen | Namenskontext und zuständiger Replikationspfad |
| nur ein DC betroffen | lokaler Dienst, DNS, Datenbank oder Netzwerkpfad |
> Eine manuell erfolgreich ausgelöste Replikation beweist nicht, dass Topologie, Zeitplan und automatische Replikation dauerhaft funktionieren.
6. Domain Controller über den DC-Locator ermitteln
Der DC-Locator ermittelt anhand von DNS-Daten, Domäne, Standort und Anforderungen einen geeigneten Domain Controller.
**Domain Controller ermitteln**
```cmd
[TEST][SENS] nltest /dsgetdc:
```
Beispiel:
```cmd
[TEST][SENS] nltest /dsgetdc:example.internal
```
**Ermittlung neu durchführen**
```cmd
[CHANGE][SENS] nltest /dsgetdc: /force
```
**Domain Controller auflisten**
```cmd
[RO][SENS] nltest /dclist:
```
**Standort des Computers anzeigen**
```cmd
[RO][SENS] nltest /dsgetsite
```
**Standortabdeckung eines DCs untersuchen**
```cmd
[RO][SENS] nltest /dsgetsite
```
**DNS-SRV-Einträge prüfen**
```cmd
[TEST][SENS] nslookup -type=SRV _ldap._tcp.dc._msdcs.
```
```cmd
[TEST][SENS] nslookup -type=SRV _kerberos._tcp.
```
Zu prüfen sind:
- werden mehrere erwartete Domain Controller geliefert?
- stimmen Namen und IP-Adressen?
- wird ein DC des erwarteten Standorts bevorzugt?
- existieren veraltete Einträge?
- sind LDAP- und Kerberos-SRV-Records vorhanden?
- verwendet der Client ausschließlich interne DNS-Server?
- erreicht der Client die ausgegebenen Server?
> Das direkte Eintragen eines Domain Controllers in die Hosts-Datei ersetzt die DNS-basierte Dienstermittlung nicht und kann die eigentliche Ursache verdecken.
7. Secure Channel prüfen
Domänenmitglieder besitzen ein Computerkonto mit einem Kennwort. Der Secure Channel verwendet diese Vertrauensbeziehung für die Kommunikation mit der Domäne.
**Secure Channel mit NLTest prüfen**
```cmd
[TEST][PRIV][REMOTE][SENS] nltest /sc_verify:
```
**Vertraute Domäne abfragen**
```cmd
[RO][PRIV][SENS] nltest /sc_query:
```
**PowerShell-Prüfung auf einem Domänenmitglied**
```powershell
[TEST][PRIV][REMOTE] Test-ComputerSecureChannel -Verbose
```
`Test-ComputerSecureChannel` ist für Domänenmitglieder vorgesehen. Die Interpretation auf Domain Controllern unterscheidet sich, weil DCs eigene Replikations- und Vertrauensmechanismen verwenden.
**Reparatur mit PowerShell**
```powershell
[CHANGE][PRIV][REMOTE][DANGER] Test-ComputerSecureChannel -Repair -Credential "\"
```
Vor einer Reparatur müssen geprüft werden:
- DNS-Konfiguration
- Erreichbarkeit eines Domain Controllers
- Uhrzeit
- Computerkonto im Active Directory
- mögliche doppelte Computernamen
- Wiederherstellung eines alten VM-Snapshots
- kürzlich erfolgte Domänenwiederaufnahme
- verwendete administrative Anmeldeinformationen
- Auswirkungen auf Dienste und geplante Aufgaben
> Ein Computer sollte nicht vorschnell aus der Domäne entfernt und wieder aufgenommen werden. Dadurch können Computerkonto, Zertifikate, lokale Profile, verschlüsselte Daten, Dienstkonten und Verwaltungszuordnungen beeinflusst werden.
8. DNS-Clientkonfiguration der Domänenmitglieder prüfen
**Vollständige IP-Konfiguration**
```cmd
[RO][SENS] ipconfig /all
```
**PowerShell-Übersicht**
```powershell
[RO][SENS] Get-DnsClientServerAddress
```
```powershell
[RO][SENS] Get-NetIPConfiguration
```
Zu prüfen sind:
- verwendete DNS-Server
- Reihenfolge der DNS-Server
- DNS-Suffix
- verbindungsspezifisches DNS-Suffix
- Registrierung der Adresse
- mehrere aktive Netzwerkadapter
- VPN-Adapter
- virtuelle Adapter
- fehlerhafte statische Einstellungen
- DHCP-Optionen
- Erreichbarkeit der eingetragenen DNS-Server
**DNS-Clientcache anzeigen**
```cmd
[RO][SENS] ipconfig /displaydns
```
**DNS-Clientcache leeren**
```cmd
[CHANGE] ipconfig /flushdns
```
Das Leeren des Caches kann einen neuen Auflösungsversuch erzwingen, beseitigt aber keine fehlerhafte Zone, falsche Delegierung oder falsche DNS-Clientkonfiguration.
**DNS-Namen prüfen**
```powershell
[TEST][SENS] Resolve-DnsName ""
```
```powershell
[TEST][SENS] Resolve-DnsName "" -Type A
```
```powershell
[TEST][SENS] Resolve-DnsName "_ldap._tcp.dc._msdcs." -Type SRV
```
> Ein Domänenclient sollte nicht ohne geplante interne DNS-Weiterleitung öffentliche DNS-Resolver zusätzlich zu internen AD-DNS-Servern verwenden. Windows behandelt mehrere eingetragene DNS-Server nicht als einfache interne-und-externe Suchreihenfolge.
9. DNS-Server und AD-integrierte Zonen untersuchen
Wichtige Prüfbereiche im DNS-Manager:
- Forward-Lookupzonen
- Reverse-Lookupzonen
- AD-integrierte Zonen
- Replikationsbereich der Zone
- dynamische Updates
- sichere dynamische Updates
- Weiterleitungen
- bedingte Weiterleitungen
- Stammhinweise
- veraltete Hosteinträge
- SRV-Einträge
- Delegierungen
- Alterung und Aufräumvorgänge
- DNSSEC, falls verwendet
**DNS-Serverzonen mit PowerShell anzeigen**
```powershell
[RO][PRIV][SENS] Get-DnsServerZone
```
**Ressourceneinträge einer Zone anzeigen**
```powershell
[RO][PRIV][SENS] Get-DnsServerResourceRecord -ZoneName ""
```
**DNS-Servereinstellungen anzeigen**
```powershell
[RO][PRIV][SENS] Get-DnsServer
```
**Weiterleitungen anzeigen**
```powershell
[RO][PRIV][SENS] Get-DnsServerForwarder
```
**DNS-Diagnose mit DCDiag**
```cmd
[TEST][PRIV][SENS] dcdiag /test:DNS /v
```
**DNS-Registrierung eines Domänenmitglieds anfordern**
```cmd
[CHANGE] ipconfig /registerdns
```
Auf einem Domain Controller kann außerdem eine erneute Registrierung domänenbezogener Einträge erforderlich sein. Dienstneustarts dürfen jedoch erst nach Prüfung der Auswirkungen erfolgen.
**DNS-Debugprotokollierung**
Die DNS-Debugprotokollierung kann sehr viele Daten und interne Abfragen erfassen. Sie sollte:
1. nur mit einem konkreten Fehlerbild aktiviert werden,
2. nach Client, Protokoll oder Pakettyp begrenzt werden,
3. nur so lange wie erforderlich laufen,
4. hinsichtlich Speicherplatz überwacht werden,
5. anschließend wieder deaktiviert werden.
```text
[CHANGE][PRIV][LOG][SENS]
```
> DNS-Debuglogs können interne Hostnamen, abgefragte Dienste, Clientadressen und Benutzeraktivitäten offenlegen.
10. Netlogon-Protokollierung kontrolliert verwenden
Netlogon ist unter anderem an Domänenanmeldung, DC-Locator und Secure-Channel-Vorgängen beteiligt.
Eine erweiterte Netlogon-Protokollierung darf nur zeitlich begrenzt aktiviert werden.
**Aktuellen Netlogon-Zustand prüfen**
```cmd
[RO][PRIV] sc query netlogon
```
**Netlogon-Diagnoseprotokollierung aktivieren**
```cmd
[CHANGE][PRIV][LOG][SENS] nltest /dbflag:0x2080ffff
```
**Protokollierung wieder auf den Standardzustand zurücksetzen**
```cmd
[CHANGE][PRIV] nltest /dbflag:0x0
```
Das Protokoll befindet sich typischerweise unter:
```text
%windir%\debug\netlogon.log
```
Vor und während der Aufzeichnung müssen geprüft werden:
- freier Speicherplatz
- Aufzeichnungsdauer
- konkreter Fehlerzeitpunkt
- betroffener Benutzer und Computer
- Schutz der Protokolldatei
- anschließende Deaktivierung
> Der Debug-Schalter darf nicht unkontrolliert dauerhaft aktiviert bleiben. Die Datei kann umfangreich werden und interne Domäneninformationen enthalten.
11. Kerberos-Tickets mit Klist untersuchen
Kerberos verwendet Tickets zur Authentifizierung. Dabei sind unter anderem Client, Key Distribution Center, Zielservice, SPN, Uhrzeit und DNS beteiligt.
**Tickets des aktuellen Anmeldekontexts anzeigen**
```cmd
[RO][SENS] klist
```
**Ticket Granting Tickets anzeigen**
```cmd
[RO][SENS] klist tgt
```
**Kerberos-Sitzungen anzeigen**
```cmd
[RO][SENS] klist sessions
```
**Tickets löschen**
```cmd
[CHANGE][SENS] klist purge
```
Das Löschen der Tickets beeinflusst den aktuellen Authentifizierungskontext. Anwendungen müssen danach möglicherweise neue Tickets anfordern.
**Ticket für einen Dienst anfordern**
```cmd
[TEST][REMOTE][SENS] klist get
```
**Typische Prüfungen**
- wurde ein TGT ausgestellt?
- welcher KDC hat das Ticket ausgestellt?
- für welchen SPN wurde ein Serviceticket ausgestellt?
- ist das Ticket abgelaufen?
- stimmen Client- und Servernamen?
- wurde auf NTLM zurückgefallen?
- tritt der Fehler nur mit Aliasnamen auf?
- funktioniert der Zugriff mit FQDN, aber nicht mit Kurzname?
- befindet sich ein altes Ticket im Cache?
- stimmt die Uhrzeit?
> `klist purge` ist keine Ursachenbehebung. Wenn DNS, SPN, Zeit oder Kontokonfiguration fehlerhaft sind, tritt das Problem nach Ausstellung neuer Tickets erneut auf.
12. Service Principal Names mit SetSPN prüfen
Ein SPN identifiziert eine Dienstinstanz für Kerberos. Er muss dem richtigen AD-Konto eindeutig zugeordnet sein.
**SPNs eines Kontos anzeigen**
```cmd
[RO][PRIV][SENS] setspn -L ""
```
**Bestimmten SPN suchen**
```cmd
[RO][PRIV][SENS] setspn -Q ""
```
**Forestweit nach doppelten SPNs suchen**
```cmd
[RO][PRIV][REMOTE][SENS] setspn -X
```
**SPN mit Duplikatprüfung registrieren**
```cmd
[CHANGE][PRIV][DANGER] setspn -S "" ""
```
**SPN entfernen**
```cmd
[CHANGE][PRIV][DANGER] setspn -D "" ""
```
Vor jeder Änderung müssen geprüft werden:
- vollständiger SPN
- Dienstklasse
- Hostname und FQDN
- Port, falls Teil des SPN
- tatsächlich verwendetes Dienstkonto
- bestehende Zuordnung
- Cluster-, Alias- oder Load-Balancer-Namen
- Auswirkungen auf andere Dienstinstanzen
- Replikationsstatus
Typische Kerberos-Probleme entstehen durch:
- fehlenden SPN
- doppelten SPN
- SPN auf falschem Konto
- Dienst läuft unter anderem Konto als erwartet
- DNS-Alias ohne passende SPN-Konfiguration
- altes Computerkonto
- nicht replizierte SPN-Änderung
- falschen Zielnamen der Anwendung
> SPNs dürfen nicht durch Ausprobieren auf verschiedene Konten geschrieben werden. Eine falsche Zuordnung kann die Kerberos-Authentifizierung mehrerer Systeme beeinträchtigen.
13. Zeitsynchronisation mit W32Time prüfen
Kerberos benötigt ausreichend übereinstimmende Zeitangaben. In einer AD-Domäne folgt die Zeithierarchie grundsätzlich der Domänenhierarchie. Der PDC-Emulator der Gesamtstruktur-Stammdomäne besitzt dabei eine besondere Rolle.
**Status anzeigen**
```cmd
[RO][SENS] w32tm /query /status
```
**Zeitquelle anzeigen**
```cmd
[RO][SENS] w32tm /query /source
```
**Konfiguration anzeigen**
```cmd
[RO][SENS] w32tm /query /configuration
```
**Peers anzeigen**
```cmd
[RO][SENS] w32tm /query /peers
```
**Domänenhierarchie überwachen**
```cmd
[TEST][REMOTE][SENS] w32tm /monitor
```
**Abweichung zu einem Computer messen**
```cmd
[TEST][REMOTE][SENS] w32tm /stripchart /computer: /dataonly /samples:10
```
**Neue Synchronisation anfordern**
```cmd
[CHANGE][PRIV][REMOTE] w32tm /resync
```
Zu prüfen sind:
- verwendete Zeitquelle
- letzte erfolgreiche Synchronisation
- aktuelle Zeitabweichung
- Zeitzone
- PDC-Emulator
- Virtualisierung und Hypervisor-Zeitquelle
- NTP-Erreichbarkeit
- Firewall
- kürzlich wiederhergestellte VM
- manuelle Zeitkonfiguration
- Dienstzustand
**FSMO-Rollen anzeigen**
```cmd
[RO][PRIV][SENS] netdom query fsmo
```
> Die manuelle Konfiguration externer Zeitserver auf allen Domänenmitgliedern kann die vorgesehene AD-Zeithierarchie umgehen. Änderungen müssen passend zur Rolle des Systems geplant werden.
14. Gruppenrichtlinienergebnis mit GPResult untersuchen
`gpresult` zeigt die Resultant Set of Policy, also die ermittelten Gruppenrichtlinienergebnisse für Computer und Benutzer.
**Zusammenfassung**
```cmd
[RO][SENS] gpresult /r
```
**Ausführliche Ausgabe**
```cmd
[RO][SENS] gpresult /v
```
**Maximal ausführliche Textausgabe**
```cmd
[RO][SENS] gpresult /z
```
**HTML-Bericht erzeugen**
```cmd
[RO][SENS] gpresult /h ".html"
```
**Nur Computerrichtlinien anzeigen**
```cmd
[RO][PRIV][SENS] gpresult /scope computer /r
```
**Nur Benutzerrichtlinien anzeigen**
```cmd
[RO][SENS] gpresult /scope user /r
```
**Bericht für einen anderen Benutzer**
```cmd
[RO][PRIV][SENS] gpresult /user "\" /h ".html"
```
Wichtige Auswertungsbereiche:
- angewendete GPOs
- abgelehnte GPOs
- Ablehnungsgrund
- Sicherheitsgruppen
- Benutzer- und Computer-OU
- langsame oder schnelle Netzwerkverbindung
- WMI-Filter
- Vererbungsinformationen
- Loopback-Verarbeitung
- Richtlinienrevision
- letzter Verarbeitungszeitpunkt
- verwendeter Domain Controller
> Eine GPO kann in der Gruppenrichtlinienverwaltung vorhanden und mit einer OU verknüpft sein, ohne auf das untersuchte Objekt angewendet zu werden.
15. Gruppenrichtlinienabruf mit GPUpdate testen
**Normale Aktualisierung**
```cmd
[CHANGE][REMOTE] gpupdate
```
**Alle Richtlinieneinstellungen erneut verarbeiten**
```cmd
[CHANGE][REMOTE] gpupdate /force
```
**Zeitlimit festlegen**
```cmd
[CHANGE][REMOTE] gpupdate /wait:
```
**Abmeldung zulassen, falls erforderlich**
```cmd
[CHANGE][REMOTE] gpupdate /logoff
```
**Neustart zulassen, falls erforderlich**
```cmd
[CHANGE][REMOTE][RESTART] gpupdate /boot
```
`gpupdate /force` sollte nicht reflexartig auf vielen Systemen gleichzeitig ausgeführt werden. Es kann:
- zusätzliche DC- und Netzwerkbelastung erzeugen
- Skripte erneut ausführen
- Softwareinstallation anstoßen
- Abmeldung oder Neustart erforderlich machen
- bestehende Sitzungen beeinflussen
- Drucker- und Laufwerkszuordnungen erneut verarbeiten
**Empfohlener Testablauf**
1. `gpresult` vor der Aktualisierung speichern.
2. Fehlerzeitpunkt dokumentieren.
3. Ereignisprotokoll prüfen.
4. `gpupdate` auf einem kontrollierten Testsystem ausführen.
5. Meldungen vollständig dokumentieren.
6. erforderliche Abmeldung oder Neustart berücksichtigen.
7. `gpresult` erneut erzeugen.
8. vorherigen und nachfolgenden Zustand vergleichen.
16. Warum eine GPO nicht angewendet wird
Mögliche Ursachen:
- Benutzer oder Computer befindet sich in der falschen OU.
- GPO ist mit einer anderen OU verknüpft.
- Verknüpfung ist deaktiviert.
- Benutzer- oder Computerteil der GPO ist deaktiviert.
- Sicherheitsfilter schließt das Objekt aus.
- notwendige Rechte `Lesen` oder `Gruppenrichtlinie übernehmen` fehlen.
- WMI-Filter liefert `False` oder kann nicht ausgewertet werden.
- Vererbung wurde blockiert.
- eine erzwungene GPO beeinflusst die Vererbungsreihenfolge.
- eine Richtlinie mit höherer Priorität überschreibt die Einstellung.
- Loopback-Verarbeitung verändert die Benutzerrichtlinien.
- Client erreicht keinen Domain Controller.
- DNS oder Secure Channel ist fehlerhaft.
- SYSVOL ist nicht erreichbar.
- AD- und SYSVOL-Replikation besitzen unterschiedliche Stände.
- Client Side Extension benötigt synchrone Verarbeitung.
- Richtlinie wird erst nach Abmeldung oder Neustart wirksam.
- Fast Startup beeinflusst den erwarteten Startvorgang.
- Anwendung liest die Einstellung nur beim Start.
- Einstellung gilt nicht für die verwendete Windows-Version oder Edition.
- ADMX-Vorlage und tatsächlich unterstützte Einstellung passen nicht zusammen.
**Prüfreihenfolge**
1. Objekt und OU bestätigen.
2. GPO-Verknüpfung bestätigen.
3. GPO-Status prüfen.
4. Sicherheitsfilter prüfen.
5. Delegierung prüfen.
6. WMI-Filter prüfen.
7. Vererbung und Reihenfolge prüfen.
8. `gpresult` auswerten.
9. GroupPolicy-Betriebsprotokoll auswerten.
10. DNS, DC-Locator und SYSVOL testen.
11. AD- und DFS-R-Replikation prüfen.
12. erforderliche Abmeldung oder Neustart testen.
17. GPO-Verarbeitung fachgerecht dokumentieren
Für jede untersuchte Gruppenrichtlinie sollten folgende Angaben erfasst werden:
```text
Aufgabe:
Betroffener Benutzer:
Betroffener Computer:
Domäne:
Standort:
Verwendeter Domain Controller:
Name der GPO:
GPO-ID:
GPO-Status:
Benutzer- oder Computerkonfiguration:
Verknüpfte OU:
Verknüpfungsreihenfolge:
Verknüpfung aktiviert:
Erzwungen:
Vererbung blockiert:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Loopback-Modus:
Pfad der Richtlinieneinstellung:
Konfigurierte Einstellung:
Erwarteter Wert:
Tatsächlicher Wert:
GPResult vor dem Test:
GPUpdate-Ergebnis:
Abmeldung erforderlich:
Neustart erforderlich:
GPResult nach dem Test:
GroupPolicy-Ereignisse:
SYSVOL erreichbar:
AD-Replikation geprüft:
DFS-R-Replikation geprüft:
Ursache:
Änderung:
Rückfallplan:
Testergebnis:
```
18. SYSVOL und NETLOGON prüfen
SYSVOL enthält unter anderem Gruppenrichtliniendateien und Skripte. Active Directory speichert den Verzeichnisanteil einer GPO, während SYSVOL den Dateianteil enthält. Beide Teile müssen konsistent und repliziert sein.
**Freigaben eines Domain Controllers anzeigen**
```cmd
[RO][REMOTE][SENS] net view \\
```
Erwartete Domänencontroller-Freigaben sind normalerweise:
- `SYSVOL`
- `NETLOGON`
**SYSVOL öffnen**
```cmd
[TEST][REMOTE][SENS] dir \\\SYSVOL
```
**NETLOGON öffnen**
```cmd
[TEST][REMOTE][SENS] dir \\\NETLOGON
```
**Bestimmte Richtlinie prüfen**
```cmd
[RO][REMOTE][SENS] dir "\\\SYSVOL\\Policies\{}"
```
Zu vergleichen sind:
- Existenz des GPO-Verzeichnisses
- GPO-GUID
- Inhalt auf mehreren Domain Controllern
- Zeitstempel
- `GPT.INI`
- Skripte
- Registry-Policy-Dateien
- Zugriffsrechte
- DFS-R-Ereignisse
> Dateien in SYSVOL dürfen nicht als normale Konfigurationsmethode manuell auf mehreren Domain Controllern bearbeitet oder kopiert werden. Dadurch können AD- und Dateianteil einer GPO inkonsistent werden.
19. DFS-Replikation von SYSVOL untersuchen
Moderne Windows-Domänen verwenden DFS Replication für SYSVOL. Wichtige Datenquellen sind:
- Ereignisprotokoll `DFS Replication`
- DFS-Verwaltung
- `dfsrdiag`
- PowerShell
- AD-Replikationszustand
- Zustand der SYSVOL- und NETLOGON-Freigaben
**DFS-R-Zustand abfragen**
```cmd
[RO][PRIV][SENS] dfsrdiag ReplicationState
```
**Konfiguration neu aus Active Directory einlesen**
```cmd
[CHANGE][PRIV] dfsrdiag PollAD
```
**DFS-R-Ereignisse abrufen**
```powershell
[RO][PRIV][SENS] Get-WinEvent -LogName "DFS Replication" -MaxEvents 200
```
Typische Prüfbereiche:
- Replikationsgruppe
- replizierter Ordner
- eingehender und ausgehender Partner
- Rückstand
- pausierte Replikation
- Datenbankzustand
- nicht ordnungsgemäß heruntergefahrener Server
- Kommunikationsfehler
- AD-Konfiguration noch nicht eingelesen
- Speicherplatz
- USN- oder Datenbankprobleme
> Eine DFS-R-Wiederherstellung oder autoritative SYSVOL-Synchronisierung ist eine eingriffsintensive Maßnahme. Sie darf erst nach gesicherter Diagnose, aktueller Sicherung und dokumentiertem Wiederherstellungsplan durchgeführt werden.
20. DHCP-Server untersuchen
DHCP-Probleme können dazu führen, dass Clients:
- keine Adresse erhalten
- eine APIPA-Adresse verwenden
- falsches Gateway erhalten
- falsche DNS-Server verwenden
- falsches DNS-Suffix erhalten
- ihre Lease nicht verlängern können
- aus einem falschen Bereich versorgt werden
- aufgrund ausgeschöpfter Bereiche keine Adresse erhalten
**DHCP-Konfiguration auf dem Client**
```cmd
[RO][SENS] ipconfig /all
```
**Lease freigeben**
```cmd
[CHANGE] ipconfig /release
```
**Lease erneuern**
```cmd
[CHANGE][REMOTE] ipconfig /renew
```
Diese Befehle unterbrechen die aktuelle IP-Konnektivität und sollten nicht unüberlegt über eine entfernte Verwaltungssitzung ausgeführt werden.
**DHCP-Server anzeigen**
```powershell
[RO][PRIV][SENS] Get-DhcpServerInDC
```
**IPv4-Bereiche anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Scope -ComputerName ""
```
**Leases anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4Lease -ComputerName "" -ScopeId ""
```
**Bereichsstatistik anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4ScopeStatistics -ComputerName ""
```
**Serveroptionen anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-DhcpServerv4OptionValue -ComputerName ""
```
Zu prüfen sind:
- DHCP-Autorisierung in Active Directory
- Dienstzustand
- Bereich aktiviert
- verfügbarer Adressvorrat
- Ausschlussbereiche
- Reservierungen
- Lease-Dauer
- Option 003 – Router
- Option 006 – DNS-Server
- Option 015 – DNS-Domänenname
- Relay-Agent oder IP Helper
- DHCP-Failover
- Konflikterkennung
- mehrere unerwartete DHCP-Server
- Auditprotokolle
> DHCP-Debug- und Auditlogs können MAC-Adressen, Hostnamen, IP-Adressen und zeitliche Gerätenutzung enthalten und müssen entsprechend geschützt werden.
21. DFS-Namespace und DFS-Replikation unterscheiden
DFS besteht aus unterschiedlichen Funktionen:
| Komponente | Aufgabe |
|---|---|
| DFS Namespace | stellt einen einheitlichen logischen Pfad bereit |
| DFS Replication | repliziert Ordnerinhalte zwischen Servern |
Ein erreichbarer Namespace beweist nicht, dass alle Replikationspartner denselben Datenstand besitzen. Umgekehrt beweist ein gesunder DFS-R-Status nicht, dass Namespace-Ziele, Berechtigungen und Verweise korrekt funktionieren.
**Namespacepfad testen**
```cmd
[TEST][REMOTE][SENS] dir "\\\"
```
**DFS-Ziele und Verweise untersuchen**
```cmd
[RO][SENS] dfsutil /pktinfo
```
**Zwischengespeicherte Verweise leeren**
```cmd
[CHANGE] dfsutil /pktflush
```
**Typische Prüfbereiche**
- DNS-Auflösung
- Namespace-Server
- Ordnerziele
- Zielstatus
- Standortkosten
- Referral-Reihenfolge
- SMB-Erreichbarkeit
- Freigabeberechtigungen
- NTFS-Berechtigungen
- DFS-R-Rückstand
- Dateisperren
- Konflikt- und gelöschte Ordner
- Staging-Speicher
22. Failovercluster untersuchen
Ein Failovercluster besteht aus mehreren voneinander abhängigen Komponenten:
- Clusterknoten
- Clusterdienst
- Quorum
- Witness
- Cluster-Netzwerke
- Speicher
- Cluster Shared Volumes
- Ressourcen
- Rollen
- Abhängigkeiten
- DNS
- Active-Directory-Computerobjekte
- Anwendungen
**Cluster anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-Cluster
```
**Knoten anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-ClusterNode
```
**Clustergruppen anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-ClusterGroup
```
**Ressourcen anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-ClusterResource
```
**Quorum anzeigen**
```powershell
[RO][PRIV][REMOTE][SENS] Get-ClusterQuorum
```
**Clusterprotokoll erzeugen**
```powershell
[TEST][PRIV][REMOTE][LOG][SENS] Get-ClusterLog -UseLocalTime -Destination ""
```
**Cluster validieren**
```powershell
[TEST][PRIV][REMOTE][LOG][SENS] Test-Cluster
```
Die vollständige Validierung kann Netzwerk-, Speicher- und Systemtests durchführen. Umfang und Auswirkungen müssen vor dem Start geprüft werden.
**Typische Diagnosefragen**
- Welche Ressource ist zuerst ausgefallen?
- Welche abhängigen Ressourcen folgten?
- Welcher Knoten war Besitzer?
- War Quorum vorhanden?
- War der Witness erreichbar?
- trat ein Netzwerk- oder Speicherfehler auf?
- konnte das Clustercomputerobjekt DNS-Daten aktualisieren?
- stimmen Ereigniszeit und Clusterlog überein?
- war der Failover geplant oder ungeplant?
- funktioniert die Anwendung nach dem Ressourcenstart tatsächlich?
> Das manuelle Verschieben oder Neustarten einer Clusterrolle ist eine Änderung am produktiven Dienst und keine rein lesende Diagnose.
23. Server Manager und Windows Admin Center richtig einordnen
**Server Manager**
Server Manager kann unter anderem anzeigen:
- Serverrollen
- Features
- verwaltete Server
- Dienstzustände
- Ereignisse
- Leistungswarnungen
- Best-Practices-Ergebnisse
- Rolleninstallationen
**Windows Admin Center**
Windows Admin Center kann abhängig von Version und Erweiterungen unter anderem verwalten:
- Server
- Cluster
- virtuelle Maschinen
- Zertifikate
- Ereignisse
- Dienste
- Speicher
- Netzwerke
- Updates
- Firewall
- Registry
- PowerShell
**Grenzen**
- eine grüne Übersicht ersetzt keine Detailprüfung
- Daten können verzögert aktualisiert werden
- Remoteverwaltung hängt von WinRM, Berechtigungen und Firewall ab
- eine fehlgeschlagene Verwaltungsverbindung beweist keinen Ausfall des Zielservers
- Aktionen können produktive Änderungen auslösen
- Erweiterungen können zusätzliche Berechtigungen benötigen
> Verwaltungsoberflächen fassen Zustände zusammen. Für belastbare Diagnosen müssen häufig Ereignisprotokolle, PowerShell-Ausgaben, Dienstprotokolle und Netzwerkdaten ergänzt werden.
24. Leistungsüberwachung auf Windows Server
Leistungsprobleme dürfen nicht allein anhand einer einzelnen CPU- oder RAM-Anzeige bewertet werden.
Wichtige Bereiche:
- Prozessor
- Arbeitsspeicher
- Datenträger
- Netzwerk
- Prozess
- System
- Serverdienst
- DNS
- AD DS
- DFS-R
- Hyper-V
- SQL Server oder weitere Anwendungsrollen
**Leistungsindikatoren anzeigen**
```powershell
[RO][SENS] Get-Counter -ListSet *
```
**Beispielhafte Systemindikatoren**
```powershell
[TEST][SENS] Get-Counter `
"\Processor(_Total)\% Processor Time",
"\Memory\Available MBytes",
"\PhysicalDisk(_Total)\Avg. Disk sec/Transfer",
"\System\Processor Queue Length"
```
**Wichtige Regeln**
- über einen repräsentativen Zeitraum messen
- Normalzustand als Vergleichswert besitzen
- Durchschnitt, Maximum und Verteilung unterscheiden
- Rolle des Servers berücksichtigen
- virtuelle und physische Ebene unterscheiden
- Wartungsfenster und Sicherungen berücksichtigen
- Ursache und Folge nicht verwechseln
- Zeitstempel mit Benutzerfehlern korrelieren
> Ein einzelner hoher Messwert beweist noch keinen Engpass. Entscheidend sind Dauer, Wiederholbarkeit, Warteschlangen, Antwortzeiten und Auswirkungen auf den Dienst.
25. Typische Fehlerbilder und geeignete Werkzeuge
| Fehlerbild | Geeignete Prüfungen |
|---|---|
| Benutzer kann sich nicht anmelden | DNS, DC-Locator, Zeit, Secure Channel, Kerberos, Netlogon, Ereignisse |
| Anmeldung funktioniert nur manchmal | mehrere DCs vergleichen, Replikation, DNS, Standorte, Zeit |
| neues Kennwort funktioniert nicht überall | `repadmin`, verwendeten DC feststellen, PDC-Erreichbarkeit |
| neuer Benutzer ist auf einem Server unbekannt | AD-Replikation, verwendeten DC, DNS |
| Computer meldet fehlende Vertrauensstellung | Secure Channel, Computerkonto, DNS, Zeit |
| GPO wird nicht angewendet | `gpresult`, GroupPolicy-Log, OU, Filter, SYSVOL, Replikation |
| GPO besitzt auf verschiedenen Clients andere Werte | verwendeten DC, AD- und SYSVOL-Replikation, Filter |
| Netzlaufwerk fehlt | GPO, DNS, DFS, SMB, Berechtigungen, Benutzerkontext |
| Domain Controller wird nicht gefunden | DNS-Client, SRV-Records, DC-Locator, Firewall |
| Kerberos funktioniert nur mit bestimmtem Namen | DNS, SPN, Alias, Dienstkonto |
| Zugriff fällt auf NTLM zurück | Kerberos-Ticket, SPN, Zielname, DNS |
| Uhrzeit springt zurück | W32Time, Domänenhierarchie, Hypervisor-Zeitquelle |
| DHCP-Client erhält APIPA | DHCP-Server, Relay, VLAN, Bereich, Firewall |
| falscher DNS-Server per DHCP | Bereichs- und Serveroptionen prüfen |
| SYSVOL fehlt | DFS-R, Netlogon, DC-Zustand, Ereignisse |
| Dateien in DFS unterscheiden sich | DFS-R-Zustand, Rückstand, Konflikte, Dateisperren |
| Clusterrolle startet nicht | Ressourcenabhängigkeiten, Clusterlog, Systemlog, DNS, Speicher |
| Server Manager zeigt Server als offline | WinRM, Firewall, DNS, Berechtigungen, Zielzustand |
26. Empfohlener Gesamtablauf bei Domänenproblemen
1. originale Fehlermeldung erfassen.
2. Benutzer, Computer und Zeitpunkt bestätigen.
3. Umfang der Störung bestimmen.
4. letzte Änderung dokumentieren.
5. lokale Netzwerkverbindung prüfen.
6. `ipconfig /all` erfassen.
7. konfigurierte DNS-Server prüfen.
8. Domänennamen und SRV-Einträge auflösen.
9. Domain Controller mit `nltest /dsgetdc` ermitteln.
10. verwendeten Standort prüfen.
11. Domain Controller gezielt erreichen.
12. Uhrzeit und Zeitquelle vergleichen.
13. Secure Channel prüfen.
14. Kerberos-Tickets untersuchen.
15. bei Dienstproblemen SPNs prüfen.
16. System- und Anwendungsprotokolle auswerten.
17. auf Domain Controllern `dcdiag` ausführen.
18. AD-Replikation mit `repadmin` prüfen.
19. bei GPO-Problemen `gpresult` sichern.
20. GroupPolicy-Betriebsprotokoll untersuchen.
21. SYSVOL auf mehreren DCs vergleichen.
22. DFS-R-Ereignisse prüfen.
23. Hypothese aus mehreren Befunden formulieren.
24. kleinste reversible Maßnahme planen.
25. Sicherung und Rückfallplan prüfen.
26. Änderung kontrolliert durchführen.
27. Funktion mit demselben Testszenario erneut prüfen.
28. Replikation und Monitoring nachkontrollieren.
29. temporäre Debugprotokollierung deaktivieren.
30. Ursache, Maßnahme und Ergebnis dokumentieren.
27. Beispiel – Gruppenrichtlinie wird auf CLIENT1 nicht angewendet
**Ausgangslage**
Eine auf `DC1` erstellte und mit einer OU verknüpfte GPO soll auf `CLIENT1` angewendet werden. Die konfigurierte Einstellung ist auf dem Client nicht wirksam.
**Vorgehensweise**
1. Benutzer- und Computername auf `CLIENT1` bestätigen.
2. prüfen, ob die Einstellung eine Benutzer- oder Computerrichtlinie ist.
3. tatsächliche OU des Zielobjekts kontrollieren.
4. GPO-Verknüpfung in der Gruppenrichtlinienverwaltung prüfen.
5. GPO-Status und Verknüpfungsstatus prüfen.
6. Sicherheitsfilter und Delegierung kontrollieren.
7. WMI-Filter prüfen.
8. `gpresult` vor einer Änderung erzeugen:
```cmd
[RO][SENS] gpresult /h "%TEMP%\gpresult-vorher.html"
```
9. verwendeten Domain Controller und DNS-Zustand prüfen:
```cmd
[RO][SENS] set LOGONSERVER
[TEST][SENS] nltest /dsgetdc:
[RO][SENS] ipconfig /all
```
10. GroupPolicy-Betriebsprotokoll untersuchen.
11. SYSVOL auf dem verwendeten DC prüfen.
12. AD- und DFS-R-Replikation zwischen `DC1` und weiteren DCs prüfen.
13. kontrollierte Aktualisierung durchführen:
```cmd
[CHANGE][REMOTE] gpupdate /force
```
14. erforderliche Abmeldung oder Neustart durchführen.
15. neuen Bericht erzeugen:
```cmd
[RO][SENS] gpresult /h "%TEMP%\gpresult-nachher.html"
```
16. beide Berichte vergleichen.
**Mögliche Befunde**
- `CLIENT1` befindet sich in der falschen OU.
- GPO enthält eine Benutzereinstellung, wurde aber nur für das Computerkonto erwartet.
- Sicherheitsfilter schließt den Benutzer oder Computer aus.
- GPO wird durch eine höher priorisierte Einstellung überschrieben.
- WMI-Filter trifft nicht zu.
- Client verwendet einen anderen DC mit älterem Replikationsstand.
- SYSVOL enthält auf einem DC nicht den aktuellen Dateianteil.
- Richtlinie benötigt Neustart oder Abmeldung.
- Einstellung wird von der Clientedition nicht unterstützt.
- Loopback-Verarbeitung verändert das Ergebnis.
28. Beispiel – Benutzer kann sich nur an manchen Computern anmelden
**Mögliche Ursachen**
- unterschiedliche Domain Controller liefern unterschiedliche AD-Stände
- Kennwortänderung ist noch nicht vollständig repliziert
- ein Standort verweist auf einen gestörten DC
- DNS liefert veraltete oder falsche Einträge
- ein Computer besitzt einen fehlerhaften Secure Channel
- Zeitabweichung verhindert Kerberos
- lokale Benutzerrechte unterscheiden sich
- GPO verweigert eine Anmeldeart
- Benutzerprofil oder Anmeldeskript schlägt fehl
- Netzwerk ist beim Start noch nicht verfügbar
**Prüfungen auf funktionierendem und betroffenem Computer**
```cmd
[RO][SENS] ipconfig /all
[TEST][SENS] nltest /dsgetdc:
[RO][SENS] nltest /dsgetsite
[TEST][PRIV][SENS] nltest /sc_verify:
[RO][SENS] w32tm /query /status
[RO][SENS] w32tm /query /source
[RO][SENS] klist
[RO][SENS] gpresult /r
```
Anschließend müssen die Ergebnisse miteinander verglichen werden:
- DNS-Server
- Domain Controller
- Standort
- Uhrzeit
- Ticketstatus
- GPOs
- Gruppenmitgliedschaften
- Ereignisprotokolle
- Secure Channel
29. Beispiel – Active-Directory-Änderung erscheint nicht auf DC2
**Ausgangslage**
Ein auf `DC1` angelegtes oder geändertes Objekt ist auf `DC2` nicht sichtbar.
**Vorgehensweise**
1. Objekt und Änderungszeitpunkt dokumentieren.
2. sicherstellen, dass tatsächlich unterschiedliche DCs abgefragt werden.
3. AD-Replikationsübersicht erstellen:
```cmd
[RO][PRIV][SENS] repadmin /replsummary
```
4. eingehende Partner von `DC2` untersuchen:
```cmd
[RO][PRIV][SENS] repadmin /showrepl DC2
```
5. betroffenen Namenskontext bestimmen.
6. DNS-Auflösung zwischen `DC1` und `DC2` prüfen.
7. RPC- und Firewall-Erreichbarkeit berücksichtigen.
8. Uhrzeit vergleichen.
9. Ereignisprotokoll `Directory Service` untersuchen.
10. Replikationsmetadaten des Objekts vergleichen:
```cmd
[RO][PRIV][SENS] repadmin /showobjmeta DC1 ""
```
```cmd
[RO][PRIV][SENS] repadmin /showobjmeta DC2 ""
```
11. erst nach Ursachenprüfung eine kontrollierte Replikation auslösen.
12. anschließend automatische Replikation weiter beobachten.
> Das manuelle Kopieren, erneute Anlegen oder Löschen des Objekts kann Konflikte erzeugen und die ursprüngliche Replikationsursache verdecken.
30. Gefährliche Fehlinterpretationen vermeiden
| Beobachtung | Nicht automatisch bewiesen |
|---|---|
| Ping zum DC funktioniert | LDAP, Kerberos, SMB und RPC funktionieren |
| Domänenname wird aufgelöst | alle benötigten SRV-Records sind korrekt |
| Anmeldung funktioniert | Anmeldung erfolgte aktuell gegen einen DC |
| `LOGONSERVER` zeigt DC1 | jeder Domänendienst verwendet DC1 |
| `gpupdate` war erfolgreich | gewünschte GPO wurde angewendet |
| GPO ist verknüpft | Zielobjekt darf sie anwenden |
| GPO erscheint in `gpresult` | jede einzelne Einstellung wurde erfolgreich verarbeitet |
| Benutzer ist Gruppenmitglied | aktuelles Token enthält die neue Mitgliedschaft |
| `klist` zeigt Tickets | Ticket gehört zum richtigen Dienst und SPN |
| SPN existiert | SPN ist dem richtigen Konto eindeutig zugeordnet |
| Uhrzeit sieht gleich aus | Zeitquelle und tatsächliche Abweichung sind korrekt |
| `repadmin /replsummary` zeigt wenig Fehler | alle Partitionen und Objekte sind aktuell |
| SYSVOL ist erreichbar | SYSVOL besitzt auf allen DCs denselben Stand |
| DHCP-Lease existiert | Optionen, VLAN und DNS-Daten sind korrekt |
| Clusterressource ist online | Anwendung ist fachlich funktionsfähig |
| Ereignis-ID ist bekannt | Ursache ist ohne Ereignistext eindeutig |
31. Sicherheits- und Datenschutzanforderungen
Diagnosedaten können enthalten:
- Benutzernamen
- Gruppenmitgliedschaften
- Computernamen
- Domänennamen
- interne DNS-Zonen
- IP- und MAC-Adressen
- Distinguished Names
- Gruppenrichtlinien
- Anmeldeserver
- Sicherheitskennungen
- Kerberos-Ticketinformationen
- Dienstkonten
- SPNs
- Freigaben
- interne Dateipfade
- Cluster- und Servernamen
- DHCP-Leases
- Ereignisprotokolle
- Netzwerkstruktur
- administrative Konten
Vor der Weitergabe müssen:
1. Zweck und Empfänger bestimmt werden.
2. benötigte Daten begrenzt werden.
3. Kennwörter, Schlüssel und Tokens ausgeschlossen werden.
4. personenbezogene Angaben redigiert werden.
5. Dateien verschlüsselt übertragen werden.
6. Zugriffsrechte beschränkt werden.
7. Aufbewahrungsfristen festgelegt werden.
8. temporäre Debuglogs wieder deaktiviert werden.
9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
10. externe Analysedienste organisatorisch freigegeben sein.
> Kennwörter dürfen nicht in Befehlszeilen, Dokumentationen, Screenshots oder Protokolldateien eingetragen werden.
32. Dokumentationsvorlage
```text
Ticket:
Datum und Uhrzeit:
Bearbeiter:
Betroffener Benutzer:
Betroffener Computer:
Windows-Version:
Serverrolle:
Domäne:
Active-Directory-Standort:
IP-Adresse:
DNS-Server:
Gateway:
VPN:
Verwendeter Domain Controller:
LOGONSERVER:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:
DC-Locator-Ergebnis:
Secure-Channel-Ergebnis:
Zeitquelle:
Zeitabweichung:
Kerberos-Tickets:
Verwendeter KDC:
Untersuchter SPN:
SPN-Zuordnung:
Doppelte SPNs:
DCDiag-Ergebnis:
Fehlgeschlagener Test:
Repadmin-Replikationsübersicht:
Betroffener Quell-DC:
Betroffener Ziel-DC:
Betroffener Namenskontext:
Letzte erfolgreiche Replikation:
Replikationsfehlercode:
Replikationsmetadaten geprüft:
DNS-Zone:
DNS-Record:
SRV-Records:
Dynamische Registrierung:
DNS-Ereignisse:
DNS-Debuglog verwendet:
Netlogon-Debuglog verwendet:
Debuglogging wieder deaktiviert:
GPO:
GPO-ID:
Benutzer- oder Computerrichtlinie:
Verknüpfte OU:
Sicherheitsfilter:
Delegierung:
WMI-Filter:
Vererbungsreihenfolge:
Loopback-Modus:
GPResult vorher:
GPUpdate-Ergebnis:
GPResult nachher:
GroupPolicy-Ereignisse:
Abmeldung erforderlich:
Neustart erforderlich:
SYSVOL erreichbar:
NETLOGON erreichbar:
GPO-Dateianteil vorhanden:
DFS-R-Status:
DFS-R-Ereignisse:
Replikationsrückstand:
DHCP-Server:
DHCP-Bereich:
Lease:
Bereichsauslastung:
Router-Option:
DNS-Option:
DNS-Suffix:
DHCP-Relay:
DHCP-Failover:
Cluster:
Clusterknoten:
Clusterrolle:
Fehlgeschlagene Ressource:
Abhängige Ressourcen:
Quorum:
Witness:
Clusterlog:
Failover-Zeitpunkt:
Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Änderung:
Ergebnis:
Wiederholungstest:
Monitoring:
Abschluss:
```
---
**Merksatz**
> Bei Fehlern in Windows-Domänen muss die Abhängigkeitskette vollständig betrachtet werden: Netzwerk ermöglicht die Verbindung, DNS findet den Dienst, Zeit und Secure Channel schaffen die Vertrauensbasis, Kerberos authentifiziert, Active Directory liefert die Objekte, Replikation verteilt den Zustand und SYSVOL stellt die Gruppenrichtliniendateien bereit.
**Quellen und weiterführende Dokumentation**
- [Microsoft Learn – DCDiag](https://learn.microsoft.com/windows-server/administration/windows-commands/dcdiag)
- [Microsoft Learn – Repadmin](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11))
- [Microsoft Learn – Problembehandlung der Active-Directory-Replikation](https://learn.microsoft.com/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems)
- [Microsoft Learn – Häufige Active-Directory-Replikationsfehler](https://learn.microsoft.com/troubleshoot/windows-server/active-directory/common-active-directory-replication-errors)
- [Microsoft Learn – NLTest](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11))
- [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/powershell/module/microsoft.powershell.management/test-computersecurechannel)
- [Microsoft Learn – Active Directory Domain Services und DNS](https://learn.microsoft.com/windows-server/identity/ad-ds/plan/dns-and-ad-ds)
- [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
- [Microsoft Learn – DNS-Server-PowerShell](https://learn.microsoft.com/powershell/module/dnsserver/)
- [Microsoft Learn – Kerberos-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance)
- [Microsoft Learn – Klist](https://learn.microsoft.com/windows-server/administration/windows-commands/klist)
- [Microsoft Learn – SetSPN](https://learn.microsoft.com/windows-server/administration/windows-commands/setspn)
- [Microsoft Learn – W32tm](https://learn.microsoft.com/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings)
- [Microsoft Learn – Funktionsweise des Windows-Zeitdienstes](https://learn.microsoft.com/windows-server/networking/windows-time-service/how-the-windows-time-service-works)
- [Microsoft Learn – GPResult](https://learn.microsoft.com/windows-server/administration/windows-commands/gpresult)
- [Microsoft Learn – GPUpdate](https://learn.microsoft.com/windows-server/administration/windows-commands/gpupdate)
- [Microsoft Learn – Gruppenrichtlinien-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/group-policy/group-policy-overview)
- [Microsoft Learn – Group Policy Operational Log](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-7/ff182331(v=ws.10))
- [Microsoft Learn – DHCP-Server-PowerShell](https://learn.microsoft.com/powershell/module/dhcpserver/)
- [Microsoft Learn – DHCP-Problembehandlung](https://learn.microsoft.com/troubleshoot/windows-server/networking/troubleshoot-dhcp-guidance)
- [Microsoft Learn – DFS Namespaces und DFS Replication](https://learn.microsoft.com/windows-server/storage/dfs-namespaces/dfs-overview)
- [Microsoft Learn – Problembehandlung bei DFS Replication](https://learn.microsoft.com/troubleshoot/windows-server/networking/dfsr-overview)
- [Microsoft Learn – Failover Clustering](https://learn.microsoft.com/windows-server/failover-clustering/failover-clustering-overview)
- [Microsoft Learn – Failovercluster erstellen und validieren](https://learn.microsoft.com/windows-server/failover-clustering/create-failover-cluster)
- [Microsoft Learn – Get-ClusterLog](https://learn.microsoft.com/powershell/module/failoverclusters/get-clusterlog)
- [Microsoft Learn – Windows Admin Center](https://learn.microsoft.com/windows-server/manage/windows-admin-center/overview)
- [Microsoft Learn – Get-Counter](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-counter)
- [Microsoft Learn – Netzwerkports für Windows-Dienste](https://learn.microsoft.com/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements)
# 5.4 Linux – Werkzeuge zur Fehleranalyse
Linux-Systeme stellen zahlreiche integrierte Werkzeuge für die Fehleranalyse bereit. Die konkrete Verfügbarkeit und Ausgabe hängt unter anderem ab von:
- Distribution und Version
- Kernel-Version
- Init-System
- installierten Paketen
- Netzwerkverwaltung
- Dateisystem
- Virtualisierung oder Containerisierung
- Berechtigungen
- Sicherheitsmechanismen wie SELinux oder AppArmor
Auf modernen Serverdistributionen wird häufig `systemd` eingesetzt. Andere Systeme können jedoch alternative Init- und Protokollierungssysteme verwenden.
---
**Kennzeichnung der Befehle**
| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | grundsätzlich lesende Abfrage |
| `[TEST]` | aktiver Test, der Netzwerk- oder Systemlast erzeugen kann |
| `[CHANGE]` | verändert den Systemzustand |
| `[PRIV]` | benötigt häufig Root-Rechte oder `sudo` |
| `[REMOTE]` | kommuniziert mit einem anderen System oder Dienst |
| `[LOG]` | erzeugt möglicherweise umfangreiche Protokolldaten |
| `[SENS]` | Ausgabe kann interne oder personenbezogene Informationen enthalten |
| `[DANGER]` | kann bei falscher Anwendung Dienste, Daten oder das gesamte System gefährden |
| `[RESTART]` | kann einen Dienst- oder Systemneustart auslösen |
> Die Kennzeichnungen sind Sicherheitshinweise und kein Bestandteil des eigentlichen Befehls.
---
1. Diagnose vor der Änderung
Eine Linux-Fehleranalyse sollte nicht mit einem Neustart, einer Paketaktualisierung oder dem Löschen von Dateien beginnen. Zuerst muss der fehlerhafte Zustand gesichert werden.
**Grundfragen**
- Was funktioniert nicht?
- Wie lautet die vollständige Fehlermeldung?
- Seit wann besteht der Fehler?
- Ist er reproduzierbar?
- Welche Benutzer, Dienste oder Systeme sind betroffen?
- Was wurde zuletzt geändert?
- Ist nur eine Anwendung oder das gesamte System betroffen?
- Tritt der Fehler lokal und remote auf?
- Besteht ein zeitlicher Zusammenhang mit Updates, Neustarts oder Sicherungen?
- Gibt es ausreichend Speicherplatz, Inodes und Arbeitsspeicher?
- Läuft das System auf Hardware, in einer VM oder in einem Container?
**Grundlegende Systeminformationen**
```bash
[RO][SENS] hostnamectl
[RO] uname -a
[RO] cat /etc/os-release
[RO] uptime
[RO][SENS] who
[RO][SENS] last -x
```
`last -x` kann unter anderem Anmeldungen, Neustarts und Herunterfahrvorgänge anzeigen. Die verfügbaren Daten hängen von der Protokollierung und Rotation der zugrunde liegenden Dateien ab.
2. Hilfe und Dokumentation direkt auf dem System verwenden
Vor der Verwendung unbekannter Optionen sollte die lokal installierte Dokumentation geprüft werden.
```bash
[RO] man
[RO] info
[RO] --help
[RO] apropos ""
[RO] man -k ""
[RO] type
[RO] command -V
```
**Warum die lokale Dokumentation wichtig ist**
- Sie passt normalerweise zur installierten Programmversion.
- Optionen können sich zwischen Versionen unterscheiden.
- Distributionen können Programme anders konfigurieren.
- Nicht jeder im Internet gefundene Befehl ist auf dem Zielsystem vorhanden.
- Gleichnamige Programme können aus unterschiedlichen Paketen stammen.
> Befehle aus fremden Anleitungen dürfen nicht ungeprüft mit Root-Rechten ausgeführt werden.
3. Systemzustand und Auslastung überblicken
```bash
[RO] uptime
[RO] top
[RO] free -h
[RO] vmstat 1 10
[RO] cat /proc/loadavg
[RO] nproc
[RO] lscpu
```
Falls installiert:
```bash
[RO] htop
[RO] mpstat -P ALL 1 10
[RO] pidstat 1 10
```
**Load Average richtig einordnen**
Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr 1, 5 und 15 Minuten. Sie erfassen nicht ausschließlich CPU-Auslastung, sondern unter Linux auch Tasks, die nicht unterbrechbar warten, beispielsweise auf bestimmte I/O-Vorgänge.
Die Bewertung muss deshalb berücksichtigen:
- Anzahl der logischen CPUs
- CPU-Auslastung
- I/O-Wartezeiten
- Prozesszustände
- Dauer der Belastung
- Normalzustand des Systems
- virtuelle CPU-Zuteilung
- mögliche Drosselung
> Ein hoher Load-Wert beweist allein weder eine CPU-Überlastung noch einen bestimmten Hardwarefehler.
4. Prozesse untersuchen
```bash
[RO][SENS] ps aux
[RO][SENS] ps -ef
[RO][SENS] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd
[RO][SENS] pstree -ap
[RO] pgrep -a ""
[RO][PRIV][SENS] lsof -p
```
**Prozesszustände**
| Zustand | Grundbedeutung |
|---|---|
| `R` | läuft oder ist ausführbar |
| `S` | unterbrechbarer Schlafzustand |
| `D` | nicht unterbrechbarer Schlafzustand, häufig im Zusammenhang mit I/O |
| `T` | angehalten oder verfolgt |
| `Z` | Zombieprozess |
Ein Zombieprozess hat seine Ausführung beendet, wurde aber vom Elternprozess noch nicht vollständig abgeholt. Das Beenden des Zombies selbst löst die Ursache normalerweise nicht; der Elternprozess muss untersucht werden.
**Signale kontrolliert verwenden**
```bash
[CHANGE] kill -TERM
[CHANGE] kill -HUP
[CHANGE][DANGER] kill -KILL
```
- `SIGTERM` fordert einen kontrollierten Abbruch an.
- `SIGHUP` kann abhängig vom Programm eine Konfiguration neu einlesen oder eine andere Bedeutung besitzen.
- `SIGKILL` beendet einen Prozess ohne eigene Aufräumlogik des Prozesses.
> `kill -9` sollte nicht als Standardmaßnahme verwendet werden. Offene Transaktionen, temporäre Dateien oder gemeinsam genutzte Ressourcen können in einem problematischen Zustand verbleiben.
5. Systemd-Dienste prüfen
```bash
[RO] systemctl status
[RO] systemctl is-active
[RO] systemctl is-enabled
[RO] systemctl is-failed
[RO] systemctl list-units --type=service --state=failed
[RO] systemctl list-dependencies
[RO] systemctl show
[RO] systemctl cat
```
**Wichtige Unterscheidung**
| Zustand | Aussage |
|---|---|
| `active` | Unit ist entsprechend ihrem Typ aktiv |
| `inactive` | Unit ist derzeit nicht aktiv |
| `failed` | Start oder Ausführung ist fehlgeschlagen |
| `enabled` | Unit soll über ihre Installationsverknüpfungen automatisch eingebunden werden |
| `disabled` | entsprechende automatische Einbindung ist nicht aktiviert |
| `masked` | Aktivierung und Start sind durch eine Verknüpfung auf `/dev/null` blockiert |
`active` beweist nicht automatisch, dass die Anwendung fachlich funktioniert. Ein Webserver kann beispielsweise laufen, während eine abhängige Datenbank oder eine bestimmte Website nicht erreichbar ist.
**Ändernde Aktionen**
```bash
[CHANGE][PRIV] sudo systemctl start
[CHANGE][PRIV] sudo systemctl stop
[CHANGE][PRIV][RESTART] sudo systemctl restart
[CHANGE][PRIV] sudo systemctl reload
[CHANGE][PRIV] sudo systemctl reset-failed
```
`reload` funktioniert nur, wenn die Unit beziehungsweise das Programm dies unterstützt. `reset-failed` löscht den registrierten Fehlerzustand, behebt aber nicht dessen Ursache.
6. Änderungen an Systemd-Units richtig behandeln
**Effektive Unit-Konfiguration anzeigen**
```bash
[RO] systemctl cat
```
**Abhängigkeiten untersuchen**
```bash
[RO] systemctl list-dependencies
[RO] systemctl list-dependencies --reverse
```
**Lokale Überschreibung bearbeiten**
```bash
[CHANGE][PRIV] sudo systemctl edit
```
**Unit-Dateien neu einlesen**
```bash
[CHANGE][PRIV] sudo systemctl daemon-reload
```
`daemon-reload` liest Unit-Dateien und die systemd-Abhängigkeitsstruktur neu ein. Es startet den betroffenen Dienst nicht automatisch neu.
Vor einer Änderung müssen gesichert werden:
- Originalkonfiguration
- Inhalt bestehender Drop-ins
- Paketzugehörigkeit
- Abhängigkeiten
- Startbenutzer
- Umgebungsvariablen
- benötigte Dateien und Verzeichnisse
- Rückfallplan
- erwartete Auswirkungen eines Neustarts
> Paketverwaltete Unit-Dateien unter `/usr/lib/systemd/system` oder `/lib/systemd/system` sollten nicht direkt als dauerhafte Anpassungsmethode bearbeitet werden. Lokale Drop-ins verhindern, dass Paketaktualisierungen die Anpassung einfach überschreiben.
7. Journal mit Journalctl auswerten
```bash
[RO][SENS] journalctl
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO][SENS] journalctl -p warning
[RO][SENS] journalctl -u
[RO][SENS] journalctl -u -b
[RO][SENS] journalctl --since "2026-08-01 14:00:00"
[RO][SENS] journalctl --since "30 minutes ago"
[RO][SENS] journalctl -k
[RO][SENS] journalctl -f
```
**Zusätzliche Filter**
```bash
[RO][SENS] journalctl _PID=
[RO][SENS] journalctl _UID=
[RO][SENS] journalctl _COMM=
[RO][SENS] journalctl -o verbose
```
**Speicherbelegung des Journals**
```bash
[RO] journalctl --disk-usage
```
Zu beachten sind:
- richtiger Bootvorgang
- Zeitzone und Zeitstempel
- erste Fehlermeldung statt nur Folgefehler
- Dienstname und Prozess-ID
- Logrotation
- persistente oder flüchtige Speicherung
- Berechtigungen
- mögliche Geheimnisse oder personenbezogene Daten
> `journalctl -f` zeigt neu eintreffende Einträge. Es ersetzt nicht die Untersuchung älterer Ereignisse vor dem sichtbaren Fehler.
8. Klassische Protokolldateien untersuchen
Abhängig von der Distribution und Konfiguration können relevante Dateien beispielsweise unter `/var/log` liegen.
```bash
[RO][PRIV][SENS] sudo ls -lah /var/log
[RO][PRIV][SENS] sudo tail -n 200
[RO][PRIV][SENS] sudo tail -f
[RO][PRIV][SENS] sudo less
[RO][PRIV][SENS] sudo grep -iE "error|fail|warning"
```
Mögliche Protokolle sind unter anderem:
- `/var/log/syslog`
- `/var/log/messages`
- `/var/log/auth.log`
- `/var/log/secure`
- `/var/log/kern.log`
- anwendungsspezifische Unterverzeichnisse
Diese Pfade sind nicht auf jeder Distribution vorhanden. Ein System kann Ereignisse ausschließlich oder zusätzlich im systemd-Journal speichern.
**Rotierte Protokolle**
```bash
[RO][PRIV][SENS] sudo zless .gz
[RO][PRIV][SENS] sudo zgrep -i "" .gz
```
> Protokolldateien dürfen nicht gelöscht oder geleert werden, bevor Ursache, Aufbewahrungspflichten und Auswirkungen auf laufende Prozesse geklärt sind.
9. Kernelmeldungen und Hardwareereignisse prüfen
```bash
[RO][PRIV][SENS] sudo dmesg
[RO][PRIV][SENS] sudo dmesg --ctime
[RO][PRIV][SENS] sudo dmesg --level=err,warn
[RO][PRIV][SENS] sudo journalctl -k -b
[RO][PRIV][SENS] sudo journalctl -k -b -1
```
Typische Suchbegriffe:
```bash
[RO][PRIV][SENS] sudo dmesg --ctime | grep -iE "error|fail|timeout|reset|oom|I/O"
```
Zu untersuchen sind beispielsweise:
- I/O-Fehler
- Geräte-Resets
- Dateisystemfehler
- Treiberprobleme
- Link-Änderungen
- Out-of-Memory-Ereignisse
- Kernel-Warnungen
- Machine-Check-Ereignisse
- USB-Verbindungsabbrüche
- blockierte Tasks
> Der Kernel-Ringpuffer ist begrenzt. Ältere Meldungen können überschrieben worden sein. Außerdem dürfen Zeitangaben aus `dmesg` nicht ungeprüft mit Zeitstempeln anderer Protokolle gleichgesetzt werden.
10. Arbeitsspeicher und OOM-Killer untersuchen
```bash
[RO] free -h
[RO] cat /proc/meminfo
[RO][SENS] ps -eo pid,user,%mem,rss,vsz,cmd --sort=-rss
[RO] vmstat 1 10
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "out of memory|oom|killed process"
```
Wichtige Bereiche:
- verfügbarer Speicher
- Page Cache
- Swap-Nutzung
- Major Page Faults
- Prozess-RSS
- cgroup- oder Containergrenzen
- Speicherwachstum über die Zeit
- OOM-Auswahl des Kernels
- NUMA-Zuordnung
- reservierter Speicher einer VM
Linux verwendet freien Arbeitsspeicher sinnvoll als Cache. Ein geringer Wert in der Spalte `free` bedeutet daher nicht automatisch Speichermangel. Für die erste Bewertung ist bei `free` insbesondere `available` relevant.
**Swap-Nutzung anzeigen**
```bash
[RO] swapon --show
[RO] cat /proc/swaps
```
> Das Leeren von Caches oder Deaktivieren von Swap ist keine allgemeine Speicherreparatur und kann zusätzliche Last oder einen Systemausfall verursachen.
11. Datenträger, Partitionen und Einhängepunkte prüfen
```bash
[RO][SENS] lsblk -f
[RO][SENS] findmnt
[RO] df -hT
[RO] df -i
[RO][PRIV][SENS] sudo fdisk -l
[RO][PRIV][SENS] sudo blkid
```
**Warum `df -h` und `df -i` benötigt werden**
Ein Dateisystem kann trotz freier Datenblöcke keine neuen Dateien mehr anlegen, wenn keine freien Inodes verfügbar sind.
**Große Verzeichnisse ermitteln**
```bash
[RO][PRIV][SENS] sudo du -xhd1 | sort -h
```
**Gelöschte, aber noch geöffnete Dateien suchen**
```bash
[RO][PRIV][SENS] sudo lsof +L1
```
Wenn ein Prozess eine gelöschte Datei noch geöffnet hält, kann der belegte Speicherplatz bis zum Schließen des Dateideskriptors weiterhin belegt bleiben.
> `du` und `df` messen unterschiedliche Sachverhalte. Abweichungen beweisen nicht automatisch einen Dateisystemfehler.
12. Datenträger-I/O und Gerätezustand analysieren
Falls die erforderlichen Werkzeuge installiert sind:
```bash
[RO] iostat -xz 1 10
[RO][PRIV] sudo smartctl -a /dev/
[RO][PRIV] sudo nvme smart-log /dev/
```
Zu prüfen sind:
- Latenz
- Warteschlangen
- Auslastung
- Durchsatz
- I/O-Fehler
- Geräte-Resets
- Medienfehler
- Temperatur
- verbleibende Reserve
- RAID- oder Storage-Layer
- virtuelle Datenträger
- parallele Sicherungen
SMART-Werte müssen geräte- und herstellerspezifisch interpretiert werden. Ein bestandener allgemeiner SMART-Status schließt einen Defekt nicht sicher aus.
> Selbsttests, Reparaturbefehle und Schreibtests können Last erzeugen oder ein vorgeschädigtes Medium zusätzlich beanspruchen. Vorher müssen Sicherungsstand und Auswirkungen geklärt werden.
13. Dateisystemfehler sicher behandeln
**Dateisystemtyp und Einhängezustand prüfen**
```bash
[RO][SENS] findmnt
[RO][SENS] lsblk -f
[RO] mount
[RO][PRIV][SENS] sudo journalctl -k | grep -iE "filesystem|ext4|xfs|btrfs|I/O error"
```
Eine Dateisystemprüfung muss zum tatsächlichen Dateisystem passen. Werkzeuge für ext-Dateisysteme, XFS und Btrfs sind nicht beliebig austauschbar.
```bash
[TEST][PRIV][DANGER] sudo fsck
```
> `fsck` darf nicht unüberlegt auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur müssen Dateisystemtyp, Geräteziel, Einhängezustand, Sicherung und Wiederherstellungsplan eindeutig geklärt sein.
Bei Root-Dateisystemen kann eine Prüfung im Rettungsmodus, über ein Wartungssystem oder beim Start erforderlich sein.
14. Netzwerkadapter und Adressen untersuchen
```bash
[RO][SENS] ip -br link
[RO][SENS] ip -br address
[RO][SENS] ip address show
[RO][SENS] ip -s link
[RO][SENS] ip route show
[RO][SENS] ip rule show
[RO][SENS] ip neigh show
```
Zu prüfen sind:
- administrativer und physischer Link-Zustand
- MAC-Adresse
- IPv4- und IPv6-Adressen
- Präfixlängen
- Standardroute
- Routingtabellen
- Policy Routing
- Interfacefehler und Drops
- Nachbartabelle
- VLANs, Bonds und Bridges
- virtuelle Interfaces
- Network Namespace
> Die früher verbreiteten Werkzeuge `ifconfig`, `route` und `netstat` werden auf vielen modernen Linux-Systemen durch Werkzeuge aus `iproute2`, insbesondere `ip` und `ss`, ersetzt.
15. Erreichbarkeit und Pfad testen
```bash
[TEST][REMOTE] ping -c 4
[TEST][REMOTE] ping -6 -c 4
[TEST][REMOTE][SENS] tracepath
[TEST][REMOTE][SENS] traceroute
[TEST][REMOTE][SENS] mtr
```
Ein erfolgreicher Ping beweist nur, dass die verwendete ICMP-Kommunikation in dieser Richtung und zu diesem Zeitpunkt funktioniert hat. Er beweist nicht, dass:
- ein bestimmter TCP- oder UDP-Port erreichbar ist
- DNS korrekt arbeitet
- die Anwendung antwortet
- TLS funktioniert
- Authentifizierung erfolgreich ist
- der Rückweg für alle Verbindungen identisch ist
Ein fehlgeschlagener Ping beweist umgekehrt keinen vollständigen Ausfall, da ICMP gefiltert oder begrenzt werden kann.
16. DNS-Auflösung untersuchen
```bash
[RO][SENS] cat /etc/resolv.conf
[RO][SENS] getent hosts
[TEST][REMOTE][SENS] dig
[TEST][REMOTE][SENS] dig A
[TEST][REMOTE][SENS] dig AAAA
[TEST][REMOTE][SENS] dig -x
[TEST][REMOTE][SENS] dig @
[TEST][REMOTE][SENS] resolvectl query
[RO][SENS] resolvectl status
```
`getent hosts` berücksichtigt die konfigurierte Namensdienstauflösung des Systems und kann daher für die tatsächliche Anwendungssicht aussagekräftiger sein als eine isolierte DNS-Abfrage.
Zu prüfen sind:
- Inhalt von `/etc/nsswitch.conf`
- konfigurierte Resolver
- Suchdomänen
- Split DNS
- lokale Hosts-Datei
- Cache
- VPN-Konfiguration
- systemd-resolved
- NetworkManager
- A- und AAAA-Einträge
- Reverse Lookup
- DNSSEC-Fehler
- unterschiedliche Antworten verschiedener Server
> `/etc/resolv.conf` kann eine automatisch erzeugte Datei oder ein symbolischer Link sein. Manuelle Änderungen können überschrieben werden und sind nicht zwingend die richtige dauerhafte Konfigurationsmethode.
17. Ports, Sockets und Verbindungen prüfen
```bash
[RO][PRIV][SENS] sudo ss -lntup
[RO][SENS] ss -tan
[RO][SENS] ss -s
[RO][PRIV][SENS] sudo lsof -i
[TEST][REMOTE] nc -vz
[TEST][REMOTE][SENS] curl -v
```
Zu prüfen sind:
- lauscht der Dienst überhaupt?
- an welcher Adresse lauscht er?
- IPv4, IPv6 oder beides?
- stimmt der Port?
- welcher Prozess besitzt den Socket?
- ist nur `127.0.0.1` beziehungsweise `::1` gebunden?
- erreicht der Client den Port?
- kommt eine Anwendungsantwort zurück?
- scheitert TLS oder Authentifizierung?
- existieren viele halboffene oder wartende Verbindungen?
> Ein offener TCP-Port beweist nur, dass eine Verbindung angenommen werden kann. Die fachliche Funktion der Anwendung muss separat getestet werden.
18. Netzwerkverkehr mit Tcpdump erfassen
```bash
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i host
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i port
[TEST][PRIV][REMOTE][LOG][SENS] sudo tcpdump -i -nn -s 0 -w .pcap
```
Vor einer Aufzeichnung müssen festgelegt werden:
- richtiges Interface
- geeigneter Filter
- Aufzeichnungsdauer
- Speicherort
- maximaler Speicherbedarf
- Zeitpunkt des Fehlers
- Datenschutz
- sichere Übertragung
- Löschfrist
Eine Paketaufzeichnung kann enthalten:
- IP-Adressen
- DNS-Anfragen
- Hostnamen
- unverschlüsselte Anwendungsdaten
- Sitzungsinformationen
- interne Netzwerkstrukturen
- Kommunikationsbeziehungen
> Ohne Begrenzung kann eine Aufzeichnung sehr groß werden. Bei produktiven Systemen sollten rotierende Dateien, zeitliche Begrenzung und möglichst enge Capture-Filter verwendet werden.
19. Firewall und Paketfilter prüfen
Je nach System können unterschiedliche Frameworks oder Verwaltungswerkzeuge eingesetzt werden.
```bash
[RO][PRIV][SENS] sudo nft list ruleset
[RO][PRIV][SENS] sudo iptables -S
[RO][PRIV][SENS] sudo iptables -t nat -S
[RO][PRIV][SENS] sudo firewall-cmd --list-all
[RO][PRIV][SENS] sudo ufw status verbose
```
Zu prüfen sind:
- tatsächlich aktives Firewall-Backend
- Eingangs-, Ausgangs- und Weiterleitungsregeln
- Standardrichtlinien
- Regelreihenfolge
- Interfaces und Zonen
- Quell- und Zielnetze
- Ports und Protokolle
- NAT
- Connection Tracking
- IPv4 und IPv6
- Container- oder Virtualisierungsregeln
- persistente gegenüber aktuell geladenen Regeln
> Mehrere Werkzeuge können auf dasselbe oder auf unterschiedliche Backends zugreifen. Eine leere `iptables`-Ausgabe beweist daher nicht automatisch, dass keine Filterregeln aktiv sind.
20. NetworkManager untersuchen
```bash
[RO][SENS] nmcli general status
[RO][SENS] nmcli device status
[RO][SENS] nmcli connection show
[RO][SENS] nmcli device show
[RO][SENS] nmcli connection show ""
[RO][PRIV][SENS] journalctl -u NetworkManager -b
```
Zu prüfen sind:
- verwaltete und nicht verwaltete Interfaces
- aktive Verbindung
- Verbindungsprofil
- DHCP-Daten
- DNS-Konfiguration
- Route und Metrik
- Autoconnect
- VLAN, Bond oder Bridge
- Zeitpunkt eines Linkwechsels
- Konflikte mit anderen Netzwerkverwaltungen
> Änderungen mit `nmcli` können eine SSH-Verbindung sofort unterbrechen. Vor Remoteänderungen sind Konsolenzugang und Rückfallplan erforderlich.
21. Benutzer, Gruppen und Berechtigungen prüfen
```bash
[RO][SENS] id
[RO][SENS] groups
[RO][SENS] getent passwd
[RO][SENS] getent group
[RO][SENS] namei -l
[RO][SENS] stat
[RO][SENS] ls -ld
[RO][SENS] getfacl
```
Bei einem Pfadproblem müssen alle übergeordneten Verzeichnisse berücksichtigt werden. Für das Durchlaufen eines Verzeichnisses ist das Ausführungsrecht am Verzeichnis entscheidend.
Zu unterscheiden sind:
- Eigentümer
- Gruppe
- klassische Modusbits
- ACLs
- umask
- effektive Benutzer- und Gruppen-ID
- ergänzende Gruppen
- Mount-Optionen
- SELinux oder AppArmor
- Container- und Namespace-Zuordnung
- NFS- oder SMB-Berechtigungen
> `chmod 777` ist keine fachgerechte Standardlösung. Es kann Daten ungewollt für alle lokalen Benutzer veränderbar machen und verdeckt die eigentliche Ursache.
22. SELinux und AppArmor berücksichtigen
**SELinux**
```bash
[RO] getenforce
[RO] sestatus
[RO][PRIV][SENS] sudo ausearch -m AVC,USER_AVC -ts recent
[RO][PRIV][SENS] sudo journalctl | grep -i "avc:"
```
**AppArmor**
```bash
[RO] aa-status
[RO][PRIV][SENS] sudo journalctl -k | grep -i apparmor
```
Ein Unix-Dateirecht kann korrekt erscheinen, während eine Mandatory-Access-Control-Richtlinie den Zugriff trotzdem verhindert.
> SELinux dauerhaft zu deaktivieren oder ein AppArmor-Profil ungeprüft abzuschalten ist keine geeignete Ursachenanalyse. Zuerst müssen die konkrete Ablehnung, der betroffene Kontext und die erwartete Richtlinie festgestellt werden.
23. Geöffnete Dateien und Systemaufrufe untersuchen
```bash
[RO][PRIV][SENS] sudo lsof -p
[RO][PRIV][SENS] sudo lsof
[RO][PRIV][SENS] sudo lsof -i :
[TEST][PRIV][LOG][SENS] sudo strace -p
[TEST][PRIV][LOG][SENS] sudo strace -f -o
```
`strace` kann sichtbar machen, ob ein Prozess beispielsweise an folgenden Vorgängen scheitert:
- Datei öffnen
- Namensauflösung
- Socket-Verbindung
- Berechtigungsprüfung
- Lesen oder Schreiben
- Warten auf ein Ereignis
- Start eines Kindprozesses
Die Ausgabe kann sehr umfangreich sein und sensible Daten enthalten. Außerdem kann Tracing das Zeitverhalten eines Prozesses beeinflussen.
> Ein produktiver Prozess sollte nur mit geklärter Auswirkung verfolgt werden. Geheimnisse, Pfade und Nutzdaten können in der Ausgabe erscheinen.
24. Paketbestand und beschädigte Installationen prüfen
**Debian- und Ubuntu-basierte Systeme**
```bash
[RO][SENS] dpkg -l
[RO] dpkg -S
[RO] apt-cache policy
[RO][PRIV] sudo dpkg --verify
```
**RPM-basierte Systeme**
```bash
[RO][SENS] rpm -qa
[RO] rpm -qf
[RO] rpm -V
[RO] dnf info
```
Zu prüfen sind:
- installierte Version
- Paketquelle
- Abhängigkeiten
- geänderte Paketdateien
- unvollständige Transaktion
- zurückgehaltene Pakete
- gemischte Repositorys
- Architektur
- Zeitpunkt des Updates
- erforderlicher Dienst- oder Systemneustart
> Eine Paketverifikation zeigt Abweichungen, bewertet aber nicht automatisch, ob diese absichtlich, harmlos oder fehlerursächlich sind.
25. Bootvorgang untersuchen
```bash
[RO] systemd-analyze
[RO] systemd-analyze blame
[RO] systemd-analyze critical-chain
[RO][SENS] journalctl -b
[RO][SENS] journalctl -b -1
[RO] systemctl --failed
[RO][PRIV][SENS] sudo dmesg --ctime
```
Bei Startproblemen sind zu prüfen:
- Bootloader
- Kernelparameter
- initramfs
- Root-Dateisystem
- `/etc/fstab`
- Geräte-UUIDs
- Mount-Zeitlimits
- systemd-Abhängigkeiten
- Netzwerkabhängigkeiten
- verschlüsselte Datenträger
- ausgefallene Dienste
- vorheriger Bootvorgang
`systemd-analyze blame` zeigt die Initialisierungszeit einzelner Units, beweist aber nicht allein, dass die oben angezeigte Unit den gesamten Start entsprechend verzögert hat. Parallelisierung und Abhängigkeiten müssen berücksichtigt werden.
26. Zeit und Zeitsynchronisation prüfen
```bash
[RO] date
[RO] timedatectl
[RO] timedatectl timesync-status
[RO][SENS] chronyc tracking
[RO][SENS] chronyc sources -v
```
Die verfügbaren Befehle hängen vom eingesetzten Zeitdienst ab.
Zu prüfen sind:
- Systemzeit
- Zeitzone
- Hardwareuhr
- aktive Synchronisation
- verwendete Zeitquelle
- Offset
- Erreichbarkeit der Zeitserver
- Virtualisierungszeitquelle
- Zeitänderungen in den Protokollen
- Zertifikatsgültigkeit
- Kerberos- oder Verzeichnisdienstabhängigkeiten
> Eine falsche Systemzeit kann Protokollkorrelation, TLS, Authentifizierung, Datenbanken und geplante Aufgaben beeinträchtigen.
27. Geplante Aufgaben untersuchen
```bash
[RO][SENS] crontab -l
[RO][PRIV][SENS] sudo crontab -l
[RO][PRIV][SENS] sudo ls -la /etc/cron.*
[RO] systemctl list-timers --all
[RO] systemctl status .timer
[RO][SENS] journalctl -u .timer
[RO][SENS] journalctl -u .service
```
Typische Fehlerursachen:
- anderer Benutzerkontext
- eingeschränkte Umgebungsvariablen
- anderer `PATH`
- relative Pfade
- fehlende Ausführungsrechte
- nicht vorhandenes Arbeitsverzeichnis
- gesperrte Dateien
- Zeitzone
- überlappende Ausführungen
- fehlgeschlagene Weiterleitung der Ausgabe
- Timer oder Dienst deaktiviert
> Ein Skript, das in einer interaktiven Shell funktioniert, muss unter Cron oder einem systemd-Timer nicht mit derselben Umgebung ausgeführt werden.
28. Container und Virtualisierung berücksichtigen
```bash
[RO] systemd-detect-virt
[RO][SENS] cat /proc/1/cgroup
[RO][SENS] lsns
[RO][SENS] docker ps
[RO][SENS] podman ps
[RO][SENS] docker inspect
[RO][SENS] docker logs
```
Bei Containerproblemen müssen Host und Container getrennt untersucht werden:
- Prozess im Container
- Containerzustand
- Restart Policy
- Exit-Code
- Healthcheck
- Logs
- Portveröffentlichung
- Container-Netzwerk
- DNS
- Volumes und Bind Mounts
- Benutzer-ID
- cgroup-Grenzen
- Host-Firewall
- Host-Speicherplatz
- Host-Kernel
> Ein laufender Container beweist nicht, dass der darin betriebene Dienst erreichbar oder funktionsfähig ist. Ein Container verwendet grundsätzlich den Kernel des Hosts und ist keine vollständige virtuelle Maschine.
29. Bash-Skripte kontrolliert debuggen
**Syntax prüfen**
```bash
[RO] bash -n
```
**Ablauf mit Trace ausführen**
```bash
[TEST][LOG][SENS] bash -x
```
In einem Skript kann die Trace-Ausgabe abschnittsweise aktiviert werden:
```bash
set -x
set +x
```
Zu prüfen sind:
- Shebang
- Shell-Kompatibilität
- Variablen
- Quoting
- Leerzeichen in Pfaden
- Rückgabecodes
- Pipelines
- relative Pfade
- Benutzerkontext
- Umgebungsvariablen
- Dateirechte
- parallele Ausführung
> `set -x` kann Kennwörter, Tokens, Argumente und andere Geheimnisse in Protokolle schreiben. Es darf nicht unkontrolliert in produktiven Skripten aktiviert werden.
30. Typische Fehlerbilder und geeignete Werkzeuge
| Fehlerbild | Geeignete Prüfungen |
|---|---|
| Dienst startet nicht | `systemctl status`, `journalctl -u`, Unit-Konfiguration, Abhängigkeiten, Rechte |
| Server reagiert langsam | `uptime`, `top`, `vmstat`, `iostat`, `free`, Prozess- und I/O-Analyse |
| Datenträger voll | `df -hT`, `df -i`, `du`, `lsof +L1`, Journalgröße |
| Prozess wird beendet | Kerneljournal, OOM-Meldungen, cgroup-Grenzen, Dienstkonfiguration |
| Port nicht erreichbar | `ss`, Dienst-Bindung, Firewall, Route, `nc`, `tcpdump` |
| Hostname wird falsch aufgelöst | `getent`, `dig`, `resolvectl`, `nsswitch.conf`, Hosts-Datei |
| Netzwerk fällt sporadisch aus | Linkstatistik, NetworkManager-Journal, Route, `mtr`, `tcpdump` |
| Datei kann nicht geöffnet werden | `namei`, `stat`, `getfacl`, SELinux/AppArmor, `lsof`, `strace` |
| System bootet langsam | `systemd-analyze`, vorheriges Journal, Mounts, Abhängigkeiten |
| Root-Dateisystem nur lesbar | Kernelmeldungen, I/O-Fehler, Dateisystemzustand, Storage |
| Cronjob läuft nicht | Benutzerkontext, Umgebung, absolute Pfade, Cronlogs, Exit-Code |
| Container startet ständig neu | Containerstatus, Exit-Code, Logs, Healthcheck, Volumes, Ressourcen |
| Anwendung funktioniert lokal, aber nicht remote | Bind-Adresse, Firewall, Routing, NAT, DNS, TLS |
| Zeitstempel sind unplausibel | `timedatectl`, Zeitdienst, Zeitzone, VM-Zeitquelle |
| Änderungen verschwinden nach Neustart | persistente Konfiguration, generierte Dateien, NetworkManager, systemd-Drop-ins |
31. Empfohlener Gesamtablauf bei Linux-Problemen
1. vollständige Fehlermeldung erfassen.
2. Benutzer, Host, Dienst und Zeitpunkt dokumentieren.
3. Umfang und Reproduzierbarkeit bestimmen.
4. letzte Änderung feststellen.
5. Distribution, Version, Kernel und Laufzeitumgebung erfassen.
6. Systemzeit und Uptime prüfen.
7. CPU, Load, Arbeitsspeicher und I/O überblicken.
8. Speicherplatz und Inodes prüfen.
9. betroffenen Prozess oder Dienst bestimmen.
10. Dienststatus und Abhängigkeiten prüfen.
11. Journal im passenden Zeitfenster auswerten.
12. Kernelmeldungen kontrollieren.
13. Konfiguration und Berechtigungen prüfen.
14. SELinux oder AppArmor berücksichtigen.
15. bei Netzwerkproblemen Adapter, Adressen und Routen prüfen.
16. DNS-Auflösung über den tatsächlich verwendeten Resolver testen.
17. Ports und Bind-Adressen prüfen.
18. Firewall und Paketpfad untersuchen.
19. bei Bedarf eng gefilterte Paketaufzeichnung erstellen.
20. Hypothese aus mehreren Befunden formulieren.
21. kleinste reversible Maßnahme planen.
22. Sicherung und Rückfallplan prüfen.
23. Änderung kontrolliert durchführen.
24. denselben Fehlerfall erneut testen.
25. Dienste, Logs und Monitoring nachkontrollieren.
26. temporäres Debugging deaktivieren.
27. Ursache, Maßnahme und Ergebnis dokumentieren.
32. Gefährliche Fehlinterpretationen vermeiden
| Beobachtung | Nicht automatisch bewiesen |
|---|---|
| Prozess erscheint in `ps` | Anwendung funktioniert |
| Dienst ist `active` | Dienst ist fachlich erreichbar |
| Port steht auf `LISTEN` | Remotezugriff funktioniert |
| Ping funktioniert | TCP, UDP, DNS und Anwendung funktionieren |
| DNS liefert eine Adresse | Adresse ist aktuell und der Dienst erreichbar |
| `free` zeigt wenig freien RAM | akuter Speichermangel |
| Load Average ist hoch | ausschließlich CPU-Überlastung |
| `df` zeigt freien Platz | genügend freie Inodes vorhanden |
| `du` ist kleiner als `df` | Dateisystem ist beschädigt |
| SMART meldet `PASSED` | Datenträger ist fehlerfrei |
| Firewallregel existiert | sie trifft in der gewünschten Richtung zu |
| Dateirechte sind korrekt | SELinux, AppArmor oder ACLs erlauben den Zugriff |
| Neustart behebt das Symptom | Ursache ist behoben |
| Paketdatei wurde verändert | Veränderung verursacht den Fehler |
| Container läuft | Anwendung im Container ist gesund |
| keine Fehlermeldung sichtbar | Vorgang war erfolgreich |
33. Sicherheits- und Datenschutzanforderungen
Linux-Diagnosedaten können enthalten:
- Benutzernamen und Gruppen
- Hostnamen
- interne IP-Adressen
- MAC-Adressen
- DNS-Namen
- Prozessargumente
- Dateipfade
- Umgebungsvariablen
- Netzwerkverbindungen
- Paketmitschnitte
- SSH-Zugriffe
- Authentifizierungsereignisse
- Containerkonfigurationen
- Volume-Pfade
- Tokens und Zugangsdaten
- interne Anwendungsdaten
Vor einer Weitergabe müssen:
1. Zweck und Empfänger bestimmt werden.
2. nur erforderliche Daten erfasst werden.
3. Kennwörter, Schlüssel, Cookies und Tokens entfernt werden.
4. personenbezogene Angaben redigiert werden.
5. Paketmitschnitte besonders geschützt werden.
6. Dateien verschlüsselt übertragen werden.
7. Zugriffsrechte und Aufbewahrungsdauer festgelegt werden.
8. temporäres Debugging deaktiviert werden.
9. nicht mehr benötigte Diagnosedaten sicher gelöscht werden.
10. externe Analysedienste organisatorisch freigegeben sein.
> Shell-History, Prozesslisten und Trace-Ausgaben können Geheimnisse enthalten, wenn diese als Befehlsargumente übergeben wurden.
34. Dokumentationsvorlage
```text
Ticket:
Datum und Uhrzeit:
Bearbeiter:
Hostname:
Distribution:
Version:
Kernel:
Architektur:
Physisch, VM oder Container:
Zeitzone:
Uptime:
Betroffener Benutzer:
Betroffener Dienst:
Betroffener Prozess:
PID:
Originale Fehlermeldung:
Fehlerzeitpunkt:
Reproduzierbar:
Betroffene Systeme:
Letzte funktionierende Nutzung:
Letzte Änderung:
CPU-Auslastung:
Load Average:
Arbeitsspeicher:
Swap:
OOM-Ereignis:
Datenträgerauslastung:
Freier Speicher:
Freie Inodes:
I/O-Wartezeit:
Dateisystem:
Mount-Optionen:
Kernelmeldungen:
Dienststatus:
Unit-Datei:
Drop-ins:
Abhängigkeiten:
Startbenutzer:
Exit-Code:
Journal-Zeitraum:
Erste relevante Fehlermeldung:
Interface:
IP-Adresse:
Präfix:
Gateway:
Route:
DNS-Server:
DNS-Ergebnis:
Lauschadresse:
Port:
Firewall:
Paketaufzeichnung:
Dateipfad:
Eigentümer:
Gruppe:
Modus:
ACL:
SELinux:
AppArmor:
Geöffnete Dateien:
Strace verwendet:
Paket:
Installierte Version:
Paketquelle:
Verifikation:
Letztes Update:
Vermutete Ursache:
Belege:
Geplante Maßnahme:
Sicherung:
Rückfallplan:
Durchgeführte Änderung:
Testergebnis:
Monitoring:
Abschluss:
```
---
**Merksatz**
> Bei der Linux-Fehleranalyse wird zuerst der Zustand gesichert und anschließend die Abhängigkeitskette geprüft: Hardware und Kernel stellen die Grundlage bereit, Dateisystem und Netzwerk ermöglichen den Zugriff, Benutzerrechte und Sicherheitsrichtlinien kontrollieren die Berechtigung, Dienste stellen die Funktion bereit und Protokolle verbinden Fehler, Zeitpunkt und Ursache.
**Quellen und weiterführende Dokumentation**
- [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html)
- [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html)
- [freedesktop.org – systemd-journald](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html)
- [freedesktop.org – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html)
- [freedesktop.org – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html)
- [freedesktop.org – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html)
- [Linux man-pages – Übersicht](https://man7.org/linux/man-pages/dir_all_alphabetic.html)
- [Linux man-pages – proc](https://man7.org/linux/man-pages/man5/proc.5.html)
- [Linux man-pages – ps](https://man7.org/linux/man-pages/man1/ps.1.html)
- [Linux man-pages – kill](https://man7.org/linux/man-pages/man1/kill.1.html)
- [Linux man-pages – ip](https://man7.org/linux/man-pages/man8/ip.8.html)
- [Linux man-pages – ss](https://man7.org/linux/man-pages/man8/ss.8.html)
- [Linux man-pages – mount](https://man7.org/linux/man-pages/man8/mount.8.html)
- [Linux man-pages – namespaces](https://man7.org/linux/man-pages/man7/namespaces.7.html)
- [Linux Kernel Documentation – Administrator’s Guide](https://docs.kernel.org/admin-guide/index.html)
- [Linux Kernel Documentation – Kernel Parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html)
- [Linux Kernel Documentation – Kdump](https://docs.kernel.org/admin-guide/kdump/kdump.html)
- [Linux Kernel Documentation – Magic SysRq](https://docs.kernel.org/admin-guide/sysrq.html)
- [Red Hat – Network Troubleshooting and Performance Tuning](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/)
- [Red Hat – NetworkManager Debugging](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/introduction-to-networkmanager-debugging)
# 5.5 macOS – Werkzeuge zur Fehleranalyse
**Kurz erklärt**
macOS stellt grafische Diagnoseprogramme und zahlreiche Unix-Werkzeuge im Terminal bereit. Damit lassen sich unter anderem folgende Bereiche untersuchen:
- Hardware und Betriebssystem,
- Prozesse und Ressourcenauslastung,
- Arbeitsspeicher,
- Datenträger und APFS,
- Netzwerk und DNS,
- Dienste und Hintergrundprozesse,
- System- und Anwendungsprotokolle,
- Energieverwaltung,
- Berechtigungen und Datenschutz,
- Systemerweiterungen,
- Startprobleme,
- interne Hardwarefehler.
Viele Terminalbefehle ähneln Linux-Befehlen. macOS verwendet jedoch eigene Komponenten und Verwaltungsmechanismen, beispielsweise:
- APFS,
- `launchd`,
- Unified Logging,
- System Integrity Protection,
- Transparency, Consent, and Control,
- Gatekeeper,
- Apple-Systemerweiterungen,
- macOS-Wiederherstellung.
> Ein Symptom ist noch keine Ursache. Auch unter macOS müssen zuerst Zustand, Zeitpunkt, Umfang und betroffene Komponente bestimmt werden, bevor Einstellungen verändert, Dateien gelöscht oder Dienste neu gestartet werden.
---
**1. Sichere Arbeitsweise**
Vor einer Veränderung sollten möglichst viele Informationen im fehlerhaften Zustand gesichert werden.
**Empfohlene Reihenfolge**
1. Störung und erwartetes Verhalten beschreiben.
2. Zeitpunkt und letzte Änderungen feststellen.
3. betroffene Benutzer, Geräte und Anwendungen bestimmen.
4. Systemversion und Hardwaremodell erfassen.
5. Prozess-, Ressourcen- und Netzwerkzustand dokumentieren.
6. relevante Protokolle sichern.
7. eine prüfbare Hypothese formulieren.
8. eine möglichst kleine und reversible Prüfung durchführen.
9. Ergebnis und Nebenwirkungen dokumentieren.
10. erst danach eine dauerhafte Lösung umsetzen.
**Vor Veränderungen prüfen**
- Ist ein aktuelles Backup vorhanden?
- Werden durch den Befehl Daten verändert oder gelöscht?
- Muss eine Anwendung vorher beendet werden?
- Wird ein produktiver Dienst unterbrochen?
- werden flüchtige Diagnoseinformationen vernichtet?
- ist ein Neustart tatsächlich erforderlich?
- bestehen Datenschutz- oder Geheimhaltungsanforderungen?
- ist die Maßnahme mit MDM-, Sicherheits- oder Unternehmensrichtlinien vereinbar?
**Wichtige Schutzmechanismen**
| Mechanismus | Bedeutung für die Fehleranalyse |
|---|---|
| Benutzerrechte | Viele Informationen sind nur für den aktuellen Benutzer sichtbar. |
| `sudo` | Führt einen Befehl mit erhöhten Rechten aus, hebt aber nicht automatisch alle macOS-Schutzmechanismen auf. |
| TCC | Kontrolliert unter anderem den Zugriff auf Dateien, Kamera, Mikrofon, Bildschirmaufnahme und Bedienungshilfen. |
| Festplattenvollzugriff | Kann für Terminal oder Diagnoseprogramme erforderlich sein, um geschützte Daten einzusehen. |
| SIP | Schützt kritische Systembereiche und Systemprozesse vor Veränderungen. |
| Gatekeeper | Bewertet heruntergeladene Programme und deren Signatur beziehungsweise Beglaubigung. |
| FileVault | verschlüsselt das Startvolume und beeinflusst Zugriff und Wiederherstellung. |
| MDM | Kann Einstellungen, Profile, Erweiterungen und Sicherheitsrichtlinien zentral vorgeben. |
> `sudo` und Festplattenvollzugriff sind nicht dasselbe. Ein als Administrator ausgeführter Prozess kann weiterhin durch TCC oder SIP eingeschränkt werden.
---
**2. Schnelle Systemübersicht**
Vor einer tieferen Analyse sollten Betriebssystem, Hardware, Laufzeit und Zeitpunkt erfasst werden.
**macOS-Version anzeigen**
```bash
sw_vers
```
Typische Ausgabe:
```text
ProductName: macOS
ProductVersion: 14.7.4
BuildVersion: 23H420
```
Nur die Versionsnummer:
```bash
sw_vers -productVersion
```
Nur die Buildnummer:
```bash
sw_vers -buildVersion
```
**Kernel und Architektur anzeigen**
```bash
uname -a
```
```bash
uname -m
```
Typische Architekturen:
| Ausgabe | Bedeutung |
|---|---|
| `arm64` | Prozess läuft nativ auf einem Mac mit Apple-Chip |
| `x86_64` | Intel-Prozess oder unter bestimmten Bedingungen ein durch Rosetta übersetzter Prozess |
**Hardware- und Systembericht**
```bash
system_profiler SPHardwareDataType SPSoftwareDataType
```
Kompaktere Darstellung:
```bash
system_profiler SPHardwareDataType SPSoftwareDataType -detailLevel mini
```
Alle verfügbaren Datentypen anzeigen:
```bash
system_profiler -listDataTypes
```
Bestimmte Bereiche gezielt untersuchen:
```bash
system_profiler SPNetworkDataType
```
```bash
system_profiler SPUSBDataType
```
```bash
system_profiler SPThunderboltDataType
```
```bash
system_profiler SPBluetoothDataType
```
```bash
system_profiler SPStorageDataType
```
```bash
system_profiler SPPowerDataType
```
```bash
system_profiler SPDisplaysDataType
```
> Ein vollständiger Aufruf von `system_profiler` kann umfangreich sein und längere Zeit benötigen. Für eine gezielte Fehleranalyse sollten nur die relevanten Datentypen abgefragt werden.
**Laufzeit und Last**
```bash
uptime
```
**Aktuelles Datum und Zeitzone**
```bash
date
```
```bash
systemsetup -gettimezone
```
`systemsetup` benötigt für viele Abfragen Administratorrechte:
```bash
sudo systemsetup -gettimezone
```
**Computername und Hostnamen**
```bash
scutil --get ComputerName
```
```bash
scutil --get LocalHostName
```
```bash
scutil --get HostName
```
Wenn kein expliziter HostName gesetzt wurde, kann der letzte Befehl eine Fehlermeldung ausgeben. Das beweist allein keine Störung.
---
**3. „Über diesen Mac“ und Systeminformationen**
Die grafische App **Systeminformationen** zeigt Hardware-, Netzwerk- und Softwareinformationen an.
**Öffnen**
- Apple-Menü → **Über diesen Mac** → **Weitere Infos** → **Systembericht**
- oder über Spotlight nach **Systeminformationen** suchen
- oder im Terminal:
```bash
open -a "System Information"
```
**Geeignete Diagnosebereiche**
- Hardwareübersicht,
- Stromversorgung,
- Speicher,
- Grafik und Displays,
- USB,
- Thunderbolt beziehungsweise USB4,
- Bluetooth,
- Netzwerk,
- WLAN,
- installierte Programme,
- Systemerweiterungen,
- Drucker,
- Speichergeräte.
**Typische Fragestellungen**
- Wird ein USB-Gerät überhaupt erkannt?
- Ist ein externer Datenträger auf Hardwareebene sichtbar?
- Welcher Netzwerkadapter gehört zu welchem BSD-Gerätenamen?
- Wird ein Display erkannt?
- Welche System- oder Netzwerkerweiterungen sind installiert?
- Welche Akkudaten und Ladezyklen werden gemeldet?
> Wenn ein Gerät in den Systeminformationen erscheint, ist zunächst nur seine Erkennung bestätigt. Daraus folgt noch nicht, dass Treiber, Berechtigungen, Anwendung und vollständige Funktion korrekt sind.
---
**4. Aktivitätsanzeige**
Die **Aktivitätsanzeige** ist das zentrale grafische Werkzeug zur Untersuchung laufender Prozesse und der Ressourcennutzung.
**Öffnen**
```bash
open -a "Activity Monitor"
```
Je nach Spracheinstellung wird die App als **Aktivitätsanzeige** dargestellt.
**Wichtige Bereiche**
| Bereich | wichtige Informationen |
|---|---|
| CPU | CPU-Anteil, CPU-Zeit, Threads, nicht reagierende Prozesse |
| Speicher | Speicherverbrauch, Speicherdruck, komprimierter Speicher, Swap |
| Energie | Energiebedarf einzelner Anwendungen |
| Festplatte | gelesene und geschriebene Daten |
| Netzwerk | empfangene und gesendete Daten und Pakete |
**Darstellung richtig auswählen**
Über **Darstellung** kann festgelegt werden, welche Prozesse angezeigt werden:
- alle Prozesse,
- alle Prozesse hierarchisch,
- eigene Prozesse,
- Systemprozesse,
- aktive Prozesse,
- Prozesse mit Fenstern.
Ein Prozess kann ansonsten übersehen werden, obwohl er weiterhin ausgeführt wird.
**Speicherdruck interpretieren**
| Zustand | Einordnung |
|---|---|
| Grün | Speicher kann derzeit effizient bereitgestellt werden. |
| Gelb | Speicherressourcen stehen unter zunehmendem Druck. |
| Rot | Der verfügbare Speicher reicht für die aktuelle Last nicht angemessen aus. |
Nicht allein der Wert „freier Speicher“ ist entscheidend. macOS verwendet freien Arbeitsspeicher bewusst als Cache. Aussagekräftiger sind:
- Speicherdruck,
- Swap-Nutzung,
- Komprimierung,
- Entwicklung über einen längeren Zeitraum,
- Zusammenhang mit dem Auftreten der Störung.
**Prozess beenden**
Die Aktivitätsanzeige bietet:
- **Beenden** – fordert einen geordneten Abbruch an,
- **Sofort beenden** – beendet den Prozess unmittelbar.
Vor dem Beenden prüfen:
- Sind ungespeicherte Daten vorhanden?
- Handelt es sich um einen Systemprozess?
- startet `launchd` den Prozess automatisch neu?
- ist der Prozess Ursache oder nur von einer anderen Störung betroffen?
> Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch fehlerhaft. Entscheidend sind Arbeitslast, Dauer, Benutzerwirkung und erwartetes Verhalten.
---
**5. Prozesse im Terminal untersuchen**
**Prozessliste**
```bash
ps aux
```
Nach einem Prozess suchen:
```bash
ps aux | grep -i "prozessname"
```
Damit der Suchbefehl selbst nicht als Treffer erscheint:
```bash
pgrep -afil "prozessname"
```
**Prozesse hierarchisch anzeigen**
```bash
ps -axo pid,ppid,user,%cpu,%mem,state,start,time,command
```
**Momentaufnahme der Ressourcennutzung**
```bash
top -l 1
```
Nach CPU-Auslastung sortieren:
```bash
top -l 1 -o cpu
```
Nach Speicherverbrauch sortieren:
```bash
top -l 1 -o mem
```
Nur einen bestimmten Prozess beobachten:
```bash
top -pid 1234
```
`1234` muss durch die tatsächliche Prozess-ID ersetzt werden.
**Signal zum geordneten Beenden senden**
```bash
kill 1234
```
**Erzwungenes Beenden**
```bash
kill -9 1234
```
`SIGKILL` sollte nur verwendet werden, wenn ein geordneter Abbruch nicht funktioniert. Der Prozess kann dann keine Aufräumarbeiten mehr ausführen oder Daten geordnet speichern.
**Prozess untersuchen**
```bash
sample 1234 10
```
Der Befehl erstellt für zehn Sekunden Stichproben der ausgeführten Funktionen. Das kann bei hoher CPU-Auslastung oder blockierten Prozessen helfen.
**Geöffnete Dateien und Verbindungen**
```bash
lsof -p 1234
```
Alle offenen Dateien mit einem bestimmten Pfad suchen:
```bash
lsof "/Pfad/zur/Datei"
```
Prozess ermitteln, der einen TCP-Port verwendet:
```bash
lsof -nP -iTCP:8080
```
Nur TCP-Listener anzeigen:
```bash
lsof -nP -iTCP -sTCP:LISTEN
```
**Bewertung**
| Beobachtung | mögliche Hypothese |
|---|---|
| dauerhaft hohe CPU-Last | Endlosschleife, rechenintensive Aufgabe, fehlerhafte Erweiterung |
| steigender Speicherverbrauch | Speicherleck, ungewöhnliche Datenmenge, Cache-Verhalten |
| Prozess reagiert nicht | blockierte Ein-/Ausgabe, Deadlock, abhängiger Dienst |
| Prozess startet nach Beenden erneut | Verwaltung durch `launchd`, Login-Objekt oder MDM |
| Port ist bereits belegt | konkurrierender Dienst oder zweite Programminstanz |
| Datei bleibt geöffnet | Prozess verhindert Aushängen, Verschieben oder Löschen |
Diese Beobachtungen sind Hinweise, aber noch keine bestätigten Ursachen.
---
**6. Arbeitsspeicher untersuchen**
**Speicherstatistik**
```bash
vm_stat
```
Die Werte werden überwiegend in Speicherseiten ausgegeben. Die Seitengröße steht in der ersten Ausgabezeile und darf nicht pauschal als immer identisch angenommen werden.
**Speicherdruck prüfen**
```bash
memory_pressure
```
**Swap-Nutzung**
```bash
sysctl vm.swapusage
```
**Wichtige Zusammenhänge**
- Hohe Speichernutzung allein beweist keinen Engpass.
- Dateicaches dürfen einen großen Teil des Speichers verwenden.
- Komprimierter Speicher ist Teil der normalen Speicherverwaltung.
- Dauerhaft hoher Speicherdruck und starke Swap-Aktivität können auf einen Engpass hinweisen.
- Ein einzelner Messwert reicht nicht zur Beurteilung einer zeitabhängigen Störung.
**Geeignete Beweiskette**
1. Zeitpunkt der Verlangsamung bestimmen.
2. Speicherdruck in der Aktivitätsanzeige prüfen.
3. Swap- und Komprimierungswerte erfassen.
4. Prozesse nach Speicherverbrauch sortieren.
5. Entwicklung über einen längeren Zeitraum beobachten.
6. Anwendungs- und Systemprotokolle zum gleichen Zeitpunkt auswerten.
---
**7. CPU- und Systemlast untersuchen**
**CPU-Übersicht**
```bash
top -l 1 -o cpu
```
**Lastmittelwerte**
```bash
uptime
```
Die drei Load-Average-Werte beziehen sich auf unterschiedliche Zeiträume. Sie dürfen nicht direkt wie Prozentwerte interpretiert werden.
**Prozessbezogene Stichprobe**
```bash
sample 1234 10
```
**Systemweite Diagnose bei Hängern**
```bash
sudo spindump
```
`spindump` sammelt umfangreiche Informationen über Prozesszustände und Aufrufstapel. Die Erfassung kann kurzfristig zusätzliche Last erzeugen und sensible Informationen enthalten.
**Mögliche Ursachen hoher CPU-Auslastung**
- legitime Medienverarbeitung,
- Indizierung durch Spotlight,
- Synchronisation,
- Update- oder Installationsvorgang,
- Browserprozess,
- fehlerhafte Anwendung,
- Erweiterung oder Plug-in,
- wiederholt abstürzender und neu gestarteter Dienst,
- Hintergrundanalyse nach einem Systemupdate.
> Erst prüfen, welche Arbeit der Prozess ausführt und ob die Last nach Abschluss der Aufgabe wieder sinkt.
---
**8. Datenträger, APFS und Speicherplatz**
**Dateisystembelegung**
```bash
df -h
```
Nur das Startvolume:
```bash
df -h /
```
**Verzeichnisgrößen**
```bash
du -sh ~/Downloads
```
Unterverzeichnisse vergleichen:
```bash
du -sh ~/Library/* 2>/dev/null
```
Fehlende Berechtigungen oder TCC-Schutz können dazu führen, dass nicht alle Verzeichnisse gelesen werden.
**Datenträgerstruktur**
```bash
diskutil list
```
**Informationen zum Startvolume**
```bash
diskutil info /
```
**APFS-Struktur**
```bash
diskutil apfs list
```
**Volume schreibgeschützt prüfen**
```bash
diskutil verifyVolume /
```
Das Prüfen kann Zeit und Ein-/Ausgabeleistung beanspruchen. Für produktive Systeme sollte die Auswirkung vorher bewertet werden.
**Festplattendienstprogramm öffnen**
```bash
open -a "Disk Utility"
```
In der App sollte für eine vollständige Darstellung gewählt werden:
**Darstellung → Alle Geräte einblenden**
Dadurch werden die Ebenen sichtbar:
1. physisches Speichergerät,
2. Partition beziehungsweise APFS-Container,
3. APFS-Volume,
4. gegebenenfalls APFS-Volumegruppe.
**Erste Hilfe**
Apple empfiehlt, bei einer Prüfung mit dem letzten Volume eines Speichergeräts zu beginnen und anschließend nacheinander weitere Volumes, Container und zuletzt das physische Speichergerät zu prüfen.
**Wichtige Grenzen**
- „Erste Hilfe“ ersetzt kein Backup.
- Ein physisch ausfallendes Speichergerät lässt sich nicht durch eine Dateisystemreparatur heilen.
- Reparaturversuche können ein bereits instabiles Gerät zusätzlich belasten.
- Bei ungewöhnlichen Geräuschen, E/A-Fehlern oder Ausfallwarnungen sollten zuerst wichtige Daten gesichert werden.
- Löschen, Partitionieren und Wiederherstellen sind keine Diagnosebefehle und können Daten vernichten.
**Datenträgeraktivität beobachten**
```bash
iostat -w 1
```
Abbruch mit:
```text
Control + C
```
**Dateisystemzugriffe live beobachten**
```bash
sudo fs_usage
```
Nach einem Prozess filtern:
```bash
sudo fs_usage -w -f filesystem | grep -i "prozessname"
```
`fs_usage` kann sehr viele Daten erzeugen und zusätzliche Last verursachen.
**Typische Fehlerbilder**
| Symptom | zu prüfen |
|---|---|
| Startvolume fast voll | `df`, große Benutzerdateien, lokale Snapshots, Caches, Protokolle |
| Volume wird nicht aktiviert | `diskutil list`, `diskutil info`, Dateisystemzustand |
| externes Laufwerk fehlt | Systeminformationen, Kabel, Stromversorgung, USB-/Thunderbolt-Erkennung |
| langsame Dateizugriffe | `iostat`, `fs_usage`, Synchronisation, Verschlüsselung, Datenträgerzustand |
| Dateien können nicht gelöscht werden | Berechtigungen, Flags, erweiterte Attribute, geöffnete Dateien |
| Volume ist schreibgeschützt | Dateisystemfehler, Bereitstellungsoptionen, Medium, Berechtigungen |
---
**9. Dateien, Berechtigungen und Attribute**
macOS verwendet neben klassischen Unix-Rechten weitere Eigenschaften:
- Access Control Lists,
- Dateiflags,
- erweiterte Attribute,
- TCC-Berechtigungen,
- SIP-Schutz,
- Sandbox-Regeln.
**Datei ausführlich anzeigen**
```bash
ls -leO@ "/Pfad/zur/Datei"
```
Bedeutung:
| Option | Anzeige |
|---|---|
| `-l` | ausführliche Dateiinformationen |
| `-e` | Access Control Lists |
| `-O` | Dateiflags |
| `-@` | erweiterte Attribute |
**Dateimetadaten**
```bash
stat "/Pfad/zur/Datei"
```
**Erweiterte Attribute**
```bash
xattr -l "/Pfad/zur/Datei"
```
Rekursiv anzeigen:
```bash
xattr -lr "/Pfad/zum/Ordner"
```
**Besitz und Rechte**
```bash
ls -ld "/Pfad/zum/Ordner"
```
**Geöffnete Datei ermitteln**
```bash
lsof "/Pfad/zur/Datei"
```
**Typische Ursachen für „Operation not permitted“**
- fehlender Festplattenvollzugriff,
- verweigerte TCC-Berechtigung,
- SIP-geschützter Bereich,
- Anwendungssandbox,
- fehlende Unix-Rechte,
- ACL-Regel,
- Dateiflag,
- MDM-Richtlinie.
> Eine Berechtigungsfehlermeldung sollte nicht sofort mit `chmod 777`, rekursivem `chown` oder dem Entfernen aller Attribute beantwortet werden. Zuerst muss geklärt werden, welcher Schutzmechanismus den Zugriff verhindert.
---
**10. Unified Logging und die App „Konsole“**
macOS verwendet ein zentrales Protokollsystem, das strukturierte Meldungen, Aktivitäten und Signposts verarbeiten kann.
**Konsole öffnen**
```bash
open -a Console
```
Die App kann unter anderem anzeigen:
- Live-Protokollmeldungen,
- Absturzberichte,
- Diagnoseberichte,
- Spin-Berichte,
- Systemberichte,
- Protokolle verbundener Geräte.
**Wichtige Filterkriterien**
- Zeitpunkt,
- Prozess,
- Subsystem,
- Kategorie,
- Meldungstext,
- Schweregrad,
- betroffener Benutzer,
- Ereignisse unmittelbar vor und nach der Störung.
**Aktuelle Protokolle anzeigen**
```bash
log show --last 1h --style compact
```
Nur Meldungen eines Prozesses:
```bash
log show --last 1h --style compact --predicate 'process == "Safari"'
```
Nach einem Textbestandteil suchen:
```bash
log show --last 1h --style compact --predicate 'eventMessage CONTAINS[c] "error"'
```
Live-Meldungen verfolgen:
```bash
log stream --style compact
```
Live nach Prozess filtern:
```bash
log stream --style compact --predicate 'process == "Safari"'
```
Nach Subsystem filtern:
```bash
log show --last 1h --style compact --predicate 'subsystem == "com.apple.network"'
```
Ob ein bestimmtes Subsystem tatsächlich verwendet wird, muss anhand vorhandener Ereignisse geprüft werden.
**Zeitfenster gezielt festlegen**
```bash
log show --start "2026-08-01 14:00:00" --end "2026-08-01 14:30:00" --style compact
```
**Logarchiv sammeln**
```bash
sudo log collect --last 1h --output ~/Desktop/SystemLogs.logarchive
```
Vor dem Weitergeben eines Logarchivs prüfen, ob es enthält:
- Benutzernamen,
- Dateipfade,
- Netzwerkadressen,
- Gerätenamen,
- Anwendungsdaten,
- interne Servernamen,
- andere vertrauliche Informationen.
**Fehlinterpretationen vermeiden**
| Beobachtung | korrekte Einordnung |
|---|---|
| Meldung enthält „error“ | Kann relevant sein, beweist aber nicht automatisch die Ursache. |
| keine sichtbare Fehlermeldung | Protokollierung kann eingeschränkt, verzögert, privat oder in einem anderen Subsystem erfolgt sein. |
| viele Meldungen eines Prozesses | Hohe Meldungszahl ist nicht automatisch ein Fehler. |
| Meldung liegt zeitlich nach dem Symptom | Sie kann Folge statt Ursache sein. |
| wiederkehrende Warnung | Bedeutung muss mit Funktion, Zeitpunkt und Auswirkung abgeglichen werden. |
> Protokolle sollten nicht ausschließlich nach den Wörtern „error“ oder „failed“ durchsucht werden. Entscheidend sind zeitlicher Zusammenhang, betroffene Komponente und technische Bedeutung.
---
**11. Absturz- und Diagnoseberichte**
Typische benutzerbezogene Diagnoseberichte befinden sich unter:
```text
~/Library/Logs/DiagnosticReports/
```
Systemweite Berichte können sich unter folgendem Pfad befinden:
```text
/Library/Logs/DiagnosticReports/
```
Inhalte anzeigen:
```bash
ls -lt ~/Library/Logs/DiagnosticReports/
```
Nach einem Programmnamen suchen:
```bash
find ~/Library/Logs/DiagnosticReports -type f -iname "*Programmname*"
```
**Typische Berichtstypen**
| Bericht | mögliche Bedeutung |
|---|---|
| Crash Report | Prozess wurde durch einen Fehler oder ein Signal beendet |
| Hang Report | Anwendung reagierte über einen bestimmten Zeitraum nicht |
| Spin Report | Prozess war aktiv, konnte aber nicht angemessen fortfahren |
| Panic Report | schwerwiegender Kernel- oder Hardwarekontext |
| Jetsam-/Ressourcenbericht | Prozessbeendigung oder Einschränkung aufgrund von Ressourcenbedingungen |
**Bei der Auswertung prüfen**
- Prozessname und Version,
- macOS-Version und Build,
- Architektur,
- Zeitpunkt,
- Ausnahmeart,
- beendender Thread,
- geladene Bibliotheken,
- wiederkehrende Drittanbieterkomponenten,
- Auftreten nach Update oder Konfigurationsänderung.
Ein Funktionsname im abstürzenden Thread beweist nicht automatisch, dass genau diese Komponente die eigentliche Ursache ist.
---
**12. Netzwerkadapter und Netzwerkkonfiguration**
**Alle Schnittstellen**
```bash
ifconfig
```
Nur aktive Schnittstellen:
```bash
ifconfig -u
```
**Hardwareports und BSD-Gerätenamen zuordnen**
```bash
networksetup -listallhardwareports
```
Beispiel:
```text
Hardware Port: Wi-Fi
Device: en0
Ethernet Address: aa:bb:cc:dd:ee:ff
```
Der Gerätename darf nicht pauschal als `en0` angenommen werden. Er muss auf dem jeweiligen Mac geprüft werden.
**Alle Netzwerkdienste**
```bash
networksetup -listallnetworkservices
```
Ein Stern vor einem Netzwerkdienst bedeutet, dass dieser deaktiviert ist.
**Konfiguration eines Dienstes**
```bash
networksetup -getinfo "Wi-Fi"
```
**IP-Adresse einer Schnittstelle**
```bash
ipconfig getifaddr en0
```
`en0` muss durch die tatsächlich ermittelte Schnittstelle ersetzt werden.
**DHCP-Informationen**
```bash
ipconfig getpacket en0
```
**Standardroute**
```bash
route -n get default
```
**Routingtabelle**
```bash
netstat -rn
```
**Aktueller DNS-Zustand**
```bash
scutil --dns
```
Die Ausgabe zeigt die tatsächlich von macOS verwalteten Resolver und ist für die Diagnose häufig aussagekräftiger als das alleinige Betrachten einer einzelnen DNS-Adresse in den Systemeinstellungen.
**Proxykonfiguration**
```bash
scutil --proxy
```
**Netzwerkzustand beobachten**
```bash
scutil --nwi
```
**Typische Prüfreihenfolge**
1. Wird der Adapter erkannt?
2. Ist die Schnittstelle aktiv?
3. besitzt sie eine erwartete IP-Konfiguration?
4. existiert eine passende Route?
5. ist das lokale Gateway erreichbar?
6. funktioniert die Namensauflösung?
7. ist der Zielport erreichbar?
8. funktioniert das Anwendungsprotokoll?
9. beeinflussen VPN, Proxy, Filter oder Firewall die Verbindung?
---
**13. Erreichbarkeit, DNS und Ports prüfen**
**IP-Erreichbarkeit**
```bash
ping -c 4 192.168.1.1
```
**Namensauflösung und Erreichbarkeit**
```bash
ping -c 4 example.com
```
Ein fehlgeschlagener Ping beweist nicht automatisch, dass ein Host oder Dienst nicht erreichbar ist. ICMP kann gefiltert werden.
**Route untersuchen**
```bash
traceroute example.com
```
**DNS-Abfrage**
```bash
dig example.com
```
Bestimmten DNS-Server abfragen:
```bash
dig @192.168.1.1 example.com
```
**macOS-Systemauflösung prüfen**
```bash
dscacheutil -q host -a name example.com
```
**Zielport testen**
```bash
nc -vz example.com 443
```
UDP-Prüfungen mit `nc` liefern aufgrund der verbindungslosen Arbeitsweise von UDP nicht dieselbe Bestätigung wie ein erfolgreicher TCP-Verbindungsaufbau.
**HTTP- und TLS-Verbindung**
```bash
curl -v https://example.com/
```
Nur Header abrufen:
```bash
curl -I https://example.com/
```
Zeitwerte erfassen:
```bash
curl -o /dev/null -sS \
-w 'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nGesamt: %{time_total}\n' \
https://example.com/
```
**Lokale Listener**
```bash
lsof -nP -iTCP -sTCP:LISTEN
```
**Verbindungen eines Prozesses**
```bash
lsof -nP -a -p 1234 -i
```
> Eine erfolgreiche TCP-Verbindung bestätigt nur, dass der Verbindungsaufbau zu diesem Ziel und Port möglich war. Sie bestätigt noch keine korrekte Anmeldung, Anwendungsfunktion oder Datenverarbeitung.
---
**14. Paketmitschnitt unter macOS**
macOS enthält `tcpdump`.
**Verfügbare Schnittstellen**
```bash
sudo tcpdump -D
```
**Verkehr einer Schnittstelle beobachten**
```bash
sudo tcpdump -i en0
```
**Ohne Namensauflösung**
```bash
sudo tcpdump -nn -i en0
```
**Nur Verkehr eines Hosts**
```bash
sudo tcpdump -nn -i en0 host 192.168.1.50
```
**Nur einen Port**
```bash
sudo tcpdump -nn -i en0 port 443
```
**In eine Datei schreiben**
```bash
sudo tcpdump -nn -i en0 -w ~/Desktop/mitschnitt.pcap
```
**Begrenzte Anzahl Pakete**
```bash
sudo tcpdump -nn -i en0 -c 500 -w ~/Desktop/mitschnitt.pcap
```
**Vor dem Mitschnitt festlegen**
- richtige Schnittstelle,
- geeigneter Capture-Filter,
- notwendige Dauer,
- maximale Paketanzahl oder Dateigröße,
- Zielpfad,
- Datenschutz,
- sichere Aufbewahrung,
- Löschung nach Abschluss der Analyse.
Paketmitschnitte können enthalten:
- IP-Adressen,
- Hostnamen,
- DNS-Abfragen,
- Kommunikationsbeziehungen,
- unverschlüsselte Inhalte,
- Authentifizierungsinformationen,
- personenbezogene oder vertrauliche Daten.
---
**15. WLAN-Diagnose**
**Verbindungsinformationen anzeigen**
Bei gedrückter **Option-Taste** auf das WLAN-Symbol in der Menüleiste klicken.
Je nach macOS-Version werden unter anderem angezeigt:
- IP-Adresse,
- Routeradresse,
- Kanal,
- Frequenzband,
- Sicherheitsstandard,
- verwendetes 802.11-Protokoll,
- weitere Verbindungsdaten.
**Diagnose für drahtlose Umgebungen**
1. Mit dem problematischen WLAN verbinden.
2. Option-Taste gedrückt halten.
3. WLAN-Menü öffnen.
4. **Diagnose für drahtlose Umgebungen öffnen** wählen.
Apple weist darauf hin, dass die Diagnoseanalyse selbst keine Änderungen an den Netzwerkeinstellungen vornimmt.
**Mögliche Diagnosebereiche**
- Signalqualität,
- Störquellen,
- Kanalbelegung,
- Verbindungsabbrüche,
- Authentifizierung,
- Verbindung zum Router,
- Internetzugriff.
**Wichtige Abgrenzung**
| Beobachtung | Einordnung |
|---|---|
| WLAN ist verbunden | bestätigt nicht automatisch Internetzugriff |
| starke Signalstärke | bestätigt nicht automatisch geringe Störung oder hohen Durchsatz |
| Internet funktioniert | bestätigt nicht automatisch lokale DNS-, VPN- oder Anwendungsfunktion |
| anderes Gerät funktioniert | grenzt ein, schließt aber benutzer- oder gerätespezifische Ursachen nicht aus |
| Ethernet funktioniert | spricht für einen WLAN-bezogenen Unterschied, beweist aber noch keine bestimmte WLAN-Ursache |
---
**16. Dienste und `launchd`**
macOS verwendet `launchd` zur Verwaltung vieler System- und Benutzerdienste.
**Benutzerdomäne anzeigen**
```bash
launchctl print gui/$(id -u)
```
**Systemdomäne anzeigen**
```bash
sudo launchctl print system
```
**Bestimmten Benutzerdienst untersuchen**
```bash
launchctl print gui/$(id -u)/com.beispiel.dienst
```
**Bestimmten Systemdienst untersuchen**
```bash
sudo launchctl print system/com.beispiel.dienst
```
Der genaue Dienstbezeichner muss vorher ermittelt werden.
**Typische Speicherorte**
```text
~/Library/LaunchAgents/
/Library/LaunchAgents/
/Library/LaunchDaemons/
/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/
```
Bedeutung:
| Ort | typischer Zweck |
|---|---|
| `~/Library/LaunchAgents` | benutzerspezifische Agenten |
| `/Library/LaunchAgents` | zusätzliche Agenten für Benutzer |
| `/Library/LaunchDaemons` | zusätzliche systemweite Daemons |
| `/System/Library/...` | von macOS bereitgestellte und geschützte Dienste |
**Eigenschaftslistendatei prüfen**
```bash
plutil -lint "/Pfad/zur/Datei.plist"
```
Inhalt lesbar ausgeben:
```bash
plutil -p "/Pfad/zur/Datei.plist"
```
**Typische Fehlerursachen**
- fehlerhafte PLIST-Syntax,
- falscher `Label`-Wert,
- nicht vorhandener Programmpfad,
- ungeeignete Dateirechte,
- falscher Besitzer,
- fehlende Arbeitsverzeichnisse,
- nicht verfügbare Umgebungsvariablen,
- TCC- oder Sandbox-Einschränkungen,
- wiederholter Absturz,
- widersprüchliche Agenten,
- veraltetes Login-Objekt.
> Dienste sollten nicht allein aufgrund ihres unbekannten Namens deaktiviert oder gelöscht werden. Zuerst müssen Hersteller, Pfad, Signatur, Zweck und Abhängigkeiten bestimmt werden.
---
**17. Login-Objekte und Hintergrundelemente**
Grafische Verwaltung:
**Systemeinstellungen → Allgemein → Anmeldeobjekte und Erweiterungen**
Dort können je nach macOS-Version unter anderem sichtbar sein:
- beim Anmelden geöffnete Programme,
- im Hintergrund erlaubte Programme,
- Erweiterungen,
- Netzwerk- oder Sicherheitskomponenten.
**Typische Diagnose**
1. Namen und Hersteller dokumentieren.
2. Installationspfad und Signatur prüfen.
3. Zeitpunkt der Installation feststellen.
4. Abhängigkeit von benötigten Anwendungen prüfen.
5. Element testweise kontrolliert deaktivieren.
6. Verhalten nach erneuter Anmeldung oder Neustart vergleichen.
7. Änderung anschließend zurücknehmen oder dokumentiert beibehalten.
Der sichere Modus kann helfen festzustellen, ob eine Störung mit beim Start geladenen Softwarebestandteilen zusammenhängt. Er benennt jedoch nicht automatisch die konkrete Ursache.
---
**18. Codesignatur und Gatekeeper prüfen**
**Signatur anzeigen**
```bash
codesign -dv --verbose=4 "/Applications/Beispiel.app"
```
Die Detailausgabe erfolgt bei `codesign` häufig über den Fehlerausgabekanal, obwohl kein Fehler vorliegt.
**Signatur verifizieren**
```bash
codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app"
```
**Gatekeeper-Bewertung**
```bash
spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app"
```
**Quarantäneattribut anzeigen**
```bash
xattr -l "/Applications/Beispiel.app"
```
**Paketinformationen**
```bash
pkgutil --pkg-info "Paketkennung"
```
Installierte Paketkennungen durchsuchen:
```bash
pkgutil --pkgs | grep -i "hersteller"
```
**Wichtige Einordnung**
- Eine gültige Signatur beweist Integrität gegenüber der signierten Version, aber nicht automatisch Fehlerfreiheit.
- Eine Gatekeeper-Ablehnung kann mit Signatur, Beglaubigung, Quarantäne oder Richtlinien zusammenhängen.
- Das Quarantäneattribut sollte nicht pauschal rekursiv entfernt werden.
- Das Deaktivieren von Gatekeeper oder SIP ist keine reguläre Fehlerbehebungsmethode.
- Unternehmensgeräte können zusätzliche MDM- und Sicherheitsrichtlinien besitzen.
---
**19. System- und Netzwerkerweiterungen**
Moderne macOS-Versionen verwenden für viele Funktionen Systemerweiterungen statt klassischer Kernel Extensions.
**Systemerweiterungen anzeigen**
```bash
systemextensionsctl list
```
**Geladene Kernelkomponenten untersuchen**
```bash
kmutil showloaded
```
Je nach Systemversion, Architektur und Berechtigung kann die Ausgabe eingeschränkt sein.
**Typische beteiligte Anwendungen**
- VPN-Clients,
- Endpoint-Security,
- Inhaltsfilter,
- Netzwerkschutz,
- Treiber,
- Audioanwendungen,
- Virtualisierungssoftware,
- Dateisynchronisation.
**Bei Problemen prüfen**
- ist die Erweiterung aktiviert?
- wurde sie vom Benutzer oder durch MDM genehmigt?
- passt die Version zur installierten macOS-Version?
- ist nach Installation ein Neustart erforderlich?
- existieren alte Komponenten eines früheren Produkts?
- wird Netzwerkverkehr durch einen Content Filter beeinflusst?
- tritt die Störung nach Deaktivierung kontrolliert nicht mehr auf?
Eine Sicherheits- oder Netzwerkerweiterung darf auf Unternehmenssystemen nicht ohne Freigabe deaktiviert werden.
---
**20. Energieverwaltung und Ruhezustand**
**Aktuelle Energieeinstellungen**
```bash
pmset -g
```
**Akkuzustand**
```bash
pmset -g batt
```
**Aktive Ruhezustandsverhinderungen**
```bash
pmset -g assertions
```
**Geplante Energieereignisse**
```bash
pmset -g sched
```
**Power-Management-Protokoll**
```bash
pmset -g log
```
Die Ausgabe kann sehr umfangreich sein und sollte zeitlich gefiltert werden.
**Hardwareinformationen zur Stromversorgung**
```bash
system_profiler SPPowerDataType
```
**Typische Fragestellungen**
- Welcher Prozess verhindert den Ruhezustand?
- erkennt macOS das Netzteil?
- wird der Akku geladen?
- bestehen ungewöhnlich viele Ladezyklen?
- tritt der Verbrauch nur bei einer bestimmten Anwendung auf?
- wacht der Mac wiederholt unerwartet auf?
- bestehen angeschlossene Geräte oder Netzwerkaktivitäten, die den Ruhezustand beeinflussen?
> Eine hohe Akkunutzung ist nicht automatisch ein Akkudefekt. Zuerst müssen Energieverbrauch, Arbeitslast, Display, Funkverbindungen, Hintergrundprozesse und angeschlossene Geräte geprüft werden.
---
**21. Spotlight untersuchen**
Spotlight-Indizierung kann zeitweise CPU-, Datenträger- und Energieauslastung verursachen.
**Status eines Volumes**
```bash
mdutil -s /
```
**Metadaten einer Datei**
```bash
mdls "/Pfad/zur/Datei"
```
**Spotlight-Suche im Terminal**
```bash
mdfind "Suchbegriff"
```
**Typische Hinweise auf Spotlight-Aktivität**
- Prozesse wie `mds`, `mds_stores` oder `mdworker`,
- erhöhte Datenträgeraktivität,
- Auftreten nach Update, Migration oder Anschluss eines Datenträgers,
- unvollständige Suchergebnisse während der Indizierung.
Die Indizierung sollte nicht ohne bestätigte Ursache dauerhaft deaktiviert werden. Zuerst ist zu prüfen, ob es sich um eine vorübergehende und erwartete Aktivität handelt.
---
**22. Zeit und Synchronisation**
Eine falsche Systemzeit kann unter anderem verursachen:
- TLS- und Zertifikatsfehler,
- Anmeldeprobleme,
- Kerberos-Fehler,
- unpassende Protokollzeitpunkte,
- Probleme mit MDM oder Cloudservices,
- fehlerhafte Zeitstempel.
**Zeit anzeigen**
```bash
date
```
**Konfiguration des Zeitservers**
```bash
sudo systemsetup -getnetworktimeserver
```
**Netzwerkzeitstatus**
```bash
sudo systemsetup -getusingnetworktime
```
**Zeitzone**
```bash
sudo systemsetup -gettimezone
```
Bei der Protokollauswertung müssen lokale Zeit, UTC, Zeitzone und Sommerzeit berücksichtigt werden.
---
**23. MDM und Konfigurationsprofile**
**Registrierungsstatus**
```bash
profiles status -type enrollment
```
**Konfigurationsprofile anzeigen**
```bash
sudo profiles show -type configuration
```
Verfügbarkeit, Umfang und erforderliche Rechte können von der macOS-Version und Geräteverwaltung abhängen.
**Profile können beeinflussen**
- WLAN,
- VPN,
- Zertifikate,
- Proxys,
- Datenschutzfreigaben,
- Systemerweiterungen,
- Sicherheitsrichtlinien,
- Softwareupdates,
- Passwörter,
- FileVault,
- Anmeldeobjekte.
> Eine Einstellung kann in der grafischen Oberfläche unveränderbar erscheinen, weil sie durch ein Profil oder MDM vorgegeben wird. Das ist nicht automatisch ein Bedienungs- oder Dateirechtefehler.
---
**24. Sicherer Modus**
Der sichere Modus kann helfen zu bestimmen, ob eine Störung mit Software zusammenhängt, die während des regulären Starts geladen wird.
**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** wählen.
**Intel-basierter Mac**
1. Mac einschalten oder neu starten.
2. sofort die Umschalttaste gedrückt halten.
3. Taste beim Anmeldefenster loslassen.
4. anmelden; gegebenenfalls ist eine zweite Anmeldung erforderlich.
**Diagnostische Aussage**
| Ergebnis | Einordnung |
|---|---|
| Fehler tritt im sicheren Modus nicht auf | Hinweis auf einen Unterschied bei geladenen Komponenten, Caches oder Startobjekten |
| Fehler tritt weiterhin auf | Drittanbieter-Startkomponenten werden weniger wahrscheinlich, aber nicht vollständig ausgeschlossen |
| System startet nur im sicheren Modus | Startobjekte, Erweiterungen, Dateisystem oder Softwarekonflikte gezielt prüfen |
> Der sichere Modus ist ein Eingrenzungstest. Er identifiziert nicht automatisch die fehlerhafte Komponente.
---
**25. Apple Diagnose**
Apple Diagnose prüft bestimmte interne Hardwarekomponenten des Mac.
Apple weist ausdrücklich darauf hin, dass damit nicht geprüft werden:
- externe Hardwarekomponenten,
- macOS-Probleme,
- Konflikte mit Anwendungen,
- Konflikte mit Erweiterungen.
**Vorbereitung**
1. Mac ausschalten.
2. nicht benötigte externe Geräte trennen.
3. Tastatur, Maus, Display, Ethernet und Stromversorgung dürfen angeschlossen bleiben.
4. Mac auf eine feste und gut belüftete Fläche stellen.
5. Internetverbindung bereithalten, falls erforderlich.
**Mac mit Apple-Chip**
1. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
2. Ein-/Ausschalter loslassen.
3. `Command-D` gedrückt halten, um Apple Diagnose zu starten.
**Intel-basierter Mac**
1. Mac einschalten.
2. sofort die Taste `D` gedrückt halten.
3. Taste loslassen, wenn ein Fortschrittsbalken oder die Sprachauswahl erscheint.
**Ergebnis dokumentieren**
- Referenzcode,
- genaue Fehlermeldung,
- Datum und Uhrzeit,
- angeschlossene Geräte,
- macOS-Version,
- reproduzierbares Symptom.
> Ein Ergebnis „keine Probleme gefunden“ schließt nicht alle Hardwarefehler aus. Sporadische, temperaturabhängige oder externe Fehler können unentdeckt bleiben.
---
**26. macOS-Wiederherstellung**
Die macOS-Wiederherstellung stellt eine vom normalen System getrennte Umgebung bereit.
**Typische Funktionen**
- Festplattendienstprogramm,
- macOS neu installieren,
- Startvolume auswählen,
- Wiederherstellungsprotokoll anzeigen,
- Terminal öffnen,
- Safari beziehungsweise Onlinehilfe,
- Diagnosedatei erstellen,
- Backup wiederherstellen.
**Mac mit Apple-Chip starten**
1. Mac vollständig ausschalten.
2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
3. **Optionen** wählen.
4. **Fortfahren** wählen.
**Intel-basierter Mac starten**
Beim Einschalten sofort eine passende Tastenkombination gedrückt halten:
| Kombination | Zweck |
|---|---|
| `Command-R` | integrierte macOS-Wiederherstellung |
| `Option-Command-R` | Internet-Wiederherstellung mit einer kompatiblen aktuellen macOS-Version |
| `Shift-Option-Command-R` | je nach Mac ursprüngliche oder nächstverfügbare Version über Internet-Wiederherstellung |
Die tatsächlich angebotene Version kann vom Mac-Modell und der Verfügbarkeit abhängen.
**Wiederherstellungsprotokoll**
In der Wiederherstellung:
**Fenster → Wiederherstellungsprotokoll**
Das Protokoll kann gefiltert und in einer Datei gesichert werden.
**Diagnostischer Nutzen**
- Startvolume außerhalb des laufenden Systems prüfen,
- unterscheiden, ob ein Fehler nur im installierten System auftritt,
- Dateisystem untersuchen,
- Wiederherstellungsprotokolle sichern,
- Startprobleme analysieren.
> Eine Neuinstallation sollte nicht der erste Diagnoseschritt sein. Sie kann den fehlerhaften Zustand verändern und beseitigt keine externen Hardware-, Netzwerk-, Benutzerprofil- oder Konfigurationsursachen.
---
**27. USB-, Thunderbolt- und externe Geräte**
**USB-Geräte**
```bash
system_profiler SPUSBDataType
```
**Thunderbolt- beziehungsweise USB4-Geräte**
```bash
system_profiler SPThunderboltDataType
```
**Speichergeräte**
```bash
diskutil list
```
**Offene Verbindungen während des Einsteckens beobachten**
```bash
log stream --style compact
```
Anschließend kann nach passenden Prozessen, Subsystemen oder Meldungstexten gefiltert werden.
**Kreuztests**
- anderer Anschluss,
- anderes Kabel,
- ohne Hub oder Dock,
- anderes Netzteil,
- anderes Benutzerkonto,
- anderer Mac,
- Gerät direkt statt über Adapter,
- bekannte funktionierende Gegenprobe.
**Eingrenzung**
| Beobachtung | mögliche Ebene |
|---|---|
| Gerät fehlt in Systeminformationen | Kabel, Anschluss, Stromversorgung, Hardware |
| Gerät erscheint, aber nicht in der Anwendung | Anwendung, Berechtigung, Treiber, Modus |
| Datenträger erscheint in `diskutil`, aber nicht im Finder | Volume, Aktivierung, Finder-Einstellung, Dateisystem |
| Gerät funktioniert direkt, aber nicht am Hub | Hub, Stromversorgung, Kabel, Kompatibilität |
| Gerät funktioniert nur an einem Benutzerkonto | benutzerspezifische Einstellung oder Berechtigung |
---
**28. Bluetooth untersuchen**
**Systembericht**
```bash
system_profiler SPBluetoothDataType
```
**Zu prüfen**
- wird der Bluetooth-Controller erkannt?
- wird das Gerät erkannt?
- ist das Gerät verbunden oder nur gekoppelt?
- besteht eine Verbindung zu einem anderen Host?
- ist der Akku des Geräts ausreichend geladen?
- tritt die Störung bei mehreren Geräten auf?
- beeinflussen USB-3-Geräte oder Funkstörungen die Verbindung?
- existieren herstellerspezifische Anwendungen oder Erweiterungen?
Das Löschen sämtlicher Kopplungen oder Einstellungsdateien ist keine geeignete Erstmaßnahme. Zuerst sollten Zustand und Umfang dokumentiert werden.
---
**29. Druckerdiagnose**
**Konfigurierte Drucker**
```bash
lpstat -p -d
```
**Druckerstatus**
```bash
lpstat -t
```
**Druckaufträge**
```bash
lpstat -o
```
**CUPS-Weboberfläche**
Auf aktuellen Systemen kann die Weboberfläche deaktiviert sein. Ihr Status und die organisatorischen Sicherheitsvorgaben müssen vor einer Aktivierung geprüft werden.
**Typische Prüfreihenfolge**
1. Wird der Drucker lokal beziehungsweise im Netzwerk erreicht?
2. ist die richtige Warteschlange ausgewählt?
3. hängt ein Auftrag in der Warteschlange?
4. stimmt Treiber beziehungsweise verwendetes Druckprotokoll?
5. funktioniert Namensauflösung?
6. ist der Drucker über IPP, AirPrint oder einen Printserver eingebunden?
7. bestehen Authentifizierungs- oder Berechtigungsfehler?
8. tritt der Fehler bei anderen Benutzern auf?
---
**30. Systemdiagnose sammeln**
macOS kann ein umfangreiches Diagnosetaket erzeugen:
```bash
sudo sysdiagnose
```
Der Vorgang kann mehrere Minuten dauern. Speicherort und Abschlussmeldung müssen der Terminalausgabe entnommen werden.
Ein `sysdiagnose` kann unter anderem enthalten:
- Systemzustand,
- Prozessinformationen,
- Protokolle,
- Netzwerkzustand,
- Speicherinformationen,
- Energieinformationen,
- Konfigurationsdaten,
- Absturz- und Diagnoseberichte.
**Vor dem Einsatz beachten**
- hoher Umfang,
- möglicher zusätzlicher Ressourcenverbrauch,
- sensible oder personenbezogene Informationen,
- sichere Speicherung,
- verschlüsselte Übertragung,
- begrenzter Empfängerkreis,
- definierte Aufbewahrungsdauer,
- kontrollierte Löschung nach Abschluss.
`sysdiagnose` ist kein Ersatz für eine gezielte Hypothese. Es ist besonders sinnvoll, wenn:
- der Fehler schwer reproduzierbar ist,
- mehrere Komponenten beteiligt sein könnten,
- Apple oder ein Hersteller umfangreiche Diagnosedaten anfordert,
- der aktuelle Systemzustand vor einer Veränderung gesichert werden muss.
---
**31. Werkzeugwahl nach Symptom**
| Symptom | erste geeignete Werkzeuge |
|---|---|
| Mac ist allgemein langsam | Aktivitätsanzeige, `top`, `vm_stat`, `memory_pressure`, `iostat`, Speicherplatzprüfung |
| Anwendung reagiert nicht | Aktivitätsanzeige, `sample`, Konsole, Diagnoseberichte |
| Anwendung stürzt ab | Konsole, DiagnosticReports, `codesign`, Versions- und Erweiterungsprüfung |
| kein Internetzugriff | `networksetup`, `ifconfig`, `route`, `scutil --dns`, `ping`, `dig`, `nc`, `curl` |
| WLAN instabil | Option-WLAN-Menü, Diagnose für drahtlose Umgebungen, Kreuztest mit Ethernet |
| Port nicht erreichbar | `nc`, `lsof`, `curl`, `tcpdump` |
| Datenträger fehlt | Systeminformationen, `diskutil list`, Festplattendienstprogramm |
| Volume fast voll | `df`, `du`, Festplattendienstprogramm |
| Datei kann nicht geöffnet werden | `ls -leO@`, `xattr`, `stat`, TCC-, Signatur- und Eigentümerprüfung |
| Hintergrunddienst startet nicht | `launchctl print`, `plutil`, Unified Log |
| hoher Energieverbrauch | Aktivitätsanzeige, `pmset`, `system_profiler SPPowerDataType` |
| USB-Gerät funktioniert nicht | Systeminformationen, USB-/Thunderbolt-Bericht, Kabel- und Direktanschlusstest |
| Startproblem | sicherer Modus, Apple Diagnose, macOS-Wiederherstellung, Festplattendienstprogramm |
| Problem nur bei einem Benutzer | neues Testkonto, benutzerspezifische Agenten, Einstellungen und TCC |
| Problem nach Softwareinstallation | Login-Objekte, Systemerweiterungen, `pkgutil`, `codesign`, Protokolle |
---
**32. Praxisbeispiel: Eine Anwendung startet nicht**
**Symptom**
Eine Anwendung beendet sich unmittelbar nach dem Start.
**Sichere Untersuchung**
1. genaue Anwendungsversion erfassen,
2. macOS-Version und Build erfassen,
3. Zeitpunkt des Startversuchs notieren,
4. prüfen, ob andere Benutzer betroffen sind,
5. Anwendung aus dem Terminal oder Finder starten,
6. Live-Protokollierung auf den Prozess filtern,
7. Absturzbericht sichern,
8. Signatur und Gatekeeper-Bewertung prüfen,
9. geladene Erweiterungen und Plug-ins berücksichtigen,
10. erst danach Konfigurationen verändern.
**Beispielbefehle**
```bash
sw_vers
```
```bash
codesign --verify --deep --strict --verbose=2 "/Applications/Beispiel.app"
```
```bash
spctl --assess --type execute --verbose=4 "/Applications/Beispiel.app"
```
```bash
log stream --style compact --predicate 'process == "Beispiel"'
```
```bash
ls -lt ~/Library/Logs/DiagnosticReports/
```
**Mögliche Hypothesen**
- beschädigte oder unvollständige Anwendung,
- inkompatible Version,
- ungültige Signatur,
- fehlende Berechtigung,
- inkompatibles Plug-in,
- beschädigte benutzerspezifische Konfiguration,
- nicht erreichbarer abhängiger Dienst,
- Architektur- oder Rosetta-Konflikt.
Das sofortige Löschen aller Einstellungsdateien würde den Beweiszustand verändern und kann benutzerspezifische Daten vernichten.
---
**33. Praxisbeispiel: Netzwerk funktioniert im Browser nicht**
**Symptom**
Webseiten werden nicht geladen.
**Schrittweise Eingrenzung**
```bash
networksetup -listallhardwareports
```
```bash
ifconfig
```
```bash
route -n get default
```
```bash
ping -c 4 192.168.1.1
```
```bash
scutil --dns
```
```bash
dig example.com
```
```bash
nc -vz example.com 443
```
```bash
curl -v https://example.com/
```
```bash
scutil --proxy
```
**Bewertung**
| Ergebnis | nächste Eingrenzung |
|---|---|
| keine IP-Adresse | Link, WLAN, DHCP |
| IP vorhanden, keine Standardroute | Netzwerkkonfiguration, DHCP, VPN |
| Gateway nicht erreichbar | lokales Netz, VLAN, WLAN, Router |
| IP-Ziel erreichbar, DNS fehlschlägt | Resolver, DNS-Server, VPN, Filter |
| DNS funktioniert, Port 443 fehlschlägt | Firewall, Route, Proxy, Zielservice |
| `curl` funktioniert, Browser nicht | Browserprofil, Erweiterung, Proxy, Zertifikat, TCC |
| Problem nur mit VPN | VPN-Route, DNS, Netzwerkerweiterung, Richtlinie |
---
**34. Praxisbeispiel: Mac ist plötzlich sehr langsam**
**Zuerst sichern**
```bash
date
```
```bash
uptime
```
```bash
top -l 1 -o cpu
```
```bash
memory_pressure
```
```bash
sysctl vm.swapusage
```
```bash
df -h /
```
```bash
iostat -w 1
```
**Danach prüfen**
- begann die Störung nach Anmeldung, Update oder Anschluss eines Geräts?
- ist ein einzelner Prozess auffällig?
- ist der Speicherdruck erhöht?
- besteht starke Swap- oder Datenträgeraktivität?
- ist das Startvolume fast voll?
- läuft Spotlight-Indizierung?
- findet eine Cloud- oder Backup-Synchronisation statt?
- existieren wiederholte Abstürze oder Neustarts von Diensten?
- tritt die Störung in einem anderen Benutzerkonto auf?
- tritt sie im sicheren Modus auf?
> Das Beenden des Prozesses mit der höchsten CPU-Auslastung ist keine vollständige Ursachenanalyse. Der Prozess kann eine notwendige Folgearbeit ausführen oder nur auf eine andere Störung reagieren.
---
**35. Typische Fehlinterpretationen**
| Aussage | fachliche Einordnung |
|---|---|
| „Der Arbeitsspeicher ist fast vollständig belegt.“ | macOS nutzt Speicher bewusst für Anwendungen und Caches. Speicherdruck und Swap sind aussagekräftiger. |
| „`sudo` müsste auf alles zugreifen können.“ | TCC und SIP können den Zugriff trotz Root-Rechten begrenzen. |
| „Der Prozess hat die höchste CPU-Auslastung und ist daher defekt.“ | Hohe Auslastung kann zur erwarteten Arbeit gehören. |
| „Apple Diagnose meldet keinen Fehler, also ist die Hardware sicher fehlerfrei.“ | Nicht alle Hardwarefehler und keine externen Komponenten werden vollständig geprüft. |
| „WLAN ist verbunden, deshalb muss Internet funktionieren.“ | WLAN-Verbindung, IP-Konfiguration, Routing, DNS und Internetdienst sind unterschiedliche Ebenen. |
| „Erste Hilfe repariert auch eine defekte SSD.“ | Das Werkzeug prüft beziehungsweise repariert Dateisystemstrukturen, nicht verschlissene Hardware. |
| „Im Protokoll steht `error`; das ist die Ursache.“ | Die Meldung kann erwartet, unabhängig oder eine Folge des eigentlichen Fehlers sein. |
| „Eine gültige Codesignatur beweist, dass die Anwendung funktioniert.“ | Sie bestätigt nicht die fehlerfreie Funktion oder Kompatibilität. |
| „Der sichere Modus behebt die Ursache.“ | Er dient vor allem als Vergleichs- und Eingrenzungstest. |
| „Das Gerät erscheint im Systembericht und funktioniert deshalb vollständig.“ | Erkennung, Treiber, Berechtigung und Anwendungsfunktion müssen getrennt geprüft werden. |
| „Ein Neustart hat geholfen, also ist die Ursache beseitigt.“ | Der Neustart kann nur flüchtigen Zustand zurückgesetzt haben. |
| „`ping` schlägt fehl, daher ist der Server offline.“ | ICMP kann blockiert sein, obwohl der eigentliche Dienst erreichbar ist. |
| „Das Löschen aller Einstellungen ist die schnellste Lösung.“ | Dadurch können Beweise und Benutzerdaten verloren gehen, ohne die Ursache zu bestätigen. |
---
**36. Checkliste macOS-Fehleranalyse**
- [ ] Störung und erwartetes Verhalten sind exakt beschrieben.
- [ ] Zeitpunkt und letzte Änderungen sind bekannt.
- [ ] macOS-Version und Build wurden erfasst.
- [ ] Mac-Modell und Prozessorarchitektur wurden erfasst.
- [ ] betroffene Benutzer und Anwendungen sind bekannt.
- [ ] Umfang und Auswirkung wurden bestimmt.
- [ ] wichtige flüchtige Informationen wurden gesichert.
- [ ] Prozess- und Ressourcenzustand wurden geprüft.
- [ ] Speicherplatz und Datenträgerzustand wurden geprüft.
- [ ] relevante Netzwerkebenen wurden getrennt getestet.
- [ ] Unified Logs wurden zeitlich passend ausgewertet.
- [ ] Absturz- oder Diagnoseberichte wurden gesichert.
- [ ] TCC, SIP, Gatekeeper und MDM wurden berücksichtigt.
- [ ] Dienste und Startobjekte wurden nicht unkontrolliert entfernt.
- [ ] Befehle mit `sudo` wurden vor der Ausführung verstanden.
- [ ] Paketmitschnitte und Diagnosedateien werden geschützt.
- [ ] Apple-Chip und Intel-Verfahren wurden unterschieden.
- [ ] sicherer Modus wurde nur als Eingrenzungstest bewertet.
- [ ] Apple Diagnose wurde nicht als vollständiger Softwaretest interpretiert.
- [ ] Änderungen wurden einzeln und reversibel durchgeführt.
- [ ] Funktion wurde nach der Maßnahme überprüft.
- [ ] Ursache und nicht nur das Symptom wurde bestätigt.
- [ ] Ergebnisse und Rückfallmöglichkeiten wurden dokumentiert.
---
**37. Schnellreferenz**
| Aufgabe | Werkzeug oder Befehl |
|---|---|
| macOS-Version | `sw_vers` |
| Architektur | `uname -m` |
| Hardwareübersicht | `system_profiler SPHardwareDataType` |
| Prozessliste | `ps aux` |
| Prozess suchen | `pgrep -afil "Name"` |
| CPU-Auslastung | `top -l 1 -o cpu` |
| Speicherdruck | `memory_pressure` |
| Speicherseiten | `vm_stat` |
| Swap | `sysctl vm.swapusage` |
| Datenträgerstruktur | `diskutil list` |
| APFS-Struktur | `diskutil apfs list` |
| Dateisystembelegung | `df -h` |
| Verzeichnisgröße | `du -sh Pfad` |
| offene Dateien | `lsof` |
| Listener | `lsof -nP -iTCP -sTCP:LISTEN` |
| Netzwerkadapter | `networksetup -listallhardwareports` |
| Schnittstellen | `ifconfig` |
| Standardroute | `route -n get default` |
| Routingtabelle | `netstat -rn` |
| DNS-Zustand | `scutil --dns` |
| Proxy-Zustand | `scutil --proxy` |
| DNS-Abfrage | `dig example.com` |
| Porttest | `nc -vz host port` |
| HTTP-/TLS-Test | `curl -v URL` |
| Paketmitschnitt | `sudo tcpdump -nn -i Schnittstelle` |
| Protokollhistorie | `log show` |
| Live-Protokoll | `log stream` |
| Dienst untersuchen | `launchctl print` |
| PLIST prüfen | `plutil -lint Datei.plist` |
| Dateirechte und Attribute | `ls -leO@ Pfad` |
| Signatur prüfen | `codesign --verify` |
| Gatekeeper prüfen | `spctl --assess` |
| Systemerweiterungen | `systemextensionsctl list` |
| Energiezustand | `pmset -g` |
| Ruhezustandsblocker | `pmset -g assertions` |
| MDM-Status | `profiles status -type enrollment` |
| umfangreiche Diagnose | `sudo sysdiagnose` |
---
**Merksatz**
> macOS-Fehleranalyse bedeutet nicht, wahllos Einstellungen zurückzusetzen oder Schutzmechanismen zu umgehen. Zuerst werden Systemzustand, Prozesse, Ressourcen, Protokolle, Netzwerk, Datenträger und Berechtigungen getrennt untersucht. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme geprüft.
---
**Quellen und weiterführende Dokumentation**
- [Apple – Aktivitätsanzeige: Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac)
- [Apple – Mac-Prozesse in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1001/mac)
- [Apple – Speichernutzung in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1004/mac)
- [Apple – CPU-Aktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr43452/mac)
- [Apple – Festplattenaktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1005/mac)
- [Apple – Netzwerkaktivität in der Aktivitätsanzeige](https://support.apple.com/de-de/guide/activity-monitor/actmntr1006/mac)
- [Apple – Diagnose für drahtlose Umgebungen](https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac)
- [Apple – Details zur WLAN-Verbindung anzeigen](https://support.apple.com/de-de/guide/mac-help/mchlfad426fa/mac)
- [Apple – Festplattendienstprogramm: Benutzerhandbuch](https://support.apple.com/de-de/guide/disk-utility/welcome/mac)
- [Apple – Speichermedium mit „Erste Hilfe“ reparieren](https://support.apple.com/de-de/guide/disk-utility/dskutl1040/mac)
- [Apple – Alle Geräte im Festplattendienstprogramm einblenden](https://support.apple.com/de-de/guide/disk-utility/dskud6b39edb/mac)
- [Apple – Detailinformationen zu Datenträgern anzeigen](https://support.apple.com/de-de/guide/disk-utility/dskutl1005/mac)
- [Apple – Mac im sicheren Modus starten](https://support.apple.com/de-de/guide/mac-help/mh21245/mac)
- [Apple – Probleme mit Apple Diagnose untersuchen](https://support.apple.com/de-de/guide/mac-help/mh35727/mac)
- [Apple – macOS-Wiederherstellung auf einem Mac mit Apple-Chip](https://support.apple.com/de-de/guide/mac-help/mchl82829c17/mac)
- [Apple – macOS-Wiederherstellung auf einem Intel-basierten Mac](https://support.apple.com/de-de/guide/mac-help/mchl338cf9a8/mac)
- [Apple – Tastenkombinationen beim Startvorgang](https://support.apple.com/de-de/102603)
- [Apple Platform Security – Startmodi eines Mac mit Apple-Chip](https://support.apple.com/de-de/guide/security/sec10869885b/web)
# 5.6 Netzwerkgeräte – Werkzeuge zur Fehleranalyse
Netzwerkgeräte wie Switches, Router, Firewalls, WLAN-Access-Points, Controller, Load Balancer und VPN-Gateways verfügen meist über eigene Diagnosefunktionen. Dazu gehören:
- Kommandozeilenbefehle,
- Weboberflächen,
- Ereignisprotokolle,
- Schnittstellenstatistiken,
- Routing- und Switchingtabellen,
- Paketmitschnitte,
- SNMP-Messwerte,
- Telemetriedaten,
- zentrale Netzwerkmanagementsysteme,
- herstellerspezifische Supportdateien.
> Die genaue Syntax hängt von Hersteller, Produktfamilie, Betriebssystem und Softwareversion ab. Ein Befehl darf deshalb nicht ungeprüft auf ein anderes Gerät übertragen werden.
---
**1. Grundregeln für die Untersuchung**
Vor jedem Zugriff müssen geklärt werden:
- betroffenes Gerät,
- Hersteller und Modell,
- Betriebssystem und Version,
- Rolle des Geräts,
- Managementadresse,
- vorgesehener Zugriffsweg,
- benötigte Berechtigungen,
- Wartungs- und Änderungsvorgaben,
- vorhandene Redundanz,
- Auswirkungen eines möglichen Ausfalls.
**Zuerst nur lesend untersuchen**
Geeignet sind zunächst:
- Statusbefehle,
- Protokollabfragen,
- Zählerstände,
- Routingtabellen,
- Nachbartabellen,
- Konfigurationsansichten,
- Paketmitschnitte mit begrenztem Umfang.
Zu vermeiden sind ohne bestätigte Ursache und Freigabe:
- Neustarts,
- Zurücksetzen von Schnittstellen,
- Löschen von Tabellen,
- Leeren von Sitzungen,
- Änderungen an VLANs oder Routen,
- Deaktivieren von Sicherheitsregeln,
- Zurücksetzen von Zählern,
- Firmwareupdates,
- Werkseinstellungen,
- dauerhafte Debug-Ausgaben.
> Eine reine Statusabfrage ist nicht auf jedem Gerät vollständig risikofrei. Umfangreiche Support- oder Diagnosebefehle können CPU, Arbeitsspeicher, Konsole oder Managementverbindung belasten.
---
**2. Systematisch von unten nach oben prüfen**
| Ebene | typische Fragestellung |
|---|---|
| Stromversorgung | Ist das Gerät eingeschaltet und ausreichend versorgt? |
| Hardware | Sind Module, Netzteile, Lüfter und Temperatursensoren fehlerfrei? |
| physische Verbindung | Besteht Link? Stimmen Medium, Kabel, Transceiver und Geschwindigkeit? |
| Sicherungsschicht | Stimmen VLAN, Trunk, STP, LACP und MAC-Lernen? |
| Netzwerkschicht | Stimmen IP-Adresse, Präfix, ARP/ND und Routing? |
| Transport | Ist der benötigte TCP- oder UDP-Port erreichbar? |
| Sicherheit | Blockieren ACL, Firewall, NAC oder VPN-Richtlinien? |
| Anwendung | Funktionieren DNS, DHCP, RADIUS, NTP oder andere Dienste? |
| Management | Erreichen Monitoring, Syslog, SNMP und zentrale Verwaltung das Gerät? |
Ein Fehler sollte möglichst auf die kleinste betroffene Ebene eingegrenzt werden.
---
**3. Zustand vor Veränderungen sichern**
Vor einer Änderung sollten mindestens dokumentiert werden:
- Datum und Uhrzeit,
- Gerätename,
- Seriennummer,
- Modell,
- Softwareversion,
- Laufzeit seit dem letzten Neustart,
- aktuelle Konfiguration,
- gespeicherte Konfiguration,
- Schnittstellenstatus,
- Routingtabelle,
- Nachbartabellen,
- Protokolle,
- CPU- und Speicherauslastung,
- Redundanzstatus,
- betroffene Benutzer oder Standorte,
- zuletzt vorgenommene Änderungen.
**Typische Beweissicherung**
```text
Gerät:
Standort:
Hersteller und Modell:
Betriebssystem und Version:
Managementadresse:
Zeitpunkt:
Symptom:
betroffene Schnittstelle:
betroffenes VLAN beziehungsweise VRF:
Quelladresse:
Zieladresse:
Zielport und Protokoll:
letzte Änderung:
gesicherte Ausgaben:
durchgeführte Tests:
Ergebnis:
```
---
**4. Managementzugriff prüfen**
Typische Zugriffswege sind:
- lokale Konsole,
- serielle Konsole,
- dedizierter Managementport,
- SSH,
- HTTPS,
- Out-of-Band-Management,
- zentrale Managementplattform,
- API,
- NETCONF oder RESTCONF.
**Sicherheitsregeln**
- Telnet nur verwenden, wenn es in einer isolierten Altumgebung ausdrücklich vorgeschrieben ist.
- SSH und HTTPS bevorzugen.
- Administrationszugriffe protokollieren.
- Nur persönliche oder nachvollziehbar zugeordnete Konten verwenden.
- Keine Kennwörter in Tickets, Protokollen oder Bildschirmfotos veröffentlichen.
- Managementzugriff möglichst über ein getrenntes Managementnetz führen.
- Änderungen nach dem Vier-Augen- oder Freigabeverfahren des Unternehmens durchführen.
**Bei fehlendem Zugriff unterscheiden**
| Beobachtung | mögliche Ursache |
|---|---|
| Gerät antwortet nicht auf Ping | ICMP gefiltert, falsche Route, Gerät ausgefallen oder Managementadresse falsch |
| Ping funktioniert, SSH nicht | Dienst deaktiviert, ACL, falscher Port, Überlastung oder Authentifizierungsproblem |
| SSH-Verbindung startet, Anmeldung schlägt fehl | lokales Konto, RADIUS, TACACS+, Zertifikat oder Berechtigung |
| Zugriff nur über Konsole möglich | Managementnetz, Routing, VRF, ACL oder Managementdienst |
| zentrale Verwaltung zeigt Gerät offline | Managementpfad, Zertifikat, Zeit, DNS, Tunnel oder Controllerverbindung |
| Zugriff funktioniert nur von einem Netz | Routing, Firewall, Management-ACL oder VRF |
---
**5. Geräteidentität und Softwarestand**
Zu erfassen sind:
- Gerätename,
- Modell,
- Seriennummer,
- Hardwaremodule,
- Betriebssystem,
- Softwareversion,
- Bootimage,
- Lizenzstatus,
- Laufzeit,
- Grund des letzten Neustarts,
- unterstützte und eingesetzte Transceiver.
**Cisco IOS beziehungsweise IOS XE**
```text
show version
```
```text
show inventory
```
```text
show license summary
```
**Juniper Junos**
```text
show version
```
```text
show chassis hardware
```
```text
show system uptime
```
**Aruba AOS-CX**
```text
show version
```
```text
show system
```
```text
show inventory
```
Die verfügbaren Befehle können je nach Plattform und Version abweichen.
---
**6. CPU, Arbeitsspeicher und Systemzustand**
Hohe Auslastung kann dazu führen, dass:
- Routingprotokolle Nachbarschaften verlieren,
- Managementzugriffe verzögert werden,
- Pakete verworfen werden,
- Protokolle unvollständig erscheinen,
- Kontrollprozesse neu starten,
- Überwachungsabfragen fehlschlagen.
**Cisco IOS beziehungsweise IOS XE**
```text
show processes cpu
```
```text
show processes memory
```
```text
show platform resources
```
**Juniper Junos**
```text
show chassis routing-engine
```
```text
show system processes extensive
```
```text
show system memory
```
**Aruba AOS-CX**
```text
show system resource-utilization
```
```text
top cpu
```
```text
top memory
```
**Bei Auffälligkeiten prüfen**
- Ist die Auslastung dauerhaft oder nur kurzfristig erhöht?
- Welcher Prozess ist betroffen?
- Begann die Auslastung nach einer Änderung?
- Bestehen ungewöhnlich viele Verbindungen oder Routingupdates?
- Läuft eine umfangreiche Protokollierung oder Diagnose?
- Findet ein Angriff oder Netzwerkscan statt?
- Besteht ein Layer-2-Loop?
- Sind Tabellen oder Sitzungsspeicher ausgelastet?
- Werden Pakete in Software statt in Hardware verarbeitet?
> Ein Prozess mit hoher CPU-Auslastung ist nicht automatisch die Ursache. Er kann auf einen Broadcast-Sturm, eine Routinginstabilität oder eine andere Störung reagieren.
---
**7. Hardware, Temperatur und Stromversorgung**
Zu prüfen sind:
- Netzteile,
- Lüfter,
- Temperatur,
- Spannungswerte,
- Module,
- Linecards,
- Stack-Mitglieder,
- Chassiszustand,
- PoE-Budget,
- Hardwarefehler,
- Redundanz.
**Cisco IOS beziehungsweise IOS XE**
```text
show environment
```
```text
show platform
```
```text
show power
```
```text
show power inline
```
Nicht jeder Befehl ist auf jeder Cisco-Plattform vorhanden.
**Juniper Junos**
```text
show chassis environment
```
```text
show chassis alarms
```
```text
show system alarms
```
```text
show poe controller
```
**Aruba AOS-CX**
```text
show environment
```
```text
show system power-supply
```
```text
show system fans
```
```text
show poe brief
```
**Typische Warnsignale**
- fehlendes Netzteil,
- ausgefallener Lüfter,
- erhöhte Temperatur,
- überlastetes PoE-Budget,
- nicht erkanntes Modul,
- Hardwarealarm,
- wiederholter Modulneustart,
- unterschiedliche Firmwarestände innerhalb eines Stacks.
---
**8. Schnittstellenstatus untersuchen**
Für jede betroffene Schnittstelle sind mindestens zu prüfen:
- administrativer Zustand,
- operativer Zustand,
- Geschwindigkeit,
- Duplexmodus,
- MTU,
- Medium,
- VLAN-Zuordnung,
- Beschreibung,
- Ein- und Ausgangsrate,
- Fehlerzähler,
- Drops,
- Linkwechsel,
- Transceiverwerte.
**Cisco IOS beziehungsweise IOS XE**
Übersicht:
```text
show interfaces status
```
IP-bezogene Übersicht:
```text
show ip interface brief
```
Details einer Schnittstelle:
```text
show interfaces GigabitEthernet1/0/1
```
Beschreibungen:
```text
show interfaces description
```
Fehlerübersicht auf unterstützten Switches:
```text
show interfaces counters errors
```
**Juniper Junos**
Übersicht:
```text
show interfaces terse
```
Details:
```text
show interfaces ge-0/0/1 extensive
```
Beschreibung und Status:
```text
show interfaces descriptions
```
**Aruba AOS-CX**
```text
show interface brief
```
```text
show interface 1/1/1
```
```text
show interface 1/1/1 statistics
```
**Status fachlich einordnen**
| Zustand | mögliche Bedeutung |
|---|---|
| administrativ deaktiviert | Schnittstelle wurde durch Konfiguration abgeschaltet |
| physisch down | kein Link, Kabel-, Transceiver-, Gegenstellen- oder Stromproblem |
| physisch up, Protokoll down | Problem oberhalb der reinen Signalerkennung |
| häufige Linkwechsel | Kabel, Stecker, Transceiver, Stromversorgung oder Autonegotiation |
| viele Eingangsfehler | Medium, Signal, Überlastung oder fehlerhafte Hardware |
| viele Ausgangsdrops | Ausgangswarteschlange überlastet oder Zielverbindung langsamer |
| Zähler steigen nicht | möglicherweise falsche Schnittstelle oder kein Verkehr |
| Link up | bestätigt nur die Verbindung auf der entsprechenden Ebene |
---
**9. Fehlerzähler bewerten**
Typische Zähler sind:
- CRC-Fehler,
- Framefehler,
- Alignment Errors,
- Runts,
- Giants,
- Input Errors,
- Output Errors,
- Discards,
- Queue Drops,
- Collisions,
- Late Collisions,
- Overruns,
- Carrier Transitions,
- Pause Frames.
**Mögliche Einordnung**
| Zähler | mögliche Ursache |
|---|---|
| CRC-Fehler | Kabel, Steckverbindung, Transceiver, elektromagnetische Störung oder Gegenstelle |
| Late Collisions | Duplexproblem oder ungeeignete gemeinsame Medienumgebung |
| Input Drops | Eingangspuffer oder Verarbeitung überlastet |
| Output Drops | Ausgangsschnittstelle oder Warteschlange überlastet |
| Giants | zu große Frames, MTU-Abweichung oder fehlerhafte Frames |
| Runts | beschädigte oder zu kurze Ethernetframes |
| viele Linkwechsel | instabile physische Verbindung oder Energieversorgung |
**Für eine korrekte Bewertung**
1. aktuellen Zählerstand dokumentieren,
2. Laufzeit des Geräts berücksichtigen,
3. Datenverkehr beobachten,
4. Veränderung des Zählers messen,
5. Gegenstelle prüfen,
6. Kabel beziehungsweise Transceiver kontrolliert gegenprüfen,
7. Fehler nicht allein anhand eines historischen Gesamtwerts bewerten.
> Ein hoher Zählerstand kann über Monate entstanden sein. Entscheidend ist häufig, ob der Wert während des aktuellen Fehlers weiter steigt.
---
**10. Geschwindigkeit, Duplex und Autonegotiation**
Typische Probleme entstehen durch:
- eine Seite automatisch und die andere fest konfiguriert,
- unterschiedliche feste Geschwindigkeiten,
- ungeeignete Transceiver,
- nicht unterstützte Kabel,
- Energiesparfunktionen,
- fehlerhafte Autonegotiation,
- unterschiedliche FEC-Einstellungen bei schnellen Verbindungen.
Zu vergleichen sind immer beide Seiten der Verbindung.
**Prüffragen**
- Welche Geschwindigkeit wurde tatsächlich ausgehandelt?
- Welcher Duplexmodus ist aktiv?
- Ist Autonegotiation auf beiden Seiten gleich behandelt?
- Werden Fehlerzähler größer?
- Passt der Transceiver zum Port und zur Gegenstelle?
- Stimmen Wellenlänge, Fasertyp und Reichweite?
- Ist bei höheren Geschwindigkeiten die benötigte Forward Error Correction aktiv?
---
**11. Transceiver und Glasfaserdiagnose**
Diagnoseinformationen können enthalten:
- Hersteller,
- Teilenummer,
- Seriennummer,
- Wellenlänge,
- Temperatur,
- Spannung,
- Sendeleistung,
- Empfangsleistung,
- Alarmgrenzen.
**Cisco – abhängig von Plattform und Software**
```text
show interfaces transceiver detail
```
**Juniper Junos**
```text
show interfaces diagnostics optics
```
Bestimmte Schnittstelle:
```text
show interfaces diagnostics optics ge-0/0/1
```
**Aruba AOS-CX**
```text
show interface transceiver
```
Die genaue Syntax muss in der Dokumentation der verwendeten Plattform geprüft werden.
**Wichtige Einordnung**
- Zu geringe Empfangsleistung kann auf Dämpfung, Verschmutzung, falsche Faser oder defekte Komponenten hinweisen.
- Zu hohe Empfangsleistung kann einen Empfänger ebenfalls außerhalb des zulässigen Bereichs betreiben.
- Ein angezeigter optischer Wert muss mit den Grenzwerten des konkreten Transceivers verglichen werden.
- Ein Link kann trotz ungünstiger Werte zunächst funktionieren und später instabil werden.
- Glasfaserstecker dürfen nur mit geeigneten Werkzeugen gereinigt und untersucht werden.
---
**12. VLAN-Zuordnung prüfen**
Typische Ursachen sind:
- falsches Access-VLAN,
- fehlendes VLAN,
- VLAN nicht auf dem Trunk erlaubt,
- unterschiedliche native VLANs,
- falsche Voice-VLAN-Konfiguration,
- VLAN auf einem Zwischen-Switch nicht vorhanden,
- falsche Portrolle.
**Cisco IOS beziehungsweise IOS XE**
```text
show vlan brief
```
```text
show interfaces trunk
```
```text
show interfaces GigabitEthernet1/0/1 switchport
```
**Juniper Junos – abhängig vom Switching-Modell**
```text
show vlans
```
```text
show ethernet-switching interfaces
```
**Aruba AOS-CX**
```text
show vlan
```
```text
show vlan port 1/1/1
```
```text
show interface 1/1/1
```
**Prüfreihenfolge**
1. Endgeräteport identifizieren.
2. Portmodus bestimmen.
3. Access- oder untagged VLAN prüfen.
4. Trunk beziehungsweise tagged VLANs prüfen.
5. Zwischenverbindungen untersuchen.
6. VLAN auf jedem beteiligten Gerät prüfen.
7. Layer-3-Gateway des VLANs kontrollieren.
8. DHCP, ARP und Sicherheitsrichtlinien prüfen.
---
**13. MAC-Adresstabelle untersuchen**
Die MAC-Adresstabelle zeigt, an welcher Schnittstelle ein Switch eine MAC-Adresse gelernt hat.
**Cisco IOS beziehungsweise IOS XE**
```text
show mac address-table
```
Bestimmte Adresse:
```text
show mac address-table address aaaa.bbbb.cccc
```
Bestimmte Schnittstelle:
```text
show mac address-table interface GigabitEthernet1/0/1
```
**Juniper Junos**
```text
show ethernet-switching table
```
**Aruba AOS-CX**
```text
show mac-address-table
```
**Mögliche Beobachtungen**
| Beobachtung | Einordnung |
|---|---|
| MAC-Adresse fehlt | kein Verkehr, falsches VLAN, Port down oder Gerät nicht verbunden |
| MAC-Adresse am erwarteten Port | Layer-2-Lernen funktioniert zumindest in dieser Richtung |
| MAC-Adresse an unerwartetem Port | Verkabelung, Schleife, virtuelle Umgebung oder Topologie prüfen |
| MAC-Adresse wechselt zwischen Ports | Schleife, redundante Fehlkonfiguration oder tatsächlich bewegtes Gerät |
| sehr viele MAC-Adressen an einem Endgeräteport | unerwarteter Switch, Hypervisor, Access Point oder Sicherheitsproblem |
| Tabelle nahezu ausgelastet | ungewöhnlich viele Geräte, Angriff oder Dimensionierungsproblem |
> Eine gelernte MAC-Adresse bestätigt nicht, dass IP-Konfiguration, Routing, DNS oder die Anwendung funktionieren.
---
**14. Spanning Tree untersuchen**
Spanning Tree verhindert Layer-2-Schleifen in redundanten Ethernetnetzen.
Zu prüfen sind:
- Root Bridge,
- Root Port,
- Portrollen,
- Portzustände,
- Topology Changes,
- blockierte beziehungsweise verworfene Ports,
- verwendete STP-Variante,
- unerwartete Root-Wahl,
- Schutzmechanismen.
**Cisco IOS beziehungsweise IOS XE**
```text
show spanning-tree
```
Bestimmtes VLAN:
```text
show spanning-tree vlan 10
```
Details:
```text
show spanning-tree detail
```
**Juniper Junos**
```text
show spanning-tree bridge
```
```text
show spanning-tree interface
```
**Aruba AOS-CX**
```text
show spanning-tree
```
```text
show spanning-tree detail
```
**Hinweise auf eine Layer-2-Schleife**
- sehr hohe Broadcast- oder Multicastlast,
- stark erhöhte CPU-Auslastung,
- MAC-Adressen wechseln zwischen Ports,
- Managementzugriff ist instabil,
- viele Topology Changes,
- Paketverlust im gesamten VLAN,
- mehrere Ports zeigen außergewöhnlich hohe Datenraten.
> Ein durch STP blockierter Port ist nicht automatisch fehlerhaft. Das Blockieren kann die beabsichtigte schleifenfreie Topologie herstellen.
---
**15. Link Aggregation und LACP**
Bei gebündelten Verbindungen müssen geprüft werden:
- Mitgliedsschnittstellen,
- physischer Linkstatus,
- LACP-Zustand,
- aktive und passive Seite,
- Aggregationskennung,
- Geschwindigkeit,
- VLAN-Konfiguration,
- Hashverfahren,
- Mindestanzahl benötigter Mitglieder,
- Konfiguration der Gegenstelle.
**Cisco IOS beziehungsweise IOS XE**
```text
show etherchannel summary
```
```text
show lacp neighbor
```
```text
show interfaces port-channel 1
```
**Juniper Junos**
```text
show interfaces ae0 extensive
```
```text
show lacp interfaces
```
**Aruba AOS-CX**
```text
show lacp interfaces
```
```text
show interface lag 1
```
**Typische Fehler**
- Port ist nicht im Bündel aktiv,
- unterschiedliche LACP-Modi,
- ungleiche Geschwindigkeiten,
- verschiedene VLAN-Listen,
- Verbindung zu unterschiedlichen logischen Gegenstellen ohne passende Multi-Chassis-Technik,
- fehlerhaftes Mitglied beeinträchtigt einen Teil des Datenverkehrs,
- Hashverteilung belastet einzelne Mitglieder stärker.
---
**16. LLDP und CDP zur Topologieprüfung**
Nachbarerkennungsprotokolle helfen dabei, die tatsächlich angeschlossene Gegenstelle zu bestimmen.
**Cisco Discovery Protocol**
```text
show cdp neighbors
```
Details:
```text
show cdp neighbors detail
```
**Link Layer Discovery Protocol auf Cisco**
```text
show lldp neighbors
```
```text
show lldp neighbors detail
```
**Juniper Junos**
```text
show lldp neighbors
```
```text
show lldp neighbors detail
```
**Aruba AOS-CX**
```text
show lldp neighbor-info
```
**Zu beachten**
- CDP ist proprietär und nicht auf allen Herstellern verfügbar.
- LLDP ist herstellerübergreifend, kann aber deaktiviert sein.
- Fehlende Nachbarinformationen beweisen nicht, dass keine physische Verbindung besteht.
- Nachbardaten können Gerätenamen, Managementadressen und Topologieinformationen enthalten und müssen geschützt werden.
---
**17. ARP und IPv6 Neighbor Discovery**
ARP ordnet IPv4-Adressen MAC-Adressen zu. IPv6 verwendet Neighbor Discovery.
**Cisco IOS beziehungsweise IOS XE**
```text
show ip arp
```
```text
show ipv6 neighbors
```
**Juniper Junos**
```text
show arp
```
```text
show ipv6 neighbors
```
**Aruba AOS-CX**
```text
show arp
```
```text
show ipv6 neighbors
```
**Typische Beobachtungen**
| Beobachtung | mögliche Ursache |
|---|---|
| kein Eintrag | Ziel nicht lokal, keine Antwort, falsches VLAN oder falsches Präfix |
| Eintrag unvollständig | ARP- beziehungsweise Neighbor-Anfrage bleibt unbeantwortet |
| wechselnde MAC-Adresse | doppelte IP-Adresse, Cluster, Proxy ARP oder Fehlkonfiguration |
| MAC-Adresse stimmt nicht mit erwartetem Gerät überein | doppelte Adresse, falsche Dokumentation oder Manipulation |
| Eintrag vorhanden, Kommunikation scheitert | Problem kann oberhalb der Nachbarauflösung liegen |
Das manuelle Löschen von ARP- oder Neighbor-Einträgen verändert den Zustand und sollte erst nach Dokumentation und mit konkreter Hypothese erfolgen.
---
**18. IP-Adressen und Routingtabelle**
Zu prüfen sind:
- IP-Adresse,
- Präfixlänge,
- direkt verbundene Netze,
- Standardroute,
- spezifische Routen,
- nächste Hops,
- Routingprotokoll,
- administrative Distanz beziehungsweise Präferenz,
- Metrik,
- VRF oder Routinginstanz,
- Rückweg.
**Cisco IOS beziehungsweise IOS XE**
```text
show ip interface brief
```
```text
show ip route
```
Bestimmtes Ziel:
```text
show ip route 192.0.2.10
```
IPv6:
```text
show ipv6 route
```
VRF-Übersicht:
```text
show vrf
```
**Juniper Junos**
```text
show interfaces terse
```
```text
show route
```
Bestimmtes Ziel:
```text
show route 192.0.2.10
```
Routinginstanzen:
```text
show route instance
```
**Aruba AOS-CX**
```text
show ip interface brief
```
```text
show ip route
```
```text
show vrf
```
**Routingprüfung**
1. Quellnetz bestimmen.
2. Zieladresse exakt bestimmen.
3. verwendete VRF beziehungsweise Routinginstanz feststellen.
4. Route zum Ziel prüfen.
5. nächsten Hop prüfen.
6. Erreichbarkeit des nächsten Hops prüfen.
7. Rückroute untersuchen.
8. Policy-Based Routing berücksichtigen.
9. NAT, Firewall und VPN berücksichtigen.
10. bei dynamischem Routing den Protokollzustand prüfen.
> Eine vorhandene Hinroute bestätigt keine funktionierende Rückroute. Asymmetrische Wege können insbesondere bei Firewalls und zustandsbehafteten Systemen Probleme verursachen.
---
**19. Ping richtig verwenden**
Ping verwendet ICMP Echo Request und Echo Reply.
Damit können unter anderem untersucht werden:
- grundsätzliche IP-Erreichbarkeit,
- Paketverlust,
- Laufzeit,
- Erreichbarkeit aus einer bestimmten Quelle,
- MTU-Probleme mit geeigneten Optionen.
**Cisco IOS beziehungsweise IOS XE**
```text
ping 192.0.2.10
```
Erweiterter Dialog:
```text
ping
```
**Juniper Junos**
```text
ping 192.0.2.10
```
Bestimmte Quelladresse:
```text
ping 192.0.2.10 source 192.0.2.1
```
**Aruba AOS-CX**
```text
ping 192.0.2.10
```
Die Optionen für Quelladresse, VRF, Paketgröße und Anzahl sind versionsabhängig.
**Sinnvolle Zielreihenfolge**
1. eigene Schnittstellenadresse,
2. direkt verbundener nächster Hop,
3. Gateway,
4. entferntes IP-Ziel,
5. Ziel über Namen.
**Grenzen**
- ICMP kann gefiltert werden.
- Eine Firewall kann Ping anders behandeln als Anwendungsverkehr.
- Ein erfolgreicher Ping prüft keinen TCP-Port.
- Ein erfolgreicher Ping bestätigt keine Anmeldung oder Anwendung.
- Ein Ping ohne festgelegte Quelladresse kann einen anderen Pfad verwenden als der betroffene Datenverkehr.
---
**20. Traceroute richtig verwenden**
Traceroute hilft dabei, den Pfad beziehungsweise die antwortenden Zwischenstationen zu untersuchen.
**Cisco IOS beziehungsweise IOS XE**
```text
traceroute 192.0.2.10
```
**Juniper Junos**
```text
traceroute 192.0.2.10
```
**Aruba AOS-CX**
```text
traceroute 192.0.2.10
```
**Einordnung**
- Sternchen bedeuten nicht automatisch, dass der gesamte folgende Pfad unterbrochen ist.
- Router können Ablaufmeldungen filtern oder begrenzen.
- Lastverteilung kann verschiedene Pfade zeigen.
- Hin- und Rückweg können unterschiedlich sein.
- Tunnel und MPLS können physische Zwischenwege verbergen.
- Ein Abbruch an einem Hop beweist nicht, dass genau dieses Gerät die Ursache ist.
---
**21. Dynamische Routingprotokolle**
Bei OSPF, BGP und anderen Protokollen sind drei Ebenen getrennt zu prüfen:
1. besteht die Nachbarschaft?
2. werden erwartete Routen ausgetauscht?
3. wird die gewünschte Route tatsächlich für die Weiterleitung verwendet?
**Cisco – OSPF**
```text
show ip ospf neighbor
```
```text
show ip ospf interface
```
```text
show ip route ospf
```
**Cisco – BGP**
```text
show ip bgp summary
```
```text
show ip bgp
```
```text
show ip route bgp
```
**Juniper – OSPF**
```text
show ospf neighbor
```
```text
show ospf interface
```
```text
show route protocol ospf
```
**Juniper – BGP**
```text
show bgp summary
```
```text
show route protocol bgp
```
**Aruba AOS-CX – je nach Plattform und Funktionsumfang**
```text
show ip ospf neighbors
```
```text
show bgp all summary
```
**Typische Ursachen**
- Schnittstelle down,
- falsche IP-Adresse oder Präfixlänge,
- unterschiedliche Area,
- Authentifizierungsfehler,
- unterschiedliche Timer,
- MTU-Abweichung,
- fehlende Route zur Nachbaradresse,
- falsche Autonomous-System-Nummer,
- Filterrichtlinie,
- maximale Präfixanzahl,
- fehlende Freigabe durch ACL oder Firewall,
- instabile Verbindung,
- unterschiedliche VRF.
> Eine bestehende Routingnachbarschaft bestätigt nicht, dass alle benötigten Präfixe korrekt angenommen, ausgewählt und weitergeleitet werden.
---
**22. ACL- und Firewallregeln prüfen**
Bei Zugriffslisten und Firewalls müssen geprüft werden:
- Quelle,
- Ziel,
- Protokoll,
- Quellport,
- Zielport,
- Eingangszone,
- Ausgangszone,
- Richtung,
- Regelreihenfolge,
- Zähler,
- NAT,
- Sitzungstabelle,
- Benutzer- oder Anwendungsidentität,
- Zeitplan,
- Protokollierung.
**Cisco IOS beziehungsweise IOS XE**
```text
show access-lists
```
```text
show ip access-lists
```
Zuordnung zu Schnittstellen:
```text
show ip interface
```
**Juniper SRX**
```text
show security policies
```
```text
show security policies hit-count
```
```text
show security flow session
```
```text
show security nat source rule all
```
**Wichtige Einordnung**
- Ein Regelzähler kann historischen Verkehr enthalten.
- Ein Zähler von null kann bedeuten, dass der Datenverkehr eine frühere Regel trifft.
- Zustandsbehaftete Firewalls benötigen häufig einen passenden Rückweg.
- NAT kann dazu führen, dass Protokolle eine andere Adresse zeigen.
- Eine erlaubende Regel bestätigt nicht, dass Routing, NAT oder Zielservice funktionieren.
- Ein Paket kann vor oder nach einer untersuchten Regel verworfen werden.
---
**23. DHCP untersuchen**
Zu prüfen sind:
- erhält der Client überhaupt eine DHCP-Antwort?
- befindet sich Client und Server im selben Netz?
- ist DHCP-Relay erforderlich?
- stimmt die Relay-Zieladresse?
- ist der Adressbereich erschöpft?
- besteht eine Sicherheitsfunktion wie DHCP Snooping?
- stimmen Gateway, DNS und Lease-Zeit?
- erreicht die Antwort den Client zurück?
**Cisco IOS beziehungsweise IOS XE**
DHCP-Relay auf einer Schnittstelle erkennen:
```text
show running-config interface Vlan10
```
DHCP Snooping:
```text
show ip dhcp snooping
```
DHCP-Bindings bei lokalem DHCP-Server:
```text
show ip dhcp binding
```
**Juniper Junos**
Die Befehle hängen davon ab, ob das Gerät als DHCP-Server, Relay oder Sicherheitsgerät arbeitet. Beispiele:
```text
show dhcp server binding
```
```text
show dhcp relay binding
```
Diese Befehle sind nicht auf jeder Junos-Plattform in derselben Form verfügbar.
**Typische Fehlerkette**
```text
Client Discover
→ Switch und VLAN
→ DHCP Relay
→ Routing beziehungsweise Firewall
→ DHCP Server
→ Offer und Acknowledgement
→ Rückweg zum Client
```
---
**24. DNS, NTP, RADIUS und TACACS+**
Netzwerkgeräte sind häufig von Infrastrukturdiensten abhängig.
**DNS-Probleme können verursachen**
- fehlgeschlagene Hostnamensauflösung,
- nicht erreichbare Controller,
- fehlgeschlagene Zertifikatsprüfung,
- Probleme mit Cloudmanagement,
- verzögerte Kommandoeingaben bei ungeeigneter Namensauflösung.
**NTP-Probleme können verursachen**
- falsche Protokollzeitpunkte,
- Zertifikatsfehler,
- Authentifizierungsprobleme,
- unbrauchbare Ereigniskorrelation,
- Probleme mit zeitabhängigen Sicherheitsmechanismen.
**RADIUS- oder TACACS+-Probleme können verursachen**
- fehlgeschlagene Administratoranmeldung,
- fehlende Autorisierung einzelner Befehle,
- fehlgeschlagene Netzwerkzugangskontrolle,
- Abhängigkeit von einem nicht erreichbaren Server.
**Cisco IOS beziehungsweise IOS XE**
```text
show clock
```
```text
show ntp associations
```
```text
show ntp status
```
```text
show aaa servers
```
Die verfügbaren AAA-Befehle unterscheiden sich nach Plattform und Version.
**Juniper Junos**
```text
show system uptime
```
```text
show ntp associations
```
```text
show system users
```
**Prüfen**
- stimmt die Uhrzeit?
- stimmt die Zeitzone?
- ist der Zeitserver erreichbar?
- wird die erwartete Quelladresse verwendet?
- erreicht der Dienst die richtige VRF?
- blockiert eine ACL den Verkehr?
- ist ein lokales Notfallkonto gemäß Unternehmensvorgabe vorhanden?
---
**25. Protokolle auswerten**
Netzwerkgeräte können Protokolle speichern oder an einen zentralen Syslog-Server senden.
Zu erfassen sind:
- genauer Zeitpunkt,
- Zeitzone,
- Meldungsquelle,
- Schweregrad,
- Prozess oder Subsystem,
- betroffene Schnittstelle,
- Meldung vor und nach dem Ereignis,
- wiederkehrende Muster,
- Zusammenhang mit Konfigurationsänderungen.
**Cisco IOS beziehungsweise IOS XE**
```text
show logging
```
**Juniper Junos**
```text
show log messages
```
Letzte Einträge:
```text
show log messages | last 50
```
**Aruba AOS-CX**
```text
show logging
```
**Typische Meldungen**
- Link up oder down,
- STP-Änderung,
- Routingnachbarschaft verloren,
- Authentifizierungsfehler,
- Hardwarealarm,
- Temperaturwarnung,
- Konfigurationsänderung,
- Prozessneustart,
- Ressourcengrenze,
- Firewallblockierung,
- VPN-Neuverhandlung.
> Eine einzelne Fehlermeldung beweist nicht automatisch die Ursache. Sie muss zeitlich und technisch mit dem beobachteten Symptom verbunden werden.
---
**26. Syslog-Schweregrade**
Die verbreitete Syslog-Einteilung umfasst:
| Wert | Bezeichnung | Bedeutung |
|---:|---|---|
| 0 | Emergency | System nicht verwendbar |
| 1 | Alert | sofortige Maßnahme erforderlich |
| 2 | Critical | kritischer Zustand |
| 3 | Error | Fehlerzustand |
| 4 | Warning | Warnung |
| 5 | Notice | bedeutender normaler Zustand |
| 6 | Informational | Informationsmeldung |
| 7 | Debug | ausführliche Diagnosemeldung |
Die tatsächliche Nutzung der Stufen hängt vom Hersteller und der jeweiligen Komponente ab.
**Zu beachten**
- Zu niedrige Schwelle kann wichtige Meldungen auslassen.
- Zu ausführliche Protokollierung kann sehr große Datenmengen erzeugen.
- Debug-Protokolle können sensible Informationen enthalten.
- Zentrale Protokolle benötigen korrekte Zeitstempel.
- UDP-Syslog bestätigt keine zuverlässige Zustellung.
- Transport, Verschlüsselung und Aufbewahrung müssen den Sicherheitsvorgaben entsprechen.
---
**27. SNMP und Telemetrie**
SNMP und Streaming-Telemetrie können langfristige Messwerte liefern.
Typische Werte sind:
- Schnittstellenstatus,
- Datenraten,
- Fehlerzähler,
- Paketverluste,
- CPU-Auslastung,
- Speichernutzung,
- Temperatur,
- Netzteilzustand,
- Routingnachbarschaften,
- Verfügbarkeit.
**SNMP-Versionen**
| Version | Einordnung |
|---|---|
| SNMPv1 | veraltet, keine moderne Absicherung |
| SNMPv2c | Community-basierte Absicherung, keine angemessene Vertraulichkeit |
| SNMPv3 | unterstützt Benutzer-, Authentifizierungs- und Verschlüsselungsmechanismen |
SNMPv3 sollte bevorzugt werden, sofern die Umgebung es unterstützt.
**Diagnostischer Nutzen**
- Beginn einer Störung zeitlich bestimmen,
- kurzfristige und langfristige Werte vergleichen,
- Lastspitzen erkennen,
- wachsende Fehlerzähler sehen,
- wiederkehrende Ausfälle untersuchen,
- Geräte miteinander vergleichen.
**Grenzen**
- Abfrageintervalle können kurze Ereignisse übersehen.
- Ein Mittelwert kann Spitzen verbergen.
- Zähler können nach Neustarts zurückgesetzt werden.
- 32-Bit-Zähler können bei schnellen Verbindungen überlaufen.
- fehlerhafte Zeitsynchronisation erschwert die Korrelation.
- Monitoringausfall bedeutet nicht automatisch Geräteausfall.
---
**28. Paketmitschnitt auf Netzwerkgeräten**
Viele Router, Firewalls und Switches unterstützen lokale oder gespiegelte Paketmitschnitte.
Mögliche Verfahren:
- integrierter Paketmitschnitt,
- Port Mirroring,
- SPAN,
- Remote SPAN,
- ERSPAN,
- Firewall Packet Capture,
- Controller-basierter Mitschnitt,
- externer Netzwerk-TAP.
**Vorher festlegen**
- betroffene Schnittstelle,
- Richtung,
- VLAN,
- Quelladresse,
- Zieladresse,
- Protokoll,
- Zielport,
- maximale Paketanzahl,
- maximale Dateigröße,
- Dauer,
- Speicherort,
- Datenschutz,
- Löschzeitpunkt.
**Wichtige Einschränkungen**
- Ein Mitschnitt auf einem überlasteten Gerät kann unvollständig sein.
- Hardwareweiterleitung kann dazu führen, dass nicht jeder Verkehr an der CPU sichtbar ist.
- Ein SPAN-Ziel kann bei Überlastung Pakete verlieren.
- Der Mitschnittpunkt bestimmt, ob VLAN-Tags, NAT-Adressen oder entschlüsselter Verkehr sichtbar sind.
- Eine Firewall kann Pakete an einer Schnittstelle empfangen und später durch eine Regel verwerfen.
- Verschlüsselter Datenverkehr zeigt ohne zulässige Entschlüsselung keine Anwendungsinhalte.
Paketmitschnitte können enthalten:
- IP-Adressen,
- MAC-Adressen,
- Hostnamen,
- DNS-Abfragen,
- Anmeldedaten bei unverschlüsselten Protokollen,
- Sitzungskennungen,
- personenbezogene Daten,
- vertrauliche Anwendungsinhalte.
---
**29. Debug-Befehle**
Debug-Befehle erzeugen detaillierte Laufzeitinformationen.
Sie können:
- sehr viele Meldungen erzeugen,
- CPU und Speicher belasten,
- die Konsole überfluten,
- Sitzungen unterbrechen,
- sensible Inhalte protokollieren,
- bei produktiven Geräten einen Ausfall verschärfen.
**Vor einem Debug**
1. konkrete Hypothese formulieren,
2. Herstellerdokumentation prüfen,
3. Auswirkungen für die Plattform prüfen,
4. Wartungsfreigabe einholen,
5. Filter festlegen,
6. Zeitdauer begrenzen,
7. Beendigung des Debugs vorbereiten,
8. alternative Beobachtungsmöglichkeit prüfen.
**Cisco IOS beziehungsweise IOS XE**
Aktive Debugs anzeigen:
```text
show debugging
```
Debug-Ausgaben vollständig beenden:
```text
undebug all
```
Der Befehl `debug all` darf auf produktiven Geräten nicht als allgemeine Diagnosemaßnahme verwendet werden.
> Ein Debug sollte nur gezielt, zeitlich begrenzt und unter Beobachtung durchgeführt werden.
---
**30. Konfiguration vergleichen**
Zu unterscheiden sind:
- aktuell laufende Konfiguration,
- für den nächsten Start gespeicherte Konfiguration,
- zentral verwaltete Konfiguration,
- automatisch erzeugte Konfiguration,
- Konfigurationsvorlage,
- tatsächlicher operativer Zustand.
**Cisco IOS beziehungsweise IOS XE**
```text
show running-config
```
```text
show startup-config
```
Letzte Konfigurationsänderung:
```text
show archive log config all
```
Der Archivierungsbefehl liefert nur dann passende Daten, wenn die entsprechende Funktion unterstützt und eingerichtet ist.
**Juniper Junos**
```text
show configuration
```
Vergleich mit vorheriger Konfiguration:
```text
show system commit
```
```text
show system rollback compare 1
```
**Aruba AOS-CX**
```text
show running-config
```
```text
show startup-config
```
**Beim Vergleich beachten**
- automatisch erzeugte Zeilen,
- unterschiedliche Reihenfolge ohne Funktionsänderung,
- verschlüsselte oder maskierte Geheimnisse,
- dynamisch gelernte Zustände,
- Änderungen durch Controller oder Automatisierung,
- nicht gespeicherte Änderungen,
- gerätespezifische Standardwerte.
> Eine Konfiguration darf nicht ungeprüft vollständig in ein Ticket oder öffentliches Dokument kopiert werden. Sie kann Kennwörter, Schlüssel, Community-Strings, Adressen und interne Topologieinformationen enthalten.
---
**31. Hochverfügbarkeit und Stacks**
Bei redundanten Geräten sind zusätzlich zu prüfen:
- aktives und passives Mitglied,
- Synchronisationsstatus,
- letzte Rollenänderung,
- Split-Brain-Schutz,
- Heartbeat- oder Keepalive-Verbindung,
- Versionsgleichheit,
- Konfigurationsgleichheit,
- Sitzungssynchronisation,
- Uplinkzustand beider Geräte,
- Stack-Ring,
- Stack-Mitglieder,
- Redundanz der Stromversorgung.
**Mögliche Fehlerbilder**
| Beobachtung | mögliche Ursache |
|---|---|
| beide Geräte halten sich für aktiv | Split Brain oder unterbrochene Kontrollverbindung |
| passives Gerät nicht bereit | Versions-, Konfigurations- oder Hardwareproblem |
| Failover funktioniert, Sitzungen brechen ab | fehlende oder unvollständige Sitzungssynchronisation |
| nur Ports eines Stack-Mitglieds betroffen | Mitglied, Stack-Verbindung oder Stromversorgung |
| wiederholte Rollenwechsel | instabile Verbindung, Ressourcenproblem oder fehlerhafte Zustandsprüfung |
| Redundanz angezeigt, aber gemeinsamer Uplink fehlt | logische Redundanz ohne vollständige Pfadredundanz |
Ein manuell ausgelöstes Failover ist eine produktive Änderung und benötigt eine Risikoprüfung.
---
**32. WLAN-Access-Points und Controller**
Bei WLAN-Problemen müssen Funk-, Netzwerk- und Authentifizierungsebene getrennt werden.
Zu prüfen sind:
- wird der Access Point mit Strom versorgt?
- erhält er eine IP-Adresse?
- erreicht er Controller oder Cloudplattform?
- wird die erwartete Konfiguration übernommen?
- sendet die gewünschte SSID?
- stimmen VLAN und Trunk?
- funktioniert Authentifizierung?
- erhält der Client eine IP-Adresse?
- bestehen Störungen oder hohe Kanalauslastung?
- wechselt der Client zwischen Access Points?
- funktionieren DNS und Gateway?
**Typische WLAN-Werte**
- RSSI,
- SNR,
- Kanal,
- Kanalbreite,
- Frequenzband,
- Sendeleistung,
- Retries,
- Kanalnutzung,
- Clientanzahl,
- Datenrate,
- Roamingereignisse,
- Authentifizierungsstatus.
**Fehlinterpretationen vermeiden**
| Beobachtung | Einordnung |
|---|---|
| starke Signalstärke | bestätigt nicht automatisch gute Signalqualität oder geringen Störpegel |
| Client ist verbunden | bestätigt nicht automatisch DHCP, Routing oder Internetzugriff |
| SSID ist sichtbar | bestätigt nicht automatisch erfolgreiche Authentifizierung |
| Access Point ist online | bestätigt nicht automatisch störungsfreien Funkbetrieb |
| hohe theoretische Datenrate | entspricht nicht automatisch dem tatsächlichen Durchsatz |
| viele Access Points | können bei ungeeigneter Planung zusätzliche Störungen verursachen |
---
**33. VPN untersuchen**
Bei einem VPN müssen getrennt geprüft werden:
1. physische und IP-Erreichbarkeit,
2. Namensauflösung,
3. IKE- beziehungsweise Kontrollverbindung,
4. Authentifizierung,
5. Tunnelaufbau,
6. Verschlüsselungsparameter,
7. Routen,
8. Sicherheitsrichtlinien,
9. NAT-Ausnahmen,
10. Datenzähler,
11. Rückweg,
12. MTU und Fragmentierung.
**Typische Fehler**
- falsche Peer-Adresse,
- Zertifikat abgelaufen,
- falsche Systemzeit,
- unterschiedliche Verschlüsselungsverfahren,
- unterschiedliche Netzdefinitionen,
- fehlende Route,
- NAT vor dem Tunnel,
- Firewall blockiert IKE oder ESP,
- Tunnel steht, aber keine Sicherheitsrichtlinie erlaubt den Verkehr,
- überlappende Adressbereiche,
- asymmetrischer Rückweg,
- MTU-Problem.
> Ein angezeigter VPN-Status „up“ bestätigt nicht automatisch, dass Nutzdaten in beide Richtungen übertragen werden.
---
**34. NAT untersuchen**
Bei NAT sind zu erfassen:
- ursprüngliche Quelladresse,
- ursprüngliche Zieladresse,
- übersetzte Quelladresse,
- übersetzte Zieladresse,
- Quellport,
- Zielport,
- zugehörige Regel,
- Richtung,
- Zone,
- Sitzung,
- Rückweg.
**Typische Probleme**
- falsche Regelreihenfolge,
- fehlende NAT-Ausnahme für VPN,
- Adresspool erschöpft,
- Portübersetzung erschöpft,
- unerwartetes doppeltes NAT,
- Rückroute zur übersetzten Adresse fehlt,
- Anwendung überträgt eingebettete Adressen,
- Protokolle zeigen nur eine Seite der Übersetzung.
Eine erfolgreiche NAT-Übersetzung bestätigt noch nicht, dass der Zielservice antwortet.
---
**35. Support- und Diagnosepakete**
Viele Hersteller bieten einen Sammelbefehl oder eine Supportdatei an.
Beispiele:
**Cisco – plattformabhängig**
```text
show tech-support
```
**Juniper Junos**
```text
request support information
```
**Aruba AOS-CX**
```text
show tech
```
Diese Ausgaben können sehr umfangreich sein und das Gerät belasten.
Sie können enthalten:
- vollständige oder teilweise Konfiguration,
- IP-Adressen,
- Seriennummern,
- Benutzernamen,
- Routinginformationen,
- Nachbarn,
- Protokolle,
- Zertifikatsinformationen,
- Sitzungstabellen,
- interne Topologie,
- Sicherheitsrichtlinien.
**Vor der Erstellung**
- Speicherplatz prüfen,
- Belastung abschätzen,
- Freigabe einholen,
- sicheren Speicherort bestimmen,
- Übertragungsweg festlegen,
- Empfängerkreis begrenzen,
- Aufbewahrungsdauer definieren,
- vertrauliche Inhalte prüfen.
---
**36. Typische Prüfreihenfolge bei einem ausgefallenen Switchport**
1. betroffenes Endgerät und Port bestimmen,
2. Linkstatus prüfen,
3. Portbeschreibung kontrollieren,
4. Fehlerzähler dokumentieren,
5. Geschwindigkeit und Duplex prüfen,
6. VLAN-Zuordnung prüfen,
7. MAC-Adresstabelle prüfen,
8. STP-Zustand prüfen,
9. Port-Security oder NAC prüfen,
10. PoE-Zustand prüfen,
11. Nachbarinformationen prüfen,
12. Gegenstelle untersuchen,
13. Kabel oder Transceiver kontrolliert gegenprüfen,
14. nach jeder Maßnahme erneut testen.
**Beispiel Cisco IOS beziehungsweise IOS XE**
```text
show interfaces status
```
```text
show interfaces GigabitEthernet1/0/1
```
```text
show interfaces GigabitEthernet1/0/1 switchport
```
```text
show mac address-table interface GigabitEthernet1/0/1
```
```text
show spanning-tree interface GigabitEthernet1/0/1 detail
```
```text
show power inline GigabitEthernet1/0/1
```
---
**37. Praxisbeispiel: Client erreicht das Gateway nicht**
**Symptom**
Ein Client besitzt eine IP-Adresse, kann aber sein Standardgateway nicht erreichen.
**Prüfung**
1. IP-Adresse und Präfix des Clients kontrollieren.
2. Standardgateway kontrollieren.
3. physische Verbindung prüfen.
4. Access-VLAN des Ports prüfen.
5. VLAN auf den Trunks verfolgen.
6. MAC-Adresse des Clients suchen.
7. ARP-Eintrag auf Client und Gateway prüfen.
8. Gateway-Schnittstelle beziehungsweise SVI prüfen.
9. STP-Zustand prüfen.
10. Port-Security, NAC und ACL prüfen.
11. Paketmitschnitt nur bei verbleibender Unklarheit verwenden.
**Mögliche Ursachen**
- falsche Clientadresse,
- falsches Präfix,
- falsches Gateway,
- falsches Access-VLAN,
- VLAN fehlt auf einem Trunk,
- Gateway-Schnittstelle down,
- doppelte IP-Adresse,
- ARP-Problem,
- Port-Security,
- NAC-Quarantäne,
- Layer-2-Schleife,
- fehlerhafte physische Verbindung.
---
**38. Praxisbeispiel: VLAN funktioniert an einem Switch, am nächsten nicht**
**Prüfung**
1. VLAN auf beiden Switches anzeigen.
2. Access-Port des Clients prüfen.
3. Uplink und Trunk bestimmen.
4. erlaubte VLANs auf beiden Seiten vergleichen.
5. native beziehungsweise untagged VLANs vergleichen.
6. STP-Zustand für das VLAN prüfen.
7. MAC-Adresse entlang des Pfads verfolgen.
8. LACP-Zustand bei gebündeltem Uplink prüfen.
9. Zwischen-Switches einbeziehen.
10. erst danach Konfiguration ändern.
**Mögliche Ursachen**
- VLAN auf einem Gerät nicht angelegt,
- VLAN nicht auf dem Trunk erlaubt,
- unterschiedliche Portmodi,
- falsches untagged beziehungsweise native VLAN,
- STP blockiert den erwarteten Pfad,
- fehlerhaftes LACP-Mitglied,
- falsche physische Verbindung,
- VLAN-Zuordnung durch Controller oder Vorlage überschrieben.
---
**39. Praxisbeispiel: Standortverbindung ist langsam**
**Zuerst messen**
- betroffene Standorte,
- betroffene Anwendungen,
- Beginn und Dauer,
- Paketverlust,
- Laufzeit,
- Durchsatz,
- Schnittstellenauslastung,
- Fehlerzähler,
- Drops,
- QoS-Warteschlangen,
- VPN-Zähler,
- CPU-Auslastung,
- MTU.
**Mögliche Ursachen**
- ausgelastete WAN-Verbindung,
- Output Drops,
- physische Fehler,
- Duplexproblem,
- ungeeignete QoS-Regel,
- Backup- oder Synchronisationsverkehr,
- Paketverlust im Providerpfad,
- VPN-Neuverschlüsselung,
- MTU- oder Fragmentierungsproblem,
- Anwendung oder Server statt Netzwerk,
- asymmetrischer Pfad.
> Ein hoher Ping-Wert allein beweist keine geringe verfügbare Bandbreite. Laufzeit, Paketverlust, Jitter und Durchsatz sind unterschiedliche Messgrößen.
---
**40. Praxisbeispiel: Gerät ist im Monitoring offline**
**Prüfreihenfolge**
1. ist nur das Monitoring oder auch die Nutzfunktion betroffen?
2. ist die Managementadresse erreichbar?
3. stimmt die Route zum Managementnetz?
4. funktioniert der verwendete SNMP-, HTTPS- oder Telemetrieport?
5. stimmt die Management-VRF?
6. sind ACL und Firewallregeln unverändert?
7. sind Zugangsdaten oder Zertifikate abgelaufen?
8. stimmt die Gerätezeit?
9. ist der Monitoringdienst selbst funktionsfähig?
10. antwortet das Gerät über einen anderen Managementweg?
**Mögliche Einordnung**
| Ergebnis | mögliche Ursache |
|---|---|
| Nutzdaten funktionieren, Monitoring nicht | Managementpfad, SNMP, Zertifikat oder Monitoringserver |
| Ping funktioniert, SNMP nicht | SNMP-Konfiguration, ACL, Zugangsdaten oder Dienst |
| mehrere Geräte gleichzeitig offline | Monitoringserver, gemeinsamer Managementpfad oder zentrale Firewall |
| nur ein Standort offline | WAN-, VPN- oder Standortproblem |
| Gerät nur über Konsole erreichbar | Managementnetz, Routing, ACL oder Überlastung |
---
**41. Häufige Fehlinterpretationen**
| Aussage | fachliche Einordnung |
|---|---|
| „Der Port ist up, also ist die Verbindung in Ordnung.“ | Linkstatus bestätigt nicht VLAN, Routing, Fehlerfreiheit oder Anwendung. |
| „Ping funktioniert, daher ist der Dienst erreichbar.“ | Ping prüft keinen Anwendungsport und keine Anmeldung. |
| „Die Route ist vorhanden, also muss der Verkehr funktionieren.“ | Rückroute, Firewall, NAT und operative Weiterleitung müssen ebenfalls stimmen. |
| „Der Traceroute endet an einem Router, also ist dieser defekt.“ | Zwischenstationen können Antworten filtern oder begrenzen. |
| „STP blockiert einen Port, deshalb liegt ein Fehler vor.“ | Das Blockieren kann die beabsichtigte Schleifenvermeidung sein. |
| „Der Fehlerzähler ist hoch, daher besteht der Fehler noch.“ | Entscheidend ist, ob der Zähler während der Störung weiter steigt. |
| „Die MAC-Adresse wurde gelernt, also funktioniert der Client.“ | Nur das Layer-2-Lernen wurde nachgewiesen. |
| „Das VPN ist up, also fließen Daten.“ | Routen, Richtlinien, NAT und Rückweg können weiterhin fehlerhaft sein. |
| „Das Gerät ist im Monitoring offline, also ist es ausgefallen.“ | Nur der Management- oder Monitoringpfad kann gestört sein. |
| „Ein Neustart behebt das Problem.“ | Er kann nur flüchtigen Zustand entfernen und Beweise vernichten. |
| „`show tech` ist nur eine harmlose Abfrage.“ | Umfangreiche Ausgaben können Ressourcen beanspruchen und vertrauliche Daten enthalten. |
| „Debug zeigt viele Fehler, also ist die Ursache gefunden.“ | Debug-Meldungen müssen mit Zeitpunkt, Datenpfad und Symptom abgeglichen werden. |
---
**42. Checkliste Netzwerkgeräte-Fehleranalyse**
- [ ] betroffenes Gerät und dessen Rolle sind bekannt.
- [ ] Hersteller, Modell und Softwareversion wurden erfasst.
- [ ] Zeitpunkt und letzte Änderungen wurden dokumentiert.
- [ ] laufende und gespeicherte Konfiguration wurden unterschieden.
- [ ] Managementzugriff wurde ohne unsichere Protokolle geprüft.
- [ ] CPU, Arbeitsspeicher und Hardwarezustand wurden kontrolliert.
- [ ] Schnittstellenstatus und Fehlerzähler wurden dokumentiert.
- [ ] Geschwindigkeit, Duplex und Medium wurden auf beiden Seiten geprüft.
- [ ] VLANs und Trunks wurden entlang des gesamten Pfads untersucht.
- [ ] MAC-, ARP- und IPv6-Nachbartabellen wurden geprüft.
- [ ] STP und LACP wurden berücksichtigt.
- [ ] Hin- und Rückroute wurden geprüft.
- [ ] richtige VRF beziehungsweise Routinginstanz wurde verwendet.
- [ ] Ping wurde bei Bedarf mit passender Quelladresse durchgeführt.
- [ ] Traceroute-Ergebnisse wurden nicht vorschnell interpretiert.
- [ ] ACL, Firewall, NAT und Sitzungstabellen wurden berücksichtigt.
- [ ] DNS, DHCP, NTP und Authentifizierungsdienste wurden getrennt geprüft.
- [ ] Protokolle wurden zeitlich mit dem Symptom abgeglichen.
- [ ] Zeitzone und Zeitsynchronisation wurden berücksichtigt.
- [ ] Monitoringwerte wurden mit aktuellen Gerätedaten verglichen.
- [ ] Debugging wurde nur gezielt und zeitlich begrenzt verwendet.
- [ ] Paketmitschnitte wurden begrenzt und geschützt.
- [ ] Supportdateien wurden auf vertrauliche Inhalte geprüft.
- [ ] Änderungen wurden einzeln und möglichst reversibel durchgeführt.
- [ ] Funktion und Nebenwirkungen wurden nach jeder Änderung geprüft.
- [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert.
---
**43. Schnellreferenz**
| Aufgabe | Cisco IOS/IOS XE | Juniper Junos | Aruba AOS-CX |
|---|---|---|---|
| Version | `show version` | `show version` | `show version` |
| Hardware | `show inventory` | `show chassis hardware` | `show inventory` |
| Systemzustand | `show platform resources` | `show chassis routing-engine` | `show system resource-utilization` |
| Schnittstellenübersicht | `show ip interface brief` | `show interfaces terse` | `show ip interface brief` |
| Schnittstellendetails | `show interfaces …` | `show interfaces … extensive` | `show interface …` |
| VLANs | `show vlan brief` | `show vlans` | `show vlan` |
| Trunks | `show interfaces trunk` | `show ethernet-switching interfaces` | Port- und VLAN-Status prüfen |
| MAC-Tabelle | `show mac address-table` | `show ethernet-switching table` | `show mac-address-table` |
| Spanning Tree | `show spanning-tree` | `show spanning-tree bridge` | `show spanning-tree` |
| LACP | `show lacp neighbor` | `show lacp interfaces` | `show lacp interfaces` |
| LLDP | `show lldp neighbors` | `show lldp neighbors` | `show lldp neighbor-info` |
| ARP | `show ip arp` | `show arp` | `show arp` |
| Routingtabelle | `show ip route` | `show route` | `show ip route` |
| OSPF-Nachbarn | `show ip ospf neighbor` | `show ospf neighbor` | `show ip ospf neighbors` |
| BGP-Übersicht | `show ip bgp summary` | `show bgp summary` | `show bgp all summary` |
| Protokolle | `show logging` | `show log messages` | `show logging` |
| NTP | `show ntp associations` | `show ntp associations` | versionsabhängig |
| Ping | `ping Ziel` | `ping Ziel` | `ping Ziel` |
| Traceroute | `traceroute Ziel` | `traceroute Ziel` | `traceroute Ziel` |
| Supportausgabe | `show tech-support` | `request support information` | `show tech` |
> Diese Tabelle ist eine Orientierung. Vor der Verwendung muss die Befehlsreferenz der konkreten Plattform und Softwareversion geprüft werden.
---
**Merksatz**
> Netzwerkgeräte werden nicht durch wahllose Neustarts, Tabellenlöschungen oder dauerhafte Debug-Ausgaben untersucht. Zuerst werden Hardware, Schnittstellen, VLANs, Nachbartabellen, Routing, Sicherheitsregeln, Protokolle und Abhängigkeiten getrennt geprüft. Danach wird eine konkrete Hypothese mit einer kleinen, kontrollierten und möglichst reversiblen Maßnahme getestet.
---
**Quellen und weiterführende Dokumentation**
- [Cisco – Ping- und Traceroute-Befehle verstehen](https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html)
- [Cisco – Extended Ping und Extended Traceroute](https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13730-ext-ping-trace.html)
- [Cisco – Switch-Port- und Schnittstellenprobleme untersuchen](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html)
- [Cisco – Troubleshooting Tools](https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1902.html)
- [Juniper – `show interfaces terse`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-interfaces-terse.html)
- [Juniper – Netzwerkprobleme untersuchen](https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/troubleshooting-network-issues.html)
- [Juniper – Junos OS CLI User Guide](https://www.juniper.net/documentation/us/en/software/junos/cli/cli.pdf)
- [HPE Aruba Networking – AOS-CX 10.15 CLI Guide für 6300/6400](https://www.arubanetworks.com/techdocs/AOS-CX/10.15/PDF/cli_6300-6400.pdf)
- [HPE Aruba Networking – AOS-CX `show tech`](https://www.arubanetworks.com/techdocs/AOS-CX/10.15/HTML/fundamentals_8400/Content/SysHW_cmds/sho-tec.htm)
- [IETF RFC 5424 – The Syslog Protocol](https://www.rfc-editor.org/rfc/rfc5424)
- [IETF RFC 3411 – SNMP Management Frameworks](https://www.rfc-editor.org/rfc/rfc3411)
- [IETF RFC 3414 – SNMPv3 User-based Security Model](https://www.rfc-editor.org/rfc/rfc3414)
- [IETF RFC 5905 – Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905)
# 5.7 Physische Messgeräte – Werkzeuge zur Fehleranalyse
Softwarewerkzeuge zeigen, wie Betriebssysteme, Netzwerkgeräte und Anwendungen einen Fehler wahrnehmen. Physische Messgeräte untersuchen dagegen Kabel, Steckverbindungen, elektrische Signale, optische Signale, Funkstörungen und die tatsächliche Stromversorgung.
Sie werden benötigt, wenn beispielsweise:
- eine Verbindung trotz korrekter Konfiguration instabil bleibt,
- ein Port keinen Link aufbaut,
- Fehlerzähler kontinuierlich steigen,
- Power over Ethernet nicht zuverlässig funktioniert,
- eine Glasfaserverbindung zu hohe Dämpfung aufweist,
- eine Netzwerkdose nicht eindeutig zugeordnet werden kann,
- ein WLAN durch nicht sichtbare Funkquellen gestört wird,
- ein Server über das normale Netzwerk nicht mehr erreichbar ist,
- ein Kabel- oder Hardwarefehler von einem Konfigurationsfehler getrennt werden muss.
> Ein Messgerät liefert Messwerte und Beobachtungen. Die Ursache ergibt sich erst aus der Verbindung zwischen Symptom, Messpunkt, Referenzwert, Vergleichsmessung und technischer Dokumentation.
---
**1. Sicherheits- und Freigaberegeln**
Vor jeder physischen Messung müssen geklärt werden:
- Darf die Verbindung unterbrochen werden?
- Handelt es sich um eine produktive Verbindung?
- Besteht eine redundante Verbindung?
- Kann das Abziehen eines Kabels einen Failover auslösen?
- Wird über das Kabel gleichzeitig Strom übertragen?
- Handelt es sich um Kupfer, Glasfaser oder eine andere Leitung?
- Ist das Messgerät für den Anschluss und den Messbereich geeignet?
- Muss persönliche Schutzausrüstung verwendet werden?
- Sind elektrische Arbeiten einer Elektrofachkraft vorbehalten?
- Können durch die Messung vertrauliche Daten erfasst werden?
- Muss der ursprüngliche Zustand fotografiert oder dokumentiert werden?
- Ist eine Änderung oder Wartungsfreigabe erforderlich?
**Grundregeln**
- Kabel und Module vor dem Entfernen eindeutig kennzeichnen.
- Vorher- und Nachher-Zustand dokumentieren.
- Nur geeignete und unbeschädigte Messleitungen verwenden.
- Messgeräte nicht ungeprüft an unbekannte Spannungsquellen anschließen.
- Glasfaserstecker nicht mit bloßem Auge betrachten.
- Aktive Glasfaser kann unsichtbare Laserstrahlung führen.
- Optische Anschlüsse vor dem Verbinden inspizieren und erforderlichenfalls fachgerecht reinigen.
- Multimeter nur durch dafür qualifizierte Personen und im zulässigen Einsatzbereich verwenden.
- Produktive Leitungen nicht ohne Prüfung mit einem Tongenerator, Kabeltester oder Loopback-Stecker verbinden.
- Messergebnisse zusammen mit Zeitpunkt, Messpunkt, Geräteeinstellung und Grenzwert dokumentieren.
---
**2. Sichtprüfung vor dem Einsatz eines Messgeräts**
Eine systematische Sichtprüfung kann bereits viele Fehler erkennen.
Zu prüfen sind:
- geknickte oder gequetschte Kabel,
- beschädigte Isolierung,
- zu enge Biegeradien,
- Zugbelastung,
- beschädigte Rastnasen,
- lockere Steckverbindungen,
- verschmutzte Anschlüsse,
- verbogene Kontakte,
- ungeeignete Kupplungen oder Adapter,
- Korrosion,
- Feuchtigkeit,
- übermäßige Wärme,
- beschädigte Patchfelder,
- unvollständige Auflegung,
- falsche Beschriftung,
- falsch eingesetzte Transceiver,
- unterschiedliche Fasertypen,
- ungeeignete Patchkabel,
- blockierte Lüftungsöffnungen,
- ausgefallene Lüfter,
- Warnanzeigen an Netzteilen oder Geräten.
**LED-Anzeigen einordnen**
| Anzeige | mögliche Bedeutung |
|---|---|
| keine Link-LED | kein Signal, Gegenstelle aus, falsches Medium, Kabel- oder Portfehler |
| Link vorhanden, keine Aktivität | keine Datenübertragung oder nur momentan kein Verkehr |
| ständig hohe Aktivität | starke Auslastung, Schleife, Broadcastlast oder normaler hoher Verkehr |
| orange beziehungsweise gelbe LED | herstellerabhängig: Geschwindigkeit, Warnung, Blockierung oder Fehler |
| wechselnde Farben | herstellerabhängiger Status oder ausgehandelte Geschwindigkeit |
| PoE-Fehleranzeige | Leistungsbudget, Klassifizierung, Kurzschluss oder inkompatibles Gerät |
> LED-Farben und Blinkmuster sind nicht herstellerübergreifend standardisiert. Ihre Bedeutung muss in der Dokumentation des konkreten Geräts geprüft werden.
---
**3. Ersatzkabel bekannter Qualität**
Ein geprüftes Ersatzkabel ist eines der wichtigsten Diagnosemittel.
Es eignet sich für den kontrollierten Vergleich von:
- Patchkabeln,
- USB-Kabeln,
- Konsolenkabeln,
- Stromkabeln,
- Glasfaser-Patchkabeln,
- DAC-Kabeln,
- Adapterkabeln.
Das Ersatzkabel muss:
- zum Anschluss passen,
- für die benötigte Geschwindigkeit geeignet sein,
- die erforderliche Kategorie oder Spezifikation erfüllen,
- die richtige Belegung besitzen,
- bei Glasfaser den richtigen Fasertyp und Steckertyp verwenden,
- bei USB Datenübertragung und nicht nur Laden unterstützen,
- selbst geprüft und eindeutig gekennzeichnet sein.
**Vorgehensweise**
1. Ausgangszustand dokumentieren.
2. betroffene Verbindung eindeutig bestimmen.
3. nur das verdächtige Kabel austauschen.
4. alle übrigen Komponenten unverändert lassen.
5. Funktion erneut prüfen.
6. ursprüngliches Kabel bei Bedarf separat testen.
7. Ergebnis dokumentieren.
**Einordnung**
| Ergebnis | mögliche Schlussfolgerung |
|---|---|
| Fehler verschwindet mit Ersatzkabel | ursprüngliches Kabel oder dessen Steckkontakt ist verdächtig |
| Fehler bleibt unverändert | Ursache liegt möglicherweise an Port, Gerät, Konfiguration oder weiterem Leitungsweg |
| Fehler tritt nur bei Bewegung auf | Kabelbruch, Steckkontakt oder Zugbelastung möglich |
| niedrigere Geschwindigkeit funktioniert | Signalqualität, Kabelkategorie, Adernpaar oder Transceiver möglich |
| Ersatzkabel funktioniert nur an anderem Port | Port- oder Konfigurationsproblem möglich |
> Ein funktionierendes Ersatzkabel beweist nicht automatisch, dass die gesamte feste Gebäudeverkabelung fehlerfrei ist.
---
**4. Einfacher Kupfer-Kabeltester**
Ein einfacher Kabeltester prüft vor allem die elektrische Verbindung und die Aderzuordnung eines Kupferkabels.
Typische Prüfungen sind:
- Durchgang,
- Unterbrechung,
- Kurzschluss,
- vertauschte Adern,
- gekreuzte Adern,
- Split Pair,
- Schirmverbindung,
- Länge oder ungefähre Fehlerentfernung bei höherwertigen Geräten.
**Typische Fehlerbilder**
| Messergebnis | Bedeutung |
|---|---|
| Open | mindestens eine Ader ist unterbrochen |
| Short | unerwünschte elektrische Verbindung zwischen Adern |
| Reversed | Adern eines Paares sind vertauscht |
| Crossed | Adern beziehungsweise Paare sind falsch zugeordnet |
| Split Pair | Pinbelegung kann logisch richtig erscheinen, aber die Adern stammen aus falschen verdrillten Paaren |
| Shield Open | Schirmverbindung ist unterbrochen |
| Length Error | gemessene Länge oder Fehlerentfernung ist unplausibel |
**Grenzen eines einfachen Kabeltesters**
Ein bestandener Wiremap-Test bestätigt nicht automatisch:
- die geforderte Kabelkategorie,
- ausreichende Signalqualität,
- geringe Dämpfung,
- ausreichende Nebensprechdämpfung,
- fehlerfreien Betrieb bei hoher Datenrate,
- zuverlässige PoE-Übertragung unter Last,
- korrekte Qualität aller Steck- und Anschlussstellen.
Ein Kabel kann bei 100 Mbit/s funktionieren und bei 1, 2,5, 5 oder 10 Gbit/s fehlschlagen.
---
**5. Verification, Qualification und Certification**
Bei Kupferverkabelung müssen drei Prüfklassen unterschieden werden.
| Prüfklasse | Zweck | typische Aussage |
|---|---|---|
| Verification | Verdrahtung und grundlegende physische Fehler prüfen | Adern korrekt verbunden oder Fehler vorhanden |
| Qualification | Eignung für bestimmte Netzwerktechnik untersuchen | Verbindung unterstützt wahrscheinlich eine bestimmte Ethernet-Anwendung |
| Certification | Verkabelung gegen definierte Norm- und Kategoriegrenzen messen | Permanent Link oder Channel besteht beziehungsweise besteht nicht |
**Verification**
Geeignet für:
- schnelle Fehlersuche,
- Wiremap,
- Kabellänge,
- Kurzschluss,
- Unterbrechung,
- Split Pair,
- Zuordnung einer Leitung.
**Qualification**
Kann zusätzlich untersuchen:
- mögliche Netzwerkgeschwindigkeit,
- Signalqualität,
- Paketübertragung,
- Linkfähigkeit,
- teilweise PoE-Eigenschaften.
**Certification**
Ein Kabelzertifizierer misst abhängig von Norm, Adapter und Messaufbau unter anderem:
- Wiremap,
- Länge,
- Einfügedämpfung,
- Laufzeit,
- Laufzeitunterschied,
- Gleichstromwiderstand,
- Widerstandsunsymmetrie,
- Near-End Crosstalk,
- Power Sum NEXT,
- Return Loss,
- Attenuation-to-Crosstalk Ratio,
- Alien Crosstalk bei entsprechenden Prüfungen.
> Ein einfacher Kabeltester ersetzt keinen normgerechten Kabelzertifizierer.
---
**6. Kabelzertifizierer**
Ein Kabelzertifizierer wird verwendet, wenn nachgewiesen werden muss, ob eine installierte Verkabelung eine bestimmte Kategorie, Klasse oder Anwendung erfüllt.
Vor der Messung müssen festgelegt werden:
- Kupfer- oder Glasfasermessung,
- Verkabelungsstandard,
- Kabelkategorie,
- Permanent Link oder Channel,
- verwendete Adapter,
- erwartete NVP,
- geschirmte oder ungeschirmte Verkabelung,
- Grenzwert,
- Anschlussbezeichnung,
- Messrichtung,
- Kalibrierungsstatus des Geräts.
**Permanent Link und Channel**
| Messaufbau | umfasst typischerweise |
|---|---|
| Permanent Link | fest installierte Verkabelung zwischen den Anschlussstellen |
| Channel | gesamte Übertragungsstrecke einschließlich Patchkabeln und Steckverbindungen |
Die Messergebnisse verschiedener Aufbauten dürfen nicht ohne Berücksichtigung der verwendeten Adapter und Grenzwerte miteinander verglichen werden.
**Bei einem fehlgeschlagenen Test dokumentieren**
- betroffene Leitung,
- verwendeter Standard,
- Messaufbau,
- fehlgeschlagener Einzelwert,
- Grenzwert,
- Abstand zum Grenzwert,
- Fehlerentfernung,
- Messrichtung,
- verwendete Adapter,
- Datum der letzten Kalibrierung,
- gespeicherten Messbericht.
**Typische Ursachen eines nicht bestandenen Zertifizierungstests**
- schlechte Auflegung,
- zu weit aufgedrehte Adernpaare,
- ungeeignete Anschlussmodule,
- beschädigtes Kabel,
- zu große Kabellänge,
- ungeeignete Patchkabel,
- schlechte Schirmung oder Erdung,
- falsche Messadapter,
- falscher Messstandard,
- Störungen durch benachbarte Leitungen,
- ungeeignete Kombination verschiedener Komponenten.
---
**7. TDR für Kupferleitungen**
Ein Time Domain Reflectometer sendet einen Impuls in eine Leitung und wertet Reflexionen aus. Dadurch können Änderungen der elektrischen Eigenschaften entlang eines Kabels lokalisiert werden.
Ein TDR kann je nach Gerät Hinweise liefern auf:
- Leitungsende,
- Unterbrechung,
- Kurzschluss,
- Beschädigung,
- schlechte Verbindung,
- Impedanzänderung,
- Abzweigung,
- ungefähre Entfernung zur Fehlerstelle.
**Vereinfachtes Prinzip**
```text
Messgerät
→ elektrischer Impuls
→ Ausbreitung im Kabel
→ Reflexion an einer Störstelle
→ Berechnung der Entfernung aus der Laufzeit
```
Die Entfernungsberechnung hängt von der Ausbreitungsgeschwindigkeit des Kabels ab. Häufig wird dafür der NVP-Wert verwendet.
**NVP**
NVP steht für Nominal Velocity of Propagation und beschreibt die Signalausbreitung im Verhältnis zur Lichtgeschwindigkeit.
Ein falscher NVP-Wert führt zu einer falschen Entfernungsangabe.
**Einordnung typischer Reflexionen**
| Beobachtung | mögliche Ursache |
|---|---|
| starke Reflexion am Leitungsende | offenes Ende oder Abschluss |
| starke Reflexion vor erwartetem Ende | Unterbrechung oder beschädigte Verbindung |
| Reflexion mit entgegengesetzter Charakteristik | Kurzschluss oder starke Impedanzänderung |
| mehrere Reflexionen | mehrere Steckstellen, Abzweigungen oder Beschädigungen |
| unplausible Entfernung | falscher NVP, falscher Kabeltyp oder komplexer Leitungsweg |
> Ein TDR lokalisiert eine elektrische Auffälligkeit. Es zeigt nicht automatisch, welches Bauteil dort tatsächlich beschädigt ist.
---
**8. Tongenerator und Leitungssucher**
Ein Tongenerator speist ein Suchsignal in eine Leitung ein. Ein Leitungssucher beziehungsweise eine induktive Prüfsonde hilft, dieses Signal an Kabeln, Patchfeldern oder Anschlussdosen zu erkennen.
Geeignet für:
- unbekannte Kabelwege,
- nicht dokumentierte Anschlussdosen,
- Zuordnung zwischen Dose und Patchfeld,
- Identifikation einzelner Leitungen in einem Bündel,
- grundlegende Durchgangsprüfung bei geeigneten Geräten.
**Sichere Vorgehensweise**
1. Leitung eindeutig bestimmen.
2. prüfen, ob sie aktiv ist oder Spannung führt.
3. Gerätespezifikation beachten.
4. Tongenerator passend anschließen.
5. Signal am vermuteten Leitungsweg verfolgen.
6. mehrere mögliche Leitungen vergleichen.
7. Leitung anschließend eindeutig beschriften.
8. Dokumentation aktualisieren.
**Grenzen**
- Nebensprechen kann das Signal auf benachbarte Kabel übertragen.
- ein starkes Signal beweist nicht immer die exakte Leitung.
- abgeschirmte Kabel können die Ortung beeinflussen.
- aktive Netzwerkverbindungen benötigen dafür geeignete Geräte.
- unbekannte elektrische Leitungen dürfen nicht ungeprüft angeschlossen werden.
- der Tongenerator bestätigt keine Ethernet-Leistungsfähigkeit.
---
**9. Port- und Leitungslokalisierung über Link Blink**
Einige Netzwerkprüfgeräte können den Link am Switchport gezielt auf- und abbauen oder ein Blinkmuster erzeugen.
Damit kann ein Administrator einen physischen Port identifizieren, ohne ausschließlich den Leitungsweg mit einem Tongenerator zu verfolgen.
**Zu beachten**
- Das Blinkmuster muss von einer zweiten Person oder Kamera am Switch beobachtet werden.
- Ein produktiver Link kann dabei kurzzeitig unterbrochen werden.
- Bei Link Aggregation, redundanten Pfaden oder Telefonen mit nachgeschaltetem PC können Nebenwirkungen entstehen.
- Link Blink beweist lediglich die Zuordnung zum Port, nicht die Fehlerfreiheit des Kabels.
- Switchport-Beschreibung, MAC-Tabelle und LLDP sollten zusätzlich geprüft werden.
---
**10. Loopback-Stecker**
Ein Loopback-Stecker führt Sende- und Empfangssignale an einer Schnittstelle kontrolliert zurück.
Mögliche Varianten existieren unter anderem für:
- Ethernet,
- serielle Schnittstellen,
- Glasfaser,
- USB,
- herstellerspezifische Diagnoseanschlüsse.
**Mögliche Einsatzzwecke**
- Schnittstelle lokal prüfen,
- Sende- und Empfangspfad testen,
- Diagnosefunktion eines Geräts ausführen,
- Port von Kabelweg und Gegenstelle trennen,
- Transceiver oder Adapter untersuchen.
**Risiken**
- Ein ungeeigneter Loopback-Stecker kann eine Schnittstelle beschädigen.
- Eine Netzwerkschleife kann entstehen.
- Spanning Tree kann reagieren.
- ein Port kann durch Schutzmechanismen deaktiviert werden.
- reflektierter Verkehr kann CPU- oder Netzlast erzeugen.
- optische Loopbacks müssen zum Fasertyp, Anschluss und Leistungsbereich passen.
> Loopback-Stecker dürfen nur nach Herstelleranleitung und mit eindeutiger Zuordnung verwendet werden.
---
**11. Vergleichshardware**
Vergleichshardware hilft dabei, einen Fehler auf Gerät, Adapter, Kabel, Port oder Konfiguration einzugrenzen.
Geeignet sind beispielsweise:
- geprüfter USB-Netzwerkadapter,
- geprüfter USB-Hub,
- geprüfter SFP- oder SFP+-Transceiver,
- geprüfter Medienkonverter,
- geprüfter PoE-Injektor,
- geprüfter Access Point,
- geprüfter Switch,
- geprüfter Laptop,
- geprüftes Netzteil,
- geprüfter Konsolenadapter.
**Kontrollierter Vergleich**
1. nur eine Komponente verändern,
2. kompatible Vergleichshardware verwenden,
3. Versions- und Treiberunterschiede dokumentieren,
4. identische Verbindung erneut testen,
5. Ergebnis mit dem Ausgangszustand vergleichen,
6. ursprüngliche Komponente separat untersuchen.
**Fehlinterpretationen vermeiden**
| Ergebnis | Einordnung |
|---|---|
| anderer Adapter funktioniert | ursprünglicher Adapter, Treiber oder dessen Kompatibilität ist verdächtig |
| anderer Laptop funktioniert | Fehler kann am ersten Client liegen, muss aber nicht ausschließlich Hardware sein |
| anderer Port funktioniert | ursprünglicher Port oder dessen Konfiguration ist verdächtig |
| anderer Transceiver funktioniert | ursprünglicher Transceiver oder dessen Kompatibilität ist verdächtig |
| Ersatznetzteil funktioniert | ursprüngliches Netzteil oder dessen Leistungsabgabe ist verdächtig |
---
**12. PoE-Tester**
Ein PoE-Tester untersucht Power over Ethernet zwischen Power Sourcing Equipment und Powered Device.
**Begriffe**
| Begriff | Bedeutung |
|---|---|
| PSE | stellt PoE-Leistung bereit, beispielsweise Switch oder Injektor |
| PD | empfängt PoE-Leistung, beispielsweise Access Point, Kamera oder Telefon |
| Endspan | PoE wird direkt durch den Switch bereitgestellt |
| Midspan | PoE wird durch einen zwischengeschalteten Injektor bereitgestellt |
| PoE-Klasse | handelt beziehungsweise beschreibt den Leistungsbedarf |
| PoE-Budget | insgesamt verfügbare Leistung eines Switches |
Je nach Messgerät können untersucht werden:
- ob PoE vorhanden ist,
- verwendetes Adernpaar,
- Spannung,
- Klasse,
- angeforderte Leistung,
- verfügbare Leistung,
- Leistungsabgabe unter Last,
- Erkennung des PSE,
- Ethernet-Link,
- Switch- und VLAN-Informationen.
**Typische PoE-Probleme**
- PoE auf dem Port deaktiviert,
- Gesamtbudget des Switches erschöpft,
- falsche oder nicht unterstützte PoE-Klasse,
- hohe Leitungswiderstände,
- Widerstandsunsymmetrie,
- beschädigte Adernpaare,
- schlechte Auflegung,
- zu lange oder ungeeignete Verkabelung,
- inkompatibler passiver PoE-Injektor,
- nur bestimmte Ports unterstützen PoE,
- Gerät benötigt mehr Leistung als verfügbar,
- Leistung bricht erst unter Last zusammen,
- Port wurde durch Schutzmechanismus abgeschaltet.
**PoE-Prüfreihenfolge**
1. Leistungsanforderung des Endgeräts bestimmen.
2. unterstützten PoE-Standard des Switches prüfen.
3. PoE-Konfiguration und Gesamtbudget kontrollieren.
4. Messung direkt am Switchport durchführen.
5. Messung an der entfernten Netzwerkdose durchführen.
6. Spannungs- und Leistungsunterschied vergleichen.
7. Kabel auf Wiremap und Widerstandsprobleme prüfen.
8. Endgerät mit geprüftem Kabel und geeignetem PSE testen.
9. Ereignisprotokolle und Portstatus untersuchen.
> Eine Leerlaufspannung bestätigt nicht, dass unter realer Last ausreichend Leistung zur Verfügung steht.
---
**13. Passive PoE-Verbindungen**
Passives PoE verwendet möglicherweise dauerhaft anliegende Spannung ohne standardisierte Aushandlung.
Risiken sind:
- Beschädigung nicht geeigneter Geräte,
- falsche Spannung,
- falsche Polarität,
- falsche Pinbelegung,
- Verwechslung mit standardisiertem IEEE-PoE,
- fehlende Schutzmechanismen.
Vor dem Anschließen müssen geprüft werden:
- Herstellerdokumentation,
- Spannung,
- Polarität,
- Pinbelegung,
- maximaler Strom,
- Kompatibilität des Endgeräts,
- Eignung des Messgeräts.
> Passives PoE darf nicht allein anhand eines identischen RJ45-Steckers als kompatibel betrachtet werden.
---
**14. Multimeter**
Ein Multimeter kann abhängig von Gerät, Messleitungen und Qualifikation unter anderem messen:
- Spannung,
- Strom,
- Widerstand,
- Durchgang,
- teilweise Frequenz,
- teilweise Kapazität.
Mögliche IT-nahe Einsatzbereiche sind:
- Prüfung eines geeigneten Kleinspannungsnetzteils,
- Kontrolle dokumentierter Gleichspannungen,
- Durchgangsprüfung an spannungsfreien Leitungen,
- Untersuchung einer vorgesehenen Erdungs- oder Schirmverbindung,
- Vergleich einer gemessenen Ausgangsspannung mit der Herstellerangabe.
**Gefahren**
- falscher Messbereich,
- Messleitung in falscher Buchse,
- Strommessung parallel zur Spannungsquelle,
- Messung an Netzspannung ohne Qualifikation,
- ungeeignete Messkategorie,
- beschädigte Messleitungen,
- Kurzschluss durch Prüfspitzen,
- Messung an unbekannten Stromkreisen,
- unzulässige Öffnung von Geräten oder Netzteilen.
**Verbindliche Begrenzung**
Multimeter dürfen nur durch dafür qualifizierte Personen, mit geeignetem Messgerät und innerhalb des zulässigen Einsatzbereichs verwendet werden.
> Ein IT-Administrator sollte keine Arbeiten an Netzspannung, Stromverteilungen oder geöffneten Netzteilen durchführen, wenn dafür die elektrotechnische Qualifikation und Freigabe fehlen.
---
**15. Netzteil- und Stromversorgungsprüfung**
Viele scheinbare Netzwerk- oder Gerätefehler entstehen durch die Stromversorgung.
Zu prüfen sind:
- sitzt der Netzstecker vollständig?
- ist die Steckdosenleiste eingeschaltet?
- zeigt die USV einen Alarm?
- ist das richtige Netzteil angeschlossen?
- stimmen Ausgangsspannung, Strombelastbarkeit und Polarität?
- ist das Netzteil ungewöhnlich warm?
- treten Neustarts nur unter Last auf?
- funktionieren redundante Netzteile?
- sind beide Netzteile tatsächlich an getrennte Strompfade angeschlossen?
- bestehen Ereignisse zu Unterspannung oder Stromverlust?
- ist der PoE-Port ausreichend dimensioniert?
- sind Sicherungen oder Schutzschalter ausgelöst?
**Typische Fehlerbilder**
| Beobachtung | mögliche Ursache |
|---|---|
| Gerät startet wiederholt neu | instabiles Netzteil, Überlast, Temperatur oder Hardwarefehler |
| Gerät funktioniert ohne Zusatzmodule | Netzteil zu schwach oder defektes Modul |
| redundante Netzteile angezeigt, aber nur ein Stromkreis | keine vollständige Stromredundanz |
| Fehler nur bei hoher Last | Spannungseinbruch, Leistungsgrenze oder Kühlungsproblem |
| USV meldet Batteriebetrieb | Stromversorgung vor der USV oder Netzqualität prüfen |
| Gerät bleibt nach Stromausfall aus | Startverhalten, Netzteil, USV oder Hardwarezustand |
---
**16. Glasfaser-Grundlagen für die Messung**
Vor einer Glasfasermessung müssen bekannt sein:
- Singlemode oder Multimode,
- Faserkategorie,
- Wellenlänge,
- Steckertyp,
- Schliffart,
- Sendeleistung,
- zulässiger Empfangsbereich,
- Linkbudget,
- Anzahl der Steckverbindungen,
- Anzahl der Spleiße,
- Streckenlänge,
- erwartete Dämpfung,
- verwendete Transceiver.
**Häufige Steckertypen**
- LC,
- SC,
- ST,
- MPO beziehungsweise MTP.
**Wichtige Unterscheidungen**
- Singlemode und Multimode dürfen nicht beliebig kombiniert werden.
- UPC- und APC-Schliffe dürfen nicht direkt miteinander verbunden werden.
- unterschiedliche Wellenlängen führen zu unterschiedlichen Messwerten.
- optische Pegel werden häufig in dBm angegeben.
- Verlust beziehungsweise Dämpfung wird häufig in dB angegeben.
**dBm und dB**
| Einheit | Bedeutung |
|---|---|
| dBm | absoluter optischer Leistungspegel bezogen auf 1 mW |
| dB | Verhältnis beziehungsweise Verlust zwischen zwei Pegeln |
> Ein Wert von `-10 dBm` ist kein Verlust von `-10 dB`. Absoluter Pegel und Streckendämpfung müssen getrennt behandelt werden.
---
**17. Glasfaser inspizieren und reinigen**
Verschmutzte Steckerendflächen gehören zu den häufigsten Ursachen optischer Probleme.
Mögliche Verunreinigungen sind:
- Staub,
- Hautfett,
- Reinigungsrückstände,
- Abrieb,
- Feuchtigkeit,
- Schmutz aus Schutzkappen.
**Grundregel**
```text
inspizieren
→ bei Bedarf reinigen
→ erneut inspizieren
→ erst danach verbinden
```
Benötigte Werkzeuge können sein:
- geeignetes Glasfaser-Inspektionsmikroskop,
- Videosonde,
- passende Adapterspitzen,
- fusselfreie Reinigungstücher,
- geeignete Reinigungsflüssigkeit,
- One-Click-Reiniger,
- Reinigungswerkzeuge für MPO/MTP,
- saubere Schutzkappen.
**Wichtige Regeln**
- niemals in eine aktive Glasfaser blicken,
- vor der Inspektion Aktivität beziehungsweise Laserquelle sicher berücksichtigen,
- keine ungeeigneten Haushaltsreiniger verwenden,
- Stecker nicht mit Kleidung oder Fingern reinigen,
- gereinigte Endflächen nicht berühren,
- auch werksseitig konfektionierte Stecker vor dem Verbinden prüfen,
- Adapter und Messleitungen ebenfalls kontrollieren,
- verschmutzte Schutzkappen nicht wiederverwenden.
> Eine verschmutzte Endfläche kann nicht nur die Messung verfälschen, sondern beim Verbinden auch die Gegenseite verschmutzen oder beschädigen.
---
**18. Visual Fault Locator**
Ein Visual Fault Locator speist sichtbares rotes Licht in eine Glasfaser ein.
Er kann helfen bei:
- Identifikation einer Faser,
- Polaritätsprüfung,
- Erkennung grober Unterbrechungen,
- Auffinden starker Biegungen,
- Erkennung schlechter Steckverbindungen,
- Untersuchung kurzer Leitungsabschnitte.
**Grenzen**
- nicht jede Beschädigung wird sichtbar,
- lange Strecken können das sichtbare Licht stark dämpfen,
- Kabelummantelung kann austretendes Licht verdecken,
- ein sichtbarer Lichtaustritt lokalisiert nicht automatisch die genaue Fehlerursache,
- ein VFL ersetzt keine Dämpfungsmessung,
- ein VFL ersetzt kein OTDR,
- Laserklassifizierung und Sicherheitsregeln müssen beachtet werden.
---
**19. Optischer Leistungsmesser**
Ein optischer Leistungsmesser misst den empfangenen optischen Pegel.
Vor der Messung müssen bekannt sein:
- Wellenlänge,
- zulässiger Empfangsbereich,
- verwendeter Anschlussadapter,
- erwarteter Sendepegel,
- Empfindlichkeit und Übersteuerungsgrenze des Empfängers,
- Referenzwert,
- Fasertyp.
**Mögliche Ergebnisse**
| Messwert | Einordnung |
|---|---|
| innerhalb des zulässigen Bereichs | Pegel ist grundsätzlich geeignet |
| unterhalb der Empfindlichkeitsgrenze | Signal zu schwach |
| oberhalb der Übersteuerungsgrenze | Signal zu stark |
| stark schwankender Pegel | instabile Quelle, Stecker, Faser oder Bewegung |
| kein Pegel | falsche Faser, Sender aus, Unterbrechung oder falsche Wellenlänge |
| Pegel ausreichend, Link bleibt down | Ursache kann Transceiver, Protokoll, Geschwindigkeit oder Gegenstelle sein |
**Typische Ursachen für zu geringe Leistung**
- verschmutzte Endfläche,
- beschädigtes Patchkabel,
- zu viele Steckverbindungen,
- ungeeigneter Spleiß,
- Makro- oder Mikrobiegung,
- falsche Faser,
- falscher Transceiver,
- zu große Streckenlänge,
- schwache Sendeleistung,
- ungeeignete Wellenlänge.
---
**20. Optical Loss Test Set**
Ein Optical Loss Test Set besteht typischerweise aus Lichtquelle und Leistungsmesser. Es bestimmt die Einfügedämpfung einer Glasfaserstrecke.
**Vereinfachtes Verfahren**
```text
Referenzmessung
→ Messleitungen und Lichtquelle referenzieren
→ zu prüfende Strecke einfügen
→ empfangenen Pegel messen
→ Verlust bestimmen
→ mit Grenzwert vergleichen
```
Vorher festzulegen sind:
- Fasertyp,
- Wellenlänge,
- Referenzmethode,
- Anzahl der Test-Referenzkabel,
- Steckertyp,
- Messrichtung,
- Grenzwert,
- erwartete Linkdämpfung.
**Fehlerquellen bei der Messung**
- verschmutzte Referenzkabel,
- beschädigte Messadapter,
- falsche Referenzmethode,
- Bewegung der Testleitungen,
- falsche Wellenlänge,
- unterschiedliche Steckerschliffe,
- nicht stabilisierte Lichtquelle,
- falscher Nullabgleich,
- vertauschte Polarität,
- unterschiedliche Messaufbauten.
> Eine Messung ist nur dann vergleichbar, wenn Referenzmethode, Wellenlänge, Messleitungen und Grenzwerte dokumentiert wurden.
---
**21. OTDR für Glasfaser**
Ein Optical Time Domain Reflectometer sendet optische Impulse in eine Faser und wertet das zurückgestreute beziehungsweise reflektierte Licht über die Zeit aus.
Ein OTDR kann je nach Gerät darstellen:
- Faserlänge,
- Steckverbindungen,
- Spleiße,
- Reflexionsereignisse,
- nicht reflektierende Ereignisse,
- Dämpfung einzelner Abschnitte,
- Gesamtdämpfung,
- Unterbrechung,
- ungefähre Entfernung zur Fehlerstelle.
**Vereinfachte Darstellung**
```text
OTDR
→ optischer Impuls
→ Rückstreuung entlang der Faser
→ Reflexionen an Ereignissen
→ Ereignistabelle und Kurve
```
**Launch- und Receive-Faser**
Eine Vorlauffaser kann erforderlich sein, um:
- den ersten Anschluss außerhalb der Totzone zu messen,
- den Eingangsstecker zu beurteilen,
- einen realistischen Leitungsanfang darzustellen.
Eine Nachlauffaser kann erforderlich sein, um:
- den letzten Anschluss zu beurteilen,
- das Ende der Strecke korrekt auszuwerten.
**Wichtige OTDR-Einstellungen**
- Wellenlänge,
- Messbereich,
- Pulsbreite,
- Messdauer,
- Brechungsindex,
- Rückstreukoeffizient,
- Ereignisschwelle,
- Fasertyp.
**Einfluss der Pulsbreite**
| Einstellung | Vorteil | Nachteil |
|---|---|---|
| kurze Pulsbreite | bessere Auflösung nahe beieinanderliegender Ereignisse | geringere Reichweite und schwächeres Signal |
| lange Pulsbreite | größere Reichweite und besserer Dynamikbereich | größere Totzonen und geringere Ereignisauflösung |
**Grenzen**
- nahe Ereignisse können in einer Totzone liegen,
- Reflexionen können Geisterereignisse erzeugen,
- falsche Einstellungen führen zu falscher Entfernung oder Dämpfung,
- bidirektionale Messungen können für belastbare Bewertung erforderlich sein,
- ein OTDR ersetzt nicht automatisch eine normgerechte Einfügedämpfungsmessung,
- Bedienung und Kurveninterpretation erfordern Fachkenntnisse.
---
**22. SFP- und Transceiver-Diagnose**
Viele Transceiver unterstützen Digital Optical Monitoring beziehungsweise Digital Diagnostic Monitoring.
Mögliche Werte sind:
- Temperatur,
- Versorgungsspannung,
- Sendeleistung,
- Empfangsleistung,
- Laser-Bias-Strom,
- Warn- und Alarmgrenzen.
**Beispielhafte Einordnung**
| Beobachtung | mögliche Ursache |
|---|---|
| Empfangsleistung zu niedrig | Dämpfung, Verschmutzung, falsche Faser oder schwacher Sender |
| Empfangsleistung zu hoch | ungeeigneter Transceiver oder fehlendes Dämpfungsglied |
| Sendeleistung außerhalb der Grenze | Transceiverfehler oder Temperaturproblem |
| hohe Temperatur | unzureichende Kühlung, hoher Umgebungswert oder Modulproblem |
| Werte nur auf einer Seite auffällig | Richtung der Faserstrecke gezielt untersuchen |
| keine Diagnosedaten | Modul unterstützt DDM nicht oder Gerät liest es nicht aus |
**Zusätzlich prüfen**
- unterstützter Transceivertyp,
- Herstellerkompatibilität,
- Geschwindigkeit,
- Wellenlänge,
- Singlemode oder Multimode,
- Duplex- oder BiDi-Verfahren,
- Faserpolarität,
- Steckertyp,
- Gegenstellenmodul,
- Fehlerzähler,
- Forward Error Correction,
- verwendete Breakout-Konfiguration.
> Optische Diagnosedaten des Transceivers sind hilfreich, ersetzen aber keine unabhängige Messung bei unklaren oder widersprüchlichen Ergebnissen.
---
**23. WLAN-Spektrumanalysator**
Ein WLAN-Scanner zeigt hauptsächlich WLAN-Netze und deren Protokollinformationen. Ein Spektrumanalysator untersucht dagegen die Hochfrequenzenergie im verwendeten Frequenzbereich und kann auch nicht WLAN-basierte Störquellen sichtbar machen.
**Mögliche Untersuchungen**
- Kanalbelegung,
- Kanalnutzung,
- Störpegel,
- dauerhafte oder periodische Signale,
- Interferenzen,
- überlappende Kanäle,
- nicht WLAN-basierte Sender,
- zeitlicher Verlauf,
- Nutzung der Frequenzbänder 2,4 GHz, 5 GHz oder 6 GHz abhängig vom Gerät.
**Mögliche Störquellen**
- andere WLAN-Netze,
- Bluetooth,
- Funkkameras,
- drahtlose Videoübertragung,
- Mikrowellengeräte,
- fehlerhafte elektrische Geräte,
- bestimmte Sensoren,
- Radarerkennung im 5-GHz-Bereich,
- breitbandige Störsender.
**Messparameter**
- Frequenz,
- Kanal,
- Signalstärke,
- Rauschpegel,
- Kanalnutzung,
- Duty Cycle,
- zeitliches Auftreten,
- Signalbreite,
- räumliche Veränderung.
**Vorgehensweise**
1. betroffenen Ort bestimmen.
2. Zeitpunkt und Symptom dokumentieren.
3. Messung am betroffenen Clientstandort durchführen.
4. Vergleichsmessung an einem funktionierenden Standort durchführen.
5. zeitlichen Verlauf beobachten.
6. Störquelle durch räumliche Messungen eingrenzen.
7. WLAN-Konfiguration und Spektrummessung gemeinsam auswerten.
8. Änderung kontrolliert testen.
9. erneut messen.
> Eine hohe WLAN-Signalstärke bestätigt keine geringe Interferenz und keine gute Signalqualität.
---
**24. WLAN-Site-Survey-Werkzeuge**
Ein Site Survey untersucht die räumliche WLAN-Versorgung.
Mögliche Ergebnisse sind:
- Signalstärke,
- Signal-Rausch-Abstand,
- Kanalnutzung,
- Access-Point-Zuordnung,
- Datenrate,
- Überlappung,
- Roamingbereiche,
- Störquellen,
- erwartete Abdeckung,
- tatsächliche Abdeckung.
**Arten**
| Art | Beschreibung |
|---|---|
| Predictive Survey | rechnerische Planung anhand von Gebäude- und Materialdaten |
| Passive Survey | Empfang und Auswertung vorhandener Funksignale |
| Active Survey | aktive Verbindung und Messung von Netzwerkleistung |
| Spectrum Survey | Untersuchung der Funkenergie einschließlich nicht WLAN-basierter Quellen |
**Zu beachten**
- Grundriss und Maßstab müssen stimmen.
- Wandmaterialien beeinflussen das Ergebnis.
- Möbel, Personen und Türen verändern Funkbedingungen.
- Messgerät und Antennenausrichtung beeinflussen Messwerte.
- verschiedene Clienttypen besitzen unterschiedliche Funkfähigkeiten.
- eine leere Umgebung kann andere Ergebnisse liefern als der spätere Produktivbetrieb.
- Messungen müssen für relevante Frequenzbänder getrennt betrachtet werden.
---
**25. Temperaturmessung und Wärmebildkamera**
Temperaturprobleme können zu instabilen Geräten, Leistungseinbrüchen und vorzeitigem Hardwareausfall führen.
Mögliche Werkzeuge sind:
- interne Temperatursensoren,
- Kontaktthermometer,
- Infrarotthermometer,
- Wärmebildkamera,
- Umgebungssensoren,
- Sensoren im Rack oder Rechenzentrum.
**Zu prüfen sind**
- Lufteinlass- und Auslasstemperatur,
- blockierte Lüftungswege,
- ausgefallene Lüfter,
- falsche Luftstromrichtung,
- Hotspots,
- ungewöhnlich warme Netzteile,
- überhitzte Transceiver,
- Rackposition,
- Umgebungstemperatur,
- Staubbelastung,
- Veränderungen unter Last.
**Grenzen von Infrarotmessungen**
- reflektierende Oberflächen können Messwerte verfälschen,
- Emissionsgrad beeinflusst das Ergebnis,
- Entfernung und Messfleckgröße müssen berücksichtigt werden,
- eine Oberflächentemperatur entspricht nicht automatisch der internen Bauteiltemperatur,
- Vergleichswerte sollten unter ähnlichen Bedingungen erhoben werden.
---
**26. Serielle Konsole**
Eine serielle Konsole ermöglicht lokalen Zugriff, wenn das normale Managementnetz nicht funktioniert.
Mögliche Anschlüsse sind:
- RJ45-Konsole,
- USB-Konsole,
- USB-C-Konsole,
- RS-232,
- herstellerspezifische Konsolenschnittstelle.
Benötigt werden gegebenenfalls:
- passendes Konsolenkabel,
- USB-Seriell-Adapter,
- geeigneter Treiber,
- Terminalprogramm,
- korrekte Übertragungsparameter.
**Typische Parameter**
```text
Geschwindigkeit: 9600 oder herstellerspezifisch
Datenbits: 8
Parität: keine
Stoppbits: 1
Flusssteuerung: keine
```
Die konkreten Werte müssen der Herstellerdokumentation entnommen werden.
**Mögliche Diagnoseinformationen**
- Bootmeldungen,
- Hardwarefehler,
- Dateisystemfehler,
- fehlgeschlagene Module,
- Konfigurationsprobleme,
- Management-IP,
- Recovery-Menü,
- Firmwarestatus.
**Sicherheitsregeln**
- Konsolenzugriff ist privilegierter Zugriff.
- Konsolenkabel und Terminalserver müssen geschützt werden.
- Bootmeldungen können vertrauliche Informationen enthalten.
- Kennwortwiederherstellung kann Konfiguration oder Verfügbarkeit beeinflussen.
- Recovery-Verfahren dürfen nur mit Freigabe durchgeführt werden.
---
**27. Out-of-Band-Management**
Out-of-Band-Management verwendet einen vom normalen Datenpfad getrennten Managementweg.
Beispiele sind:
- Konsolenserver,
- dediziertes Managementnetz,
- Mobilfunkverbindung für Notfallzugriff,
- HPE iLO,
- Dell iDRAC,
- IPMI-basierte Managementcontroller,
- Cisco CIMC,
- KVM over IP.
**Mögliche Funktionen**
- Hardwarezustand anzeigen,
- Sensoren und Ereignisprotokolle prüfen,
- Remote-Konsole öffnen,
- Startvorgang beobachten,
- Gerät kontrolliert ein- oder ausschalten,
- virtuelle Medien bereitstellen,
- Firmware verwalten,
- ausgefallenes Betriebssystem unabhängig untersuchen.
**Sicherheitsanforderungen**
- getrenntes Managementnetz,
- Zugriff nur für berechtigte Administratoren,
- Mehrfaktor-Authentifizierung, sofern unterstützt,
- aktuelle Firmware,
- keine direkte öffentliche Erreichbarkeit,
- sichere Protokolle,
- zentrale Protokollierung,
- individuelle Konten,
- eingeschränkte Firewallregeln,
- Notfallzugriff dokumentieren und testen,
- Standardkennwörter entfernen,
- Zertifikate prüfen.
> Out-of-Band-Management ist kein gewöhnliches Messgerät, aber ein unabhängiger Diagnoseweg zur physischen Hardware und zum Startvorgang.
---
**28. In-Band und Out-of-Band unterscheiden**
| Merkmal | In-Band-Management | Out-of-Band-Management |
|---|---|---|
| Datenpfad | nutzt reguläres Netzwerk | nutzt separaten Managementweg |
| Abhängigkeit vom Betriebssystem | häufig vorhanden | häufig geringer oder keine |
| Zugriff bei Routingfehler | möglicherweise nicht möglich | bei funktionsfähigem OOB-Pfad weiterhin möglich |
| Zugriff während des Bootens | meist eingeschränkt | häufig möglich |
| Risiko | Ausfall des Produktivnetzes blockiert Zugriff | separater Weg muss besonders geschützt werden |
| Beispiele | SSH, HTTPS, SNMP | Konsole, iLO, iDRAC, CIMC, IPMI, Konsolenserver |
Eine physisch vorhandene Managementbuchse bestätigt nicht automatisch, dass ein vollständig unabhängiger Out-of-Band-Pfad aufgebaut wurde.
---
**29. Messgerät selbst überprüfen**
Auch ein Messgerät kann fehlerhaft sein.
Vor wichtigen Messungen prüfen:
- Akkustand,
- Netzteil,
- Firmwarestand,
- Selbsttest,
- Kalibrierungsdatum,
- Messadapter,
- Messleitungen,
- Steckverbinder,
- Referenzkabel,
- richtige Geräteeinstellung,
- richtige Wellenlänge,
- richtiger Kabeltyp,
- richtiger Grenzwert,
- Datum und Uhrzeit,
- Speicherplatz,
- gespeicherte Kunden- oder Projektdaten.
**Kontrollmessung**
Eine Kontrollmessung an einer bekannten, funktionierenden Referenz hilft dabei, Fehler des Messaufbaus zu erkennen.
> Wenn ein unerwartetes Ergebnis große Folgen hätte, sollte es mit einer zweiten Messung, einem anderen Messaufbau oder einem unabhängigen Messgerät bestätigt werden.
---
**30. Kalibrierung und Rückführbarkeit**
Bei Zertifizierungs- und Abnahmemessungen ist die Kalibrierung besonders wichtig.
Zu dokumentieren sind:
- Hersteller und Modell,
- Seriennummer,
- Firmwareversion,
- Kalibrierungsdatum,
- nächster Kalibrierungstermin,
- verwendete Adapter,
- verwendete Referenzleitungen,
- Prüfstandard,
- Messperson,
- Datum und Uhrzeit,
- Messort.
Eine abgelaufene Kalibrierung bedeutet nicht zwangsläufig, dass jeder Messwert falsch ist. Sie kann jedoch die Nachweisbarkeit und Verwendbarkeit der Messergebnisse beeinträchtigen.
---
**31. Messergebnisse dokumentieren**
Eine Messung sollte mindestens folgende Angaben enthalten:
| Feld | Inhalt |
|---|---|
| Ticket oder Vorgang | eindeutige Referenz |
| Datum und Uhrzeit | Zeitpunkt der Messung |
| Messperson | verantwortliche Person |
| Standort | Gebäude, Raum, Rack oder Anschluss |
| Verbindung | Start- und Endpunkt |
| Gerät | Hersteller, Modell und Seriennummer |
| Messgerät | Hersteller, Modell und Seriennummer |
| Kalibrierung | gültig bis beziehungsweise Status |
| Messaufbau | Permanent Link, Channel, direkt am Port oder anderer Aufbau |
| Einstellung | Standard, Wellenlänge, NVP, Pulsbreite oder Messbereich |
| Ausgangszustand | ursprüngliches Symptom |
| Messwert | tatsächliches Ergebnis |
| Grenzwert | erwarteter beziehungsweise zulässiger Wert |
| Maßnahme | kontrollierte Änderung |
| Nachmessung | Ergebnis nach der Maßnahme |
| Anhänge | Fotos, Kurven, Berichte oder Exportdateien |
**Beispiel**
```text
Verbindung: Patchfeld A-17 → Datendose B-204
Symptom: Link fällt mehrmals pro Stunde auf 100 Mbit/s zurück
Messgerät: Kabelzertifizierer, Seriennummer dokumentiert
Messaufbau: Permanent Link
Grenzwert: Cat 6A
Ergebnis: nicht bestanden
Auffälligkeit: NEXT am nahen Anschluss
Fehlerentfernung: innerhalb des Anschlussbereichs
Maßnahme: Anschluss neu aufgelegt
Nachmessung: bestanden
Funktionstest: stabiler 1-Gbit/s-Link, Fehlerzähler steigen nicht weiter
```
---
**32. Messwerte richtig vergleichen**
Vergleichsmessungen sind nur sinnvoll, wenn die Bedingungen vergleichbar sind.
Zu berücksichtigen sind:
- identischer Messpunkt,
- identisches Messgerät,
- identische Adapter,
- identische Geräteeinstellung,
- identische Wellenlänge,
- identischer Kabeltyp,
- gleiche Messrichtung,
- ähnliche Temperatur,
- gleicher Betriebszustand,
- gleiche Last,
- gleicher Zeitraum,
- gleiche Referenzmethode.
**Ungültige Vergleiche**
- dBm und dB direkt gleichsetzen,
- OTDR-Dämpfung ohne Kontext mit OLTS-Messung vergleichen,
- Permanent-Link-Messung mit Channel-Messung gleichsetzen,
- PoE-Leerlaufwert mit Leistung unter Last gleichsetzen,
- WLAN-Messungen an verschiedenen Standorten ohne Positionsangabe vergleichen,
- Messwerte verschiedener Wellenlängen gleichsetzen,
- Kabellängen mit falschem NVP vergleichen.
---
**33. Kontrollierte Prüfreihenfolge bei Kupferproblemen**
1. Symptom und betroffene Verbindung bestimmen.
2. Portstatus und Fehlerzähler dokumentieren.
3. sichtbare Schäden prüfen.
4. Steckverbindungen kontrollieren.
5. geprüftes Patchkabel verwenden.
6. Gegenstelle mit Vergleichshardware testen.
7. Wiremap und Kabellänge prüfen.
8. Fehlerentfernung mit TDR untersuchen.
9. bei Leistungsanforderungen qualifizieren oder zertifizieren.
10. PoE gegebenenfalls unter Last messen.
11. Anschlussstellen und Patchfeld untersuchen.
12. nach jeder Maßnahme erneut messen.
13. Konfiguration und physische Messung gemeinsam bewerten.
14. Ursache und Ergebnis dokumentieren.
---
**34. Kontrollierte Prüfreihenfolge bei Glasfaserproblemen**
1. Fasertyp, Wellenlänge und Transceiver bestimmen.
2. Portstatus und optische Diagnosedaten dokumentieren.
3. richtige Polarität prüfen.
4. Endflächen sicher inspizieren.
5. bei Bedarf reinigen und erneut inspizieren.
6. geprüftes Patchkabel einsetzen.
7. sichtbare Fehlersuche nur mit geeignetem VFL durchführen.
8. optischen Empfangspegel messen.
9. Streckendämpfung mit geeigneter Lichtquelle und Leistungsmesser bestimmen.
10. Ereignisse und Fehlerentfernung bei Bedarf mit OTDR untersuchen.
11. Messung gegebenenfalls in Gegenrichtung wiederholen.
12. Ergebnis mit Linkbudget und Grenzwerten vergleichen.
13. nach jeder Maßnahme erneut messen.
14. Messkurven und Berichte sichern.
---
**35. Praxisbeispiel: Link fällt auf 100 Mbit/s zurück**
**Symptom**
Ein Gigabit-Endgerät verbindet sich nur mit 100 Mbit/s oder wechselt wiederholt zwischen Geschwindigkeiten.
**Prüfung**
1. unterstützte Geschwindigkeiten beider Geräte prüfen.
2. Auto-Negotiation auf beiden Seiten kontrollieren.
3. Portstatus und Fehlerzähler dokumentieren.
4. geprüftes Patchkabel einsetzen.
5. alle vier Adernpaare mit Kabeltester prüfen.
6. feste Gebäudeverkabelung untersuchen.
7. Split Pair, Unterbrechung oder schlechte Auflegung prüfen.
8. Verbindung bei Bedarf qualifizieren oder zertifizieren.
9. Vergleichsport und Vergleichsadapter verwenden.
10. nach der Maßnahme Linkgeschwindigkeit und Fehlerzähler erneut prüfen.
**Mögliche Ursachen**
- ein Adernpaar unterbrochen,
- schlechte Auflegung,
- ungeeignetes Patchkabel,
- beschädigte Dose,
- fehlerhafter Port,
- defekter Netzwerkadapter,
- falsche Konfiguration,
- unzureichende Signalqualität.
---
**36. Praxisbeispiel: PoE-Gerät startet wiederholt neu**
**Symptom**
Ein Access Point oder eine Kamera startet unter Last neu.
**Prüfung**
1. PoE-Anforderung des Geräts bestimmen.
2. unterstützten Standard und Port des Switches prüfen.
3. verfügbares Gesamtbudget kontrollieren.
4. Switchprotokolle untersuchen.
5. Leistung direkt am Switchport prüfen.
6. Leistung an der entfernten Dose unter Last prüfen.
7. Kabelweg und Widerstandsunsymmetrie untersuchen.
8. geprüftes kurzes Kabel verwenden.
9. geeigneten Vergleichsport oder PSE einsetzen.
10. Temperatur und Firmware berücksichtigen.
**Mögliche Ursachen**
- Leistungsbudget erschöpft,
- falsche PoE-Klasse,
- hoher Spannungsabfall,
- beschädigtes Adernpaar,
- schlechte Auflegung,
- ungeeigneter Injektor,
- defektes Endgerät,
- Überhitzung,
- fehlerhafte Switchkonfiguration.
---
**37. Praxisbeispiel: Glasfaserlink bleibt down**
**Prüfung**
1. Transceivertypen auf beiden Seiten vergleichen.
2. Geschwindigkeit und Wellenlänge prüfen.
3. Singlemode beziehungsweise Multimode prüfen.
4. Faserpolarität kontrollieren.
5. Transceiver vollständig einsetzen.
6. optische Diagnosedaten auslesen.
7. Endflächen inspizieren und fachgerecht reinigen.
8. geprüftes Patchkabel verwenden.
9. optischen Pegel messen.
10. Strecke mit OLTS beziehungsweise OTDR untersuchen.
11. Transceiver kontrolliert austauschen.
12. Port- und Gerätekonfiguration prüfen.
**Mögliche Ursachen**
- vertauschte Sende- und Empfangsfaser,
- falscher Transceiver,
- inkompatible Wellenlänge,
- verschmutzte Endfläche,
- beschädigtes Patchkabel,
- zu hohe Dämpfung,
- Unterbrechung,
- Port administrativ deaktiviert,
- unterschiedliche Geschwindigkeit,
- fehlerhafter Transceiver.
---
**38. Praxisbeispiel: WLAN ist nur in einem Raum instabil**
**Prüfung**
1. betroffene Clients und Zeiten bestimmen.
2. Signalstärke und SNR messen.
3. Kanal und Kanalnutzung prüfen.
4. Spektrum am betroffenen Ort untersuchen.
5. Vergleichsmessung außerhalb des Raums durchführen.
6. zeitabhängige Störquelle suchen.
7. Wandmaterialien und Raumaufteilung berücksichtigen.
8. Client mit Vergleichshardware testen.
9. Access-Point-Position und Sendeleistung prüfen.
10. Änderung nur einzeln durchführen und erneut messen.
**Mögliche Ursachen**
- nicht WLAN-basierte Störquelle,
- starke Kanalüberlagerung,
- ungünstige Abschirmung,
- Metallflächen,
- fehlerhafter Clientadapter,
- zu hohe oder zu niedrige Sendeleistung,
- ungeeignete Kanalbreite,
- Roamingproblem,
- hohe Kanalnutzung.
---
**39. Praxisbeispiel: Server ist über das Netzwerk nicht erreichbar**
**Prüfung**
1. Stromversorgung und Statusanzeigen prüfen.
2. Switchport und Kabel untersuchen.
3. Out-of-Band-Management testen.
4. Hardwareereignisse und Sensoren prüfen.
5. Remote-Konsole öffnen.
6. Bootstatus beobachten.
7. Betriebssystem- und Netzwerkzustand prüfen.
8. bei Bedarf geprüftes Kabel und Vergleichsport verwenden.
9. Netzteil- und Temperaturzustand untersuchen.
10. Neustart nur nach Freigabe und Beweissicherung durchführen.
**Mögliche Ergebnisse**
| Ergebnis | Einordnung |
|---|---|
| Out-of-Band erreichbar, Betriebssystem nicht | Betriebssystem, Treiber, Netzwerkdienst oder Konfiguration |
| weder In-Band noch Out-of-Band erreichbar | Stromversorgung, Managementpfad oder Hardware |
| Remote-Konsole zeigt Startfehler | Bootmedium, Dateisystem, Firmware oder Hardware |
| Hardwarestatus zeigt Alarm | betroffene Komponente gezielt untersuchen |
| anderer Switchport funktioniert | ursprünglicher Port oder dessen Konfiguration |
| geprüftes Kabel funktioniert | ursprüngliche Verkabelung verdächtig |
---
**40. Häufige Fehlinterpretationen**
| Aussage | fachliche Einordnung |
|---|---|
| „Der Kabeltester zeigt alle Adern, also ist das Kabel für 10 Gbit/s geeignet.“ | Ein einfacher Wiremap-Test zertifiziert keine Übertragungsleistung. |
| „Mit dem Ersatzkabel funktioniert es, also ist sicher nur das Kabel defekt.“ | Auch ein Steckkontakt oder eine veränderte mechanische Belastung kann beteiligt sein. |
| „PoE-Spannung ist vorhanden, also reicht die Leistung aus.“ | Entscheidend ist die verfügbare Leistung unter Last. |
| „Der optische Pegel ist sichtbar, also ist die Faser in Ordnung.“ | Pegel, Dämpfung, Reflexionen, Polarität und Protokoll müssen getrennt geprüft werden. |
| „Das OTDR zeigt einen Fehler bei 20 Metern, also ist dort sicher das Kabel gebrochen.“ | Die Anzeige beschreibt ein optisches Ereignis; Messparameter und Leitungsweg müssen berücksichtigt werden. |
| „Starke WLAN-Signalstärke bedeutet eine gute Verbindung.“ | Interferenz, SNR, Kanalnutzung und Retries können die Verbindung trotzdem beeinträchtigen. |
| „Die Temperatur fühlt sich normal an.“ | subjektive Wahrnehmung ersetzt keine Messung und keine Herstellergrenze. |
| „Der Managementport ist erreichbar, also ist der Server vollständig in Ordnung.“ | Out-of-Band-Zugriff bestätigt nicht den Zustand des Betriebssystems oder der Anwendung. |
| „Ein Multimeter ist ungefährlich, weil nur Kleinspannung gemessen wird.“ | falsche Bedienung und unbekannte Stromkreise können weiterhin Schäden verursachen. |
| „Ein einmal bestandener Test beweist dauerhaft fehlerfreie Verkabelung.“ | Kabel, Stecker und Umgebungsbedingungen können sich später verändern. |
---
**41. Checkliste physische Messgeräte**
- [ ] betroffene Verbindung und deren Funktion sind bekannt.
- [ ] Wartungs- oder Änderungsfreigabe wurde geprüft.
- [ ] Ausgangszustand wurde dokumentiert.
- [ ] Kabel und Anschlüsse wurden eindeutig beschriftet.
- [ ] Sichtprüfung wurde durchgeführt.
- [ ] geeignetes Messgerät wurde ausgewählt.
- [ ] Messgerät und Adapter sind unbeschädigt.
- [ ] Kalibrierungsstatus wurde geprüft.
- [ ] richtige Messleitungen wurden verwendet.
- [ ] richtige Geräteeinstellung wurde gewählt.
- [ ] Referenzwert und Grenzwert sind bekannt.
- [ ] geprüftes Ersatzkabel ist verfügbar.
- [ ] immer nur eine Komponente wurde verändert.
- [ ] Kupfermessung unterscheidet Verification, Qualification und Certification.
- [ ] TDR-Messung verwendet einen passenden NVP-Wert.
- [ ] PoE wurde bei Bedarf unter Last geprüft.
- [ ] passive PoE-Verbindungen wurden nicht ungeprüft angeschlossen.
- [ ] Multimeter wurde nur durch qualifizierte Personen eingesetzt.
- [ ] Glasfasertyp und Wellenlänge wurden bestimmt.
- [ ] aktive Glasfaser wurde sicher behandelt.
- [ ] Glasfaser wurde inspiziert, gereinigt und erneut inspiziert.
- [ ] optischer Pegel und Streckendämpfung wurden unterschieden.
- [ ] OTDR-Einstellungen und Totzonen wurden berücksichtigt.
- [ ] Launch- und Receive-Faser wurden bei Bedarf verwendet.
- [ ] WLAN-Scanner und Spektrumanalysator wurden unterschieden.
- [ ] Vergleichsmessung wurde unter vergleichbaren Bedingungen durchgeführt.
- [ ] Out-of-Band-Zugriff wurde sicher verwendet.
- [ ] Messwerte, Einstellungen und Messpunkte wurden dokumentiert.
- [ ] Nachmessung nach der Maßnahme wurde durchgeführt.
- [ ] Funktion und mögliche Nebenwirkungen wurden geprüft.
- [ ] Messberichte wurden sicher gespeichert.
---
**42. Schnellreferenz**
| Werkzeug | Hauptzweck | bestätigt nicht automatisch |
|---|---|---|
| geprüftes Ersatzkabel | verdächtiges Kabel kontrolliert vergleichen | Fehlerfreiheit der festen Verkabelung |
| einfacher Kabeltester | Wiremap, Unterbrechung und Kurzschluss prüfen | Einhaltung einer Kabelkategorie |
| Kabelqualifizierer | Eignung für Netzwerkanwendung untersuchen | normgerechte Zertifizierung |
| Kabelzertifizierer | Verkabelung gegen definierte Grenzwerte messen | fehlerfreie Switch- oder Endgeräte |
| TDR | Entfernung zu elektrischer Auffälligkeit bestimmen | genaue mechanische Ursache |
| Tongenerator | Leitung suchen und zuordnen | Ethernet-Leistungsfähigkeit |
| Loopback-Stecker | lokalen Sende- und Empfangspfad prüfen | gesamten Ende-zu-Ende-Pfad |
| PoE-Tester | PoE-Erkennung und Leistung untersuchen | stabile Leistung ohne Lastmessung |
| Multimeter | geeignete elektrische Größen messen | sichere Bedienung ohne Qualifikation |
| Glasfaser-Inspektionssonde | Endflächen untersuchen | optische Dämpfung |
| Visual Fault Locator | grobe Fehler und Faserzuordnung prüfen | normgerechte Streckenqualität |
| optischer Leistungsmesser | absoluten Empfangspegel messen | genaue Position einer Fehlerstelle |
| OLTS | Einfügedämpfung der Strecke messen | genaue Lage einzelner Ereignisse |
| OTDR | Ereignisse und Entfernungen entlang der Faser analysieren | vollständigen Ersatz für OLTS |
| Spektrumanalysator | Funkenergie und Störquellen untersuchen | erfolgreiche WLAN-Anmeldung |
| Wärmebildkamera | Temperaturverteilung sichtbar machen | interne Bauteiltemperatur ohne Einordnung |
| Konsolenkabel | lokalen Gerätezugriff ermöglichen | funktionierendes Netzwerk |
| Out-of-Band-Management | unabhängigen Hardware- und Konsolenzugriff bereitstellen | funktionierendes Betriebssystem |
---
**Merksatz**
> Physische Fehleranalyse beginnt mit Sichtprüfung, Dokumentation und einem kontrollierten Vergleich. Danach wird das passende Messgerät eingesetzt: Kabeltester für Verdrahtung, Zertifizierer für Übertragungsgrenzen, TDR und OTDR für Fehlerentfernungen, Leistungsmesser für optische Pegel, PoE-Tester für Stromversorgung unter realen Bedingungen und Spektrumanalysator für Funkstörungen. Ein einzelner Messwert ersetzt niemals die technische Einordnung und die abschließende Funktionsprüfung.
---
**Quellen und weiterführende Dokumentation**
- [Fluke Networks – Verification, Qualification und Certification unterscheiden](https://www.flukenetworks.com/blog/cabling-chronicles/verification-qualification-certification-which-do-i-need.html)
- [Fluke Networks – Kupfer-Kabelzertifizierung mit der DSX CableAnalyzer-Serie](https://www.flukenetworks.com/datacom-cabling/Versiv/dsx-cableanalyzer-series)
- [Fluke Networks – Versiv Cable Certifier](https://www.flukenetworks.com/products/cabling-certification/cabling-certification-versiv)
- [Fluke Networks – Grundlagen der Netzwerk- und Kabelprüfung](https://www.flukenetworks.com/blog/cabling-chronicles/network-and-cable-testing.html)
- [Fluke Networks – Glasfaser-Messgeräte und Fehlersuche](https://www.flukenetworks.com/expertise/learn-about/fiber-testing)
- [Fluke Networks – Optische Leistungsmesser und Fehlerlokalisierung](https://www.flukenetworks.com/products/installation-and-test/fiber-optic-power-meters-and-fault-locators)
- [Fluke Networks – OLTS und OTDR als vollständige Prüfstrategie](https://www.flukenetworks.com/edocs/olts-otdr-complete-testing-strategy)
- [Fluke Networks – OptiFiber Pro OTDR](https://www.flukenetworks.com/datacom-cabling/fiber-testing/optifiber-pro-otdr)
- [Fluke Networks – Glasfaser inspizieren und reinigen](https://www.flukenetworks.com/edocs/wp-fiber-cleaning-and-inspection-white-paper)
- [Fluke Networks – Grundregel für Glasfaser: inspizieren, reinigen und erneut inspizieren](https://www.flukenetworks.com/blog/cabling-chronicles/golden-rule-fiber-inspection-keeps-times.html)
- [NetAlly – Funktionsweise von Netzwerk-Kabeltestern](https://www.netally.com/general/how-do-network-cable-testers-work/)
- [NetAlly – Häufige PoE-Probleme erkennen](https://www.netally.com/wired-solutions/how-to-find-common-poe-problems/)
- [NetAlly – PoE-Prüfung mit einem tragbaren Netzwerkprüfgerät](https://www.netally.com/tech-tips/how-to-do-an-easy-poe-test-under-10-seconds/)
- [NetAlly – Kabel-, Netzwerk-, WLAN- und Spektrumanalyse](https://www.netally.com/products/)
- [Cisco – Out-of-Band-Management: Best Practices](https://www.cisco.com/c/en/us/solutions/collateral/service-provider/out-of-band-best-practices-wp.html)
- [Cisco – Integrated Management Controller für UCS-C-Series-Server](https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/sw/gui/config/guide/1-0_1x/b_Cisco_UCS_C-Series_Servers_Integrated_Management_Controller_Configuration_Guide_1-0_1x/Cisco_UCS_C-Series_Servers_Integrated_Management_Controller_Configuration_Guide_1-0_1x_chapter1.html)