Votre clé Windows Server 2019 affiche « clé non valide » lors de l’activation ? Voici une procédure complète, pragmatique et sûre pour identifier la cause, corriger rapidement l’erreur et — si nécessaire — activer par une méthode alternative.
Vue d’ensemble
Le message « clé non valide » masque souvent d’autres causes : clé saisie avec une erreur, édition du système incompatible, image d’évaluation non convertie, canal (Retail/MAK/KMS/OEM) inadapté, connectivité réseau absente, activation dépassant le quota, etc. Cette page vous guide pas à pas, du diagnostic éclair à l’escalade maîtrisée, afin d’activer Windows Server 2019 de façon fiable.
Réponse & solution — vue rapide
Commencez par ce tableau récapitulatif, puis déroulez les sections détaillées ci‑après.
Étape | Action recommandée | Détails utiles |
---|---|---|
1. Vérifier la clé | Vérifier les caractères (O/0, I/1). Confirmer que la clé correspond bien à Windows Server 2019 et à l’édition installée (Standard, Datacenter). | Une clé Standard n’active pas Datacenter, et inversement. |
2. Valider l’édition installée | Ouvrir Paramètres > Système > À propos ou exécuter slmgr /dli pour identifier l’édition et le canal (Retail, OEM, Volume). | Une clé Retail n’active pas une image Volume et réciproquement. |
3. Conversion d’une version d’évaluation | Si « Evaluation » apparaît, convertir avant l’activation :dism /online /set-edition:ServerStandard /productkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /accepteula Redémarrer puis lancer slmgr /ato . | L’activation échoue tant que l’édition n’est pas passée de Evaluation à Retail/Volume. |
4. Vérifier la validité de la clé | Contrôler auprès du revendeur ou du portail volume que la clé n’est pas expirée et n’a pas dépassé son nombre d’activations (MAK). | Les clés MAK possèdent un quota d’activations limité. |
5. Contrôler la connectivité d’activation | Retail/MAK : accès HTTP/HTTPS sortant nécessaire. KMS : vérifier l’enregistrement DNS SRV ( nslookup -type=SRV _vlmcs._tcp ) puis définir le serveur : slmgr /skms <hote>:1688 . | Un proxy ou pare‑feu mal configuré génère souvent « clé non valide ». |
6. Réparer les fichiers système | Exécuter sfc /scannow puis, si besoin, dism /online /cleanup-image /restorehealth . | Des fichiers corrompus empêchent l’enregistrement de la licence. |
7. Escalade | Ouvrir un ticket Microsoft et communiquer l’ID d’erreur exact (slui 4 ou slmgr /ato retournent un code). | Exemples : 0xC004C020 (quota/clé bloquée), 0xC004F050 (clé non valide), 0xC004F074 (KMS introuvable). |
Arborescence de diagnostic (logique de décision)
- Le serveur indique‑t‑il « Evaluation » ? → Oui : convertir avec DISM (set‑edition) puis retenter l’activation. Non : étape suivante.
- L’édition/la version correspondent‑elles à la clé ? → Si doute, exécuter
dism /online /Get-CurrentEdition
etslmgr /dli
. Adaptez la clé au canal (Retail/MAK/KMS/OEM). - Quel est le canal prévu ?
- Retail/MAK : test réseau sortant HTTP/HTTPS, proxy WinHTTP et TLS.
- KMS : vérifier enregistrement DNS et connectivité vers l’hôte KMS (1688/TCP).
- ADBA (Activation basée sur Active Directory) : la machine est‑elle jointée au domaine et voit‑elle un objet ADBA valide ?
- AVMA (Activation automatique des VM) : invité hébergé sur un hôte Datacenter activé ?
- Le code d’erreur pointe‑t‑il vers la clé, le réseau, ou le service ? → reportez‑vous au tableau d’erreurs ci‑dessous.
- Le système est‑il sain ? →
sfc
/dism
, services, journaux SPP (Software Protection Platform).
Comprendre les canaux d’activation (et choisir le bon)
Canal | Usage typique | Clé à saisir | Point de contrôle | Remarques |
---|---|---|---|---|
Retail | Licences individuelles, serveurs isolés | Clé Retail 25 caractères | Accès Internet vers serveurs Microsoft | Possible activation par téléphone via slui 4 si réseau restreint |
MAK (Volume) | Environnements volume sans KMS | Clé MAK 25 caractères | Accès Internet (quota limité) | Compteur d’activations : surveiller le quota |
KMS (Volume) | Parcs de serveurs/PC, activation interne | Clé client KMS (GVLK) | Hôte KMS joignable sur 1688/TCP | Enregistrement DNS SRV _vlmcs._tcp ; seuil de compte KMS requis |
ADBA | Domaines AD, activation par AD | Clé client KMS (GVLK) | Objet ADBA publié dans AD | Nécessite le rôle « Volume Activation Services » |
AVMA | VM sur hôte Datacenter activé | Clé AVMA (dans l’invité) | Hyper‑V, communication hôte‑invité | Pas d’accès Internet requis pour la VM |
Important : Ne confondez pas la clé du serveur hôte KMS (CSVLK, installée sur la machine qui « sert » l’activation) et les clés clients KMS (GVLK, installées sur les machines à activer).
Étapes détaillées de résolution
Vérifier l’édition, la version et le canal
- Édition et version :
dism /online /Get-CurrentEdition dism /online /Get-TargetEditions systeminfo | findstr /i "OS Name OS Version"
- État de la licence :
slmgr /dli slmgr /dlv
/dli
donne un résumé rapide ;/dlv
affiche des détails (canal, ID d’activation, délais de grâce).
Si le serveur est en « Evaluation »
- Choisir la cible correspondant à votre clé :
ServerStandard
ouServerDatacenter
. - Lancer la conversion (exemple vers Standard) :
dism /online /set-edition:ServerStandard /productkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /accepteula
- Redémarrer, puis activer :
slmgr /ato
Astuce : si une mauvaise clé a été saisie auparavant, désinstallez‑la d’abord : slmgr /upk
, puis slmgr /cpky
pour purger la clé du registre. Réinstallez ensuite la clé correcte avec slmgr /ipk
avant /ato
.
Retail/MAK : vérifier le réseau sortant et le proxy
- Tester la sortie HTTP/HTTPS :
powershell -c "try { iwr https://www.microsoft.com -UseBasicParsing -TimeoutSec 10 | out-null; 'OK' } catch { 'ECHEC' }"
- Vérifier la configuration WinHTTP (le service d’activation l’utilise) :
netsh winhttp show proxy netsh winhttp reset proxy :: ou définir un proxy si nécessaire : netsh winhttp set proxy proxy-server="http=myproxy:8080;https=myproxy:8080"
- Heure et TLS : une date/heure incorrecte ou des suites TLS obsolètes peuvent bloquer l’activation. Synchronisez l’horloge (
w32tm /resync
), vérifiez vos politiques TLS si un proxy SSL inspecte le trafic.
KMS : vérifier DNS, seuil, routage et pare‑feu
- Résolution du service KMS :
nslookup -type=SRV _vlmcs._tcp nslookup kms.exemple.local
- Forcer le KMS si nécessaire :
slmgr /skms kms.exemple.local:1688 slmgr /ato
- Ouvrir 1688/TCP vers l’hôte KMS sur les pare‑feu. Sur l’hôte KMS, autoriser les clients et surveiller le compte d’activation (les clients/serveurs doivent atteindre un seuil pour que le KMS commence à activer).
- Si votre organisation utilise ADBA, assurez‑vous que le serveur est joint au domaine et qu’une clé Host a été installée via l’Assistant « Volume Activation Tools ».
Réparer le système si l’infrastructure est correcte
sfc /scannow
dism /online /cleanup-image /restorehealth
sc query sppsvc
sc query LicenseManager
Note : sppsvc
(Software Protection) et LicenseManager
doivent être en état RUNNING.
Activer hors ligne (téléphone) en dernier recours
Pour un serveur sans Internet ni KMS :
- Lancer
slui 4
. - Choisir votre pays, appeler le numéro indiqué.
- Fournir l’ID d’installation affiché et saisir l’ID de confirmation reçu.
Codes d’erreur fréquents et corrections
Code | Symptôme | Cause probable | Correction |
---|---|---|---|
0xC004F050 | Clé non valide | Clé mal saisie / édition ou canal incompatibles | Vérifier l’édition (dism /Get-CurrentEdition ) et le canal (slmgr /dlv ) puis resaisir une clé correspondante |
0xC004C003 | Clé bloquée | Clé annulée/blacklistée | Contacter le revendeur/Microsoft pour remplacement et vérifier la provenance de la clé |
0xC004C020 | Quota dépassé | MAK a atteint son nombre d’activations | Demander une extension du quota ou recycler les activations inutilisées via le support |
0xC004F074 | KMS introuvable | DNS SRV absent, port 1688 bloqué, mauvais hôte | Créer/corriger l’enregistrement _vlmcs._tcp , ouvrir 1688/TCP, slmgr /skms puis /ato |
0x8007232B | Nom DNS introuvable | Client en mode KMS mais serveur KMS absent de DNS | Basculer vers Retail/MAK (slmgr /ipk ) ou publier le SRV KMS |
0x80072F8F | Erreur de sécurité | Horloge/TLS/inspection SSL | Corriger la date/heure (w32tm ), ajuster proxy/inspection TLS |
Journaux et traces utiles
- Visionneuse d’événements → Applications and Services Logs → Microsoft → Windows → SoftwareProtectionPlatform (canaux Service/Platform)
- Historique PowerShell : consignez chaque tentative (date, édition, clé masquée, code retour) — utile pour l’escalade.
- Inventaire : conservez ID matériel et GUID machine si vous virtualisez et clônez des images.
Bonnes pratiques complémentaires
- Sauvegarde préalable : avant toute conversion d’édition, créez une sauvegarde ou un snapshot.
- Documentation : archivez la preuve d’achat et l’e‑mail de licence pour toute réclamation future.
- Automatisation : pour les déploiements à grande échelle, script PowerShell avec journalisation et codes d’erreur normalisés.
- Hygiène des clés : n’achetez pas de clés « marché gris ». Préférez les circuits officiels (revendeur agréé, portail volume).
- Images de référence : n’intégrez jamais une clé Retail/MAK dans une image maître. Utilisez GVLK (KMS/ADBA) ou AVMA dans les invités.
Script PowerShell prêt à l’emploi (diagnostic et activation)
Ce script ne stocke jamais la clé en clair : il vous la demande, la masque en log et retourne un statut compréhensible.
# Exécuter en PowerShell (Administrateur)
# Diagnostic + activation Windows Server 2019 (Retail/MAK/KMS)
# Journal : C:\ProgramData\ActivationWS2019.log
$Log = "C:\ProgramData\ActivationWS2019.log"
function Write-Log($msg){ ("{0} {1}" -f (Get-Date -f "yyyy-MM-dd HH:mm:ss"), $msg) | Tee-Object -FilePath $Log -Append }
Write-Log "=== DÉBUT DIAGNOSTIC ==="
$os = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion")
$edition = (dism /online /Get-CurrentEdition | Out-String)
$dlv = (cscript /nologo $env:SystemRoot\System32\slmgr.vbs /dlv | Out-String)
Write-Log "Nom OS: $($os.ProductName)"
Write-Log "Édition DISM: $([string]($edition -replace '\s+',' ')).Trim()"
Write-Log "Résumé SLMGR /DLV: $([string]($dlv.Split([Environment]::NewLine) | Select-Object -First 10) -replace '\s+',' ').Trim()"
$channelHint = if($dlv -match "VOLUME_*"){"VOLUME"} elseif($dlv -match "RETAIL"){"RETAIL"} else {"INCONNU"}
Write-Log "Canal probable: $channelHint"
$choice = Read-Host "Choisir le mode (RETAIL/MAK/KMS/ADBA/AVMA/QUIT)"
if($choice -eq "QUIT"){ Write-Log "Abandon utilisateur."; exit }
switch($choice){
"RETAIL" { $mode = "Retail"; }
"MAK" { $mode = "MAK"; }
"KMS" { $mode = "KMS"; }
"ADBA" { $mode = "KMS" } # côté client : GVLK comme KMS
"AVMA" { $mode = "AVMA"; }
default { $mode = "MAK"; }
}
if($mode -in @("Retail","MAK")){
$secureKey = Read-Host "Saisir la clé (xxxxx-xxxxx-...)" -AsSecureString
$key = (New-Object System.Net.NetworkCredential("", $secureKey)).Password
Write-Log "Clé saisie (masquée)."
cmd /c "cscript //nologo %windir%\system32\slmgr.vbs /ipk $key" | Out-Null
Write-Log "SLMGR /IPK exécuté."
cmd /c "cscript //nologo %windir%\system32\slmgr.vbs /ato" | Out-Null
Write-Log "SLMGR /ATO exécuté."
}
elseif($mode -eq "KMS"){
$kms = Read-Host "Nom d'hôte KMS (laisser vide si auto)"
if($kms){ cmd /c "cscript //nologo %windir%\system32\slmgr.vbs /skms $kms:1688" | Out-Null; Write-Log "KMS ciblé: $kms:1688" }
Write-Log "Assurez-vous d'avoir installé la GVLK correspondant à l'édition."
cmd /c "cscript //nologo %windir%\system32\slmgr.vbs /ato" | Out-Null
Write-Log "SLMGR /ATO exécuté."
}
elseif($mode -eq "AVMA"){
Write-Log "AVMA : installez la clé AVMA adaptée à l'édition dans la VM (non saisie ici)."
}
$rc = $LASTEXITCODE
Write-Log "Code retour: $rc"
Write-Log "=== FIN DIAGNOSTIC ==="
Write-Output "Journal : $Log"
Conseils : exécutez ce script sur une machine de test, validez le chemin de log et adaptez‑le à votre politique interne (proxy, KMS par défaut, etc.).
Check‑list réseau (Retail/MAK/KMS)
- Pare‑feu/Proxy : autoriser la sortie vers les services d’activation Microsoft (80/443) ou vers l’hôte KMS (1688/TCP).
- DNS : résolution du SRV
_vlmcs._tcp
et du FQDN de l’hôte KMS. Pas d’entrées obsolètes. - Heure : synchronisation NTP correcte (
w32tm /query /status
). - Inspection SSL : si activée, exclure les domaines Microsoft d’activation pour éviter les erreurs TLS.
Cas particuliers et pièges fréquents
- Clonage d’images : syspreppez vos images. Une activation faite dans l’image maîtresse peut entraîner des conflits et des clés « déjà utilisées ».
- Changement matériel majeur : certaines activations Retail/MAK peuvent demander une réactivation (téléphone).
- Éditions Core/GUI : l’édition (Standard/Datacenter) compte, pas l’interface. Les clés sont différentes par édition, pas par Shell.
- Monter de Standard vers Datacenter : possible via
dism /set-edition:ServerDatacenter
avec une clé valide Datacenter — sauvegardez avant. - AVMA : réservé aux VMs hébergées sur un hôte Hyper‑V Datacenter activé. N’essayez pas AVMA sur un hôte Standard : échec garanti.
Procédure d’escalade efficace
Si vous devez ouvrir un ticket au support :
- Inclure l’édition, la version (
systeminfo
), le canal (slmgr /dlv
). - Fournir le code d’erreur exact et un horodatage de l’échec.
- Joindre un extrait des journaux SPP (quelques lignes, sans clé en clair) et un schéma réseau simplifié si KMS/Proxy.
- Préciser la provenance de la clé (revendeur, contrat volume) et l’historique d’activation (si MAK).
FAQ rapide
Une clé Windows Server 2016 peut‑elle activer un 2019 ?
Non. Les clés sont liées à la version et à l’édition. Utilisez une clé Windows Server 2019 de la bonne édition.
Faut‑il Internet pour KMS/ADBA ?
Non pour les clients : ils contactent un hôte KMS ou AD local. En revanche, votre hôte KMS doit être activé avec une clé hôte valide (CSVLK), ce qui peut nécessiter un accès sortant au moins une fois.
Pourquoi mon serveur dit « clé non valide » alors que la clé est correcte ?
Ce message générique apparaît aussi quand l’édition ne correspond pas, que la machine est encore en « Evaluation », que le canal est incorrect (Retail vs Volume) ou quand le service d’activation n’atteint pas Internet/KMS.
Puis‑je « convertir » sans réinstaller ?
Oui, via dism /set-edition
avec une clé de la cible (Standard ↔ Standard, Datacenter ↔ Datacenter). La conversion entre éditions différentes (Standard → Datacenter) est possible mais irreversible sans réinstallation.
Quid des serveurs isolés (réseau fermé) ?
Utilisez la téléactivation (slui 4
) pour Retail/MAK, ou mettez en place un KMS dans la bulle isolée.
Exemples de commandes utiles (mémo)
Installer/retirer une clé
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /upk
slmgr /cpky
Activer
slmgr /ato
slui 4 :: activation par téléphone
Pointer un KMS
slmgr /skms kms.exemple.local:1688
slmgr /ckms :: revenir à la découverte auto
État & logs
slmgr /dli
slmgr /dlv
eventvwr.msc :: journaux SPP
Conclusion
Dans l’immense majorité des cas, le triptyque édition/canal corrects → conversion depuis Evaluation → connectivité d’activation rétablit une activation Windows Server 2019 en quelques minutes. Les scripts fournis, la matrice des canaux et la table des erreurs vous offrent une méthode reproductible pour traiter aussi bien un serveur unique qu’un déploiement à grande échelle. En cas de doute, sécurisez par une sauvegarde, consignez chaque essai et n’exposez jamais vos clés en clair.
Annexe : modèle de fiche d’escalade
Copiez/collez ce canevas pour accélérer vos échanges avec le support.
Environnement :
- Édition/version : ______________________
- Canal (prévu / détecté) : ______________
- Méthode d'activation : Retail / MAK / KMS / ADBA / AVMA
- Contexte réseau : Proxy ? Oui / Non — DNS interne ? Oui / Non
- Hôte KMS (si applicable) : ________________
Symptôme :
* Message exact : __________________________
* Code d'erreur : 0x________________________
* Fréquence : À la demande / Aléatoire / Permanent
Actions déjà tentées :
* Conversion DISM ? Oui / Non
* SLMGR (ipk/ato) ? Oui / Non
* SFC/DISM (réparation) ? Oui / Non
* Vérifs DNS/Proxy/Ports ? Oui / Non
Pièces jointes :
* Extraits SLMGR /DLV (sans clé)
* Événements SPP pertinents (horodatés)
* Traçage réseau si KMS