Never say never again: Keeping Your SSMS Server List Safe in 2026

Twelve years ago 🤯 I wrote a quick post about never losing your server list in SSMS again. The short version was: copy one file, stay sane. The file was called SqlStudio.bin, and the trick still works today if you are on an old enough version.

But if you are running SSMS 19, 20, 21 or 22 on Windows 11, the file is gone. The settings have moved, and the format has changed. The principle is the same, but the file you need to grab is different.

Here is the updated version for 2026.


What Changed

In the older versions of SSMS, the registered server list was stored in a binary file:

C:\Users\<PROFILE>\AppData\Roaming\Microsoft\SQL Server Management Studio\<VERSION>\SqlStudio.bin

From SSMS 19 onwards, the file you want is:

C:\Users\<PROFILE>\AppData\Roaming\Microsoft\SQL Server Management Studio\<VERSION>\UserSettings.xml

Same idea, different file, plain XML instead of binary. That last part is actually an improvement: you can open it, read it, and understand what is in there before you copy it anywhere.


Where to Find It

On Windows 11, with SSMS installed and a server list you want to keep, navigate to:

C:\Users\<your Windows username>\AppData\Roaming\Microsoft\SQL Server Management Studio\

You will see one folder per installed SSMS version. I currently have four:

  • 19\
  • 20\
  • 21\
  • 22\

Inside each one, look for UserSettings.xml. That is the file that holds your registered servers.

The AppData folder is hidden by default in Windows 11. If you do not see it in Explorer, type the full path into the address bar, or go to View > Show > Hidden items.


What to Do With It

The same logic as 2014 applies:

  1. Make a copy of UserSettings.xml from your current machine.
  2. Store it somewhere you can get to it: OneDrive, a network share, a USB drive, wherever works for you.
  3. On a fresh install, copy the file into the correct version folder before opening SSMS.

SSMS reads the file on startup. If the file is in place when SSMS opens, your registered servers appear as if you never left.

If you have multiple SSMS versions installed side by side and maintain different server lists in each, you need a separate copy per version. They do not share the file.


One Thing Worth Knowing

The file is XML, so you can also merge server lists manually if you need to combine two environments into one. I have not done this in a scripted way, but looking at the structure it is readable enough that it would not take long to figure out.

If you are already using Azure Data Studio instead of or alongside SSMS, the settings are stored differently again. That is a separate post.


The short version: the file changed, the folder structure stayed the same, and the trick still works. Copy UserSettings.xml before you reinstall anything.

Filtering SQL Agent Jobs

I suspect that any developer who has been near a SQL Server for more than just a short while, you will be able to recognize a list of SQL Agent jobs that can no longer can be seen in its full extent without having to scroll.
A tip to make it easier for yourself is that you can filter the list.

Just right-click ‘Jobs’ and select Filter->Filter Settings and you’re off.

Looong SQL Agent Job List
Looong SQL Agent Job List

 Then punch in the filtering you’d like to have

SQL Agent Jobs Filter
SQL Agent Jobs Filter

And voila, your list of jobs are filtere to show only the ones you want:

SQL Agent Jobs Filtered
SQL Agent Jobs Filtered

Never lose your server list in SSMS again…

Having to install new laptops, re-install old ones, configuring virtual servers or whenever you get the opportunity to install SQL Server from scratch, you always end up with an empty list of servers, when you try to connect through SQL Server Management Studio (SSMS).

Empty List

There is a way around this minor, but still sometimes very annoying issue.
The information is stored in one file only, on the profile you are currently logged on to. So copying this file, from an existing setup or a shared repository (like SkyDrive or TFS), to the new environment will bring you up to speed really quick.

The file is named SqlStudio.bin and can be found at <DRIVE>:\Users\<PROFILE>\AppData\Roaming\Microsoft\SQL Server Management Studio\<SQLVersion>

Disclaimer:
I have not tested if any third-party tools register anything in this file, so beware and be sure to have the original file ready, in case of dissaster

 

Server and column collation conflicts in properties of a login

Problem:

Error: Cannot resolve the collation conflict between “Danish_Norwegian_CI_AS” and “SQL_Latin1_General_CP1_CI_AS” in the UNION operation. (Microsoft SQL Server, Error: 468) when clicking “Securables” in properties of a server login.

Setup:

Server is set up with collation: SQL_Latin1_General_CP1_CI_AS
The database, or more precisely, the columns are created with collation: Danish_Norwegian_CI_AS
Login is set up with default language: English

The following steps will reproduce the error:

1. See properties for the server-login:

2. Click “User Mapping”

3. Click “Securables”

4. Observe error:

Cannot resolve the collation conflict between “Danish_Norwegian_CI_AS” and “SQL_Latin1_General_CP1_CI_AS” in the UNION operation. (Microsoft SQL Server, Error: 468)

Solution/Impact:

Can anyone say anything intelligent about this issue?

SSMS Quick Tip

If you ever need to test Analysis Services roles, you can easily do so either by browsing the cube or by means of a query.

When browsing a cube through SQL Server Management Studio (SSMS) or Bisuness Intelligence Developer Studio (BIDS), you can select one or more roles to be enforced on data, by clicking the little “user” icon in the top left corner of the cube browser:

You will then be able to select on or more of the roles available on the database via a dialog:

This way of browsing roles has the following pros and cons:
Pros: Visual confirmation of PC Hierarchies
Cons: A lot of clicking top verify permission integrity

The other way of testing roles is through SSMS is by creating an MDX query. The trick is to click the options button when the connection dialog is active. The last tab allows you to specify additional connection parameters. The Roles property is described in detail at technet. Basically it’s a comma seperated list of roles (case sensitive). The trick is showed in the screendump below:

Pros: Custom queries
Cons: No visual confirmation of integrity, can be hard to visually confirm permissions on a PC hierarchy as an example