If this is a stand-alone password, consider using the local Administrator account and password.
As Greg points out, if you have a password expiry policy set, Scheduled Tasks will not pick up the forced new password and the Scheduled Task entry needs to be edited again to reflect the change.
Use the runas... feature of Task Scheduler and use the local Administrator account.
Why?
Because the runas is scheduled under a user account. If the system is in a screensaver lock mode, hibernate, or standy, or sometimes because it feels like it, its only recourse is to use Local System, and local system has very limited rights.
You could using services.msc change the logon authority from local system to NT/Authority, (Service Pack 2 for XP does exactly this, which confounds some scheduling and remote access products completely). But it is a safer logon for the Task Scheduler service.
Two thoughts:
. I create a Administrator-priviliged account, no password experiation, and then flip through Administrative Tools, Local Policy, and deny it access to anything that could possibly harm the system. If this is a password protected local workstation, then do not worry about local policies. Create a new Administrative user, and use the Runas... feature of the Task Scheduler to assign the logon to this new user (with password!).
. As Service Pack 2 is imminent, apply SP2 final when it appears. Remove all of your existing scheduled tasks, as many may not work as defined under SP2. Rebuild them.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.