Microsoft-Aktivierungsfehler beheben: 0xC004F074 & Co.

Fehler richtig einordnen: KMS, MAK oder Key-Problem?

Aktivierungsfehler mit Codes der Form 0xC004… oder 0x8007… betreffen fast immer Volumenlizenz-Produkte, also Windows, Windows Server und Office-Volumeneditionen. Für die Fehlersuche zählt zuerst die Frage, mit welchem Schlüsseltyp das System arbeitet:

• GVLK (KMS-Client-Key): der öffentlich von Microsoft dokumentierte Setup-Key, auf Volumenlizenz-Medien bereits vorinstalliert. Ein GVLK aktiviert nie gegen Microsoft, sondern ausschließlich gegen einen KMS-Host im eigenen Netz. Typische Fehler: 0xC004F074, 0xC004F038, 0xC004F039, 0x8007007B.
• MAK (Multiple Activation Key): aktiviert einmalig direkt bei Microsoft (online oder offline über das Product Activation Portal) und hat ein begrenztes Aktivierungskontingent. Typische Fehler: 0xC004C020, 0xC004C021.
• KMS-Host-Key (CSVLK): aktiviert den KMS-Host selbst gegenüber Microsoft. Typischer Fehler: 0xC004C008.

Das Zusammenspiel der drei Aktivierungswege erklärt unsere Systemseite KMS vs. MAK vs. AD-Aktivierung; diese Seite hier ist die Fehler-Referenz für den Störfall.

Fehlercode-Referenz: die 8 wichtigsten Codes

Die Tabelle führt die 8 wichtigsten Aktivierungsfehler aus Microsofts offizieller Troubleshooting-Dokumentation auf (der Microsoft-Artikel dokumentiert insgesamt 29 Codes); die Fehlertexte sind wörtlich (gekürzt) übernommen.

Unter anderem für die Codes 0xC004F038, 0xC004F039, 0xC004F074, 0xC004C008 und 0x8007007B bietet Microsoft zusätzlich den Support and Recovery Assistant (SaRA) mit geführten Lösungen an. Fehlercode-Bedeutungen lassen sich auf Rechnern mit Office-Volumenlizenz auch lokal nachschlagen: cscript ospp.vbs /ddescr:0xC004F042 (Pfad und Aufruf: slmgr- und ospp-Referenz).

Die drei häufigsten Ursachen

1. Der KMS-Host ist nicht erreichbar

Hinter 0xC004F074, 0xC004F039 und 0x8007007B steckt fast immer ein Verbindungs- oder Namensauflösungsproblem: Der SRV-Record _vlmcs._tcp fehlt im DNS, eine Firewall blockiert TCP-Port 1688, oder der eingetragene Host existiert nicht mehr. Microsoft nennt für 0xC004F074 außerdem eine Zeitabweichung von mehr als 4 Stunden zwischen Client und Host als Hauptursache (verwandter Code 0xC004F06C); der dokumentierte Fix ist w32tm /resync. Besonderheit bei Azure-VMs: Die Aktivierung muss über eine Azure-Public-IP laufen, Forced Tunneling bricht sie.

2. Die Aktivierungsschwelle ist nicht erreicht

Ein KMS-Host spricht Aktivierungen erst ab einem Mindest-Count aus: 25 für Windows-Clients, 5 für Windows Server und Office-Volumeneditionen. Der Host zählt dabei nur eindeutige Kontakte der letzten 30 Tage und speichert maximal die 50 jüngsten. Fällt der Count unter die Schwelle, erhalten neue Clients 0xC004F038. In kleinen Umgebungen sind MAK oder die Active-Directory-basierte Aktivierung (ohne Schwellenwert) deshalb oft der bessere Weg.

3. Falscher Key-Typ: GVLK statt MAK (oder umgekehrt)

Ein GVLK funktioniert nicht als Retail-Lizenz und aktiviert nie direkt bei Microsoft. Wer auf einem Einzelgerät ohne KMS-Host den vorinstallierten GVLK belässt, produziert zwangsläufig KMS-Fehler. Umgekehrt führt ein Key, der nicht zur installierten Windows-Version passt, zu 0xC004F050. Die offiziellen GVLK-Listen pflegt Microsoft auf learn.microsoft.com (Quellenblock unten).

Diagnose in 6 Schritten

So grenzen Sie jeden Aktivierungsfehler systematisch ein. Alle Befehle laufen in einer Eingabeaufforderung; für einige sind Administratorrechte nötig.

