Windows Server 2022 : lancer automatiquement une application à la connexion RDP avec la GPO « Start a program on connection »

Vous avez activé « Start a program on connection » pour lancer calc.exe en RDP sur Windows Server 2022, mais seul le Bureau apparaît ? Ce guide explique pourquoi et fournit une procédure fiable, reproductible et sûre pour corriger le problème.

Sommaire

Contexte et symptômes sous Windows Server 2022

Sur un serveur Windows Server 2022, la stratégie locale ou de domaine Start a program on connection doit ouvrir automatiquement un exécutable (ex. calc.exe) lors de l’ouverture d’une session RDP. Le Resultant Set of Policy (RSOP) confirme l’application de la GPO, et la même configuration fonctionne sur Windows Server 2012 ou pour des comptes de domaine. Pourtant, pour des comptes locaux, la Calculatrice ne se lance pas : l’utilisateur arrive sur un Bureau classique.

Ce symptôme est typique d’un environnement où un composant RDS est manquant, où des paramètres concurrentiels en Computer Configuration neutralisent l’action de la GPO utilisateur, ou encore où le Program path/Working directory est mal renseigné.

Ce que fait réellement « Start a program on connection »

Cette stratégie remplace la shell de l’utilisateur RDP par un programme unique. Concrètement :

  • À la connexion RDP, le serveur ne charge pas l’Explorateur Windows ; il démarre l’exécutable indiqué.
  • Dès que l’application se ferme, la session RDP se déconnecte ou se termine.
  • Le paramètre existe à la fois en User Configuration et en Computer Configuration.

Où se trouvent les paramètres

Dans l’Éditeur de stratégie de groupe (local ou de domaine), le chemin est similaire :

  • Configuration utilisateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Environnement de session > Start a program on connection
  • Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Environnement de session > Start a program on connection

La stratégie Always show desktop on connection se trouve au même emplacement.

Priorités et effets

Les paramètres en Computer Configuration priment sur ceux en User Configuration. Et Always show desktop on connection impose, si activé, l’affichage du Bureau et empêche l’exécution d’un programme unique.

ParamètreEmplacementPrioritéEffet attendu
Start a program on connectionUser ou ComputerFaible si Computer est différentRemplace le Bureau par le programme indiqué
Always show desktop on connectionComputerÉlevéeForce l’ouverture du Bureau, neutralise un programme unique
Program path / Working directoryUser ou ComputerN/AChemin incorrect = échec de session ou retour au Bureau

Causes fréquentes d’échec sous Windows Server 2022

Rôle RDS requis

Le serveur doit exécuter le rôle Remote Desktop Services, et plus précisément la composante Remote Desktop Session Host (RDSH). Sans RDSH, Start a program on connection peut n’être ni honoré, ni fiable pour des comptes locaux.

Vérifier l’installation :

Server Manager > Add roles and features > Remote Desktop Services > Remote Desktop Session Host

Vérifier/installer via PowerShell :

# Vérifier
Get-WindowsFeature -Name RDS-RD-Server

# Installer (redémarrage souvent requis)

Install-WindowsFeature -Name RDS-RD-Server -IncludeManagementTools

Conflit de stratégies

  • Des valeurs divergentes entre Computer et User provoquent la neutralisation du comportement attendu.
  • Always show desktop on connection activé empêche systématiquement l’ouverture d’un programme unique.

Paramétrage du programme

  • Un chemin incomplet ou erroné (Program path and file name) fait échouer la session.
  • Un Working directory inexistant, ou nécessitant des privilèges non accordés à l’utilisateur, provoque une déconnexion immédiate ou l’ouverture du Bureau.
  • Attention à la redirection WoW64 : pour lancer une application 32 bits depuis un OS 64 bits, utiliser le bon chemin (Program Files (x86)) ou SysWOW64 si nécessaire.

Différences avec Windows Server 2012

Des environnements plus anciens toléraient parfois des configurations partielles (ex. sans RDSH) ou des paramètres hérités. Windows Server 2022 applique des vérifications plus strictes : l’absence du rôle RDSH ou un conflit de Computer Configuration rend le lancement automatique moins permissif, surtout pour des comptes locaux.

Comptes de domaine vs comptes locaux

Les comptes de domaine bénéficient souvent de GPO Computer déjà cohérentes via l’OU Serveurs RDS. Les comptes locaux, eux, dépendent de la stratégie locale : la moindre divergence côté Computer annule l’effet de la stratégie utilisateur.

