Renaming Fabric SQL-endpoints in SSMS

One of the many qualities of OneLake in Microsoft Fabric is, that it automatically builds SQL Analytics Endpoints for all your delta-tables.

In AP Pension, we have a lot of SQL users, who work in Management Studio (SSMS). A very useful feature in Microsoft Fabric is therefore the ability to copy a connection string for the SQL-endpoints and let the users connect to the data in OneLake like if it were a SQL Database, like they are accustomed to.

There is a unique connection string for each workspace, which makes perfect sense. However, at the moment, there is no easy way to change the connection string to make it readable to the human eye. If you are only working with one workspace at a time in SSMS, it doesn’t really matter but if you work with data in more than one workspace, the autogenerated connection names become really tiresome.

Consider the following (realistic) example, where we have 3 workspaces in Microsoft Fabric: Development and Test (that run on the dev-capacity) and production, that run on the production capacity.

When working in the Fabric GUI, you are never in doubt about which workspace, you are working in, but in SSMS it is very hard to determine which is which … even if the full names are not anonymized like they are in the screenshot below.

To get around this problem, we have found it useful to use an old SSMS feature: Registered Servers.

Servers can be registered manually by opening the Registered Serves Window and making Server and Server Group Registrations, but as I will show later, the process can also be automated via scripting.

In the Registered Servers window, you can create new server groups and register specific servers within these groups.

Here I create a server group called Fabric

And within this group, I register the SQL Analytical endpoints for my dev, test and prod workspaces for APData

Servers need to be registered with a valid user and can be given a readable name and description. The connection string is copied from the relevant Fabric workspace and entered under "Server name”.

Once saved, registered server will be available whenever SSMS is launched.

Although the registered server name is displayed in SSMS, there can still be some difficulty navigating between open queries against different workspaces in SSMS, since the connection name and not the registered server is dispalayed as the connection at the bottom of the SSMS window.

Therefore we also recommend to update the color scheme for the connections under the tab Connection Properties. A suggested color scheme could be white for dev, grey for test and red or black for production

... and the end result is seen below, where I as a user have all three connections open, and can see, that I am currently querying APData (test)... both from the header and the color of the footer.

The registration of servers can also be managed centrally or imported from a script. There is a lot of documentation on this on-line, but I feel that the best way to get acquainted with the notation is to export the scripts, that we have just created, and look at them.

Importing a registered server is just a matter of pointing to the supplied .regsrvr-file. If the file is manually created by another user, there may be a need for changing the username before saving the result.

In AP Pension, we are currently working on a method for automatically generating and distributing the relevant .regsrvr-files for our SQL users as part of our metadata-driven data delivery framework … but more about this later.

?