Si vous avez déjà eu une machine Windows parfaitement fonctionnelle qui a commencé à afficher des messages d’activation après un changement matériel,
une opération d’image système, ou une modification « mineure » de la politique d’entreprise, vous avez rencontré le problème : les gens traitent les clés produit,
les licences numériques et l’activation comme interchangeables. Ce n’est pas le cas. Et les conséquences de deviner sont réelles — temps d’arrêt,
risques de conformité et une file d’assistance qui sent le toast brûlé.
Voici le modèle mental opérationnel correct : une clé produit est une entrée,
une licence numérique est un droit stocké, et l’activation est la machine d’état
qui décide si Windows vous croit.
Les trois termes que vous confondez
Clé produit : l’identifiant que vous tapez (ou injectez)
Une clé produit est typiquement une chaîne de 25 caractères (cinq groupes de cinq) qui identifie une revendication de licence.
Pensez-y comme un numéro de badge. Elle peut être :
- Retail (achetée en boîte/magasin numérique ; transférable sous certaines limites)
- OEM (liée à l’appareil d’origine ; généralement pas destinée à être déplacée)
- Volume (MAK ou clés de configuration client KMS ; régies par des accords organisationnels)
Une clé n’est pas synonyme d’activation. Vous pouvez avoir une clé parfaitement valide et malgré tout échouer à activer parce que :
le serveur d’activation est injoignable, la clé a été bloquée, votre matériel a changé, l’édition ne correspond pas,
ou l’horloge système fait du voyage dans le temps.
Licence numérique : le droit que Windows mémorise
Une licence numérique (souvent appelée digital entitlement dans les anciens termes) est l’enregistrement stocké par Microsoft
qui indique : « Cet appareil, avec cette identité matérielle, a le droit d’exécuter cette édition. »
Ce n’est pas une clé que vous tapez. C’est une association.
Le plus souvent, les licences numériques apparaissent quand :
- Vous passez d’une ancienne version de Windows à Windows 10/11 et Microsoft enregistre le droit.
- Vous vous connectez avec un compte Microsoft et liez l’activation à ce compte (utile pour les changements matériels).
- Vous achetez Windows sur le Microsoft Store et il est lié à votre compte/identité d’appareil.
Implication opérationnelle : si vous réinstallez une machine et qu’elle possède une licence numérique, l’activation peut revenir
automatiquement—si l’édition correspond et que l’identité matérielle est « suffisamment proche » pour Microsoft.
Activation : l’état du système, pas un achat
L’activation est la décision de Windows que l’installation courante est licenciée et doit cesser
de se comporter comme une période d’essai. L’activation est appliquée par un sous-système de licences qui évalue :
- Le canal et la politique de licence (Retail/OEM/Volume)
- L’alignement d’édition (Home vs Pro vs Enterprise)
- L’identité matérielle (surtout pour les licences numériques Retail/OEM)
- La connectivité et la capacité de joindre les services (Microsoft, ou KMS en entreprise)
- La validité dans le temps (l’activation KMS attend des renouvellements)
L’activation est une machine d’état : elle peut être activée, non activée, en grâce, en mode notification, ou « activée mais sur le point d’être mécontente ».
Vous pouvez acheter une licence et ne pas être activé. Vous pouvez aussi être activé aujourd’hui et échouer demain si votre KMS disparaît et que la période de renouvellement expire.
Blague n°1 : L’activation, c’est comme un bip de 1998 — silencieuse quand ça marche, terriblement bruyante quand ça ne marche pas.
Comment l’activation fonctionne réellement (sans contes de fées)
Étape 1 : Windows détermine quel type de licence il pense avoir
Windows stocke des informations de licence localement (dans des zones protégées du système) et rapporte un « canal de licence »
comme Retail, OEM, Volume:KMSClient, Volume:MAK, etc. Ce n’est pas purement cosmétique. Cela détermine :
- Quels serveurs Windows contacte (Microsoft vs KMS)
- Si une clé produit est attendue comme étant unique (les clés client KMS ne le sont pas)
- Ce qui se passe après une image système
- Ce que « valide » signifie lors des audits
Étape 2 : Windows construit ou référence une identité matérielle
Pour l’activation hébergée par Microsoft (Retail/OEM), Windows dérive une empreinte matérielle (pas un seul numéro de série,
mais une identité pondérée). Changer un disque ? Généralement sans problème. Changer la carte mère ? Généralement problématique.
Les machines virtuelles compliquent ceci car leur « matériel » peut changer lorsque vous modifiez des périphériques virtuels ou clonez.
Une licence numérique existe à l’intersection de cette identité matérielle et de l’édition. Si vous réinstallez la même
édition sur un matériel « assez identique », elle se rétablit généralement d’elle‑même.
Étape 3 : Windows tente l’activation en utilisant la méthode courante
L’activation s’effectue soit :
- En ligne contre les services d’activation Microsoft (scénarios Retail/OEM/licence numérique)
- Contre votre serveur KMS d’entreprise (Volume:KMSClient)
- En utilisant une clé MAK (Volume:MAK), contactant Microsoft mais suivie par activation individuelle
Si cela fonctionne, Windows enregistre l’état d’activation localement. Si cela échoue, Windows conserve des journaux et un code d’erreur.
Votre travail est de lire le code et d’arrêter de deviner.
Étape 4 : Attentes de renouvellement (surtout KMS)
L’activation KMS n’est pas « une seule fois ». Les clients s’activent pour une période et doivent renouveler périodiquement. Si un portable
ne voit jamais le VPN, ou si l’enregistrement SRV KMS a été « optimisé » hors service, vous pouvez avoir une flotte entière progressivement hors conformité
pendant que tout le monde insiste sur « il l’a activé l’année dernière ».
Une citation opérationnelle utile pour rester lucide : L’espoir n’est pas une stratégie.
— Général Gordon R. Sullivan
Canaux de licence : Retail, OEM, Volume (KMS/MAK), Abonnement
Retail : flexible, à taille humaine, facilement mal utilisé
Les clés Retail sont destinées aux utilisateurs finaux et petites structures. Elles peuvent souvent être déplacées vers un autre appareil
(sous réserve des conditions Microsoft). Elles sont courantes dans :
- Ordinateurs portables achetés individuellement
- Systèmes de petites entreprises
- Solutions d’urgence « il me faut une licence aujourd’hui » (qui deviennent fréquemment permanentes)
En exploitation d’entreprise, les clés Retail sont radioactives à moins d’avoir un processus discipliné. Elles ne s’alignent pas proprement
avec les pipelines d’imagerie, et elles sont faciles à laisser fuiter dans des images de référence.
OEM : préinstallé, ancré dans le BIOS, pas votre compagnon de voyage
L’activation OEM est généralement liée à l’appareil avec lequel il a été expédié. Les systèmes modernes stockent souvent une clé OEM dans le firmware
(table ACPI MSDM). Windows peut la lire automatiquement pendant l’installation, ce qui est pratique jusqu’à ce que vous vouliez standardiser les éditions sur une flotte.
Les clés OEM sont excellentes quand vous conservez l’appareil tel quel. Elles sont pénibles quand vous changez la carte mère ou réaffectez du matériel.
Ce n’est pas une défaillance technique ; c’est le modèle.
Volume : activation client KMS (scalable, fragile quand le DNS est « nettoyé »)
KMS est conçu pour les organisations. Les clients utilisent une clé générique KMS client pour leur édition puis
s’activent contre un hôte KMS à l’intérieur de votre réseau. Points clés :
- KMS dépend du DNS (généralement un enregistrement SRV spécifique) ou d’une configuration explicite.
- Les clients doivent renouveler périodiquement.
- C’est résilient quand c’est bien construit, et silencieusement catastrophique quand c’est « astucieux ».
KMS ne concerne pas la confidentialité de la clé cliente. Il s’agit du contrôle de l’hôte et des comptes/seuils.
Volume : MAK (simple, mesurable, facile à brûler accidentellement)
Les clés MAK s’activent contre Microsoft mais sont comptées comme activations individuelles. Elles sont utilisées pour :
- Systèmes déconnectés/isolés (avec activation par téléphone ou connectivité limitée)
- Serveurs ou appliances qui ne voient pas de KMS de façon fiable
- Cas limites où le renouvellement KMS est irréaliste
MAK peut être opérationnellement propre si vous l’automatisez de façon responsable et suivez l’utilisation. Il est aussi facile de le ruiner si vous
intégrez la MAK dans une image de référence et la clonez 3 000 fois. Ce n’est pas « montée en charge », c’est « provoquer un incident de conformité à toute vitesse ».
Activation par abonnement (le cloud rencontre l’identité de l’appareil)
Dans les écosystèmes Microsoft modernes, la licence peut être liée à l’identité (Azure AD / Entra ID, abonnements).
L’activation par abonnement existe, mais ce n’est pas magique. Elle a toujours des dépendances :
- L’appareil doit être correctement joint/enregistré
- L’utilisateur doit avoir le droit approprié
- L’édition doit être éligible
- La connectivité et le rafraîchissement des jetons doivent fonctionner
Traitez-la comme tout autre système distribué : fournisseur d’identité, politique, réseau, synchronisation temporelle, télémétrie.
Faits intéressants et contexte historique (court et utile)
- Windows XP a rendu l’activation grand public. La Product Activation existait avant, mais XP est quand les consommateurs l’ont largement ressentie et que les entreprises ont commencé à formaliser des processus.
- Les clés OEM sont passées dans le firmware à l’ère Windows 8. De nombreux appareils sont livrés avec des clés dans la table ACPI MSDM, permettant des réinstallations « sans clé » — jusqu’à ce que vous vouliez une édition différente.
- KMS a été conçu pour l’échelle, pas la confidentialité. Les clés client KMS sont intentionnellement génériques ; la sécurité réside dans le contrôle de l’hôte KMS, pas dans la dissimulation d’une clé aux utilisateurs.
- La licence numérique est née de la vague de mise à niveau gratuite vers Windows 10. Microsoft avait besoin d’un moyen pour se souvenir « cet appareil a déjà obtenu Windows 10 », sans demander une nouvelle clé.
- Les incompatibilités d’édition sont un mode de défaillance majeur. Installer Pro alors que votre droit est Home (ou inversement) est l’un des moyens les plus rapides de générer un ticket « ça devrait marcher ».
- KMS repose par défaut sur des enregistrements DNS SRV. Si ces enregistrements manquent, les clients ne « découvrent » pas KMS à moins d’être configurés explicitement.
- L’activation dispose d’une période de grâce. Vous pouvez réinstaller et être « OK » pendant un certain temps, ce qui permet aux mauvais processus de survivre assez longtemps pour devenir des habitudes.
- La virtualisation change les règles d’identité. Cloner des VM ou modifier du matériel virtuel peut altérer l’identité suffisamment pour déclencher une réactivation, selon le canal.
- Certaines entreprises se tirent accidentellement une balle dans le pied. Imagerie + clés unattend + GPO + scripts MDM peuvent entrer en conflit, provoquant des basculements d’activation entre méthodes.
Feuille de route pour un diagnostic rapide
Quand l’activation casse, ne commencez pas par retaper des clés. C’est ainsi que vous brûlez des quotas MAK, verrouillez des comptes et
créez le chaos. Commencez par réunir des éléments de preuve.
Première étape : identifier le canal de licence et l’état courant
- Est‑ce Retail/OEM, ou Volume (KMS/MAK) ?
- Est‑ce activé, en période de grâce ou en notification ?
- L’édition est‑elle correcte ?
Deuxième étape : vérifier la découvrabilité et la joignabilité
- Si KMS : le client peut‑il résoudre l’enregistrement SRV KMS et joindre le port TCP 1688 ?
- Si activation Microsoft : a‑t‑il un accès Internet, l’heure correcte et aucune interception TLS qui casse la communication ?
Troisième étape : inspecter les changements récents et les déplacements d’identité
- Changement de carte mère/TPM ? Clonage de VM ? L’hyperviseur a‑t‑il modifié le modèle de la carte réseau virtuelle ?
- Un MDM ou une GPO a‑t‑il déployé une clé produit ou un script d’activation ?
- Des règles DNS ou de pare‑feu ont‑elles changé ?
Quatrième étape : remédier avec l’action la moins destructive
- Pour KMS : corriger l’enregistrement SRV DNS, ou définir l’hôte KMS explicitement, puis activer.
- Pour incompatibilité d’édition : changer l’édition via le mécanisme approprié ; ne persistez pas à marteler l’activation.
- Pour Retail/OEM lié au compte/appareil : utiliser l’outil de résolution d’activation ou relier à nouveau le compte, puis activer.
Tâches pratiques : commandes, sorties, décisions
Ce sont des tâches réelles et exécutables. Chacune inclut : une commande, ce que signifie la sortie, et quelle décision prendre.
Utilisez‑les comme liste de vérification pendant les incidents et lors de la validation des builds.
Tâche 1 : Vérifier le statut d’activation de base (lisible)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /xpr
The machine is permanently activated.
Signification : « Permanently activated » signifie typiquement activation Retail/OEM en ligne ou un état sans expiration.
Si elle affiche plutôt une date d’expiration, vous êtes probablement sur KMS.
Décision : Si ce n’est pas activé, ne devinez pas encore les clés. Continuez l’identification du canal.
Tâche 2 : Identifier le canal de licence, la clé partielle et les détails KMS
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /dlv
Software licensing service version: 10.0.19041.3636
Name: Windows(R), Professional edition
Description: Windows(R) Operating System, VOLUME_KMSCLIENT channel
Activation ID: 12345678-1234-1234-1234-1234567890ab
Application ID: 55c92734-d682-4d71-983e-d6ec3f16059f
Partial Product Key: 3V66T
License Status: Licensed
KMS machine name from DNS: kms01.corp.example
KMS port: 1688
Remaining Windows rearm count: 1000
Signification : La ligne « Description » est précieuse. Ici c’est VOLUME_KMSCLIENT. Cet appareil s’attend
à s’activer contre KMS, pas en tapant n’importe quelle clé retail trouvée dans un e‑mail.
Décision : Si client KMS : vérifier la découverte DNS et la connectivité vers l’hôte KMS. Si c’est Retail/OEM :
focalisez‑vous sur l’activation Microsoft et le lien compte/appareil.
Tâche 3 : Vérification rapide de l’édition
cr0x@server:~$ dism /online /Get-CurrentEdition
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Current Edition : Professional
Signification : L’édition doit correspondre à votre droit/clé. Les incompatibilités Pro vs Enterprise vs Home provoquent
des boucles d’activation.
Décision : Si l’édition est incorrecte, arrêtez les tentatives d’activation et corrigez d’abord le chemin d’édition.
Tâche 4 : Lister les éditions cibles possibles (pour changements contrôlés d’édition)
cr0x@server:~$ dism /online /Get-TargetEditions
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Target Edition : Professional
Target Edition : Enterprise
Signification : Montre quelles mises à niveau d’édition sont possibles depuis l’installation actuelle.
Décision : Si vous avez besoin d’Enterprise mais ne voyez que Pro/Enterprise en cibles, c’est probablement bon.
Si l’édition souhaitée n’apparaît pas, vos médias ou l’installation de base peuvent être incorrects.
Tâche 5 : Vérifier si une clé OEM existe dans le firmware (important pour le comportement après réinstallation)
cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance -ClassName SoftwareLicensingService).OA3xOriginalProductKey"
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Signification : Si ceci renvoie une clé, l’appareil a probablement été livré avec une licence OEM intégrée au firmware.
Si c’est vide, il se peut qu’il n’y ait pas de clé intégrée (ou que l’accès soit restreint).
Décision : Si vous standardisez sur Enterprise via du licensing en volume, assurez‑vous que votre processus d’imagerie n’installe
pas accidentellement Home/Pro à cause de la clé firmware.
Tâche 6 : Vérifier la découverte de l’enregistrement SRV KMS via DNS
cr0x@server:~$ nslookup -type=srv _vlmcs._tcp.corp.example
Server: dns01.corp.example
Address: 10.0.0.53
_vlmcs._tcp.corp.example SRV service location:
priority = 0
weight = 0
port = 1688
svr hostname = kms01.corp.example
Signification : La découverte KMS fonctionne. Si cela échoue, les clients peuvent ne pas trouver KMS du tout.
Décision : Si manquant : restaurez l’enregistrement SRV DNS ou définissez explicitement l’hôte KMS sur les clients.
Tâche 7 : Tester la connectivité TCP vers l’hôte KMS
cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection kms01.corp.example -Port 1688"
ComputerName : kms01.corp.example
RemoteAddress : 10.0.10.21
RemotePort : 1688
InterfaceAlias : Ethernet0
SourceAddress : 10.0.20.44
TcpTestSucceeded : True
Signification : Le port est joignable. Si TcpTestSucceeded est false, vous avez des problèmes de pare‑feu/routage/VPN.
Décision : Corrigez le chemin réseau avant de faire autre chose. L’activation ne réussira pas sans joignabilité.
Tâche 8 : Forcer une tentative d’activation KMS et lire le résultat
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /ato
Activating Windows(R), Professional edition...
Product activated successfully.
Signification : Le succès est ennuyeux, comme il se doit. Si cela échoue, vous obtiendrez un code d’erreur.
Décision : Si l’erreur mentionne le DNS, l’hôte KMS ou serveur injoignable, revenez aux Tâches 6–7.
Si l’erreur suggère clé invalide ou incompatibilité d’édition, allez aux Tâches 3–4 et aux vérifications de clé/canal.
Tâche 9 : Définir l’hôte KMS explicitement (quand la découverte DNS est cassée ou segmentée)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /skms kms01.corp.example:1688
Key Management Service machine name set to kms01.corp.example:1688 successfully.
Signification : Le client utilisera désormais l’hôte KMS spécifié au lieu de dépendre de la découverte SRV DNS.
Décision : Utilisez ceci comme correction tactique, pas comme béquille permanente, sauf si votre conception réseau l’exige vraiment.
Tâche 10 : Effacer un hôte KMS défini explicitement (retour à la découverte DNS)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /ckms
Key Management Service machine name cleared successfully.
Signification : Supprime l’hôte KMS codé en dur. Le client utilisera à nouveau la découverte SRV DNS.
Décision : Si votre environnement supporte la découverte SRV DNS fiable, préférez‑la. La dérive de configuration est un tueur silencieux.
Tâche 11 : Installer une clé produit (prudemment, intentionnellement)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Installed product key XXXXX-XXXXX-XXXXX-XXXXX-XXXXX successfully.
Signification : Cela change la clé sur la machine. Cela peut aussi modifier le canal d’activation attendu.
Décision : Ne le faites que lorsque vous savez quel canal vous voulez. Si vous êtes une entreprise utilisant KMS,
installer une clé Retail comme « correctif rapide » est la façon de s’offrir le pire weekend de votre futur vous.
Tâche 12 : Supprimer une clé produit de la machine (réduire le risque de fuite)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /upk
Uninstalled product key successfully.
Signification : Supprime la clé produit actuelle de l’installation (cela n’efface pas une licence numérique).
Décision : Utilisez‑le sur les modèles et images de référence pour éviter de distribuer accidentellement une clé MAK/Retail.
Tâche 13 : Effacer la clé produit du registre (hygiène des templates)
cr0x@server:~$ cscript //nologo C:\Windows\System32\slmgr.vbs /cpky
Product key from registry cleared successfully.
Signification : Aide à empêcher la récupération de la clé depuis le registre par des outils locaux. Ce n’est pas une sécurité parfaite, mais une bonne hygiène.
Décision : Standardisez ceci dans vos étapes de finalisation d’image si vous injectez des clés pendant la construction.
Tâche 14 : Vérifier le service Software Protection (la plomberie d’activation)
cr0x@server:~$ sc query sppsvc
SERVICE_NAME: sppsvc
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
Signification : Si sppsvc ne tourne pas, les opérations d’activation et de licences peuvent échouer de façon étrange.
Décision : Démarrez/réparez le service avant de perdre du temps avec des clés et des serveurs.
Tâche 15 : Vérifier la synchronisation temporelle (parce que la licence déteste le voyage temporel)
cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 8:41:20 AM
Source: time01.corp.example
Poll Interval: 10 (1024s)
Signification : Si l’heure est fortement décalée, TLS et l’activation peuvent échouer, et les journaux deviennent mensongers.
Décision : Corrigez d’abord la synchronisation temporelle, puis réessayez l’activation. Si votre réponse aux incidents n’inclut pas le temps, ce n’est pas une vraie réponse aux incidents.
Tâche 16 : Inspecter les journaux d’événements liés aux licences pour des codes d’erreur
cr0x@server:~$ wevtutil qe Microsoft-Windows-Security-SPP/SoftwareProtectionPlatform /c:5 /rd:true /f:text
Event[0]:
Log Name: Microsoft-Windows-Security-SPP/SoftwareProtectionPlatform
Source: Microsoft-Windows-Security-SPP
Event ID: 8198
Level: Error
Description:
License Activation (slui.exe) failed with the following error code:
0xC004F074
Signification : Les codes d’erreur sont exploitables. L’exemple 0xC004F074 est couramment vu lorsque KMS est injoignable.
Décision : Mappez le code à la branche correcte de votre playbook : joignabilité KMS, SRV DNS, incompatibilité clé/canal, ou problèmes de politique.
Blague n°2 : Si votre plan d’activation est « essayer une clé différente jusqu’à ce que ça marche », félicitations — vous avez inventé la force brute de la conformité.
Trois mini-récits d’entreprise issus du terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne avait une flotte Windows 10/11 stable et une routine : réimager les portables, les expédier, les laisser s’activer.
Leur croyance était simple : « L’activation est liée au compte Microsoft de l’utilisateur, donc ça se réglera tout seul. »
Cette croyance était erronée à deux égards.
Premièrement, la plupart des appareils devaient être en Volume KMS, pas en licences numériques grand public. Deuxièmement,
la moitié de la force terrain se connectait rarement au VPN suffisamment longtemps pour atteindre les services internes. Ils pouvaient s’authentifier sur
des applications cloud, oui. Ils ne pouvaient pas atteindre KMS, non.
Le mode de défaillance avait un délai. Les nouveaux portables étaient expédiés correctement, semblaient corrects et fonctionnaient pendant des semaines.
Puis la fenêtre de renouvellement d’activation a commencé à expirer sur des appareils qui n’ont jamais atteint KMS. Les utilisateurs voyaient « Windows n’est pas activé »
aux pires moments : en déplacement, chez des clients et en clôture de trimestre.
La solution n’était pas « acheter plus de clés ». La solution a été de cesser de supposer un comportement d’activation consommateur et de traiter cela comme
une dépendance de service distribué. Ils ont fait trois choses : publier les enregistrements SRV KMS corrects dans la vue DNS du VPN, s’assurer que le client VPN
se connecte tôt, et valider l’état d’activation pendant le provisioning et après le premier démarrage.
La leçon : l’activation est un système avec des dépendances. Si vous ne concevez pas pour ces dépendances, le système vous le rappellera plus tard, bruyamment.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une autre organisation voulait un « DNS propre ». Quelqu’un a repéré un enregistrement SRV mystérieux : _vlmcs._tcp. Il ne semblait pas
critique pour l’activité. Il n’avait pas de ticket. Il avait une aura de « legacy ».
Ils l’ont supprimé lors d’un projet d’hygiène DNS, avec quelques anciens enregistrements d’hôtes. Rien n’a explosé immédiatement.
C’est le danger : les clients KMS peuvent rester activés pendant un certain temps. La modification est donc passée, célébrée comme une victoire,
puis oubliée.
Des semaines plus tard, des échecs d’activation sporadiques ont commencé à apparaître sur des machines nouvellement imagées. Le support a répondu comme le support le fait sous pression :
ils ont essayé des clés au hasard, réimagé des machines et escaladé vers l’ingénierie poste de travail. Pendant ce temps, les machines déjà sur le terrain ont commencé
à perdre leur activation au fur et à mesure que les renouvellements échouaient.
La cause racine a été découverte non par intuition mais en lisant les preuves : slmgr /dlv affichait VOLUME_KMSCLIENT et « KMS machine name from DNS: not available ».
Le nettoyage DNS avait supprimé l’enregistrement de découverte de service.
La correction a été de restaurer l’enregistrement SRV et d’ajouter une vérification dans le contrôle des changements : « Y a‑t‑il des enregistrements SRV soutenant la licence,
l’identité, l’enrôlement des appareils, ou la synchronisation temporelle ? » Vous n’optimisez pas le plan de contrôle sans plan de retour arrière.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une entreprise régulée avait une habitude douloureusement lente : chaque build d’image mensuel incluait une étape automatisée de validation d’activation, exécutée
sur plusieurs modèles matériels et dans une VM. Ils ne faisaient pas confiance au « ça devrait s’activer ».
Ils exigeaient « ça s’est activé, et voici la preuve ».
Leur pipeline produisait des artefacts : sortie slmgr /dlv, vérification d’édition via DISM,
contrôles de découverte KMS, et instantanés des journaux d’événements. Tout était stocké avec les métadonnées du build. Personne n’aimait ça.
Ce n’était pas glamour. Ça n’a remporté aucun hackathon.
Puis un mois, un changement apparemment inoffensif est arrivé : une mise à jour de gestion de configuration qui définissait un hôte KMS explicitement
sur certains appareils (vers un nom d’hôte qui ne résolvait que dans un segment réseau). Dans un autre segment, il ne résolvait plus. Les appareils terrain
ont commencé à échouer à l’activation.
Parce que l’organisation avait une validation au moment de la construction, ils ont détecté le problème pendant la canary. Ils ont comparé l’artefact de licence du mois précédent
avec le nouveau et ont vu la ligne d’hôte KMS changer immédiatement. Ils ont reverté la configuration avant un déploiement large. Le support n’a jamais vu l’incident.
La conformité n’a jamais appelé. Tout le monde a pu garder son weekend.
La leçon : les contrôles ennuyeux battent les sauvetages héroïques. Les artefacts de construction sont la vérité opérationnelle.
Erreurs courantes : symptôme → cause → réparation
1) Symptom : « Windows ne peut pas s’activer pour l’instant » après réinstallation
Cause racine : Joignabilité réseau, résolution DNS, ou problèmes de proxy/interception TLS ; parfois une dérive temporelle.
Réparation : Validez l’heure (w32tm), la connectivité et les journaux. Pour KMS, confirmez le SRV et le port 1688. Pour Microsoft,
vérifiez la sortie TLS et l’horloge système correcte. Ensuite réessayez l’activation.
2) Symptom : Activé hier, pas activé aujourd’hui (surtout les portables)
Cause racine : Échec de renouvellement KMS parce que le client ne peut pas atteindre KMS pendant de longues périodes (pas de VPN, DNS divisé mal configuré).
Réparation : Assurez‑vous que les appareils peuvent résoudre et atteindre KMS depuis leurs lieux d’utilisation (VPN avec DNS d’entreprise),
ou basculez cette population vers un modèle de licence plus approprié (MAK/abonnement) avec gouvernance.
3) Symptom : « La clé produit que vous avez saisie n’a pas fonctionné » alors que la clé est « connue bonne »
Cause racine : Incompatibilité d’édition (par ex. installer Pro alors que l’entitlement est Enterprise), ou utilisation d’une clé d’un autre canal.
Réparation : Vérifiez l’édition via DISM ; vérifiez le canal via slmgr /dlv. Corrigez d’abord l’édition. Ensuite appliquez la bonne clé/méthode.
4) Symptom : « Non authentique » / mode notification après changement matériel
Cause racine : La licence numérique Retail/OEM ne correspond plus à l’identité matérielle (les changements de carte mère/TPM sont des déclencheurs courants).
Réparation : Utilisez l’outil de résolution d’activation et le rattachement de compte si applicable. Si OEM, considérez‑la comme une licence liée à l’appareil et remplacez adéquatement.
5) Symptom : L’imagerie crée des appareils qui s’activent en Home alors que vous avez besoin de Pro/Enterprise
Cause racine : La clé OEM firmware dirige la sélection d’édition lors de l’installation.
Réparation : Contrôlez la sélection d’édition dans votre processus de déploiement. Détectez la présence d’une clé OEM et assurez-vous que votre séquence de tâches ou unattend impose l’édition désirée.
6) Symptom : Les clients KMS affichent « KMS machine name: not available »
Cause racine : Enregistrement SRV DNS manquant/cassé, liste de suffixes de recherche DNS erronée, ou clients utilisant un DNS non‑corporate.
Réparation : Restaurez l’enregistrement SRV et validez le suffixe/search DNS. Si des réseaux segmentés existent, configurez l’hôte KMS explicitement seulement là où c’est nécessaire.
7) Symptom : Activations MAK épuisées de façon inattendue
Cause racine : Clé MAK intégrée dans une image/template ; chaque clone consomme une activation. Ou l’automatisation réessaye l’activation en boucle lors d’un échec.
Réparation : Retirez les clés des templates (/upk, /cpky). Contrôlez les tentatives d’activation et journalisez les échecs plutôt que de réessayer aveuglément.
8) Symptom : L’activation bascule entre états après le démarrage
Cause racine : Outils concurrents (GPO vs MDM vs scripts) définissant des clés/hôtes KMS différents.
Réparation : Établissez une responsabilité unique pour la configuration d’activation. Auditez les politiques et scripts. Supprimez les doublons d’application.
Listes de contrôle / plan étape par étape
Checklist A : Pour une machine unique qui ne veut pas s’activer
-
Confirmer l’état courant : exécutez
slmgr /xpretslmgr /dlv.
Décidez si vous êtes en Retail/OEM vs KMS/MAK. -
Confirmer l’édition : exécutez
dism /online /Get-CurrentEdition.
Si elle est incorrecte, arrêtez et corrigez l’édition d’abord. -
Vérifier l’heure : exécutez
w32tm /query /status.
Si l’heure est décalée, corrigez la synchronisation temporelle avant de retenter l’activation. -
Si client KMS : confirmez l’enregistrement SRV DNS et la connectivité TCP 1688 ; définissez l’hôte KMS explicitement si nécessaire ; exécutez
slmgr /ato. - Si Retail/OEM : assurez‑vous de la connectivité sortante et qu’aucun proxy TLS ne casse la communication ; puis utilisez l’interface d’activation/outil de résolution si nécessaire.
-
Lire les journaux d’événements : utilisez
wevtutilpour trouver les codes d’erreur et suivez le chemin de correction correspondant.
Checklist B : Pour un problème d’ampleur (pics d’échecs d’activation)
- Échantillonnez intelligemment : sélectionnez des appareils répartis par sites, états VPN et modèles matériels. Ne déboguez pas seulement les postes du siège.
-
Déterminez le canal dominant : collectez les sorties
slmgr /dlvdes échantillons.
Si vous voyez des canaux mixtes, vous avez un problème de processus. - Validez les dépendances : présence des enregistrements SRV DNS dans toutes les vues DNS, règles de pare‑feu vers KMS, comportement DNS du VPN, et synchronisation temporelle.
-
Vérifiez les poussées de configuration récentes : GPO/MDM/scripts qui définissent
/skmsou/ipk.
Restaurez d’abord les politiques conflictuelles. - Remédiation canari : appliquez les correctifs à un petit groupe, vérifiez le succès et la persistance de l’activation, puis étendez.
Checklist C : Hygiène des images/templates (prévenir le problème)
-
Ne jamais intégrer de clés MAK/Retail dans les images. Après toute activation temporaire, exécutez
slmgr /upketslmgr /cpky. -
Enregistrer les artefacts de licence au moment de la construction. Stockez la sortie
slmgr /dlvet les informations d’édition avec les métadonnées du build. - Validez la découverte KMS dans chaque segment réseau pertinent. Surtout VPN et VLAN isolés.
- Rendre la sélection d’édition explicite. Ne laissez pas les clés firmware surprendre votre cible de déploiement.
- Définir la responsabilité. Une seule équipe/outil définit la configuration d’activation ; tout le reste observe.
FAQ
1) Si j’ai une clé produit, suis‑je activé ?
Non. Une clé produit est une entrée. L’activation est le résultat. Les clés peuvent être valides mais l’activation peut échouer pour cause d’incompatibilité d’édition,
problèmes réseau, injoignabilité KMS, ou clés épuisées/bloquées.
2) Quelle est la différence pratique entre une licence numérique et une clé produit ?
Une clé produit est quelque chose que vous tapez (ou déployez). Une licence numérique est le droit enregistré par Microsoft lié à l’identité de l’appareil (et parfois au compte).
Les licences numériques permettent souvent la réinstallation sans ressaisir une clé, tant que l’édition et l’identité matérielle correspondent aux attentes.
3) Pourquoi l’activation a‑t‑elle cassé après le remplacement d’une carte mère ?
Parce que la carte mère influence fortement l’identité matérielle. Pour les licences numériques Retail/OEM, ce changement d’identité peut ressembler à un nouvel appareil.
Pour OEM, la licence est typiquement liée à l’appareil. La réparation consiste soit en dépannage d’activation avec rattachement de compte (Retail) soit en relicensing approprié (OEM).
4) Comment savoir si une machine est KMS, MAK ou Retail ?
Exécutez cscript //nologo C:\Windows\System32\slmgr.vbs /dlv et regardez la ligne « Description » :
VOLUME_KMSCLIENT, VOLUME_MAK, RETAIL, ou des indicateurs liés à OEM.
5) Puis‑je convertir un client KMS en activation Retail en saisissant une clé retail ?
Techniquement, installer une autre clé peut changer le comportement. Opérationnellement, ne faites pas cela à la légère.
Vous créerez des flottes à canaux mixtes difficiles à auditer et encore plus difficiles à dépanner. Si vous devez le faire, documentez‑le,
retirez‑le des images et assurez‑vous du respect des termes de licence.
6) Pourquoi certaines machines activées par KMS affichent une date d’expiration ?
Parce que l’activation KMS est limitée dans le temps et requiert un renouvellement. La machine reste licenciée tant qu’elle contacte périodiquement un hôte KMS.
Si elle arrête, elle finit par perdre son activation.
7) Pourquoi la réinstallation de Windows s’active parfois automatiquement sans saisir de clé ?
Soit l’appareil possède une clé OEM dans le firmware que l’installation lit automatiquement, soit Microsoft reconnaît la licence numérique de l’appareil
en fonction de l’identité matérielle et de l’édition. C’est normal — quand la sélection d’édition correspond.
8) Que dois‑je faire avant d’ouvrir un ticket auprès de mon équipe licensing ou du support Microsoft ?
Rassemblez : slmgr /xpr, slmgr /dlv, dism /Get-CurrentEdition, le code d’erreur pertinent du journal d’événements,
et (pour KMS) la recherche SRV DNS et les résultats de connectivité TCP. Sans cela, vous soumettez essentiellement des impressions.
9) Effacer une clé produit est‑ce la même chose que supprimer une licence numérique ?
Non. slmgr /upk supprime la clé installée de l’instance OS. Une licence numérique (si elle existe) est un droit enregistré à l’extérieur
et peut toujours réactiver l’appareil ultérieurement. Effacer les clés relève de l’hygiène des templates et réduit les fuites accidentelles.
10) Pourquoi l’activation se comporte différemment dans les VM ?
Le « matériel » d’une VM peut changer quand vous clonez, modifiez des périphériques virtuels ou migrez entre plateformes. Cela peut déclencher une réactivation.
De plus, certaines licences en volume sont conçues pour la virtualisation ; utilisez le modèle adapté à votre environnement plutôt que d’improviser.
Conclusion : prochaines étapes qui réduisent vraiment la douleur
Cessez de traiter l’activation comme une propriété mystique de Windows. Traitez‑la comme une dépendance opérationnelle avec un état connu,
un canal connu et des modes de défaillance connus. Les clés produit sont des identifiants, les licences numériques sont des droits, et l’activation est un verdict.
Si vous confondez ces lignes, vous « réparez » aujourd’hui en cassant le trimestre suivant.
Prochaines étapes pratiques :
- Standardisez le modèle mental dans votre équipe : canal d’abord, édition ensuite, connectivité en troisième.
- Ajoutez une validation au moment du build : capturez
slmgr /dlv, l’édition et la preuve de découverte KMS pour chaque image. - Protégez vos templates : retirez les clés installées (
/upk) et effacez les traces du registre (/cpky). - Renforcez les dépendances KMS : enregistrements SRV DNS, joignabilité des ports et comportement VPN/DNS séparé.
- Documentez la responsabilité : une chaîne d’outils unique définit les paramètres d’activation ; tous les autres observent et alertent.
Faites cela, et l’activation redeviendra ce qu’elle doit être : ennuyeuse. L’ennui est le plus grand compliment que vous puissiez faire à un système de licences.