Le déploiement de Remote Desktop Services échoue dans l’assistant ? Dans l’immense majorité des cas, le service de pare‑feu Windows est désactivé. Voici une méthode éprouvée pour corriger l’erreur, relancer l’installation et sécuriser votre environnement RDS.
Vue d’ensemble du problème
Lors de l’installation du rôle Remote Desktop Services (RDS) sur Windows Server, l’assistant se termine par une erreur générique. Le piège : même si vos règles sont « gérées ailleurs », le service Pare‑feu Windows (MpsSvc) doit impérativement être activé et en cours d’exécution pendant l’installation. Sans lui, l’assistant ne parvient pas à créer et à attacher les règles d’ouverture de ports nécessaires et abandonne silencieusement.
Autres facteurs aggravants fréquents : résolution DNS défaillante, serveur non joint au domaine, GPO qui désactivent le pare‑feu, ports dynamiques RPC filtrés, ou encore déploiement RDS partiellement installé après une tentative avortée.
Pourquoi l’assistant peut échouer
- Service de pare‑feu arrêté : l’assistant pilote la création de dizaines de règles (RDP, WinRM, RPC, WMI, etc.). Si MpsSvc est arrêté, ces étapes échouent.
- GPO contradictoires : des stratégies « Désactiver le Pare‑feu » empêchent la création/activation des règles même si vous démarrez MpsSvc manuellement.
- DNS et domaine : RDS s’appuie massivement sur AD DS et la résolution FQDN. Un simple mauvais suffixe DNS ou un enregistrement manquant suffit à faire échouer l’orchestration.
- Ports bloqués : RDP 3389/TCP, WinRM 5985/5986 et la plage RPC dynamique 49152‑65535 doivent être autorisés entre les rôles RDS et les contrôleurs de domaine.
- Image système altérée : des fichiers corrompus peuvent bloquer les opérations DISM/Server Manager.
Procédure de remédiation rapide
- Vérifier et activer le pare‑feu Windows
Exécuter dans PowerShell en tant qu’Administrateur :# Vérifier l’état des services essentiels Get-Service -Name MpsSvc, BFE | Format-Table -Auto # S’assurer que le pare-feu peut démarrer Set-Service -Name BFE -StartupType Automatic Set-Service -Name MpsSvc -StartupType Automatic Start-Service BFE Start-Service MpsSvc # Optionnel : activer les profils si une GPO les a coupés netsh advfirewall set allprofiles state onImportant : si une GPO désactive le pare‑feu, corrigez d’abord la stratégie (Configuration ordinateur → Modèles d’administration → Composants Windows → Pare‑feu Windows Defender). La valeur « Désactiver le Pare‑feu » doit être Non configuré ou Désactivé. - Relancer l’installation RDS
Rouvrez Server Manager et relancez l’assistant RDS. Sur un déploiement monoserveur, n’oubliez pas que le Connection Broker, le Session Host et le Web Access peuvent résider sur la même machine lors d’un premier test. - Débloquer manuellement RDP si l’erreur persiste
Exécutez la commande suivante pour autoriser RDP et créer les règles minimales :$tss = Get-WmiObject -Namespace root\cimv2\terminalservices -Class Win32_TerminalServiceSetting $tss.SetAllowTSConnections(1,0)Cette action active les connexions RDP et ajoute les règles nécessaires dans le pare‑feu. - Consulter la documentation Microsoft Learn
Cherchez l’article “Adding Remote Desktop Services role fails” pour dérouler toutes les étapes officielles et les correctifs courants (sans lien externe ici).
Étapes détaillées et diagnostics
Vérifications réseau et DNS
Avant tout, validez la base : branchement au domaine, FQDN résolu, connectivité entre les serveurs RDS, le broker et les DC.
# Afficher la configuration réseau et le suffixe DNS
ipconfig /all
# Vérifier la résolution DNS du domaine et d’un DC
nslookup contoso.local
nslookup dc01.contoso.local
# Tester les ports critiques vers le broker et un DC
Test-NetConnection broker.contoso.local -Port 3389
Test-NetConnection dc01.contoso.local -Port 53
Test-NetConnection dc01.contoso.local -Port 88
Test-NetConnection dc01.contoso.local -Port 389
Test-NetConnection broker.contoso.local -Port 5985 Assurez‑vous aussi de l’heure et de Kerberos :
w32tm /query /status
w32tm /query /source
w32tm /resyncJournaux utiles
- Journaux d’événements : Applications and Services Logs → Microsoft → Windows → TerminalServices‑Deployment / Operational pour les erreurs de déploiement.
- Server Manager :
C:\Windows\Logs\ServerManager.log - DISM/CBS :
C:\Windows\Logs\DISM\etC:\Windows\Logs\CBS\CBS.log
Recherchez rapidement les dernières erreurs RDS :
# Derniers événements du journal de déploiement RDS
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Deployment/Operational" |
Sort-Object TimeCreated -Descending | Select-Object -First 50 |
Format-Table TimeCreated, Id, LevelDisplayName, Message -WrapIntégrité du système
Corrigez une image potentiellement endommagée avant de réessayer :
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthPorts requis à minima
Les flux ci‑dessous doivent passer entre le serveur où vous installez RDS, le Connection Broker (s’il est distinct) et les contrôleurs de domaine. Ajoutez d’autres ports selon les rôles activés (Gateway, Web Access, SQL externe, etc.).
| Flux | Ports / Protocole | Sens conseillé | Raison |
|---|---|---|---|
| RDP Session Host | 3389/TCP | Entrant vers les Session Hosts | Transport des sessions RDP |
| WinRM | 5985/TCP (HTTP), 5986/TCP (HTTPS) | Entrant vers les serveurs gérés | Orchestration par Server Manager et cmdlets |
| RPC | 135/TCP + 49152‑65535/TCP | Bidirectionnel RDS ↔︎ DC / Broker | Appels RPC et WMI, détection des services |
| DNS | 53/TCP, 53/UDP | Sortant depuis les serveurs RDS vers DC/DNS | Résolution FQDN et SRV |
| Kerberos | 88/TCP, 88/UDP | Sortant RDS → DC | Authentification domaine |
| LDAP | 389/TCP, 636/TCP (LDAPS) | Sortant RDS → DC | Requêtes vers AD DS |
| SMB | 445/TCP | Bidirectionnel selon la topologie | Partages, scripts, copies de binaires |
| Gateway (si utilisée) | 443/TCP, 3391/UDP | Entrant vers RD Gateway | Tunnel HTTPS et UDP pour RDP |
| Web Access (si utilisé) | 443/TCP (recommandé), 80/TCP | Entrant vers RD Web | Portail Web RDS |
| SQL externe (si utilisé) | 1433/TCP | Sortant Broker → SQL | Base de données Connection Broker |
Dépannage pas à pas
Assainir un déploiement partiellement installé
Après un échec, des composants peuvent rester. Désinstallez‑les proprement, redémarrez, puis recommencez.
# Inventaire des rôles RDS
Get-WindowsFeature | Where-Object {$_.Name -like "RDS*" -or $_.Name -like "Remote-Desktop*"} |
Format-Table DisplayName, Name, InstallState -Auto
# Exemple : retrait des rôles (adapter à votre situation)
Uninstall-WindowsFeature RDS-Connection-Broker, RDS-Web-Access, RDS-RD-Server -RestartDéploiement scripté fiable avec PowerShell
Déployer par script contourne certains écueils de l’assistant et vous laisse des traces reproductibles.
# Paramètres
$Broker = "rds01.contoso.local"
$Web = "rds01.contoso.local" # même serveur pour un POC
$Host = "rds01.contoso.local"
# Prérequis : Management Tools et rôles de base
Install-WindowsFeature RDS-Connection-Broker, RDS-Web-Access, RDS-RD-Server -IncludeManagementTools -Verbose
# Déploiement RDS monoserveur
Import-Module RemoteDesktop
New-RDSessionDeployment -ConnectionBroker $Broker -WebAccessServer $Web -SessionHost $Host
# Configurer la licence (mode à adapter : PerUser ou PerDevice)
# Set-RDLicenseConfiguration -Mode PerUser -LicenseServer "rdlic01.contoso.local"
# Vérifier l’état du déploiement
Get-RDServer -ConnectionBroker $Broker | Format-Table Server, Roles -AutoForcer l’ouverture des règles RDP si nécessaire
Si malgré tout, l’assistant ne pousse pas ses règles, ouvrez le minimum vital.
# Activer le groupe de règles "Bureau à distance"
Enable-NetFirewallRule -DisplayGroup "Bureau à distance"
# ou, en anglais selon l’OS
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# Vérifier l’état des règles
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, ProfileContrôles Active Directory et droits
- Utilisez un compte disposant des droits d’administration sur le serveur et d’ajout d’ordinateurs dans l’OU cible du domaine.
- Vérifiez les SPN du broker si vous utilisez un nom personnalisé.
- Évitez toute confusion NetBIOS vs FQDN : l’assistant et les cmdlets préfèrent les FQDN.
Bonnes pratiques de sécurité RDP
- Jamais d’exposition directe de 3389 sur Internet. Pour l’accès externe, utilisez RD Gateway (443/3391) et, idéalement, un VPN ou une authentification multifacteur.
- Activer NLA (Network Level Authentication) via GPO pour réduire la surface d’attaque.
- Restreindre l’accès au groupe Utilisateurs du Bureau à distance et appliquer le droit « Autoriser l’ouverture de session par les Services Bureau à distance » uniquement aux groupes nécessaires.
- Surveiller les journaux de sécurité et activer l’audit des connexions RDP.
- Certificats : utilisez TLS valide pour Gateway et Web Access.
Check‑list rapide
- Le service MpsSvc est Automatique et Démarré.
- Aucune GPO ne désactive le pare‑feu Windows ni ne bloque les profils.
- DNS et domaine opérationnels : FQDN résolus, Kerberos OK, heure synchronisée.
- Ports RDP, WinRM et RPC dynamique autorisés entre serveurs RDS et DC.
- Aucune installation RDS incomplète en place (retrait puis redémarrage si besoin).
- Relance de l’assistant ou déploiement PowerShell exécuté sans erreur.
- Si besoin,
SetAllowTSConnectionsappliqué pour débloquer RDP. - Mises à jour Windows installées et redémarrage effectué.
Questions fréquentes
Le pare‑feu est géré par une GPO d’entreprise, je ne peux pas l’activer localement
Modifiez la stratégie au niveau du domaine : la stratégie « Désactiver le Pare‑feu Windows Defender » doit être Non configuré ou Désactivé, au minimum durant l’installation. Exécutez ensuite gpupdate /force et contrôlez avec rsop.msc ou gpresult /h.
Le serveur n’est pas joint au domaine
Un déploiement RDS complet (avec Broker, Collection et Licensing) attend un environnement AD DS. Pour des tests ponctuels, il est possible d’ajouter uniquement le rôle Session Host, mais la plupart des scénarios d’entreprise nécessitent la jonction au domaine.
Comment vérifier que RDP est bien actif après la correction
# Depuis un autre serveur
Test-NetConnection rds01.contoso.local -Port 3389
# Sur le serveur RDS
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | ft Name, Enabled, Profile
(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TerminalServiceSetting).AllowTSConnectionsDans quel ordre déployer une architecture multi‑rôles
Commencez par le Connection Broker. Ajoutez ensuite les Session Hosts, puis RD Web Access et RD Gateway si exposés. Terminez par la licence (mode Per User ou Per Device) et la création de collections.
Exemple de procédure complète reproductible
L’exemple ci‑dessous illustre un déploiement monoserveur solide, intégrant la correction pare‑feu, les vérifications réseau et la mise en place RDS.
# 1) Préparation pare-feu
Set-Service BFE -StartupType Automatic; Start-Service BFE
Set-Service MpsSvc -StartupType Automatic; Start-Service MpsSvc
netsh advfirewall set allprofiles state on
# 2) Sanity checks
ipconfig /all
nslookup contoso.local
Test-NetConnection dc01.contoso.local -Port 53
w32tm /query /source
# 3) Nettoyage éventuel
Get-WindowsFeature RDS* | ? InstallState -eq "Installed"
# Uninstall-WindowsFeature RDS-Connection-Broker, RDS-Web-Access, RDS-RD-Server -Restart
# 4) Installation et déploiement
Install-WindowsFeature RDS-Connection-Broker, RDS-Web-Access, RDS-RD-Server -IncludeManagementTools
Import-Module RemoteDesktop
$server = $env:COMPUTERNAME + ".contoso.local"
New-RDSessionDeployment -ConnectionBroker $server -WebAccessServer $server -SessionHost $server
# 5) Activation RDP minimale en secours (si nécessaire)
$tss = Get-WmiObject -Namespace root\cimv2\terminalservices -Class Win32_TerminalServiceSetting
$tss.SetAllowTSConnections(1,0)
# 6) Vérifications
Get-RDServer -ConnectionBroker $server
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Deployment/Operational" | sort TimeCreated -desc | select -first 10Conclusion
Dans la quasi‑totalité des échecs d’installation de RDS, la cause immédiate est un service de pare‑feu désactivé ou une stratégie qui le bloque. En rétablissant MpsSvc, en validant DNS/AD et en ouvrant les ports essentiels, l’assistant reprend son cours normal. En complément, un déploiement scripté via PowerShell vous offre traçabilité et reproductibilité. En suivant les vérifications ci‑dessus et en appliquant la commande SetAllowTSConnections si nécessaire, vous débloquez rapidement la situation et posez des bases saines pour votre infrastructure RDS.
Récapitulatif express
- Pare‑feu Windows actif et démarré, profils On.
- DNS/AD valides : FQDN, Kerberos, heure synchronisée.
- Ports 3389, 5985/5986, 135 + 49152‑65535 ouverts selon les flux.
- Nettoyage des reliquats puis relance de l’assistant ou déploiement PowerShell.
- Si blocage persiste :
SetAllowTSConnections(1,0). - Mettre à jour Windows et redémarrer avant un nouvel essai.