Procédure de résolution détaillée

  1. Vérifier et, si besoin, installer le rôle RDSH Installez Remote Desktop Session Host sur le serveur. Sans lui, la stratégie peut ne pas être exécutée correctement. Après installation, redémarrez le serveur.
  2. Unifier les stratégies entre Computer et User Dans la stratégie locale (gpedit.msc) ou la GPO de domaine ciblant le serveur :
    • Si Computer Configuration porte une valeur différente de User Configuration, alignez-les. Vous pouvez également laisser Computer Not Configured et définir uniquement User.
    • Évitez les paramètres contradictoires venant d’une autre GPO liée au serveur.
    Élément Valeur recommandée Start a program on connection (Computer) Not Configured ou identique à User Start a program on connection (User) Enabled, chemin complet du programme, répertoire de travail valide
  3. Désactiver « Always show desktop on connection » Si vous souhaitez vraiment remplacer le Bureau par une application unique, réglez cette stratégie sur Disabled dans Computer Configuration. Sinon, le Bureau s’ouvrira systématiquement.
  4. Renseigner le chemin et le répertoire de travail Exemple correct pour la Calculatrice (Windows Server 2022) : Program path and file name : C:\Windows\System32\calc.exe Working directory : C:\Windows\System32 (ou laisser vide) Pour des applications tierces, utilisez le chemin absolu (évitez les variables d’environnement si possible) et pointez le Working directory vers un dossier existant et accessible à l’utilisateur.
  5. Actualiser la stratégie et effectuer un test RDP gpupdate /force Fermez la session, puis ouvrez une nouvelle session RDP avec un compte local cible. L’application doit se lancer automatiquement, et la session doit se fermer lorsque l’utilisateur quitte l’application.

Vérifications et diagnostics utiles

Confirmer l’application de la stratégie

  • RSOP depuis la session de l’utilisateur concerné.
  • gpresult pour générer un rapport : gpresult /h C:\Temp\gp.html & start C:\Temp\gp.html

Journaux d’événements à consulter

  • Microsoft‑Windows‑GroupPolicy/Operational : traitement des GPO côté ordinateur et utilisateur.
  • Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational : création et fermeture des sessions.
  • Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational : négociation RDP et erreurs de démarrage de shell.

Recherchez des messages indiquant un chemin introuvable, une défaillance de shell ou une stratégie contradictoire.

Paramètres côté client RDP

Assurez-vous qu’aucun paramètre Program n’est défini dans le fichier RDP du client, susceptible d’entrer en conflit. Nettoyez d’anciens fichiers .rdp si nécessaire.

Résumé des paramètres critiques

ParamètreValeur pour lancer calc.exeCommentaires
Start a program on connectionEnabledDéfinir en User et/ou Computer. Éviter les conflits.
Program path and file nameC:\Windows\System32\calc.exeChemin absolu recommandé.
Working directoryC:\Windows\System32 ou videDoit exister et être accessible.
Always show desktop on connectionDisabledSinon le Bureau s’affichera et l’application unique ne sera pas lancée.
Rôle Remote Desktop Session HostInstalléIndispensable pour un comportement fiable côté serveur.

Erreurs fréquentes et corrections rapides

  • Chemin avec espaces non entre‑guillemets : utilisez le chemin absolu sans guillemets dans la stratégie, ou testez via cmd.exe /c "C:\Chemin Avec Espaces\app.exe" si l’application requiert des arguments.
  • Programme réseau sur partage UNC : préférer un binaire local ou une application publiée. Un chemin UNC ajoute latence, dépendances et potentiels refus d’accès.
  • Application nécessitant « Élever » (UAC) : éviter les exécutables nécessitant des privilèges admin pour le shell utilisateur.
  • Sessions administratives (/admin) : ces connexions sont conçues pour l’administration, pas pour la publication d’applications. Testez avec une session utilisateur standard.

Alternatives selon le besoin

  • Exécuter plusieurs programmes : la stratégie Run these programs at user logon ou un script de logon est plus adaptée. Start a program on connection ne gère qu’un seul exécutable et remplace le Bureau.
  • Proposer une application isolée tout en conservant un Bureau : envisagez RemoteApp. L’application est publiée via RDS sans remplacer l’environnement de session complet.
  • Population mixte (certaines personnes avec un Bureau, d’autres avec une app unique) : utilisez le filtrage de sécurité de la GPO, des groupes dédiés et/ou des filtres WMI pour cibler les utilisateurs/ordinateurs.

