I have Windows Server 2003, with schedules setup via Remote Desktop under one account. That account appears in the 'creator' column too. I have 'Run only if logged on' unticked.

When I have logged in under that account and then 'disconnected' leaving the the session alive, the schedule runs. But every time the server is rebooted, the task again fails to run until I again log in and disconnect.

Any KB fixes I've missed or issues I've overlooked? Normally I only discover the issue when a user tells me the schedule has stopped running so it's a real reliability issue.

I'd also be happy with an answer suggesting an alternative scheduler with higher reliability.

Thanks

link|improve this question
Does it fail to run, or run and then fail? What's the Last Run Result code reported by the Task Scheduler after it attempts to run while you're not logged in? – techie007 Jan 18 at 0:59
It says 0x0 (success) normally. In fact, when I try to run it from the other account I use, it says it's run and returns 0x0 even though it hasn't executed. – Glinkot Jan 18 at 1:05
We need more information about the rest of the sheduled task. For instance, have you set it to run at highest privileges? Did you tell it to run when only certain parameters are true? Have you deleted and recreated the task with the same outcomes? – Randolph West Jan 18 at 5:05
Hi. Both the accounts are localadmin accounts. I'm not aware of a setting to run the task itself at a different privelege level - if so where is it and I'll have a look. I have this issue with several tasks, some of which I've recreated with the same result unfortunately. – Glinkot Jan 19 at 22:01
I added an edit to my answer. The facts in your question and comments seem contradictory. – surfasb Jan 20 at 0:42
show 1 more comment
feedback

1 Answer

A task that only runs correctly when a user is logged in sounds like a permissions issue. What does the task exactly do?

Does the task run correctly if the user account is left logged in at a console or remote session and then the task is started remotely under a different remote session?

edit

I want to verify this. The facts in your question and your comments seem contradictory.

So if I understand the situation correctly, the Task was created under "Admin2". If you log into that account, whether it be remotely or at the console, the task will start while you are logged in.

The task refuses to run correctly (it returns 0x0 even though the results are undesired) at system startup.

Nor will it run correct if you log in under "Admin1".

But then you say:

It says 0x0 (success) normally. In fact, when I try to run it from the other account I use, it says it's run and returns 0x0 even though it hasn't executed.

The other account seems contradictory. You've mentioned only two accounts with local admin privs. At first, in the question you state the task does work on the other account, if you login remotely. Then in the comments you say it doesn't work. This seems confusing.

link|improve this answer
Hi, the task just runs a .bat file which in turn runs an .exe file. No, if it is run under another remote session it doesn't work even if the other user is logged in. :( Good to see we have an IT/singing expert on board! – Glinkot Jan 19 at 22:06
@Glinkot: Strange. What does the exe do? – surfasb Jan 20 at 0:33
Hi. Re your edit: I didn't say it works from the second account. For clarify, let's say the account it's setup under is called 'automate' (which it is!) and the second mfoley (which it is!). Logging in remotely as automate and manually running it, works. Logging in as automate, then disconnecting, leaves the schedule running. Running manually from mfoley account returns 0x0 but doesn't actually execute. Restarting causes the schedules to no longer run, until I have logged into RDP as automate and disconnected again. The exe copies/encrypts files, from folders both accounts can access. – Glinkot Jan 20 at 1:18
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.