Vous craignez qu’une CAL RDS Per Device cesse soudainement de fonctionner ou que le clonage d’une VM rompe vos licences ? Voici un guide complet, concret et éprouvé pour sécuriser votre environnement Windows Server 2019/2022.
Durée de validité d’une licence RDS Per Device CAL
Problème
L’utilisateur craint qu’une licence Remote Desktop Services (RDS) « Per Device » achetée pour un serveur Windows Server 2019/2022 expire soudainement, provoquant une indisponibilité immédiate pour ses clients.
Solution
- Licence perpétuelle : une CAL RDS Per Device achetée via un contrat de licence perpétuelle (Microsoft Store, Volume Licensing, etc.) n’expire pas. Une fois activée sur le serveur de licences RDS, elle reste valide pendant toute la durée de vie du serveur et du poste client visé.
- Renouvellement automatique côté client : lors de la première connexion, le client reçoit un jeton temporaire, puis un jeton permanent. Ce jeton, stocké dans la ruche
HKLM\Software\Microsoft\MSLicensing, se renouvelle automatiquement (généralement tous les 52–89 jours) tant que le poste continue d’utiliser le service. Aucune intervention manuelle n’est requise. - Risques d’expiration : la seule perte possible survient si le serveur de licences est réinitialisé, corrompu ou si une CAL est révoquée manuellement. Prévenez ces risques en réalisant des sauvegardes régulières de la base de licences RDS et du serveur de licences.
Informations complémentaires utiles
- Les licences RDS de type Subscription ou SPLA (paiement mensuel) sont différentes : elles expirent si l’abonnement n’est pas renouvelé.
- Les CAL RDS sont indépendantes des licences Windows Server OEM/Volume de l’OS serveur.
- Un hôte de sessions RDS (RD Session Host) dispose d’une période de grâce (environ 120 jours) pour la découverte/licensing. Elle évite une coupure immédiate dans les déploiements neufs, mais ne remplace pas l’activation et l’installation de CAL.
Comment cela fonctionne en pratique
Le serveur de licences RDS (rôle Remote Desktop Licensing) émet des jetons pour les appareils qui se connectent à un hôte de sessions. Le cycle est le suivant :
- Première connexion d’un appareil : attribution d’une licence temporaire.
- Connexion suivante réussie : conversion en licence permanente (si des CAL sont disponibles).
- Le jeton se renouvelle automatiquement tant que l’appareil revient régulièrement (fenêtre 52–89 jours).
Résultat : avec des CAL perpétuelles correctement installées, il n’y a pas de « date d’expiration » provoquant une panne brutale. L’infrastructure continue de délivrer des jetons renouvelés aux machines qui se reconnectent.
Vérifier l’état de vos CAL (check-list rapide)
- Ouvrez Gestionnaire de licences Bureau à distance (licmgr.exe) sur le serveur de licences : vérifiez l’activation du serveur et les packs de CAL installés (type, version, quantité, utilisées/disponibles).
- Sur l’hôte de sessions, ouvrez le Diagnostiqueur de licences RDS (via le Gestionnaire de serveur) : validez le mode de licence, les serveurs découverts et l’absence d’erreurs.
- Sur un poste client, contrôlez la présence du jeton sous
HKLM\Software\Microsoft\MSLicensing. (Prudence : n’effacez jamais ce nœud sans sauvegarde et sans plan de ré-attribution.)
Configurer proprement les hôtes de sessions
Assurez-vous que chaque RD Session Host pointe vers le(s) serveur(s) de licences et qu’il est en mode Per Device. Deux méthodes robustes :
Via Stratégie de groupe (recommandé en domaine)
- Ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Gestion des licences.
- Activez Utiliser les serveurs de licences Bureau à distance spécifiés et indiquez le(s) nom(s) FQDN.
- Activez Définir le mode de gestion des licences Bureau à distance et choisissez Par périphérique.
Via Registre (scénarios hors domaine / automatisation)
REM Mode "Per Device"
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core" ^
/v LicensingMode /t REG_DWORD /d 2 /f
REM Serveurs de licences (créez une clé par serveur)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\LicenseServers\licsrv01" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\LicenseServers\licsrv02" /f Via PowerShell (déploiements gérés)
Dans un déploiement RDS standard (avec Connection Broker) :
# Exécuter en administrateur sur le Connection Broker
Import-Module RemoteDesktop
Set-RDLicenseConfiguration -LicenseServer @("licsrv01.contoso.local","licsrv02.contoso.local") -Mode PerDevice
Sauvegarder et restaurer le serveur de licences
Le cœur des licences réside dans %SystemRoot%\System32\lserver\TLSLic.edb et dans des clés de registre associées. Bonnes pratiques :
- Utilisez la fonction Sauvegarder du Gestionnaire de licences RDS pour capturer la base et l’activation.
- Pour une copie à froid, arrêtez le service Remote Desktop Licensing, copiez
TLSLic.edb, puis redémarrez. - Documentez vos packs (ID, quantité, type) afin de pouvoir les réémettre via le Clearinghouse si nécessaire (en cas de reconstruction sans sauvegarde).
Astuce : planifiez une tâche hebdomadaire qui exporte le registre lié aux licences et copie
TLSLic.edbaprès stop du service. Vous minimisez ainsi l’impact d’un incident matériel ou d’une corruption système.
Impact du clonage ou de la duplication du serveur sur les licences
Problème
Vous souhaitez cloner un serveur (instantané VM, image « golden image », réplication) et vous vous demandez l’effet sur les licences RDS Per Device existantes, tant pour l’original que pour le clone.
Solution
Identité du serveur de licences
- Chaque instance de serveur de licences RDS possède un identifiant unique généré au moment de son activation.
- Cloner une machine contenant déjà le rôle Remote Desktop Licensing duplique cet identifiant : Microsoft considère qu’il s’agit d’un second serveur distinct, nécessitant sa propre activation et ses propres CAL.
Recommandations lors du clonage
| Étape | Action conseillée |
|---|---|
| Avant clonage | Désinstallez ou désactivez le rôle Services Bureau à distance (au minimum le rôle Licence Server) sur la source, ou généralisez l’image (sysprep /generalize) pour supprimer l’ID du serveur de licences. |
| Après clonage | Si vous avez besoin d’un deuxième serveur de licences, activez-le et installez un nouveau pack de CAL. Sinon, configurez le clone pour qu’il pointe vers le serveur de licences d’origine (via GPO ou paramètres RDS) et n’installez pas le rôle « Licence Server » sur le clone. |
| CAL existantes | Les CAL déjà attribuées aux dispositifs (stockées côté client) restent valides et continueront à être renouvelées, à condition que le nouveau serveur de licences dispose de suffisamment de CAL disponibles pour ces dispositifs. |
Scénarios courants et décisions
| Scénario | Rôle « Licensing » sur le clone | Action sur les CAL | Remarques |
|---|---|---|---|
| Mise à l’échelle horizontale (nouvel hôte de sessions) | Non | Pointer l’hôte vers le serveur de licences existant | Simple, aucun nouveau pack requis si le stock est suffisant. |
| Résilience du serveur de licences (licsrv01 & licsrv02) | Oui (deuxième serveur de licences) | Installer un pack dédié ou redistribuer via le Clearinghouse | Configurez deux serveurs de licences dans vos GPO pour la haute dispo. |
| Clonage d’une « golden image » avec le rôle Licensing | À éviter | Retirer le rôle avant capture ou sysprep /generalize | Sinon, identités dupliquées et activation incohérente. |
| Migration vers un nouveau serveur | Oui (sur le nouveau) | Activer, installer/reporter les packs, repointer les hôtes | Planifier une fenêtre, tester, et conserver l’ancien en secours temporaire. |
Étapes de migration d’un serveur de licences
- Préparer le nouveau serveur : installer le rôle Remote Desktop Licensing, puis l’activer.
- Installer ou déplacer les CAL : si vous avez une sauvegarde (
TLSLic.edb+ registres), restaurez-la. Sinon, réémettez les packs (détails du contrat requis) via le centre d’activation. - Configurer les hôtes de sessions : via GPO, indiquez le nouveau ou les deux serveurs (Use the specified Remote Desktop license servers), et vérifiez le mode Per Device.
- Validation : contrôlez le Diagnostiqueur, les journaux événements et simulez quelques connexions clientes.
- Basculer : une fois validé, vous pouvez retirer l’ancien serveur, ou le conserver en backup le temps d’un cycle complet de renouvellement.
Bonne pratique
- Traçabilité : maintenez un inventaire clair de vos CAL (type, quantité, version, ID d’installation) et de vos serveurs de licences.
- Sauvegarde : exportez régulièrement la base
%SystemRoot%\System32\lserver\TLSLic.edbet utilisez l’outil de sauvegarde intégré. - Automatisation : appliquez des GPO homogènes à tous les hôtes de sessions pour éviter les divergences de configuration.
Dépannage : erreurs courantes et correctifs rapides
| Symptôme | Cause probable | Correctif |
|---|---|---|
| « Aucun serveur de licences RDS n’a été trouvé » | Découverte impossible, GPO manquante ou DNS/FW | Configurer explicitement le(s) serveur(s) de licences via GPO ou Registre ; vérifier DNS, pare-feu, et droits. |
| « Pas de CAL disponibles » alors qu’il y en a | Mode de licence incorrect sur l’hôte (Per User vs Per Device) | Forcer Per Device via GPO/Registre, redémarrer l’hôte de sessions. |
| Clients subitement refusés | Serveur de licences indisponible/corrompu | Rétablir depuis sauvegarde TLSLic.edb ou réémettre les packs ; prévoir un second serveur de licences. |
| Un poste consomme plusieurs CAL | Clonage client sans nettoyage de la clé MSLicensing | Dans le master VDI, avant sysprep, purger la clé HKLM\Software\Microsoft\MSLicensing (snapshot), puis laisser chaque clone recevoir son jeton. |
| La révocation d’une CAL échoue | Quota de révocations atteint / droits insuffisants | Attendre la fenêtre suivante ou contacter le support d’activation pour assistance ; utiliser un compte admin du serveur de licences. |
| Le Diagnostiqueur indique « période de grâce » | Hôte non licencié ou non joint à un serveur de licences | Configurer le serveur de licences et installer les CAL avant la fin des ~120 jours. |
Procédure sûre pour « réinitialiser » un client
- Créer un point de restauration ou une sauvegarde du Registre du poste.
- Supprimer uniquement la clé
HKLM\Software\Microsoft\MSLicensing(session admin élevée). - Relancer la connexion RDS : le serveur de licences réémettra un jeton propre.
Important : n’effacez pas la base TLSLic.edb du serveur de licences sans stratégie de restauration ou de réémission documentée.
Choisir entre Per Device et Per User
| Critère | Per Device | Per User |
|---|---|---|
| Postes partagés (ateliers, bornes, salles) | Excellent | Moyen |
| Utilisateurs multi‑appareils (PC, laptop, tablette) | Moyen | Excellent |
| VDI non persistant | À cadrer (nettoyage jetons) | Souvent préférable |
| Suivi & conformité | Basé sur appareils | Basé sur identités |
Dans le contexte de cet article, vous disposez de CAL Per Device : leur comportement de renouvellement automatique et leur caractère perpétuel en font un choix sûr pour les parcs fixes et les postes partagés.
Modèle opérationnel recommandé
- Deux serveurs de licences (si possible) : licsrv01 et licsrv02, tous deux activés, référencés par GPO.
- Inventaire mensuel : rapprocher CAL installées et CAL émises, vérifier les tendances d’usage.
- Backups automatisés :
TLSLic.edb+ export Registre + captures d’écran des packs/ID. - Politique de clonage :
sysprep /generalizepour les images serveur, purgeMSLicensingdans les images client. - Surveillance : alertes sur événements RDS Licensing et seuils de CAL disponibles.
FAQ rapide
Une CAL Per Device peut‑elle « arriver à échéance » et couper l’accès ?
Non. La CAL est perpétuelle. Le jeton côté client a une date de renouvellement (52–89 jours) mais il se met à jour automatiquement tant que l’appareil se reconnecte périodiquement. Que se passe‑t‑il si le serveur de licences est perdu sans sauvegarde ?
Vous pouvez réinstaller le rôle, l’activer et réémettre vos packs via le centre d’activation en fournissant les informations de contrat. D’où l’intérêt d’un inventaire précis. Puis‑je déplacer des CAL d’un serveur à un autre ?
Oui, via une réémission (restauration de sauvegarde ou contact d’activation). Les CAL ne sont pas « attachées » à vie à un serveur unique. En clonant un serveur avec le rôle Licensing, est‑ce supporté ?
Non, pas tel quel. Il faut supprimer le rôle avant la capture ou sysprep /generalize afin que chaque instance soit activée proprement, avec ses propres CAL. Comment éviter que des clones VDI consomment des CAL en double ?
Dans la golden image, purgez HKLM\Software\Microsoft\MSLicensing avant sysprep pour forcer chaque clone à obtenir un jeton unique. Existe‑t‑il une limite de révocation des CAL Per Device ?
Oui, la révocation n’est pas illimitée par design. Si vous atteignez un plafond de révocations, patientez ou sollicitez l’assistance d’activation avec la preuve d’achat.
Résumé global
- Licence RDS Per Device = licence perpétuelle : pas de coupure inopinée tant que le serveur de licences reste opérationnel.
- Clonage de serveur : considéré comme une nouvelle machine ; soit le lier au serveur de licences existant, soit en activer un nouveau avec un pack de CAL propre.
- Points de vigilance : sauvegarde du serveur de licences, cohérence entre le nombre de dispositifs et le nombre de CAL, distinction entre licences perpétuelles et licences par abonnement.
Exemples de procédures pas‑à‑pas
Activer un nouveau serveur de licences
- Installer le rôle Remote Desktop Licensing.
- Ouvrir Gestionnaire de licences > clic droit sur le serveur > Activer le serveur > Connexion automatique.
- Une fois activé, Installer les licences > renseigner le programme (Open/EA/Retail) et l’ID produit.
- Vérifier l’état : Activé, packs visibles, compteur « Distribuées/Disponibles » fonctionnel.
Pointer un hôte de sessions vers deux serveurs de licences (GPO)
- Créer/éditer une GPO liée à l’OU des serveurs RDS.
- Configurer :
- Use the specified Remote Desktop license servers :
licsrv01.contoso.local, licsrv02.contoso.local - Set the Remote Desktop licensing mode : Per Device
- Use the specified Remote Desktop license servers :
- Forcer l’application (
gpupdate /force) et redémarrer au besoin. - Contrôler via le Diagnostiqueur et les journaux événements.
Script de vérification rapide (PowerShell)
# Vérifie le mode de licence sur un hôte RDS
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core"
(Get-ItemProperty -Path $path).LicensingMode # 2 = PerDevice, 4 = PerUser
# Liste des serveurs de licences déclarés
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\LicenseServers" | Select-Object PSChildName Gouvernance et conformité
Pour rester conforme et éviter toute surprise lors d’un audit :
- Tenir un registre des achats (contrats, IDs, quantités) et des affectations (Issued vs Available).
- Documenter les changements (migrations, réémissions, révocations), datés et approuvés.
- Standardiser les procédures (GPO, sauvegardes, DRP) dans votre centre de compétences Windows Server.
Cette discipline opérationnelle garantit que vos CAL Per Device — par nature perpétuelles — demeurent un non‑sujet, même en cas de clonage, d’extension de capacité ou de reprise après incident.
Conclusion
Une CAL RDS Per Device bien gérée ne s’« éteint » pas du jour au lendemain. Le mécanisme de jeton renouvelé automatiquement protège vos utilisateurs, tandis que des pratiques simples — GPO cohérentes, sauvegardes de TLSLic.edb, politique de clonage maîtrisée — éliminent les scénarios d’interruption. En consolidant vos serveurs de licences, en automatisant la configuration et en tenant un inventaire clair, vous obtenez une plateforme RDS Windows Server 2019/2022 prévisible, résiliente et conforme.