Migration KMS Windows Server : guide pas‑à‑pas (DNS _vlmcs, TCP 1688, slmgr, Office)

Migrer un hôte KMS sans interruption repose sur trois leviers : DNS, clés CSVLK et automatisation PowerShell. Ce guide pratique propose un runbook éprouvé pour remplacer votre serveur KMS tout en gardant Windows et Office activés en continu.

Sommaire

Vue d’ensemble de la question

Objectif : désactiver proprement un ancien hôte KMS et en déployer un nouveau, afin que tous les clients Windows (et éventuellement Office) basculent dessus automatiquement. Faut‑il retirer la clé KMS de l’ancien serveur ? Quel service opère KMS ? Comment garantir l’absence d’interruption ?

Ce qui fait fonctionner KMS

Service : Software Protection Service (nom de service sppsvc), écoute par défaut en TCP 1688 et peut publier l’enregistrement DNS SRV _vlmcs._tcp.
Office (côté clients) : Office Software Protection Platform (osppsvc).
Clés :
- CSVLK (clé d’hôte KMS) à installer sur le serveur KMS.
- GVLK (clé générique client volume) côté clients Windows/Office.
Découverte : via DNS (_vlmcs._tcp) ou ciblage explicite du KMS (slmgr /skms ou ospp.vbs /sethst).

Architecture & paramètres clés

Ports et services

Composant	Service / Binaire	Port	Rôle
KMS (Windows)	`sppsvc`	TCP 1688 (écoute)	Réception des requêtes d’activation/renouvellement
Client Office	`osppsvc`	Sortant vers 1688	Appelle l’hôte KMS pour activer/renouveler

Enregistrement DNS SRV pour KMS

Champ	Valeur	Remarques
Service	`_vlmcs`	Service KMS
Protocole	`_tcp`	TCP obligatoire
Port	1688	Port par défaut KMS
Cible	FQDN du nouveau KMS	Par ex. `kms‑new.contoso.local`
TTL	5–15 min (migration)	Baissez le TTL avant le basculement
Priorité/Poids	Priorité basse, poids élevé	Pour favoriser le nouveau serveur en phase de cohabitation

Cycle de contact des clients KMS

Moment	Périodicité par défaut	But	Conséquence
Avant activation	toutes les ~2 heures	Découvrir/contacter un hôte KMS	Re‑essaye jusqu’à succès
Après activation	tous les ~7 jours	Renouvellement d’activation	La validité reste à 180 jours
Expiration	~180 jours	Au‑delà, retour à l’état de notification	Nécessite un KMS joignable

Plan de migration recommandé (sans interruption)

Préparer le nouvel hôte KMS

OS et rôle : mettre à jour le serveur (patches), joindre au domaine et installer le rôle Volume Activation Services. Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools
Clé d’hôte KMS (CSVLK) : assurez-vous de disposer d’une CSVLK correspondant à votre version (Windows Server 2022/2019, etc.).
Pare‑feu : ouvrir le port TCP 1688 en entrée depuis le réseau interne. New-NetFirewallRule -DisplayName "KMS TCP 1688" -Direction Inbound -Protocol TCP -LocalPort 1688 -Action Allow
DNS : valider la publication SRV automatique (si autorisée) ou préparer la création manuelle de _vlmcs._tcp avec un TTL réduit.
Office (si concerné) : installer le Volume License Pack correspondant sur l’hôte KMS.
Heure/DNS/AD : synchronisation NTP, résolution DNS et intégration AD opérationnelles.

Installer et activer KMS sur le nouveau serveur

slmgr.vbs /ipk <clé CSVLK Windows>
slmgr.vbs /ato
:: Office côté hôte KMS via l’assistant du Volume License Pack

Vérifiez l’état KMS de l’hôte :

slmgr.vbs /dlv

Basculer la découverte/pointage des clients

Méthode recommandée : DNS SRV — mettez à jour _vlmcs._tcp pour cibler le nouveau serveur (baissez le TTL, utilisez priorité/poids pour favoriser le nouveau tout en gardant l’ancien accessible).

# Exemple de publication SRV (serveur DNS Windows)
Add-DnsServerResourceRecord -ZoneName "domaine.local" `
  -Srv -Name "_vlmcs._tcp" -DomainName "kms-nouveau.domaine.local" `
  -Priority 0 -Weight 100 -Port 1688

Méthode forcée (temporaire, GPO/commande) — utile pour pré‑amorcer le compteur KMS ou traiter des segments réseau isolés.

slmgr.vbs /skms kms-nouveau.domaine.local:1688
slmgr.vbs /ato

\:: Clients Office
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /sethst\:kms-nouveau.domaine.local
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /act

Une fois le basculement validé, revenez à l’auto‑découverte DNS si souhaité :

slmgr.vbs /ckms

Vérifier finement

