1.1 Störung strukturiert aufnehmen

Zweck dieser Seite

Diese Seite dient der vollständigen und einheitlichen Aufnahme einer IT-Störung.

Bevor mit der technischen Diagnose begonnen wird, müssen das sichtbare Problem, der Zeitpunkt, die betroffenen Systeme und die verfügbaren Beweise dokumentiert werden.

Eine gute Störungsaufnahme verhindert:

falsche Annahmen;

unnötige Tests;

wiederholte Rückfragen;

Verlust flüchtiger Informationen;

Veränderungen ohne dokumentierten Ausgangszustand;

unvollständige Eskalationen an andere Administratoren oder Hersteller.

Grundregel

Die Störung wird zunächst beschrieben, aber noch nicht bewertet.

Beispiel:

Nicht ausreichend:

Das Netzwerk funktioniert nicht.

Besser:

Der Client erhält seit dem 30.07.2026 um 14:35 Uhr über Ethernet keine DHCP-Adresse. Windows verwendet stattdessen die IPv4-Adresse 169.254.18.24. Über WLAN erhält derselbe Client eine gültige Adresse und kann auf interne Dienste zugreifen.

Die zweite Beschreibung enthält ein beobachtbares Symptom, einen Zeitpunkt, ein betroffenes Interface und einen funktionierenden Vergleich.

Die wichtigsten Informationen

Information	Fragestellung
Melder	Wer hat die Störung gemeldet?
Zeitpunkt	Wann wurde die Störung erstmals festgestellt?
Letzter funktionierender Zustand	Wann funktionierte der Dienst zuletzt nachweislich?
Betroffener Benutzer	Welcher Benutzer beobachtet das Problem?
Betroffenes Gerät	Hostname, Gerätetyp und Betriebssystem
Betroffener Dienst	Welche Anwendung, Verbindung oder Funktion ist gestört?
Standort	Gebäude, Raum, Homeoffice, Außenstelle oder Cloud
Netzwerkverbindung	Ethernet, WLAN, Mobilfunk oder VPN
Fehlermeldung	Exakter und vollständiger Wortlaut
Reproduzierbarkeit	Kann der Fehler gezielt erneut ausgelöst werden?
Häufigkeit	Dauerhaft, gelegentlich, periodisch oder einmalig
Auswirkung	Was kann der Benutzer oder das Unternehmen nicht durchführen?
Workaround	Gibt es einen vorübergehend funktionierenden Alternativweg?
Letzte Änderungen	Was wurde kurz vor dem Auftreten verändert?
Beweise	Screenshots, Logs, Zeitstempel, Monitoring oder Paketmitschnitt

Exakte Fehlermeldung erfassen

Fehlermeldungen dürfen nicht nur sinngemäß wiedergegeben werden.

Dokumentiert werden:

vollständiger Wortlaut;

Fehlercode;

Event-ID;

HTTP-Status;

Uhrzeit;

betroffene Anwendung;

betroffener Vorgang;

sichtbare Details;

Screenshot, falls sinnvoll.

Beispiel:

Nicht ausreichend:

Anmeldung geht nicht.

Besser:

Bei der Anmeldung erscheint um 08:14 Uhr die Meldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.“

Exakte Fehlermeldungen ermöglichen eine gezieltere Suche in Logs und Herstellerdokumentationen.

Zeitpunkt dokumentieren

Der genaue Zeitpunkt ist erforderlich, um Ereignisse verschiedener Systeme miteinander zu vergleichen.

Dokumentiert werden:

Datum;

Uhrzeit;

Zeitzone;

Beginn der Störung;

letzter erfolgreicher Vorgang;

Zeitpunkt jedes reproduzierten Fehlers.

Beispiel:

Fehler reproduziert am 30.07.2026 um 14:42:18 Uhr MESZ.

Ungefähre Angaben wie „heute Morgen“ oder „vorhin“ reichen für eine Logkorrelation nicht aus.

Zeit und Systeminformationen erfassen

