Activation Windows avec clé client KMS (GVLK) : guide complet, étapes, scripts et dépannage

Tout savoir pour activer légalement et à grande échelle Windows avec une clé client KMS (GVLK) : principes, prérequis, étapes détaillées, scripts PowerShell, bonnes pratiques de sécurité et procédures de dépannage en environnement d’entreprise (poste, serveur, VDI, sites distants).

Sommaire

Vue d’ensemble de la question

L’échange porte sur :

la signification des clés client KMS publiées par Microsoft ;
la possibilité de les utiliser pour activer les systèmes d’exploitation Windows d’une organisation ;
la marche à suivre et les contraintes associées.

Réponse & solution condensées

Point clé	Explications & bonnes pratiques
Rôle des clés client KMS	Les Generic Volume License Keys (GVLK) n’accordent pas de droits de licence. Elles indiquent simplement à Windows de chercher un hôte KMS interne pour son activation.
Conditions d’utilisation	Être titulaire d’un contrat de licence en volume (Open, MPSA, EA, etc.). Disposer d’un hôte KMS (VM ou serveur) activé auprès de Microsoft à l’aide d’une clé hôte KMS (obtenue sur le portail de licences). Respecter les seuils : ≥ 25 clients pour les éditions cliente (Pro, Enterprise) ou ≥ 5 serveurs pour les éditions serveur afin que l’hôte commence à délivrer des activations.
Déploiement côté clients / serveurs	Installer/imaginer Windows en édition Volume (ou convertir avec `DISM /online /Set-Edition` si nécessaire). Entrer la clé client KMS : `slmgr /ipk <GVLK>` Vérifier que le DNS contient l’enregistrement SRV _vlmcs._tcp@domaine pointant vers l’hôte KMS (port 1688 par défaut) ou, à défaut, forcer l’adresse : `slmgr /skms <nom_hôte>:1688` Activer : `slmgr /ato` et contrôler : `slmgr /dlv`
Sécurité & périmètre	Les GVLK sont publiques ; elles peuvent donc figurer sur Internet sans risque, mais ne fonctionnent qu’en interne. Les partager n’a d’utilité que pour vos propres déploiements.
Alternatives	MAK (Multiple Activation Key) : activation directe auprès de Microsoft ; utile pour sites isolés. Active Directory-Based Activation (ADBA) : si votre forêt est ≥ Windows Server 2012, l’activation peut être intégrée à AD, évitant l’hôte KMS dédié.
Bonnes pratiques supplémentaires	Sauvegarder le fichier d’activation (`tokens.dat`) de l’hôte KMS. Surveiller le compteur d’activation KMS (`slmgr /dli`) pour éviter de descendre sous le seuil. Ouvrir le port 1688/TCP et autoriser l’hôte dans les GPO pare‑feu. Documenter chaque clé hôte et son usage (nombre d’activations restantes).

Informations complémentaires utiles

Mixité versions/éditions : un même hôte KMS peut activer plusieurs versions, mais il doit exécuter l’OS le plus récent de la plage qu’il couvre (ex. KMS 2022 active Server 2022, 2019, 2016…).
Renouvellement automatique : les clients renouvellent leur activation tous les 7 jours et expirent après 180 jours s’ils ne recontactent plus l’hôte.
Audit : conserver les preuves d’achat (contrat VL) ; en cas d’audit logiciel, le KMS est examiné en même temps que les factures.

Conclusion rapide : oui, vous pouvez utiliser les clés client KMS listées publiquement pour vos serveurs et postes, à condition de disposer des licences en volume correspondantes et de configurer correctement un hôte KMS ou une activation ADBA dans votre réseau.

Comprendre l’architecture KMS en 5 minutes

KMS (Key Management Service) centralise l’activation des produits Windows en environnement d’entreprise. Les composants clés sont :

Hôte KMS : serveur (ou VM) portant la clé hôte KMS. Il répond sur TCP/1688 aux requêtes d’activation.
Clients KMS : machines Windows configurées avec une GVLK. Elles interrogent l’hôte via DNS (enregistrement SRV _vlmcs._tcp).
Seuils d’activation : l’hôte KMS commence à délivrer des activations à partir de 25 clients (édition cliente) ou 5 serveurs.
Renouvellement : chaque client réactive périodiquement (7 jours par défaut) et reste valide 180 jours sans contact.

Quand choisir ADBA ? Si votre AD est au niveau Windows Server 2012 ou plus, ADBA permet d’éviter un hôte dédié : la clé hôte KMS est publiée dans AD et l’activation se fait automatiquement lors de la jointure au domaine.

Pré‑requis, conformité et sécurité

Pré‑requis

