1

I have a machine that will be deployed at a customer's location. The machine will be headless and only be accessed via RDC. (Unless there is a catastrophe.) There is a piece of software that must run at all times to log data from connected sensors. The software only works when it runs in the "foreground". That is to say that if I have it start up as a task using the "Run whether user is logged on or not" I can see in in the Task Manager, but no data gets logged. If I kill it and run the task via Task Scheduler, it still doesn't log data. If I kill it and start it via it's pinned task bar icon, it works.

How do I get this software to run on boot**? I want to do it such that when I RDC in using a username and password, I see the application. However, if someone were to plug in keyboard and mouse, the computer would NOT be unlocked.

** I have the machine's BIOS set to boot automatically after power failure.

3
  • 1
    Setup auto login, start the task and lock the desktop or make the application run-able in the background/as a task. The first solution is obviously going to be a security risk as someone might reboot and use the small time window before locking to do something.
    – Seth
    Commented Dec 7, 2016 at 7:00
  • This operating system is really so weak that the only option is to unlock the local environment? Surely not. Commented Dec 7, 2016 at 14:07
  • You're not able to use an application that is meant to be run without an user interface or change the application accordingly? Chances are that an application that is required to be run as an interactive application isn't meant to be run as a service.
    – Seth
    Commented Dec 7, 2016 at 14:58

2 Answers 2

2

Use psexec run from a scheduled task. There is a "When the system starts" option in task scheduler. Configure it to run:

psexec -u USERNAME -p PASSWORD -i 0 -d c:\path\to\program.exe

-i 0 tells it to run in session 0, which starting in 2008 is the console session.

2
  • Upvoting because this worked for one of the tasks, but not for the actual (exceptionally challenging) task I created this question for. Commented Dec 8, 2016 at 16:48
  • Session 0 is NOT the user space, not accessible to a logged-on user and NOT foreground. Session 0 is background
    – Dr.Ping
    Commented Dec 9, 2016 at 5:05
0

I ended up solving this with the excellent (if confusingly documented) nssm - the Non-Sucking Service Manager

I'm not a Windows admin, so I lean towards making everything Unix friendly. Hopefully this is more helpful than it is confusing. Here is how I solved this (and documented it for my future self).

  1. Install choco because it's as close as you get to apt or brew for Windows.
  2. Install cygwin because we're going to be using BASH.

    choco install --yes cygwin
    
  3. Install nssm

    choco install --yes nssm
    
  4. Save the following into a script I'll call create_service.sh

    name='Phone Home'
    command='C:\Program Files\Python35\python.exe'
    arguments='phone_home.py -p 3389'
    start_in='C:\Users\ET\Dropbox\src\' # Edit this shared code have it sync'd via Dropbox FTW!
    domain='.'
    username='ET'
    password='Use SSH and reverse port forwarding!'
    description='Launch Phone Home script at startup for real, not at log on. (Because this machine is headless, and how are you supposed to log in before it phones home?)'
    display_name="00 $name" # make it sort to the top in Services
    
    nssm stop    "$name"
    nssm remove  "$name" confirm
    nssm install "$name" "$command"   $arguments
    nssm set     "$name" AppDirectory "$start_in"
    nssm set     "$name" DisplayName  "$display_name"
    nssm set     "$name" ObjectName   "$domain\\$username" "$password"
    nssm set     "$name" Description  "$description"
    nssm start   "$name"
    
  5. "Install" a Windows service via the nssm API just by calling the script.

    source create_service.sh
    

NOTE:

The nssm stop and nssm remove commands will fail the first time, but I put them in there so you can rerun the script to make changes to your service.

This all hints to a very complex system of remote code execution and ssh proxying of Microsoft Remote Desktop. That's a lesson for another day.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .