4.13 Update-, Patch- und Paketverwaltungsfehler

Vor einer Reparatur müssen die genaue Updateart und die Fehlerphase bestimmt werden.

Zu erfassende Informationen

• Welches Betriebssystem und welche Version werden verwendet?
• Welches konkrete Update oder Paket schlägt fehl?
• Welche Paket-, KB-, Build- oder Versionsnummer ist betroffen?
• Wird das Update direkt vom Hersteller oder intern bereitgestellt?
• Tritt der Fehler bei Erkennung, Download, Prüfung, Installation oder Neustart auf?
• Wird ein numerischer oder hexadezimaler Fehlercode angezeigt?
• Sind alle Systeme oder nur einzelne Geräte betroffen?
• Wurde das System kürzlich geklont, wiederhergestellt oder migriert?
• Ist ein Neustart ausstehend?
• Besteht ausreichend freier Speicherplatz?
• Stimmen Datum und Uhrzeit?
• Wird ein Proxy, VPN, WSUS, MDM oder internes Repository verwendet?
• Wurden Sicherheitssoftware oder Firewallregeln verändert?
• Ist die Betriebssystemversion noch unterstützt?
• Funktionierte die Aktualisierung zuvor?
• Welche Änderungen erfolgten unmittelbar vor dem Fehler?

Fehlerphasen

Dokumentationsregel

Der originale Fehlercode muss vollständig übernommen werden. Beschreibungen wie „irgendein Updatefehler“ reichen für eine gezielte Analyse nicht aus.

Viele Updatefehler entstehen nicht in der Paketverwaltung selbst.

Schnellprüfung des Speicherplatzes

Windows:

[RO] Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        HealthStatus, SizeRemaining, Size

Linux:

[RO] df -hT

macOS:

[RO] df -h

Zeit prüfen

Windows:

[RO] Get-Date -Format o

Linux:

[RO] timedatectl status

macOS:

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Ein Update kann nur installiert werden, wenn Version, Build, Edition und Architektur unterstützt werden.

Windows

[RO] Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsEditionId,
        WindowsVersion, OsBuildNumber, OsArchitecture

Kompakter:

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OSArchitecture

Linux

[RO][FILE] cat /etc/os-release

[RO] uname -r

[RO] uname -m

macOS

[RO] sw_vers

[RO] uname -m

Typische Architekturbezeichnungen

Die Prozessorarchitektur des Hosts, die Architektur des Betriebssystems und die Architektur eines einzelnen Programms können unterschiedlich sein.

Windows-Geräte können Updates aus unterschiedlichen Quellen beziehen:

• Windows Update
• Microsoft Update
• Windows Server Update Services, kurz WSUS
• Microsoft Intune oder andere Geräteverwaltung
• Windows Update for Business
• Lokale oder zentrale Richtlinien
• Manuell bereitgestellte Updatepakete

Windows-Update-Richtlinien anzeigen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' `
    -ErrorAction SilentlyContinue

Richtlinien für automatische Updates anzeigen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' `
    -ErrorAction SilentlyContinue

Angewendete Gruppenrichtlinien dokumentieren

[RO][SENS] gpresult /scope computer /r

Ausführlichen HTML-Bericht erstellen:

[RO][FILE][SENS] gpresult /scope computer /h "<ZIELPFAD>\gpresult-computer.html"

Relevante Hinweise

Registrywerte dürfen nicht allein aufgrund einer Internetanleitung gelöscht oder verändert werden. Zuerst muss festgestellt werden, ob sie zentral verwaltet werden.

Relevante Dienste anzeigen

[RO] Get-Service -Name wuauserv, bits, cryptsvc, trustedinstaller |
    Select-Object Name, DisplayName, Status, StartType

Bedeutung:

Ausführliche Dienstinformationen

[RO] Get-CimInstance Win32_Service |
    Where-Object {
        $_.Name -in 'wuauserv','BITS','CryptSvc','TrustedInstaller'
    } |
    Select-Object Name, State, StartMode, StartName, ExitCode

