Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

[NOTE: I posted this originally at StackOverflow but it got no traction there - reposting here.]

We have a bit of software installed at a few client locations that runs (via Windows task scheduler) a few times each day.

In ONLY ONE of the client locations, we have a unique problem: each month, the task will stop working, after running every day for weeks. Twice now it's failed on the 2nd of the month. When I walk the client through troubleshooting it, we've found that it can't start - access denied.

To fix it, we edit the scheduled task itself, and re-enter the same exact password - then off it goes happy as a clam.

I've never heard of this issue, and their IT people say they don't have anything running once a month that might cause that.

I'm at a complete loss here. Any ideas as to why this might be happening?

Further details:

Windows XP pro machine. Task is being fired with credentials from a local admin account. Computer is always on, and connected to the net.

share|improve this question
It's been one month tomorrow - have you had the chance to try Evan's suggestion about scrutinizing the actual .job file? – mfinni Mar 17 '11 at 0:56
up vote 1 down vote accepted

When you say "we simply re-enter the same exact password" I think you're really saying "We reset the password on the account using the same password". I don't think you're saying that you're changing the password stored in the "Scheduled Task" entry.

If that's correct it sounds to me like the account's password is expiring. By resetting the password you're resetting the expiration countdown, too.

If the account is an account on the local machine where the task is running using "Local Users and Groups" to mark the account as "Password never expires". If the account is a domain account you'll need to make that change in the Active Directory.

Examining the security policy (either on the local machine or the "Domain Security Policy", depending on where the account is located) is going to tell you what the password expiration policy is like. It seems the most likely explanation that password expiration is the cause of your issue.


Per your comment and edit it sounds like my "psychic powers" have failed me on this one.

I think I'd fall back to making a copy of the ".job" file from the %SystemRoot%\Tasks directory that corresponds to the problematic task and using a file compare utility when the problem crops up to see if the task definition file is actually changing. If it is, then auditing filesystem access to the file may be able to pinpoint the cause of the change.

If the file isn't changing then you've got me stumped!

share|improve this answer
No I'm sorry - I'm saying that we literally edit the scheduled task, and re-enter the password. After that, it works fine. – Ducain Feb 17 '11 at 16:21
@Ducain: Oh, well... My psychic powers fail on this one. I'll drop on an edit with an idea, but it's weak at best. – Evan Anderson Feb 17 '11 at 17:20
I'd still look at password expiration. – Joel Coel Feb 17 '11 at 17:26
I'll have their IT people take a look at the file expiration just to be safe, but it doesn't make sense to me that it could be the cause of that issue, since simply editing the task itself fixes it. – Ducain Feb 17 '11 at 18:29
thanks, I actually didn't know about the .job files - I'll pass this info on and see if we can take a look at that. – Ducain Feb 17 '11 at 18:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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