Windows Server 2025 : publier des applications avec RDS et RemoteApp

La généralisation du télétravail et des équipes distribuées a transformé l'accès aux applications métier en enjeu stratégique pour les entreprises de toutes tailles. Plutôt que de migrer l'ensemble du parc applicatif vers le cloud ou de déployer des solutions VPN complexes, les Remote Desktop Services (RDS) de Microsoft offrent une alternative éprouvée, performante et centralisée : les applications s'exécutent sur un serveur Windows centralisé, tandis que les utilisateurs y accèdent depuis n'importe quel appareil compatible RDP, qu'il s'agisse d'un PC Windows, d'un Mac, d'une tablette ou d'un navigateur web. Windows Server 2025, la dernière version du système d'exploitation serveur de Microsoft, apporte des améliorations notables à RDS : meilleure compatibilité avec les protocoles modernes, support amélioré de RemoteFX, intégration renforcée avec Entra ID (anciennement Azure AD) et des performances réseau optimisées. Ce guide complet couvre l'ensemble du processus de mise en place d'une infrastructure RDS sur Windows Server 2025, de l'installation des rôles à la publication des applications en RemoteApp, en passant par la sécurisation SSL et la configuration de la passerelle pour l'accès distant depuis Internet.

Architecture RDS — Session Host, Connection Broker, Web Access, Gateway

Les Remote Desktop Services reposent sur une architecture modulaire composée de plusieurs rôles complémentaires. Comprendre le rôle de chaque composant est indispensable avant toute installation.

RD Session Host (RDSH)

Le Session Host est le serveur sur lequel s'exécutent réellement les applications et les sessions des utilisateurs. C'est le composant central de l'infrastructure RDS. Chaque utilisateur connecté dispose d'une session isolée sur ce serveur. En environnement de production, plusieurs Session Hosts peuvent être regroupés en collection pour assurer la haute disponibilité et l'équilibrage de charge.

RD Connection Broker (RDCB)

Le Connection Broker gère la distribution des connexions entre les Session Hosts d'une même collection. Il assure :

• La reconnexion des sessions déconnectées vers le bon Session Host.
• L'équilibrage de charge entre les serveurs de la collection.
• La gestion des licences RDS en coordination avec le License Server.

RD Web Access (RDWA)

Le Web Access expose les RemoteApp et les collections de sessions via un portail web (HTTPS). Les utilisateurs accèdent à leurs applications depuis un navigateur sans configuration spécifique du client RDP, en se connectant typiquement à https://remote.monentreprise.fr/RDWeb.

RD Gateway (RDGW)

La Gateway RDS permet d'encapsuler les connexions RDP dans du HTTPS (port 443), autorisant l'accès depuis Internet sans ouvrir le port 3389 directement. Elle joue le rôle de point d'entrée sécurisé pour les utilisateurs mobiles ou distants.

RD License Server

Le serveur de licences gère les CAL (Client Access License) RDS. Sans serveur de licences configuré et actif, RDS fonctionne en mode de grâce pendant 120 jours avant de refuser les connexions.

Pour les petites structures, tous ces rôles peuvent coexister sur un même serveur. Pour la production, la séparation des rôles sur des serveurs dédiés est recommandée pour la résilience et les performances.

Prérequis et licences RDS (CAL Device/User)

Licences Windows Server

Windows Server 2025 est disponible en éditions Standard et Datacenter. Les deux supportent RDS. L'édition Standard permet 2 machines virtuelles par licence ; l'édition Datacenter est illimitée en VMs et préférable pour les environnements virtualisés denses.

CAL RDS (Client Access License)

Chaque utilisateur ou appareil accédant à un Session Host doit disposer d'une CAL RDS, en plus de la CAL Windows Server standard. Deux modèles de CAL existent :

• CAL Device : attribuée à un appareil. Tous les utilisateurs de cet appareil peuvent accéder à RDS. Idéale pour les postes partagés (équipes en rotation, salles de cours).
• CAL User : attribuée à un utilisateur. L'utilisateur peut accéder depuis n'importe quel appareil. Recommandée pour les télétravailleurs et les profils itinérants.

Les CAL RDS sont distinctes des CAL Microsoft 365 qui incluent, selon les licences, l'accès RDS pour certains scénarios. Vérifier la conformité licences avec un revendeur Microsoft agréé avant tout déploiement en production.

Prérequis matériels (Session Host)

