up vote 1 down vote favorite
share [g+] share [fb]

I've been searching all day for a solution for this, and so far have come up with nothing.

I have some scheduled tasks on a server that run PowerShell scripts. They run fine for a day or so, and then suddenly stop. The error they start giving 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.

Simply reseting the password for the Run as user fixes the problem. Everything I've seen online claims that this is a problem with permissions, but I don't believe that as the tasks run fine for a day. The user account being used is a domain account with administrator privileges.

link|improve this question
does the script reach out and touch remote workstations\servers, if so there may be a particular workstation\server that is having problems with your domain account that the task is running as. Try to have your powershell script fail silently! – tony roth Dec 2 '10 at 15:26
It does. The script is building SSRS reports via SOAP. However, the script is being executed so that all output (stdout and stderr) are being redirected to a log file. According to these logs, the scripts are not failing. – Matthew Dec 2 '10 at 16:46
Perhaps this is a Kerberos ticket timeout issue? What is the security context of the scheduled task (machine or domain user account)? Do you use smart cards for login? Does it run even if a user is not logged into the server? Does the job terminate properly when it does run (or does it remain in a running state)? – newmanth Dec 2 '10 at 19:35
I've tried the tasks with both domain and machine accounts with the same result. We do not use smart card logins. The task does run when a user is not logged in (that is, until it stops working). The job has terminated gracefully each time according to the output log and the result shown in Scheduled Tasks. It's almost as if the task is losing credentials. Simply reentering the password for the Run as account fixes it for the next day or so. – Matthew Dec 3 '10 at 14:35
feedback

1 Answer

up vote 1 down vote accepted

Problem solved. If you guessed it was policies, you win a cookie.

Simply put, entering the username and password for the run as user in a task adds that user to the local run as batch policy. The catch is that when group policies are updated, this is overwritten. The problem is alleviated by reentering the password (thus adding the user to the local policy again) until the next time policies are pulled.

It's a silly mistake on my part, but I figured I'd post the answer here for anyone else who may be suffering from the same dilemma.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.