There are several best practices for dealing with passwords, but one that gets overlooked a LOT is the one that says never use your personal account for services or processes. The reason usually given is because when you change your password, the processes will stop working. That's nice, but so often people don't care about that. They prefer the ease of being able to use their account because they know it has th There are several best practices for dealing with passwords, but one that gets overlooked a LOT is the one that says never use your personal account for services or processes. The reason usually given is because when you change your password, the processes will stop working. That’s nice, but so often people don’t care about that. They prefer the ease of being able to use their account because they know it has the rights they need, and they can control the credentials and not have to get any other groups involved.Well, the other side of that is that these processes running under your account will get you locked out if you’re not careful. If you change your password, and these processes are still running, you’ll get locked out for sure. And just try to track down what’s locking you out when you can’t stay on the network longer than a few minutes at a time. Now you’ve got to involve someone else in your hunt. I don’t care how bad you want to… never use your personal account for anything other than logging in. Now with Yukon, you’ve got even more reasons not to do that since you can setup proxies under your account. So if you reset your personal password one day and you find yourself suddenly getting locked out, here are some common places to look.Services: Quite often just to get things going, a DBA will run some of the SQL services under his account. Don’t do it. But if you do, start here for troubleshooting.Reporting Services: Reports take credentials to connect to the DB. It’s very common for DBAs to setup his reporting environment to just connect with his account. Bad idea. VBS: It’s also not that unheard of to see OS-level scripts running under someone’s account. A lot of these things will use WMI to connect to different machines to be used as collectors for stats. That’s fine, just have an account created for that.Scheduled Windows Jobs: Here’s another place you have to hardcode your password. You have to tell the job to run as somebody… just don’t make it you and you’ll be fine.Stored Procedures: It’s not all that out of whack to see SPs with openrowset and xp_cmdshell commands in them, and quite often these will have your account and password hardcoded in them as well. The most common place I see that is in mapping drives in cmdshell. TS: Terminal Services sessions can be a big culprit too. A good best practice to get into is always logging out of your TS sessions when you’re done. This is because if you have open sessions, TS will use your previous credentials and lock you out eventually. I used to do this all the time at my old gig. Our network guy was constantly having to search the network for servers carrying my rogue TS sessions. And they can be tough to track down, so just log out when you’re done.OK, those are the biggest ones. I’m sure there are some I forgot, but this isn’t meant to be a comprehensive list, just a few ideas. But think about it. If something’s locking you out, how hard would it be to track it down if you manage dozens of boxes and have processes running all over the place. It’s next to impossible. especially since you get very little information from AD on the event. And if it’s a .vbs that’s hidden in a folder somewhere, or being called from another program like MOM or NetIQ you’re just screwed. You’ll be lucky if you ever find it. So if you don’t care about this best practice because your environment is safe and you’re not in much danger of your account being used for evil, then at least consider this point and set yourself for success the next time you change your password. Anyway, that’s all I got. Databases