My organization is running a Terminal Server Farm in order to provide a specific application to the users. The setup consists of a AD domain controller plus two Terminal Servers running the Remote Desktop Services. All servers are running Windows Server 2008 R2 Standard.

The users are outside our organization, thus the client configuration is outside our scope. We will only provide them with a RDP connection file and a username which is stored in the AD. In the RDP file, we configured "Start the following program on connection" = C:\path\to\batchscript.bat. When a user connects, the batch script does some cleanup and configuration stuff and then launches the actual application. The user does his work and closes the application afterwards. When the application is closed, the user is being logged out, and the RDP session is ended.

This setup worked fine until the first user upgraded to Windows 10. Apparently, in Windows 10 the option "Start the following program on connection" was removed from mstsc.exe, leaving the user back with the Terminal Server's desktop instead of launching our batch script.

To prevent this, I set up the following GPO: User Configuration \ Admin Templates \ System \ Logon \ Run these programs at logon = C:\path\to\batchscript.bat. As far as I understood, this should override the client's "Start the following program on connection" setting. In fact, the batch script runs and launches the application. Everything behaves as expected, except that the user won't be logged out when the application is closed, leaving him with a completely empty desktop screen.

Apparently, the GPO "Run these programs at logon" does not correspond to the mstsc.exe setting "Start the following program on connection".

What's the difference between these two? Is there another GPO which does exactly the same as the mstsc.exe setting?


Each new connection to an RDS session is not necessarily a new logon. Users will often reconnect to an existing session.

You can get close by configuring sessions to log off after a certain amount of time in a disconnected state, but this has lots of ramifications depending on what you are trying to accomplish with RDS.

  • What kind of ramifications are you thinking about? – abaumg Jan 26 '16 at 17:19
  • If the user has edited a db record but not actually saved it and then idles long enough to be forced out. – rjt Jan 26 '16 at 18:13
  • Yeah, a specific example from my own experience is Great Plains. Some workflows in that client could take 10-15 minutes, and users would often disconnect their RDS session for a number of reasons. GP was infamously bad at keeping session state healthy in this scenario. – blaughw Jan 26 '16 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.