DBA Scripts: SQL Server Installation and Patching

Part of the DBA-Tools Project, in the Server and Configuration area.

Ten scripts covering a SQL Server instance’s whole install-to-patch lifecycle: confirm a machine is ready, install unattended, apply sensible defaults, validate the result, keep it patched, and remove it cleanly when it’s done, for both the SQL Server engine and SSMS. Six posts below, each covering a pair of scripts that belong together.

Testing this pillar surfaced two real, concrete bugs, not hypothetical edge cases: a corrupted double UTF-8 BOM silently broke every single script in powershell/installation/, and patch-summary.ps1‘s build-to-CU lookup table had no entry at all for SQL Server 2025. Both are fixed, both are documented on the page for the script they affected.

The Six Posts

Why This Matters

• Every script in the set is logged, and most preview safely before doing anything. -WhatIf works without elevation on all of them except install-sql.ps1 and uninstall-sql.ps1, a real, documented inconsistency, not an oversight glossed over.
• Checks bookend the risky operations. Pre-install and post-install validation exist specifically so an install or a patch isn’t the first time you learn something was misconfigured.
• Nothing here was tested by actually breaking this site’s own working environment. Install and uninstall of SQL Server or SSMS itself were code-reviewed in full rather than run destructively against the machine every other post on this site depends on, said plainly on the posts where that applies rather than implied by a suspiciously generic “Example Output” section.

The Two Real Bugs Found Testing This Pillar

A corrupted double UTF-8 BOM broke every script in powershell/installation/. All six files, pre-install-check.ps1, install-sql.ps1, configure-sql.ps1, post-install-validation.ps1, uninstall-sql.ps1, and generate-install-report.ps1, had two stacked BOM sequences at the start of the file instead of one, which broke PowerShell’s parser badly enough to misreport the error as a syntax problem in plain English help text. Fixed across all six, confirmed by actually running each one afterward. Full detail on Install and Configure SQL Server.

patch-summary.ps1 had no CU mapping for SQL Server 2025. A fully up-to-date SQL 2025 instance reported as “Unknown build” instead of its real CU level, while the separate config file used by the actual patcher script already had the correct mapping, the two had simply drifted apart. Fixed, confirmed with real before-and-after output on Patch SQL Server and Check Status.

How They Fit Together

A sensible order, whether standing up a new server or maintaining an existing one:

1. Pre-Install Check first, confirm the machine is actually ready
2. Install and Configure next, unattended install, then recommended settings applied
3. Post-Install Validation to confirm, and periodically afterward, not just once
4. Install SSMS alongside it, on any machine that needs the management tooling
5. Patch SQL Server and check status on an ongoing basis, not just at install time
6. Uninstall cleanly when it’s decommissioned, SQL Server and SSMS both, with a history report to confirm what actually happened over the instance’s life

Best Practices Across the Series

• Treat every FAIL from a pre-install check as a blocker, not a note to revisit later.
• Run post-install validation more than once, configuration drift happens quietly over an instance’s working life.
• Know which scripts need elevation before scripting a fully unattended pipeline, install-sql.ps1 and uninstall-sql.ps1 require it even for -WhatIf, the rest of the set doesn’t.
• Never skip the confirmation prompts on uninstall scripts for anything approaching production, -Force-equivalent flags exist for genuinely unattended automation, not as the default habit.
• Keep CU lookup tables and patch configs current manually and in sync with each other, Microsoft doesn’t expose a queryable source for this, and the two files in this set had already drifted apart once.

See Also

This pillar is part of DBA Scripts: The Complete Guide, the map across the whole series organized by the question you’re actually asking.

Summary

Ten scripts, one lifecycle: ready the machine, install, configure, validate, patch, and eventually remove, for both SQL Server and SSMS. Two genuine bugs came out of actually testing this against a real, working instance rather than just reading the code, a repo-wide parser-breaking BOM corruption and a missing SQL 2025 entry in a patch status lookup table, both fixed and confirmed. What wasn’t safe to test live, actually installing or uninstalling SQL Server or SSMS on this site’s own working machine, is said plainly rather than glossed over.