This week Tom LaRock(@sqlrockstar) tweeted a question, followed by a full on blog post and survey, asking folks if they installed client tools on their servers. My answer was pretty blunt:
@sqlrockstar Allow it?Yes.Like it?No.
— Mike Fal (@Mike_Fal) March 14, 2013
This got wrapped up in a larger discussion about whether or not installing client tools is appropriate, with some strong (and not necessarily wrong) opinions on either side. I confess I didn’t get involved, mostly because I find it hard to have a serious discussion in 140 character snippets. So now I’ll blog about it!
I’m the kind of DBA that is a “jerk”. I say no a lot and prefer, in production, not to take any more action than absolutely necessary until it’s proven that the action will do no harm. I don’t get off on it nor do I enjoy giving people the hand. I’m just…..careful. We’ve all been burned and it’s my responsibility to make sure that we’re protecting the company’s assets, both data and the systems that data lives on.
The problem with client tools is they can create avenues for danger. For example, if I install SQL Server Management Studio and the Sysinternals tools, I’ve created a way for a local administrator on that server to log in to my SQL Server as an administrator, even if it wasn’t my intention to grant him that access. This can be extremely useful (such as a situation where you do lose your SQL admin logins), but there’s inherent risk there. Other tools can create similar risk, so my view is to try and reduce this risk by minimizing client tool installs.
Another problem with client tool installs is that client tools take resources away from SQL Server (or other processes that the server is hosting up). I know, I know…we live in an age where RAM and CPU are plentiful, but I still get protective of my stuff. These are MY toys and, since I’m a jerk, I hate sharing. By restricting client tool installs, I proactively prevent this sort of sharing and keep folks out of my sandbox.
Thirdly, by putting client tools on to server, I provide a crutch for those who feel they have to do all their work directly on the server. This is a bad practice, even if you have resources. You’re not just taking stuff away from SQL, things you could also seriously damage something without even intending to. Accidentally shut down the box? Easy. Delete or corrupt critical files? Piece of cake. I often think of working on the server as playin around in the middle of a minefield and why put a tool I need in the middle of that minefield? If the tool isn’t installed, there’s no reason to log in to a server, so it doesn’t even become an issue.
This is one of many reasons I’m so high on Server 2012 Core. By the very lack of its GUI, a lot of people will shy away from tools. And the tools are there, but let’s be honest with each other here: Most of us Windows folks love our dialog boxes and ‘Ok’ buttons, our drop ‘n drag paired with right clicking. Command line interfaces are an anathema and we will avoid them as a preference.
I get it, though. There are plenty of valid reasons why you would install those tools. It can speed up troubleshooting and there are certain things that can only be done from the machine itself. Plus, if your box is secure, you can reduce the risk of having those tools out there. I would argue that, even with the box secure, minimizing your client tool installs will reduce your risk even further.
I challenge folks to really, REALLY ask themselves: Do you really need use those client tools on the server? In most cases, you probably don’t. And if you don’t need to use them on the server, then why are you installing them in the first place?