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.
Start Here
The Two Pillars
📁 Server Inventory
The five questions to answer before touching an unfamiliar server: version, hardware, configuration, licensing, connections.
💻 Installation and Patching
Install, configure, patch, and uninstall SQL Server and SSMS, ten scripts across the whole lifecycle.
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_configuredefaults 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:
- Before install, Pre-Install Checks confirms the machine is actually ready.
- 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.
- 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.
- 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.
- 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.
Common Questions
What should I check first on a server I have never seen?
Version and edition, then whatever has been changed from the defaults. Edition determines which features are even legal to use, and non-default configuration is where the surprises live: MAXDOP, max memory, and trace flags someone set years ago for a reason nobody recorded. Get MAXDOP Configuration, in Related Scripts below, covers that in full.
Why does edition matter so much?
Because it silently governs capability. Compression, online index rebuilds, and several availability features are Enterprise-only, so a script that works on one instance can fail on another for licensing reasons rather than technical ones.
Is a default MAXDOP of 0 a problem?
Usually yes on a modern multi-core server. It lets a single query use every scheduler, which turns one heavy query into a server-wide event. The right value depends on core count and NUMA layout, which is exactly what the CPU topology script reports.
Should I care about trace flags I did not set?
Yes, and especially the ones nobody can explain. Trace flags change engine behaviour globally and often outlive the problem they were added for, so an unexplained flag is worth researching before it becomes load-bearing by accident.
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.
Leave a Reply