Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a couple of jobs scheduled to run daily on a customer server running Windows Server 2003 Standard Edition, SP1 using Windows Scheduled Tasks. The tasks are set to run as a user that is in the Administrators group, and were scheduled as that same user. The password of that user is set to never expire. These tasks fail to run pretty much every day. Going into Scheduled Tasks and attempting to run the tasks manually indicates that the password is incorrect. I go into the task properties, retype the password into the appropriate fields, click OK, and attempt to run the task manually again. Now it works fine. What might be the cause of the password being lost like this?

These same tasks are running on other customers servers with no problems.

Thanks in advance for any thoughts.

share|improve this question
    
We've been struggeling with this for years as well. It disappeared when we reinstalled our entire serverpark. But I'm guessing that is not an option for you ;) –  Frode Lillerud May 29 '09 at 20:35
    
What error appears in the Schedlgu.txt log in C:\Windows when the task tries to run? –  Shaun Hess Jun 5 '09 at 22:24
add comment

7 Answers

Not sure what causes it, but this worked for me as a workaround. Try changing local policy to allow the user to logon locally.

share|improve this answer
    
Thanks for the reply. The "Administrators" group is included in the "Allow log on locally" policy, and as I mentioned in the question, the user that the scheduled task is set to run as is a member of "Administrators" group. I wouldn't think that I would need to add the user name to that policy if the "Administrators" group is already there, but would that be worth a shot? There are no users/groups in the "Deny log on locally" policy. –  E Brown Jun 1 '09 at 12:59
add comment

Assuming that the job needs to run as a service you may neeed to add that account to run as a service or create account to just log on as a service. Are you able to modify Goup Policies?

John

share|improve this answer
add comment

There seem to be a lot of references to time changes messing up the task scheduler. Is it possible your server isn't keeping good time, so the windows time service is constantly changing it? Maybe you could try disabling that service for a little while and seeing if it resolves your problem. (Some services might depend on Windows Time)

You might also look at 933550 and 826895. I know they aren't exactly the same version of server you running. You might have a corrupt task scheduler database. 328773 might also be a possibility.

share|improve this answer
add comment

When a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user. The Task Scheduler injects this right for the user into the computer's effective policy immediately after the task is scheduled. If there is a contradictory group policy defining the Logon as a batch job user right, the effective policy settings will be overwritten by the group policy.

Make sure the Administrators group or the user scheduling the tasks is defined in the "Logon as a batch job" in the group policy. I believe its under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

Also what error appears in the Schedlgu.txt log? You can access this log on Windows Server 2003 by running the command below:

%SystemRoot%\Tasks\SchedLgU.txt
share|improve this answer
    
Thanks for the reply. Neither the Administrators group nor the user the task is scheduled to run as is in the "Logon as a batch job" group policy. The Administrator account is, but not the Administrators group. I don't have permission to modify policies, but will contact the server admin person to have them try this. Also, I'm not seeing any file named schedlgu.txt anywhere on the server. Is that the correct filename for Windows Server 2003? –  E Brown Jun 8 '09 at 12:42
    
Sorry about that, I corrected the post. In any case you can access the scheduled task log by running: %SystemRoot%\Tasks\SchedLgU.txt. –  Shaun Hess Jun 8 '09 at 19:45
    
Thanks for the update. The error in the log is "0x80070569: Logon failure: the user has not been granted the requested logon type at this computer. Verify that the task's Run-as name and password are valid and try again." –  E Brown Jun 9 '09 at 12:41
add comment

Did you try to remove the local profile of this account ?

check for GPO that may restrict "logon as a batch" to some groups. This is hard to solve, because when you create the task, it works, but when the gpo is applied again, it stop working.

Any audit failure in the security event log?

share|improve this answer
add comment
up vote 0 down vote accepted

Thanks for all of the replies, suggestions, and comments. Despite everything I've tried, I can't get this server to stop losing the password for this user in Scheduled Tasks. I don't really know that it is a policy issue anyway, since the jobs will run after resetting the password in the task's properties. I can do that, reschedule the job for 5 minutes later, and it works. Schedule it to run for 5 hours later, 10 hours later, various different times - sometimes it will run once, maybe, then won't again until the password is reset. So it doesn't seem to be a policy issue, but more an issue that the password configured in the task's properties is getting corrupted or lost for some reason. Scheduling the jobs to run at various different times in an attempt to find some pattern or time frame where the password goes has uncovered nothing. It seems to happen pretty much randomly. I ended up installing CRONw (http://cronw.sourceforge.net/) a perl-based version of the "cron" utility of the *nix world that runs as a Windows service. The scheduled jobs work fine now, so that's my solution, for the time being at least.

share|improve this answer
    
Hey, thanks for the follow-up. Sorry we couldn't come up with something for you! –  squillman Jun 18 '09 at 13:09
add comment

In my case it is solved with the Group Policy "Log on as batch job" option. The moment that the group policy is applied, it removes the account from the batch job list.

share|improve this answer
add comment

Your Answer

 
discard

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.