Wazuh Agent unter Windows 11 lässt sich nicht deinstallieren: MSI-Fehler 1603 nach Windows-Updates beheben

Einleitung

Bei einem Wazuh-Agent-Upgrade auf Windows-Endpunkten wird die vorhandene Installation normalerweise über den Windows Installer entfernt oder direkt aktualisiert. Schlägt die Deinstallation jedoch mit dem MSI-Rückgabecode 1603 fehl, bleibt die alte Agent-Version registriert. Eine neuere Version kann anschließend häufig nicht sauber installiert werden.

Im hier betrachteten Fall trat das Problem auf Windows-11-Systemen nach den kumulativen Windows-Updates vom Juni 2026 auf. Die Deinstallation mit msiexec.exe /x wurde abgebrochen, obwohl der Befehl mit administrativen Rechten und im unbeaufsichtigten Modus ausgeführt wurde. Im MSI-Protokoll führte der Fehlerpfad über die Wazuh-Custom-Action CustomAction_RemoveAllScript und einen VBScript-Laufzeitfehler 457.

Der Fehler ist sicherheitsrelevant: Solange der Agent nicht aktualisiert werden kann, fehlen möglicherweise Fehlerkorrekturen und neue Erkennungsfunktionen. Gleichzeitig darf ein Windows-Sicherheitsupdate nicht vorschnell entfernt werden, da dadurch bekannte Betriebssystem-Schwachstellen wieder geöffnet werden können.

Ausgangslage / Problemstellung

Betroffen war eine typische Umgebung mit folgenden Merkmalen:

Windows 11 als Endpoint-Betriebssystem
Wazuh Agent 4.x
Installation über ein MSI-Paket
unbeaufsichtigte Deinstallation über die Kommandozeile
installierte kumulative Windows-Updates vom Juni 2026

Der reguläre Deinstallationsversuch sah beispielsweise so aus:

msiexec.exe /x .\wazuh-agent-4.x.x-x.msi /qn

Alternativ wurde die Deinstallation über den MSI-ProductCode angestoßen:

msiexec.exe /x "{PRODUCT-CODE-DES-WAZUH-AGENTEN}" /qn

Der Windows Installer beendete den Vorgang mit Fehler 1603. Dieser Code bedeutet zunächst nur, dass während der MSI-Transaktion ein schwerwiegender Fehler aufgetreten ist. Er beschreibt nicht die eigentliche Ursache. Microsoft nennt unter anderem Berechtigungsprobleme, bereits vorhandene Installationen, verschlüsselte Zielordner und unzureichende SYSTEM-Berechtigungen als mögliche Auslöser. Entscheidend ist deshalb immer das ausführliche MSI-Protokoll.

Im konkreten Fehlerbild enthielt das Protokoll Hinweise wie:

CustomAction_RemoveAllScript
VBScript error 457
MainEngineThread is returning 1603

Da die vorhandene Installation nicht vollständig entfernt wurde, blieb der Wazuh Agent im Windows-Installer-Inventar registriert. Die Installation einer neueren Version konnte dadurch ebenfalls fehlschlagen oder in einen inkonsistenten Upgrade-Zustand geraten.

Technische Analyse

MSI-Fehler 1603 ist nur der übergeordnete Rückgabecode

Der Fehlercode 1603 ist ein Sammelfehler des Windows Installers. Er allein reicht nicht aus, um zwischen folgenden Ursachen zu unterscheiden:

fehlgeschlagene MSI-Custom-Action
gesperrte Agent-Dateien
nicht vollständig beendeter Wazuh-Prozess
falsches MSI-Paket für die registrierte Installation
fehlende Berechtigungen
defekte oder veränderte Script-Laufzeit
nicht mehr vorhandenes Installationsprodukt

Für eine belastbare Analyse muss die Deinstallation deshalb mit /L*v wiederholt werden:

msiexec.exe /x "{PRODUCT-CODE}" /qn /norestart `
  /L*v "C:\Windows\Temp\wazuh-uninstall.log"

Im Protokoll sollte anschließend vom letzten Eintrag Return value 3 nach oben gesucht werden. Der eigentliche Fehler befindet sich in der Regel unmittelbar vor diesem Eintrag.

Die Wazuh-Deinstallation verwendet eine MSI-Custom-Action

Die offizielle Wazuh-Dokumentation sieht für Windows grundsätzlich eine Deinstallation über das ursprüngliche MSI-Paket vor:

msiexec.exe /x wazuh-agent-<VERSION>.msi /qn

Der Windows-Agent wird standardmäßig unter C:\Program Files (x86)\ossec-agent installiert.

Im Wazuh-4.x-Installer wird während der Deinstallation unter anderem das VBScript RemoveAllScript.vbs ausgeführt. Das Script übernimmt die Bereinigung des Installationsverzeichnisses. Bestimmte Dateien wie ossec.conf, client.keys, local_internal_options.conf und das Installer-Protokoll werden dabei vorübergehend in .save-Dateien umbenannt, während andere Dateien und Unterverzeichnisse entfernt werden. Für die Ausschlusslisten verwendet das Script Scripting.Dictionary-Objekte.

Der VBScript-Fehler 457 steht normalerweise dafür, dass einem Dictionary ein Schlüssel hinzugefügt werden soll, der bereits vorhanden ist. Die Wazuh-Custom-Action beendet sich dadurch unerwartet und der Windows Installer setzt die gesamte Deinstallation zurück. Das erklärt, warum der Agent trotz bereits gelöschter oder umbenannter Einzeldateien weiterhin als installiert erscheinen kann.

Die zeitliche Korrelation mit den Windows-Updates vom Juni 2026 deutet auf eine veränderte beziehungsweise fehlerhafte Script- oder Automationsausführung hin. Eine öffentlich dokumentierte, Wazuh-spezifische Root-Cause-Analyse für exakt diese Custom-Action lag zum Zeitpunkt der Untersuchung jedoch nicht vor. Deshalb sollte nicht pauschal angenommen werden, dass jeder Fehler 1603 auf denselben Windows-Patch zurückzuführen ist.

Die genannten KB-Nummern müssen zum Betriebssystem passen

Bei der Analyse ist die korrekte Zuordnung der Windows-Updates wichtig. Verschiedene Windows-Versionen erhielten am 9. Juni 2026 unterschiedliche kumulative Pakete:

Betriebssystem	Kumulatives Update vom 9. Juni 2026
Windows 11 23H2	KB5093998
Windows 11 24H2 und 25H2	KB5094126
Windows 11 26H1	KB5095051
Windows Server 2022	KB5094128
Windows Server 2019 beziehungsweise Windows-10-Build 17763	KB5094123

KB5094128 ist somit kein Windows-11-Update, sondern gehört zu Windows Server 2022. KB5088862 ist wiederum ein kumulatives .NET-Framework-Update vom 12. Mai 2026 für Windows Server 2022 und sollte nicht pauschal als Windows-11-Juni-Update eingeordnet werden.

Ein falsches MSI-Paket kann ein zweites Fehlerbild erzeugen

Nach einem WPK-Upgrade kann das auf dem Dateisystem vorhandene MSI-Paket von dem Produkt abweichen, das im Windows Installer registriert ist. In einem dokumentierten Wazuh-Fall schlug die Deinstallation über den MSI-Dateinamen fehl, während die Deinstallation über den tatsächlich registrierten ProductCode funktionierte.

Das ist von dem VBScript-Fehler zu unterscheiden:

Fehler 1605 deutet häufig darauf hin, dass das angegebene Produkt nicht installiert ist.
Fehler 1603 mit CustomAction_RemoveAllScript und VBScript 457 deutet auf eine fehlgeschlagene Custom-Action hin.
Fehler 1603 während RemoveFiles kann durch noch laufende oder gesperrte Wazuh-Dateien verursacht werden.

Wazuh hat außerdem einen separaten Fall dokumentiert, in dem der Agent-Prozess nach dem Stoppen des Dienstes nicht rechtzeitig beendet wurde. Dadurch blieben Installationsdateien geöffnet und die MSI-Deinstallation schlug ebenfalls mit 1603 fehl.

Aktueller Windows-Patchstand vor einem Rollback

Microsoft veröffentlichte am 14. Juli 2026 das kumulative Windows-11-Update KB5101650. Darin wurde unter anderem ein durch das Juni-Update ausgelöstes Problem mit OLE-Automation und Drittanbieteranwendungen korrigiert. Das ist keine ausdrückliche Bestätigung, dass damit auch die Wazuh-Custom-Action repariert wurde. Es spricht jedoch dafür, vor einer Deinstallation von Sicherheitsupdates zunächst den aktuellen kumulativen Patchstand einzuspielen und die Wazuh-Deinstallation erneut zu testen.

Lösung / Best Practices

1. Betriebssystem, Build und installierte Updates erfassen

Die Analyse sollte auf jedem betroffenen Endpoint mit einer vollständigen Bestandsaufnahme beginnen:

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

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 20 HotFixID, Description, InstalledOn

Da Get-HotFix nicht jedes Servicing-Paket gleich zuverlässig auflistet, kann zusätzlich DISM beziehungsweise das Windows-Package-Cmdlet verwendet werden:

Get-WindowsPackage -Online |
    Where-Object {
        $_.PackageName -match '5093998|5094126|5095051|5094128|5094123'
    } |
    Select-Object PackageName, PackageState, InstallTime

Die Ausgaben sollten zusammen mit dem MSI-Protokoll im Incident- oder Deployment-Ticket gespeichert werden.

2. Agent-Konfiguration kontrolliert sichern

Vor manuellen Eingriffen sollte das Wazuh-Verzeichnis gesichert werden:

$agentPath = "${env:ProgramFiles(x86)}\ossec-agent"
$backupPath = "C:\Windows\Temp\wazuh-agent-backup"

New-Item -ItemType Directory -Path $backupPath -Force | Out-Null

$files = @(
    "ossec.conf",
    "client.keys",
    "local_internal_options.conf",
    "installer.log"
)

foreach ($file in $files) {
    $source = Join-Path $agentPath $file

    if (Test-Path $source) {
        Copy-Item $source $backupPath -Force
    }
}

client.keys enthält die Identität und den Authentisierungsschlüssel des Endpoints. Die Datei muss wie ein Secret behandelt werden. Sie darf nur dann wiederverwendet werden, wenn derselbe Endpoint mit derselben Wazuh-Agent-Identität neu installiert wird. Das Verteilen derselben Datei auf mehrere Systeme erzeugt Identitätskonflikte und schwächt die Nachvollziehbarkeit.

3. Den tatsächlich registrierten MSI-ProductCode ermitteln

Statt einen angenommenen MSI-Dateinamen zu verwenden, sollte der registrierte ProductCode aus beiden Windows-Uninstall-Zweigen gelesen werden:

$uninstallPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

$app = Get-ItemProperty $uninstallPaths -ErrorAction SilentlyContinue |
    Where-Object {
        $_.DisplayName -like "Wazuh Agent*"
    } |
    Sort-Object DisplayVersion -Descending |
    Select-Object -First 1

if (-not $app) {
    throw "Keine registrierte Wazuh-Agent-Installation gefunden."
}

$app |
    Format-List DisplayName, DisplayVersion, PSChildName, UninstallString

$productCode = ""

if ($app.PSChildName -match '^\{[0-9A-Fa-f-]{36}\}$') {
    $productCode = $app.PSChildName
}
elseif ($app.UninstallString) {
    $productCode = [regex]::Match(
        $app.UninstallString,
        '\{[0-9A-Fa-f-]{36}\}'
    ).Value
}

if (-not $productCode) {
    throw "Der MSI-ProductCode konnte nicht ermittelt werden."
}

Damit wird vermieden, dass ein nicht passendes oder nach einem WPK-Upgrade nicht mehr registriertes MSI-Paket verwendet wird.

4. Dienst und verbleibende Prozesse stoppen

Vor der Deinstallation sollte der Wazuh-Dienst beendet werden:

Stop-Service -Name WazuhSvc -Force -ErrorAction SilentlyContinue

Get-Process -Name "wazuh-agent" -ErrorAction SilentlyContinue |
    Stop-Process -Force

Anschließend sollte geprüft werden, ob noch Wazuh-Prozesse laufen:

Get-Process |
    Where-Object {
        $_.ProcessName -match 'wazuh|ossec'
    }

Das erzwungene Beenden sollte nur für den Wartungsvorgang verwendet werden. Im normalen Betrieb ist das kontrollierte Stoppen des Dienstes vorzuziehen.

5. Standarddeinstallation mit ausführlichem Protokoll wiederholen

$log = "C:\Windows\Temp\wazuh-uninstall.log"
$arguments = "/x $productCode /qn /norestart /L*v `"$log`""