1. Lizenz- und Aktivierungsstatus anzeigen: cscript slmgr.vbs /dlv ausführen. Die Ausgabe zeigt Edition, Lizenzstatus, Teil-Produktschlüssel und bei KMS-Clients den erkannten Host samt Port (Deutung der Felder: Windows-Aktivierung prüfen).
2. Fehlerdetails aus dem Ereignisprotokoll holen: Anwendungs-Ereignisprotokoll öffnen und alle Einträge mit Event-ID 12288 zum Aktivierungsversuch prüfen. Dort steht, welchen Host der Client kontaktiert hat und welcher Fehler zurückkam.
3. DNS-SRV-Record prüfen: Kontrollieren Sie in der DNS-Zone, ob der Eintrag für die KMS-Autoerkennung existiert und auf den richtigen Host zeigt. Dokumentierte Werte: Typ SRV, Service _vlmcs, Protokoll _tcp, Priority/Weight 0/0, Port 1688, Hostname = FQDN des KMS-Hosts.
4. Netzwerkpfad und Firewall prüfen: TCP-Port 1688 (Standard) darf auf dem Weg zum Host weder blockiert noch gefiltert sein.
5. Systemzeit abgleichen: Bei mehr als 4 Stunden Abweichung zwischen Client und Host schlägt die KMS-Aktivierung fehl; w32tm /resync synchronisiert die Zeit neu.
6. Count auf dem KMS-Host prüfen: Auf dem Host cscript slmgr.vbs /dli ausführen; die Ausgabe enthält den aktuellen Count. Liegt er unter 25 (Clients) beziehungsweise 5 (Server/Office), ist die Schwelle das Problem, nicht das Netzwerk.

Lösungswege je Fehlertyp

KMS-Client-Fehler (0xC004F074, 0xC004F038, 0xC004F039, 0x8007007B)

1. Diagnose-Schritte 1 bis 6 durchgehen und die gefundene Ursache beheben (DNS-Record anlegen, Firewall-Regel korrigieren, Zeit synchronisieren, Pool vergrößern).
2. Falls die DNS-Autoerkennung dauerhaft Probleme macht: KMS-Host fest eintragen mit slmgr.vbs /skms <Name:Port> und Aktivierung neu anstoßen mit slmgr.vbs /ato. Den festen Eintrag entfernt später slmgr.vbs /ckms (stellt die Autoerkennung wieder her).
3. Wenn kein KMS-Host mehr existiert oder die Schwelle dauerhaft unerreichbar ist: auf MAK umstellen (Key per slmgr.vbs /ipk, dann /ato) oder auf die Active-Directory-basierte Aktivierung wechseln (Anleitungen: KMS-Server einrichten, ADBA einrichten).

MAK-Fehler (0xC004C020, 0xC004C021)

1. Der Key ist nicht defekt, nur das Kontingent ist erschöpft: beim Microsoft Licensing Activation Center zusätzliche Aktivierungen (bei 0xC004C021: eine erneute Erweiterung) anfordern.
2. Ohne Internetzugang bleibt die Offline-Aktivierung über das Product Activation Portal, das seit Dezember 2025 die Telefonaktivierung ersetzt (Anleitung: MAK telefonisch aktivieren).

Host-Key- und Key-Fehler (0xC004C008, 0xC004F050)

1. Bei 0xC004C008 hat der KMS-Host-Key sein Limit erreicht (bis zu 10 Aktivierungen auf höchstens 6 Computern): zusätzliche Aktivierungen beim Activation Center anfordern.
2. Bei 0xC004F050 den Key Zeichen für Zeichen prüfen und sicherstellen, dass er zur installierten Windows-Version passt. Microsoft weist ausdrücklich darauf hin, dass die Zwischenablage beim Kopieren Bindestriche durch Gedankenstriche ersetzen kann, der Key dann also unbemerkt verfälscht ist.

Praxisbeispiel: 25 Mitarbeiter, Count zu niedrig

Ein Unternehmen mit 25 Arbeitsplätzen betreibt einen eigenen KMS-Host, der Count liegt damit exakt auf der Schwelle von 25. Im Herbst sind sechs Außendienst-Notebooks über 30 Tage nicht im Firmennetz; weil der Host nur eindeutige Kontakte der letzten 30 Tage zählt, sinkt der Count auf 19. Zwei neu installierte PCs melden daraufhin 0xC004F038. Die Diagnose auf dem Host (cscript slmgr.vbs /dli) macht die Ursache in einer Minute sichtbar. Die sinnvolle Lösung in dieser Größenordnung: die Außendienstgeräte auf MAK umstellen oder die Umgebung auf die Active-Directory-basierte Aktivierung heben, die ohne Mindest-Schwellenwert auskommt. Das Problem war nie die Lizenzzahl, sondern die Zählmechanik.

Fazit

Aktivierungsfehler folgen einem klaren Muster: KMS-Client-Codes deuten auf Netzwerk, DNS, Zeit oder Schwelle; MAK-Codes auf erschöpfte Kontingente; 0xC004F050 auf den falschen oder verfälschten Key. Mit slmgr /dlv, der Event-ID 12288 und dem SRV-Check ist die Ursache fast immer in Minuten gefunden. Wenn Sie beim Nachlizenzieren Volumenlizenzen benötigen: Der Lyzio-Shop führt geprüfte Gebrauchtlizenzen bis zu 80 % unter Neupreis, bei Fragen zur passenden Aktivierungsart hilft die Beratung.

Häufige Fragen