Tout savoir sur la période de grâce RDS sous Windows Server 2019 : durée exacte, fonctionnement des CAL et impact sur le nombre de connexions simultanées. Guide pratique, étapes de mise en conformité, commandes utiles et conseils de dimensionnement inclus.
Période d’essai RDS (Windows Server 2019) & nombre d’utilisateurs simultanés
Vue d’ensemble de la question
Quelle est la durée de la période d’essai — dite « période de grâce » — des Services Bureau à distance (RDS) sur Windows Server 2019 ? Et combien d’utilisateurs peuvent se connecter simultanément au serveur pendant et après cette période ?
Réponse & Solution
Période d’essai (grâce)
- 120 jours à compter de l’activation des rôles RDS, en particulier RD Session Host.
- Pendant ces 120 jours, les connexions RDS sont autorisées sans CAL RDS (licences d’accès client RDS).
Après la période de grâce
- Vous devez acheter et installer des CAL RDS pour continuer à utiliser RDS.
- Deux modes de licence :
- Par utilisateur (Per User) : suivi « à l’honneur » par l’organisation ; le serveur n’impose pas techniquement la limite.
- Par appareil (Per Device) : attribution et suivi de jetons par le serveur de licences RDS ; contrôle technique appliqué.
Nombre d’utilisateurs simultanés
- Pendant la période de grâce : aucun plafond logiciel imposé par RDS ; la limite réelle dépend des ressources et du paramétrage (CPU, RAM, disque/IOPS, applications, stratégies, etc.).
- Après la période de grâce :
- Mode Par utilisateur : la conformité doit refléter le nombre d’utilisateurs se connectant (gouvernance interne).
- Mode Par appareil : le volume de connexions est borné, en pratique, par le nombre de CAL RDS « Device » disponibles et allouées.
- Important : sans rôle RD Session Host (simple « Administration à distance »), Windows Server autorise jusqu’à deux connexions RDP simultanées pour l’administration, sans CAL RDS — ce n’est pas destiné aux usages utilisateurs.
Mise en conformité — procédure rapide
- Installer les rôles RD Session Host et RD Licensing (sur le même hôte pour un petit déploiement si souhaité).
- Activer le serveur de licences via Gestionnaire de licences Bureau à distance (
rdlicmgr.exe
). - Définir le mode de licence et le(s) serveur(s) de licences via stratégie de groupe :
Configuration ordinateur > Modèles d'administration > Composants Windows > Services Bureau à distance > Hôte de session > Gestion des licences
Activez : Définir le mode de licences Bureau à distance et Utiliser les serveurs de licences Bureau à distance spécifiés. - Installer les CAL RDS achetées (User ou Device) dans le Gestionnaire de licences.
- Vérifier l’état via le Diagnostiqueur de licences Bureau à distance (dans le Gestionnaire de serveur) et tester une session utilisateur.
Conseils pratiques & compléments utiles
- Dimensionnement : pour une charge bureautique + navigateur, prévoyez souvent 0,5 à 1,5 Go de RAM par session (hors système) ; le CPU et le stockage (IOPS/latence) sont déterminants. Testez avec un échantillon représentatif.
- Surveillance rapide :
quser
/query user
,qwinsta
/query session
. Pour des fermes avec courtier,Get-RDUserSession
en PowerShell. - Conformité : n’essayez pas de « réinitialiser » la grâce via le Registre ; c’est non conforme au contrat de licence Microsoft.
- Rappels : les CAL Windows Server (accès au serveur) et les CAL RDS (accès aux sessions) sont distinctes. Selon vos usages, vous pouvez avoir besoin des deux.
Comprendre les CAL RDS, le comptage et l’impact sur les connexions
Les CAL RDS existent en deux saveurs. Le choix influe sur la manière dont vous gouvernez les accès et, indirectement, sur le nombre de connexions que vous pouvez accepter en toute conformité.
Type de CAL | Mécanisme | Contrôle technique | Cas d’usage typique | Avantages | Points d’attention |
---|---|---|---|---|---|
Par utilisateur (Per User) | Licence rattachée à un utilisateur (AD/AAD/hybride) | Non imposé par le serveur (suivi organisationnel) | Collaborateurs multi‑terminaux, effectifs « nomades » | Souplesse, pas de gestion de jetons par appareil | Nécessite une gouvernance claire (groupes AD, audits) |
Par appareil (Per Device) | Jeton délivré à un poste au premier accès | Contrôle par le serveur de licences | Postes dédiés, environnements kiosques, entrepôts | Prévisibilité du parc, blocage si quota atteint | Gestion des jetons (révocations limitées), prévoir marge |
Compatibilité de version : une CAL RDS doit être de version égale ou supérieure à la version du rôle RD Session Host ciblé. La rétrocompatibilité vers des hôtes plus anciens est fréquente, l’inverse ne l’est pas.
Limites réelles et paramètres qui pilotent la simultanéité
- Ressources : le facteur le plus structurant. Un goulot d’étranglement CPU/IOPS rend une session inutilisable avant d’atteindre une « limite » logicielle.
- Politiques de session : durée d’inactivité, déconnexion/fin de session, single session per user (Limiter chaque utilisateur à une seule session). Ce dernier paramètre affecte directement la simultanéité si vous autorisez plusieurs sessions par utilisateur.
- Applications : suites lourdes (CAO, ETL, navigateurs multiprocessus) consomment largement plus qu’un socle bureautique.
- Profil utilisateur : profils itinérants/FSLogix, redirection de dossiers, taille des profils ; impact sur RAM, réseaux et stockage.
Profil d’usage | RAM par session (hors OS) | CPU par session | Stockage | Notes |
---|---|---|---|---|
Bureautique légère + intranet | 0,5 à 0,8 Go | 3–5 % d’un vCPU | IOPS faibles, latence < 5 ms | Précharger polices, désactiver extensions inutiles |
Bureautique standard + navigateur lourd | 0,8 à 1,5 Go | 5–8 % d’un vCPU | IOPS modérés, mise en cache navigateur | FSLogix recommandé pour profils Office |
Apps gourmandes (analyse, CAO légère) | 1,5 à 3 Go | 8–15 % d’un vCPU | IOPS élevés, disque rapide | Évaluer GPU/vGPU si rendu 3D |
Architecture type selon la taille
- Petit site : un hôte avec RD Session Host et RD Licensing. Optionnel : RD Gateway pour l’accès externe.
- Moyen : deux hôtes RD Session Host (équilibrage DNS ou via Connection Broker), RD Licensing dédié, RD Gateway & RD Web Access.
- Grand : ferme avec RD Connection Broker hautement disponible, plusieurs RD Session Host, RD Gateway en pair, serveurs de licences multiples (CAL réparties) et supervision centralisée.
Dépannage des erreurs de licence et de connexion
Après les 120 jours, un hôte qui n’a ni mode de licence défini ni serveur de licences déclaré peut refuser des connexions avec un message du type : « Une erreur de licence s’est produite qui empêche la connexion ». Procédez ainsi :
- Vérifiez la stratégie de licence : mode (User ou Device) et nom du serveur de licences correctement renseigné.
- Confirmez que le serveur de licences est activé et que les CAL y sont installées.
- Actualisez la stratégie (
gpupdate /force
), puis redémarrez si besoin le service Services Bureau à distance (TermService
) hors heures d’ouverture. - Contrôlez les journaux d’événements : Applications and Services Logs > Microsoft > Windows > TerminalServices-* pour des alertes de licence et de sessions.
- Testez avec un compte propre au groupe autorisé (Remote Desktop Users) et un client RDP à jour.
Scripts et commandes utiles
Installer les rôles clés (exécuter en PowerShell en tant qu’administrateur) :
# Installation RD Session Host + RD Licensing (inclut les outils d'admin)
Install-WindowsFeature -Name RDS-RD-Server, RDS-Licensing -IncludeManagementTools
# Vérifier l'état des rôles installés
Get-WindowsFeature RDS\* | Where-Object {$\_.InstallState -eq 'Installed'}
Déclarer le mode de licence et le serveur :
# Si vous administrez via le gestionnaire RDS (déploiements gérés)
Set-RDLicenseConfiguration -Mode PerUser -LicenseServer "SRV-LIC-01"
# Alternative par GPO (recommandée) : définir les paramètres puis forcer l'application
gpupdate /force
Lister les sessions actives :
# Console classique
quser
qwinsta
# PowerShell (avec Connection Broker)
Get-RDUserSession
Contrôle des groupes :
# Vérifier qui est autorisé à ouvrir une session distante
Get-LocalGroupMember -Group "Remote Desktop Users" | Select-Object Name, ObjectClass
Checklist de mise en production
- Mode de licence défini et testé (User ou Device), serveur(s) de licences renseigné(s).
- CAL installées et visibles dans le Gestionnaire de licences.
- Stratégies de session (inactivité, déconnexion, limite de session) alignées sur la charte d’usage.
- Groupes AD d’accès (RDS_Users) créés, approbations et processus d’onboarding définis.
- Journalisation et supervision opérationnelles (collecte des événements, métriques CPU/RAM/IO).
- Plan de capacité et de croissance, y compris tests de charge ciblés.
- Accès externe sécurisé via RD Gateway et authentification multifacteur si exposition Internet.
Questions fréquentes
Combien d’utilisateurs peuvent se connecter simultanément pendant la période de grâce ?
Il n’y a pas de plafond logiciel imposé par RDS. La simultanéité est bornée par les ressources (CPU/RAM/IO), les réglages de session et l’empreinte des applications. Testez avec un groupe pilote pour trouver votre point de saturation acceptable.
Que se passe‑t‑il à l’expiration des 120 jours ?
Sans CAL, les nouvelles connexions peuvent être refusées avec une erreur de licence. Installez et activez vos CAL, puis déclarez le mode et le serveur de licences.
Peut‑on mélanger des CAL Per User et Per Device ?
Oui, mais pour un même hôte RD Session Host, vous devez choisir un seul mode effectif. Vous pouvez néanmoins répartir des hôtes différents selon les modes, selon vos cas d’usage.
Une CAL Per User limite‑t‑elle le nombre de sessions d’un même utilisateur ?
Non. La limite par utilisateur est gouvernée par la stratégie Limiter chaque utilisateur à une seule session (paramètre RDS), indépendante de la licence Per User.
Comment gérer les remplacements d’appareils en Per Device ?
Les jetons peuvent être révoqués avec parcimonie (fenêtre de révocation) via le Gestionnaire de licences. Planifiez une marge de CAL pour absorber les renouvellements.
Mauvaises pratiques à éviter
- Utiliser le mode « Administration à distance » pour des usages utilisateurs (limité à deux connexions, non conforme).
- Tenter de réinitialiser la période de grâce via le Registre ; c’est contraire aux conditions de licence.
- Laisser le mode de licences en « Non défini » après déploiement ; cela mène à des refus de connexion le jour J.
- Négliger la surveillance de la capacité ; les performances se dégradent avant que « plus personne ne puisse entrer ».
Paramètres de stratégie recommandés
Chemin | Paramètre | Recommandation | Impact |
---|---|---|---|
Configuration ordinateur > … > Hôte de session > Gestion des licences | Définir le mode de licences Bureau à distance | Activé ; Par utilisateur ou Par appareil | Conformité et levée des erreurs de licence |
Configuration ordinateur > … > Hôte de session > Gestion des licences | Utiliser les serveurs de licences Bureau à distance spécifiés | Activé ; liste de vos serveurs (FQDN) | Découverte fiable du serveur de licences |
Configuration ordinateur > … > Hôte de session > Connexions | Limiter chaque utilisateur à une seule session | Selon besoin ; Activé pour éviter les sessions multiples | Impact direct sur la simultanéité par utilisateur |
Configuration ordinateur > … > Hôte de session > Limites de temps de session | Déconnecter une session après inactivité | Définir des seuils raisonnables (ex. 30–60 min) | Récupération de ressources, meilleure densité |
Ports et communication
Composant | Port/protocole | Objet | Remarques |
---|---|---|---|
RDP | TCP 3389 | Transport des sessions | Exposer via RD Gateway plutôt que 3389 sur Internet |
Serveur de licences | TCP 135 + ports RPC dynamiques | Attribution (Device) et validation | Plage dynamique Windows par défaut |
RD Gateway | TCP 443 | Accès externe TLS | Prérequis certificat serveur |
RD Web Access | TCP 443 | Portail applicatif | Intégration SSO possible |
Bonnes pratiques de gouvernance des licences
- Registre des droits : tenez un inventaire des CAL achetées et de leur affectation (par utilisateur ou par appareil), avec justificatifs d’achat.
- Groupes AD : contrôlez l’accès RDS via des groupes (ex. GG_RDS_Users) et auditez régulièrement membres et usages.
- Processus RH/IT : rattachez l’attribution/retrait de CAL aux processus d’arrivée/mutation/départ.
- Revue périodique : trimestrielle ou semestrielle, pour ajuster le parc de CAL et anticiper la croissance.
Exemples concrets
- Atelier avec dix PC partagés : mode Per Device recommandé, dix CAL Device + marge de deux pour le SAV. Stratégies d’inactivité courtes pour libérer les sessions.
- Siège avec collaborateurs multi‑écrans : mode Per User ; gouvernance via groupes AD. Autoriser une session par utilisateur pour préserver la densité.
- Accès externe : ajoutez RD Gateway + MFA. Le choix User vs Device ne change pas l’architecture mais influe sur la gestion des accès.
Résumé actionnable
- La période de grâce RDS sous Windows Server 2019 dure 120 jours à compter de l’activation de RD Session Host.
- Le nombre de connexions simultanées n’est pas plafonné par RDS ; il est borné par vos ressources et vos stratégies.
- Après la grâce, installez des CAL RDS et définissez le mode de licence (User ou Device) ainsi que le serveur de licences.
- Ne confondez pas administration distante (deux connexions RDP) et un environnement RDS pour utilisateurs.
Annexe : pas à pas détaillé
- Installer les rôles : dans Gestionnaire de serveur > Ajouter des rôles et fonctionnalités > Services Bureau à distance > sélectionnez Hôte de session et Licences (et, selon besoin, Broker, Gateway, Web Access).
- Activer le serveur de licences : via
rdlicmgr.exe
> clic droit sur le serveur > Activer > suivez l’assistant (internet, web ou téléphone). - Installer les CAL : toujours dans
rdlicmgr.exe
, Installer des licences > saisissez programme/numéro/quantité. - Configurer l’hôte RD Session Host : par GPO (recommandé) ou, à défaut, par stratégie locale, renseignez le mode et le serveur de licences.
- Appliquer et tester :
gpupdate /force
> ouvrez une session avec un utilisateur standard > vérifiez l’absence d’alerte de licence. - Durcir et optimiser : ajustez les limites de session, l’impression redirigée, la redirection de presse‑papiers/USB selon la politique de sécurité.
Annexe : notes sur la haute disponibilité des licences
- Vous pouvez déclarer plusieurs serveurs de licences sur vos hôtes RD Session Host pour réduire le risque de panne.
- Répartissez vos CAL Device entre les serveurs ; les jetons ne sont pas partagés automatiquement.
- Pour CAL User, privilégiez la gouvernance et l’audit régulier plutôt que la redondance technique.
Conclusion
Sur Windows Server 2019, la période de grâce RDS de 120 jours vous laisse le temps de valider votre dimensionnement et votre mode de licence. Pour la production, fixez clairement le mode User ou Device, installez vos CAL, déclarez le serveur de licences et cadrez les politiques de session. La « limite » de connexions simultanées est avant tout la capacité réelle de votre serveur et la qualité de vos réglages.