Part of the DBA-Tools Project.
Three Fallback Methods Deep, Because SSMS Uninstalls Don’t Always Go Cleanly
The manual SSMS uninstall walkthrough covers the standard path and the reinstall-won’t-go-clean escalation steps by hand. This script automates the same removal and goes further: for SSMS 21+, it tries vswhere-based detection, then a registry-command passthrough, then winget, in that order, before giving up. For SSMS 20 and below, it tries the WiX uninstaller, then winget, then a direct MsiExec product-code removal as a last resort. Real fallback depth, not a single command with no plan B.
Why This Many Fallback Layers Matters
- A single uninstall method failing doesn’t mean the machine needs manual cleanup. Corrupted Package Cache, a stale registry entry, or a
vswheremismatch are all things the next fallback layer is specifically built to route around. - Every attempt is logged, including which method actually succeeded, worth knowing when the same script runs across a fleet and a handful of machines needed the third fallback instead of the first.
- Verification happens after the uninstall, not just a trust-the-exit-code assumption. The script re-checks the registry for the specific entry it targeted before declaring success.
When to Run This Script
- Removing SSMS ahead of an SSMS 20-to-22 upgrade, where an in-place update isn’t possible
- Decommissioning a machine or removing SSMS from a box that no longer needs it
- Cleaning up after a corrupted or partial SSMS install that the standard Settings → Apps removal won’t touch
The Script
# uninstall-ssms.ps1 - Silently uninstall SQL Server Management Studio
#
# SSMS 17-20 : WiX installer - reads UninstallString, appends /uninstall /quiet /norestart
# SSMS 21+ : VS Installer - uses vswhere to find productId, runs setup.exe uninstall -q
# winget is tried as a fallback if vswhere fails
#
# Parameters:
# -WhatIf : show what would run, no changes
# -Force : skip confirmation prompts
# -Passive : show VS Installer progress window (default is silent with console timer)
(The full script is in the repo, link below.)
Real Output — WhatIf Against This Lab Machine
No elevation needed to preview:
[11:08:56] SSMS uninstall log - 20260730-110856
[11:08:57] Found : SQL Server Management Studio 22 v22.7.0
[11:08:57] [WhatIf] Would uninstall 'SQL Server Management Studio 22' via VS Installer CLI or winget.
[11:08:57] Done.
Correctly finds the real installed SSMS entry and identifies the right removal path for an SSMS 22+ install (VS Installer CLI, with winget as the documented fallback) without attempting anything. Same as the install script’s post, an actual uninstall wasn’t run against this machine’s working SSMS install for the obvious reason, this -WhatIf preview is the honest extent of live testing here.
How To Run From The Repo
git clone https://github.com/peterwhyte-lgtm/dba-tools
cd dba-tools
.\Initialize-Environment.ps1
.\powershell\patching\ssms\uninstall-ssms.ps1 -WhatIf
.\powershell\patching\ssms\uninstall-ssms.ps1
.\powershell\patching\ssms\uninstall-ssms.ps1 -Force
This script lives in the repo at:
Understanding the Results
- “Uninstall completed via winget” or “via MsiExec” in the log means a fallback layer was needed, worth checking which one when running across several machines, a pattern of the same fallback firing everywhere can point at a broader environment issue.
- A “Still detected” message after an uninstaller reports success usually means a reboot is pending, not a failed removal, the script says so explicitly when this happens.
- MSI sub-component registrations are deliberately skipped during detection (entries whose uninstall string starts with
MsiExec.exe /I{), those are Language Pack and base-MSI sub-registrations the main bootstrapper already handles, treating them as separate top-level SSMS installs would produce false “still installed” results.
Best Practices
- Run with
-WhatIffirst, especially on a machine with an unfamiliar or older SSMS version, confirm which removal path it’ll take before committing. - Close SSMS before running this, or let
-Forcehandle it automatically, an SSMS process left running can block the uninstaller regardless of which method is used. - Check the log for which fallback layer actually succeeded when running across multiple machines, it’s useful signal about install-state drift across a fleet, not just a pass/fail result.
- If every fallback fails, the script tells you to use Settings → Apps manually rather than leaving you guessing, follow that path rather than assuming something is unfixable.
Related Scripts
You may also find these scripts useful:
- SQL Server Installation and Patching (hub)
- Install and Update SSMS via PowerShell
- Install and Update SSMS (manual walkthrough)
Frequently Asked Questions
The uninstaller reports success but SSMS still shows in Settings → Apps, what happened?
Check the log for whether the script flagged a pending reboot. The VS Installer bootstrapper can exit cleanly while the actual removal finishes on the next restart, that’s a reboot needed, not a failed uninstall.
Why does the script try three or four different removal methods instead of just one?
Because SSMS uninstalls genuinely fail in different ways depending on install history: a corrupted Package Cache, a vswhere catalogue mismatch, or a stale registry entry each need a different workaround. One method covers the common case; the fallbacks exist for the real, if less common, failure modes.
Summary
A three-to-four-layer-deep uninstall script for SSMS, covering both the modern VS Installer framework (21+) and the legacy WiX installer (20 and below), with winget and direct MsiExec removal as fallbacks when the primary method fails. Verified with a real -WhatIf preview against this machine’s genuine SSMS 22.7.0 install, correctly identified the removal path without touching anything.
Leave a Reply