Résolution DNS : Resolve-DnsName -Type SRV _vlmcs._tcp.domaine.local
Connectivité : Test-NetConnection kms-nouveau.domaine.local -Port 1688
Statut côté clients : slmgr.vbs /dli slmgr.vbs /dlv cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /dstatus
Journaux : Observateur d’événements > Microsoft > Windows > Software Protection Platform. Recherchez les événements d’activation/réponse KMS.

Retirer l’ancien hôte KMS (après bascule confirmée)

Supprimer/mettre à jour l’enregistrement DNS SRV pointant vers l’ancien serveur.
Désactiver l’écoute 1688 (règle pare‑feu) ou désinstaller le rôle si souhaité.
Désinstaller la clé KMS (recommandé pour éviter toute confusion) : slmgr.vbs /upk slmgr.vbs /cpky
Nettoyer le Volume License Pack Office si installé.

Pourquoi ce plan évite l’interruption

Les clients activés disposent d’une fenêtre de validité (~180 jours) et renouvellent toutes les ~semaines. En cas de bascule, ils continuent de fonctionner si l’un des hôtes KMS est joignable.
La cohabitation temporaire (priorité/poids DNS) permet d’atteindre rapidement les seuils KMS sur le nouveau serveur sans couper l’ancien.
Le TTL bas du SRV accélère la propagation du changement.

Bonnes pratiques & points d’attention

Seuils KMS : au minimum 25 clients pour Windows client (10/11) et 5 pour Windows Server (et Office) avant que l’hôte n’émette des activations.
Pré‑amorçage : forcez temporairement 5 serveurs + 25 postes à pointer vers le nouveau KMS pour franchir les seuils, puis revenez à DNS.
GVLK : vérifiez que les clients utilisent des clés GVLK (et non des MAK). Le cas échéant, reconfigurez et activez.
Sécurité : limitez le port 1688 au réseau interne, surveillez les journaux, et évitez toute exposition Internet.
Horloge et DNS : une dérive NTP ou une résolution défaillante est la cause n°1 des échecs d’activation.
Alternative : en environnement AD, AD‑Based Activation (ADBA) supprime la dépendance au SRV DNS (activation via AD).

Méthode DNS vs méthode forcée (GPO/commande)

Approche	Avantages	Limites	Quand l’utiliser
DNS SRV (`_vlmcs._tcp`)	Automatique, scalable, haute compatibilité	Dépend du DNS dynamique et du TTL	Par défaut et en régime permanent
Forcée (`/skms` ou GPO)	Contrôle fin, utile pour pré‑amorcer	Nécessite un retour à l’auto‑découverte (`/ckms`)	Migration, segments isolés, dépannage

Automatiser la bascule (exemples PowerShell)

Publier/ajuster le SRV avec un TTL court

