Votre hôte RD Session Host refuse toute nouvelle connexion après 120 jours ? Voici une procédure claire pour rétablir l’accès en urgence, remettre votre environnement en conformité (CAL RDS) et, si nécessaire, basculer vers des alternatives cloud.
Vue d’ensemble du problème
Sur Windows Server, le rôle RD Session Host (RDS) dispose d’une période de grâce de 120 jours. À son expiration, le serveur n’accepte plus les nouvelles sessions RDP « utilisateur », même si le service Bureau à distance est démarré. Le but de cette période est de vous laisser le temps d’installer un Serveur de licences RDS et d’y déposer des CAL RDS (Client Access Licenses) en mode Par utilisateur ou Par périphérique.
Symptômes typiques
- L’utilisateur reçoit un message indiquant que l’ordinateur distant ne peut pas accepter la connexion ou qu’aucun serveur de licences n’est disponible.
- Les deux sessions d’administration « /admin » fonctionnent encore, mais les sessions utilisateur échouent.
- Dans l’Observateur d’événements (journaux TerminalServices*), des avertissements signalent l’absence de mode de licence ou de serveur de licences.
Pourquoi cela arrive
La période de grâce démarre lorsque le rôle RD Session Host est installé. Sans configuration de licence RDS valide, le serveur bride les connexions au terme des 120 jours. Les deux connexions d’administration restent disponibles si le rôle RD Session Host n’est pas installé ; dès que ce rôle est présent, toutes les connexions RDP utilisateur exigent des CAL.
Accès d’urgence (légal) pour intervenir
Si vous avez perdu l’accès « utilisateur », il existe deux portes d’entrée, sans utiliser de CAL, pour dépanner et remettre le serveur en conformité :
- Session console / administrative depuis un poste d’admin :
mstsc.exe /adminCette session n’« consomme » pas de CAL RDS. Elle est réservée à l’administration. - Ouverture de session locale sur la machine (accès physique, iDRAC/ILO/Hyper‑V Console, etc.).
Astuce : si deux sessions d’admin sont déjà occupées, libérez-les :
quser
logoff <ID-de-session>Panorama des options
| Approche | Principe | Avantages | Inconvénients / Risques |
|---|---|---|---|
| Acheter des CAL RDS (User ou Device) | Activer le serveur de licences, installer les CAL, configurer le mode. | Conforme aux contrats Microsoft ; retour à la normale rapide. | Coût immédiat. |
| Licences en volume | Achat groupé (Open Value, CSP, etc.) pour réduire le prix unitaire. | Économies d’échelle ; administration centralisée. | Engagement sur des quantités / durée. |
| Solutions cloud (Azure Virtual Desktop, Windows 365) | Déporter l’exécution des sessions/applications sur un service managé. | Facturation à l’usage, élasticité, moins d’infrastructure à maintenir. | Migration à planifier, dépendance réseau/Internet. |
| Désinstaller RD Session Host | Revenir au mode « Administration à distance » (2 sessions). | Récupération immédiate des deux sessions d’admin sans CAL. | Perte des fonctionnalités RDS (ses. multiples, RemoteApp, etc.). |
Chemin rapide recommandé (conforme)
Dans la majorité des cas, il est plus simple et sûr d’activer un serveur de licences et d’installer des CAL. Voici une procédure compacte, avec alternatives GUI/PowerShell.
1) Installer/activer le serveur de licences RDS
- Sur un serveur (idéalement deux pour la haute dispo), installez la fonctionnalité Remote Desktop Licensing :
Install-WindowsFeature RDS-Licensing -IncludeManagementTools - Ouvrez « Gestionnaire de licences Bureau à distance » et activez le serveur (méthode automatique/téléphone selon vos contraintes).
- Installez votre pack de CAL (Per User ou Per Device) sur ce serveur de licences.
2) Déclarer le mode et le serveur de licences sur le RD Session Host
Option A – Stratégie locale/GPO
- Ouvrez l’Éditeur de stratégie de groupe (ou un GPO domaine) et définissez :
- Ordinateur → Modèles d’administration → Composants Windows → Services Bureau à distance → Hôte de session Bureau à distance → Licences
- Définir le mode de licences des Services Bureau à distance : Par utilisateur ou Par périphérique.
- Utiliser les serveurs de licences Services Bureau à distance spécifiés : renseignez le ou les noms FQDN de vos serveurs (
rdlsrv1.contoso.local; rdlsrv2.contoso.local).
Option B – PowerShell (rapide, scriptable)
# 2 = PerDevice, 4 = PerUser
$LicenseMode = 4
$LicenseServers = @("rdlsrv1.contoso.local","rdlsrv2.contoso.local")
$cim = Get-WmiObject -Namespace "root\cimv2\TerminalServices" -Class "Win32_TerminalServiceSetting"
$cim.SetSpecifiedLicenseServerList(($LicenseServers -join ",")) | Out-Null
$cim.SetLicensingType($LicenseMode) | Out-Null
# Appliquer la stratégie et redémarrer le service RDP
gpupdate /target:computer /force
Restart-Service TermService -Force3) Vérifier et tester
- Depuis un poste client, ouvrez une session RDP « utilisateur » classique et vérifiez l’absence d’erreur.
- Contrôlez les journaux TerminalServices‑* dans l’Observateur d’événements : pas d’alerte liée à la licence.
- Sur le serveur de licences, confirmez que les CAL sont émises (pour le mode « Par périphérique »). En « Par utilisateur », le suivi est déclaratif : conservez une preuve de conformité.
Choisir entre CAL « Par utilisateur » et « Par périphérique »
| Critère | User CAL (Par utilisateur) | Device CAL (Par périphérique) |
|---|---|---|
| Scénario | Un utilisateur se connecte depuis plusieurs postes (bureau, domicile, mobilité). | Plusieurs personnes partagent un même poste (atelier, kiosque, call‑center). |
| Gestion | Suivi administratif (déclaratif côté licence), flexible pour la mobilité. | Attribution technique tracée par le serveur de licences. |
| Coût | Optimal si le ratio utilisateurs/postes > 1. | Optimal si le ratio utilisateurs/postes < 1. |
Compatibilité des versions de CAL RDS
Une CAL RDS doit être de même version ou plus récente que la version du serveur RDS : une CAL « n+1 » couvre en général « n », mais l’inverse n’est pas vrai. Vérifiez votre parc et standardisez autant que possible.
| Version du serveur RDS | CAL minimales recommandées | Remarque |
|---|---|---|
| Windows Server 2016 | CAL 2016 (ou supérieures) | Les CAL plus récentes restent compatibles. |
| Windows Server 2019 | CAL 2019 (ou supérieures) | Évitez les mixes hétérogènes par site. |
| Windows Server 2022 | CAL 2022 | Choix recommandé pour une pérennité maximale. |
Désinstaller le rôle RD Session Host pour récupérer 2 sessions d’admin
Si vos besoins ne dépassent pas l’administration à distance (deux connexions simultanées), retirez le rôle RD Session Host :
Uninstall-WindowsFeature RDS-RD-Server -RestartAprès redémarrage, vous retrouvez les deux connexions d’administration (sans CAL) mais vous perdez les fonctionnalités RDS (RemoteApp, sessions multiples, profils itinérants, etc.).
Alternatives cloud : quand AVD / Windows 365 a du sens
Si l’achat de CAL n’est pas immédiat ou si vous voulez réduire l’empreinte on‑premises, évaluez :
Azure Virtual Desktop (AVD)
- Mutualisation de VMs (pooling), montée/descente en charge.
- Facturation au compute/stockage ; nécessite Azure AD/entra ID, FSLogix pour profils, et une image maîtrisée.
- Idéal pour des usages « en pointes » ou saisonniers.
Windows 365
- PC Cloud dédié par utilisateur (forfait mensuel).
- Très simple à opérer, coût prévisible, montée en version automatique.
- Pertinent si vous valorisez la simplicité plus que l’optimisation fine des coûts.
| Critère | RDS (on‑prem) | AVD | Windows 365 |
|---|---|---|---|
| CapEx / OpEx | CAL + serveurs (CapEx) | OpEx (à l’usage) | OpEx (forfait) |
| Élasticité | Limitée par votre matériel | Élevée | Moyenne (par licence) |
| Complexité d’exploitation | Maitrise locale | Maitrise Azure requise | Faible |
Prévenir la prochaine échéance : supervision & alertes
Plutôt que d’attendre 120 jours, mettez en place une surveillance légère :
Contrôler la configuration de licence (script)
# Vérifie mode & serveurs de licences définis, services, et connectivité RPC
$regBase = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
$mode = (Get-ItemProperty -Path $regBase -Name LicensingMode -ErrorAction SilentlyContinue).LicensingMode
$lsKey = Join-Path $regBase "LicenseServers"
$servers = @()
if (Test-Path $lsKey) {
Get-ChildItem $lsKey | ForEach-Object { $servers += $_.PSChildName }
}
$svc1 = Get-Service -Name TermService
$svc2 = Get-Service -Name TermServLicensing -ErrorAction SilentlyContinue
$results = [PSCustomObject]@{
LicensingMode = if($mode -eq 2){"PerDevice"} elseif ($mode -eq 4){"PerUser"} else {"Non défini"}
LicenseServers = if($servers){$servers -join ", "} else {"Aucun"}
TermService = $svc1.Status
LicensingSvc = if($svc2){$svc2.Status}else{"Non installé"}
}
$results
foreach($s in $servers){
Test-NetConnection -ComputerName $s -Port 135 -InformationLevel Quiet | `
ForEach-Object { Write-Host "RPC vers $s : " + ($(if($_){"OK"}else{"KO"})) }
}Créer une alerte planifiée
- Enregistrez le script ci‑dessus (par ex.
C:\Ops\Test-RdsLicensing.ps1). - Planifiez‑le hebdomadairement via le Planificateur de tâches, en sortie vers un fichier :
powershell.exe -ExecutionPolicy Bypass -File "C:\Ops\Test-RdsLicensing.ps1" | Tee-Object -FilePath "C:\Ops\logs\rds-check.log" -Append - Ajoutez un seuil : si LicensingMode est « Non défini » ou si tous les tests RPC sont « KO », envoyez un mail/Teams ou écrivez un événement personnalisé.
Ports et pare‑feu à ne pas oublier
| Usage | Port(s) | Direction | Notes |
|---|---|---|---|
| Connexion RDP | TCP 3389 | Client → RD Session Host | Peut être personnalisé. |
| RD Session Host → Serveur de licences | TCP 135 + ports éphémères | RDSH → RDLS | RPC dynamique (plage Windows éphémère, par défaut 49152‑65535). |
| Activation du serveur de licences | HTTPS 443 (sortant) | RDLS → Internet | Nécessaire lors de l’activation/ajout de packs de licences. |
Ce qu’il ne faut pas faire
Important – conformité : vous trouverez sur Internet des « astuces » consistant à manipuler la base de registre pour réinitialiser la période de grâce de 120 jours. Cette pratique viole les conditions d’utilisation et peut exposer votre organisation à des risques contractuels et juridiques. Je ne fournis pas d’instructions pour contourner les mécanismes de licence. Utilisez les méthodes conformes décrites ci‑dessus ou, à défaut, désinstallez le rôle RD Session Host pour retrouver les deux sessions d’administration.
FAQ express
Combien de sessions d’administration sont autorisées sans CAL ? Deux connexions simultanées « d’administration ». Elles ne remplacent pas des sessions utilisateurs RDS normales.
Per User vs Per Device : quel suivi ? En « Par périphérique », l’attribution est suivie techniquement par le serveur de licences. En « Par utilisateur », c’est généralement un suivi administratif (conformité déclarative).
Puis‑je installer le serveur de licences sur le même hôte que le RDSH ? Oui pour les petites structures. En production, privilégiez deux serveurs de licences distincts pour la tolérance de panne.
Dois‑je redémarrer le serveur après la configuration de la licence ? Pas forcément. Un gpupdate et le redémarrage du service TermService suffisent dans la plupart des cas.
Checklist « mise en conformité en 60 min »
- Accéder via
mstsc /adminet libérer une session si besoin (quser/logoff). - Installer la fonctionnalité RDS-Licensing sur 1‑2 serveurs et les activer.
- Importer les packs de CAL achetés.
- Configurer sur le RDSH le mode de licence et la liste des serveurs (GPO/PowerShell).
- Redémarrer le service
TermServiceet tester une session utilisateur. - Documenter (inventaire CAL, captures d’écran, procédure) et planifier la supervision.
Budget & plan B réaliste
- Si l’achat de CAL est acté : priorisez le déploiement des serveurs de licences, installez les CAL immédiatement, finalisez les bons de commande plus tard si nécessaire (selon votre processus interne).
- Si le budget est bloqué : chiffrez une bascule temporaire vers AVD/Windows 365 pour les profils critiques, ou désinstallez RD Session Host et organisez l’exploitation via les deux sessions d’admin le temps de la décision.
Bonnes pratiques pour l’avenir
- Standardisez la version des CAL au niveau de la plus haute version de vos serveurs.
- Déployez deux serveurs de licences et référencez‑les via GPO sur tous vos RDSH.
- Automatisez un contrôle hebdomadaire (script ci‑dessus) et un rapport mensuel de conformité.
- Budgétisez les renouvellements CAL dans votre cycle financier annuel.
Conclusion
La fin de la période de grâce RDS n’est pas une fatalité. En gardant un accès d’urgence via /admin, en configurant correctement votre serveur de licences et en choisissant le bon type de CAL, vous rétablissez les connexions en quelques étapes, en toute conformité. Et si le contexte l’exige, les options cloud offrent un filet de sécurité efficace, sans compromis légal.