SSMS Registered Servers–Key not valid for use in specified state

After exporting the registered servers from SQL Server Management Studio’s “Registered Servers window” and then importing the exported list into a new machine. You may encounter the following error if passwords were stored against the servers…

Registered Servers Key not valid for use in specified state. (System.Security)

This is due to the encryption key used to encrypt the passwords being specific to the machine the server details were exported from and it not existing on the new machine.

Even more annoying, this message will pop up multiple times, once for each registered server in the list that has an issue.
The servers with issues will be absent from the registered servers window in the new machine SSMS GUI, even though they exist in the list behind the scenes.

By the time I got around to fixing this, the original machine was long gone. The recommended approach of re-exporting the server list without passwords and re-importing it into the other machone's SSMS was no longer an option.

So to solve this problem needed to remove the passwords from the affected registered servers. Once the passwords have been removed, the registered server list is properly populated again with the servers that were previously missing. The server properties can then be simply edited to put the password back in for each server affected.

This registered server list is populated from an xml file found in a location on your machine similar to these, depending on SSMS version and where it was installed:

C:\Users\{username}\AppData\Roaming\Microsoft\Microsoft SQL Server\{sql version}\Tools\Shell\RegSrvr.xml

C:\Users\{username}\AppData\Roaming\Microsoft\SQL Server Management Studio\RegSrvr17.xml

On opening this "RegSrvr.xml" file and examining the XML found inside with an intent to remove the password I hit a snag. The snag was that some servers had been added to the registered servers after the server import resulting in a mix of duplicated entries in the XML as some of those servers were named the same as the ones causing the error. Scrolling through the XML in Notepad, it was not easy to tell which was which, I didn't want to remove passwords for servers that were ok.

To help work out which entries were showing in the user interface, I went back into the registered server list in SSMS and added a distinct comment that I could identify in the XML later, to all the servers that I could edit and were showing, i.e. the server entries that were ok. After exiting again to update the XML file, I simply searched for “Password=” in the file and removed the matching text Password=”jdsalkfjdalksjd”;, between password and semicolon. If you are familiar with regular expression search and replace, you may use the regexpression-

password=[^;]*; 

Note that I only removed the XML password property of the connection string where there was not also a description node like that shown below. The MyMarkerText was the unique text that I manually put in each connection earlier using the SSMS user interface, I had basically tagged the known ok connections with this unique text.

<RegisteredServers:Description type="string">**MyMarkerText**</RegisteredServers:Description>

• Save the xml file
• launch SSMS.

The error will no longer appear and the missing registered servers will be available to see again.

You must now right click and edit the properties of each to manually restore the passwords.