Should I install SSMS on a server running SQL Server?

There’s a lot of advice out there on the internet that suggests that you should not install SSMS on your database servers running SQL Server.

This came up at work recently, where I was asked “Should we install SSMS on our database servers?” and my answer is:

1000%! Heck Yes. Install SSMS on your servers!

“But wait, Andy. That’s not a best practice!” you say?

The pseudo best practice of “don’t install SSMS” is a misguided one–advice that I even fell into repeating in the past. However, that’s actually a proposed solution to a best practice, rather than being itself a best practice.

“OK Andy. Stop saying “best practice” and get to the point”

(I know you were thinking that!)

Yes, install SSMS on your servers. Eventually, you’re going to have an emergency situation where the server is in trouble, you need to respond, and connecting remotely is problematic. Maybe your laptop is dead. Maybe there’s a network issue. Maybe your server is being DDoS’ed. Maybe the server got knocked off the domain and you’re having auth issues. Maybe Kerberos is refusing connections because of SPN issues. Or maybe you’re on an airplane trying to fix a problem from 30,000 feet on a low bandwidth connection and SSMS pulls back too much data over that network connection.

In all those situations, your fastest response to fix the problem might be to RDP directly to the server. At most of the jobs I’ve had over my career, having the fastest possible resolution to downtime is extremely important. Every single one of the situations I list above are scenarios that have happened to me in real life over the years, and every time, having SSMS on the server saved my bacon.

SSMS is my security blanket. I’ve been using it for 15 years, and just about everything I need to do during a critical response will be fastest if I do it in SSMS. In some cases, PowerShell is the tool of choice–but not always. Azure Data Studio and I are building our relationship, but there’s still some work to do before it can be my DBA daily driver. SSMS is still the tool I need in an emergency–at least for now.

But there’s a catch. My advice is still:

Don’t use SSMS on your servers

SSMS should be on your servers for an emergency, not for every day use. If you find you have any operational tasks where you’re logging in to the server to use SSMS locally as standard operating procedure, reconsider your process. My goal is to only use SSMS on the server if there’s an emergency.

All your normal processes should be things that you can do from your desktop, or from a central management server. If you have processes that involve “Log in to the server via RDP…” you should keep track of those processes, and revisit them so that you can eliminate the need to RDP to the server directly.

Why not use SSMS on the server itself?

There are a bunch of reasons, but lets hit a few of the bigger/fundamental ones.

Firstly, just logging in via RDP can cause a pretty decent resource spike. Establishing your session & running your login scripts from Active Directory will cause a memory & CPU spike. If you watch Task Manager (or your monitoring software) while a user logs in via RDP, the CPU spike can be noticeable, particularly on a smaller server. On one (random) server I looked at, I could reliably see one CPU core bounce to 100% for almost a minute. In the past, I’ve seen clunky login scripts cause an even larger impact.

Another reason is that SSMS is a resource hog. Go ahead & check Task Manager on your desktop right now. On my work computer, my SSMS is currently using over 500MB of memory–and I only have a dozen tabs open! Now imagine your entire DBA team all has an SSMS running on the server in your separate RDP sessions. That’s a bunch of memory & CPU that you are taking away from your server’s processing capacity.

Some tips to avoid running SSMS on the server

You can’t just say “NO! STOP DOING THAT!” without making sure there is a viable alternative. In some cases, folks will RDP to work directly on the server out of habit or comfort. In other cases, they might have a legitimate reason where they don’t have viable alternatives. By keeping track of those processes where it’s necessary, you can eliminate roadblocks and make it easier for folks to comply with not logging directly into the server via RDP to do their work.

  • Have a management server / jump server – Your team should have at least one server in each data center that you can remote desktop into to do work. This server should have an RDP license that allows everyone on your team to connect simultaneously, and have enough resources for you to all work in parallel. This ensures that you have a workspace physically close to your servers–so client tools will be fast in getting results back, and you don’t have to worry about network disconnects causing long-running scripts to fail. I generally prefer to work from my laptop, but if I have to leave something running overnight, or if I am on a low-bandwidth/high-latency network connection (like airplane wifi), RDP to a server is a better experience than SSMS over that slow network connection.
  • Learn remote management tools – Windows & SQL Server both provide great remote management tools. Learn about PowerShell remoting, Windows Admin Center, Remote Server Administration Tools (RSAT), as well as any other management tools your employer might have.
  • Log out idle connection on your database servers – You can set RDP to automatically log off an idle session via Group Policy. Just go to .../ Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / Session Time Limits and you’ll find the settings to enable idle logoff. This will help ensure that if someone does log in to perform a task, their session will get automatically cleaned up, and prevent a pile up of long-idle sessions all hogging resources. It also reinforces the behavior you want–after folks lose unsaved work a few times from the automatic logoff, they’ll start to remember to depend on other processes.
  • Ensure remote admin connections are enabled – As part of your standard configuration, I recommend running EXEC sp_configure 'remote admin connections',1; and opening port 1434 to your management servers & DBA workstations. This will allow you to connect to the Dedicated Admin Connection(DAC) remotely via TCP. If this isn’t enabled, then the DAC only listens on the server’s loopback IP ( The DAC is necessary/helpful in certain situations–such as when your server hits the 32k connection limit & stops accepting new connections.

So go ahead and install Management Studio on all your servers. But only use it in an emergency.


  1. What are your thoughts on keeping up with the version? Since SSMS gets released every 3 months or so now, do you worry about keeping it current or just having the tool available checks the box?

    • How do you keep SQL Server up to date? I assume you have a patching process where you update the DB engine on your production servers. How do you push out those Windows Updates & CU installs? Depending on that process (or those processes), they are different. At past jobs, CU install was manual–but we would install SSMS updates & CUs in the same patch window/process (both manually). At my current gig, we use Puppet to keep software up to date, and that makes life a lot easier when managing large SQL Server estates. There are other alternatives to Puppet–SCCM, chocolatey, PowerShell, etc–that can help make pushing out the install to many server easier & automated.

  2. Some small mention should probably be made toward extension management. If you’ve got “power users” who go hard on RedGate extension customisations or personal snippets they’ve collected on the laptop they’ve had for 6 years or a “C:\Users\Andy\Documents\SQLScripts” folder they need to do their work – then those resources may not be available in an emergency and can cause headaches. Even if you you don’t want to bother syncing user settings for all tha thingz like that, it’s good to be mentally prepared for what is (and isn’t) available in the clutch.

  3. I think I have another situation where it is needed. Since 2016 SSMS has been detached from the SQL install. You also had SSDT for SSIS/SSAS/SSRS work. Now when we installed SQL 2016 we used SSMS 16 on both workstations and SQL Servers. We installed SSMS 17.9.1 on our servers as this had improvements for AG’s. Little known to us DBA’s and analyst had also installed SSMS 17.9.1 and created/updated SSIS packages using it. The migration Workstation didn’t have 17.9.1 and couldn’t find a component because the different versions use different file locations. Once the 2 workstations started to use 17.9.1 the SSIS packages could be deployed and I am thinking because we had 17.9.1 on the actual server the packages ran. Of course the SSMS 18 version can go into a different set of file locations. We will install SSMS 18.5 on a SQL server with the exact same file location as will go on the workstations.

1 Trackback / Pingback

  1. Installing SSMS on Servers Running SQL Server? – Curated SQL

Comments are closed.