Windows Task Scheduler looses account credentials data

[Eugene Borisov]

Hello,

I have spent many hours trying to find the solution for this problem. I have
found several discussions on IT forums with very similar or exact same
problem. For instance:

http://www.realgeek.com/forums/task-scheduler-unreliable-nt-2000-xp-420027.html

Here is my problem described by someone else:

I have encountered a problem with Windows Task Scheduler at many
client sites over the years, where tasks may run flawlessly for days
or weeks, then magically - they stop running (listing "Could Not
Start" for the task's status). To correct the problem, I simply have
to re-enter the task's password - the SAME password that has always
been there. The task will then run for several more days/weeks! This
has been a problem in Windows NT 4.0(sp6a) SERVERs AND XP Prof
workstations. And no surprise, since XP probably uses some of the
same underlying code as NT! I have talked with other consultants -
and we've all concluded that Microsoft's task scheduler is "unreliable
at best". I would love to find out the real cause of the problem and
solve this once and for all... More info: generally a single domain
exists, YES user account associated with task ALWAYS has/had a
password...

SchedLog.txt reports: 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.

How does Windows lose the "account information"? I can log in as the
same user assigned to the task - without a problem!

In my own case the Task Manager log says:

12/2/2008 1:25:17 PM ** ERROR **

The attempt to log on to the account associated with the task
failed, therefore, the task did not run. The specific error 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.



There are several "solutions" on the forums like verifying group policy,
disabling 3rd party services, day light saving time changing effect and some
others. Neither works for my situation.

As I understand the problem has existed for years and generations of
Windows. I am curious if MS ever provided real solution for this. Once more:
the scheduled task on XP runs for weeks\months normally under the domain
admin account. The password is never changed on this account. Suddenly the
task stops running with description from above. I reapply the password and
it works again.

Thank you

Eugene

 

[Kelly]

Hi,

Here are some suggestions:

Go to Start/Run/Msconfig. Click Selective Startup and uncheck Load System
Services, click ok. Reboot.

Upon reboot, click OK to the first Window that indicates that you have
selected "Selective Startup". When the System Configuration Utility
reappears, Check the Normal
Startup Box.

Then go to Start/Search and type in: schedlgu.txt. When it appears, right
click on the file and delete it. Reboot.

You will now have a new Task Scheduler Log File. It can be checked by going
to Start/Search and typing in: schedlgu.txt. Appearing will be your new Task
Scheduler Log.

Running Scheduled Tasks without a password:

For Pro: Start/Control Panel/Administrative Tools/Local Security
Policy/Local Policies/Security options. In the right hand pane (third down).

Accounts: Limit local account use of blank passwords to console logon only.
This is enabled by default, disable it.

For Home: Run Scheduled Task without a Password (Line 68)
http://www.kellys-korner-xp.com/xp_tweaks.htm

Troubleshooting the Task Scheduler
http://www.kellys-korner-xp.com/xp_t.htm#ts

Task Scheduler MS-KB Articles: http://tinyurl.com/3gnjc

How to Enable Automatic Logon in Windows
http://support.microsoft.com/default.aspx?scid=kb;en-us;315231

HOW TO: Schedule Tasks in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q308569

HOW TO: Modify Scheduled Tasks in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q308671

--

All the Best,
Kelly (MS-MVP/DTS&XP)

Taskbar Repair Tool Plus!
http://www.kellys-korner-xp.com/taskbarplus!.htm

 

[Eugene Borisov]

Hello, Kelly



Thank you for prompt reply. I am not sure I understand how deleting the log
file might solve this problem, nevertheless I went ahead and followed your
instructions. The problem is certainly still here. Running the task without
the password is not an option - this task accesses network resources and
such requires domain account. Thank you for trying though.



Eugene

 

[Tim Quan [MSFT]]

Hello Eugene,

Thank you for posting.

From your description, I understand that scheduled tasks forget passwords
and do not run properly. This issue occurs on both Windows NT 4.0 and
Windows XP Professional. If there is any misunderstanding, please let me
know.

This seems to be a known issue. I suggest installing Windows XP Service
Pack 3.

Windows XP Service Pack 3 can be downloaded from the following site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5b33b5a8-5e76-401f-
be08-1e1555d4f3d4&DisplayLang=en

For more information, please refer to the following article:

Task Scheduler jobs stop running in Windows XP
http://support.microsoft.com/default.aspx/kb/812960/en-us

Task Scheduler Does Not Run Scheduled Tasks on Backup Domain Controller
(BDC)
http://support.microsoft.com/default.aspx/kb/222628/en-us

Please understand that we mainly discuss Windows XP issues here. If the
issue persists on Windows NT 4.0, I suggest discussing it in our Windows NT
newsgroup.

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=micros
oft.public.windowsnt.misc&cat=en_US_08ed5e1b-445d-4c44-8361-3c668729540b&lan
g=en&cr=US

Please take your time trying the above suggestions and let me know the
results at your earliest convenience.

Sincerely,
Tim Quan
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eugene Borisov]

