Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Scheduled Task: Could Not Run

Status
Not open for further replies.

fuzzyocelot

Programmer
Jul 22, 2003
333
US
I don’t know a lot about Windows servers, but I’m desperate for ideas here so please bear with me. I’m a fairly new SQL database administrator and I don’t have a lot of experience to draw on yet. Please be patient with me. :)

The servers on which we have an issue are both Windows Server 2003 Enterprise Edition SP2. Both these servers are dedicated to SQL Server 2000. I tried to search for this problem under this forum but it kept returning no results. So I apologize if this has been addressed before. If it has, please refer me to the appropriate thread. :)

We have two visual basic scripts that transfers SQL database backup files from the production server to the disaster recover server. There are two Windows scheduled tasks that run the two scripts on a regular basis on the production server. One tasks runs every morning at 4:45 am. Let’s say it’s Task_1 that runs Script_1.vbs. The other task (Task_2) runs the script (Script_2.vbs) every 30 minutes. The production server is on a cluster but the DR server is not.

Something somewhere changed because these tasks ran fine for years. All of a sudden they stopped working. The last time they ran was on May 8 of this year. No one knew they had stopped running until I checked them around May 22 because I had noticed the databases weren’t current on the disaster recovery server. It’s a good thing I checked! No one seems to know what changed, though. Under “Scheduled Tasks”, the status just said “could not run”. When we tried to right-click and run the tasks, we didn’t get any errors and the status just said “could not run”. Both tasks are scheduled to run under a domain account called IT\SQLDR. It belongs to the Administrators group. The network guys checked and it still has all the right permissions (full control) on the domain and on the two servers (including both nodes on the cluster). So one of our network guys reset the password for this account on the domain and for both tasks. He then was able to manually run both tasks. That was the last time it ran. I checked the tasks today and the status is still at “could not run”.

I talked with our senior DBA about it and she checked a few things. She was able to successfully run Script_1.vbs as the IT\SQLDR account via the command prompt (using “run as user:IT\SQLDR cmd.exe”). She checked permissions on the destination server and everything looked fine. The destination folder is a share and hasn’t changed. She then reset the password on Task_2 and it ran fine. I then reset the password on Task_1 and it ran fine too. We’re stumped!

The Event Viewer shows NOTHING occurring at these times. No errors, no warnings, no informational messages. I checked SQL and nothing is running to cause this to happen that I can see. Our network guys don’t know what the problem is either. Something changed but I have no idea how to find it.

I’ll keep an eye on the tasks to see if they run in the morning. I’m predicting they won’t run. I just don’t know how to determine what else is running to cause this! Any ideas are greatly appreciated!!!

Thanks!!!
 
Most probs with sched tasks used to transfer files to network shares mostly involves authentication issues. It is possible that a policy may have been applied to the SQLDR account to cause it to have its password expire
Before you reset password make sure that the task is not still running (you can check the task manager to ensure that it still isn't), since resetting the password may still lock the account if the other running job hasn't been stopped.
 
Thank you for replying! :) I had asked the network guys if there is some sort of policy applied to the account that would cause the password to expire and they said no. I thought he checked it while I was standing at his desk, but I'll check with him again to make sure.

The task was not running when we reset the password. I checked.
 
I'm glad I took notes this morning! :) It's been one of those days already! We ran the script from the production server under the IT\SQLDR account and it ran fine. We were able to log into the servers with that account and did not encounter any problems or issues. This was BEFORE we reset the password on the task. Very weird!
 
I checked this morning and neither task ran. I’m not surprised.

Both have a status of "could not start". Something must be preventing them from starting because we reset the password on both tasks yesterday, and they ran fine after that. The last time the main one ran was at 2:26 pm yesterday, and the one that runs every 30 minutes ran at 4:20 am this morning. Maybe something else ran between 4:20 am and 4:45 am this morning that caused this problem. I say that because the main task is scheduled to run at 4:45 am and it didn't run this morning. Yet the one that runs every 30 minutes ran at 4:20 am this morning. Will re-creating the tasks help in any way?

I'm going to check the Event Viewer and see if it'll say if anything ran between 4:20 am and 4:45 am this morning.
 
I believe I have found the culprit and I have proof! :) I’m waiting for our network guys to confirm or deny it for me. The only process I could find via the Event Viewer that ran between 4:20 and 4:45 this morning was… take a wild guess! Yep! You guessed it! A security policy! :) The event description was “Security policy in the Group policy objects has been applied successfully.” I could have sworn I asked them about this before. Grrrr… oh well. As long as someone at least looks into it I’ll be happier. :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top