0

I need to create a scheduled task on the command line that runs a script as local administrator. One thing that this script does is run an installer as a specific domain user (that is already local admin on this machine). This scheduled task needs to be run on startup, without requiring the user to log on. Note this is on Windows Server 2012.

The problem is that using "schtasks /create /RU administrator /RP " to do so does not work as expected.

It creates the scheduled task as expected, but when it runs the scheduled task it fails to run the installer as the domain user, and logs in the eventvwr system log " Application Error : The application was unable to start correctly (0xc0000142). Click OK to close the application. ".

I can recreate the problem by making a scheduled task on the command line with "/RU administrator /RP " that runs a Powershell script, which starts notepad with different credentials.

This fails. But if I create the scheduled task without specifying "/RU administrator" it works (if I run cmd.exe as local administrator).

However this won't work for me as if you don't specify a user with "/RU" then you cannot set the scheduled task to "run whether user is logged in or not".

There seems to be a fundamental difference when creating a scheduled task using schtasks between "/RU administrator" vs not passing "RU" but running cmd.exe as administrator.

Any way around this?

Timje
  • 740
  • 9
  • 12
  • Launching a process as another user from a non-interactive context is tricky, see for example http://stackoverflow.com/q/20256665/886887 ; I'm not sure it can be done from Powershell. Any chance you could rearchitecture to schedule the task as the target domain user? Or get the run-as-administrator-script to schedule a new task as the domain user? – Harry Johnston Jan 30 '14 at 00:58
  • Alternatively, the script could use the `psexec` tool to launch the installer. You can download `psexec` from the MS web site. This does require certain services to be running, e.g., file sharing. – Harry Johnston Jan 30 '14 at 00:59
  • Thanks for the suggestions Harry, both sound like viable options. I was trying to avoid running the scheduled task as the target domain user, as this is actually one step amongst many - and there are likely to be more target users for more steps. My current solution is to run the "script" via a Windows Service, and the Windows service runs as local administrator. This required giving the local admin "log on as a service" group policy rights. psexec is a good idea too but unfortunately on this project its use is banned by the powers that be. – Timje Jan 30 '14 at 10:31

1 Answers1

0

Try adding /RL Highest That worked for me

Tempesta5300
  • 1