Vous hébergez un serveur de jeux sur Windows Server 2019 Datacenter ? Voici un guide clair et actionnable pour savoir précisément quelles licences sont requises (ou non) et comment rester conforme sans dépenses inutiles.
Vue d’ensemble : ce qui change pour un serveur de jeux
Dans le scénario étudié, la machine Windows Server 2019 Datacenter n’héberge que des parties multijoueurs. Les joueurs se connectent par Internet directement au moteur du jeu (ports TCP/UDP du jeu). Ils n’ouvrent pas de session Windows, n’utilisent aucun partage de fichiers et n’accèdent pas à un Bureau à distance. Deux comptes d’administration existent pour la maintenance (session console ou « Remote Desktop for Administration »).
Dans ces conditions, la plupart des coûts liés aux CAL (Client Access Licenses) disparaissent : vous conservez la licence par cœur de l’édition Datacenter, et vous exploitez la double session RDP d’administration incluse — sans souscrire de RDS CAL. Ce guide détaille pourquoi, comment vérifier votre configuration et dans quels cas des licences supplémentaires redeviendraient nécessaires.
Rappel express sur les modèles de licence Windows Server 2019
Licence par cœur (Datacenter)
L’édition Datacenter se licencie par cœur physique, avec des minima (8 cœurs par processeur et 16 cœurs par serveur). Une fois couverts, vous êtes autorisé à exécuter un nombre illimité d’instances Windows Server dans des machines virtuelles sur l’hôte licencié, ainsi que des conteneurs Windows. Dans notre contexte, retenez : la clé Datacenter couvre le serveur lui‑même. Rien à ajouter côté « licence de base ».
CAL Windows Server : quand en faut‑il ?
Les Windows Server CAL sont requises pour des utilisateurs ou des appareils qui accèdent à des services Windows (authentification au domaine, partages de fichiers/SMB, impression, IIS/HTTP authentifié, etc.). À l’inverse, l’accès public par Internet à un service applicatif sans authentification Windows — par exemple un binaire de jeu qui écoute sur des ports dédiés — n’implique pas de CAL, car les joueurs sont assimilés à des utilisateurs externes anonymes du point de vue du système d’exploitation.
Point d’attention : si vous ajoutez ultérieurement des services Windows identifiables (ex. : partages SMB pour mods, portail IIS nécessitant une authentification, intégration Active Directory, etc.), vous devrez fournir des CAL (User ou Device) aux personnes qui y accèdent — ou envisager un « External Connector » pour de grands volumes d’utilisateurs externes authentifiés.
RDS CAL : seulement pour des bureaux/applications publiés
Les RDS CAL ne sont nécessaires que si vous fournissez un bureau à distance ou des applications publiées via les Services Bureau à distance (RD Session Host, RD Gateway, etc.). En revanche, deux sessions RDP « for Administration » sont incluses gratuitement et suffisent pour les tâches de maintenance. Tant que vous n’installez pas les rôles RDS et que seuls des administrateurs utilisent ces deux sessions, aucune RDS CAL n’est exigée.
Autres rôles/produits
Si vous activez des rôles Windows côté serveur (fichier/impression) ou déployez des produits Microsoft supplémentaires (ex. SQL Server), des licences spécifiques peuvent s’appliquer :
- Partages de fichiers/SMB : Windows Server CAL requises pour les utilisateurs qui y accèdent.
- Impression : Windows Server CAL requises pour les utilisateurs des files d’impression.
- SQL Server : modèle par cœur ou CAL SQL (distinct des CAL Windows).
Synthèse opérationnelle
| Élément | Exigence de licence | Commentaire |
|---|---|---|
| Licences par cœur (Datacenter) | Déjà couvertes | Votre clé Datacenter couvre tous les cœurs physiques de l’hôte. |
| Windows Server CAL | Aucune | Les joueurs ne s’authentifient pas auprès de Windows et n’utilisent pas de services Windows identifiables ; ils sont assimilés à des utilisateurs Internet anonymes. |
| RDS CAL (Remote Desktop Services) | Aucune | Les deux sessions « Remote Desktop for Administration » sont incluses. Des RDS CAL ne s’imposent que pour des bureaux/applications publiés aux utilisateurs finaux. |
| Autres rôles Windows (SMB, impression, SQL, etc.) | CAL ou licences dédiées requises | Ajoutez des CAL (User/Device) si vous exposez ces services à des utilisateurs authentifiés ; pour SQL, suivez le modèle de licence SQL (par cœur ou CAL SQL). |
| Conversion de version d’évaluation | Commande DISM | DISM /online /Set-Edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula puis redémarrer. |
Pourquoi les joueurs n’ont pas besoin de CAL dans ce cas
Le moteur de jeu ouvre ses propres sockets réseau (UDP/TCP) et ne délègue pas l’authentification à Windows. Les joueurs n’obtiennent ni jeton de sécurité Windows, ni accès à des API/partages/objets protégés par le système d’exploitation. Dans ce modèle, ils restent externes et anonymes pour Windows, même s’ils possèdent un compte applicatif au sein du jeu. Résultat : pas de CAL Windows requises.
Limite d’administration : deux sessions RDP
Windows Server permet jusqu’à deux connexions RDP simultanées pour l’administration, plus la session console. Cela suffit pour la plupart des opérations d’exploitation (mises à jour, redémarrages, diagnostics). Si un troisième administrateur doit intervenir au même moment, il faudra soit libérer une session, soit basculer vers un déploiement RDS avec RDS CAL.
Décider en un coup d’œil
- Les joueurs se connectent uniquement au moteur de jeu : aucune CAL Windows, aucune RDS CAL.
- Vous publiez des bureaux/applications via RDS : RDS CAL nécessaires.
- Vous exposez partages SMB/imprimantes/IIS authentifié : Windows Server CAL nécessaires pour les utilisateurs qui y accèdent.
- Beaucoup d’utilisateurs externes identifiés accédant à des services Windows : envisager l’External Connector plutôt que des CAL individuelles.
Scénarios concrets et recommandations
Serveur de jeux « pur » sur Internet
Le binaire du jeu écoute sur ses ports, aucune intégration AD/SMB/IIS. Deux administrateurs utilisent RDP pour la maintenance ponctuelle. Conformité : Datacenter par cœur déjà couvert, pas de CAL Windows, pas de RDS CAL. Conservez des preuves d’usage (journaux réseau, configuration de pare‑feu) montrant l’absence de services Windows exposés aux joueurs.
Tournoi LAN avec déploiement d’outils
Plusieurs postes partagés sur le même réseau local. Tant que les clients ne consomment que le service du jeu, la situation ne change pas. En revanche, si vous commencez à distribuer des fichiers via SMB ou à imposer une authentification Windows (partage privé, GPO, etc.), alors les utilisateurs qui accèdent à ces ressources nécessitent des Windows Server CAL. Dans ce cas, choisissez User CAL si chacun utilise plusieurs appareils, ou Device CAL si des groupes se relaient sur peu de machines.
Panel web d’administration
Si l’administration se fait par RDP d’administration, rien à ajouter. Si vous exposez un portail IIS authentifié (Windows, Kerberos, NTLM), les comptes qui s’y connectent requièrent des Windows Server CAL (ou un External Connector si ce sont des externes en très grand nombre).
Troisième administrateur simultané
Deux solutions : (1) libérer une session ou utiliser la console/iDRAC/iLO/KVM‑over‑IP ; (2) mettre en place une ferme RDS et acheter des RDS CAL si vous avez un besoin régulier d’accès simultané étendu.
Contrôles de conformité : check‑list pratique
- Aucun rôle RDS installé : pas de RD Session Host, RD Gateway, RD Web Access.
- Partages de fichiers désactivés vers Internet : ports 445/139/135 bloqués au périmètre.
- Pas d’IIS authentifié exposé aux joueurs ; si un site public d’info existe, limiter à l’accès anonyme.
- Deux comptes d’admin seulement, appartenance contrôlée au groupe « Administrateurs ».
- Journalisation des ports du jeu et des connexions entrantes (pare‑feu Windows, logs applicatifs).
- Preuves de couverture Datacenter : facture/contrat, inventaire des cœurs, capture de l’édition installée.
- Durcissement : NLA activée pour RDP, MFA via bastion/VPN, mots de passe robustes, mises à jour régulières.
Vérifications et commandes utiles
Confirmer l’édition et l’activation
dism /online /Get-CurrentEdition
dism /online /Get-TargetEditions
slmgr /dli
slmgr /ato
Passer de l’évaluation à Datacenter
DISM /online /Set-Edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
shutdown /r /t 0
Contrôler les rôles installés et les ports
powershell -NoLogo
Get-WindowsFeature | Where-Object {$_.Installed -eq $true} | Sort-Object DisplayName
Get-NetFirewallRule -Enabled True | Where-Object {$_.Direction -eq 'Inbound'}
netstat -ano | findstr /R /C:"LISTENING"
Limiter le RDP à l’administration
Vérifiez que les rôles RDS n’existent pas et appliquez les paramètres suivants :
- Stratégie locale : Limiter les connexions RDP à une seule session par utilisateur.
- Autoriser uniquement les administrateurs à se connecter via Services Bureau à distance.
- Activer NLA et exiger TLS.
Bonnes pratiques pour un serveur de jeux Windows
- Comptes séparés : un compte de service non‑admin pour le moteur de jeu, comptes d’admin distincts sans usage quotidien.
- Surface d’attaque minimale : désinstallez les rôles/fonctionnalités non utilisés, bloquez tous les ports sauf ceux du jeu et de l’administration.
- Mises à jour et redémarrages programmés : planifiez les patchs hors des créneaux de tournois, communiquez les indisponibilités.
- Surveillance : superviseur du processus du jeu, alertes sur crash, collecte de dumps, journaux centralisés.
- Sauvegardes : config, clés de licence, sauvegardes régulières des fichiers de configuration et éventuelles bases du jeu.
- Isolation : séparez l’administration du trafic joueurs (VLAN/bastion), interdisez SMB/WinRM depuis Internet.
Quand les CAL redeviennent nécessaires
| Changement introduit | Impact licence | Mesure à prendre |
|---|---|---|
| Partages de fichiers pour mods/replays | Windows Server CAL pour les utilisateurs qui y accèdent | Ajouter des User/Device CAL selon l’usage |
| Portail IIS nécessitant une authentification | Windows Server CAL (ou External Connector pour externes identifiés) | Dimensionner les CAL ou l’External Connector par serveur |
| Publication de bureaux/applications | RDS CAL requises | Déployer l’infrastructure RDS et acheter des RDS CAL |
| Intégration Active Directory pour les joueurs | Windows Server CAL pour chaque utilisateur/device qui s’authentifie | Provisionner des CAL et documenter l’accès |
| Déploiement de SQL Server | Licence SQL dédiée (par cœur ou CAL SQL) | Choisir le bon modèle selon le nombre d’utilisateurs/requêtes |
FAQ de terrain
Les joueurs utilisent un lanceur qui se connecte en HTTPS à une API hébergée sur le serveur. Faut‑il des CAL ?
Si l’API ne repose pas sur l’authentification Windows/AD et que les joueurs n’accèdent à aucun service Windows, vous restez dans l’exemption « externes anonymes ». Si l’API s’authentifie via Windows (Kerberos/NTLM/ comptes locaux), prévoyez des Windows Server CAL pour les utilisateurs concernés.
Un bot d’arbitrage ou un spectateur se connecte aux mêmes ports que les joueurs. Est‑ce différent ?
Non, c’est le même principe : tant que l’accès reste au niveau du service applicatif du jeu et non des services Windows, pas de CAL Windows.
Nous sommes hébergés dans le cloud sur une VM Windows fournie par le prestataire. Qu’est‑ce que cela change ?
Le fournisseur inclut généralement la licence Windows Server de l’instance. Les règles d’accès via CAL restent les mêmes : accès joueurs anonymes ⇒ pas de CAL. Si vous exposez des services Windows authentifiés à des utilisateurs, dimensionnez des CAL ou un External Connector.
Un troisième administrateur veut se connecter en même temps.
Les deux sessions RDP d’administration sont la limite sans RDS. Au‑delà, soit on libère une session, soit on déploie RDS et on achète des RDS CAL.
Windows Defender, pare‑feu et mises à jour affectent‑ils la licence ?
Non. Ces composants n’influencent pas les CAL. Ils sont toutefois essentiels pour la sécurité et doivent rester activés et configurés.
Faut‑il des CAL pour DHCP/DNS ?
Non. Les rôles d’infrastructure réseau (DHCP/DNS) n’exigent pas de CAL pour les appareils qui obtiennent une IP ou résolvent des noms. En revanche, les services d’annuaire, de fichiers, d’impression, ou IIS authentifié en exigent.
Modèle de dossier de conformité (à conserver)
- Preuve de licence Datacenter : contrat/facture, relevé des cœurs, capture d’écran de l’édition.
- Topologie réseau : schéma montrant les ports du jeu, filtrage, absence d’SMB/135‑139/445 vers Internet.
- Journal des rôles : export
Get-WindowsFeatureattestant l’absence de rôles RDS/SMB s’ils ne sont pas nécessaires. - Politique RDP : paramètres NLA, restriction aux administrateurs, preuve des deux sessions max.
- Captures des ACL de pare‑feu et des règles NAT montrant uniquement les ports du jeu et de l’admin.
- Procédures : routine de patching, sauvegardes, reprise après incident, comptes d’administration.
Guide pas à pas de mise en conformité
- Vérifiez l’édition et l’activation avec
dismetslmgr. - Désinstallez tout rôle RDS si présent (
Remove-WindowsFeaturecôté PowerShell). - Bloquez SMB/WinRM depuis Internet ; n’exposez que les ports du jeu et le bastion d’administration.
- Activez NLA pour RDP et limitez l’accès aux groupes d’admin.
- Attribuez au moteur de jeu un compte de service non‑admin avec les droits minimaux.
- Tracez les connexions entrantes (pare‑feu Windows, logs App) et archivez régulièrement.
- Documentez que les joueurs n’utilisent aucun service Windows (captures, exports de rôles).
- Planifiez les mises à jour et testez le redémarrage contrôlé de l’instance de jeu.
- Préparez une procédure « troisième admin » (libération de session ou bascule vers RDS si besoin récurrent).
- Réévaluez la licence si vous ajoutez un rôle Windows consommé par des utilisateurs.
Erreurs courantes à éviter
- Installer RDS par commodité alors que deux sessions d’admin suffisent : vous déclencheriez des besoins en RDS CAL.
- Partager des fichiers via SMB avec les joueurs « juste pour un test » : cela requiert des CAL pour les utilisateurs qui y accèdent.
- Publier un portail IIS authentifié sans anticiper les CAL nécessaires pour ses utilisateurs.
- Mélanger production et annuaire sur le même serveur de jeux : l’AD impose des CAL pour les utilisateurs authentifiés.
Récapitulatif clair
Dans un hébergement de parties multijoueurs sur Windows Server 2019 Datacenter, où les joueurs ne s’authentifient pas auprès de Windows et n’accèdent à aucun service Windows :
- CAL Windows Server : non requises pour les joueurs.
- RDS CAL : non requises tant que vous restez sur les deux sessions RDP d’administration incluses.
- Licence Datacenter par cœur : déjà couverte par votre clé.
- Si vous ajoutez des services Windows consommés par des utilisateurs : prévoyez des CAL (User/Device) ou un External Connector, et des RDS CAL si vous publiez un bureau/applications.
Annexe : User CAL ou Device CAL ?
| Option | À privilégier si… | Avantage | Limite |
|---|---|---|---|
| User CAL | Un même utilisateur utilise plusieurs appareils | Souplesse par personne | Coût si de nombreux utilisateurs uniques |
| Device CAL | Plusieurs personnes se relaient sur peu de postes | Rentable en environnement kiosque/LAN | Moins adapté si chaque joueur a plusieurs devices |
Annexe : reformulation des points clés
Exemption Internet : pas de CAL pour des utilisateurs externes non authentifiés auprès de Windows qui n’utilisent pas de services Windows identifiables.
Limite d’administration : jusqu’à deux connexions RDP simultanées pour la maintenance, sans RDS CAL.
External Connector : alternative aux CAL individuelles pour un grand volume d’utilisateurs externes authentifiés aux services Windows.
Conclusion : pour un serveur de jeux Windows Server 2019 Datacenter « pur », vous êtes déjà du bon côté de la conformité : aucune CAL pour les joueurs, aucune RDS CAL pour l’administration. Restez vigilant : le jour où vous activez des rôles Windows consommés par des utilisateurs, intégrez immédiatement les licences correspondantes et documentez‑le.