Start program on computer startup when nobody is logged on and show the window when someone does log on (OS: Windows)

I have a program that is launched on system startup using Task Scheduler on Windows Server 2012. The program must start even if the computer reboots automatially.

Administrator is the account used to start the program, the option "Run whether user is logged on or not" is checked for the task.

The problem with this is that when someone finally does log on as Administrator using Remote Desktop Connection the interface (program window) is hidden.

As I understand there is no way to solve this using Task Scheduler.

How can I solve this?

It should be a fairly common problem but I can't find anything by searching the net. I'm pretty surprised that Microsoft allow such a limitation in their scheduler. Can I make a VBScript or something that runs on startup and launches the program which will then be visible when the user actually logs on?

Other ideas?

(I don't want to have to make a separate GUI-only program that connects to the original program by the way. I would also prefer it if I don't have to terminate the already-running program upon user logon and then launch it again.)

Figured out how to do it myself. It's somewhat of a workaround but that's what I expected to get.

• Alright, first step is to grab a program called AutoLogon.exe from Microsoft:
  http://technet.microsoft.com/sv-se/sysinternals/bb963905.aspx

Stop! Don't cringe just yet. Read on...

• Run it, set it so that Administrator should log on automatically.

• Create a task in Task Scheduler. Set it to run only when user (Administrator) is logged on. Trigger is "at log on" and specify that it's only when Administrator logs on.

• Create a second task. Run only when user is logged on, trigger at admin log on. Action should be "start a program" and program is "C:\Windows\System32\rundll32.exe" with the argument field set to "user32.dll, LockWorkStation".

What happens now if you restart the computer is that Administrator automatically logs on, the program you want to start is started and the work station becomes locked. If I log in via Remote Desktop Connection I can see the program window and use the GUI. I can lock/unlock the computer with no problem and disconnect/reconnect as I please. There's no issue if I go to the server and log in at the actual workstation either. Since Administrator is already signed in the task will not run again (it doesn't create some infinite log-in-lock-loop that you can't break out of).

Simple as that. Granted there is a one second time period before the computer becomes locked after the auto login and I guess a pro hacker with physical access to the computer could do something sneaky during this time window but in my case I can overlook that security risk. As long as I don't let any pro hackers into my home and show them the computer the system should be relatively safe. Above all there isn't that much of value on the computer that needs super-vault protection so I'm quite happy with this solution.

I have a program that is launched on system startup using Task Scheduler on Windows Server 2012. The program must start even if the computer reboots automatially.

Then why do you not make it a system service, as the windows specs define?

How can I solve this?

You can not. Background programs are not supposed to interact with the UI. Or: the UI should run it's own program that then connects to the service. The UI running in the user space of the logged in user does the presentation, the windows service does the processing. This is how the model is designed for maybe 15 years or so.

I'm pretty surprised that Microsoft allow such a limitation in their scheduler.

I am more surprised you never botthered to ask why.

There are multiple issues:

• When multiple people are logged in, who gets the UI?
• When the user logs out, you kill the program? OUCH.
• Security. The background program may run under limited rights - exposing the UI to the user means the user can execute code there. THe windows messaging model is - ah - full with issues.

I don't want to have to make a separate GUI-only program that connects to the original program by the way.

Neither me nor Microsoft cares at this point what you like to do. There is an established and supported model to tie background processing into a logged in user UI - use it, or not. But when not, do not compllain about security issues you put up.