[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.
Best Answer
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.
Edit:
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!