Contrat de licences en volume valide (EA/MPSA/Open).
Accès aux clés hôte KMS et au média Volume (ISO VL).
Serveur Windows supporté (idéalement la version la plus récente en production) pour héberger KMS.
Résolution DNS interne correctement configurée.
Pare-feu autorisant TCP/1688 depuis les sous-réseaux concernés.

Conformité

Une GVLK ne remplace pas un droit de licence. Elle oriente seulement l’activation.
Documentez la correspondance machines ↔ droits acquis (postes, serveurs, VDI).
Tracez toute opération d’ajout/remplacement de clés hôte KMS.

Sécurité

Restreignez l’accès au port 1688 aux seules IP internes.
Surveillez les journaux du service de protection logicielle.
Sauvegardez %systemroot%\System32\spp\store\2.0\tokens.dat côté hôte.

Mise en œuvre pas à pas

Étape 1 — Préparer l’hôte KMS

Installez une VM/serveur Windows (ex. Windows Server 2022) avec les dernières mises à jour.
Installez la clé hôte KMS (clé de votre contrat) : slmgr /ipk <Clé_Hôte_KMS> slmgr /ato slmgr /dlv La commande /dlv confirme l’activation et affiche le Current count (compteur de clients/serveurs découverts).
Publiez l’enregistrement SRV DNS : _vlmcs._tcp.<votre_domaine> SRV 0 0 1688 <nom_hôte_KMS> Si vous utilisez plusieurs sites, publiez un SRV par site ou utilisez des poids/priorités.

Étape 2 — Préparer les clients/serveurs

Vérifiez l’édition : utilisez une édition VL ou convertissez-la. DISM /online /Get-TargetEditions DISM /online /Set-Edition:<Cible> /ProductKey:<GVLK> /AcceptEula Exemples de cibles : Enterprise, Education, Professional (ou variantes Volume selon OS). Redémarrage requis.
Installez la GVLK et forcez l’hôte si nécessaire : slmgr /ipk <GVLK> slmgr /skms <nom_hôte_KMS>:1688 slmgr /ato
Contrôlez l’état : slmgr /dlv slmgr /dli Vérifiez : License Status: Licensed, Product Key Channel: Volume:GVLK, et la date d’expiration (180 jours).

Étape 3 — Automatiser (GPO & scripts)

Via GPO (poste/serveur) :

Script d’ouverture de session/démarrage : slmgr /ipk <GVLK> puis slmgr /ato.
Préférences de Registre pour définir KeyManagementServiceName et KeyManagementServicePort si vous ne publiez pas le SRV.
GPO Pare‑feu : règle entrante TCP/1688 sur l’hôte KMS.

PowerShell (exemples) :

# Forcer KMS sur un poste
cscript.exe C:\Windows\System32\slmgr.vbs /ipk <GVLK>
cscript.exe C:\Windows\System32\slmgr.vbs /skms kms.corp.local:1688
cscript.exe C:\Windows\System32\slmgr.vbs /ato

# Vérifier côté client

cscript.exe C:\Windows\System32\slmgr.vbs /dlv

# Tester la résolution DNS du SRV

nslookup -type=SRV _vlmcs._tcp.

Scénarios de déploiement types

Scénario	Approche recommandée	Points d’attention
Siège + agences reliées en MPLS/VPN	Un hôte KMS central. Publier le SRV DNS au niveau de la zone principale.	Latence raisonnable ; ouvrir 1688 depuis les VLANs des agences.
Sites isolés sans connectivité permanente	Utiliser des activations MAK pour ces machines.	Suivre le stock de MAK (compteur d’activations) et conserver les justificatifs.
VDI non‑persistant	KMS recommandé ; préparation du master avec GVLK, sysprep, et vérif. du seuil.	Éviter la surconsommation du compteur ; planifier le « rearm » du master si nécessaire.
Forêt AD moderne	ADBA : publier l’activation dans AD pour simplifier.	Contrôler les autorisations, la réplication AD et le niveau fonctionnel.

Vérifications, commandes et journaux

Commandes `slmgr` utiles

slmgr /ipk <GVLK> : installe la GVLK.
slmgr /skms <hôte>:1688 : définit l’hôte KMS manuellement.
slmgr /ato : tente l’activation immédiate.
slmgr /dli : état concis de la licence.
slmgr /dlv : état détaillé (canal, compteur, expiration).
slmgr /upk : désinstalle la clé produit (avec prudence).
slmgr /rearm : réinitialise la période de grâce (nombre de réarmements limité).

Résolution de nom et connectivité

nslookup -type=SRV _vlmcs._tcp.<domaine>
Test-NetConnection <hôte_KMS> -Port 1688
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform"

Journaux à consulter