Prüfung	Windows	Linux	macOS
Hostname	`[RO] hostname`	`[RO] hostname`	`[RO] hostname`
Benutzerkontext	`[RO] whoami`	`[RO] whoami`	`[RO] whoami`
Systemzeit	`[RO] Get-Date -Format o`	`[RO] date "+%Y-%m-%d %H:%M:%S %Z"`	`[RO] date "+%Y-%m-%d %H:%M:%S %Z"`
Betriebssystem	`[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object Caption,Version,BuildNumber`	`[RO] cat /etc/os-release`	`[RO] sw_vers`
Laufzeit	`[RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime`	`[RO] uptime`	`[RO] uptime`
Letzter Systemstart	`[RO] Get-CimInstance Win32_OperatingSystem \| Select-Object LastBootUpTime`	`[RO] who -b`	`[RO] sysctl -n kern.boottime`

Diese Befehle verändern keine Konfiguration.

Betroffenes System erfassen

Für einen Client oder Server werden mindestens folgende Angaben benötigt:

Hostname;

Gerätetyp;

Hersteller und Modell, falls relevant;

Betriebssystem;

Betriebssystemversion;

Patch- oder Buildstand;

physisches Gerät, virtuelle Maschine oder Container;

Standort;

verwendete Netzwerkverbindung;

Benutzerkontext;

lokale oder zentrale Verwaltung;

relevante Anwendungs- oder Dienstversion.

Betroffenen Dienst erfassen

Der betroffene Dienst muss möglichst genau benannt werden.

Nicht ausreichend:

Der Server geht nicht.

Besser:

Die HTTPS-Anwendung auf app.example.internal ist über TCP 443 nicht erreichbar. Der Server antwortet weiterhin auf ICMP und SSH.

Mögliche Dienstangaben:

DNS;

DHCP;

HTTPS;

SMB;

RDP;

SSH;

VPN;

Datenbank;

Druckdienst;

Active Directory;

E-Mail;

Containeranwendung;

Cloud-Dienst;

Netzwerkspeicher.

Sollzustand und Istzustand trennen

Zustand	Beschreibung
Sollzustand	Was sollte normalerweise geschehen?
Istzustand	Was geschieht tatsächlich?
Abweichung	Welcher konkrete Unterschied besteht?

Beispiel:

Zustand	Beobachtung
Sollzustand	Client erhält per DHCP eine Adresse aus `192.168.10.0/24`
Istzustand	Client verwendet `169.254.18.24/16`
Abweichung	Kein gültiger DHCP-Lease vorhanden

Reproduzierbarkeit dokumentieren

Ein reproduzierbarer Fehler ist leichter zu untersuchen als ein unregelmäßiger Fehler.

Dokumentiert werden:

Ausgangszustand;

genaue Aktion;

verwendeter Benutzer;

verwendetes Gerät;

Zielsystem oder Zieladresse;

erwartetes Ergebnis;

tatsächliches Ergebnis;

genaue Fehlerzeit.

Beispiel:

Client ist über Ethernet verbunden.

Benutzer öffnet https://app.example.internal.

Browser wartet ungefähr 30 Sekunden.

Anschließend erscheint ein Timeout.

Fehler reproduziert um 14:42:18 Uhr MESZ.

Andere Webseiten funktionieren.

Häufigkeit bestimmen

Auftreten	Dokumentation
Dauerhaft	Fehler tritt bei jedem Versuch auf
Gelegentlich	Fehler tritt unregelmäßig auf
Periodisch	Fehler tritt in erkennbaren Zeitabständen auf
Zeitabhängig	Fehler tritt nur zu bestimmten Uhrzeiten auf
Lastabhängig	Fehler tritt nur bei hoher Nutzung auf
Standortabhängig	Fehler tritt nur in einem Gebäude oder Netz auf
Benutzerabhängig	Fehler tritt nur mit einem bestimmten Konto auf
Geräteabhängig	Fehler tritt nur an einem bestimmten Client auf
Einmalig	Fehler konnte bisher nicht erneut erzeugt werden

