I cant schedule a task to run

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

This is the message I get in the log when I try to add a new scheduled task

"Taskname.job" (taskname.exe) 9/2/2006 11:51:00 PM ** ERROR **
The attempt to retrieve account information for the specified task failed;
therefore, the task did not run. Either an error occurred, or no account
information existed for the task.
The specific error is:
0x8004130f: No account information could be found in the Task Scheduler
security database for the task indicated.

I'm running XP Media Centre edition 2005 with update rollup 2
 
0x8004130f: No account information could be found in the Task Scheduler
security database for the task indicated

This problem may also occur when you create a new task and you do not type a
password for that task. In this case, you must create a password for your
user account if it does not have one, and use that password for any new task
you create.

“0x80070005: Access is denied" error message when you create a scheduled
task in Windows XP Service Pack 2
http://support.microsoft.com/default.aspx?scid=kb;en-us;884573

See...
WORKAROUND

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In
 
To run the task without the password , open properties of that task and check
the box
"Run Only If Logged on" ( This option is only available in SP2)
And be sure that Run As xxxx match your user account name.
 
On Sat, 2 Sep 2006 20:40:01 -0700, Ayush <ayush[X]maan.j at

I think I know what this problem is ;-)
To run the task without the password , open properties of that task and check
the box "Run Only If Logged on" ( This option is only available in SP2)
And be sure that Run As xxxx match your user account name.
"anabrin" wrote:

In XP before SP2, no Tasks would run if the account password was
blank. You could enter such Tasks, and you'd see no error messges;
they just wouldn't run! The Task Manager needs a password and takes
"blank" as nothing entered, so when the password really IS "blank" it
is impossible to match it. So Tasks behave as if pwd is wrong.

This is really nasty, because it compelled users to use an account
password when they didn't want to. So they'd use something trivial,
and that in turn would turn on XP Pro's "hidden admin share" feature.

Because the account password was no longer blank, XP Pro would expose
ALL of EVERY HD volume for full access via File & Print Sharing -
potentially allowing any Internet entity to do anything anywhere on
the PC. Sure, the shares are "hidden", but that just means the user
doesn't see them or realize the risk; the names of the shares are
always the same, you don't even have to guess.

With a weak password, it's trivially easy to break in, steal files,
drop malware, whatever you like.

SP2 helped this by allowing "run when logged on" to bypass the
password check, with the added advantage that changing the user
account password no longer stops existing Tasks from running.


But that's not this poster's problem, because he's getting an error
when he tries to enter the Task, not when it is run.

His failure pattern I see often, after this scenario:
- you change the PC or user account name
- you try to work with Tasks, e.g. edit or copy an old one, etc.

What now happens is that the machine/user same that pre-populates the
Task dialog is now at variance with the real machine and user account
name. It can't resolve when the Task is entered, so you get the
error. What is more annoying, though, is that you can manually fiddle
with the machine/user name as much as you like, but chances are you
will never get XP to accept the Task you're trying to enter!

The workaround is to create an arbitrary new Task. When you do so,
that Task will be pre-populated with the correct machine/user name,
and will work. You can then delete that Task, go back to edit other
Tasks, and you will now find them pre-populated with the correct
machine/user name and they will now work when (re-)entered.


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
 
cquirke wrote:

The workaround is to create an arbitrary new Task. When you do so,
that Task will be pre-populated with the correct machine/user name,
and will work. You can then delete that Task, go back to edit other
Tasks, and you will now find them pre-populated with the correct
machine/user name and they will now work when (re-)entered.

---------------------

My tasks were already populated with the proper machine/user name, my box is
checked (run only if logged in) and I still get the error message and no
backup task runs. IT ONLY HAPPENS FOR THE BACKUP TASK in my case.

Any help is apprecited...

cquirke (MVP Windows shell/user) said:
On Sat, 2 Sep 2006 20:40:01 -0700, Ayush <ayush[X]maan.j at

I think I know what this problem is ;-)
To run the task without the password , open properties of that task and check
the box "Run Only If Logged on" ( This option is only available in SP2)
And be sure that Run As xxxx match your user account name.
"anabrin" wrote:

In XP before SP2, no Tasks would run if the account password was
blank. You could enter such Tasks, and you'd see no error messges;
they just wouldn't run! The Task Manager needs a password and takes
"blank" as nothing entered, so when the password really IS "blank" it
is impossible to match it. So Tasks behave as if pwd is wrong.

