Windows Volume Activation : migrer de KMS vers ADBA sans rupture (DNS _vlmcs._tcp, GVLK, MAK, 180 jours)

Vous préparez la fin de vie d’un ancien KMS et la bascule vers ADBA (ou un nouveau KMS) ? Cet article explique pourquoi vos machines restent “Licensed” même sans hôte KMS valide, quels risques réels vous courez, et comment migrer proprement (DNS, GVLK, MAK, scripts, contrôles).

Sommaire

Pourquoi les machines ne réclament‑elles pas l’activation alors que le KMS n’existe plus ?

Contexte et symptômes

Vous constatez sur des postes/serveurs que slmgr /dlv affiche un canal VOLUME_KMS (ex. WS16), alors que l’enregistrement DNS _vlmcs._tcp ne pointe plus vers un hôte KMS valide. Pourtant, aucun watermark “Activer Windows” ni bannière de notification n’apparaît. C’est logique : l’activation par KMS/ADBA est valable 180 jours et se renouvelle périodiquement. Tant que la validité n’est pas échue, le système reste en état Licensed.

Explications détaillées

Activation KMS encore valable (180 jours) : une machine qui a réussi à se faire activer conserve son état “Licensed” jusqu’à l’expiration du bail. Elle tentera un renouvellement environ toutes les 7 jours (et plus fréquemment en cas d’échec). Sans KMS répondant, elle reste silencieuse jusqu’à l’échéance.
Activation en MAK déjà acquise : même si le canal affiché par un composant ou un produit tiers prête à confusion, une activation Multiple Activation Key est définitive (sauf réinstallation/édition). Elle n’a pas besoin de KMS/ADBA.
Poste joint au domaine avec ADBA disponible : si votre forêt AD publie l’Activation Object, une machine domain-joined et munie d’une clé GVLK peut s’activer au contact des contrôleurs de domaine, sans passer par KMS ni par le SRV _vlmcs._tcp.

Le rôle réel de `BackupProductKeyDefault`

Le Registre (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform) contient la valeur BackupProductKeyDefault. Elle n’active rien. C’est une clé de sauvegarde (souvent OEM/édition) que Windows stocke pour information et restauration. Ne la confondez ni avec une GVLK, ni avec votre clé MAK, ni avec l’état d’activation courant. Sa présence n’explique pas l’absence de messages d’alerte.

Quel risque lors du passage à un nouveau KMS/ADBA ?

Pratiquement aucun à court terme : déployer un nouveau service d’activation ne “casse” pas les machines déjà activées. Elles restent Licensed jusqu’à leur prochaine échéance. Le seul risque est qu’elles n’arrivent pas à se réactiver à 180 jours si aucune cible valide n’est joignable (KMS/ADBA). D’où l’intérêt d’un plan de migration propre (publication DNS/AD, nettoyage des paramètres forcés côté client).

Vérifier l’état réel (à faire tout de suite)

slmgr /xpr    <-- expiration effective
slmgr /dlv    <-- canal, hôte KMS mémorisé, délai de grâce, etc.

Matrice de décision rapide

Contexte	Modèle recommandé	Pourquoi
PC/serveurs jointes au domaine	ADBA	Pas de dépendance au SRV, activation au contact des DC, gestion simple.
Hors domaine / DMZ / lab isolé	KMS (ou MAK)	KMS si accès périodique au port 1688, sinon MAK pour l’isolement total.
Portables rarement connectés (>180 j)	MAK	Évite le passage en “notification” en cas d’absence prolongée.

Faut‑il nettoyer l’enregistrement DNS `_vlmcs._tcp` obsolète ?

Réponse courte

Oui. Si plus aucun hôte KMS ne doit répondre (ou si vous basculez vers ADBA seul), supprimez l’enregistrement SRV _vlmcs._tcp pour éviter des découvertes hasardeuses, des délais d’activation et des logs d’erreur inutiles.

Méthodes de nettoyage/publication

Console DNS : Zone → _tcp → _vlmcs → supprimer l’enregistrement SRV obsolète. Recréez‑le si vous conservez KMS en pointant vers le nouveau FQDN/port.
PowerShell (serveur DNS) : Get-DnsServerResourceRecord -ZoneName "votre-domaine.local" -RRType SRV -Name "_vlmcs._tcp" | Remove-DnsServerResourceRecord -ZoneName "votre-domaine.local" -Force
Vérification : nslookup -type=srv _vlmcs._tcp.votre-domaine.local Test-NetConnection -ComputerName kms.nouveau.fqdn -Port 1688