Observateur d’événements > Applications et services > Software Protection Platform Service.
Journaux système (pare‑feu, DNS) si la détection échoue.
Fichier %windir%\system32\spp\logs pour des diagnostics avancés.

Procédure de déploiement en masse (exemple)

Exemple de script PowerShell pour un lot de postes :

$machines = Get-Content .\liste-postes.txt
$kmsHost = "kms.corp.local:1688"
$gvlk    = "<GVLK>"  # Remplacer par la GVLK correspondant à l’édition

foreach($m in $machines){
try {
Invoke-Command -ComputerName $m -ScriptBlock {
param($kms,$key)
cscript.exe $env:windir\system32\slmgr.vbs /ipk $key | Out-Null
cscript.exe $env:windir\system32\slmgr.vbs /skms $kms | Out-Null
cscript.exe $env:windir\system32\slmgr.vbs /ato  | Out-Null
} -ArgumentList $kmsHost,$gvlk -ErrorAction Stop
Write-Host "[OK] $m activé via KMS"
} catch {
Write-Warning "[KO] $m : $($_.Exception.Message)"
}
}

Adaptez cette logique dans un outil de gestion (SCCM/MECM, Intune en mode hybride avec script, Ansible/WinRM, etc.).

Bonnes pratiques d’exploitation

Standardisez un unique nom d’hôte KMS (ex. kms.corp.local) et utilisez un alias DNS (CNAME) pour faciliter les changements.
Haute disponibilité : un seul hôte suffit en général ; pour de très grands parcs, publiez plusieurs SRV avec priorités/poids.
Surveillez le compteur (Current count) : alerte si < 25 (clients) ou < 5 (serveurs).
Sécurisez l’accès au port 1688 aux sous‑réseaux autorisés (pare‑feu, ACL, segmentations).
Documentez les clés hôte, l’inventaire des éditions et l’emplacement du fichier tokens.dat.
Mise à jour : gardez l’hôte au niveau OS le plus récent supporté pour couvrir les clients modernes.

Dépannage : erreurs courantes et correctifs

Symptôme	Cause probable	Correctif
« No Key Management Service (KMS) could be contacted »	SRV DNS manquant/erroné, port 1688 bloqué, nom d’hôte KMS faux.	Publier/valider `_vlmcs._tcp`, ouvrir 1688/TCP, `slmgr /skms <hôte>:1688`.
Échec d’activation avec GVLK valide	L’hôte n’a pas atteint le seuil ou n’est pas activé.	Vérifier `slmgr /dlv` côté hôte ; monter le parc au‑delà de 25/5, activer l’hôte (`/ato`).
Client bascule en « Notification » après quelques mois	Pas de contact KMS depuis > 180 jours.	Rétablir la connectivité, `slmgr /ato`, vérifier les routes VPN et le DNS split‑brain.
Édition non compatible KMS	Image Retail/OEM, pas d’édition Volume.	`DISM /online /Set-Edition:<Cible> /ProductKey:<GVLK> /AcceptEula` puis redémarrer.
ADBA ne fonctionne pas	Niveau fonctionnel/permissions AD, clé hôte non publiée.	Publier la clé via l’assistant ADBA, vérifier la réplication et les autorisations d’écriture AD.
Multiples hôtes KMS visibles	Ancien enregistrement SRV non supprimé.	Nettoyer les SRV obsolètes et purger le cache DNS des clients (`ipconfig /flushdns`).

ADBA en pratique (alternative à KMS dédié)

Active Directory-Based Activation enregistre la clé hôte directement dans AD. Tout ordinateur membre du domaine et éligible s’active automatiquement, sans requérir la résolution du SRV _vlmcs._tcp.

Quand choisir ADBA ?

Unique forêt AD (ou forêts approuvées) et postes toujours joints au domaine.
Volonté de réduire la surface d’attaque (pas d’écoute 1688 sur un hôte dédié).

Étapes simplifiées

Sur un DC ou une machine avec RSAT, lancer l’assistant « Volume Activation Tools ».
Choisir « Active Directory-Based Activation », renseigner la clé hôte KMS, activer.
La publication crée les objets nécessaires dans la configuration AD ; les clients s’activent à la prochaine évaluation.

Pensez à la surveillance : journal Software Protection Platform Service, rapports d’état via VAMT si vous l’utilisez.

FAQ : questions fréquentes

Une GVLK suffit‑elle à être conforme ?

Non. La GVLK ne confère aucun droit ; elle sert uniquement à orienter l’activation vers KMS/ADBA. Les droits proviennent de votre contrat Volume. Faut‑il Internet pour KMS ?

Seul l’hôte KMS doit être activé une fois auprès de Microsoft. Les clients n’appellent que l’hôte interne (pas Internet). Peut‑on activer plusieurs versions depuis un seul hôte ?