This is really nasty, because it compelled users to use an account
password when they didn't want to. So they'd use something trivial,
and that in turn would turn on XP Pro's "hidden admin share" feature.

Because the account password was no longer blank, XP Pro would expose
ALL of EVERY HD volume for full access via File & Print Sharing -
potentially allowing any Internet entity to do anything anywhere on
the PC. Sure, the shares are "hidden", but that just means the user
doesn't see them or realize the risk; the names of the shares are
always the same, you don't even have to guess.

With a weak password, it's trivially easy to break in, steal files,
drop malware, whatever you like.

SP2 helped this by allowing "run when logged on" to bypass the
password check, with the added advantage that changing the user
account password no longer stops existing Tasks from running.


But that's not this poster's problem, because he's getting an error
when he tries to enter the Task, not when it is run.

His failure pattern I see often, after this scenario:
- you change the PC or user account name
- you try to work with Tasks, e.g. edit or copy an old one, etc.

What now happens is that the machine/user same that pre-populates the
Task dialog is now at variance with the real machine and user account
name. It can't resolve when the Task is entered, so you get the
error. What is more annoying, though, is that you can manually fiddle
with the machine/user name as much as you like, but chances are you
will never get XP to accept the Task you're trying to enter!

The workaround is to create an arbitrary new Task. When you do so,
that Task will be pre-populated with the correct machine/user name,
and will work. You can then delete that Task, go back to edit other
Tasks, and you will now find them pre-populated with the correct
machine/user name and they will now work when (re-)entered.


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -
 
cquirke wrote:

The workaround is to create an arbitrary new Task. When you do so,
that Task will be pre-populated with the correct machine/user name,
and will work. You can then delete that Task, go back to edit other
Tasks, and you will now find them pre-populated with the correct
machine/user name and they will now work when (re-)entered.

------------------------

I also get the error message "0x80070005: Access is denied. You do not have
permission to perform the requested operation" because I do not enter a
password for my account log in.

Frustrating.....

cquirke (MVP Windows shell/user) said:
On Sat, 2 Sep 2006 20:40:01 -0700, Ayush <ayush[X]maan.j at

I think I know what this problem is ;-)
To run the task without the password , open properties of that task and check
the box "Run Only If Logged on" ( This option is only available in SP2)
And be sure that Run As xxxx match your user account name.
"anabrin" wrote:

In XP before SP2, no Tasks would run if the account password was
blank. You could enter such Tasks, and you'd see no error messges;
they just wouldn't run! The Task Manager needs a password and takes
"blank" as nothing entered, so when the password really IS "blank" it
is impossible to match it. So Tasks behave as if pwd is wrong.

This is really nasty, because it compelled users to use an account
password when they didn't want to. So they'd use something trivial,
and that in turn would turn on XP Pro's "hidden admin share" feature.

Because the account password was no longer blank, XP Pro would expose
ALL of EVERY HD volume for full access via File & Print Sharing -
potentially allowing any Internet entity to do anything anywhere on
the PC. Sure, the shares are "hidden", but that just means the user
doesn't see them or realize the risk; the names of the shares are
always the same, you don't even have to guess.

With a weak password, it's trivially easy to break in, steal files,
drop malware, whatever you like.

SP2 helped this by allowing "run when logged on" to bypass the
password check, with the added advantage that changing the user
account password no longer stops existing Tasks from running.


But that's not this poster's problem, because he's getting an error
when he tries to enter the Task, not when it is run.

His failure pattern I see often, after this scenario:
- you change the PC or user account name
- you try to work with Tasks, e.g. edit or copy an old one, etc.

What now happens is that the machine/user same that pre-populates the
Task dialog is now at variance with the real machine and user account
name. It can't resolve when the Task is entered, so you get the
error. What is more annoying, though, is that you can manually fiddle
with the machine/user name as much as you like, but chances are you
will never get XP to accept the Task you're trying to enter!

The workaround is to create an arbitrary new Task. When you do so,
that Task will be pre-populated with the correct machine/user name,
and will work. You can then delete that Task, go back to edit other
Tasks, and you will now find them pre-populated with the correct
machine/user name and they will now work when (re-)entered.


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -
 
Back
Top