Bonnes pratiques pour la fiabilité et la sécurité

  • Documentez l’ordre de traitement des GPO : Site > Domaine > OU ; gardez la GPO de publication d’application proche de l’OU des serveurs RDS.
  • Consolidez le paramétrage en Computer Configuration : Not Configured si vous pilotez via User, ou au contraire dupliquez à l’identique.
  • Validez les droits NTFS et la présence de toutes les dépendances de l’application (fichiers de conf, DLL, licences).
  • Sur un environnement de production, prévoyez les CAL RDS adéquates et un serveur de licences RDS si vous servez des connexions utilisateurs régulières.
  • Mettez en place une surveillance : journaux RDS et alertes sur les erreurs de démarrage de shell.

Exemples concrets de configuration

Calculatrice (scénario de test)

Program path and file name : C:\Windows\System32\calc.exe
Working directory         : C:\Windows\System32
Always show desktop       : Disabled

Bloc‑notes

Program path and file name : C:\Windows\System32\notepad.exe
Working directory         : C:\Windows\System32

Application tierce installée

Program path and file name : C:\Program Files\Éditeur\App\App.exe
Working directory         : C:\Program Files\Éditeur\App
Arguments éventuels       : configurez‑les côté raccourci ou via un script de lancement .cmd

Check‑list de validation

  • RDSH est installé et opérationnel.
  • Aucun paramètre contradictoire côté Computer.
  • Always show desktop on connection désactivé si application unique.
  • Chemin complet et répertoire de travail valides.
  • gpupdate /force exécuté et nouvelle session RDP ouverte avec l’utilisateur cible.
  • RSOP et gpresult confirment l’application.
  • Journaux RDS sans erreur bloquante.

Résultat obtenu après correction

Après alignement des paramètres côté Computer Configuration, désactivation de Always show desktop on connection et renseignement du chemin complet (C:\Windows\System32\calc.exe), la Calculatrice s’ouvre désormais automatiquement pour les comptes locaux lors de la connexion RDP. Lorsque l’utilisateur ferme l’application, la session se termine immédiatement, comme prévu.

Foire aux questions

Peut‑on démarrer plusieurs programmes ?
Non. Cette stratégie remplace la shell par un seul exécutable. Utilisez Run these programs at user logon ou un script si plusieurs programmes sont nécessaires.

Peut‑on utiliser un script .cmd/.ps1 ?
Oui, en pointant Program path vers C:\Windows\System32\cmd.exe et en passant /c chemin\script.cmd comme arguments. Pour PowerShell, préférez un .cmd lanceur afin d’éviter les politiques d’exécution restrictives.

Faut‑il un serveur de licences RDS ?
Pour un usage de production avec des utilisateurs, oui, des CAL RDS sont requises. Pour l’administration (sessions limitées), les règles diffèrent ; vérifiez votre conformité avant déploiement.

Pourquoi cela fonctionnait‑il sur 2012 et plus sur 2022 ?
Les contrôles et dépendances RDS sont aujourd’hui plus stricts. Des paramètres Computer contradictoires ou l’absence de RDSH se traduisent plus directement par un retour au Bureau.

Conclusion

Le non‑lancement d’un programme RDP sous Windows Server 2022 est rarement un mystère : dans la majorité des cas, l’absence ou la mauvaise configuration du rôle RDSH, une stratégie Computer en conflit, ou un chemin inexact en sont la cause. En appliquant la procédure ci‑dessus — installation/vérification RDSH, unification des stratégies, désactivation d’Always show desktop, chemin complet et gpupdate — vous obtenez un démarrage fiable et conforme aux attentes, y compris pour des comptes locaux.


Notes complémentaires

  • Cette stratégie remplace le Bureau. Pour démarrer plusieurs programmes, utilisez Run these programs at user logon ou un script de logon.
  • Si vous devez proposer une application isolée tout en conservant un Bureau complet pour d’autres usages, privilégiez RemoteApp plutôt qu’un exécutable unique imposé.

Mémo express :

RDSH installé           : Oui
Start program (User)    : Enabled
Start program (Computer): Not Configured (ou identique)
Always show desktop     : Disabled
Program path            : C:\Windows\System32\calc.exe
Working directory       : C:\Windows\System32
Mise à jour GPO         : gpupdate /force
Test                    : nouvelle session RDP avec le compte local
Sommaire