Clients avec un KMS forcé (mémorisé)

Certains clients peuvent avoir un hôte KMS “codé en dur” (paramétré via /skms). Nettoyez et réactivez :

slmgr /ckms   <-- efface l’hôte KMS mémorisé
slmgr /ato    <-- relance une activation (ADBA si dispo, sinon découverte)

Quel sera l’impact d’un nouveau KMS/ADBA sur les postes MAK ?

Comportement par défaut

Un poste activé en MAK reste en MAK. Aucun basculement automatique vers KMS/ADBA, même si un KMS ou un objet ADBA apparaît.
La présence d’un SRV _vlmcs._tcp ou d’un objet ADBA n’a aucun effet tant que la clé installée n’est pas une GVLK (clé client KMS).

Migrer MAK → KMS/ADBA

Installer la GVLK correspondant à l’édition (Pro/Enterprise/Server). slmgr /ipk <GVLK_de_votre_édition>
Activer (ADBA si joint au domaine et objet présent, sinon KMS par SRV/paramètre). slmgr /ato
Automatiser (GPO, Intune, outil d’inventaire, script de démarrage). REM Exemple GPO (Script de démarrage) slmgr /ckms slmgr /ipk <GVLK> slmgr /ato

Identifier à grande échelle le canal et le statut

# PowerShell (local ou via remoting)
Get-CimInstance -ClassName SoftwareLicensingProduct |
  Where-Object { $_.PartialProductKey -and $_.Name -like "*Windows*" } |
  Select-Object Name, Description, LicenseStatus, PartialProductKey

Interprétez LicenseStatus avec la table ci‑dessous.

LicenseStatus	Signification
0	Unlicensed
1	Licensed
2	OOBGrace (grâce initiale)
3	OOTGrace (out-of-tolerance)
4	NonGenuineGrace
5	Notification (watermark, personnalisation limitée)
6	ExtendedGrace

Postes ADBA qui ne voient pas l’AD pendant > 180 jours

Ce qui se passe en pratique

La validité d’une activation KMS/ADBA est de 180 jours.
Le client tente un renouvellement environ tous les 7 jours (et retente plus souvent en cas d’échec).
Au‑delà de 180 jours sans succès, le poste passe en mode notification : watermark “Activer Windows” et limitations mineures de personnalisation. À la prochaine connexion réseau valide, il se réactivera automatiquement (ou via slmgr /ato).

Stratégies pour terminaux nomades

MAK pour les appareils rarement connectés/isolés.
Accès périodique via VPN/split‑tunnel vers les DC ou le KMS (port 1688 TCP) pour conserver KMS/ADBA.
Surveillance des baux à l’approche des 180 jours (inventaire WMI, requêtes CIM, slmgr /xpr).

Chemin de migration recommandé (KMS → ADBA/KMS)

Étape 1 : choisir le modèle cible

ADBA pour la majorité des machines jointes au domaine (Windows 8/Server 2012 et +).
KMS en parallèle pour les hôtes hors domaine/DMZ/lab, ou MAK si aucun accès périodique n’est garanti.
Si vous conservez KMS, vérifiez le seuil d’activation : ≈25 clients Windows, ≈5 serveurs Windows (CMID uniques).

Étape 2 : déployer ADBA

Installer le rôle Volume Activation Services sur un membre du domaine (ou DC si politique interne).
Installer la clé hôte CSVLK dans l’AD (création de l’Activation Object).
Contrôler les journaux :
- Clients : Applications and Services Logs → Microsoft → Windows → Security‑SPP → Operational.
- Hôte KMS (si utilisé) : Applications and Services Logs → Microsoft → Windows → Key Management Service.

Étape 3 : nettoyer/publier DNS

Si vous abandonnez KMS : supprimez les SRV _vlmcs._tcp orphelins.
Si vous conservez KMS : publiez un SRV propre vers le nouvel hôte (FQDN/port 1688), et filtrez l’accès par firewall.

Étape 4 : basculer les clients