Bei unregelmäßigen Fehlern müssen Zeitpunkt und Begleitumstände besonders genau dokumentiert werden.

Letzten funktionierenden Zustand festhalten

Die Frage lautet nicht nur:

Seit wann besteht der Fehler?

Zusätzlich muss geklärt werden:

Wann wurde die betroffene Funktion zuletzt nachweislich erfolgreich verwendet?

Beispiele:

letzte erfolgreiche Anmeldung;

letzter erfolgreicher Druckauftrag;

letzte erfolgreiche DNS-Abfrage;

letzter erfolgreicher Backupjob;

letzte erfolgreiche VPN-Verbindung;

letzte erfolgreiche Replikation;

letzter erfolgreicher API-Aufruf.

Der letzte funktionierende Zustand begrenzt den Zeitraum, in dem eine auslösende Änderung stattgefunden haben kann.

Letzte Änderungen erfassen

An dieser Stelle werden Änderungen zunächst nur gesammelt. Die technische Bewertung erfolgt später auf der Seite 1.3 Zeitpunkt und letzte Änderungen untersuchen.

Mögliche Änderungen:

Update oder Patch;

Neustart;

Treiber- oder Firmwareänderung;

neue Anwendung;

neue Hardware;

Benutzer- oder Passwortänderung;

Rechte- oder Gruppenänderung;

GPO-Änderung;

Firewall- oder ACL-Änderung;

VLAN- oder Switchportänderung;

Routing- oder NAT-Änderung;

DNS- oder DHCP-Änderung;

Zertifikatserneuerung;

Migration;

Snapshot oder Restore;

Backupjob;

Provider- oder Cloudänderung.

Auch die Antwort „Keine Änderung bekannt“ wird dokumentiert.

Auswirkung erfassen

Die technische Störung und ihre betriebliche Auswirkung sind getrennt zu dokumentieren.

Technische Störung	Mögliche Auswirkung
Ein Client erhält keine IP-Adresse	Ein Benutzer kann nicht arbeiten
DHCP für ein VLAN ausgefallen	Eine gesamte Abteilung erhält keine Netzwerkverbindung
DNS-Auflösung gestört	Mehrere Anwendungen erscheinen gleichzeitig ausgefallen
Fileserver nicht erreichbar	Gemeinsame Dokumente können nicht geöffnet werden
VPN ausgefallen	Remotezugriff für Außenstellen oder Homeoffice nicht möglich
Datenbank nicht erreichbar	Geschäftsanwendung vollständig ausgefallen
Backup fehlgeschlagen	Wiederherstellbarkeit möglicherweise gefährdet
Verdächtige Anmeldung	Möglicher Security-Vorfall

Workaround dokumentieren

Ein vorhandener Workaround kann bei der Eingrenzung helfen.

Beispiele:

Ethernet funktioniert nicht, WLAN funktioniert;

Hostname funktioniert nicht, direkte IP-Adresse funktioniert;

VPN funktioniert nicht, lokaler Zugriff funktioniert;

ein Browser funktioniert, ein anderer nicht;

ein Benutzer ist betroffen, ein anderer nicht;

ein Server ist betroffen, ein anderer Server funktioniert;

Neustart behebt das Problem nur vorübergehend.

Ein Workaround ist keine dauerhafte Fehlerbehebung.

Beweise sichern

Mögliche Beweise:

Screenshot;

exportiertes Eventlog;

Logdatei;

Konsolenausgabe;

Monitoringgraph;

Prozessliste;

Liste laufender Dienste;

Netzwerkstatus;

Interface-Counter;

Routingtabelle;

DNS-Ergebnis;

Paketmitschnitt;

Konfigurationsexport;

Hersteller-Supportbundle.

Dateinamen sollten den Host und den Zeitpunkt enthalten.

Beispiel:

client01_systemlog_2026-07-30_1442.evtx

server01_network_2026-07-30_1442.pcapng

