Les applications RemoteApp hébergées sur votre second hôte de session refusent de démarrer ? Entre erreurs « Windows cannot start the remote program » et « Remote Desktop can’t connect », cet article détaille chaque vérification réseau, service et configuration pour restaurer un lancement fiable et sécurisé.
Problématique : RemoteApp échoue uniquement sur un second Session Host
Dans une ferme RDS comportant deux serveurs :
- Serveur A : Connection Broker, Web Access et Session Host
- Serveur B : Session Host dédié aux applications métiers
Depuis le portail RD Web, toutes les RemoteApp résidant sur le serveur A se lancent correctement, tandis que celles du serveur B affichent :
« Windows cannot start the remote program. The following RemoteApp program is not in the list of authorized programs »
« Remote Desktop can’t connect to the computer… »
Ces symptômes indiquent qu’après l’authentification sur le Connection Broker, la sous‑connexion RDP entre le client et le serveur B ne s’établit pas.
Pourquoi les applications du serveur B ne se lancent‑elles pas ?
Plusieurs verrous peuvent isoler un Session Host et empêcher la publication effective de ses RemoteApp :
- Le port TCP 3389 n’est pas joignable (pare‑feu ou service non démarré).
- Le service Remote Desktop Services (TermService) est désactivé ou corrompu.
- Des règles réseau ou la pile IPv6 réacheminent mal le trafic.
- La liste de programmes publiée par le Connection Broker ne contient pas l’application (ou la contient sans signature valide).
- DNS ou certificats imposent un nom non résolu / non approuvé par le client.
Analyse rapide : questions à se poser avant tout
- Un
mstsc.exedirect versB:3389aboutit‑il ? - Quel est l’état du port 3389 (
netstat -ano | find ":3389") ? - Le même utilisateur lance‑t‑il sans problème une application hébergée sur A ?
- La collection de sessions inclut‑elle bien le serveur B ?
- Des mises à jour ou un redémarrage récent ont‑ils modifié la configuration réseau ?
Étapes de diagnostic détaillées
| Étape | Action | Détails pratiques |
|---|---|---|
| 1 | Réactiver Remote Desktop | Désactivez le Bureau à distance, redémarrez, réactivez. Cela réinitialise les ACL et la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server. |
| 2 | Ouvrir le port 3389 | Dans Pare‑feu Windows Defender, vérifiez la règle « Remote Desktop » pour les profils privé et public. Sur un firewall tiers, ajoutez une règle TCP 3389 en entrée. |
| 3 | Désactiver IPv6 si non requis | Dans les propriétés de l’interface réseau, décochez « TCP/IPv6 », redémarrez. Sur certaines appliances, la translation NAT‑PT vers 3389 échoue en présence d’IPv6. |
| 4 | Contrôler l’écoute RDP | qwinsta /server:B doit afficher rdp-tcp en Listen. Si absent, réinstallez la fonctionnalité Services Bureau à distance. |
| 5 | Mettre à jour la publication RemoteApp | Dans Server Manager → Remote Desktop Services → Collections, supprimez puis ré‑ajoutez l’application. Sélectionnez « Tasks → Refresh in RD Web Access ». |
| 6 | Vérifier certificats & DNS | Le FQDN du Broker et de la Gateway doit être inclus comme SAN dans le certificat et pointer vers l’adresse publique correcte. |
| 7 | Consulter la documentation Microsoft | L’article « Can’t establish a Remote Desktop session – Windows Server » couvre les licences CAL, NLA et stratégies GPO. |
Méthode complète de remédiation
Réinitialiser proprement le service Remote Desktop
Un service TermService inactif ou figé peut bloquer l’écoute sur 3389. Exécutez :
sc config TermService start= auto
net stop TermService
net start TermServicePuis, forcez la publication du pare‑feu :
netsh advfirewall set currentprofile state on
netsh advfirewall firewall set rule group="Remote Desktop" new enable=yesConfirmer la disponibilité réseau du port 3389
Côté client, un Test-NetConnection B -Port 3389 (PowerShell) doit retourner TcpTestSucceeded : True. Dans le cas contraire :
- Inspectez les ACL sur les routeurs intermédiaires ou l’UTM.
- Recherchez une règle de deep packet inspection bloquant RDP.
- Contrôlez le mapping NAT si le serveur est derrière un PAT externe.
Synchroniser la liste RemoteApp sur le Broker
À chaque ajout de serveur dans une collection, RD Web génère un fichier .rdp signé. Si la signature ne référence pas la nouvelle machine, le client détecte une incohérence et déclenche « program not in the list ». L’utilitaire rdpsign.exe permet de renouveler la signature :
rdpsign.exe /f chemin\vers\certificat.pfx /p motdepasse chemin\vers\*.rdpMaîtriser IPv6, NAT et pare‑feu applicatifs
Un environnement double‑pile peut conduire le client à négocier une adresse AAAA qui ne répond pas ou n’est pas routée. Deux stratégies possibles :
- Désactiver IPv6 uniquement sur l’interface du serveur B.
- Conserver IPv6 mais publier un enregistrement AAAA dans le DNS public et interne.
Dans tous les cas, assurez‑vous que les WAN links et proxies inspectent bien RDP‑TLS sur 3389.
Certificats, DNS et passerelle RD Gateway
Les certificats utilisés par le Broker, le Web Access et la Gateway doivent respecter l’UR I spécifiée dans le workspace du client. Placez, si nécessaire, plusieurs SAN :
- rdweb.domaine.local
- broker.domaine.local
- gateway.domaine.com
Une chaîne incomplète ou un nom d’hôte manquant déclenche le refus de connexion après l’authentification.
Collections de sessions et équilibrage
Ne mélangez pas RemoteApp isolées et bureaux complets dans la même Session Collection. Pour répartir la charge :
- Créez une collection dédiée aux applications critiques.
- Activez Load Balancing sur le Connection Broker.
- Surveillez la métrique Current Sessions dans
perfmon.exe.
Un Session Host placé en Drain mode pour maintenance continuera d’apparaître dans la liste si les .rdp ne sont pas rafraîchis.
Foire aux questions
Le port 3389 doit‑il être ouvert sur tous les hôtes ? Oui. Chaque Session Host écoute en entrée sur TCP 3389, même lorsque le client passe initialement par le Broker ou une Gateway SSL. Une passerelle RD Gateway peut‑elle remplacer 3389 ? La Gateway encapsule RDP dans HTTPS 443, mais le tunnel termine sur TCP 3389 côté Session Host. Le port reste donc indispensable en interne. Que signifie l’erreur ponctuelle « 127.1.1.1:8000 » ? Elle renvoie à un test local ou à un service tiers exécuté sur le poste client ; elle n’a aucun lien direct avec l’architecture RDS.
Bonnes pratiques pour éviter le retour de l’erreur
- Mettez à jour vos serveurs RDS chaque trimestre afin d’intégrer les correctifs TLS et NLA.
- Automatisez la vérification de port avec
Invoke-CommandetTest-NetConnectiondans un script de supervision. - Documentez chaque changement (GPO, certificat, ajout d’hôte) dans votre CMDB pour retracer la configuration précédente.
- Signez systématiquement les fichiers .rdp distribués à vos utilisateurs.
Conclusion
Une RemoteApp qui ne démarre pas depuis un second Session Host est presque toujours liée à un blocage bas niveau : port 3389 fermé, service RDP inactif, certificat ou DNS incohérent. En suivant l’ordre de diagnostic proposé (écoute RDP, pare‑feu, publication RemoteApp, certificats), vous éliminerez chaque point de défaillance et rétablirez un portail RD Web pleinement fonctionnel. Conservez enfin des procédures de test automatisé pour qu’une migration ou un correctif mensuel n’interrompe plus jamais vos utilisateurs.