slmgr /ckms                     <-- efface tout KMS codé en dur
slmgr /ipk <GVLK_de_l’édition>  <-- installe la clé client KMS
slmgr /ato                      <-- force l’activation

Automatisation via GPO/Intune/outil d’inventaire. Pensez à séquencer (publier ADBA/KMS avant d’envoyer les GVLK).

Étape 5 : contrôler et industrialiser

Spot‑checks sur des échantillons : slmgr /xpr, slmgr /dlv.
Inventaire (CIM/WMI) : extraire canal, statut, date d’expiration.
Alerting à J‑30 de l’expiration pour éviter les watermarks.

Mémo de commandes utiles

:: État & expiration
slmgr /dlv
slmgr /xpr

\:: Basculer vers KMS/ADBA (installer GVLK) puis activer
slmgr /ipk \
slmgr /ato

\:: Effacer un KMS codé en dur (retour à la découverte AD/DNS)
slmgr /ckms

\:: Spécifier un KMS (si vous conservez KMS)
slmgr /skms kms.nouveau.fqdn:1688

\:: Vérifier le SRV et le port
nslookup -type=srv \_vlmcs.\_tcp.votre-domaine.local
Test-NetConnection -ComputerName kms.nouveau.fqdn -Port 1688

Réponses directes aux points soulevés

La mise en place d’un nouveau KMS/ADBA va‑t‑elle casser la licence ? Non. Les activations existantes restent valides jusqu’à leur échéance. Migrez ensuite les clients selon le modèle cible.
Faut‑il nettoyer _vlmcs._tcp ? Oui, s’il est orphelin. Sinon, publiez le SRV du nouveau KMS.
Les machines MAK basculent‑elles automatiquement vers KMS/ADBA ? Non. Elles restent en MAK tant que vous n’installez pas une GVLK.
Que se passe‑t‑il au‑delà de 180 jours sans contact AD/KMS ? Passage en mode notification (watermark, personnalisation limitée), puis réactivation automatique au prochain contact réseau valide.
BackupProductKeyDefault joue‑t‑il un rôle d’activation ? Non. C’est uniquement une sauvegarde d’identifiant de clé (souvent OEM/édition).

Comparatif KMS / ADBA / MAK (repères opérationnels)

Modèle	Prérequis	Découverte	Renouvellement	Scénarios idéaux	Points d’attention
KMS	Hôte KMS (CSVLK), port 1688	SRV `_vlmcs._tcp` ou `/skms`	Tous les ~7 jours (bail 180 j)	Parc mixte, DMZ si routage possible	Seuils : ~25 clients / ~5 serveurs. Gérer le DNS et le firewall.
ADBA	Objet d’activation dans AD, GVLK, poste joint au domaine	Contact DC (pas de SRV KMS requis)	Tous les ~7 jours (bail 180 j)	Entreprises orientées AD, gestion simple	Nécessite contact régulier avec l’AD (VPN pour nomades).
MAK	Clé MAK, activation unique	Aucune découverte (one‑shot)	Pas de renouvellement	Isolés, déconnectés, longue durée sans réseau	Gestion du stock de clés, suivi des activations

Bonnes pratiques pour une migration sans rupture

Publiez d’abord (ADBA/KMS), puis déployez les GVLK/paramètres côté clients.
Nettoyez le SRV orphelin _vlmcs._tcp pour éviter les mauvaises cibles.
Sécurisez le port 1688 (KMS) : ACL internes, pas d’exposition Internet.
Standardisez le script de bascule (/ckms, /ipk, /ato) et logguez la sortie.
Contrôlez via WMI/CIM et journaux SPP/KMS pour détecter tôt les échecs.
Anticipez les besoins d’activation d’autres produits (ex. Office en volume) : ADBA ou KMS distinct, selon votre stratégie.

Dépannage rapide (checklist)

Canal & expiration : slmgr /dlv, slmgr /xpr.
DNS : nslookup -type=srv _vlmcs._tcp, vérifiez TTL/cibles.
Résidus de configuration : slmgr /ckms, puis slmgr /ato.
Réseau : port 1688 ouvert du client vers l’hôte KMS.
Journaux : SPP (clients) et KMS (serveur). Recherchez des codes 0xC004F…
CMID dupliqués (images non sysprepées) : régénérez l’ID machine (image correcte, ou sysprep avant capture) pour respecter les seuils KMS.

