Une connexion Bureau à distance peut fonctionner normalement après la réinstallation des rôles RDS, puis cesser de fonctionner dès le redémarrage suivant du serveur. Le client RDP peut alors afficher une erreur 0x3, accompagnée d’une erreur étendue 0x7, tandis qu’une connexion administrative avec mstsc /admin continue parfois de fonctionner. Cette procédure présente le diagnostic et la solution appliqués avec succès sur un serveur Windows Server utilisant les rôles Hôte de session Bureau à distance et Service Broker pour les connexions Bureau à distance.
Signes fréquents
- La connexion Bureau à distance fonctionne après la réinstallation des rôles RDS, puis ne fonctionne plus après le redémarrage du serveur
- Le client Bureau à distance affiche une erreur 0x3 avec une erreur étendue 0x7
- La connexion avec mstsc /admin fonctionne alors qu’une connexion RDP normale échoue
- Le problème réapparaît systématiquement après un redémarrage programmé du serveur
- Les événements 1296 et 1306 apparaissent dans le journal TerminalServices-SessionBroker-Client
- Le redémarrage du service TermService rétablit immédiatement les connexions RDP
Causes possibles
- Le service Bureau à distance (TermService) démarre avant que le Service Broker RDS soit complètement opérationnel
- TermService ne rejoint pas correctement la batterie RDS après le démarrage du serveur
- Le service Connection Broker (Tssdis) ou Windows Internal Database (WID) n’est pas encore prêt lorsque TermService s’initialise
- Un problème différent de Broker RDS peut également provoquer une erreur 0x3 / 0x7 : il faut confirmer le diagnostic avec les événements Windows avant d’appliquer le correctif
Les vérifications à effectuer
Vérifier si la panne apparaît après un redémarrage
Si les rôles RDS viennent d’être réinstallés et que les connexions Bureau à distance fonctionnent de nouveau, ne considérez pas encore le problème comme résolu. Testez une connexion RDP normale, redémarrez complètement le serveur, attendez la fin de son démarrage puis testez de nouveau. Si le RDP fonctionne avant le redémarrage mais affiche de nouveau l’erreur 0x3 / 0x7 après celui-ci, poursuivez ce guide. Ce test est particulièrement important lorsque le serveur redémarre automatiquement la nuit ou le week-end et que la panne réapparaît systématiquement le lendemain.
Vérifier les événements du Connection Broker
Après le redémarrage du serveur et l’échec d’une connexion RDP normale, ouvrez l’Observateur d’événements et consultez : Journaux des applications et des services > Microsoft > Windows > TerminalServices-SessionBroker-Client > Operational. Recherchez particulièrement les événements 1280, 1281, 1283, 1296 et 1306. L’absence d’un événement 1281 après le démarrage, suivie d’événements 1296 et 1306 lors d’une tentative de connexion RDP, constitue un indice important que le serveur n’a pas correctement rejoint la batterie RDS.
Vérifier que les services RDS sont démarrés
Ouvrez PowerShell en tant qu’administrateur. La commande à copier est indiquée à la fin de cette étape. Elle affiche l’état de TermService (Services Bureau à distance), Tssdis (Connection Broker) et RDMS (Gestion des services Bureau à distance). Un service indiqué « Running » est démarré, mais cela ne garantit pas que le serveur a correctement rejoint le déploiement RDS. Commande : Get-Service -Name TermService,Tssdis,RDMS
Tester le redémarrage de TermService
Attention : cette opération peut déconnecter les sessions Bureau à distance en cours. Effectuez-la de préférence depuis la console du serveur, une console iKVM/iLO/iDRAC ou pendant une période de maintenance. Une fois le Connection Broker démarré, ouvrez PowerShell en tant qu’administrateur et copiez-collez cette commande : Restart-Service TermService -Force ; puis appuyez sur Entrée. Testez immédiatement une connexion RDP normale. Si le RDP fonctionne de nouveau et qu’un événement 1281 apparaît dans le journal TerminalServices-SessionBroker-Client, cela indique que le serveur rejoint correctement la batterie RDS après la réinitialisation de TermService.
Automatiser le correctif au démarrage du serveur
Si le test précédent rétablit systématiquement le RDP après chaque redémarrage, une tâche planifiée peut automatiser cette réinitialisation. Téléchargez le script avec ce lien : https://allopcs.com/wp-content/uploads/2026/09/RDS-TermService-Startup.zip puis décompressez le fichier ZIP. Le script attend le démarrage du service Connection Broker (Tssdis), pendant un maximum de 120 secondes, patiente encore 10 secondes puis redémarre TermService. Il enregistre son journal dans C:\Windows\Temp\RDS-TermService-Startup.log. La configuration de la tâche planifiée est décrite à l’étape 7.
Placer le script sur le serveur
Sur le serveur concerné, créez le dossier C:\Scripts s’il n’existe pas. Décompressez l’archive téléchargée, puis copiez le fichier RDS-TermService-Startup.ps1 dans ce dossier. Le chemin complet doit être : C:\Scripts\RDS-TermService-Startup.ps1. La tâche planifiée utilisera ce chemin pour lancer le script au démarrage du serveur.
Créer la tâche planifiée
Ouvrez le Planificateur de tâches sur le serveur et cliquez sur « Créer une tâche ». Dans l’onglet Général, nommez-la « RDS - Initialisation TermService ». Cliquez sur « Modifier l’utilisateur ou le groupe », saisissez SYSTEM, puis validez avec « Vérifier les noms » et OK. Cochez « Exécuter avec les autorisations maximales ». Dans l’onglet Déclencheurs, cliquez sur Nouveau, choisissez « Au démarrage », puis validez. Dans l’onglet Actions, cliquez sur Nouveau et choisissez « Démarrer un programme ». Dans « Programme/script », saisissez powershell.exe. Dans « Ajouter des arguments », saisissez exactement : -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Scripts\RDS-TermService-Startup.ps1" . Validez l’action puis la tâche. Le point après les guillemets ne fait pas partie des arguments.
Vérifier le fonctionnement après redémarrage
Pendant une période de maintenance, prévenez les utilisateurs puis redémarrez le serveur. Gardez un accès à sa console en cas de problème. Après le démarrage, consultez le fichier C:\Windows\Temp\RDS-TermService-Startup.log et vérifiez que les dernières lignes correspondent à ce redémarrage, avec les messages « Tssdis est Running » et « Etat TermService : Running ». Testez ensuite une connexion RDP normale, sans le paramètre /admin. Si la connexion fonctionne, le contournement a fonctionné pour ce redémarrage. Si le journal signale une erreur, n’est pas actualisé ou si la connexion échoue, poursuivez le diagnostic.