Douze collaborateurs, un serveur Windows et une même question : faut‑il des CAL RDS par utilisateur ou par périphérique ? Voici un guide opérationnel et sans jargon pour choisir, déployer et rester conforme, avec des exemples concrets et des check‑lists prêtes à l’emploi.
Vue d’ensemble de la question
Une équipe d’une douzaine de personnes se connecte, via leurs comptes locaux, à un unique serveur Windows pour exécuter des tâches à distance. Chaque collaborateur dispose de son propre ordinateur portable. On cherche à savoir :
- Faut‑il acheter des CAL Remote Desktop par utilisateur ou par périphérique ?
- Existe‑t‑il d’autres formules mieux adaptées (édition spéciale de Windows Server, etc.) pour qu’un petit groupe puisse travailler simultanément sans restriction ?
Rappels rapides : de quelles licences parle‑t‑on ?
- CAL Windows Server : licence d’accès « de base » à Windows Server (nécessaire pour toute connexion réseau authentifiée). Elle est distincte des CAL RDS.
- CAL RDS (Remote Desktop Services) : licence supplémentaire requise pour les sessions RDS (bureau complet ou RemoteApp).
- Modes RDS :
- Per‑Device : la licence s’attache au poste client qui se connecte.
- Per‑User : la licence s’attache à l’utilisateur (souvent suivi via Active Directory).
- Rôles RDS principaux : RD Session Host (RDSH), RD Licensing, RD Broker, RD Web, RD Gateway.
Per‑Device vs Per‑User : comparaison claire
| Point clé | Per‑Device CAL | Per‑User CAL |
|---|---|---|
| Principe d’attribution | Licence inscrite dans la clé de registre du poste client :HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing. | Licence suivie côté serveur et associée à l’utilisateur (attributs du compte dans Active Directory). |
| Scénario recommandé | Parc de PC partagés (postes fixes, quarts de travail) et/ou environnement en groupe de travail (sans AD). | Chaque collaborateur utilise plusieurs appareils (portable, domicile, tablette). Nécessite généralement un AD pour le suivi. |
| Nombre de postes vs. utilisateurs | Peu d’appareils mais beaucoup d’utilisateurs ? ➜ Per‑Device. | Beaucoup d’appareils par utilisateur ? ➜ Per‑User. |
| Enforcement technique | Contrôle effectif : des jetons sont délivrés au périphérique ; dépassement bloquant après la période de grâce. | Contrôle plus souple : suivi côté serveur/AD, mais non bloquant par défaut ; conformité contractuelle à respecter. |
| Mobilité & BYOD | Moins flexible si un même utilisateur change souvent d’appareil. | Très adapté : la licence « suit » la personne. |
| Administration | Gérable sans AD. Réaffectation possible (ex. remplacement d’un PC), dans des limites prévues par Microsoft. | Suivi optimal avec AD (comptes identifiés). Sans AD, difficile à piloter proprement. |
| Cas « 12 personnes / 12 portables » | Simple et économique si pas d’AD et un seul appareil par personne. | Pertinent si les mêmes 12 personnes utilisent plusieurs appareils. |
Sans Active Directory : si le serveur est hors domaine et que les comptes sont locaux, la gestion automatisée des licences par utilisateur n’est pas prévue ; on privilégie alors Per‑Device pour rester conforme.
Important : Les règles de licence évoluent. Validez toujours votre cas (Software Assurance, souscriptions, hébergement, etc.) auprès d’un revendeur ou d’un spécialiste Microsoft.
Option alternative pour très petites structures
Microsoft mentionne Windows Server Essentials (jusqu’à 25 utilisateurs / 50 périphériques) comme solution « clé en main ». Toutefois :
- Cette édition ne prend pas en charge le rôle RD Session Host multi‑utilisateur ; elle n’offre que l’administration à distance (2 sessions).
- Si votre objectif est la bureautique ou des applications publiées pour 12 utilisateurs simultanés, il faut un Windows Server Standard + CAL RDS.
Recommandation pratique
- Lister les usages réels : nombre d’utilisateurs × appareils par utilisateur, présence ou non d’AD, mobilité (télétravail, BYOD) et besoins futurs.
- Choisir la métrique dominante :
- Per‑Device si chaque collaborateur se connecte toujours depuis son PC portable unique et que le serveur n’est pas joint à un domaine.
- Per‑User si vous prévoyez plusieurs appareils (PC pro + domicile, tablette) et que vous disposez d’Active Directory.
- Ne pas oublier les CAL Windows Server de base, en plus des CAL RDS.
- Pour simplifier la gestion et réduire les coûts à long terme, envisagez une standardisation sur Per‑User CAL couplée à Azure AD / AD local : les licences suivent alors la personne.
Exemples concrets
| Exemple | Contexte | Choix recommandé | Remarques |
|---|---|---|---|
| A | 12 utilisateurs, 12 portables dédiés, pas d’AD, comptes locaux. | Per‑Device | Simple, conforme, peu d’administration. |
| B | 12 utilisateurs, chacun a 1 portable + 1 PC à domicile + 1 tablette, AD présent. | Per‑User | La licence suit la personne, idéal pour BYOD/télétravail. |
| C | 8 intérimaires se relaient sur 3 postes partagés + 4 salariés équipés chacun d’un portable. AD absent. | Per‑Device | Sur postes partagés, Per‑Device est imbattable. Les 4 portables « dédiés » entrent aussi dans ce modèle. |
| D | Besoin de séparer « salariés » (multi‑appareils) et « kiosques » (postes partagés). | Deux hôtes RDSH : l’un en Per‑User, l’autre en Per‑Device. | Un même serveur de licences peut délivrer les deux types de CAL. Le mode se règle par hôte/collection. |
Checklist de conformité (petit groupe)
- CAL Windows Server achetées pour chaque utilisateur ou périphérique accédant au serveur.
- CAL RDS en nombre suffisant : Per‑Device ou Per‑User selon votre choix.
- Rôle RD Licensing activé et serveur de licences spécifié sur les hôtes RDSH.
- Mode de licences RDS configuré (Per‑Device ou Per‑User) sur chaque RDSH.
- Gestion des comptes : AD conseillé pour Per‑User (suivi/audit), comptes locaux OK pour Per‑Device.
- Office en RDS : utilisez des éditions compatibles (Microsoft 365 Apps avec Activation en Ordinateur Partagé). Les éditions « boîte » grand public ne conviennent pas.
- Accès externes : prévoyez RD Gateway + MFA/NPS. Évitez l’ouverture directe du port RDP sur Internet.
Déploiement pas à pas (petite infra sur un seul serveur)
- Installer les rôles : RD Session Host et RD Licensing (sur le même serveur pour une petite équipe).
- Activer le serveur de licences (via le gestionnaire de licences RDS).
- Installer le pack de CAL RDS (Per‑Device ou Per‑User).
- Spécifier le serveur de licences aux RDSH et définir le mode :
- GPO : Configuration ordinateur > Modèles d’administration > Services Bureau à distance > Hôte de session > Licences.
- PowerShell (exemples) :
# Définir le serveur de licences Set-RDLicenseConfiguration -LicenseServer @("SRV-RDS-LIC") -Mode PerDevice # Basculer en Per-User si besoin Set-RDLicenseConfiguration -LicenseServer @("SRV-RDS-LIC") -Mode PerUser # (Alternative registre, valeur 2 = Per-Device, 4 = Per-User) Set-ItemProperty ` -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core'` -Name 'LicensingMode' -Value 2 - Tester : connexion de 1‑2 postes, vérification du suivi (RD Licensing Manager, Observateur d’événements).
Période de grâce : après l’installation d’un RDSH, vous disposez d’une période limitée (typiquement ~120 jours) pendant laquelle les connexions fonctionnent sans serveur de licences. Ne considérez pas cela comme un mode permanent : activez et configurez le serveur de licences.
Comprendre le cycle de vie des CAL RDS
- Per‑Device : le premier accès délivre un jeton temporaire au poste, puis un jeton « permanent ». Les jetons expirent et se renouvellent automatiquement si le poste se reconnecte. En cas de remplacement d’un PC, vous pouvez révoquer certains jetons via la console (dans des limites fixées par Microsoft).
- Per‑User : le serveur enregistre les utilisateurs consommant des licences. La conformité repose sur l’inventaire et la politique d’achat ; l’AD facilite l’audit et les rapports.
Résolution de problèmes fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| « La session s’est déconnectée : aucune licence d’accès… » après quelques semaines. | Période de grâce expirée, serveur de licences non configuré ou non atteint. | Activer RD Licensing, installer les CAL, définir le serveur de licences + le mode sur le RDSH, vérifier DNS/pare‑feu. |
| Un poste ne parvient plus à obtenir un jeton Per‑Device. | Clé MSLicensing corrompue côté client. | Lancer le client RDP en administrateur, sauvegarder puis recréer HKLM\Software\Microsoft\MSLicensing (avec prudence), reconnecter pour réémettre un jeton. |
| Licence Per‑User choisie mais comptes locaux. | Pas d’AD : suivi Per‑User incomplet. | Basculer en Per‑Device ou intégrer le serveur à un domaine (AD/Azure AD DS). |
| Office ne démarre pas en session RDS. | Édition non compatible (pas d’Activation en Ordinateur Partagé). | Utiliser Microsoft 365 Apps (ex‑ProPlus) avec SCA, ou édition volume compatible RDS. |
Modèle de calcul budgétaire (pédagogique)
Adaptez ces formules à vos prix réels :
- Coût total Per‑Device ≈ (Nb de périphériques uniques qui se connectent) × (prix unitaire CAL RDS Per‑Device) + CAL Windows Server correspondantes.
- Coût total Per‑User ≈ (Nb d’utilisateurs uniques habilités) × (prix unitaire CAL RDS Per‑User) + CAL Windows Server correspondantes.
Règle d’or : comptez « à la source » : qui est autorisé à se connecter (Per‑User) ou quels appareils se connectent (Per‑Device). Ne mélangez pas les deux sur un même hôte RDSH.
Architecture type et bonnes pratiques pour 12 utilisateurs
- 1 × RDSH + RD Licensing sur le même serveur (VM recommandée) ; 8 vCPU et 24–32 Go de RAM suffisent souvent pour bureautique légère (à valider par test).
- Profils : FSLogix ou répertoires itinérants pour éviter l’enflure du profil local.
- Impression : pilote universel ou redirection d’imprimantes pour limiter les incidents.
- Sécurité : RD Gateway + MFA (NPS/Authenticator), blocage RDP Internet direct, mises à jour régulières.
- Surveillance : PerfMon (CPU Ready, mémoire engagée), Observateur d’événements, canal RemoteDesktopServices‑RdpCoreTS.
Arbre de décision express
- Votre serveur est‑il joint à un domaine AD ?
Non ➜ privilégier Per‑Device.
Oui ➜ passez à la question suivante. - Un même utilisateur utilise‑t‑il plusieurs appareils (PC pro + domicile + tablette) ?
Oui ➜ Per‑User.
Non ➜ Per‑Device. - Avez‑vous des postes partagés en équipes/rotations ?
Oui ➜ Per‑Device (souvent moins cher).
Non ➜ Per‑User reste pertinent si multi‑appareils.
FAQ ciblée
Puis‑je mélanger Per‑User et Per‑Device ?
Pas sur un même hôte RDSH. En revanche, un même serveur de licences peut délivrer les deux types de CAL à des hôtes ou collections différents.
Combien de licences dois‑je acheter ?
Autant que d’utilisateurs (Per‑User) autorisés ou d’appareils (Per‑Device) se connectant. Ajoutez les CAL Windows Server correspondantes. Anticipez les pics (saisonniers, intérimaires).
Et si un PC est remplacé ?
En Per‑Device, vous pouvez révoquer un jeton et en réémettre un pour le nouveau poste (il existe des limites périodiques). En Per‑User, la licence reste liée à la personne.
Essentials suffit‑il pour 12 sessions simultanées ?
Non. Essentials n’autorise pas un hôte de session multi‑utilisateur ; vous restez limité à l’admin à distance.
Que se passe‑t‑il au bout de la période de grâce ?
Les nouvelles connexions échouent. Activez le serveur de licences, installez les CAL et configurez le mode (Per‑Device/Per‑User) pour rétablir l’accès.
Procédure de vérification post‑déploiement
- Dans Gestionnaire de licences Bureau à distance, confirmer : serveur activé, packs de CAL installés, compte d’usage non dépassé.
- Sur le(s) RDSH : GPO appliquée (gpresult /h ou rsop.msc) ; clé
LicensingModecorrecte ; serveurs de licences renseignés. - Journal d’événements : absence d’erreurs TermService liées aux licences.
- Échantillon de connexions réelles (2‑3 postes) et contrôle des jetons (Per‑Device) ou des utilisateurs suivis (Per‑User) pour valider le flux.
Quand RDS n’est pas optimal
- PC Cloud dédiés (ex. solutions Cloud PC) : facturation à l’utilisateur, gestion simplifiée, mais coût récurrent.
- Azure Virtual Desktop : Windows multi‑session, montée/descente en charge à la demande, mais complexité cloud.
- SaaS natif : quand l’app métier existe en mode web, évitez RDS si possible.
Conclusion
Pour un petit groupe sans domaine AD où chacun se connecte depuis son unique portable, le mode Per‑Device est généralement le plus simple et le plus économique. Dès qu’un même collaborateur utilise plusieurs appareils, ou que vous standardisez votre identité avec un AD (local ou Azure), le mode Per‑User devient plus pertinent. Dans tous les cas : n’oubliez pas les CAL Windows Server, activez correctement le serveur de licences RDS, testez vos connexions … et faites valider votre situation par un revendeur.
Annexe : mémo technique
- Clés utiles :
- Client :
HKLM\Software\Microsoft\MSLicensing(jetons Per‑Device). - Serveur :
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core\LicensingMode(2 = Per‑Device, 4 = Per‑User).
- Client :
- GPO : « Définir le mode des licences Bureau à distance » et « Utiliser les serveurs de licences Bureau à distance spécifiés ».
- Cmdlets :
Set-RDLicenseConfiguration,Get-RDLicenseConfiguration. - Messages d’erreur : surveiller TermService et RemoteDesktopServices‑RdpCoreTS dans l’Observateur d’événements.
Résumé exécutable pour votre cas
- Contexte : 12 collaborateurs, chacun avec un portable, comptes locaux, un seul serveur.
- Choix : CAL RDS Per‑Device + CAL Windows Server correspondantes.
- Étapes : installer RD Licensing & RDSH → activer le serveur de licences → importer les CAL Per‑Device → configurer GPO/PowerShell (serveur & mode) → tester.
- Évolutivité : si vous introduisez AD ou du multi‑appareils, envisagez de basculer en Per‑User (ou d’ajouter un second RDSH dédié Per‑User).
En synthèse : sans domaine et avec un PC par employé, le mode Per‑Device est le plus simple et le moins coûteux ; dès qu’un utilisateur doit se connecter depuis plusieurs appareils ou que l’entreprise bascule vers Active Directory, Per‑User devient plus pertinent.