Creating a Scheduled task with a named account is a fun thing to do.
You get to do all sorts of wonderful things.
Including paying attention to this KB and the associated implications
http://support.microsoft.com/?id=867466
When your Scheduled task is a batch file, that account HAS to have READ & EXECUTE access to the CMD.EXE file in %SYSTEMROOT%\SYSTEM32
If you don't you get a wonderfully non-descript error of 0x80070005: Access is denied. This shows up in Task Scheduler as "Cannot start task"
Anyway - the problem is solved by adding an Access Control Entry (ACE) to the Access Control List (ACL) to the file for a well known security ID. Which one?
The one I needed was...
SID: S-1-5-3
Name: Batch
Description: A group that includes all users that have logged on through a batch queue facility. Membership is controlled by the operating system.
I was trying to setup a scheduled task using a domain user. Thusly, they have to have the ability to login as a batch, which should be setup automagically when creating the job. They're not logged on Interactively (the console), and they're not running as a service (services.msc). We're definately not running under telnet, and that user shouldn't be an administrator for obvious reasons. That leaves us with the final solution.
Also, if the scheduled task is a batch file, that user has to have access to the CMD.EXE file in %SYSTEMROOT%\SYSTEM32\
On windows 2003 server by default, that file has the ACL
BUILTIN\Administrators:F
NT AUTHORITY\INTERACTIVE:R
NT AUTHORITY\SERVICE:R
NT AUTHORITY\SYSTEM:F
SERVERNAME\TelnetClients:R
I needed to have an ACE for
NT AUTHORITY\BATCH:R
in that list for my task to work