Exemples de scripts orientés production

PowerShell : inventaire succinct de l’activation

$computers = Get-Content .\liste_machines.txt
$results = foreach ($c in $computers) {
  try {
    $p = Invoke-Command -ComputerName $c -ScriptBlock {
      Get-CimInstance -ClassName SoftwareLicensingProduct |
        Where-Object { $_.PartialProductKey -and $_.Name -like "*Windows*" } |
        Select-Object Name, Description, LicenseStatus, GracePeriodRemaining, PartialProductKey
    } -ErrorAction Stop
    [PSCustomObject]@{ Computer=$c; Data=$p }
  } catch {
    [PSCustomObject]@{ Computer=$c; Data=$null }
  }
}
$results | Format-List

PowerShell : bascule MAK → ADBA/KMS

# À exécuter via GPO/Intune avec élévation
slmgr /ckms
slmgr /ipk <GVLK_correspondante>
slmgr /ato
# Option : journaliser l’issue
powershell -Command "Get-Date | Out-File C:\Windows\Temp\activation.log -Append"

FAQ ciblée

Dois‑je conserver un KMS si je passe à ADBA ?

Conservez‑le seulement si vous avez des hôtes hors domaine ou des segments isolés qui ne peuvent pas joindre l’AD. Sinon, ADBA suffit pour les machines jointes au domaine. Un poste en KMS peut‑il s’activer via ADBA sans changer de clé ?

Oui si la clé installée est une GVLK et que le poste est joint au domaine : il utilisera ADBA au contact des DC. Dans le doute, remettez la GVLK de l’édition et forcez slmgr /ato. Dois‑je mettre à jour l’hôte KMS pour les versions Windows récentes ?

Oui : assurez‑vous que votre hôte KMS est supporté pour activer les éditions/versions de votre parc. Intégrez cette vérification au runbook de migration. Que faire des clones/VMs déployées d’une image ancienne ?

Veillez à générer un CMID unique (sysprep correct). Des CMID en double faussent le décompte et peuvent empêcher d’atteindre les seuils d’activation KMS.

Résumé actionnable

Pourquoi pas d’alerte : activation KMS/ADBA encore valide (180 j) ou poste en MAK. BackupProductKeyDefault n’y change rien.
Risque : uniquement à l’échéance si aucun service d’activation n’est joignable. Déployez ADBA/KMS avant.
DNS : supprimez _vlmcs._tcp obsolète, ou republiez pour le nouveau KMS.
MAK : ne bascule pas tout seul. Installez la GVLK, puis /ato.
Nomades : MAK ou accès périodique au DC/KMS.
Contrôles : /xpr, /dlv, inventaire WMI, journaux SPP/KMS.

Annexe : champs et éléments utiles dans `slmgr /dlv`

Champ	Ce qu’il indique	Interprétation
License Status	État courant (Licensed, Notification…)	“Licensed” = pas d’action immédiate
Remaining Windows rearm count	Nombre de rearms restants	À ne pas utiliser pour “tricher” le cycle ; réservé aux scénarios d’image
KMS machine IP/name	Nom/IP de l’hôte KMS ciblé	Renseigné si un `/skms` a été posé ou si une découverte a trouvé un KMS
Activation type configuration	Canal attendu (KMS/MAK/ADBA)	Doit correspondre à votre stratégie cible
Key Management Service lookup domain	Domaine de découverte SRV	Utile si plusieurs domaines/forêts

Annexe : modèles de communication utilisateur

Pour éviter les tickets lors de la bascule, communiquez simplement :

“Nous changeons de mécanisme d’activation Windows. Aucun impact attendu. Si vous voyez ‘Activer Windows’ dans les semaines à venir, reconnectez‑vous au réseau/VPN ou redémarrez. Contactez l’IT si le message persiste.”

Conclusion

Vous pouvez déployer ADBA (et/ou un nouveau KMS) sans perturber l’existant. Nettoyez les SRV _vlmcs._tcp obsolètes, migrez les hôtes MAK en installant les GVLK, et outillez le suivi (WMI, journaux). Avec ce plan, la transition reste invisible pour les utilisateurs et maîtrisée pour l’équipe IT.