After you have set up all of your registered servers the way you want them, you should be able to export the whole set under any server group by right-clicking the Local Server Groups node in View > Registered Servers and selecting Tasks > Export...
You can save individual servers or the whole lot. When you lose them, you can then import the file you backed up to reset them. I did not test (sorry, on the move) but this should save off all your servers, their credentials (which should be encrypted if present), and any personalized settings including custom colors.
(I suspect you are losing them because you are using a roaming profile or have some other AD/Group Policy perhaps resetting your profile.)
These settings are also stored in RegSrv.xml, which is going to be in a path something like:
C:\Users\<you>\AppData\Roaming\Microsoft\Microsoft SQL Server\<version>\Tools\Shell\
You will see lines like this, which you can change on the fly. I believe they will require a restart of Management Studio though, and you'll have to map your desired RGB color with the int equivalent (there are many calculators available online). Carriage returns added by me:
<RegisteredServers:UseCustomConnectionColor type="boolean">
true
</RegisteredServers:UseCustomConnectionColor>
<RegisteredServers:CustomConnectionColorArgb type="int">
-16777216
</RegisteredServers:CustomConnectionColorArgb>
The point is more that you can back up that RegSvr.xml file to save all your settings somewhere, and restore them whenever this happens. But you should also look into why this file is getting reset or why your profile gets re-created (that may be a question your system administrator can answer even if you can't).
The custom connection settings you set in the Connect to Server dialog are stored separately; these are in a file called SqlStudio.bin, in the following path:
C:\Users\<you>\AppData\Roaming\Microsoft\SQL Server Management Studio\<ver>
However, knowing where the file is will not really help you - the information about servers is largely not stored in a human readable format, and after connecting to a server with a custom color set, the change I saw when I performed a diff against the before and after files yielded nothing intelligible (and in fact I can't even confirm that that color change is saved there, except that when I open SSMS again it remembers it, like all the server credentials I've ever used). So:
- You can't very easily hand-modify the SqlStudio.bin file to put your chosen colors back in there.
- While it's possible you could back up your SqlStudio.bin file at a time when you've connected to your servers and SSMS currently remembers all of the settings, it would be missing anything else you've changed since you backed it up, so you might lose other things.
Therefore, I propose that it would just be much easier to just use registered servers, and stop manually setting a color when you connect, because with a moving profile you're constantly going to get SqlStudio.bin blown away (other things you can easily save off and import when that happens, e.g. fonts and colors).
With registered servers, you can keep a separate server group for the important servers where you want to be careful, and keep the other ones in a different group. And you can back them all up so it is easy to restore them on a different machine, when they get blown away, when your profile gets nuked again (or fixed), etc.
Best Answer
SQL Management Studio (versions prior to 2016)
Unfortunately, there are some caveats that make using Application Intent in SQL Management Studio somewhat painful:
To connect manually with ReadOnly intent, after bringing up the Connect to Server dialog from the Object Explorer, users must remember to:
The caveats that apply are as follows:
SQL Management Studio (versions 2016 or later)
SQL Server Management Studio 2016 or higher can connect with Read Only Application Intent (using the same 6 steps as prior versions) and it does store the Additional Connection Parameters. There are still some caveats:
Third-Party Products
LinqPad stores the whole connection string including Application Intent and the database when you save a connection and therefore might be a viable option for performing Read Only queries against Always On databases.