Sensible Daten, Passwörter, Tokens und private Schlüssel dürfen nicht ungeschützt in Tickets oder Dokumentationen eingefügt werden.

Vorlage für die Störungsaufnahme

Feld	Eintrag
Ticket oder Referenz
Gemeldet von
Aufgenommen am
Aufgenommen durch
Beginn der Störung
Letzter funktionierender Zustand
Betroffener Benutzer
Betroffenes Gerät
Hostname
Betriebssystem und Version
Standort
Netzwerkverbindung
Betroffener Dienst
Zielsystem oder Zieladresse
Sollzustand
Istzustand
Exakte Fehlermeldung
Fehlercode oder Event-ID
Reproduzierbar
Schritte zur Reproduktion
Häufigkeit
Bekannte letzte Änderungen
Betriebliche Auswirkung
Vorhandener Workaround
Gesicherte Logs und Beweise
Genaue Fehlerzeit mit Zeitzone
Security-Verdacht
Zusätzliche Hinweise

Beispiel einer ausgefüllten Störungsaufnahme

Feld	Eintrag
Ticket oder Referenz	INC-2026-0730-01
Gemeldet von	Benutzer der Arbeitsstation
Aufgenommen am	30.07.2026, 14:40 Uhr MESZ
Beginn der Störung	ungefähr 14:35 Uhr
Letzter funktionierender Zustand	30.07.2026, 12:10 Uhr
Betroffenes Gerät	Arbeitsplatzrechner
Hostname	CLIENT-01
Betriebssystem und Version	Windows 11
Standort	Hauptstandort, Raum 204
Netzwerkverbindung	Ethernet
Betroffener Dienst	DHCP und allgemeiner Netzwerkzugriff
Sollzustand	IPv4-Adresse aus `192.168.10.0/24`
Istzustand	IPv4-Adresse `169.254.18.24/16`
Exakte Fehlermeldung	Keine Fehlermeldung angezeigt
Reproduzierbar	Ja
Häufigkeit	Dauerhaft über Ethernet
Bekannte letzte Änderungen	Keine Änderung bekannt
Betriebliche Auswirkung	Benutzer kann keine internen Dienste erreichen
Vorhandener Workaround	WLAN funktioniert
Gesicherte Beweise	Ausgabe von `ipconfig /all`, Screenshot und Fehlerzeit
Security-Verdacht	Nein

Diese Aufnahme beschreibt den Zustand. Die technische Eingrenzung erfolgt anschließend auf der Seite 1.2 Fehlerumfang mit Kreuztests bestimmen.

Ungeeignete Störungsbeschreibungen

„Geht nicht.“

„Alles ist langsam.“

„Seit dem Update ist alles kaputt.“

„Der Server ist offline.“

„DNS ist defekt.“

„Die Firewall blockiert.“

„Der Benutzer macht etwas falsch.“

„Nach einem Neustart geht es wieder.“

Diese Aussagen enthalten Vermutungen oder sind technisch nicht ausreichend eingegrenzt.

Ergebnis dieser Seite

Nach Abschluss der Störungsaufnahme müssen folgende Punkte bekannt sein:

sichtbares Symptom;

Sollzustand;

Istzustand;

exakte Fehlermeldung;

betroffener Benutzer;

betroffenes Gerät;

betroffener Dienst;

Beginn der Störung;

letzter funktionierender Zustand;

Reproduzierbarkeit;

Häufigkeit;

bekannte Änderungen;

betriebliche Auswirkung;

möglicher Workaround;

vorhandene Logs und Beweise.

Erst danach beginnt die systematische technische Eingrenzung.

Nächste Seite

1.2 Fehlerumfang mit Kreuztests bestimmen

Quellen

IBM – Systematischer Troubleshooting-Ansatz

Microsoft – Windows Networking Troubleshooting

Microsoft – DHCP Troubleshooting Checklist

Microsoft – Windows Performance Troubleshooting

NIST – Incident Response Recommendations