23

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.)

Marcus
  • 617
  • 2
  • 6
  • 8
  • 2
    Firedaemon, install the app as a service, when RDPed in switch to "Session 0" using Firedaemon. See the app. – TheCleaner Mar 20 '14 at 19:42
  • This could technically be done if you develop your own service. – Ryan Ries Mar 20 '14 at 20:15
  • 1
    Just answered my own question. I can't accept my own answer for two days however, because the system here at serverfault.com is extremely bad (most people would now just abandon this page without waiting two days and leave the question forever marked as unsolved). – Marcus Mar 20 '14 at 23:41
  • 2
    @Marcus: The limits on who can do what and when are intended to stop certain abuses. Unfortunately they do sometimes cause inconvenience for genuine attempts to do things right, but sometimes such compromises need to be made. If you have a suggestion that might improve the situation (protecting the site at least as well but inconveniencing genuine users less) it would be a better idea to raise the thought via a relevant "meta" site (http://meta.serverfault.com/, http://meta.stackoverflow.com/) instead of complaining in a comment that the site runners are very unlikely to see. – David Spillett Mar 21 '14 at 10:38
  • As you can see from the voting, the answer you want to accept isn't the one that people approve of because the way you are trying to go about this is wrong to start with. – JamesRyan Mar 21 '14 at 11:16

3 Answers3

31

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

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.

Marcus
  • 617
  • 2
  • 6
  • 8
  • 7
    No disrespect (or downvote), Marcus. But if this is really the type of answer you were looking for, this question would've been more appropriate for [SuperUser](http://superuser.com). – Ryan Bolger Mar 21 '14 at 04:15
  • 2
    It wasn't easy to decide on what stack exchange to post this. – Marcus Mar 21 '14 at 12:19
  • Hi Marcus, I followed your answer but I have a problem launching two programs with GUI instead of just one. I have posted a question in `SuperUser`. If you could answer it there it will be a great help - http://superuser.com/questions/902386/scheduling-a-gui-program-task-and-showing-its-gui-at-login – izac89 Apr 16 '15 at 15:10
  • 1
    Actually downvoting that now too because it is NOT an answer to the question. The question explicitly defines noon being logged in - and your "solution" here makes an automatic login (so someone IS logged in). Maybe not smart fomulation in the question, but the question is as it is. – TomTom Jul 24 '15 at 07:49
  • What exactly does the first task? It's triggered by admin logon and...what? – EvAlex Sep 29 '15 at 06:35
  • 1
    @TomTom As an option presented to an end-user "Run whether user is logged on or not" could certainly mean "You won't have to be here to babysit to make sure it starts." – Aryeh Leib Taurog Mar 17 '16 at 12:22
17

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.

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • 3
    Amen. I wish more app vendors grasped this concept. – Ryan Bolger Mar 20 '14 at 19:47
  • 16
    Wow aren't you snooty in your attitude. Well, guess I'm out of luck. Unless you're misinformed and someone has some way to solve this, everybody can't know everything so you might be wrong with the absolute "you can not" part of your post. I'd like to leave the question open for more answers for a while longer, just in case anybody has a uncommon workaround to share. Else I'll accept your answer. – Marcus Mar 20 '14 at 20:22
  • It's actually increasingly difficult to give a UI to a service nowadays on current versions of Windows, but not impossible. – MDMoore313 Mar 20 '14 at 20:37
  • It is actively not wanted because mostly of security concerns. THe main problem here is that - and you really need to get that - if you show a window in my UI, I can execute code in your process. I can then send you windows messages and that has a TON of stuff that can be exploited. Normally not a problem - because if it is a user app, I can only do things that I as a user could.... but if the service has higher priviledges, here goes the security nightmare. THis is why this was closed many many years ago and everyone who learned programming and read the documentation should have read about it – TomTom Mar 20 '14 at 21:04
  • 1
    If you really want to go there, you could try the steps in http://www.coretechnologies.com/WindowsServices/FAQ.html#GUIServices - not sure they still work in current windows but there are ways to make the UI accessbile - and open all the security issues. – TomTom Mar 20 '14 at 21:06
0

It's all about the Session that your program runs in. If no one is logged in, there's no interactive session to display under, I believe it runs under Session 0, which has a weird UI that doesn't show up like the others.

Now, if your program detects when explorer.exe launches (or some other way to detect user login) and magically remorphed itself or spawned some child process on that new sessionid, then anyone who logs in will happily see what you're doing.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73