dtview
asked on
Scheduled tasks do not run, log shows "the scheduled task did not run because an incorrect password or user name was used".
I am using a Windows 2003 to schedule multiple backup jobs (using ntbackup). There are more than 10 backup jobs, and 3 jobs running per night. I scheduled those jobs in 1 shot (task scheduler wizard), using the a local admin account (set to run as using the same admin account). A week later I came back to check. Some did run, some did not. Those that did not run showed "the scheduled task did not run because an incorrect password or user name was used" in the task scheduler transaction log. For example, I may be scheduling a full backup on our accounts database, differential backup of artwork files, and full backup of document folders. The next day I may find the documents and accounts db backed up but not the artwork file differential backup. Then yet the following day only the accounts db backup completed successfully.
I opened the property of the tasks that did not run to reset the run as account, since password seems to be the issue the log was pointing at. A few days later I came back to find again some tasks did run, some did not. Another funny thing is that some of the tasks that did run the previous week did not run the 2nd week, even though I did not touch them. Some jobs stubbornly refused to start, their last status forever stuck with "Never" no matter how I reset the password.
I am backing up to hard disk (customer is averse to tapes). I keep the account logged on to the console of the server all the time.
I did manually test out on 1 or 2 tasks, by choosing to run now. I also tried scheduling it to a time so I can watch it happen. They all worked under my eyes. But I can't get rid of the nagging feeling that the OS "forgets" the password behind my back (the account is a local admin account and it has a proper password). Some of the jobs, I had re-entered the password so many times -- I can't be typing the wrong password everytime! I googled on this issue before. It appears there are other people that ran into similar annoyances working on WindowsXP, but no solution / explanation was offered.
I have taken the time to convert all these backup tasks into batch files, and am considering using AT to schedule them instead. But it strikes me that if AT also does not work, I may not even have a log to reference for troubleshooting. Next Tuesday I will check on the jobs again and decide what to do next.
Much appreciation for your kind recommendations.
DTVIEW
I opened the property of the tasks that did not run to reset the run as account, since password seems to be the issue the log was pointing at. A few days later I came back to find again some tasks did run, some did not. Another funny thing is that some of the tasks that did run the previous week did not run the 2nd week, even though I did not touch them. Some jobs stubbornly refused to start, their last status forever stuck with "Never" no matter how I reset the password.
I am backing up to hard disk (customer is averse to tapes). I keep the account logged on to the console of the server all the time.
I did manually test out on 1 or 2 tasks, by choosing to run now. I also tried scheduling it to a time so I can watch it happen. They all worked under my eyes. But I can't get rid of the nagging feeling that the OS "forgets" the password behind my back (the account is a local admin account and it has a proper password). Some of the jobs, I had re-entered the password so many times -- I can't be typing the wrong password everytime! I googled on this issue before. It appears there are other people that ran into similar annoyances working on WindowsXP, but no solution / explanation was offered.
I have taken the time to convert all these backup tasks into batch files, and am considering using AT to schedule them instead. But it strikes me that if AT also does not work, I may not even have a log to reference for troubleshooting. Next Tuesday I will check on the jobs again and decide what to do next.
Much appreciation for your kind recommendations.
DTVIEW
In Control Panel, Scheduled Tasks clcik advanced, then set the At service account as a domain admin account. Make sure it has "run as a service" rights...
ASKER
My trip to the customer's place has been delayed until Wednesday. I will implement it and observe how it fares, and let you know asap. Thanks for the contribution.
dtview
dtview
ASKER
The problem has evolved.
1. Scheduled task log shows that for the past 20 days tasks had started but had completed with an exit code of (1f). That can only mean ntbackup didn't run because the duration from start to completion is only 2-3 seconds.
2. The NTbackup log (summary only) says "The saved selection file "Backup.bks" cannot be found." This applies to every single ntbackup task. The same messages were found in Event log (application).
3. I randomly picked out a job and chose "Run". Nothing showed. I checked scheduled task log and it said "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." ... However, it had been able to "start" at the designated day and hour during the past 20 days, even if it didn't execute properly.
4. I went into the Properties page of that task, re-entered the password, chose "Run". This time it ran full blast. The job completed successfully! (no complaints of not being able to locate Backup.bks)
5. I checked out M$ KB 828402. It is possible that this is the cause, but why isn't it consistent (won't happen when I manually ran the job, and didn't happen 20 days ago)???
I have since configured for the log to be "full". I plan to wait until 6pm local time, and schedule a bunch of jobs to run early so I can watch them happen / not happen.
dtview
1. Scheduled task log shows that for the past 20 days tasks had started but had completed with an exit code of (1f). That can only mean ntbackup didn't run because the duration from start to completion is only 2-3 seconds.
2. The NTbackup log (summary only) says "The saved selection file "Backup.bks" cannot be found." This applies to every single ntbackup task. The same messages were found in Event log (application).
3. I randomly picked out a job and chose "Run". Nothing showed. I checked scheduled task log and it said "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." ... However, it had been able to "start" at the designated day and hour during the past 20 days, even if it didn't execute properly.
4. I went into the Properties page of that task, re-entered the password, chose "Run". This time it ran full blast. The job completed successfully! (no complaints of not being able to locate Backup.bks)
5. I checked out M$ KB 828402. It is possible that this is the cause, but why isn't it consistent (won't happen when I manually ran the job, and didn't happen 20 days ago)???
I have since configured for the log to be "full". I plan to wait until 6pm local time, and schedule a bunch of jobs to run early so I can watch them happen / not happen.
dtview
ASKER
AT is no better than task scheduler. So in the end, I went back to task scheduler and rescheduled all the tasks.
While manually running the tasks to see if account is a problem, something strange that I found:
1. Certain individual tasks, no matter how I reconfig the password, always returns with error "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." If I delete that task and recreate it, often it will immediately work.
2. Certain tasks can manually run once. When I return to try again the 2nd time, it gives me the same error as in 1. If I try to make it run again 10 seconds later (without re-key in password), it will work.
This is way too unstable. Appreciate any contributions as I really want to finish this one off.
dtview
While manually running the tasks to see if account is a problem, something strange that I found:
1. Certain individual tasks, no matter how I reconfig the password, always returns with error "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." If I delete that task and recreate it, often it will immediately work.
2. Certain tasks can manually run once. When I return to try again the 2nd time, it gives me the same error as in 1. If I try to make it run again 10 seconds later (without re-key in password), it will work.
This is way too unstable. Appreciate any contributions as I really want to finish this one off.
dtview
Ok, so what tasks are you trying to run. Post the full script or cmd file and the command line from the at command.
ASKER
Below are 2 of the scripts that runs on a daily basis:
FilesDailyDiff.bat
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
FilesSatFull.bat
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
I had set the machine to auto-logon in the event any restart occurs, and I had made sure that at auto-logon, the explorer opens to the network drives, so that disconnected network won't be the cause of backup failure.
I did not use AT after discovering AT to be just as unreliable. Right now what I often get is, for the 3 backup jobs that are supposed to be performed at night, I'd often find 2 of them succeeded, while 1 will give me "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." If I right click on that "failed" job and choose Run, it will run in front of my eyes.
I can say that all the jobs had their turn to run properly at least once... at least I don't get any one that just refuses to play a part!
In order to do these backups I have had to schedule for services to be disabled on the target servers (those that share the network drives). They are old NT 4 servers but heck, they are a lot more reliable in this regard. The start/stop service scripts scheduled to run ALWAYS run. I am seriously considering initiating these jobs from the NT4 end.
dtview
FilesDailyDiff.bat
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
FilesSatFull.bat
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
C:\WINDOWS\system32\ntback
I had set the machine to auto-logon in the event any restart occurs, and I had made sure that at auto-logon, the explorer opens to the network drives, so that disconnected network won't be the cause of backup failure.
I did not use AT after discovering AT to be just as unreliable. Right now what I often get is, for the 3 backup jobs that are supposed to be performed at night, I'd often find 2 of them succeeded, while 1 will give me "** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. Verify that the task's Run-as name and password are valid and try again." If I right click on that "failed" job and choose Run, it will run in front of my eyes.
I can say that all the jobs had their turn to run properly at least once... at least I don't get any one that just refuses to play a part!
In order to do these backups I have had to schedule for services to be disabled on the target servers (those that share the network drives). They are old NT 4 servers but heck, they are a lot more reliable in this regard. The start/stop service scripts scheduled to run ALWAYS run. I am seriously considering initiating these jobs from the NT4 end.
dtview
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, ok, I ran into some free cron software and was contemplating that also.
Since the primary aim is to get it to work, I shall use whatever way to get it to work reliably -- boot the MS task scheduler until specific problem - resolution is offered then.
Thanks and all the best to you
Since the primary aim is to get it to work, I shall use whatever way to get it to work reliably -- boot the MS task scheduler until specific problem - resolution is offered then.
Thanks and all the best to you