Oui, tant que l’hôte est suffisamment récent pour couvrir la plage des versions à activer. Maintenez‑le à jour. Et si le parc passe temporairement sous le seuil ?

Les clients déjà activés restent valides jusqu’à leur expiration. De nouvelles activations peuvent échouer tant que le seuil n’est pas atteint. Intune/MECM avec KMS, possible ?

Oui. Déployez les GVLK et la configuration KMS via scripts/profils, tout en conservant KMS ou ADBA côté infrastructure.

Checklist « prêt pour l’audit »

Contrat de licences en volume et preuves d’achat archivés.
Documentation de l’hôte KMS (clé hôte, serveur, sauvegarde de tokens.dat).
Inventaire des éditions déployées (Pro/Enterprise/Server), volume vs retail/OEM.
Politique de bascule MAK claire pour sites isolés.
Procédure de continuité (VM de secours, alias DNS, export/import de l’activation si réinstallation).

Exemples concrets de commandes par cas d’usage

Cas	Commande	Effet
Forcer l’hôte KMS	`slmgr /skms kms.corp.local:1688`	Ignore le SRV DNS et contacte l’hôte indiqué.
Retour à la détection DNS	`slmgr /ckms`	Supprime l’hôte forcé et revient au SRV `_vlmcs._tcp`.
Activer immédiatement	`slmgr /ato`	Déclenche l’activation sans attendre la planification.
Afficher l’état détaillé	`slmgr /dlv`	Canal, compteur, ID d’installation, expiration (180 jours).
Changer d’édition vers Enterprise	`DISM /online /Set-Edition:Enterprise /ProductKey:<GVLK> /AcceptEula`	Convertit l’édition et installe la GVLK correspondante (redémarrage nécessaire).

Ergonomie et opérations quotidiennes

Tableaux de bord : un simple script PowerShell peut agréger /dli ou l’API WMI de la plateforme de protection logicielle pour dresser un état des postes.
Alertes : surveillez le compteur de l’hôte KMS et le taux d’échec d’activation sur 7 jours.
Changement d’hôte : si vous migrez, maintenez l’ancien en parallèle, publiez le nouveau SRV avec une priorité supérieure, puis retirez l’ancien après propagation.
Postes nomades : prévoyez une fenêtre de connexion VPN périodique (≤ 180 jours) pour renouveler l’activation.

Résumé opérationnel

GVLK ≠ licence : elle oriente l’activation vers un hôte KMS/ADBA. Avec un contrat VL valide, mettez en place un hôte KMS (ou ADBA), publiez _vlmcs._tcp en DNS, ouvrez le port 1688, convertissez les éditions si besoin, poussez la GVLK et validez slmgr /ato. Surveillez le compteur (≥ 25/5) et automatisez via GPO/PowerShell. Pour les sites isolés, optez pour MAK. Avec cette méthode, l’activation Windows devient fiable, reproductible et audit‑ready.

Modèle de procédure interne (copier‑coller)

1) Conformité
   - Vérifier le contrat VL et l’accès à la clé hôte KMS.
   - Lister les éditions cibles (Pro/Enterprise/Server).

2. Préparer l’hôte

   * Installer la clé hôte: slmgr /ipk  ; slmgr /ato
   * Publier le SRV DNS: _vlmcs._tcp. → :1688
   * Ouvrir TCP/1688 sur le pare-feu serveur et réseau.

3. Préparer les images

   * DISM /online /Set-Edition: /ProductKey: /AcceptEula
   * Sysprep des masters (poste/VDI).

4. Déploiement

   * slmgr /ipk  ; slmgr /ato
   * Vérifier: slmgr /dlv (Status: Licensed).

5. Exploitation

   * Supervision du compteur KMS et des journaux.
   * Sauvegarde de tokens.dat ; PRA KMS documenté.

6. Dépannage rapide

   * nslookup SRV, Test-NetConnection 1688
   * slmgr /ckms (retour auto), /skms (forcer), /ato (forcer activation)

Points clés SEO à retenir (pour les lecteurs pressés)

Activer Windows avec une clé client KMS (GVLK) nécessite un contrat Volume et un hôte KMS/ADBA.
Seuils : 25 clients / 5 serveurs. Port 1688/TCP. SRV DNS _vlmcs._tcp.
Renouvellement : tentative toutes les 7 jours, expiration à 180 jours sans contact.
Alternatives : MAK pour sites isolés, ADBA pour AD moderne.
Automatisation : slmgr, DISM, GPO, PowerShell, VAMT.

Activation Windows avec clé client KMS (GVLK) : guide complet, étapes, scripts et dépannage