
Then in the "Properties" section choose "Always use the following command-line arguments" and specily "/k c:\mypath\Test.bat" When creating RemoteApp, In the screen to select the application dont point to test.bat directly, instead point to cmd.exe

This can be achieved by creating the RemoteApp the following way. The only option is to workaround this by not terminating the original RemoteAPP i.e. When it reconnects obiviously it doesnt find the TEST.BAT running as it has already finished execution. It doesnt know or care about what you do or launch within TEST.BAT So the explanation to this behavior is same as given above, as far as RDS is concerned the remote app is your TEST.BAT that you point to when you create your remote app. I am now able to reproduce this issue with the additional information provided.
#Tinyterm enterprise app windows#
RDS server is Windows Server 2008 R2 SP1 and client is Windows 7. Is it possible to ask Windows not to start again the application? Or do you see any workaround? We really need a batch file. I guess that's because with a script, the exe which is strated by RemoteApp (in fact cmd.exe) is not the same as the final exe (the graphical application). On the opposite, if the RemoteApp program starts directly the graphical application (so without a script) and if we loose the network connection, when we reconnect the application is displayed again but another instance is NOT started (which seems normal). Reconnect, the graphical application is displayed again in correct state BUT the bat file is also recalled, so at the end we have the application started twice! If we loose the connection with the RDS server (eg.

The bat file does some processing then starts a graphical application at the end. To be more accurate, we have a RemoteApp program which actually starts a bat file. When the RemoteApp program is started within a script, there is a strange behaviour if we loose the connection and then reconnect: the application is started again, so we have the application started twice.
