Introduction

Rolling back a SQL Server cumulative update (CU) or security update can be confusing when a Windows Server hosts multiple SQL Server versions. Windows Update may show updates for components such as SQL Server Browser and VSS Writer while the Database Engine patch is not obvious. The reliable approach is to identify each instance’s engine build, locate the uninstall command for the exact Knowledge Base (KB) update, and review its scope before running SQL Server Setup’s RemovePatch action.

This guide walks through a real side-by-side example with SQL Server 2019 and SQL Server 2025. The commands show how the KB-specific Setup cache paths differ, and why the /AllInstances switch deserves careful attention.

Why rollback becomes confusing

SQL Server Setup maintains separate servicing information for each major version. On one Windows Server, the SQL Server 2019 setup cache is under the 150 directory, while SQL Server 2025 uses the 170 directory. Updates can also apply to shared features, so Windows’ Uninstall updates page may display Browser or VSS Writer entries without clearly showing the Database Engine update you intend to remove.

In the example, the server had two named instances: SQL Server 2019 instance TEST and SQL Server 2025 instance AZTEST. The Windows update screen showed SQL Server 2025 Browser and VSS Writer entries for KB5128492, but not an obvious Database Engine rollback entry. Removing one of those entries from Settings would not be a clear, verified way to roll back the engine patch.

The instance names and host details below are anonymised. The KBs and build numbers correspond to the observed update versions.

1. Confirm the build on each instance

Connect to each instance separately in SQL Server Management Studio and run:

SELECT
@@SERVERNAME AS ServerName,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel;

The example returned these results:

SQL Server 2019 TEST: 15.0.4500.2 | RTM | CU32
SQL Server 2025 AZTEST: 17.0.1145.4 | RTM | NULL

The SQL Server 2019 build 15.0.4500.2 maps to CU32 + GDR KB5128494. SQL Server 2025 build 17.0.1145.4 maps to GDR KB5128492. ProductUpdateLevel being NULL on the SQL Server 2025 result does not, by itself, mean that the security update failed; check the full ProductVersion against Microsoft’s build list.

2. Read the uninstall command for each KB

Run the following read-only PowerShell check in an elevated session. It reads the uninstall information for the identified SQL Server KB; it does not start the removal.

$kb = 'KB5128494'
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$kb" -ErrorAction SilentlyContinue |
Select-Object DisplayName, UninstallString

$kb = 'KB5128492'
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$kb" -ErrorAction SilentlyContinue |
Select-Object DisplayName, UninstallString

For this server, the returned entries identified Hotfix 4500 for SQL Server 2019 (KB5128494) and GDR 1145 for SQL Server 2025 (KB5128492). The commands pointed to separate Setup cache branches: 150\...\KB5128494\QFE for SQL Server 2019, and 170\...\KB5128492\GDR for SQL Server 2025.

Treat the registry value as the source for the uninstall command. Do not guess a path from the version number, copy an uninstall command for a different KB, or use the general Remove/Uninstall instance workflow. Microsoft documents reading the update’s UninstallString and invoking SQL Server Setup with Action=RemovePatch.

3. Review the command scope

The exact UninstallString returned /Action=RemovePatch /AllInstances for both KBs. Microsoft defines /AllInstances as applying the update action to all applicable SQL Server instances and shared, instance-unaware components. Therefore, check the server inventory before running it. If the server has additional instances eligible for that same update, they may be affected too. Do not assume that /AllInstances means “only the instance I connected to in SSMS.”

Where only one instance should be targeted, use a documented instance-specific RemovePatch command and verify the target with SQL Server Setup documentation for the installed version. Do not silently replace flags in a registry command without validating the package and target scope.

4. Back up, schedule downtime, and remove the patches

Patch removal interrupts SQL Server services. Plan a maintenance window, notify application owners, take and verify full backups of all user databases, and back up master and msdb for each instance. Microsoft recommends backing up databases and stopping SQL Server services before CU removal. Stop the relevant SQL Server Agent and Database Engine services, along with other SQL Server services required by the installed features.

From an elevated PowerShell window, the commands returned for this example were:

& "C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\Update Cache\KB5128494\QFE\setup.exe" /Action=RemovePatch /AllInstances

& "C:\Program Files\Microsoft SQL Server\170\Setup Bootstrap\Update Cache\KB5128492\GDR\setup.exe" /Action=RemovePatch /AllInstances

Run each command separately and follow the SQL Server Setup prompts. The first command targets the SQL Server 2019 KB5128494 patch; the second targets the SQL Server 2025 KB5128492 patch. The paths are examples from this server: use the exact UninstallString returned by your own machine.

If both a CU and a later security update were installed as separate packages, rollback is a layered operation. Remove the latest update first, then inspect the resulting build and the remaining installed patch entries. Remove an earlier CU only if you intend to undo it as well and have its own verified uninstall entry. Do not assume removing a security update also removes the CU underneath it.

5. Restart and verify both instances

Restart Windows if Setup requests it. Start the SQL Server services and reconnect to both instances. Re-run the build query and verify the resulting versions against the state you intended to restore. Then confirm that all expected databases are online and review SQL Server error logs, SQL Agent jobs, application connectivity, and backup jobs.

Keep the backups until the applications and both instances have passed operational checks. A supported patch rollback is intended to revert SQL Server program files; it should not delete user database files. It still causes downtime, and backups remain important for recovery if an unexpected problem occurs.

Practical lessons

  • Use the Database Engine build and KB number to identify the update; the Installed apps list alone may show only shared feature updates.
  • Read the KB-specific UninstallString rather than guessing a setup path.
  • The 150 and 170 setup cache directories in this example are version-specific locations; always confirm the KB and product before running a command.
  • Review /AllInstances carefully because it can affect multiple applicable instances and shared components.
  • Remove patches in reverse installation order, with backups and a planned outage.

If you need help reviewing SQL Server patching or planning a rollback across production instances, contact Onsys for database administration support.

Microsoft references