I have a number of scheduled tasks which run succesfully under my administrator account (Windows Server 2003 Standard), however if I try to run the tasks using a service account (that by all accounts should have the same privileges), the tasks all fail. The only error message I can get however is from the log file which just tells me that it timed out. "transfer.job" (transfer.vbs) 9/9/2010 2:20:02 PM ** WARNING ** The task was forced to close since its execution time exceeded the configured maximum. You may want to go to the Settings page and increase the "Stop the scheduled task after" time. The job doesn't take more than a couple seconds on my account, and on the service account it is timing out after the 2 minutes I've given it. Is there another way to trouble shoot the scheduled tasks other than through the log in Advanced-View Log?

If the job connects to another machine you may need to add the user/ group 'logon as batch job' rights (server side). Control Panel|Admin Tools|Local Security Policy\Local Policies\User Rights Assignments "Log on as a batch job" If the task completes but the job does not then there is a problem in the job itself. Remember that if it involves network resources to make sure the user account has permissions to the resources and also use UNC paths as mapped drives won't natively exist when no one is logged on. Regards, Dave Patrick .... Microsoft Certified Professional -Microsoft MVP [Windows]

I checked the User Rights Assignments and the account was already there for "Log on as a batch job" Can you help me with what would be the proper UNC path? If the path to the script was D:\applications\scripts\blah.vbs would the proper UNC be \\servername\applications\scripts\blah.vbs? Also I should mention that if I log in with the service account to the server I still can't run the scheduled job (just by right clicking it and hitting 'run') so I don't think it's a path issue. I CAN just run the sctipt directly with the service account it just wont work via the scheduled job.

If it resides on a local disk then the D:\ notation is correct. Otherwise it should be; \\servername\sharename\applications\scripts\blah.vbs Might be something within the script causing the issue. Regards, Dave Patrick .... Microsoft Certified Professional -Microsoft MVP [Windows]