why would this scheduled tasks running as "SYSTEM", be failing?

[bennett]

Prior to today, schtasks would allow me to schedule tasks using syntax
like the following:

schtasks /create /sc hourly /mo 1 /ru "SYSTEM" /tn ipresub /tr
"c:\perl\bin\perl.exe c:\test.pl"

which means, create a job called "ipresub" to run hourly, as the
"SYSTEM" user.

Some time today, and I have no idea what could have changed this, a job
that I had set up to run every hour, stopped working. Windows tries to
run it every hour, but it's always listed in Scheduled Tasks with
"Could not start" in the "Status" column.

When I look in the C:\Windows\schedlgu.txt file, the results for the
attempts to run this job, say:"ipresub.job" (perl.exe) 1/24/2007 12:04:00 AM ** ERROR **
The attempt to log on to the account associated with the task failed,
therefore, the task did not run.
The specific error is:
0x8007052f: Logon failure: user account restriction. Possible reasons
are blank passwords not allowed, logon hour restrictions, or a policy
restriction has been enforced.
Verify that the task's Run-as name and password are valid and try
again.
However, the schtasks documentation at
http://www.microsoft.com/resources/.../xp/all/proddocs/en-us/schtasks.mspx?mfr=true
says "Tasks run with with permissions of the NT Authority\System
account do not require a password and SchTasks.exe does not prompt for
one." So that would seem to rule out the blank password problem. And
after all it worked earlier today anyway. But is there any way I can
find out more about why it just mysteriously stopped working?

If I open Task Manager, go to Processes and check the "Show processes
for all users" checkbox, it shows some processes running under the
SYSTEM account, so there appears to be nothing wrong with the account
itself.

 

[Pegasus \(MVP\)]

Prior to today, schtasks would allow me to schedule tasks using syntax
like the following:

schtasks /create /sc hourly /mo 1 /ru "SYSTEM" /tn ipresub /tr
"c:\perl\bin\perl.exe c:\test.pl"

which means, create a job called "ipresub" to run hourly, as the
"SYSTEM" user.

Some time today, and I have no idea what could have changed this, a job
that I had set up to run every hour, stopped working. Windows tries to
run it every hour, but it's always listed in Scheduled Tasks with
"Could not start" in the "Status" column.

When I look in the C:\Windows\schedlgu.txt file, the results for the
attempts to run this job, say:
"ipresub.job" (perl.exe) 1/24/2007 12:04:00 AM ** ERROR **
The attempt to log on to the account associated with the task failed,
therefore, the task did not run.
The specific error is:
0x8007052f: Logon failure: user account restriction. Possible reasons
are blank passwords not allowed, logon hour restrictions, or a policy
restriction has been enforced.
Verify that the task's Run-as name and password are valid and try
again.

However, the schtasks documentation at
http://www.microsoft.com/resources/.../xp/all/proddocs/en-us/schtasks.mspx?mfr=true
says "Tasks run with with permissions of the NT Authority\System
account do not require a password and SchTasks.exe does not prompt for
one." So that would seem to rule out the blank password problem. And
after all it worked earlier today anyway. But is there any way I can
find out more about why it just mysteriously stopped working?

If I open Task Manager, go to Processes and check the "Show processes
for all users" checkbox, it shows some processes running under the
SYSTEM account, so there appears to be nothing wrong with the account
itself.

I would try one of the following:
- Stop, then restart the Task Scheduler service.
- Create a dedicated Task Scheduler account, then use it to run this task.

 

[bennett]

I would try one of the following:

- Stop, then restart the Task Scheduler service.
- Create a dedicated Task Scheduler account, then use it to run this task.

I tried restarting Task Scheduler (in fact, tried restarting the entire
computer) but that didn't fix it.

The problem with creating a dedicated Task Scheduler account is that
I'm actually not trying to do this for myself on my own computer, but
to do it within a script that will be distributed to many users. So
creating a user as a workaround for my own machine wouldn't solve it.
I could try to create a user from the command line in the script that
will be distributed to multiple users' machines, however every thing
like that that you do in a script that runs on many machines with many
settings in many environments, is one more thing that can go wrong...

If there is no commonly known solution to this general problem, is
there a way I can get more specific information on why it's failing?
Any suggestions whatsoever would be appreciated.