• CPU : 4 cores minimum ; compter 0.5 à 1 vCPU par session active.
• RAM : 16 Go minimum ; compter 1 à 2 Go par utilisateur connecté selon les applications.
• Stockage : SSD recommandé pour les profils utilisateurs. NVMe pour les workloads intenses.
• Réseau : 1 Gbps minimum ; QoS recommandée pour prioriser le trafic RDP.

Installer les rôles RDS sur Windows Server 2025

L'installation des rôles RDS sur Windows Server 2025 peut se faire via le Gestionnaire de serveur (GUI) ou PowerShell. L'approche PowerShell est préférable pour la reproductibilité et l'automatisation.

Installation via PowerShell

# Installation des rôles RDS sur un seul serveur (déploiement simplifié)
# À exécuter sur le serveur cible en tant qu'Administrateur

# Session Host + Connection Broker + Web Access + License Server
Install-WindowsFeature -Name RDS-RD-Server,RDS-Connection-Broker,RDS-Web-Access,RDS-Licensing -IncludeManagementTools

# Pour la Gateway (sur le même serveur ou un serveur dédié)
Install-WindowsFeature -Name RDS-Gateway -IncludeManagementTools

# Redémarrage nécessaire après installation
Restart-Computer -Force

Installation via l'Assistant Ajout de rôles

Pour un déploiement guidé, le Gestionnaire de serveur propose un assistant spécifique RDS :

