1.3 Zeitpunkt und letzte Änderungen untersuchen 1.3 Zeitpunkt und letzte Änderungen untersuchen Viele Störungen treten kurz nach einer Änderung auf. Deshalb gehört die Frage „Was hat sich verändert?“ zu den wichtigsten Schritten einer systematischen Fehleranalyse. Dabei gilt jedoch: Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein Beweis für einen ursächlichen Zusammenhang. Ein Update kurz vor einer Störung kann die Ursache sein. Es kann aber ebenso Zufall sein, während beispielsweise gleichzeitig eine Firewall-Regel, ein VLAN oder ein Zertifikat geändert wurde. Ziel dieser Seite Nach diesem Schritt sollten folgende Fragen beantwortet sein: Wann funktionierte das System zuletzt nachweislich? Wann trat der Fehler erstmals nachweislich auf? Was wurde innerhalb dieses Zeitfensters verändert? Wer oder welcher Prozess führte die Änderung aus? Welche Systeme sind von der Änderung betroffen? Passt die Änderung technisch zum Fehlerbild? Kann der Zusammenhang durch einen Test bestätigt oder widerlegt werden? 1. Das Störungszeitfenster bestimmen Zuerst wird der Zeitraum eingegrenzt, in dem die Ursache wahrscheinlich entstanden ist. Zeitpunkt Bedeutung Beispiel Letzter bekannter funktionierender Zustand Funktion wurde erfolgreich verwendet oder geprüft Benutzer meldete sich um 13:50 Uhr erfolgreich an Erste bekannte Störung Fehler wurde erstmals sicher beobachtet Anmeldung schlug um 14:35 Uhr fehl Meldezeitpunkt Störung wurde an den Support gemeldet Ticket wurde um 14:47 Uhr erstellt Beginn der Untersuchung Technische Analyse wurde gestartet Administrator begann um 15:05 Uhr Störungszeitfenster Zeitraum zwischen „funktioniert“ und „funktioniert nicht“ 13:50 bis 14:35 Uhr Je kleiner das Störungszeitfenster ist, desto gezielter können Änderungen, Ereignisse und Protokolle durchsucht werden. Wichtige Unterscheidung „Der Benutzer hat den Fehler um 14:35 Uhr bemerkt“ bedeutet nicht automatisch, dass der Fehler um 14:35 Uhr entstanden ist. Eine ausgefallene nächtliche Sicherung kann beispielsweise erst am nächsten Morgen auffallen. Ein Zertifikat kann um Mitternacht ablaufen, obwohl der betroffene Dienst erst Stunden später verwendet wird. Ein DHCP-, Kerberos- oder DNS-Problem kann bereits bestehen, bevor ein Benutzer eine sichtbare Störung meldet. 2. Uhrzeit und Zeitzone prüfen Bevor Ereignisse verschiedener Systeme verglichen werden, müssen Uhrzeit und Zeitzone geprüft werden. Abweichende Systemzeiten können eine korrekte Ereignisreihenfolge vortäuschen oder verbergen. Besonders relevant ist dies bei: Active Directory und Kerberos Zertifikaten VPN-Verbindungen Firewalls Netzwerkkomponenten Virtualisierungssystemen Cloud-Diensten verteilten Anwendungen SIEM- und Monitoring-Systemen Aktuelle Uhrzeit anzeigen Betriebssystem Befehl Windows PowerShell [RO] Get-Date -Format o Windows Eingabeaufforderung [RO] echo %date% %time% Linux [RO] date "+%Y-%m-%d %H:%M:%S %Z" macOS [RO] date "+%Y-%m-%d %H:%M:%S %Z" Aktuelle UTC-Zeit anzeigen Betriebssystem Befehl Windows PowerShell [RO] (Get-Date).ToUniversalTime().ToString("o") Linux [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" macOS [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" Zeitzone und Zeitsynchronisation prüfen Betriebssystem Befehl Windows PowerShell [RO] Get-TimeZone Windows [RO] w32tm /query /status Windows [RO] w32tm /query /source Linux mit systemd [RO] timedatectl status Linux mit chrony [RO] chronyc tracking Linux mit chrony [RO] chronyc sources -v macOS [RO] systemsetup -gettimezone macOS [RO] sntp -d time.apple.com [RO] bedeutet „Read-only“. Der Befehl liest Informationen aus und soll keine Konfiguration verändern. Bei der Dokumentation sollte immer angegeben werden, ob eine Uhrzeit als lokale Zeit oder als UTC-Zeit notiert wurde. 3. Letzten Systemstart bestimmen Ein Neustart kann eine Störung ausgelöst, beseitigt oder sichtbar gemacht haben. Manche Änderungen werden außerdem erst nach einem Neustart wirksam. Betriebssystem Befehl Windows PowerShell [RO] Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime Windows Eingabeaufforderung [RO] systeminfo Linux [RO] uptime -s Linux [RO] who -b Linux [RO] last reboot macOS [RO] sysctl -n kern.boottime macOS [RO] last reboot Alle Unix-artigen Systeme [RO] uptime Windows-Betriebsdauer berechnen [RO] (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime Typische Schlussfolgerungen Beobachtung Mögliche Bedeutung Störung begann direkt nach einem Neustart Dienststart, Treiber, Update, Abhängigkeit oder Startreihenfolge prüfen System wurde unerwartet neu gestartet Stromversorgung, Absturz, Watchdog, Hypervisor oder automatischer Neustart prüfen System wurde lange nicht neu gestartet Ausstehende Updates, Ressourcenprobleme oder nicht aktivierte Konfigurationsänderungen prüfen Fehler verschwindet nach Neustart Flüchtiger Zustand, Ressourcenleck, blockierter Dienst oder fehlerhafter Cache möglich Fehler erscheint erst nach Neustart Änderung wurde möglicherweise erst beim Systemstart aktiviert 4. Änderungen im Störungszeitfenster sammeln Folgende Änderungsquellen sollten systematisch geprüft werden: Bereich Typische Änderungen Betriebssystem Updates, Neustarts, Treiber, Sicherheitsrichtlinien Anwendungen Installation, Update, Deinstallation, Konfigurationsänderung Dienste Start, Stopp, Absturz, Starttyp oder Dienstkonto geändert Netzwerk VLAN, Routing, Switchport, ACL, Firewall-Regel, NAT DNS Neuer, gelöschter oder geänderter Eintrag DHCP Scope, Reservierung, Option, Lease oder Relay geändert Active Directory Benutzer, Gruppe, Gruppenrichtlinie, Computerobjekt Berechtigungen NTFS-, Freigabe-, Rollen- oder Cloud-Berechtigung Zertifikate Ausstellung, Austausch, Ablauf oder Vertrauenskette Storage Datenträger, LUN, Mount, Berechtigung, Speicherplatz Virtualisierung Snapshot, Migration, Ressourcen oder virtuelle Netzwerke Backup Sicherung, Wiederherstellung, Agent- oder Repository-Änderung Cloud Sicherheitsgruppe, Rolle, Richtlinie, Netzwerk oder Ressource Automatisierung Skript, geplante Aufgabe, Cronjob, Pipeline Hardware Austausch, Firmware, Verkabelung oder Portwechsel Externe Dienste Provider-Störung, Wartung oder geänderte Schnittstelle 5. Ereignisse im relevanten Zeitfenster anzeigen Für die folgenden Beispiele wird dieses Störungszeitfenster verwendet: Letzter bekannter funktionierender Zustand: 30.07.2026, 14:00 Uhr Erste bekannte Störung: 30.07.2026, 15:00 Uhr Die Werte müssen an den tatsächlichen Vorfall angepasst werden. Windows-Ereignisse mit PowerShell durchsuchen Systemprotokoll innerhalb eines Zeitfensters [RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} Anwendungsprotokoll innerhalb eines Zeitfensters [RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} Warnungen und Fehler anzeigen [RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=2,3; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message Level Bedeutung 1 Kritisch 2 Fehler 3 Warnung 4 Information 5 Ausführlich Ereignisse als übersichtliche Tabelle darstellen [RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Sort-Object TimeCreated | Format-Table TimeCreated, Id, ProviderName, LevelDisplayName -AutoSize Nicht jeder Fehler erzeugt ein Ereignis der Stufe „Fehler“. Auch Informationsereignisse können wichtige Hinweise auf Dienststarts, Updates oder Konfigurationsänderungen enthalten. Linux-Ereignisse mit journalctl durchsuchen Alle Ereignisse innerhalb eines Zeitfensters [RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" Nur Warnungen und schwerwiegendere Meldungen [RO] journalctl --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" -p warning Ereignisse eines bestimmten Dienstes [RO] journalctl -u --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" Beispiel für SSH: [RO] journalctl -u sshd --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" Ereignisse des aktuellen Systemstarts [RO] journalctl -b Ereignisse des vorherigen Systemstarts [RO] journalctl -b -1 Kernel-Meldungen des aktuellen Systemstarts [RO] journalctl -k -b macOS-Ereignisse durchsuchen Systemprotokoll innerhalb eines Zeitfensters [RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --style compact Nur Fehler und Störungen [RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'messageType == error OR messageType == fault' --style compact Ereignisse eines bestimmten Prozesses [RO] log show --start "2026-07-30 14:00:00" --end "2026-07-30 15:00:00" --predicate 'process == ""' --style compact Beispiel für den Prozess softwareupdated : [RO] log show --last 2h --predicate 'process == "softwareupdated"' --style compact Alternativ können Protokolle über die Anwendung Konsole untersucht werden. 6. Betriebssystem- und Softwareupdates prüfen Windows Installierte Hotfixes anzeigen [RO] Get-HotFix | Sort-Object InstalledOn -Descending Ausgewählte Informationen darstellen [RO] Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description, InstalledBy Windows-Update-Ereignisse anzeigen [RO] Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 100 | Select-Object TimeCreated, Id, LevelDisplayName, Message Windows-Update-Ereignisse innerhalb eines Zeitfensters [RO] Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} Windows-Update-Protokolldatei erzeugen [RO] Get-WindowsUpdateLog Das Cmdlet erstellt aus den ETL-Dateien eine lesbare Windows-Update-Protokolldatei. Grafischer Weg Einstellungen → Windows Update → Updateverlauf Get-HotFix zeigt nicht zwingend jede installierte Aktualisierung an. Die Ausgabe sollte deshalb mit dem Windows-Updateverlauf, dem Ereignisprotokoll und gegebenenfalls dem eingesetzten Patchmanagement verglichen werden. Debian und Ubuntu APT-Transaktionsverlauf anzeigen [RO] less /var/log/apt/history.log DPKG-Aktivitäten anzeigen [RO] less /var/log/dpkg.log Installationen, Aktualisierungen und Deinstallationen suchen [RO] grep -E " install | upgrade | remove " /var/log/dpkg.log Ältere Protokolle können rotiert und komprimiert vorliegen: [RO] zgrep -hE " install | upgrade | remove " /var/log/dpkg.log* Red Hat Enterprise Linux, Rocky Linux, AlmaLinux und Fedora DNF-Transaktionen anzeigen [RO] dnf history list Details einer Transaktion anzeigen [RO] dnf history info Letzte Transaktion untersuchen [RO] dnf history info last Installierte Pakete nach Installationszeit sortieren [RO] rpm -qa --last SUSE Linux Enterprise und openSUSE Zypper-Verlauf anzeigen [RO] less /var/log/zypp/history Nur Paketinstallationen anzeigen [RO] grep "|install|" /var/log/zypp/history Nur Paketaktualisierungen anzeigen [RO] grep "|update|" /var/log/zypp/history Arch Linux Paketmanager-Protokoll anzeigen [RO] less /var/log/pacman.log Paketänderungen suchen [RO] grep -E "\[ALPM\] (installed|upgraded|removed)" /var/log/pacman.log macOS Verlauf der Softwareupdates anzeigen [RO] softwareupdate --history Installationsverlauf anzeigen [RO] system_profiler SPInstallHistoryDataType Grafischer Weg Systeminformationen → Software → Installationen Die Liste kann nach dem Installationsdatum sortiert werden. 7. Dienständerungen und Dienstabstürze prüfen Windows Besonders interessante Ereignisse des Service Control Managers: Ereignis-ID Typische Bedeutung 7031 Dienst wurde unerwartet beendet 7034 Dienst wurde unerwartet beendet 7036 Dienst hat seinen Status geändert 7040 Starttyp eines Dienstes wurde geändert 7045 Ein neuer Dienst wurde installiert Relevante Dienstereignisse abfragen [RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; Id=7031,7034,7036,7040,7045; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message Aktuellen Zustand eines Dienstes anzeigen [RO] Get-Service -Name Dienstkonfiguration anzeigen [RO] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName, PathName Linux Status eines Dienstes anzeigen [RO] systemctl status Protokoll eines Dienstes anzeigen [RO] journalctl -u --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" Fehlgeschlagene Dienste anzeigen [RO] systemctl --failed Zeitpunkt der Dienstaktivierung anzeigen [RO] systemctl show -p ActiveEnterTimestamp -p InactiveEnterTimestamp macOS Geladene launchd-Dienste anzeigen [RO] launchctl list Nach einem bestimmten Dienst suchen [RO] launchctl list | grep -i "" Prozessereignisse untersuchen [RO] log show --last 2h --predicate 'process == ""' --style compact 8. Geplante und automatisierte Änderungen prüfen Nicht jede Änderung wird manuell durch einen Administrator ausgelöst. Häufige Ursachen sind: geplante Aufgaben Cronjobs Systemd-Timer Wartungsskripte Patchmanagement Softwareverteilung CI/CD-Pipelines Konfigurationsmanagement Gruppenrichtlinien Backup- und Cleanup-Jobs automatische Zertifikatserneuerung automatische Skalierung oder Cloud-Automatisierung Windows Geplante Aufgaben anzeigen [RO] Get-ScheduledTask Laufzeitinformationen anzeigen [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending Aufgaben mit Fehlerergebnis suchen [RO] Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object {$_.LastTaskResult -ne 0} Task-Scheduler-Ereignisse anzeigen [RO] Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -MaxEvents 100 Ein von 0 abweichender Rückgabewert ist ein Hinweis, muss aber anhand der jeweiligen Aufgabe interpretiert werden. Linux Systemd-Timer anzeigen [RO] systemctl list-timers --all Cronjobs des aktuellen Benutzers anzeigen [RO] crontab -l Systemweite Cron-Verzeichnisse prüfen [RO] ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Cron-Ereignisse auf Debian und Ubuntu suchen [RO] journalctl -u cron --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" Cron-Ereignisse auf RHEL-kompatiblen Systemen suchen [RO] journalctl -u crond --since "2026-07-30 14:00:00" --until "2026-07-30 15:00:00" macOS Geladene launchd-Aufträge anzeigen [RO] launchctl list Systemweite LaunchDaemons anzeigen [RO] ls -la /Library/LaunchDaemons Systemweite LaunchAgents anzeigen [RO] ls -la /Library/LaunchAgents Benutzerspezifische LaunchAgents anzeigen [RO] ls -la ~/Library/LaunchAgents 9. Konfigurationsänderungen vergleichen Wenn eine frühere Konfigurationsversion vorhanden ist, sollte sie mit dem aktuellen Zustand verglichen werden. Windows PowerShell [RO] Compare-Object (Get-Content "") (Get-Content "") Linux und macOS [RO] diff -u "" "" Git-verwaltete Konfigurationen [RO] git status [RO] git diff [RO] git log --oneline --decorate -n 20 [RO] git log -p -- "" Mögliche Quellen früherer Konfigurationen Konfigurationsmanagement Versionsverwaltung Systembackup VM-Snapshot Firewall-Konfigurationsbackup Switch-Konfigurationsarchiv Gruppenrichtlinien-Backup Dokumentation Export aus der Verwaltungsoberfläche gewünschter Zustand aus Infrastructure as Code Der aktuelle Zustand zeigt nur, wie das System jetzt konfiguriert ist. Ohne Auditierung, Versionsverwaltung oder Backup lässt sich daraus nicht zuverlässig ableiten, wann und durch wen eine Änderung vorgenommen wurde. 10. Änderungen an Netzwerkkomponenten prüfen Bei Netzwerkstörungen sollten nicht nur Server und Clients betrachtet werden. Komponente Zu prüfende Änderungen Switch Portstatus, VLAN, Trunk, Port-Security, STP, Firmware Router Routing, Interface, NAT, ACL, dynamisches Routing Firewall Regelwerk, NAT, VPN, Objektgruppen, Zertifikate WLAN-Controller SSID, VLAN-Zuordnung, Authentifizierung, Funkkanal DHCP-Server Scope, Optionen, Reservierungen, Relay DNS-Server Einträge, Zonen, Weiterleitungen, Replikation Load Balancer Backend, Health Check, Zertifikat, Listener Proxy Ausnahmen, Authentifizierung, Zertifikat, Filterregel NAC-System Richtlinie, Geräteprofil, Quarantäne Provider Wartung, Routingänderung, Störung Zu verwendende Informationsquellen Konfigurations- und Auditprotokoll des Gerätes AAA-, TACACS+- oder RADIUS-Protokoll Syslog-Server SIEM Netzwerkmanagementsystem Monitoring Konfigurationsbackup Change-Ticket Hersteller- oder Provider-Statusseite Wartungsankündigungen Besonders wichtige Angaben Benutzer- oder Automationskonto Zeitpunkt Quell-IP-Adresse betroffene Komponente alter Wert neuer Wert Commit-, Revisions- oder Transaktions-ID zugehörige Ticketnummer 11. Active Directory und Gruppenrichtlinien prüfen Mögliche relevante Änderungen: Benutzer wurde deaktiviert oder gesperrt Gruppenmitgliedschaft wurde geändert Computerobjekt wurde verschoben oder gelöscht Gruppenrichtlinie wurde geändert Gruppenrichtlinie wurde neu verknüpft Sicherheitsfilterung wurde verändert DNS- oder Replikationsproblem trat auf Dienstkonto oder Kennwort wurde geändert Berechtigung wurde entzogen Vertrauensstellung wurde verändert Windows-Sicherheitsprotokoll nach Änderungen durchsuchen [RO] Get-WinEvent -FilterHashtable @{LogName="Security"; StartTime=[datetime]"2026-07-30 14:00:00"; EndTime=[datetime]"2026-07-30 15:00:00"} | Select-Object TimeCreated, Id, Message Der Zugriff auf das Sicherheitsprotokoll benötigt entsprechende Berechtigungen. Resultierende Gruppenrichtlinien anzeigen [RO] gpresult /r Ausführlichen HTML-Bericht erstellen [RO] gpresult /h "\gpresult.html" Das Erstellen der HTML-Datei ist keine reine Leseoperation, verändert aber keine Systemkonfiguration. Es wird lediglich eine Berichtsdatei geschrieben. Zeitpunkt der letzten Richtlinienverarbeitung prüfen [RO] Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 100 Für eine zuverlässige Nachverfolgung von Änderungen müssen die passenden Überwachungsrichtlinien bereits vor dem Vorfall aktiviert worden sein. 12. Cloud- und SaaS-Änderungen prüfen Je nach Umgebung sind unter anderem folgende Protokolle relevant: Plattform Typische Quelle Microsoft Entra ID Überwachungsprotokolle und Anmeldeprotokolle Microsoft 365 Einheitliches Überwachungsprotokoll Microsoft Azure Activity Log und Resource Logs Amazon Web Services AWS CloudTrail Google Cloud Cloud Audit Logs VMware vCenter Tasks und Events Proxmox VE Task History und Systemprotokoll Backup-System Job-, Audit- und Konfigurationsverlauf Endpoint-Management Geräte-, Richtlinien- und Bereitstellungsverlauf Softwareverteilung Deployment- und Installationsstatus Zu prüfen sind insbesondere: Wer führte die Änderung aus? Wurde die Änderung manuell oder automatisiert ausgeführt? Von welcher Quell-IP kam die Aktion? Welche Ressource wurde verändert? Was war der vorherige Wert? Was ist der aktuelle Wert? War die Änderung erfolgreich? Gibt es eine zugehörige Ticket-, Job- oder Request-ID? 13. Zeitachse erstellen Alle relevanten Ereignisse werden in einer gemeinsamen Zeitachse dokumentiert. Zeit Quelle oder System Ereignis oder Änderung Benutzer oder Prozess Beleg Bewertung 13:50 Client-PC Anmeldung erfolgreich Max Mustermann Benutzerangabe Letzter funktionierender Zustand 14:10 Windows Server Sicherheitsupdate installiert Patchmanagement Updateverlauf Zeitlich auffällig 14:31 Switch Port in anderes VLAN verschoben Admin-Konto Auditprotokoll Technisch passend 14:35 Client-PC Anmeldung nicht mehr möglich Max Mustermann Ticket und Ereignisprotokoll Erste bekannte Störung 14:42 Monitoring Domänencontroller weiterhin erreichbar Monitoring-System Messwert Serverausfall unwahrscheinlich 15:12 Testport Anmeldung funktioniert Testbenutzer Kreuztest Switchport als Fehlerbereich bestätigt Dieses Beispiel zeigt: Das Windows-Update fand zwar vor der Störung statt. Die VLAN-Änderung liegt jedoch näher am ersten Fehler. Das Fehlerbild passt technisch zur VLAN-Änderung. Der Kreuztest über einen anderen Switchport bestätigt den Zusammenhang. Das Update war lediglich zeitlich auffällig, aber nicht die wahrscheinlichste Ursache. 14. Änderungen bewerten Nicht jede gefundene Änderung besitzt dieselbe Bedeutung. Kriterium Frage Zeitliche Nähe Liegt die Änderung kurz vor dem ersten Fehler? Technische Plausibilität Kann die Änderung genau dieses Fehlerbild verursachen? Betroffener Umfang Entspricht der Änderungsumfang den betroffenen Benutzern oder Systemen? Reproduzierbarkeit Tritt der Fehler nach der Änderung zuverlässig auf? Gegenprobe Funktioniert es ohne die Änderung oder auf einem unveränderten Vergleichssystem? Protokollbeleg Gibt es passende Fehler, Warnungen oder Statusänderungen? Abhängigkeiten Betrifft die Änderung einen abhängigen Dienst oder ein vorgelagertes System? Vergleichswerte Funktionieren nicht geänderte Systeme weiterhin? Bekanntes Problem Ist das Verhalten vom Hersteller dokumentiert? Praktische Priorisierung Bewertung Bedeutung Hoch Änderung liegt im Zeitfenster, passt technisch und wird durch Tests gestützt Mittel Änderung liegt im Zeitfenster und ist technisch möglich, aber noch nicht bestätigt Niedrig Änderung liegt nur zeitlich nahe, passt aber kaum zum Fehlerbild Ausgeschlossen Gegenprobe oder Messung widerlegt den Zusammenhang 15. Korrelation und Ursache unterscheiden Nur Korrelation Update wurde am selben Tag installiert. Fehler wurde später gemeldet. Es gibt keine passende Fehlermeldung. Andere identisch aktualisierte Systeme funktionieren. Eine Deinstallation verändert das Fehlerbild nicht. Wahrscheinlicher ursächlicher Zusammenhang Fehler trat unmittelbar nach der Änderung auf. Nur geänderte Systeme sind betroffen. Nicht geänderte Vergleichssysteme funktionieren. Protokolle zeigen passende Fehler. Der Fehler lässt sich reproduzieren. Eine kontrollierte Rücknahme beseitigt den Fehler. Erneutes Anwenden der Änderung erzeugt den Fehler wieder. Die stärkste Bestätigung entsteht durch einen kontrollierten A/B-Test: Zustand A Zustand B Schlussfolgerung Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler verschwunden Zusammenhang wahrscheinlich Änderung vorhanden, Fehler vorhanden Änderung entfernt, Fehler bleibt Änderung vermutlich nicht ursächlich Geändertes System gestört Unverändertes Vergleichssystem funktioniert Änderung oder Systemunterschied priorisieren Beide Systeme gestört Gemeinsame Abhängigkeit untersuchen Lokale Änderung weniger wahrscheinlich 16. Vor einem Rollback beachten Eine Änderung darf nicht allein aufgrund zeitlicher Nähe unüberlegt zurückgenommen werden. Vor einem Rollback sollten folgende Punkte geklärt sein: Ist die Änderung dokumentiert? Ist der ursprüngliche Zustand bekannt? Existiert eine getestete Rückfallmöglichkeit? Werden Sicherheitslücken erneut geöffnet? Entstehen Abhängigkeiten zu anderen Änderungen? Ist eine Freigabe erforderlich? Sind Konfiguration, Protokolle und Beweise gesichert? Kann die Auswirkung des Rollbacks überwacht werden? Gibt es einen Wartungszeitraum? Kann das System nach dem Rollback vollständig getestet werden? Sicheres Vorgehen Aktuellen Zustand dokumentieren. Relevante Protokolle und Konfigurationen sichern. Rollback-Auswirkungen bewerten. Freigabe einholen. Möglichst nur eine Änderung zurücknehmen. Den ursprünglichen Fehler erneut testen. Abhängige Funktionen prüfen. Ergebnis und Uhrzeit dokumentieren. System anschließend weiter beobachten. Ein Rollback ist selbst eine Änderung und kann neue Störungen verursachen. 17. Häufige Fehler bei der Änderungsanalyse Fehler Folge Besseres Vorgehen Erstbeste Änderung wird beschuldigt Falsche Ursache wird verfolgt Technische Plausibilität und Gegenprobe prüfen Nur der Server wird untersucht Netzwerk-, Client- oder Cloud-Änderung bleibt unentdeckt Gesamten Kommunikationsweg betrachten Uhrzeiten werden ungeprüft verglichen Falsche Ereignisreihenfolge Uhrzeit, Zeitzone und Synchronisation prüfen Nur Fehlerereignisse werden gelesen Wichtige Informationsereignisse fehlen Auch Starts, Stopps und Statusänderungen prüfen Aktueller Zustand wird als Verlauf interpretiert Zeitpunkt und Urheber bleiben unbekannt Audit-, Versions- und Änderungsprotokolle verwenden Mehrere Änderungen werden gleichzeitig zurückgenommen Ursache kann nicht mehr zugeordnet werden Möglichst eine Variable pro Test verändern Protokolle werden erst nach Neustart gesichert Flüchtige Informationen gehen verloren Beweise vor Änderungen und Neustarts sichern Benutzerangabe wird als exakter Fehlerbeginn behandelt Suchzeitraum wird zu eng gewählt Letzten sicheren Funktionstest und erste sichere Störung trennen Nur geplante Änderungen werden geprüft Automatische oder unautorisierte Änderung fehlt Audit-, Deployment- und Automationsprotokolle einbeziehen Provider oder SaaS wird vergessen Externe Störung bleibt unberücksichtigt Service Health und Anbieterstatus prüfen 18. Dokumentationsvorlage Feld Eintrag Letzter bekannter funktionierender Zustand Quelle dieser Information Erste bekannte Störung Quelle dieser Information Verwendete Zeitzone Zeitabweichungen festgestellt Ja / Nein Letzter Systemstart Änderungen im Zeitfenster Verantwortlicher Benutzer oder Prozess Zugehöriges Change-Ticket Technische Plausibilität Hoch / Mittel / Niedrig Protokollbeleg vorhanden Ja / Nein Vergleichssystem geprüft Ja / Nein Gegenprobe durchgeführt Ja / Nein Rollback durchgeführt Ja / Nein Ergebnis Vermutete Ursache Ursache bestätigt Ja / Nein Noch offene Prüfungen Kurzcheckliste Letzten funktionierenden Zustand bestimmt Erste bekannte Störung bestimmt Meldezeitpunkt nicht mit Fehlerbeginn verwechselt Uhrzeit und Zeitzone aller beteiligten Systeme geprüft Letzte Neustarts geprüft Betriebssystemupdates geprüft Softwareinstallationen und Paketänderungen geprüft Dienststarts, Dienststopps und Abstürze geprüft Geplante Aufgaben und Automatisierungen geprüft Netzwerk- und Firewalländerungen geprüft DNS-, DHCP- und Active-Directory-Änderungen geprüft Cloud- und SaaS-Auditprotokolle geprüft Konfiguration mit früherem Zustand verglichen Gemeinsame Zeitachse erstellt Zeitliche Korrelation von bestätigter Ursache getrennt Ursache durch Messung, Vergleich oder Gegenprobe geprüft Beweise vor Neustart oder Rollback gesichert Ergebnisse im Ticket dokumentiert Ergebnis dieses Arbeitsschrittes Am Ende sollte eine nachvollziehbare Zeitachse vorliegen. Darin stehen der letzte funktionierende Zustand, der erste bekannte Fehler und alle technisch relevanten Änderungen dazwischen. Eine Änderung gilt erst dann als wahrscheinliche Ursache, wenn sie: zeitlich zum Fehler passt, das Fehlerbild technisch erklären kann, den tatsächlich betroffenen Umfang erklärt und möglichst durch einen Vergleichs- oder Rücknahmetest bestätigt wurde. Nächste Seite: 1.4 Flüchtige Informationen und Beweise sichern Quellen und weiterführende Dokumentation Microsoft Learn – Get-WinEvent Microsoft Learn – Get-HotFix Microsoft Learn – Windows-Update-Protokolldateien Microsoft Learn – Problembehandlung bei Windows-Server-Updates Microsoft Learn – Windows-Ereignisanzeige freedesktop.org – journalctl Red Hat – Configuring basic system settings Apple Support – Anzeigen von Protokollmeldungen in der Konsole Apple Support – Installationsverlauf auf einem Mac anzeigen