$process = Start-Process `
    -FilePath "msiexec.exe" `
    -ArgumentList $arguments `
    -Wait `
    -PassThru

"MSI exit code: $($process.ExitCode)"

Relevante Rückgabecodes:

0: Deinstallation erfolgreich
3010: erfolgreich, Neustart erforderlich
1605: angegebenes Produkt ist nicht installiert
1603: schwerwiegender MSI-Fehler; Protokoll analysieren

Bleibt der Vorgang bei CustomAction_RemoveAllScript mit VBScript 457 stehen, ist ein erneuter Aufruf mit identischen Parametern meist nicht zielführend.

6. Aktuellen kumulativen Windows-Patch installieren und erneut testen

Bevor ein Sicherheitsupdate zurückgerollt wird, sollte das Gerät auf den aktuellen kumulativen Windows-Patchstand gebracht werden. Für Windows 11 24H2 und 25H2 war im Juli 2026 beispielsweise KB5101650 relevant. Neuere kumulative Updates enthalten normalerweise die vorherigen Korrekturen.

Nach Installation und Neustart werden die Schritte zur Prozessprüfung und MSI-Deinstallation erneut ausgeführt.

Dieser Weg ist einem Patch-Rollback vorzuziehen, weil der aktuelle Sicherheitsstand erhalten bleibt. Eine erfolgreiche Deinstallation sollte zunächst auf einem repräsentativen Pilotgerät bestätigt werden, bevor die Änderung breit ausgerollt wird.

