Updated for SSMS 21 and later: This is a new, rewritten version of my earlier article for SQL Server Management Studio (SSMS) 21 and later. SSMS 21 is built on Visual Studio 2022 and is now a native 64-bit application. So it now installs to
C:\Program Filesinstead ofC:\Program Files (x86)by default. It also uses the Visual Studio Installer.
Some of the folders and files that older guides, including the original version of this one, tells you to move them, aren't where they used to be. If you're still on SSMS 20 or earlier, the original article still applies.
If you are reading this, it's probably because you too have this rare need to clear the SSMS cache for some kind of troubleshooting.
When I'm troubleshooting a connection issue that might be caused by a cached or stale connection, the first things that come to mind are the DNS client cache and, occasionally, the ARP cache. The SSMS cache rarely makes the list. But there are times when it's exactly the right suspect: a new table that IntelliSense refuses to acknowledge, an old server name that keeps showing up in the connection dialog, or SSMS just behaving oddly after an upgrade.
"The SSMS cache" is really several caches
Almost everything in the computer world uses some kind of cache, and SSMS is no exception. The catch is that "the SSMS cache" isn't one thing. It's at least four, and they're cleared in different ways:
| What's cached | What it does for you | How to clear it |
|---|---|---|
| IntelliSense object metadata | Table, column, and function names for completion lists | Ctrl+Shift+R in the query window |
| Connection history (MRU, most recently used) | Server names, authentication types, and user names in the connection dialog | Remove the entry in the connection dialog, or reset the per-user data |
| Environment settings | Fonts, colors, window layouts, and everything under Tools > Options | Tools > Import and Export Settings > Reset all settings |
| Microsoft Entra ID tokens (SSMS 22) | Avoids reauthenticating on every connection | Help > Clear Entra ID Token Cache |
Refresh The Stale IntelliSense
IntelliSense helps you by keeping a cached copy of database metadata (information about objects such as tables, columns, and functions), so it can auto-complete names as you type without asking the server every time.
The trade-off is that the copy can fall behind. IntelliSense doesn't instantly know about database objects created by another connection after your editor window connected to the database. So if a colleague adds a table while your query window is open, you may get a red squiggle under a perfectly valid name. There are three ways to refresh the object cache in your active SSMS window:
- Press Ctrl+Shift+R.
- Select Edit > IntelliSense > Refresh Local Cache.
- Disconnect the query window and reconnect.
You may also see the lag after your own DDL in the same window. If you do, the fix is the same.
If a refresh doesn't help, the problem probably isn't the cache. The other typical culprits are 1) If you have SQLCMD mode enabled, it turns IntelliSense off 2) a syntax error above the cursor can stop parsing 3) a lost connection breaks completion lists and 4) objects you don't have permission to see won't appear in them. No amount of cache clearing can grant you permissions.
Curious what IntelliSense actually asks the server? Capture your own session with Extended Events (or Profiler). The metadata queries typically show up with the client application name Microsoft SQL Server Management Studio - Transact-SQL IntelliSense under your login.
Removing one unwanted server in the connection list
If you just want SSMS to forget a single old server name, you don't need to clear anything else. Open the Server name dropdown, hover over the entry, and press Delete.
SSMS 21 also introduced a Modern connection dialog with its own Recent and Favorites lists, so the exact controls depend on which dialog you have enabled under Tools > Options > Environment > Connection Dialog.
If the problem is a login failure right after you were added to a Microsoft Entra ID group, that's a token cache issue, not a connection-history one. Use Help > Clear Entra ID Token Cache. That menu item was introduced in SSMS 22.0, so don't go looking for it in SSMS 21.
Save your settings before you clear anything
Your customizations (basically everything under Tools > Options) live in a Visual Studio settings file. In older SSMS versions, guides pointed to NewSettings.vssettings under a version folder. In SSMS 21 and later, I'd rather not hard-code a path, because Microsoft doesn't document one for these releases. The documented method to backup/export settings is to use the built-in Import/Export Settings wizard:
- Select Tools > Import and Export Settings.
- Choose Export selected environment settings and save the
.vssettingsfile somewhere safe.
The same wizard has a Reset all settings option. If odd editor or layout behavior is your only complaint, try that before moving or deleting any folders.
If you use Registered Servers, export them too: View > Registered Servers, right-click the group, then Tasks > Export. User names and passwords are excluded by default. SQL Server Authentication passwords are stored per user, so you'll have to reenter them after an import.
Clearing the SSMS cache folders
When the targeted fixes don't help and you suspect damaged per-user files, close all SSMS instances, copy RegSrvr*.xml if you want to keep your Local Server Groups, remove the files in these two folders, and restart SSMS (Microsoft Learn: Clear SSMS cache files):
%USERPROFILE%\AppData\Local\Microsoft\SQL Server Management Studio
%USERPROFILE%\AppData\Roaming\Microsoft\SQL Server Management Studio
SSMS 21 and later have a wrinkle here. These releases also keep version-specific data under Microsoft\SSMS. Microsoft documents %APPDATA%\Microsoft\SSMS\<installid> as the SSMS 22 location for activity logs. Under %LOCALAPPDATA%\Microsoft\SSMS you'll typically find one subfolder per installed release, named something like 21.0_xxxxxxxx, and these appear to hold per-user data such as connection history. Microsoft hasn't document their contents, and its cleanup procedure doesn't mention them. So, on SSMS 21 and later, clearing only the two documented folders may leave your connection history untouched. The suffix differs from machine to machine, so look before you move or delete them.
My advice is to move these folders instead of deleting them. A move gives you the same clean start, plus an undo button.
- Export your settings and registered servers (see above).
- Close every SSMS window.
- Move the folders to a backup location. Keep Local and Roaming separate.
- Start SSMS and repeat the action that was failing.
- Restore only what you need. If you put everything back right away, you'll never know whether the cache was the problem.
When SSMS starts with empty folders, it rebuilds them. You may see first-run prompts or messages about missing settings. If a message isn't what you expected, read it and write it down; don't just click through.
One security note: contents inside some files aren't plain text, but that doesn't make them harmless. They hold your connection details and, if you've used Remember Password, saved credentials. Saved passwords are encrypted and tied to your Windows account, so they aren't readable as plain text. Even so, treat your backup copies like any other file that holds credentials: keep them in your own profile, and delete them once you no longer need them.
A PowerShell script to back up and clear the cache
Here is the script I use to back up and clear the SSMS cache folders. By default it runs as a dry run: it shows what it would move and changes nothing. Add -NoDryRun to actually move the folders.
Out of the box, it targets only the two folders in Microsoft's procedure. Add -IncludeSsmsData to also move Microsoft\SSMS in Local and Roaming. That resets connection history and per-user data for every SSMS 21+ release you have installed, not just one.
Before you run it:
- Use Windows PowerShell 5.1 or PowerShell 7 on Windows, as the same Windows account that runs SSMS. It doesn't connect to SQL Server, so no database permissions are involved.
- Close SSMS. The script refuses to run if
Ssms.exeis running.
- Keep the backup on the same drive as your profile.
Move-Itemcan't move a folder to a different volume (Microsoft Learn: Move-Item), so the script stops if your profile is redirected to another drive or a network share.
- Before it moves anything, the script writes
HOW-TO-RESTORE.txtto the backup folder. The file lists each original path, explains how to restore by hand, and includes PowerShell code that puts the folders back.
- If something fails partway, the script stops and doesn't roll back. The restore notes still cover you: the restore code puts back whatever was moved and skips anything that wasn't.
#requires -Version 5.1 <# .SYNOPSIS Backs up AND CLEARS SQL Server Management Studio (SSMS) per-user folders. .DESCRIPTION Verifies SSMS (Ssms.exe) is not running, then MOVES SSMS per-user folders from AppData to a timestamped backup folder. Moving the folders clears them while keeping a copy you can restore from. Default targets are the two folders in Microsoft's "Clear SSMS cache files" procedure: %LOCALAPPDATA%\Microsoft\SQL Server Management Studio %APPDATA%\Microsoft\SQL Server Management Studio -IncludeSsmsData also moves the folders SSMS 21 and later use for version-specific data, such as connection history: %LOCALAPPDATA%\Microsoft\SSMS %APPDATA%\Microsoft\SSMS This resets EVERY installed SSMS 21+ release for the current user. Before moving anything, writes HOW-TO-RESTORE.txt to the backup folder. It lists the original paths, explains how to restore, and includes PowerShell code that puts the folders back. Runs in DryRun (preview) mode by default. Use -NoDryRun to make changes. This is not an IntelliSense refresh. For stale IntelliSense, press Ctrl+Shift+R in the query window instead. .PARAMETER NoDryRun Perform the move. Without this switch, nothing is changed. .PARAMETER IncludeSsmsData Also move the SSMS 21+ "Microsoft\SSMS" folders (see DESCRIPTION). .PARAMETER BackupRoot Optional local-drive folder for the backup. Defaults to Documents\SQL Server Management Studio - Backup. Must be on the same drive as the folders being moved, because Move-Item cannot move a folder to a different volume. .NOTES Updated: 2026-10-05 Version: 2.1 Status: Tested on Windows; worked as expected. Further testing planned. Always run the dry run first. .EXAMPLE .\Backup-SsmsCache.ps1 Previews the operation (DryRun default). .EXAMPLE .\Backup-SsmsCache.ps1 -NoDryRun Backs up and clears the two Microsoft-documented folders. .EXAMPLE .\Backup-SsmsCache.ps1 -IncludeSsmsData -NoDryRun
Also backs up and clears the SSMS 21+ version-specific data folders, for every SSMS 21+ release installed for the current user. This is close to a fresh-install state but not guaranteed to match it; some state, such as Entra ID or GitHub sign-in, may live elsewhere.#> [CmdletBinding()] param( [switch]$NoDryRun, [switch]$IncludeSsmsData, [string]$BackupRoot ) Set-StrictMode -Version Latest $ErrorActionPreference = 'Stop' function Assert-SsmsClosed { if (Get-Process -Name 'Ssms' -ErrorAction SilentlyContinue) { throw 'SSMS is running. Close every SSMS window, then run this script again.' } } $mode = if ($NoDryRun) { 'LIVE' } else { 'DRY RUN' } Write-Output "[$mode] SSMS per-user folder backup + clear" Assert-SsmsClosed if (-not $env:LOCALAPPDATA -or -not $env:APPDATA) { throw 'LOCALAPPDATA or APPDATA is not set. Nothing was changed.' } # --- Backup location ---------------------------------------------------------- if (-not $BackupRoot) { $BackupRoot = Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'SQL Server Management Studio - Backup' } if ($BackupRoot -notmatch '^[A-Za-z]:\\') { throw "BackupRoot must be a local-drive path such as C:\SsmsBackup. Got: $BackupRoot" } $BackupRoot = [IO.Path]::GetFullPath($BackupRoot) $BackupPath = Join-Path $BackupRoot (Get-Date -Format 'yyyyMMdd_HHmmss') # --- Build the list of folders to move ---------------------------------------- $candidates = @( @{ Label = 'Local\SQL Server Management Studio'; Source = Join-Path $env:LOCALAPPDATA 'Microsoft\SQL Server Management Studio' } @{ Label = 'Roaming\SQL Server Management Studio'; Source = Join-Path $env:APPDATA 'Microsoft\SQL Server Management Studio' } ) if ($IncludeSsmsData) { $candidates += @{ Label = 'Local\SSMS'; Source = Join-Path $env:LOCALAPPDATA 'Microsoft\SSMS' } $candidates += @{ Label = 'Roaming\SSMS'; Source = Join-Path $env:APPDATA 'Microsoft\SSMS' } } # Validate everything before moving anything. $plan = @( foreach ($c in $candidates) { if (-not (Test-Path -LiteralPath $c.Source -PathType Container)) { continue } $src = [IO.Path]::GetFullPath($c.Source) if ([IO.Path]::GetPathRoot($src) -ine [IO.Path]::GetPathRoot($BackupRoot)) { throw "Different drive or redirected profile: $src. Choose a -BackupRoot on the same drive or move this folder manually." } if ($BackupRoot.StartsWith($src.TrimEnd('\') + '\', [StringComparison]::OrdinalIgnoreCase)) { throw "BackupRoot cannot be inside a folder being moved: $src" } [pscustomobject]@{ Label = $c.Label Source = $src Destination = Join-Path $BackupPath $c.Label } } ) if ($plan.Count -eq 0) { Write-Warning 'None of the targeted SSMS folders exist. Nothing to clear.' return } Write-Output "Backup + clear target: $BackupPath" foreach ($p in $plan) { Write-Output " $($p.Label)" Write-Output " From: $($p.Source)" Write-Output " To: $($p.Destination)" } if (-not $NoDryRun) { Write-Output "`n[DRY-RUN COMPLETE] Nothing was changed. Use -NoDryRun to execute." return } # --- Restore notes ------------------------------------------------------------ # Wraps a path in single quotes for the generated code, doubling any embedded # single quote (for example, a user profile named O'Brien). function ConvertTo-QuotedLiteral([string]$Text) { "'" + $Text.Replace("'", "''") + "'" } $RestoreFile = Join-Path $BackupPath 'HOW-TO-RESTORE.txt' $folderLines = foreach ($p in $plan) { " @{{ Backup = {0}; Original = {1} }}" -f (ConvertTo-QuotedLiteral $p.Destination), (ConvertTo-QuotedLiteral $p.Source) } $nl = [Environment]::NewLine $folderList = foreach ($p in $plan) { " $($p.Label)$nl Original: $($p.Source)$nl Backup: $($p.Destination)" } $restoreNotes = @" SSMS CACHE BACKUP - HOW TO RESTORE ================================== Created: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Computer: $env:COMPUTERNAME User: $env:USERDOMAIN\$env:USERNAME The following folders were scheduled to be MOVED here from AppData: $($folderList -join $nl) If the backup script reported an error, some folders may not have moved. A folder was moved only if it exists under this backup folder. BEFORE YOU RESTORE ------------------ - Restore as the same Windows user shown above. - Close every SSMS window. - Consider restoring only what you need. If the cleanup fixed your problem, restoring everything may bring the problem back. - This folder can contain saved connection details and credentials. Keep it private, and delete it once you no longer need it. RESTORE BY HAND --------------- For each folder listed above: 1. If SSMS recreated a folder at the Original path, rename it (for example, add .recreated to the name). Do not merge the two. 2. Move the Backup folder back to the Original path. 3. Start SSMS and confirm your settings and connections are back. RESTORE WITH POWERSHELL ----------------------- Copy everything between the two marker lines into a PowerShell window (or save it as Restore-SsmsCache.ps1 and run it). It restores every folder that is still in this backup and renames any folder SSMS recreated to <name>.recreated_<timestamp>. It does not delete anything. # ----- BEGIN RESTORE CODE ----- `$ErrorActionPreference = 'Stop' if (Get-Process -Name 'Ssms' -ErrorAction SilentlyContinue) { throw 'SSMS is running. Close every SSMS window, then run this again.' } `$stamp = Get-Date -Format 'yyyyMMdd_HHmmss' `$folders = @( $($folderLines -join $nl) ) foreach (`$f in `$folders) { if (-not (Test-Path -LiteralPath `$f.Backup)) { Write-Warning "Not in backup (never moved, or already restored): `$(`$f.Backup)" continue } if (Test-Path -LiteralPath `$f.Original) { `$asideName = (Split-Path `$f.Original -Leaf) + '.recreated_' + `$stamp Rename-Item -LiteralPath `$f.Original -NewName `$asideName Write-Output "Renamed folder SSMS recreated to: `$asideName" } Move-Item -LiteralPath `$f.Backup -Destination `$f.Original Write-Output "Restored: `$(`$f.Original)" } Write-Output 'Restore complete. Start SSMS and check your settings and connections.' # ----- END RESTORE CODE ----- "@ # --- Move --------------------------------------------------------------------- $moved = @() try { New-Item -Path $BackupPath -ItemType Directory -Force | Out-Null # Write the restore notes BEFORE moving anything, so they exist even if a move fails. Set-Content -LiteralPath $RestoreFile -Value $restoreNotes -Encoding UTF8 Write-Output " Restore notes: $RestoreFile" foreach ($p in $plan) { Assert-SsmsClosed New-Item -Path (Split-Path $p.Destination) -ItemType Directory -Force | Out-Null Move-Item -LiteralPath $p.Source -Destination $p.Destination $moved += $p.Label Write-Output " MOVED: $($p.Label)" } } catch { Write-Warning "Stopped early. Folders already moved: $(if ($moved) { $moved -join ', ' } else { 'none' })" Write-Warning "Nothing was rolled back automatically. See $RestoreFile to restore." throw } Write-Output "`nSSMS folders backed up and cleared to: $BackupPath" Write-Output "To undo, follow the instructions in: $RestoreFile" Write-Output 'Start SSMS and retest the original problem before restoring anything.'
Here's what a successful run looks like with the default targets. Your user name appears where <UserName> is shown, and the timestamp folder name reflects when you ran the script:
To undo the cleanup, open HOW-TO-RESTORE.txt in the backup folder. Close SSMS, then either follow the manual steps or copy the code between the BEGIN RESTORE CODE and END RESTORE CODE markers into a PowerShell window. The restore code renames any folder SSMS recreated to <name>.recreated_<timestamp> before moving your backup back. It deletes nothing and never merges the old and new folders. Once you're happy, you can delete the .recreated_ folders and the backup yourself.
A few configuration files worth knowing
Some file names come up in nearly every SSMS cache discussion. Here's a short guide for SSMS 21 and later:
.vssettingsfiles: Visual Studio-format settings files that store fonts, colors, layouts, and editor preferences. Don't go hunting for the file; export and import it through Tools > Import and Export Settings.
RegSrvr*.xml: Your Local Server Groups in Registered Servers, which you build and maintain yourself. Keep a copy before clearing the cache folders. A.regsrvrexport is the cleaner backup.
- Connection history: Unlike registered servers, this list maintains itself: SSMS adds every server you connect to. In SSMS 18 through 20 it lived in
UserSettings.xml. In SSMS 21 and later it appears to live under the version-specificMicrosoft\SSMSfolders instead.
Ssms.exe.config: An application configuration file that sits in the installation folder next tossms.exe(by defaultC:\Program Files\Microsoft SQL Server Management Studio 21\Release\Common7\IDEfor SSMS 21), not in your profile. It isn't a cache file. Leave it out of any cleanup.
The short version
If IntelliSense is behind, press Ctrl+Shift+R. To get rid of one old server name, delete it from the connection dialog. For a sign-in problem after an Entra ID group change, clear the token cache. Clear the cache folders only when nothing narrower works, and move them rather than delete them so you can always get back to where you started.
