Vous envisagez de supprimer des CAL Utilisateur RDS en pensant activer 120 jours de grâce ? Attention : ce délai ne se déclenche pas ainsi. Voici un guide précis pour Windows Server 2019 afin d’assurer la continuité de service et la conformité.
Période de grâce après suppression de CAL Utilisateur (Remote Desktop Services, Windows Server 2019)
Vue d’ensemble de la question
Un administrateur dispose d’environ 1 000 CAL Utilisateur réparties sur deux serveurs de licences RDS. Avant d’acheter de nouveaux droits, il envisage de supprimer ces CAL et se demande si cela déclenchera automatiquement une période de grâce de 120 jours pour continuer à accepter des connexions.
Réponse courte et nette
Non. Supprimer des CAL sur un serveur de licences ne déclenche pas de nouveau délai de grâce. Les connexions peuvent continuer à fonctionner en mode « Per User » (car l’application est déclarative), mais l’environnement devient non conforme. La bonne pratique est de conserver les licences existantes jusqu’à l’installation des nouvelles, ou d’utiliser des alternatives cadrées (voir ci-dessous).
Réponse & solutions
| Point clé | Détails pratiques |
|---|---|
| Pas de période de grâce liée à la suppression manuelle | Le délai de grâce de 120 jours s’applique uniquement au premier démarrage d’un hôte de sessions RDS qui n’a pas encore pu joindre un serveur de licences. La suppression volontaire des CAL n’entre dans aucun de ces cas : aucun nouveau délai ne démarre. |
| CAL Utilisateur : absence d’application technique stricte | Contrairement aux CAL Périphérique, le mode « Per User » n’émet pas de « jeton » bloquant. Les utilisateurs pourront encore ouvrir des sessions, mais l’environnement ne sera plus conforme aux termes du contrat de licence. |
| Bonne pratique : conserver les licences existantes | Maintenez les CAL en place jusqu’à réception et installation des nouvelles. Vous évitez ainsi toute non‑conformité et tout risque juridique. |
| Solutions temporaires si des CAL doivent vraiment être retirées | Discuter avec votre revendeur ou Microsoft des options temporaires (contrats ou aménagements commerciaux) pour couvrir la transition. Installer les nouvelles CAL sur un autre serveur de licences, puis reconfigurer vos hôtes RDS pour qu’ils pointent vers ce nouveau serveur avant de supprimer les anciennes licences. |
| Vérifications complémentaires | Assurez‑vous que vos hôtes RDS sont configurés en mode « Per User » et joignent au moins un serveur de licences valide. Contrôlez régulièrement le Gestionnaire de licences Bureau à distance pour repérer toute alerte de conformité. Documentez les opérations (dates de retrait, de ré‑attribution, justificatifs d’achat) en cas d’audit. |
Information additionnelle utile
- Délai de grâce initial d’un hôte RDS : lorsqu’un serveur de sessions RDS est fraîchement installé, il bénéficie d’un délai de 120 jours pour contacter un serveur de licences. Ce délai n’est pas réinitialisé par la suppression de CAL sur le serveur de licences.
- CAL Périphérique vs CAL Utilisateur : les CAL Périphérique délivrent un jeton et peuvent bloquer la connexion une fois la limite atteinte ; les CAL Utilisateur reposent sur un suivi déclaratif.
- Audit Microsoft : en cas de contrôle logiciel, l’absence de CAL valides peut entraîner des pénalités financières. Conservez toujours les accusés de réception et les clés de licence avant toute suppression.
Comprendre réellement la « période de grâce » RDS de 120 jours
La période de grâce appartient à l’hôte de sessions RDS (RDSH), pas aux CAL elles‑mêmes. Elle sert à permettre le fonctionnement initial d’un serveur de sessions non encore rattaché à un serveur de licences. Une fois le RDSH configuré avec un serveur de licences, la suppression ou le retrait de CAL sur ce serveur n’a aucun effet pour redémarrer un compte à rebours.
En mode « Per User », l’accès ne se bloque généralement pas immédiatement, car l’application est déclarative ; c’est pourquoi on peut avoir l’illusion que « ça passe ». En revanche, le risque de non‑conformité est bien réel.
Rappel : modes de licence RDS et impacts
| Critère | CAL Utilisateur (Per User) | CAL Périphérique (Per Device) |
|---|---|---|
| Contrôle technique | Déclaratif, non bloquant à court terme | Jetons émis et suivis, blocage possible si quota atteint |
| Scénario d’usage | Utilisateurs nominatifs utilisant plusieurs appareils | Postes mutualisés, kiosques, salles de formation |
| Risque en cas de suppression | Non‑conformité sans blocage immédiat | Non‑conformité avec risques de refus de connexion pour de nouveaux appareils |
| Bonnes pratiques | Inventaire nominatif, alignement RH/IT, procédures d’entrée/sortie | Gestion du cycle de vie des jetons, réattribution maîtrisée |
Ce qu’il ne faut pas faire
- Ne pas supprimer des CAL en production en espérant récupérer 120 jours : cela n’arrivera pas.
- Ne pas tenter de « réinitialiser » un délai de grâce via des manipulations du Registre ou autres contournements : c’est non supporté et potentiellement illégal.
- Ne pas mélanger « Per User » et « Per Device » sans plan clair : vous créez une zone grise de conformité difficile à défendre.
Procédure pas‑à‑pas pour rester conforme tout en assurant la continuité
- Figer l’état : exportez l’inventaire actuel des CAL et des serveurs de licences (captures, exports du Gestionnaire de licences, listing nominatif).
- Préparer la cible : installez/activez un nouveau serveur de licences (si besoin) et ajoutez‑y les nouvelles CAL.
- Pointer les RDSH vers le nouveau serveur de licences sans toucher pour l’instant aux anciennes licences.
- Tester la résolution DNS, la connectivité RPC et l’absence d’alertes dans les journaux (voir section Dépannage).
- Basculer progressivement : appliquez la stratégie « Utiliser les serveurs de licences Bureau à distance spécifiés » vers le nouveau serveur ; validez sur un sous‑ensemble d’hôtes RDS.
- Surveiller : pendant quelques jours, contrôlez l’absence d’erreurs de licence et la charge des serveurs.
- Nettoyer : une fois la bascule terminée et documentée, désactivez le serveur de licences d’origine et, seulement alors, retirez les anciennes CAL.
Vérifier et configurer correctement la licence RDS
Via la stratégie de groupe (recommandé)
- Chemin GPO : Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Licences
- Paramètres clés :
- Définir le mode de licences des Services Bureau à distance → Par utilisateur (ou Par périphérique selon votre choix).
- Utiliser les serveurs de licences Bureau à distance spécifiés → NomNetBIOS ou FQDN de vos serveurs de licences.
- Après application, exécutez
gpupdate /forcepuis redémarrez la machine si nécessaire.
Points de contrôle rapides
- DNS : résolution correcte des serveurs de licences ; pas de doublons A/CNAME.
- Pare‑feu : autoriser RPC Endpoint Mapper (TCP 135) et ports RPC dynamiques (TCP hautes plages), plus la communication DCOM.
- Annuaire : le serveur de licences est membre du groupe Terminal Server License Servers (environnement domaine).
Journalisation et diagnostic
Sur l’hôte RDS et le(s) serveur(s) de licences, surveillez :
- Observateur d’événements > Applications and Services Logs > Microsoft > Windows > TerminalServices-* (dont Licensing, RemoteConnectionManager, LocalSessionManager).
- Gestionnaire de licences Bureau à distance (compteur de CAL installées, état du serveur, alertes).
Scripts PowerShell utiles (exemples)
Remarque : adaptez les commandes à votre contexte (déploiement avec courtier de connexions ou RDSH autonomes).
Lister les serveurs de licences déclarés côté RDSH (via Registre)
# Exécuter en tant qu'administrateur sur un RDSH
Get-ChildItem 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers' |
Select-Object PSChildName
Vérifier le mode de licences appliqué (valeur GPO)
# 2 = Per Device ; 4 = Per User
(Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services').LicensingMode
Inventorier rapidement les sessions utilisateurs actives
query user
# ou
quser /server:NomDuRDSH
Tester la connectivité RPC vers le serveur de licences
Test-NetConnection -ComputerName MonServeurLicences -Port 135
Scénarios concrets et recommandations
Scénario 1 : remplacement des CAL Utilisateur arrivant à échéance
Installez les nouvelles CAL sur un serveur de licences secondaire, pointez progressivement les RDSH vers celui‑ci via GPO, validez, puis retirez les anciennes licences. Avantage : zéro interruption, conformité maîtrisée, retour arrière simple.
Scénario 2 : consolidation de deux serveurs de licences
Activez la cible, importez toutes les CAL (ou réémission si autorisée par votre contrat), alignez les GPO, vérifiez les journaux, puis désactivez l’ancien serveur. Évitez la suppression de CAL tant que des hôtes pointent encore vers la source.
Scénario 3 : indisponibilité temporaire du serveur de licences
En « Per User », les connexions continuent souvent car l’application est déclarative. En « Per Device », des appareils déjà titulaires d’un jeton peuvent se connecter, mais les nouveaux risquent d’être bloqués. Corrigez la panne, pas les CAL.
Check‑list migration / rotation de licences
| Étape | Objectif | Valide si… |
|---|---|---|
| Inventaire | Connaître l’existant (CAL, serveurs, GPO) | Exports et captures conservés |
| Cible prête | Serveur de licences activé + nouvelles CAL | Gestionnaire de licences sans alerte |
| Redirection | RDSH pointent vers le nouveau serveur | GPO appliquées, résolution DNS OK |
| Validation | Connexions stables, journaux propres | Aucune erreur TerminalServices‑Licensing |
| Nettoyage | Retrait contrôlé des anciennes CAL | Documentation mise à jour, audit interne |
FAQ
La suppression de CAL déclenche‑t‑elle une nouvelle période de grâce de 120 jours ?
Non. La grâce de 120 jours est liée à un RDSH fraîchement installé non rattaché à un serveur de licences, pas à la présence/absence de CAL sur le serveur de licences.
Les utilisateurs pourront‑ils encore se connecter si je supprime des CAL Utilisateur ?
Souvent oui, à court terme, car l’application Per User est déclarative. Mais vous ne serez plus conforme, avec un risque financier en cas d’audit.
Existe‑t‑il des licences temporaires pour tenir la transition ?
Discutez‑en avec votre revendeur ou Microsoft. Selon vos contrats et votre historique, des options commerciales de transition peuvent être possibles. Ne comptez pas sur un « redéclenchement » de grâce.
Je suis en Per Device, que se passe‑t‑il si le serveur de licences est indisponible ?
Les postes déjà titulaires d’un jeton peuvent continuer quelque temps. Les nouveaux périphériques risquent d’être refusés. Restaurez la disponibilité du serveur de licences, évitez toute suppression de CAL.
Dépannage express
- Événements : recherchez des IDs liés à TerminalServices‑Licensing, RD Licensing Diagnosis.
- Nom DNS : préférez le FQDN et gardez une résolution cohérente depuis tous les RDSH.
- Pare‑feu réseau : vérifiez TCP 135 et les ports RPC dynamiques entre RDSH et serveur de licences.
- GPO : confirmez le mode (Per User vs Per Device) et la liste des serveurs de licences appliqués à l’OU des RDSH.
Modèle de journal de changement (à réutiliser)
Date/Heure :
Demandeur :
Motif :
Serveur(s) de licences source :
Serveur(s) de licences cible :
Nombre de CAL Utilisateur :
Nombre de CAL Périphérique :
RDSH concernés (liste/OU) :
Étapes réalisées :
Tests de validation :
Décision de bascule :
Responsable de validation :
Preuves (captures/exports) :
Erreurs fréquentes à éviter
- Supposer qu’une indisponibilité du serveur de licences ré‑accorde 120 jours : faux.
- Retirer des CAL avant d’avoir reconfiguré tous les RDSH : risque de refus de connexion (Per Device) ou de non‑conformité (Per User).
- Oublier d’ajouter le serveur de licences au groupe Terminal Server License Servers : erreurs d’autorisation.
- Négliger la documentation : en cas d’audit, l’absence de preuves pèse lourd.
Bonnes pratiques de gouvernance licence RDS
- Cycle de vie utilisateur : liez l’attribution des CAL à vos processus RH (arrivées/départs).
- Inventaire périodique : rapprochez les comptes AD actifs, les équivalents ETP et le parc de CAL.
- Segmentation : utilisez plusieurs serveurs de licences pour limiter l’impact d’une panne et faciliter les migrations.
- Automatisation : scripts d’audit (sessions, jetons), rapports périodiques, alertes sur événements.
Résumé opérationnel
- La suppression de CAL n’active pas la grâce de 120 jours.
- En « Per User », les connexions peuvent continuer mais vous êtes hors conformité.
- Conservez les CAL en place jusqu’à l’installation des nouvelles et basculer d’abord les RDSH vers le nouveau serveur de licences.
- Pour une transition : options temporaires via votre revendeur/Microsoft, ou installation en parallèle sur un autre serveur de licences.
- Tracez tout (exports, journaux, captures) pour être serein en cas d’audit.
Annexe : feuille de route détaillée de migration
- Avant‑projet : cadrage (périmètre RDSH, nombre d’utilisateurs/périphériques, calendrier, fenêtres de maintenance).
- Pré‑requis techniques : membres des groupes AD nécessaires, ports réseau ouverts, sauvegardes système, accès administratifs.
- Préparation : activation du nouveau serveur de licences, ajout des CAL, configuration GPO de test.
- Pilote : application GPO vers un lot restreint de RDSH, observation 48–72 h.
- Déploiement : extension à l’ensemble des RDSH, monitoring des événements et performances.
- Validation : revues quotidiennes des journaux, sondes d’ouverture de session, feedbacks helpdesk.
- Retrait : désactivation du serveur de licences d’origine, retrait des CAL, mise à jour CMDB et dossiers d’audit.
- Bilan : rapport de clôture (écarts, leçons apprises, indicateurs de conformité).
Clause de responsabilité : ce guide est informatif et ne remplace pas l’avis juridique ni les conditions de votre contrat de licences. Validez vos décisions avec votre revendeur et vos conseillers internes.