Hello, Tim

All our systems run Windows XP with SP3 installed, so the solutions hides
somewhere else.

Thank you for your reply
Eugene

 

[Colon Terminus]

Hello,

I have spent many hours trying to find the solution for this problem. I
have found several discussions on IT forums with very similar or exact
same problem. For instance:

http://www.realgeek.com/forums/task-scheduler-unreliable-nt-2000-xp-420027.html

Here is my problem described by someone else:

I have encountered a problem with Windows Task Scheduler at many
client sites over the years, where tasks may run flawlessly for days
or weeks, then magically - they stop running (listing "Could Not
Start" for the task's status). To correct the problem, I simply have
to re-enter the task's password - the SAME password that has always
been there. The task will then run for several more days/weeks! This
has been a problem in Windows NT 4.0(sp6a) SERVERs AND XP Prof
workstations. And no surprise, since XP probably uses some of the
same underlying code as NT! I have talked with other consultants -
and we've all concluded that Microsoft's task scheduler is "unreliable
at best". I would love to find out the real cause of the problem and
solve this once and for all... More info: generally a single domain
exists, YES user account associated with task ALWAYS has/had a
password...

SchedLog.txt reports: 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.

How does Windows lose the "account information"? I can log in as the
same user assigned to the task - without a problem!

In my own case the Task Manager log says:

12/2/2008 1:25:17 PM ** ERROR **

The attempt to log on to the account associated with the task
failed, therefore, the task did not run. The specific error 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.



There are several "solutions" on the forums like verifying group policy,
disabling 3rd party services, day light saving time changing effect and
some others. Neither works for my situation.

As I understand the problem has existed for years and generations of
Windows. I am curious if MS ever provided real solution for this. Once
more: the scheduled task on XP runs for weeks\months normally under the
domain admin account. The password is never changed on this account.
Suddenly the task stops running with description from above. I reapply the
password and it works again.

Thank you

Eugene

Probably no help in your situation but I have found that this situation
occurs when the Operating System is installed on a FAT32 partition. I've
solved this many times by simply converting the O/S partition from FAT32 to
NTFS; doing so simply made the problem go away.

 

[Pegasus \(MVP\)]

Probably no help in your situation but I have found that this situation
occurs when the Operating System is installed on a FAT32 partition. I've
solved this many times by simply converting the O/S partition from FAT32
to NTFS; doing so simply made the problem go away.

I agree but my recollection is that the FAT-issue only causes a problem
twice each year: Whenever the machine changes from Standard Time to Daylight
Saving Time and back again. Strange but true.

 

[Eugene Borisov]

Gentlemen,



You are both right - I saw this solution somewhere on the Internet.
Unfortunately this is not case here - all systems are NTFS. I start thinking
MS will take this mystery to the grave

Nevertheless, I really appreciate everyone trying to help.



Respectfully,

Banging head against wall

Eugene

 

[Tim Quan [MSFT]]

Hello Eugene,

According to my research, this issue may be caused by group policies.

Is it convenient for you to setup a new computer without joining the domain
to test the result? Or you can move your computer into an OU and block the
domain policy inheritance.

In addition, I would like to know what task you would like to schedule.

Tim Quan - MSFT

 

[Eugene Borisov]

Hello, Tim

Yes, I can test it on such machine, no problem, will create new OU and block
policies. The result migh take A WHILE, though. I am scheduling simple
batch file sitting on network share, this is why I use domain account. This
is a simple defragmentation task- not more.

Thank you
Eugene

 

[Tim Quan [MSFT]]

Hi,

Thank you for posting.

I have tested this issue on my Windows Vista machine and I can reproduce
this issue:

If an domain user belongs to both Domain Guests group and a client's local
Administrators group, when logging on this user account on the client, a
temporarily user profile is created. When logging off this account, this
user profile will be deleted.

It is not recommended to add Domain Users group to (Domain) Guests group.

Now if you would like to prevent users from leaving behind profiles on
clients while preserve administrator profiles, you can use the following
method:

1. For non- clients' administrator domain users, add them to Domain Guests
group. When logging on them on clients, only temporarily profiles will be
created

2. For clients' administrator domain users, add them to clients' local
Administrators group. When logging on them on clients, permanent profiles
will be created.

If anything in my e-mail is unclear or you need further help, don't
hesitate to let me know.

Sincerely,
Tim Quan
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Tim Quan [MSFT]]

