DBA Scripts: Server and Configuration

Part of the DBA-Tools Project.

What This Server Is, and How It Got That Way

Two pillars, one underlying question: before performance, before security, before anything else, what is this SQL Server instance, and how did it come to be configured the way it is. Server Inventory answers the first half, a snapshot of what’s running right now, version, hardware, configuration, licensing, connections. Installation and Patching answers the second half, the lifecycle actions that put a server in that state and keep it there: install, configure, patch, and eventually uninstall.

Fifteen scripts total. This post is the map between the two.

The Two Pillars

Why These Two Belong Together

• Inventory is a snapshot, Installation and Patching is the process that produced it. Run Server Inventory on a server today and it tells you the version, edition, and configuration as they stand. Installation and Patching’s scripts are how that state was reached, and how it changes going forward: an unattended install with validated parameters, sensible sp_configure defaults applied on top, and a repeatable patch path to keep the version current.
• Both are the first thing you touch, not the last. Every other area on this site (performance, security, HA) assumes you already know what server you’re looking at and that it’s configured sanely. These two pillars are what makes that assumption safe to make.
• Both were genuinely bug-affected pillars, not just documentation. Testing Installation and Patching surfaced a corrupted double UTF-8 BOM that silently broke every script in powershell/installation/, and a missing SQL Server 2025 entry in the patch-to-CU lookup table, both fixed and documented on the pages for the scripts they affected.

How They Fit Together

A server’s lifecycle through these two pillars, roughly in order:

1. Before install, Pre-Install Checks confirms the machine is actually ready.
2. Install, Install and Configure SQL Server does the unattended install and applies sensible defaults, then the post-install check validates the result actually matches what was intended.
3. Now it exists, Server Inventory becomes the ongoing reference: what version, what hardware, what’s configured, what’s connected. Run it any time you inherit the server, before a migration, or just to confirm nothing’s drifted.
4. Keep it current, Patch SQL Server and Check Status handles the ongoing CU cadence, and the SSMS install/update scripts do the same for the client tooling DBAs actually use day to day.
5. Eventually, decommission, Uninstall SQL Server removes it cleanly when its life is over.

Best Practices Across This Area

• Run Server Inventory as the very first step on any server you didn’t build yourself, before performance tuning, before security review, before anything.
• Treat a post-install validation failure the same as an install failure, a server that “installed” but isn’t configured as intended is not actually done.
• Re-run Server Inventory after any patch or configuration change, not just at the start, drift is the thing this pillar exists to catch.
• Keep SSMS current on DBA workstations with the same discipline as the engine itself, an outdated client is its own quiet source of confusing bugs.

See Also

• DBA Scripts: The Complete Guide, the full pillar index
• Performance and Troubleshooting
• Maintenance and Automation

Summary

Server Inventory and Installation and Patching are two sides of the same question, what a server is, and how it got that way. Fifteen scripts between them, from pre-install readiness through to clean uninstall, with Server Inventory as the recurring checkpoint in between. Start here on any server you didn’t build yourself.