Abhängigkeiten eines Dienstes anzeigen

[RO] Get-Service -Name wuauserv -RequiredServices

Wichtige Bewertung

• Ein beendeter Dienst ist nicht automatisch fehlerhaft.
• Einige Dienste werden bedarfsgesteuert gestartet.
• Der Starttyp Manual kann vorgesehen sein.
• Zentral verwaltete Systeme können abweichende Konfigurationen verwenden.
• Ein Dienstneustart behebt nicht die Ursache einer defekten Richtlinie oder Updatequelle.

Ausgewählte installierte Updates anzeigen

[RO] Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, Description, InstalledOn, InstalledBy

Get-HotFix zeigt nicht jede denkbare Update-, Treiber-, App- oder Servicing-Komponente an. Die Ausgabe darf deshalb nicht als vollständiges Inventar aller installierten Aktualisierungen interpretiert werden.

Installierte Windows-Pakete mit DISM anzeigen

[RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table

Nach einem bestimmten KB-Paket suchen

[RO] Get-HotFix -Id <KB-NUMMER> -ErrorAction SilentlyContinue

Beispiel:

[RO] Get-HotFix -Id KB5030000 -ErrorAction SilentlyContinue

Die KB-Nummer im Beispiel ist durch die tatsächlich zu prüfende Nummer zu ersetzen.

Installationszeit und Paketstatus mit DISM prüfen

[RO][PRIV] DISM.exe /Online /Get-PackageInfo /PackageName:<PAKETNAME>

Den exakten Paketnamen erhält man zuvor über:

[RO][PRIV] DISM.exe /Online /Get-Packages /Format:Table

Moderne Windows-Versionen speichern Windows-Update-Ereignisse überwiegend als ETL-Daten. Get-WindowsUpdateLog erzeugt daraus eine lesbare Protokolldatei.

Lesbares WindowsUpdate-Protokoll erzeugen

[RO][FILE][SENS] Get-WindowsUpdateLog -LogPath "<ZIELPFAD>\WindowsUpdate.log"

Der Befehl sammelt und konvertiert vorhandene Protokolldaten. Die erzeugte Datei kann Servernamen, URLs, Geräteinformationen und Fehlerdetails enthalten.

Windows-Update-Ereignisse anzeigen

[RO][SENS] Get-WinEvent -LogName `
    'Microsoft-Windows-WindowsUpdateClient/Operational' |
Select-Object -First 100 TimeCreated, LevelDisplayName, Id, Message

Nur Warnungen und Fehler der letzten 24 Stunden

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-WindowsUpdateClient/Operational'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler'
} |
Select-Object TimeCreated, LevelDisplayName, Id, Message

Servicing-Protokolle

[RO][FILE][SENS] %WINDIR%\Logs\CBS\CBS.log

[RO][FILE][SENS] %WINDIR%\Logs\DISM\dism.log

Setup- und Upgradeprotokolle können unter anderem hier liegen

[RO][FILE][SENS] %WINDIR%\Panther

[RO][FILE][SENS] %WINDIR%\Logs\MoSetup

Die tatsächlich vorhandenen Dateien hängen von Updateart, Betriebssystemversion und Fehlerphase ab.

Bei der Protokollanalyse suchen nach

• Fehlercode
• KB-Nummer
• Paketname
• Zeitpunkt des Installationsversuchs
• Downloadfehler
• Signaturfehler
• Paketabhängigkeit
• ausstehendem Neustart
• beschädigten Komponenten
• Rollback-Ursache

Ein ausstehender Neustart kann weitere Updates, Rolleninstallationen oder Paketänderungen blockieren.

Component-Based-Servicing prüfen

[RO] Test-Path `
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

Windows-Update-Neustartstatus prüfen

[RO] Test-Path `
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'

Ausstehende Dateiumbenennungen prüfen

[RO][SENS] Get-ItemProperty `
    -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' `
    -Name PendingFileRenameOperations `
    -ErrorAction SilentlyContinue

Bewertung

• Nicht jeder vorhandene Indikator bedeutet denselben Neustartgrund.
• Ein Neustart muss mit den Protokollen und dem Änderungsverlauf abgeglichen werden.
• Produktivserver dürfen nicht unkontrolliert neu gestartet werden.
• Vor dem Neustart müssen Dienste, Benutzer, Clusterstatus und Wartungsfenster geprüft werden.

Beschädigungen im Windows-Komponentenspeicher können Updates und Rolleninstallationen verhindern.

Schnelle Prüfung

[TEST][PRIV] DISM.exe /Online /Cleanup-Image /CheckHealth

/CheckHealth prüft, ob bereits eine Beschädigung markiert wurde. Es führt keinen vollständigen Scan aus.

Ausführlichere Prüfung

[TEST][PRIV] DISM.exe /Online /Cleanup-Image /ScanHealth

Systemdateien prüfen

[TEST][PRIV] sfc /verifyonly

Reparatur des Komponentenspeichers

[CHANGE][PRIV] DISM.exe /Online /Cleanup-Image /RestoreHealth

Systemdateien prüfen und reparieren

[CHANGE][PRIV] sfc /scannow

Wichtige Hinweise

• RestoreHealth kann Dateien von Windows Update beziehen.
• In abgeschotteten Umgebungen kann eine passende Reparaturquelle erforderlich sein.
• Eine Reparaturquelle muss zur Betriebssystemversion und zum Wartungsstand passen.
• DISM und SFC können längere Zeit benötigen.
• Ein Abbruch sollte nicht allein wegen eines länger unveränderten Prozentwerts erfolgen.
• Protokolle befinden sich unter anderem in CBS.log und dism.log.

DISM und SFC sind keine pauschalen ersten Schritte für jeden Updatefehler. Zuerst müssen Fehlercode, Quelle, Speicherplatz und Updatephase geprüft werden.

Windows-Systemdienste können andere Proxyeinstellungen verwenden als ein angemeldeter Benutzer.

WinHTTP-Proxy anzeigen

[RO] netsh winhttp show proxy

DNS-Auflösung prüfen

[RO] Resolve-DnsName "<UPDATE-ODER-WSUS-SERVER>"

HTTPS-Erreichbarkeit eines konkret bekannten Servers prüfen

[TEST] Test-NetConnection `
    -ComputerName "<SERVERNAME>" `
    -Port 443

Bei einem internen WSUS-Server muss der tatsächlich konfigurierte Port verwendet werden.

Route anzeigen

[RO] Test-NetConnection `
    -ComputerName "<SERVERNAME>" `
    -TraceRoute

Typische Ursachen

• Proxy verlangt eine interaktive Anmeldung.
• WinHTTP-Proxy ist veraltet.
• PAC-Datei funktioniert nur im Benutzerkontext.
• Firewall blockiert Updateendpunkte.
• TLS-Inspection verändert Zertifikate.
• DNS liefert eine falsche oder interne Adresse.
• VPN verändert Route oder Namensauflösung.
• WSUS ist erreichbar, aber dessen Datenbank oder Anwendungspool ist gestört.

Öffentliche Updateplattformen verwenden mehrere dynamische Endpunkte. Es sollten keine unbestätigten Einzeladressen dauerhaft freigeschaltet werden; maßgeblich ist die aktuelle Herstellerdokumentation.

Debian und Ubuntu verwenden üblicherweise APT und dpkg.

Betriebssystemversion prüfen

[RO][FILE] cat /etc/os-release

Konfigurierte Paketquellen anzeigen

[RO][FILE][SENS] grep -RhsE '^[[:space:]]*deb ' \
    /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Neuere APT-Quellen können zusätzlich im Deb822-Format mit der Endung .sources gespeichert sein:

[RO][FILE][SENS] grep -RhsE \
    '^[[:space:]]*(Types|URIs|Suites|Components|Signed-By):' \
    /etc/apt/sources.list.d 2>/dev/null

Paketstatus auf Inkonsistenzen prüfen

[RO][PRIV] sudo dpkg --audit

Alternativ:

[RO][PRIV] sudo dpkg -C

Paketabhängigkeiten prüfen

[TEST][PRIV] sudo apt-get check

Installierte und verfügbare Version eines Pakets anzeigen

[RO] apt-cache policy "<PAKETNAME>"

Zurückgehaltene Pakete anzeigen

[RO] apt-mark showhold

Paketarchitektur anzeigen

[RO] dpkg --print-architecture

Zusätzlich konfigurierte Architekturen:

[RO] dpkg --print-foreign-architectures

Letzte dpkg-Aktionen anzeigen

[RO][FILE][SENS] tail -n 100 /var/log/dpkg.log

APT-Verlauf anzeigen, sofern vorhanden

[RO][FILE][SENS] ls -l /var/log/apt

[RO][FILE][SENS] tail -n 100 /var/log/apt/history.log

Das Aktualisieren der Paketlisten ist bereits eine Veränderung des lokalen Paketcache.

[CHANGE][PRIV] sudo apt update

Dabei sind besonders folgende Meldungen zu beachten:

Simulation einer Installation

[TEST] apt-get --simulate install "<PAKETNAME>"

Die Simulation verändert keine Pakete, bildet aber nicht jede Nebenwirkung eines tatsächlichen Installationsskripts ab.

Paketinformationen anzeigen

[RO] apt-cache show "<PAKETNAME>"

Abhängigkeiten anzeigen

[RO] apt-cache depends "<PAKETNAME>"

Reverse-Abhängigkeiten anzeigen

[RO] apt-cache rdepends "<PAKETNAME>"

Eine Sperrdatei darf nicht allein aufgrund ihrer Existenz gelöscht werden. Zuerst muss geprüft werden, ob ein Paketmanager tatsächlich arbeitet.

APT- und dpkg-Prozesse anzeigen

[RO][SENS] ps -ef |
    grep -E '[a]pt|[d]pkg|[u]nattended-upgrade'

Prozesse mit geöffneten APT- oder dpkg-Sperren anzeigen

[RO][PRIV][SENS] sudo lsof \
    /var/lib/dpkg/lock \
    /var/lib/dpkg/lock-frontend \
    /var/lib/apt/lists/lock \
    /var/cache/apt/archives/lock 2>/dev/null

Automatische Updates prüfen

[RO] systemctl status apt-daily.service --no-pager

[RO] systemctl status apt-daily-upgrade.service --no-pager

Protokolle automatischer Updates

[RO][PRIV][SENS] sudo journalctl \
    -u apt-daily.service \
    -u apt-daily-upgrade.service \
    --since "-24 hours" --no-pager

Das Löschen einer Sperrdatei oder Beenden eines Paketmanagers während einer Installation kann die Paketdatenbank beschädigen. Erst muss geklärt werden, ob der Prozess noch arbeitet, wartet oder abgestürzt ist.

Ein abgebrochener Installationsprozess kann Pakete in einem nicht fertig konfigurierten Zustand hinterlassen.

Zustand zunächst prüfen

[RO][PRIV] sudo dpkg --audit

Paketstatus eines bestimmten Pakets anzeigen

[RO] dpkg-query -W \
    -f='${Package}\t${Status}\t${Version}\n' "<PAKETNAME>"

Noch nicht konfigurierte Pakete konfigurieren

[CHANGE][PRIV] sudo dpkg --configure -a

Abhängigkeiten reparieren

[CHANGE][PRIV] sudo apt-get --fix-broken install

Diese Befehle können:

• Paketkonfigurationen ausführen
• Dienste starten oder neu starten
• Konfigurationsdateien verändern
• zusätzliche Pakete installieren
• Pakete entfernen
• Administratorfragen anzeigen

Vorher sollten geprüft werden:

• Sicherung oder Snapshot
• freier Speicherplatz
• aktueller Paketstatus
• betroffene Produktivdienste
• vorgeschlagene Paketänderungen
• Wartungsfenster

Bei apt-get --fix-broken install muss die vorgeschlagene Paketliste vor der Bestätigung vollständig gelesen werden.

Fedora, Red Hat Enterprise Linux und verwandte Distributionen verwenden häufig DNF und RPM.

Betriebssystemversion

[RO][FILE] cat /etc/os-release

Aktive Repositories anzeigen

[RO][SENS] dnf repolist

Alle bekannten Repositories anzeigen

[RO][SENS] dnf repolist --all

Paketdatenbank und Abhängigkeiten prüfen

[TEST][PRIV] sudo dnf check

Verfügbare Aktualisierungen prüfen

[TEST][PRIV] sudo dnf check-update

dnf check-update kann mit Rückgabecode 100 enden, wenn Updates verfügbar sind. Dieser Rückgabecode bedeutet dann nicht automatisch einen Fehler.

Paketinformationen anzeigen

[RO] dnf info "<PAKETNAME>"

Installierte Paketversion anzeigen

[RO] rpm -q "<PAKETNAME>"

Paketarchitektur anzeigen

[RO] rpm -q --queryformat \
    '%{NAME}\t%{VERSION}-%{RELEASE}\t%{ARCH}\n' "<PAKETNAME>"

Transaktionsverlauf anzeigen

[RO][SENS] dnf history

Details einer Transaktion

[RO][SENS] dnf history info <TRANSAKTIONS-ID>

Installierte Dateien gegen RPM-Metadaten prüfen

[TEST][PRIV][FILE][SENS] sudo rpm -Va

rpm -Va kann lange laufen und meldet auch absichtlich veränderte Konfigurationsdateien. Abweichungen sind nicht automatisch Beschädigungen.

SUSE Linux Enterprise und openSUSE verwenden typischerweise Zypper.

Repositories anzeigen

[RO][SENS] zypper repos

Ausführlicher:

[RO][SENS] zypper repos --details

Verfügbare Patches anzeigen

[TEST][PRIV] sudo zypper list-patches

Abhängigkeiten prüfen

[TEST][PRIV] sudo zypper verify

Paketinformationen anzeigen

[RO] zypper info "<PAKETNAME>"

Installierte Version prüfen

[RO] rpm -q "<PAKETNAME>"

Zypper-Protokoll lesen

[RO][FILE][SENS] tail -n 100 /var/log/zypper.log

macOS-Version und Build anzeigen

[RO] sw_vers

Verfügbare Apple-Softwareupdates suchen

[TEST] softwareupdate --list

Der Befehl kontaktiert die konfigurierte Updateinfrastruktur und kann einige Zeit benötigen.

Verlauf installierter Apple-Updates anzeigen

[RO] softwareupdate --history

Ausführlicher Verlauf:

[RO] softwareupdate --history --all

Hilfe der installierten softwareupdate-Version anzeigen

[RO] softwareupdate --help

Die verfügbaren Optionen von softwareupdate können sich zwischen macOS-Versionen unterscheiden. Deshalb sollte die lokale Hilfe geprüft werden, bevor Installationsoptionen verwendet werden.

Freien Speicherplatz prüfen

[RO] df -h /

Datum und Uhrzeit prüfen

[RO] date "+%Y-%m-%dT%H:%M:%S%z"

Netzwerkzeitstatus prüfen

[RO][PRIV] sudo systemsetup -getusingnetworktime

Eingetragenen Zeitserver anzeigen

[RO][PRIV][SENS] sudo systemsetup -getnetworktimeserver

MDM-Registrierungsstatus anzeigen

[RO][PRIV][SENS] sudo profiles status -type enrollment

Ein verwalteter Mac kann Updates aufgrund von MDM-Vorgaben:

• verzögert angeboten bekommen
• zu einem Termin erzwungen installieren
• nur über bestimmte Updatekanäle erhalten
• mit anderen Neustartbedingungen installieren
• nicht manuell verändern dürfen

Softwareupdate-Protokolle der letzten Stunde

[RO][PRIV][SENS] sudo log show --last 1h \
    --predicate 'process == "softwareupdated"' \
    --style compact

Mehrere typische Updateprozesse berücksichtigen

[RO][PRIV][SENS] sudo log show --last 2h \
    --predicate 'process == "softwareupdated" OR process == "softwareupdate"' \
    --style compact

Nur Fehler und schwerwiegende Meldungen

[RO][PRIV][SENS] sudo log show --last 2h \
    --predicate '(process == "softwareupdated" OR process == "softwareupdate") AND messageType >= error' \
    --style compact

Die von macOS verwendeten Prozesse und Protokollfelder können sich zwischen Versionen unterscheiden. Wenn die Abfrage keine Ergebnisse liefert, bedeutet dies nicht automatisch, dass kein Updateversuch stattgefunden hat.

Typische Ursachen

• Zu wenig Speicherplatz
• Nicht unterstütztes Mac-Modell
• Falsche Systemzeit
• Netzwerk- oder CDN-Problem
• MDM-Aufschub
• Fehlende Benutzerbestätigung
• FileVault- oder Bootstrap-Token-Anforderung in verwalteten Umgebungen
• Beschädigter Download
• Nicht abgeschlossener vorheriger Updateversuch
• Firmware- oder Wiederherstellungsfehler
• Update wird für den verwendeten Kanal noch nicht angeboten

Softwarepakete und Repositorymetadaten werden normalerweise kryptografisch geprüft.

Typische Fehlerursachen

Sicherheitsregel

Signatur- und Zertifikatsprüfungen dürfen nicht dauerhaft deaktiviert werden, um eine Installation „zum Laufen zu bringen“.

Stattdessen müssen geprüft werden:

1. Systemzeit
2. Repositoryadresse
3. Distributionsversion
4. Paketarchitektur
5. erwarteter Signaturschlüssel
6. Zertifikatskette
7. Proxy- oder TLS-Inspection
8. Integrität des Downloads
9. offizielle Installationsanleitung des Herstellers

Paketmanager installieren selten nur eine einzelne Datei. Pakete besitzen Abhängigkeiten, Konflikte und Versionsanforderungen.

Typische Beziehungen

APT-Abhängigkeiten anzeigen

[RO] apt-cache depends "<PAKETNAME>"

APT-Reverse-Abhängigkeiten

[RO] apt-cache rdepends "<PAKETNAME>"

RPM-Abhängigkeiten anzeigen

[RO] rpm -qR "<PAKETNAME>"

Paket ermitteln, das eine Fähigkeit bereitstellt

DNF:

[RO] dnf provides "<DATEI-ODER-FÄHIGKEIT>"

APT:

[RO] apt-file search "<DATEINAME>"

apt-file ist nicht standardmäßig auf jedem System installiert und benötigt einen eigenen Suchindex.

Diagnosefragen

• Ist das benötigte Repository aktiviert?
• Ist ein Paket bewusst festgehalten worden?
• Wurden Fremdquellen gemischt?
• Wird ein Paket aus einer anderen Distributionsversion verwendet?
• Verlangt die Anwendung eine ältere Bibliothek?
• Wurde ein Teilupdate durchgeführt?
• Passt die Architektur?
• Ist ein Herstellerrepository noch unterstützt?

Beschädigte oder unvollständige Downloads können wiederholte Fehler verursachen. Das pauschale Löschen aller Updatecaches ist dennoch kein sinnvoller erster Diagnoseschritt.

Vor einer Cachebereinigung prüfen

• Ist der Fehler reproduzierbar?
• Ist die Prüfsumme falsch?
• Betrifft der Fehler immer dieselbe Datei?
• Liegt ein Proxycache zwischen Client und Repository?
• Ist genügend Speicherplatz vorhanden?
• Gibt es noch einen aktiven Paketmanager?
• Werden Dateien für einen Rollback benötigt?
• Kann der Download aus einer vertrauenswürdigen Quelle erneut erfolgen?

APT-Downloadcache anzeigen

[RO][FILE] du -sh /var/cache/apt/archives

DNF-Cachebelegung anzeigen

[RO][FILE][PRIV] sudo du -sh /var/cache/dnf

Windows-Update-Downloadbereich

[RO][FILE][PRIV] %WINDIR%\SoftwareDistribution\Download

Der Ordner SoftwareDistribution darf nicht unkontrolliert umbenannt oder gelöscht werden. Ein Reset der Windows-Updatekomponenten verändert den Updatezustand und erschwert möglicherweise die ursprüngliche Ursachenanalyse.

Automatische Aktualisierungen können parallel zu manuellen Arbeiten laufen oder durch Wartungsregeln eingeschränkt sein.

Windows

Zu prüfen sind:

• Gruppenrichtlinien
• Windows Update for Business
• WSUS-Zielgruppen
• aktive Nutzungszeit
• Neustartrichtlinien
• Intune-Update-Ringe
• geplante Wartungsfenster

Debian und Ubuntu

[RO] systemctl status apt-daily.timer --no-pager

[RO] systemctl status apt-daily-upgrade.timer --no-pager

[RO][FILE] systemctl list-timers --all |
    grep -E 'apt|upgrade'

DNF-Systeme

[RO] systemctl list-timers --all |
    grep -E 'dnf|upgrade'

Je nach Distribution und Konfiguration kann beispielsweise dnf-automatic verwendet werden.

macOS

Zu prüfen sind:

• Einstellungen für automatische Updates
• MDM-Aufschübe
• erzwungene Installationstermine
• erforderliche Benutzeraktion
• Neustartbedingungen
• verfügbare Bootstrap- oder Secure Tokens

Automatische Updateprozesse dürfen nicht beendet werden, ohne ihren aktuellen Transaktionszustand zu prüfen.

Ein Update kann zunächst erfolgreich erscheinen und erst beim Neustart scheitern.

Typische Symptome

• Endlose Neustartschleife
• „Änderungen werden rückgängig gemacht“
• Dienst startet nicht
• Treiber wird nicht geladen
• Netzwerkverbindung fehlt
• Anwendung ist inkompatibel
• Kernel startet nicht
• Dateisystem muss geprüft werden
• Firmwareaktualisierung schlägt fehl
• Verschlüsseltes Systemvolume wird nicht entsperrt

Prüfreihenfolge

1. Exakte Meldung und Zeitpunkt dokumentieren.
2. Prüfen, ob ein automatischer Rollback erfolgt ist.
3. Update- und Bootprotokolle sichern.
4. Zuletzt installierte Pakete ermitteln.
5. Dienst- und Treiberstatus kontrollieren.
6. Freien Speicherplatz prüfen.
7. Abhängige Systeme und Clusterstatus berücksichtigen.
8. Herstellerhinweise zum konkreten Update prüfen.
9. Rücknahme nur nach Bewertung der Sicherheitsauswirkung durchführen.
10. Vor erneuter Installation die ursprüngliche Ursache beheben.

Linux: vorherigen Boot untersuchen

[RO][PRIV][SENS] sudo journalctl -b -1 -p warning --no-pager

Windows: letzte Systemfehler

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-24)
} |
Where-Object {
    $_.LevelDisplayName -in 'Warning','Error','Warnung','Fehler'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Bei Clustern, Replikationssystemen und redundanten Diensten reicht die Betrachtung eines einzelnen Servers nicht aus.

Vor einem Update prüfen

• Ist der Cluster gesund?
• Funktioniert die Replikation?
• Ist ausreichend Redundanz vorhanden?
• Welcher Knoten besitzt aktuell die produktiven Rollen?
• Können Rollen kontrolliert verschoben werden?
• Ist Quorum beziehungsweise Witness erreichbar?
• Sind alle Knoten kompatibel?
• Unterstützt der Hersteller gemischte Patchstände?
• Existiert ein getesteter Rückfallplan?
• Ist das Monitoring aktiv?
• Wurde eine Sicherung geprüft?

Gefahren

• Mehrere Knoten werden gleichzeitig neu gestartet.
• Ein bereits gestörter Knoten wird als Ausweichknoten eingeplant.
• Datenbankschema und Anwendungsversion passen nicht zusammen.
• Quorum geht verloren.
• Load Balancer leitet weiterhin auf einen gewarteten Knoten.
• Replikation wird durch Versionsunterschiede unterbrochen.
• Ein automatisches Update umgeht das Wartungsfenster.

Ein Snapshot eines einzelnen Clusterknotens ist kein vollständiger Rückfallplan für einen verteilten Dienst.

1. Betroffenes Update, Paket oder KB eindeutig bestimmen.
2. Originalen Fehlercode und Fehlerzeitpunkt dokumentieren.
3. Betriebssystemversion, Build und Architektur prüfen.
4. Updatephase bestimmen.
5. Freien Speicherplatz und Inodes kontrollieren.
6. Datum, Uhrzeit und Zeitzone prüfen.
7. Ausstehenden Neustart berücksichtigen.
8. Updatequelle, Repository, WSUS oder MDM ermitteln.
9. DNS, Proxy, Firewall und Erreichbarkeit prüfen.
10. Paketmanager- beziehungsweise Updatedienste untersuchen.
11. Protokolle zum Fehlerzeitpunkt auswerten.
12. Paketabhängigkeiten und Signaturen prüfen.
13. Aktive Installations- oder Sperrprozesse identifizieren.
14. Systemdateien beziehungsweise Paketdatenbank kontrollieren.
15. Erst danach Cachebereinigung oder Reparaturmaßnahmen planen.
16. Änderung im Wartungsfenster durchführen.
17. Neustartbedarf kontrolliert umsetzen.
18. Update-, Dienst- und Anwendungsfunktion verifizieren.
19. Ergebnis und verbleibende Risiken dokumentieren.

Ticket:
Datum und Uhrzeit:
Bearbeiter:

Betroffenes System:
Betriebssystem:
Version und Build:
Architektur:
Systemrolle:
Physisch oder virtuell:
Cluster- oder Domänenmitglied:

Updateart:
KB-, Paket- oder Versionsnummer:
Updatequelle:
WSUS, Repository oder MDM:
Fehlerphase:
Originaler Fehlercode:
Originale Fehlermeldung:
Zeitpunkt des Fehlers:

Freier Speicher:
Inode-Belegung:
Datum und Uhrzeit:
Ausstehender Neustart:
Updatedienst:
Paketmanager:
Aktive Installationsprozesse:
Sperrstatus:

DNS-Auflösung:
Proxy:
Erreichbarkeit der Updatequelle:
Signatur- oder Zertifikatsfehler:
Repositorystatus:
Abhängigkeitsfehler:

Relevante Protokolle:
Letzte erfolgreiche Aktualisierung:
Letzte Änderungen:
Vergleich mit funktionierendem System:

Vermutete Ursache:
Durchgeführte Tests:
Sicherung geprüft:
Wartungsfenster:
Durchgeführte Änderung:
Neustart durchgeführt:
Rückfallplan:

Installationsstatus nach der Maßnahme:
Dienststatus:
Anwendungsprüfung:
Monitoring unauffällig:
Weiterführende Maßnahmen: