Période d’essai RDS Windows Server 2019 : 120 jours, CAL et connexions simultanées

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.

Sommaire

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

  1. Installer les rôles RD Session Host et RD Licensing (sur le même hôte pour un petit déploiement si souhaité).
  2. Activer le serveur de licences via Gestionnaire de licences Bureau à distance (rdlicmgr.exe).
  3. 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.
  4. Installer les CAL RDS achetées (User ou Device) dans le Gestionnaire de licences.
  5. 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 CALMécanismeContrôle techniqueCas d’usage typiqueAvantagesPoints 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 appareilNécessite une gouvernance claire (groupes AD, audits)
Par appareil (Per Device)Jeton délivré à un poste au premier accèsContrôle par le serveur de licencesPostes dédiés, environnements kiosques, entrepôtsPrévisibilité du parc, blocage si quota atteintGestion 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’usageRAM par session (hors OS)CPU par sessionStockageNotes
Bureautique légère + intranet0,5 à 0,8 Go3–5 % d’un vCPUIOPS faibles, latence < 5 msPrécharger polices, désactiver extensions inutiles
Bureautique standard + navigateur lourd0,8 à 1,5 Go5–8 % d’un vCPUIOPS modérés, mise en cache navigateurFSLogix recommandé pour profils Office
Apps gourmandes (analyse, CAO légère)1,5 à 3 Go8–15 % d’un vCPUIOPS é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 :

  1. Vérifiez la stratégie de licence : mode (User ou Device) et nom du serveur de licences correctement renseigné.
  2. Confirmez que le serveur de licences est activé et que les CAL y sont installées.
  3. Actualisez la stratégie (gpupdate /force), puis redémarrez si besoin le service Services Bureau à distance (TermService) hors heures d’ouverture.
  4. Contrôlez les journaux d’événements : Applications and Services Logs > Microsoft > Windows > TerminalServices-* pour des alertes de licence et de sessions.
  5. 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 &quot;Remote Desktop Users&quot; | 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

CheminParamètreRecommandationImpact
Configuration ordinateur > … > Hôte de session > Gestion des licencesDéfinir le mode de licences Bureau à distanceActivé ; Par utilisateur ou Par appareilConformité et levée des erreurs de licence
Configuration ordinateur > … > Hôte de session > Gestion des licencesUtiliser les serveurs de licences Bureau à distance spécifiésActivé ; liste de vos serveurs (FQDN)Découverte fiable du serveur de licences
Configuration ordinateur > … > Hôte de session > ConnexionsLimiter chaque utilisateur à une seule sessionSelon besoin ; Activé pour éviter les sessions multiplesImpact direct sur la simultanéité par utilisateur
Configuration ordinateur > … > Hôte de session > Limites de temps de sessionDé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

ComposantPort/protocoleObjetRemarques
RDPTCP 3389Transport des sessionsExposer via RD Gateway plutôt que 3389 sur Internet
Serveur de licencesTCP 135 + ports RPC dynamiquesAttribution (Device) et validationPlage dynamique Windows par défaut
RD GatewayTCP 443Accès externe TLSPrérequis certificat serveur
RD Web AccessTCP 443Portail applicatifInté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é

  1. 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).
  2. Activer le serveur de licences : via rdlicmgr.exe > clic droit sur le serveur > Activer > suivez l’assistant (internet, web ou téléphone).
  3. Installer les CAL : toujours dans rdlicmgr.exe, Installer des licences > saisissez programme/numéro/quantité.
  4. 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.
  5. Appliquer et tester : gpupdate /force > ouvrez une session avec un utilisateur standard > vérifiez l’absence d’alerte de licence.
  6. 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.

Sommaire