THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Buck Woody

Carpe Datum!

Restarting the SQL Server Service Account – Why?

SQL Server runs under the aegis of a “service” in Windows. That means it’s running in the background all of the time. A Service in Windows requires the ability to “log on” to the system – even if you don’t see that happening. Which brings us to this post.

First, you should use a regular, low-privileged user account to start SQL Server. There are several “system” accounts that you can use, but most of time they have either too many rights an privileges in Windows to run SQL Server, or too few. The only exception is the Express Edition – but that’s another post. so create a domain user, just a regular account, with no special privileges or rights (yet).

The next important thing to remember is that you should always assign and work with SQL Server accounts using the SQL Server Configuration Manager tool – not the Services Applet in Control Panel. The reason why is that the CM tool does more than just set a password or start a service – it grants all of the rights and privileges a body needs to run the SQL Server system, even down to the files level.

Which brings us to today’s post. Most shops have a “rotation” rule about changing passwords – for people. When SQL Server is started with a user account, it often falls under this rule. So when it’s time to change the passwords for everyone else, you have to change the SQL Server password as well.

The question is, should you have to re-start the SQL Server service after you change it’s password? The answer is yes for SQL Server 2005 and lower (more here on that). The reason is that Windows doesn’t actually pass around passwords when it “knocks at the door” of a resource like a fileshare. Windows creates a separate value for the password, called a “token”. That is what is passed around for the account. So when you change the password for the user account that starts SQL Server, the domain now knows about the new token, but the Service (which hasn’t “logged off”, so to speak) is still using the “old” token. So while the database might keep running for a while, eventually backups fail and so on. So you need to restart the service – again, it’s best to use Configuration Manager for that, but in this case that can be automated with PowerShell or some other utility for a simple restart.

Now, if you have hundreds of servers (like I’ve hand in the past) then this can be a real pain. You can – and this might not be the best solution – set the user account that runs SQL Server not to require a password change. In some of my shops I set a very low priv account to run SQL Server, make a very complicated password, record that on paper, and then lock that paper in a sealed envelope in a safe. That way only one person knows the password (me), but others could get to it in an emergency. But if they did, they would need physical access (the safe) and we would know (the envelope would be torn open).

This may not be a security best practice in your shop, so make sure you discuss it with everyone to make sure you’re doing the right thing.

In SQL Server 2008 and later, this isn't so much of a problem. Check here for more:

Published Thursday, February 18, 2010 7:19 AM by BuckWoody



josantia said:

Hi Buck,

The MSDN article you are pointing is about changing the service account to a new one and it says, you must restart the services.

But when you are changing only the password, you don't need to do that:

"The password takes effect immediately, without restarting SQL Server."


Jose Oyervides.

February 18, 2010 10:34 AM

Buck Woody said:

You're absolutely correct - unless you try and access another resrouce. Thanks for posting.

February 18, 2010 4:35 PM

Buck Woody said:

Oh - and Jose - that was changed for 2K8. Thanks for that correction!

February 18, 2010 4:36 PM
New Comments to this post are disabled

About BuckWoody

This Blog


Privacy Statement