7. Validiertes PowerShell-Workaround verwenden

Wenn die Wazuh-Deinstallation weiterhin reproduzierbar an der VBScript-Custom-Action scheitert, kann ein von Wazuh bereitgestelltes und für den konkreten Fehler validiertes PowerShell-Workaround-Script verwendet werden.

Vor der Ausführung gelten folgende Mindestanforderungen:

Script nur aus einer vertrauenswürdigen Quelle beziehen.
Inhalt vor der Ausführung prüfen.
SHA-256-Hash dokumentieren.
Script lokal speichern und nicht direkt aus dem Internet ausführen.
PowerShell als Administrator starten.
keine dauerhafte Absenkung der systemweiten Execution Policy vornehmen.

Beispiel:

Get-FileHash `
    -Path ".\wazuh-uninstall-workaround.ps1" `
    -Algorithm SHA256

Unblock-File ".\wazuh-uninstall-workaround.ps1"

powershell.exe `
    -NoProfile `
    -ExecutionPolicy Bypass `
    -File ".\wazuh-uninstall-workaround.ps1"

ExecutionPolicy Bypass gilt hier nur für den gestarteten Prozess. Es ersetzt weder eine Signaturprüfung noch eine Codeprüfung.

Ein solches Script sollte dieselben Sicherheitsgrenzen wie der MSI-Uninstaller einhalten:

Wazuh-Dienst stoppen
verbleibende Agent-Prozesse beenden
benötigte Konfigurationsdateien sichern
Windows-Dienst kontrolliert entfernen
MSI-Registrierung bereinigen
ausschließlich Wazuh-spezifische Dateien und Registry-Einträge entfernen
einen nachvollziehbaren Ausführungslog erzeugen

Nicht geprüfte Cleanup-Scripte, die pauschal Verzeichnisse oder Registry-Zweige löschen, sind auf produktiven Endpoints ungeeignet.

8. Windows-Sicherheitsupdate nur als letzte Option entfernen

Das temporäre Entfernen des auslösenden Windows-Updates kann die ursprüngliche Script-Ausführung wiederherstellen. Es sollte jedoch nur eingesetzt werden, wenn:

kein aktueller kumulativer Fix verfügbar ist,
das validierte Workaround nicht eingesetzt werden kann,
das Agent-Upgrade betrieblich zwingend erforderlich ist,
die Sicherheitsauswirkungen bewertet wurden,
das Gerät während des Wartungsfensters anderweitig geschützt wird.

Beispiel für Windows 11 24H2 oder 25H2:

wusa.exe /uninstall /kb:5094126 /quiet /norestart

Die KB-Nummer darf nicht ungeprüft auf andere Windows-Versionen übertragen werden. Auf Systemen mit einem neueren kumulativen Update kann die einzelne Juni-KB außerdem bereits ersetzt worden sein und nicht mehr separat deinstalliert werden.

Nach dem Neustart sollte der Wazuh Agent entfernt, die neue Version installiert und anschließend unverzüglich wieder der aktuelle Windows-Patchstand hergestellt werden.

9. Bereinigung verifizieren

Nach der Deinstallation sollten mindestens Dienst, Prozesse, MSI-Registrierung und Installationspfad geprüft werden:

Get-Service -Name WazuhSvc -ErrorAction SilentlyContinue

Get-Process -Name "wazuh-agent" -ErrorAction SilentlyContinue

Get-ItemProperty $uninstallPaths -ErrorAction SilentlyContinue |
    Where-Object {
        $_.DisplayName -like "Wazuh Agent*"
    }

Test-Path "${env:ProgramFiles(x86)}\ossec-agent"

Ein noch vorhandenes Verzeichnis ist nicht automatisch ein Fehler. Je nach Deinstallationspfad können gesicherte Konfigurationsdateien oder Logs zurückbleiben. Diese sollten geprüft und erst danach kontrolliert archiviert oder gelöscht werden.

10. Neue Agent-Version installieren und Verbindung prüfen

Die Neuinstallation erfolgt mit dem freigegebenen Wazuh-MSI-Paket:

msiexec.exe `
    /i ".\wazuh-agent-<VERSION>.msi" `
    /qn `
    WAZUH_MANAGER="<MANAGER-FQDN-ODER-IP>" `
    /L*v "C:\Windows\Temp\wazuh-install.log"

Anschließend:

Start-Service -Name WazuhSvc
Get-Service -Name WazuhSvc

Zusätzlich muss im Wazuh Dashboard geprüft werden, ob der Endpoint wieder verbunden ist und aktuelle Daten liefert.

Die lokale Deinstallation des Agenten entfernt nicht automatisch den Agent-Datensatz auf dem Wazuh Manager. Bei einem In-Place-Upgrade sollte die bestehende Identität in der Regel erhalten bleiben. Wird der Endpoint dauerhaft außer Betrieb genommen, muss der Agent zusätzlich über das Dashboard oder die Wazuh API aus dem Manager-Inventar entfernt werden.

Lessons Learned / Best Practices

Windows-Patches müssen auch gegen Security-Agent-Lifecycle-Tests geprüft werden

Pilotgruppen sollten nicht nur prüfen, ob der Wazuh Agent nach einem Windows-Update weiterhin Events sendet. Zur Abnahmematrix gehören auch:

Neuinstallation
Dienststart und Dienststopp
Upgrade
WPK-Upgrade
MSI-Reparatur
unbeaufsichtigte Deinstallation
anschließende Neuinstallation

Ein Agent, der Daten sendet, aber nicht mehr aktualisiert oder entfernt werden kann, stellt ein verzögertes Betriebsrisiko dar.

MSI-Protokolle gehören in jedes Softwareverteilungssystem

Installations- und Deinstallationsbefehle sollten grundsätzlich mit ausführlicher Protokollierung ausgeführt werden:

/L*v C:\Windows\Temp\<produkt>-<aktion>.log

Ohne MSI-Protokoll ist Fehler 1603 kaum belastbar zu analysieren. Zentrale Deployment-Systeme sollten Exitcode, Logdatei und installierte Produktversion gemeinsam erfassen.

ProductCodes sind zuverlässiger als Paketdateinamen

Der Dateiname eines MSI-Pakets sagt nicht zwingend aus, welches Produkt aktuell in Windows registriert ist. Besonders nach Remote-Upgrades sollte die Deinstallation über den registrierten ProductCode erfolgen.

Konfiguration und Agent-Identität getrennt behandeln

ossec.conf enthält die lokale Agent-Konfiguration. client.keys enthält dagegen die kryptografische Agent-Identität. Beide Dateien benötigen unterschiedliche Wiederherstellungs- und Schutzregeln.

Insbesondere dürfen vorbereitete Windows-Images keine produktive client.keys enthalten. Jeder geklonte Endpoint muss eine eigene Identität erhalten.

Security-Agent-Ausfälle müssen als Monitoring-Lücke behandelt werden

Während Deinstallation, Cleanup und Neuinstallation sendet der Endpoint keine oder nur unvollständige Telemetrie an den Wazuh Manager. Bei größeren Rollouts sollten deshalb folgende Informationen überwacht werden:

Zeitpunkt des letzten Agent-Kontakts
Dauer der Unterbrechung
erfolgreiche Neuinstallation
erneute Registrierung
korrekte Gruppenzuweisung
Empfang aktueller Events
FIM-, SCA- und Syscollector-Status

Workaround-Scripte benötigen denselben Governance-Prozess wie Softwarepakete

Ein administratives Cleanup-Script kann Dienste, Dateien und Registry-Einträge entfernen. Es muss daher versioniert, geprüft, gehasht, getestet und zentral freigegeben werden. Ein Script aus einem vergänglichen Kommunikationsverlauf sollte nicht die einzige Dokumentation eines kritischen Wiederherstellungsverfahrens sein.

Abhängigkeiten von VBScript langfristig abbauen

Microsoft hat die schrittweise Ablösung von VBScript angekündigt. Installer und Betriebsprozesse, die weiterhin von VBScript-Custom-Actions abhängen, sollten deshalb in den Kompatibilitätstests besonders berücksichtigt und langfristig auf modernere Mechanismen umgestellt werden.

Fazit

Eine fehlgeschlagene Wazuh-Agent-Deinstallation mit MSI-Fehler 1603 ist nicht automatisch ein Berechtigungsproblem. Entscheidend ist der konkrete Fehlerpfad im ausführlichen MSI-Protokoll.

Tritt der Fehler nach den Windows-Updates vom Juni 2026 innerhalb von CustomAction_RemoveAllScript zusammen mit VBScript-Fehler 457 auf, sollte die Fehlerbehebung in einer kontrollierten Reihenfolge erfolgen: Betriebssystem und KB-Stand erfassen, Konfiguration sichern, registrierten ProductCode verwenden, Dienst und Prozesse vollständig stoppen, aktuellen kumulativen Windows-Patch installieren und die Standarddeinstallation erneut testen.

Erst wenn dieser Weg scheitert, sollte ein validiertes PowerShell-Cleanup eingesetzt werden. Das Entfernen eines Windows-Sicherheitsupdates bleibt die letzte Option und muss zeitlich begrenzt sowie durch eine dokumentierte Risikobewertung abgesichert werden.

Für den dauerhaften Betrieb ist vor allem eines wichtig: Windows-Patchtests müssen den vollständigen Lifecycle des Security-Agenten abdecken. Nur so wird verhindert, dass ein scheinbar erfolgreicher Patch-Rollout spätere Wazuh-Upgrades oder Notfallmaßnahmen blockiert.