|
This is a problem I've actually wrestled with myself on the server end. If you have a service that runs under the auspices of the administrator account and you change that account's password, the service will not start correctly unless you update the stored copy of the password for that service. I found this out the hard way when I discovered that tasks scheduled to run through SQL Server Agent weren't running after I changed the administrator password (since they were running under that account and not the SQL Server "sa" account, which hadn't changed).
One possible way to get around this is to have a separate account created on that system specifically for running scheduled tasks, one which doesn't require its password to be reset as aggressively but which has the needed permissions to get everything done. (The Task Scheduler has built-in provisions for running a task with different user credentials.) This is the approach I used. If you use a fairly cryptic username and password, it should not be susceptible to attack (if that's a concern).
Additional Expert Help:
Be sure to check our Answer FAQ for more expert advice.
For faster answers, visit ITKnowledge Exchange.
|
