Part of the DBA-Tools Project.
Bookend Checks for an Installation You Can Trust
Two scripts, same shape (PASS / WARN / FAIL, a summary verdict), sitting on either side of an install: pre-install-check.ps1 confirms the machine is actually ready before you run setup, post-install-validation.ps1 confirms the instance is actually configured sensibly after you’re done. Neither installs or changes anything, both are safe to run any time.
Why Checking Both Ends Matters
- A failed prerequisite caught before install is a two-minute fix. The same problem caught after install is a support call. Low disk space, a pending reboot, or an existing instance name collision are all things
setup.exewill either fail on or silently work around in a way you don’t want. - “The installer finished successfully” and “this instance is configured correctly” are different claims. Setup completing without an error says nothing about whether SA is disabled, whether TempDB has the right file count, or whether max server memory got left at its unbounded default.
- Both scripts are read-only. Run them as often as you like, on any machine, without needing to justify a change window first.
When to Run These Scripts
pre-install-check.ps1, before running SQL Server setup on any new machinepost-install-validation.ps1, immediately after any install, and again periodically on servers you’ve inherited- Either one when auditing a machine you didn’t build yourself, to see what state it’s actually in
pre-install-check.ps1
Checks admin elevation, OS version against the minimum build for the target SQL Server version, pending reboot state, RAM, CPU count, .NET Framework version, PowerShell version, free disk space on the planned install/data/log drives, TCP port 1433 availability, existing SQL Server instances, and the active Windows Firewall profile.
<#
.SYNOPSIS
Run pre-installation checks before deploying SQL Server.
.DESCRIPTION
Validates the machine is ready for SQL Server installation. Reports PASS / WARN / FAIL
for each check. Does not make any changes to the system.
.PARAMETER SqlVersion
SQL Server version being installed (2016|2017|2019|2022). Default: 2022.
.EXAMPLE
.\powershell\installation\pre-install-check.ps1
.\powershell\installation\pre-install-check.ps1 -SqlVersion 2019 -DataDir D:\SQLData
#>
(The full script is in the repo, link below.)
Real Output — Run Against This Lab Machine
This machine already has SQL Server installed, which is exactly the kind of situation this script is meant to catch:
SQL Server 2022 Pre-Install Checks
------------------------------------------------------------
[FAIL] Running as Administrator Re-run as Administrator
[PASS] OS version Microsoft Windows 11 Home (Build 26200)
[PASS] No pending reboot Clean
[WARN] RAM 7.8 GB (8 GB recommended)
[PASS] Logical CPUs 8 processors
[PASS] .NET Framework 4.8+
[PASS] PowerShell version 7.6
[FAIL] Install dir 8.6 GB free on C: (need 20 GB)
[FAIL] Data dir 8.6 GB free on C: (need 50 GB)
[FAIL] Log dir 8.6 GB free on C: (need 20 GB)
[WARN] TCP port 1433 Already in use — check existing SQL instance
[FAIL] Existing instances Instance 'MSSQLSERVER' already exists: MSSQLSERVER
[WARN] Windows Firewall Active profile: Domain — ensure port 1433 rule is added post-install
============================================================
NOT READY — fix FAIL items before proceeding
PASS: 5 WARN: 3 FAIL: 5
Every FAIL here is genuine and correctly identified: this machine already runs a default instance, has well under the recommended free disk space, and the shell wasn’t elevated for this run. That’s exactly the signal a pre-install check should give.
post-install-validation.ps1
Connects to a SQL Server instance and checks service status, connectivity, version, key sp_configure settings, TempDB file count, TCP/IP connectivity, SA account status, and authentication mode.
<#
.SYNOPSIS
Validate a SQL Server installation is configured correctly.
.DESCRIPTION
Connects to a SQL Server instance and checks services, connectivity, version,
configuration settings, TempDB layout, and security posture.
Outputs PASS / WARN / FAIL per check with a summary.
#>
(The full script is in the repo, link below.)
Real Output — Run Against This Lab Machine
Post-Install Validation — .
--------------------------------------------------------------
[PASS] SQL Server service running Running
[WARN] SQL Agent service running Stopped
[WARN] SQL Agent startup type Manual
[PASS] SQL Server connection v17.0.4045.5 RTM
[PASS] Max server memory 1600MB
[PASS] MaxDOP 8
[WARN] Cost threshold for parallelism 5 — SQL default; 25-50 recommended
[WARN] Backup compression Disabled — enable for smaller backups
[WARN] Optimize for ad hoc workloads Disabled — enable to reduce plan cache bloat
[PASS] TempDB data file count 8 files (recommended: 8 for this CPU count)
[PASS] TCP/IP connection Port 1433
[WARN] SA account disabled SA is ENABLED — disable if not needed
[PASS] Authentication mode Mixed mode (Windows + SQL)
==============================================================
PASSED WITH WARNINGS — review WARN items
PASS: 7 WARN: 6 FAIL: 0
Six genuine WARN findings on a real, working instance, not a manufactured example. Every one of these is fixable with Configure SQL Server, which applies exactly this class of setting.
How To Run From The Repo
git clone https://github.com/peterwhyte-lgtm/dba-tools
cd dba-tools
.\Initialize-Environment.ps1
.\powershell\installation\pre-install-check.ps1
.\powershell\installation\post-install-validation.ps1
These scripts live in the repo at:
Understanding the Results
- A FAIL on
pre-install-check.ps1means don’t proceed yet, not “proceed carefully.” Disk space and existing-instance collisions are the two most likely to actually break a setup run partway through. - A WARN on
post-install-validation.ps1is a configuration choice, not a failure. SA enabled, for example, is fine on a locked-down lab box and a real problem on anything internet-facing, judge each WARN in context. - Re-run
post-install-validation.ps1periodically, not just once. Settings drift, someone re-enables SA for a one-off task and forgets to turn it back off, Agent gets stopped during troubleshooting and never restarted.
Best Practices
- Run
pre-install-check.ps1before every new install, even on a machine you think you know, disk space and pending reboots change silently. - Treat every FAIL from
pre-install-check.ps1as a blocker; treat WARNs as judgment calls to make deliberately, not skip past. - Run
post-install-validation.ps1right after setup finishes, then again a few weeks later once real workload has run against the instance. - Feed WARN findings from
post-install-validation.ps1straight into Configure SQL Server rather than fixing them by hand onesp_configureat a time.
Related Scripts
You may also find these scripts useful:
- SQL Server Installation and Patching (hub)
- Install and Configure SQL Server
- Uninstall SQL Server
- Get Instance Configuration Snapshot
Frequently Asked Questions
Does pre-install-check.ps1 need to run on the target machine, or can it check remotely?
It reads local registry keys, drive free space, and OS info directly, so it needs to run on the machine that will host the new instance, not from a remote workstation.
Why does post-install-validation.ps1 flag SA being enabled as a WARN instead of a FAIL?
Because it’s a legitimate configuration in some environments (isolated lab boxes, certain legacy application requirements) and a real risk in others. The script surfaces it for a judgment call rather than assuming it’s always wrong.
Summary
Two read-only bookend checks, one before an install, one after. Run against a real, already-installed lab machine, pre-install-check.ps1 correctly flagged five genuine blockers (disk space, an existing instance, non-elevated shell) and post-install-validation.ps1 found six genuine configuration gaps on the working instance, every one of them fixable with the companion Configure SQL Server script.
Leave a Reply