Hi,

Sorry for my mistake.

Please ignore the above post.

Sincerely,
Tim Quan
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Tim Quan [MSFT]]

Hello Eugene,

Thank you for the reply.

You can also try the following method to test the issue:

On the domain Controller Security Policy:

a. Make the user a part of administrator and;

b. Grant the user/administrator rights to "Log on as batch job" and "Log on
as a service". To do it do the following:

c. Click Start --> Programs ¨¤ Administrative Tools -> Domain Controller
Security Policy.
d.. Expand
-- Windows settings
Security Settings
Local Policies
User Rights Assignments

e. Confirm that the administrator is not a part of the rights: "Deny logon
as a
batch job" and "Deny logon as a service".

3. On the local Security policy:

Expand
-- Windows settings
Security Settings
Local Policies
User Rights Assignments
Grant this user the rights of;

a. Log on as a batch
b. Log on as a services
c. Log on locally

4. Close the console.

a. From the command prompt on the server run the command:
b. Secedit /refreshpolicy machine_policy /enforce
c. Have the administrator/user "logoff and logon".

5. Create a new scheduled job and run again.

Sincerely,
Tim Quan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eugene Borisov]

Tim,

I double-checked the settings you pointed and found my user is a domain
administrator and has all these rights to logon. Please, don't forget, the
problem occurs after long period of normal functioning. It might take weeks
or even months to stop working for my job in Scheduled Tasks.
On the other note, you might be on something regarding policies. I have
noticed, that all my workstations in question belong to OU "EndWorkstations"
with configured Group Policy object. The rest of domain systems sit in the
default AD Computers folder. These system NEVER failed to run the same
scheduled task running under the same user.
I am moving one workstation back to Computers folder and will monitor it.
If you have any thoughts on this , please share.

Thank you for your help.

Eugene

 

[PA Bear [MS MVP]]

No soup for you!

 

[Tim Quan [MSFT]]

Hello Eugene,

I have no more to add now. I suggest monitoring this issue. If the issue
does occur on the workstation you moved to Computers folder, it is probably
caused by the group policy. If so, I suggest further discussing this issue
in our Windows Server newsgroup or forum.

Windows Server 2003 newsgroup:
http://technet.microsoft.com/en-us/windowsserver/bb841405.aspx

Windows Server forum:
http://social.technet.microsoft.com/Forums/en-US/category/windowsserver/

If you require further assistance, please feel free to let me know.

Tim Quan - MSFT

 

[Eugene Borisov]

I have found the solution. Apparantly we run software deployment using the
same domain account. Every time this remote push is done, the credentials in
scheduled task were lost. Mistery, but this fact allowed workaround - we
simply use different account and so far (more than month) all looks fine.

Eugene

 

[Tim Quan [MSFT]]

Hello Eugene,

Thank you for the reply.

I am glad to hear that the cause of the issue has been found.

If you need further help regarding this issue in the future, please feel
free to let me know.

Sincerely,
Tim Quan
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.