DBA Scripts: Uninstall SQL Server

Part of the DBA-Tools Project.


Removing an Instance Cleanly, and Knowing What Happened Afterward

uninstall-sql.ps1 detects installed instances, confirms the target explicitly, and runs setup.exe /ACTION=Uninstall, with an option to remove data directories afterward. generate-install-report.ps1 reads back through every install, configure, and patch log this toolkit has ever written for an instance and produces a readable timeline, useful both before an uninstall (what actually happened to this instance over its life) and after (confirming the removal itself is in the record).

Both scripts are part of the same powershell/installation/ folder that had a corrupted double UTF-8 BOM breaking every script in it, the same fix covered on Install and Configure SQL Server. Both now parse and run correctly.


Why Confirming Before You Uninstall Matters

  • Every step requires explicit confirmation. This script doesn’t quietly remove an instance because a variable happened to match, you confirm the exact instance name before anything runs.
  • Data directory cleanup is optional and separate from the uninstall itself. Removing the SQL Server program files doesn’t have to mean losing the data files in the same step, in case anything still needs recovering from them.
  • A readable history of what happened to an instance is worth having before you remove it, not reconstructed afterward from memory.

uninstall-sql.ps1

Detects installed SQL Server instances, confirms the target, and runs setup.exe /ACTION=Uninstall. Optionally removes data directories after uninstall. All steps require explicit confirmation.

<#
.SYNOPSIS
Uninstall a SQL Server instance with optional data directory cleanup.

.DESCRIPTION
Detects installed SQL Server instances, confirms the target, and runs setup.exe
/ACTION=Uninstall. Optionally removes data directories after uninstall.
All steps require explicit confirmation.
#>

(The full script is in the repo, link below.)

Not run live on this machine, deliberately. This lab box is the working environment behind every other post on this site, actually uninstalling its only SQL Server instance to test this script would have taken the whole operation down. Like install-sql.ps1, -WhatIf on this one also requires an elevated shell (confirmed: same “must be run as Administrator” error even in preview mode), so even a safe dry-run preview wasn’t available without stepping outside this lab’s normal working setup. Covered from a full code read, said plainly rather than glossed over.


generate-install-report.ps1

Reads install, configure, and patch logs from output-files\ and produces a readable summary: what was installed, when, against which instance, and the outcome.

<#
.SYNOPSIS
Generate a summary report from SQL Server installation and configuration logs.

.DESCRIPTION
Reads install/configure/patch logs from output-files\ and produces a readable
summary showing what was installed, when, against which instances, and the outcome.
#>

(The full script is in the repo, link below.)

Real Output — Run Against This Lab Machine

No elevation needed, this one is read-only against the log folder:

  SQL Server Installation & Patch Report
  ----------------------------------------------------------------------

  2026-07-30 11:08  Patch      MSSQLSERVER  (MSSQL17.MSSQLSERVER) Unknown
  2026-06-14 23:58  Patch      MSSQLSERVER  (MSSQL17.MSSQLSERVER) Unknown
  2026-06-14 23:46  Patch      MSSQLSERVER  (MSSQL17.MSSQLSERVER) Unknown
  2026-06-14 23:42  Patch      MSSQLSERVER  (MSSQL17.MSSQLSERVER) Unknown
  2026-06-14 23:36  Patch      MSSQLSERVER  (MSSQL17.MSSQLSERVER) Unknown

  Total events: 8

Every event here shows Unknown rather than Success, and that’s the correct, honest read rather than a bug: this instance has only ever had patch status checks run against it (-WhatIf and up-to-date confirmations via Invoke-SqlPatch.ps1), never an actual patch application. The script’s outcome-parser looks for text like “succeeded” or “Done” in the log, an up-to-date check or a WhatIf preview genuinely doesn’t contain either, so Unknown is the accurate classification, not a gap in the parsing logic.


How To Run From The Repo

git clone https://github.com/peterwhyte-lgtm/dba-tools
cd dba-tools
.\Initialize-Environment.ps1

.\powershell\installation\uninstall-sql.ps1 -WhatIf
.\powershell\installation\generate-install-report.ps1

These scripts live in the repo at:


Understanding the Results

  • Unknown in the report means “no completed install or patch event found,” not “something went wrong.” Status-only checks and WhatIf previews correctly show as Unknown, they never claimed to change anything.
  • Explicit confirmation prompts in uninstall-sql.ps1 are the safety net, not a formality. Don’t script around them with -Force-style automation unless the removal is genuinely meant to run unattended.
  • Data directory removal is a separate decision from the uninstall itself. Removing the program files first, then deciding on the data directories afterward, is the safer default order if there’s any doubt.

Best Practices

  • Run generate-install-report.ps1 before uninstalling anything, know the instance’s full history before you remove it.
  • Never skip the confirmation prompts on uninstall-sql.ps1 for a production instance, even when scripting the removal, -Force-equivalent flags exist for automation but should be a deliberate choice, not the default.
  • Keep data directories in place initially after an uninstall if there’s any chance something still needs recovering, delete them as a separate, later step once you’re certain.
  • Run generate-install-report.ps1 again after the uninstall to confirm the removal is reflected in the log history.

Related Scripts

You may also find these scripts useful:


Frequently Asked Questions

Does uninstall-sql.ps1 remove the data files by default?

No. Data directory cleanup is a separate, optional step after the uninstall itself, so removing the program files doesn’t automatically mean the data is gone too.

Why do all my patch events show as “Unknown” in the report?

The report only marks an event Success when the underlying log actually contains success language. A -WhatIf preview or an up-to-date status check never writes that language, because nothing was actually installed, Unknown is the accurate result, not a bug.


Summary

uninstall-sql.ps1 removes an instance with explicit confirmation at every step and optional, separate data directory cleanup; generate-install-report.ps1 gives you the full install/configure/patch history for an instance in one readable pass, useful before a removal and to confirm after it. Neither script was run destructively against this site’s own working SQL Server instance, for the obvious reason, but both were code-reviewed in full and the reporting script’s real output against this machine’s genuine (if patch-light) history is shown above.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *