Password change


We had something break yesterday.  I'm trying to figure out what happened, in the interest of "Lessons Learned".  Here are the facts and background.

1.  We use Active Directory.

2.  I needed to change the password for the SQL Server account and the SQL Server Agent account.  We have three SQL Servers.  Base on a response to a post I made in this forum, we decided to use one domain account for the SS accounts and the SS Agent accounts.  There was already an account being used for one of the SS Agents.  Since no one remembered the password, we decided to change it.

3.  We have a weekly maintenance window once a week.  I asked the guy who handles the domain accounts to change the password on the account for me.  I was going to stop and restart the services during the maintenance window.

4.  I was unable to be here during the maintenance window, so I never stopped and restarted the services.  I didn't think it mattered, because it is my understanding that the password change does not take effect until the services are stopped and restarted.

5.  I was out yesterday.  SS Agent jobs that access the servers broke (I don't much, yet, about how those apps are architected).  The guys here stopped and restarted the services, and it solved the problem.

So the initial diagnosis in most folks' minds is that changing the password broke the jobs.  But I thought that password changes don't take effect until the services were stopped and restarted.

Can someone offer their opinion here?


Who is Participating?
pcsentinelConnect With a Mentor Commented:
I might be something simple.

If the services where already running and therefor logged in under the old password then they would be fine. However if the services spawned other services then they would try to log in using the parent password of the already connected service, which is no longer valid.

Best I can think of at the mo, but will give it further thought

guillotjAuthor Commented:
Please someone give me some insight into this.  The guy doing the complaining today was going on without giving me complete info (damn user <joke>).  "something about IUSR or something like that", he would say.

I don't know what the front end code looks like.  I know who the IUSR_...  is.  Is it possible that a password was hardcoded into a connection string in IIS?  If we changed the domain account's password, but hadn't started and stopped the SS services, it seems that SS Agent would still run.  It doesn't read the new password until a stop and start, right?

The folks across the country from me were complaining their jobs weren't running, but all the jobs I've created on the server ran fine, so the SS Agent was working OK.

So it's not merely a case of SS Agent not running.  They must have been affected when I changed the domain account password, but not in the sense that the Agent wasn't running.

I apologize that I don't have more info, but that's all I could glean from a guy who is not experienced in Windows or SS.  But his repeating of "IUSR something or other" gives me a clue that it's IIS-related.  I suppose that changing the domain account without changing the settings in IIS Manager could have definitely broken things.

But they report that when they stopped and restarted SQL Server, it fixed the problem.  So it's getting confusing.  I'm probably getting faulty info from my colleague.

Come on, y'all, someone come through for me...tomorrow's another day, and I want it to be a good one.  I increased the points, since I haven't had a response all day, so maybe the question is tougher than I thought :)
guillotjAuthor Commented:
Thanks!!  Exactly my thoughts!!

BTW, Mr. Sentinel, I don't think you're simple at all :)


Read first line of your post...I couldn't resist...apologies... :)

It's FRIDAY!!!!!!!

And please do send more info, I find your comments quite helpful...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.