Scheduled task works interactively but fails when scheduled
Documentation: Microsoft Learn
Work the problem
The scheduled report is missing
Fictional case: The script reads .\input.csv and writes to a mapped Z: drive. It works in your console but runs under a service account in Task Scheduler.
Reasoning notebook
Record the evidence that supports your answer and the check you would run next. Your notes stay in this browser — nothing is uploaded.
Why it happens
A task runs under the identity configured on it rather than the one that created it, so anything depending on the interactive user's mapped drives, stored credentials, or profile module paths is simply absent. The working directory defaults to the system directory instead of the script's folder, which breaks every relative path in it. An account that has never signed in interactively has no profile for the script to fall back on.
Check this first
What to look for
Relative paths and mapped drives depend on execution context. Capture the actual task context and use accessible explicit paths.
Diagnose before fixing
It works in your terminal but fails in Task Scheduler. What changed?
Choose the strongest first hypothesis for this symptom.
Genie: pick a hypothesis, then compare the two environments.
Interactive session
- User: your admin account
- Working dir: project folder
- Mapped drive: Z:
- Profile modules loaded
Scheduled task
- User: configured task identity
- Working dir: often system directory
- Mapped drive: usually absent
- Profile may not load
Smallest useful check: log $env:USERNAME, (Get-Location).Path, $PSModulePath and the exact file path before the failing line.
Working through it
- Read the result code from Get-ScheduledTaskInfo -TaskName $Task and translate it before assuming a cause.
- Run schtasks /query /tn $Task /fo LIST /v and check the Run As User together with the Start In value.
- Replace relative paths in the script with absolute ones, or set Start In on the task action.
- Add Start-Transcript writing to a fixed path so the next failed run leaves evidence behind it.
- Test under the task's own identity rather than yours, either with a one-off scheduled run or with a tool that launches a process as that account.
Avoiding it next time
Verify the repair: Run through Task Scheduler under its configured identity and verify a new output file with the expected contents.
Primary documentation
Work through the incident
Investigate a scheduled report
The report succeeds in your interactive shell but produces no CSV overnight.
The sandbox is visible now. Sign in with Google only when you run or check a task; commands and temporary files are discarded when you leave.
Run a command to inspect its result.