Beim Installieren eines Windows-Product-Keys oder Konfigurieren der KMS-Aktivierung erscheint 0x80041008 – „Invalid parameter (SWbemObjectEx)“? Nach den November-Sicherheitsupdates 2026 ist dieses Fehlerbild von Microsoft bestätigt. Seit dem 13. November stehen passende Out-of-Band-Updates bereit.
Recherche- und Prüfstand: 14. November 2026. Diese Anleitung behandelt den aktuellen Fehler bei Windows-Lizenzierungsbefehlen. Derselbe WMI-Code kann in anderen Anwendungen andere Ursachen haben. Prüfe deshalb immer den fehlgeschlagenen Vorgang und den installierten Windows-Stand.
Was bedeutet 0x80041008 bei der Windows-Aktivierung?
Microsoft ordnet den Code in der WMI-Fehlerreferenz dem Wert wbemErrInvalidParameter zu: Ein Parameter des Aufrufs ist ungültig. WMI ist eine Windows-Verwaltungsschnittstelle, über die unter anderem Skripte Informationen und Verwaltungsfunktionen abrufen.
Die Meldung ist zunächst eine Rückgabe dieser Schnittstelle. Aus ihr allein folgt weder, dass Dein Product Key ungültig ist, noch, dass eine Neuinstallation nötig wäre. Entscheidend ist, ob sie beim aktuell dokumentierten Lizenzierungsvorgang oder beispielsweise in einer völlig anderen WMI-Abfrage erscheint.
Das Windows-Nachrichtencenter bestätigt eine Störung nach dem Sicherheitsupdate vom November 2026. Sie betrifft vor allem Organisationen mit SLMGR-Skripten, automatischer Schlüsselinstallation oder KMS-Konfiguration. KMS steht für Key Management Service und dient der Volumenaktivierung innerhalb einer Organisation. Bereits aktivierte Geräte bleiben laut Microsoft aktiviert.
Woran erkennst Du das bestätigte November-Problem?
Microsoft nennt im Fehlerhinweis zu KB5131096 insbesondere Aufrufe von slmgr.vbs /skms-domain <domain> und slmgr.vbs /ipk <key>. Der erste konfiguriert die KMS-Suchdomäne, der zweite installiert einen Product Key. Die Platzhalter stehen hier nur zur Einordnung; führe diese Änderungsbefehle nicht probeweise aus.
Wenn KMS-Clientschlüssel und Konfiguration bereits vorhanden sind und keine betroffenen Befehle benötigt werden, ist ein Gerät nicht automatisch beeinträchtigt. Eine fehlgeschlagene Konfigurationsänderung und ein verlorener Aktivierungsstatus sind unterschiedliche Befunde.
Lege vor weiteren Maßnahmen eine kurze Dokumentation an:
- Öffne
winverüber Windows + R und notiere Version und vollständigen Build. - Erfasse Edition und Systemarchitektur sowie die zuletzt installierten Qualitätsupdates.
- Notiere den konkreten Befehl, die vollständige Fehlermeldung und den Zeitpunkt. Ersetze echte Product Keys in Notizen für Dritte durch Platzhalter.
- Prüfe, ob der Fehler auf einem einzelnen Gerät, einem Master-Image oder in einer zentralen Verteilung auftritt.
In Windows PowerShell kannst Du die Versionsdaten ohne Änderung am System auslesen:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, DisplayVersion, CurrentBuild, UBR, EditionIDFür die Abfrage sind normalerweise keine Administratorrechte erforderlich. CurrentBuild und UBR bilden zusammen den vollständigen Build; die Werte helfen bei der Paketauswahl.
Warum kann das auch die Image-Erstellung stören?
Ein konkretes technisches Beispiel liefert Citrix in CTX697342: Nach dem November-Update weist der Windows-Lizenzierungs-WMI-Provider eine Abfrage der Client Machine ID bei der MCS-Imagevorbereitung zurück. Dadurch kann das anschließende Rearming scheitern. Citrix beschreibt also einen Fehler im Windows-Lizenzierungsablauf, keine fehlerhafte Eingabe des Administrators.
Bei Citrix DaaS kann dabei die Warnung ImagePreparationOSRearmFailed erscheinen. Diese Herstellerbeschreibung erklärt einen konkreten MCS-Fall; sie ist keine vollständige Ursachenanalyse für jedes Auftreten von 0x80041008. Auf einem normalen Client solltest Du deshalb keine Citrix-spezifischen Maßnahmen ausführen.
Einfachste Lösung: passendes OOB-Update installieren
Microsoft veröffentlichte am 13. November 2026 folgende kumulative Korrekturen. „Out-of-Band“ bedeutet eine Veröffentlichung außerhalb des regulären Updateplans. Die Pakete sind als Nicht-Sicherheits-OOB-Updates bezeichnet, enthalten aber auch die Verbesserungen des vorherigen November-Sicherheitsupdates.
| System | OOB-Korrektur | Zielbuild |
|---|---|---|
| Windows 11 23H2 | KB5136483 | 22631.7714 |
| Windows 10 22H2 ESU / Enterprise LTSC 2021 (21H2) | KB5136493 | 19045.7850 / 19044.7850 |
| Windows Server 2019 / Windows 10 Enterprise LTSC 2019 | KB5136490 | 17763.9488 |
| Windows Server 2022 | KB5136487 | 20348.5873 |
| Windows Server 2025 | KB5136489 | 26100.33828 |
Die Versionszuordnung zählt: Das 23H2-Paket ist kein Update für Windows 11 24H2, 25H2 oder 26H2. Übertrage es nicht auf einen anderen Zweig. Ein Sonderpatch ersetzt außerdem keine Prüfung des Supportstatus. Zum Versionswechsel findest Du hier die separate Anleitung Windows 11 23H2: Support endet, aber kein Upgrade verfügbar?
Wo bekommst Du die Pakete?
Laut Microsoft werden die genannten Server- und Windows-10-OOB-Pakete ausschließlich über den Microsoft Update Catalog bereitgestellt. Für Windows 11 23H2 steht die Korrektur zusätzlich unter Einstellungen → Windows Update → Erweiterte Optionen → Optionale Updates zur Verfügung. Die jeweiligen KB-Artikel oben verlinken die offiziellen Downloads.
Installiere mit Administratorrechten das zur Edition, Architektur und Version passende Paket. Beachte zuvor die Voraussetzungen, bekannte Probleme und gegebenenfalls die Reihenfolge erforderlicher Checkpoint-Pakete im jeweiligen Artikel. Plane Datensicherung, Wartungsfenster und einen erforderlichen Neustart ein. Bei verwalteten Geräten übernimmt die IT Test und Freigabe; ändere keine Update-Richtlinien, nur um das Paket sofort zu erzwingen.
Aktivierungsstatus sicher kontrollieren
Öffne eine normale Eingabeaufforderung. Die folgenden Diagnosebefehle zeigen den Zustand und ändern weder Product Key noch KMS-Ziel; sie benötigen laut SLMGR-Dokumentation keine erhöhten Rechte:
cscript.exe //Nologo "%windir%\System32\slmgr.vbs" /dlv
cscript.exe //Nologo "%windir%\System32\slmgr.vbs" /xpr/dlv zeigt ausführliche Lizenzinformationen, /xpr den Ablauf der Aktivierung. Letzteres ist besonders für KMS-Clients relevant; dort ist ein Ablaufdatum nicht automatisch ein Fehler. Bewahre die Ausgabe auf, teile aber Geräte- und Lizenzkennungen nicht ungeprüft öffentlich.
Falls schon diese Abfragen scheitern, notiere den Fehler. Erzwinge den Test nicht durch Löschen von Lizenzdateien. Nach Installation und Neustart kontrollierst Du Build und Status erneut. Den ursprünglich fehlgeschlagenen Änderungsbefehl wiederholst Du nur, wenn er weiterhin fachlich erforderlich und freigegeben ist. Insbesondere /ipk kann einen vorhandenen Schlüssel ersetzen.
Fortgeschritten: neue KMS-Fehler nach dem Fix unterscheiden
Ist 0x80041008 behoben, aber die eigentliche Aktivierung scheitert anschließend mit einem anderen Code, beginnt eine neue Diagnose. Microsoft nennt in der KMS-Problembehandlung unter anderem Namensauflösung, Erreichbarkeit und den standardmäßigen TCP-Port 1688.
Auf einem KMS-Client kannst Du mit Windows PowerShell einen einzelnen Verbindungstest ausführen. Ersetze kms.intern.example durch den von Deiner IT bestätigten KMS-Host und gegebenenfalls den Port durch den tatsächlich verwendeten Wert:
Test-NetConnection -ComputerName 'kms.intern.example' -Port 1688Der Test braucht normalerweise keine Administratorrechte. TcpTestSucceeded : True bestätigt nur die TCP-Erreichbarkeit, keine erfolgreiche Lizenzierung. Nutze keine öffentlichen fremden KMS-Server und schalte die Firewall nicht pauschal ab.
Für die weitere Untersuchung gehören Lizenzkanal, passende Edition und Schlüsseltyp zusammen. Ein Parameterproblem kann auch durch einen tatsächlich fehlerhaften Aufruf entstehen. Verändert sich der Fehlercode, dokumentiere ihn separat, statt jede Aktivierungsstörung weiterhin dem November-Bug zuzuordnen.
Bei Citrix: Master-Image und Katalog prüfen
Citrix empfiehlt für den beschriebenen MCS-Fall, die Korrektur im Master-Image zu installieren, dieses herunterzufahren, einen neuen Snapshot zu erstellen und den Maschinenkatalog damit zu aktualisieren. Prüfe anschließend, ob die Imagevorbereitung ohne Rearm-Warnung abschließt. Eine ausschließlich auf einer bereits erzeugten VM installierte Korrektur ersetzt diesen Image-Schritt nicht.
Untersuche das Ergebnis im vorgesehenen Testkatalog, bevor Du produktive Kataloge aktualisierst. Dokumentiere Image- und Snapshot-Version. Ein erfolgreicher Kataloglauf und eine erfolgreiche Aktivierung sind getrennt zu kontrollieren.
Wenn der Fehler bleibt
Sichere Windows-Version, Edition, vollständigen Build nach dem Neustart, installierte Korrektur, genauen Aufruf und vollständige Meldung. Ergänze bei automatisierten Abläufen Benutzerkontext, Werkzeugversion und Zeitpunkt. Übergib diese Angaben an die IT, den Softwarehersteller oder Microsoft Support. Der ausgewertete Microsoft-Fehlerhinweis nennt keine eindeutige Event-ID für diesen Bug.
Vermeide einen WMI-Repository-Reset, das Löschen von tokens.dat, die Deinstallation des Product Keys oder pauschale Registry-Reparaturen auf Verdacht. Der bestätigte Fehler hat einen gezielten Update-Fix. Bleibt 0x80041008 außerhalb des beschriebenen Szenarios bestehen, muss die betroffene Verwaltungsabfrage gesondert untersucht werden.
Fazit
Prüfe zuerst, welcher Lizenzierungsvorgang scheitert und welches Windows tatsächlich installiert ist. Für den bestätigten November-Fehler stehen gezielte OOB-Pakete bereit. Danach kontrollierst Du sowohl den ursprünglichen Ablauf als auch den Aktivierungsstatus. Eine fehlerhafte SLMGR-Ausführung allein ist kein Grund, eine vorhandene Aktivierung zurückzusetzen.