1

I know how to automaticaly open a console session when a Windows host boots (recommanded way is to use an encrypted password: https://docs.microsoft.com/en-us/sysinternals/downloads/autologon).
This is usefull when a server run an ill-written program which need a GUI to be run, while it should run as services, or at least in the background.

Once the session is open, the screen can be locked and the program continue to work. An administrator can even RDP with another session (this also lock the console session). Until now I saw no exception to this.

This method lead to several problems. Some of the biggests:

  • a session is wide open on the console. Anyone in front of the server has full access to this session, or anything hitting the unmonitored keybord/mouse can lead to desaster. We can mitigate this with a short screen timeout
  • only one session can be opened in this way. So when we need it for 2 different and non-cohabiting programs, we are screwed

 

I'd like to open several non-console sessions automaticaly when the server boots. As if several remote desktop sessions where opened then disconnected. The incriminated programs can then run with a GUI in separate sessions.
--> any idea how to achieve that?

Gregory MOUSSAT
  • 1,737
  • 2
  • 25
  • 48
  • What program its ? as its badly coded to need the gui for a service. – yagmoth555 Aug 18 '17 at 12:58
  • Have you tried to run it through srv2any? I experienced good success rate with it in such cases. – Marco Aug 20 '17 at 13:22
  • 1
    Honestly, if you have to jump through these kinds of hoops to get an application to run as a "service", I'd never install it onto bare metal anyway, only into a VM. And with a VM you don't have these problems (one interactive session per VM is enough, and nobody will see the virtual screen either): – mihi Aug 20 '17 at 17:34

2 Answers2

2

mstsc.exe can run without GUI, which is usually useless but very helpfull in this case.
You can create a scheduled task fired when the computer starts.
This task will launch as many remote desktop sessions you want, then kill them, leaving the sessions alive and disconnected.

I personnaly use a batch (.cmd) called by the scheduled task:

start c:\windows\system32\mstsc.exe "c:\path\do_it.rdp"
timeout /nobreak /t 60
taskkill /f /im mstsc.exe

I have a more sophisticated way to kill mstsc.exe which is specific to my needs, so I just put a basic taskkill for the example.

Bernad MAVISSU
  • 539
  • 3
  • 7
1

To achieve exactly what you've asked you'll need at least one Linux with GUI or Windows Server to put a script on.

In linux/bash I'd script a ping monitoring script that runs a command after what would probably be a reboot of the server (ping down for a while). The command would be a script running twice an rdp client in background with preacceppted certs and valid stored credentials (one for each connection) to the server object of your question. I would then end the script with a 

sleep 60 && killall -9 rdpclientname

(as killing the rdp client won't terminate the remote sessions which is part of what you want to achieve).

I'm sure you can easily do such in a Windows batch instead of bash if you might want to use Windows as client. Just I'm not sure if you can establish multiple connections from the same Windows client to the same Windows server. At a very minimum you'll have to use two different users running the script twice, I think. If you can't you'll have to put such scripts on two different Windows clients machines.

If you opt to go on a Windows client, the binary called by your second script activated by the ping monitoring script will be mstsc.exe and will have the full path to the rdp-for-your-server-saved-session.rdp, containing preaccpeted certs, and valid credentials.

On the Windows client you may use srv2any to run mstsc and scripts would just start and stop the two services. On win you'll use task scheduler, in Linux, crontab.

In order for this to work as you want, you'll have to disable auto login on the Windows server. You may then achieve a delayed local login following this.

This solution has of course a percentage of failures where the downtime observed by the ping monitoring script will not be due to a server reboot. But the two automated unwanted logins won't hurt too much in this case.

You'll have to work and test hard in order to achieve such. That's why the following... I'd try any other thing possible before building such an arrangement!

In any case, as I suggested in my comment to your question, I'd try just to start the badly coded program through srv2any on the server. You didn't mention this attempt in your question. Have you tried it?

Marco
  • 1,679
  • 3
  • 17
  • 31