$zone     = "domaine.local"
$target   = "kms-nouveau.domaine.local"
$ttl      = [TimeSpan]::FromMinutes(5)
Add-DnsServerResourceRecord -ZoneName $zone -Srv -Name "_vlmcs._tcp" `
  -DomainName $target -Priority 0 -Weight 100 -Port 1688 -TimeToLive $ttl

Forcer un échantillon de machines à pointer sur le nouveau KMS

$computers = @("SRV01","SRV02","PC001","PC002","PC003","PC004","PC005","PC006","PC007","PC008","PC009","PC010",
               "PC011","PC012","PC013","PC014","PC015","PC016","PC017","PC018","PC019","PC020","PC021","PC022","PC023","PC024","PC025")
$kms = "kms-nouveau.domaine.local:1688"
Invoke-Command -ComputerName $computers -ScriptBlock {
  param($kms)
  cscript.exe //nologo $env:windir\system32\slmgr.vbs /skms $kms
  cscript.exe //nologo $env:windir\system32\slmgr.vbs /ato
} -ArgumentList $kms

Vérifier l’état d’activation via CIM

Get-CimInstance -ClassName SoftwareLicensingProduct `
 | Where-Object { $_.PartialProductKey -and $_.Name -match "Windows" } `
 | Select-Object Name, LicenseStatus, GracePeriodRemaining

Suivre l’activité KMS dans les journaux

# Exemples d’Event IDs fréquents à filtrer
Get-WinEvent -LogName "Microsoft-Windows-Security-SPP/Software Protection Platform Service" |
  Where-Object { $_.Id -in 12288,12289,12290,12291 } |
  Select-Object TimeCreated, Id, Message

Checklist opérationnelle

CSVLK validée et activée (slmgr /ato sur le nouveau KMS).
Port 1688 accessible depuis tous les segments (pare‑feu/NACL).
SRV _vlmcs._tcp publié avec TTL court et priorité vers le nouveau KMS.
Seuils KMS atteints (5 serveurs, 25 postes minimum selon produits).
Échantillon de clients testés (slmgr /dlv, ospp.vbs /dstatus).
Journaux vérifiés et absence d’erreurs récurrentes.
Ancien hôte décommissionné (clé retirée, SRV nettoyé, port fermé).

Dépannage express (codes fréquents)

Code/Message	Cause probable	Action corrective
`0xC004F074` (Host non joignable)	DNS/pare‑feu/port 1688 bloqué	Tester `Resolve-DnsName`, `Test-NetConnection`, corriger le SRV/pare‑feu
`0xC004F038` (Seuil non atteint)	Nouveau KMS sans suffisamment de clients	Forcer un groupe de clients vers le nouveau KMS, attendre la montée du compteur
`0xC004F042` (Réponse invalide)	Clé/édition incompatibles, service instable	Vérifier la CSVLK, redémarrer `sppsvc`, contrôler les versions
Office non activé	Hôte non défini côté Office	`ospp.vbs /sethst:<KMS>` + `/act`, vérifier `osppsvc`

Scénarios particuliers

Multi‑domaines/forêts : publiez le SRV dans chaque zone DNS pertinente, ou utilisez /skms avec FQDN. Assurez la résolution inter‑forêts.
VDI/masters clonés : toujours sysprep pour générer un CMID unique afin d’éviter des compteurs faussés.
Deux hôtes KMS (tolérance de panne) : publiez deux SRV avec priorités/poids. Le client sélectionne selon ces paramètres.
ADBA : si vous basculez vers l’activation basée sur AD, les clients s’activent lors de l’authentification au domaine, sans SRV KMS.

Plan de retrait sécurisé de l’ancien hôte

S’assurer que tous les tests client/serveur passent via le nouveau KMS et que les seuils sont stables.
Supprimer l’entrée SRV de l’ancien hôte et augmenter légèrement le TTL (ex. 1 h) pour le régime permanent.
Bloquer/retirer l’écoute 1688 sur l’ancien serveur.
Retirer la clé KMS et nettoyer le registre : slmgr.vbs /upk slmgr.vbs /cpky
Désinstaller le rôle Volume Activation Services si non réutilisé.

Plan de secours (rollback)

Conservez l’ancien SRV (à priorité supérieure) pendant la phase de test. En cas de souci, rétablissez sa priorité/poids pour reprendre la main immédiatement.
Conservez une règle GPO de bascule forcée (/skms) prête à être appliquée sur un OU critique.
Documentez l’état initial (export SRV, capture slmgr /dlv) pour revenir en arrière à l’identique.

Résumé des commandes utiles

:: Ancien KMS (retrait)
slmgr.vbs /upk
slmgr.vbs /cpky

\:: Nouveau KMS (installation)
slmgr.vbs /ipk \
slmgr.vbs /ato

\:: Clients Windows (bascule temporaire)
slmgr.vbs /skms kms-nouveau.domaine.local:1688
slmgr.vbs /ato
slmgr.vbs /ckms   :: revenir à l’auto‑découverte DNS

\:: Vérifications Windows
slmgr.vbs /dli
slmgr.vbs /dlv

\:: Office (client)
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /dstatus
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /sethst\:kms-nouveau.domaine.local
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /act

\:: Réseau/DNS
Resolve-DnsName -Type SRV \_vlmcs.\_tcp.domaine.local
Test-NetConnection kms-nouveau.domaine.local -Port 1688

Réponse aux questions initiales, en bref

Comment désactiver l’ancien hôte et déployer le nouveau ? Installez/activez la CSVLK sur le nouveau serveur, publiez/ajustez le SRV _vlmcs._tcp pour le favoriser (TTL court), validez, puis retirez l’ancien (clé, 1688, SRV).
Faut‑il retirer la clé de l’hôte KMS actuel ? Pas strictement obligatoire si le serveur est décommissionné immédiatement, recommandé pour éviter tout pointage résiduel : slmgr /upk puis /cpky et nettoyage DNS.
Quel service fait fonctionner KMS ? sppsvc (Software Protection Service) à l’écoute en TCP 1688 et publication SRV _vlmcs._tcp si autorisée. Pour Office côté clients : osppsvc.

FAQ courte

Dois‑je réactiver tous les clients ? Non. Ils renouvellent automatiquement contre le nouveau KMS dès qu’ils le découvrent (ou qu’ils y sont pointés).
Que se passe‑t‑il si le nouveau KMS redémarre ? Les clients réessaient selon leur intervalle. Tenez l’ancien en cohabitation pendant la phase de rodage.
Peut‑on avoir deux KMS actifs ? Oui. Publiez deux SRV avec priorités/poids différents pour la répartition et la tolérance de panne.
Et si des machines sont en MAK ? Elles ne basculeront pas vers KMS tant que vous ne les reconfigurez pas en GVLK.

Avec ce runbook, la migration d’un hôte KMS se résume à : préparer le nouveau serveur, publier correctement le SRV DNS, vérifier, puis retirer proprement l’ancien. En respectant les seuils KMS et en contrôlant le TTL, la transition se fait sans interruption.