1

i have a powershell script which creates scheduled tasks as a part of automation process and my syntax is following;

schtasks /create /s ServerName /u $username /p $password /ru $username /rp $password /sc once /sd $StartDate /st $StartTime /tn $taskname /tr "\\ServerName\c$\$TaskName\$Taskname.bat"

The tasks gets created succesfully, but when the execution time comes, it allways fails with error (0X1).

If i run batch file individually it runs perfectly; so my schedule task is created wrong.

Then i found it works when i provide it the "start-in" directory path.

My question is why should i provide a start in path when clearly it says "Optional" in the task's properties?

My other question is how to provide the start in path? Tried lot of ways , everything fails, is there no automated way to do that? should i update every task manually?

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
Darktux
  • 827
  • 5
  • 21
  • 36

2 Answers2

4

My question is why should i provide a start in path when clearly it says "Optional" in the task's properties?

Let's say for instance that I am creating a scheduled task that will run a Powershell script:

enter image description here

Why is this wrong? Well first, we're not sure if powershell.exe will resolve correctly because we don't know if the user who executes the scheduled task has his or her PATH environment variables set up correctly. Depending on who you set the task to run as, be it System, or a domain user, their PATH variables will be different. Sometimes it works, and powershell.exe is launched properly, but why not go ahead and take the guesswork out of it and specify a fully qualified path name the powershell.exe executable.

Secondly, script.ps1 is where? You didn't specify. Powershell is going to launch and its startup directory will be %WINDIR%\System32. Unless that is where you stored your script (and I hope it's not,) Powershell will not be able to find it.

enter image description here

This is better now that we've given fully qualified pathnames to both the executable and the script. But we still haven't gotten to what "Start in (optional)" is for. Well hang on, we're getting there.

The contents of script.ps1 is thus:

"Hello world!" | Out-File test.txt

So if I were to run the above scheduled task now, which launches Powershell, which runs script.ps1, where do you think test.txt will be written?

If you guessed %WINDIR%\System32, then you get a cookie!

If I wanted test.txt to go to C:\Scripts instead, then I would type C:\Scripts into the "Start in (optional)" field!

That's why it's optional.

I should also point out that you can also work around this by using fully qualified path names in your script to get things to go where you want them to go without having to worry about PATH variables and working directories.

Now on to the second question.

schtasks.exe does not appear to have the capability to add the "Start in" or "Working directory" of a scheduled task. Bummer.

One thing you can do is use the XML for Task Scheduler 2.0 tasks, which does let you set the working directory. Here is the XML for the test task that I created for this question:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2013-07-19T09:41:27.0446696</Date>
    <Author>DOMAIN\user</Author>
  </RegistrationInfo>
  <Triggers />
  <Principals>
    <Principal id="Author">
      <UserId>DOMAIN\user</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
      <Arguments>C:\Scripts\script.ps1</Arguments>
      <WorkingDirectory>C:\Scripts</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

You can use schtasks /XML to scriptomatically import tasks from XML files.

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • Got it , issue was with not providing the full path; got it worning now; Previously my bat file contains ".\Script.Ps1" , now i replaced it with full path. I will try the XML option too, looks intriguing. Thank you. – Darktux Jul 19 '13 at 16:53
0

I just encountered this myself. In my case the issue was due to an error in the script itself, even though the error was in a part of the script that would never have been reached during execution.

To troubleshoot the issue, you should try running the entire action as the user that is going to be running the script. For example, first open PowerShell as the target user (if not yourself):

RunAs /user:domain\serviceaccount PowerShell.exe

And then run the entire action block in PowerShell and see if it encounters any errors:

PowerShell.exe -ExecutionPolicy Bypass -File "C:\Scripts\My-Automated-Task.ps1"
jdgregson
  • 109
  • 5