1. Gestionnaire de serveur → Gérer → Ajouter des rôles et des fonctionnalités.
2. Choisir Installation des services Bureau à distance (et non l'installation standard).
3. Sélectionner Déploiement rapide pour un serveur unique ou Déploiement standard pour une infrastructure multi-serveurs.
4. Sélectionner les rôles à installer selon l'architecture retenue.

Activation du serveur de licences

# Activer le serveur de licences RDS
$licServer = "NOM-DU-SERVEUR"
$tsLic = Get-WmiObject -Namespace root/CIMV2 -Class Win32_TSLicenseServer -ComputerName $licServer
$tsLic.ActivateServer(5, "FR", $null, $null, $null, $null) | Out-Null

# Installer les licences CAL (nécessite une connexion Internet ou activation par téléphone)
# Via la console Gestionnaire de licences des services Bureau à distance
licmgr.exe

Créer une collection de sessions (Session Collection)

Une collection de sessions regroupe un ou plusieurs Session Hosts et définit les paramètres de connexion pour un groupe d'utilisateurs.

Création de la collection

1. Dans le Gestionnaire de serveur → Services Bureau à distance → Collections.
2. Cliquer sur Créer des services Bureau à distance → Session collection.
3. Nommer la collection : Applications-Metier.
4. Sélectionner les serveurs Session Host à inclure.
5. Définir les groupes d'utilisateurs autorisés (ex : DOMAINE\RDS-Users).
6. Configurer les disques de profils utilisateurs (User Profile Disks) — voir section dédiée.

Paramètres avancés de la collection

Dans les propriétés de la collection, plusieurs paramètres influencent les performances et l'expérience utilisateur :

• Limite de sessions par serveur : définir un plafond pour éviter la surcharge.
• Redirection de ressources : activer ou désactiver la redirection des imprimantes, disques locaux, Presse-papiers selon les besoins de sécurité.
• Délai de session inactive : déconnecter les sessions inactives après un délai défini (recommandé : 30 minutes).
• RemoteApp programs : gérer les applications publiées dans cette collection.

Publier une application en RemoteApp (Bureau à distance → RemoteApp Programs)

RemoteApp permet de présenter une application Windows comme si elle s'exécutait localement sur le poste de l'utilisateur. La fenêtre de l'application apparaît dans la barre des tâches du client, sans l'interface complète du bureau distant.

Publier une application

1. Dans Services Bureau à distance → sélectionner la collection → RemoteApp Programs.
2. Cliquer sur Publier des programmes RemoteApp.
3. La liste des applications installées sur le Session Host s'affiche. Sélectionner les applications à publier (ex : Excel, Sage, ERP métier).
4. Valider : les applications apparaissent dans la collection avec leur icône.

Publier une application personnalisée

Pour publier une application non listée ou avec des arguments spécifiques :

# Publier une application avec chemin personnalisé via PowerShell
New-RDRemoteApp -CollectionName "Applications-Metier" `
    -DisplayName "Mon ERP" `
    -FilePath "C:\Program Files\MonERP\erp.exe" `
    -CommandLineSetting Require `
    -RequiredCommandLine "/mode=remote" `
    -ConnectionBroker "RDS-BROKER.mondomaine.local"

Les RemoteApps publiées sont accessibles via le portail RD Web Access, via les fichiers .rdp générés automatiquement, ou via les GPO de distribution des RemoteApps (RemoteApp and Desktop Connections).

Configurer le RD Web Access (accès via navigateur)

Le portail Web Access est accessible par défaut à l'adresse https://SERVEUR/RDWeb. Après connexion avec les credentials Active Directory, les utilisateurs voient les RemoteApps auxquelles ils ont accès.

Configuration du Web Access

1. Le Web Access est configuré automatiquement lors de l'installation du rôle. Vérifier via IIS Manager que le site RDWeb est actif.
2. Configurer le nom d'hôte public : dans les propriétés de déploiement RDS → RD Web Access → saisir le FQDN public (remote.monentreprise.fr).
3. Associer un certificat SSL à ce FQDN (voir section suivante).

Personnalisation du portail

La page web RDWeb peut être personnalisée (logo, couleurs) en modifiant les fichiers dans C:\Windows\Web\RDWeb\Pages\. Une personnalisation de base améliore l'adoption par les utilisateurs en rendant le portail cohérent avec l'identité de l'entreprise.

Sécuriser RDS avec SSL/TLS (certificat)

Par défaut, RDS utilise un certificat auto-signé qui génère des avertissements dans les navigateurs et clients RDP. En production, un certificat SSL valide (Let's Encrypt, DigiCert, Sectigo) est indispensable.

Configurer les certificats RDS

# Configurer le certificat pour chaque rôle RDS via PowerShell
# Importer le certificat PFX d'abord
$cert = Import-PfxCertificate -FilePath "C:\certs\remote.monentreprise.fr.pfx" `
    -CertStoreLocation "cert:\LocalMachine\My" `
    -Password (ConvertTo-SecureString -String "MotDePasse" -AsPlainText -Force)

$thumbprint = $cert.Thumbprint

# Appliquer aux rôles RDS
$connectionBroker = "RDS-BROKER.mondomaine.local"

Set-RDCertificate -Role RDRedirector -ImportPath "C:\certs\remote.monentreprise.fr.pfx" `
    -Password (ConvertTo-SecureString "MotDePasse" -AsPlainText -Force) `
    -ConnectionBroker $connectionBroker -Force

Set-RDCertificate -Role RDPublishing -ImportPath "C:\certs\remote.monentreprise.fr.pfx" `
    -Password (ConvertTo-SecureString "MotDePasse" -AsPlainText -Force) `
    -ConnectionBroker $connectionBroker -Force

Set-RDCertificate -Role RDWebAccess -ImportPath "C:\certs\remote.monentreprise.fr.pfx" `
    -Password (ConvertTo-SecureString "MotDePasse" -AsPlainText -Force) `
    -ConnectionBroker $connectionBroker -Force

Set-RDCertificate -Role RDGateway -ImportPath "C:\certs\remote.monentreprise.fr.pfx" `
    -Password (ConvertTo-SecureString "MotDePasse" -AsPlainText -Force) `
    -ConnectionBroker $connectionBroker -Force

Configurer RD Gateway pour l'accès depuis Internet

La RD Gateway encapsule le trafic RDP dans HTTPS (port 443), permettant aux utilisateurs distants de se connecter aux applications RDS sans VPN, avec un niveau de sécurité élevé.

Configuration de la Gateway

1. Ouvrir Gestionnaire de passerelle des services Bureau à distance (tsgateway.msc).
2. Dans Stratégies d'autorisation des connexions (CAP) → créer une nouvelle stratégie autorisant les groupes d'utilisateurs RDS.
3. Dans Stratégies d'autorisation des ressources (RAP) → définir quels serveurs les utilisateurs peuvent joindre via la Gateway.

# Créer une stratégie CAP via PowerShell
Add-RDServer -Server "RDS-GATEWAY.mondomaine.local" -Role RDS-Gateway -ConnectionBroker "RDS-BROKER.mondomaine.local"

# Vérifier le service Gateway
Get-Service TSGateway | Select-Object Name, Status, StartType

Configuration DNS et pare-feu

• Créer un enregistrement DNS public A pointant remote.monentreprise.fr vers l'IP publique du pare-feu.
• Ouvrir le port 443/TCP entrant vers l'IP du serveur RD Gateway.
• Ne jamais exposer le port 3389 directement sur Internet.

Optimiser les performances RDS pour une expérience utilisateur optimale

La qualité de l'expérience utilisateur sur une infrastructure RDS dépend de nombreux paramètres au-delà du simple dimensionnement serveur. Plusieurs optimisations permettent d'améliorer significativement la fluidité des sessions, même sur des liaisons Internet de qualité moyenne.

Paramètres de qualité d'affichage RDP

Le protocole RDP de Windows Server 2025 intègre des mécanismes d'adaptation automatique de la qualité d'affichage en fonction de la bande passante disponible. Pour les connexions Internet lentes, configurer les GPO suivantes :

# GPO : Configuration ordinateur → Modèles d'administration
# → Composants Windows → Services Bureau à distance → Hôte de session Bureau à distance → Environnement de session à distance

# Compression RDP
"Configurer la compression pour les données distantes" : Optimisé pour utiliser moins de mémoire

# Qualité d'image
"Configurer la mise en cache des bitmaps persistants" : Activé
"Limiter la profondeur de couleur maximale" : 16 bits (pour connexions lentes)

# RemoteFX (Windows Server 2025)
"Configurer RemoteFX" : Activé avec compression adaptative

QoS réseau pour RDP

Sur les réseaux partagés, configurer la QoS pour prioriser le trafic RDP (port 3389 ou 443 via Gateway) évite la dégradation des sessions lors de pics de charge réseau :

# Créer une stratégie QoS via GPO pour prioriser RDP
# GPO → Configuration ordinateur → Paramètres Windows → QoS basée sur les stratégies
# Nouveau : Nom "Priorité RDP", DSCP = 46 (Expedited Forwarding), Port destination = 3389

Paramètres de session et délais

Les délais d'expiration des sessions sont critiques pour libérer les licences CAL et les ressources serveur :

# GPO : Hôte de session Bureau à distance → Délais d'expiration des sessions
# "Définir le délai de déconnexion des sessions actives" : 8 heures
# "Définir le délai pour les sessions déconnectées actives" : 4 heures
# "Définir le délai d'expiration des sessions inactives" : 30 minutes
# "Fin d'une session déconnectée" : Déconnecter (et non Terminer pour préserver le travail)

Optimisation des applications publiées

Certaines applications présentent des comportements problématiques en environnement multi-sessions. Points de vigilance :

• Chemins de fichiers temporaires : s'assurer que les applications utilisent %TEMP% et %APPDATA% (variables par session) et non des chemins absolus partagés.
• Licences logicielles flottantes : certains logiciels (AutoCAD, Sage, etc.) nécessitent une configuration spécifique pour le mode multi-sessions RDS. Contacter l'éditeur pour les paramètres de licences flottantes.
• Polices et thèmes : standardiser les polices installées sur le Session Host pour éviter les substitutions d'affichage.
• Imprimantes : la redirection automatique des imprimantes locales peut générer des conflits. Configurer Universal Print Driver ou Easy Print pour normaliser l'impression.

Haute disponibilité RDS

Pour les environnements critiques, la haute disponibilité RDS s'articule autour de plusieurs éléments :

• Connection Broker en cluster : deux Connection Brokers en mode actif/passif avec SQL Server comme base de données partagée.
• Multiple Session Hosts : l'équilibrage de charge automatique distribue les nouvelles sessions entre les hôtes. Si un hôte tombe, les sessions des autres hôtes ne sont pas affectées.
• Partage SMB haute disponibilité : les profils FSLogix ou UPD doivent être stockés sur un partage SMB hautement disponible (DFS-N + DFS-R ou cluster Windows).
• Monitoring proactif : intégrer les compteurs de performance RDS dans un outil de supervision (PRTG, Zabbix, Datadog) avec alertes sur la charge CPU, RAM et le nombre de sessions.

Gestion des profils utilisateurs (User Profile Disks / FSLogix)

La gestion des profils utilisateurs est un point critique en environnement RDS multi-sessions. Sans solution adaptée, les profils locaux peuvent se désynchroniser entre les sessions sur différents Session Hosts.

User Profile Disks (UPD) — solution native

Les UPD stockent le profil de chaque utilisateur dans un fichier VHDX sur un partage réseau. Lors de la connexion, le VHDX est monté en tant que disque local, garantissant la cohérence du profil quelle que soit la session host utilisée.

# Configurer les UPD sur une collection via PowerShell
Set-RDSessionCollectionConfiguration -CollectionName "Applications-Metier" `
    -EnableUserProfileDisk $true `
    -MaxUserProfileDiskSizeGB 10 `
    -DiskPath "\\FILESERVER\RDSProfiles$" `
    -ConnectionBroker "RDS-BROKER.mondomaine.local"

FSLogix — solution recommandée pour la production

FSLogix (acquis par Microsoft en 2018, désormais inclus dans les licences Microsoft 365) offre des performances supérieures aux UPD natifs. Les profils sont stockés dans des conteneurs VHD/VHDX sur un partage SMB :

# Configuration FSLogix via GPO ou registre
# Clé : HKLM\SOFTWARE\FSLogix\Profiles
$regPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
New-ItemProperty -Path $regPath -Name "Enabled" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path $regPath -Name "VHDLocations" -Value "\\FILESERVER\FSLogix$" -PropertyType MultiString -Force
New-ItemProperty -Path $regPath -Name "SizeInMBs" -Value 30000 -PropertyType DWORD -Force
New-ItemProperty -Path $regPath -Name "IsDynamic" -Value 1 -PropertyType DWORD -Force

FSLogix est particulièrement recommandé pour les environnements utilisant MDT pour le déploiement des postes en combinaison avec RDS, car les deux outils s'intègrent naturellement dans un workflow Microsoft cohérent. Nos experts en gestion de la sécurité externalisée peuvent vous conseiller sur l'architecture optimale.

Monitoring et dépannage RDS

Outils de monitoring intégrés

• Gestionnaire de serveur → Services Bureau à distance : vue d'ensemble des sessions actives, utilisateurs connectés, état des serveurs de la collection.
• Gestionnaire des tâches (sur le Session Host) : onglet Utilisateurs pour voir toutes les sessions actives et leur consommation de ressources.
• Observateur d'événements : journaux Applications and Services Logs → Microsoft → Windows → TerminalServices-*.

# Lister toutes les sessions actives via PowerShell
Get-RDUserSession -CollectionName "Applications-Metier" -ConnectionBroker "RDS-BROKER.mondomaine.local" | Select-Object UserName, HostServer, SessionState, SessionID

# Déconnecter une session inactive
Invoke-RDUserLogoff -HostServer "RDSH-01.mondomaine.local" -UnifiedSessionID 3 -Force

Erreurs courantes et résolutions RDS

La documentation officielle Microsoft RDS est disponible sur learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/. Pour la documentation FSLogix, consulter learn.microsoft.com/en-us/fslogix/.

Combien d'utilisateurs simultanés un Session Host Windows Server 2025 peut-il supporter ?

Le nombre dépend fortement des applications utilisées et des ressources allouées. Pour des applications bureautiques légères (Excel, Word, ERP web), un Session Host avec 32 Go de RAM et 8 vCPUs peut supporter 40 à 60 utilisateurs simultanés confortablement. Les applications gourmandes en CPU (calculs, rendu) réduisent significativement cette capacité. Il est recommandé de démarrer avec un ratio de 1 Go de RAM par utilisateur plus 4 Go pour le système, puis d'ajuster après observation en production.

Les utilisateurs Mac peuvent-ils utiliser RDS RemoteApp ?

Oui. Microsoft Remote Desktop pour macOS (disponible sur le Mac App Store gratuitement) supporte pleinement les connexions RDS et l'affichage des RemoteApps via les fichiers .rdp. Les utilisateurs Mac peuvent également accéder aux RemoteApps via le portail RD Web Access depuis Safari ou Chrome, sans installation de client spécifique.

Peut-on utiliser RDS sans Active Directory ?

RDS peut fonctionner en mode workgroup (sans AD) pour les très petites structures. Cependant, les fonctionnalités de Connection Broker, la gestion des licences et les stratégies de groupe requièrent un domaine Active Directory. En production, un AD est pratiquement indispensable pour administrer efficacement les utilisateurs RDS.

Quelle est la différence entre RemoteApp et VDI (Virtual Desktop Infrastructure) ?

RemoteApp publie des applications individuelles qui apparaissent dans la barre des tâches du poste local, comme si elles étaient installées localement. VDI fournit un bureau Windows complet dans une machine virtuelle dédiée par utilisateur. RemoteApp est plus économique en ressources (sessions partagées) ; VDI offre une isolation totale mais nécessite une VM par utilisateur. Windows Server 2025 supporte les deux modèles via RDS.

Comment migrer des profils itinérants existants vers FSLogix ?

Microsoft propose l'outil FSLogix Profile Migration Tool pour migrer les profils itinérants (Roaming Profiles) ou les UPD existants vers des conteneurs FSLogix. La migration se fait utilisateur par utilisateur, avec une période de coexistence possible. Il est recommandé de tester sur un groupe pilote avant la migration globale.