Part of the DBA-Tools Project.
Everything You’d Need Before Touching an Unfamiliar Server
Hand a DBA a server they’ve never seen before, and there’s a fixed set of questions that come first, before performance tuning, before security review, before anything: what version and edition is this, what’s the OS and hardware underneath it, is it configured sanely, does licensing allow what’s actually running on it, and what else is this instance connected to.
Those five questions are what “server inventory” means in practice, and each one has its own script in this cluster, because each is a genuinely different kind of check with different permissions and a different shape of answer. This post is the map: what each script answers, how they fit together, and the order to run them in when you’re starting from zero.
Why Server Inventory Matters
- Every other diagnostic, performance tuning, security review, capacity planning, assumes you already know the basics: version, hardware ceiling, configuration baseline. Skipping this step means every later finding is read without context
- Edition and licensing gaps (a feature in use that requires Enterprise, a downgrade that would silently break something) are cheapest to catch before a migration, not during one
- A configuration score or snapshot is only meaningful once you know what “normal” looks like for this specific server’s hardware and edition, inventory comes first
- Linked servers are the most commonly forgotten dependency in a migration plan, they don’t show up in a database backup or a login export, they only show up if you specifically go look
The Scripts, Grouped by Question
What version and edition is this?
- Version and Edition: the fastest single-server snapshot, version, edition, cluster status
- Patch Level: the same version information resolved into a friendly name, CU level, and exact KB reference, built to run across an estate for a patch compliance inventory
What’s the OS and hardware underneath it?
- OS and Hardware Info: Windows release, logical and physical CPU counts, physical memory, and SQL Server uptime in one row, the baseline context every other diagnostic assumes
Is it configured sanely?
- Instance Configuration Snapshot: every
sp_configurevalue and key trace flag in one readable pass - Instance Configuration Score: the same configuration surface scored against known-good defaults, so a drift from best practice is a number, not a hunch
Does licensing allow what’s actually running?
- Edition Feature Usage: audits twelve Enterprise-dependent features (TDE, Resource Governor, readable AG secondaries, and more) and flags exactly what would break on a downgrade
What else is this instance connected to?
- Linked Servers: four scripts covering plain inventory, a migration pre-check (logins + linked servers + jobs), credential risk level, and live connectivity testing
How They Fit Together
Run these roughly in this order when reviewing an unfamiliar server or building a migration plan:
- Version and Edition, then Patch Level if you’re building a compliance inventory across more than one server, establishes what you’re actually working with
- OS and Hardware Info, establishes the physical ceiling everything else gets read against
- Instance Configuration Snapshot, then Instance Configuration Score, establishes whether the current setup makes sense for that hardware and edition
- Edition Feature Usage, establishes what’s actually in use that depends on the current edition, critical before any downgrade
- Linked Servers, establishes what else depends on this instance being here, the most commonly forgotten migration dependency
Each step narrows from “what is this” to “what does this depend on and what depends on it.” Skipping straight to step 4 or 5 without the earlier context usually means re-doing the earlier steps anyway once a finding needs explaining.
Best Practices Across the Series
- Run the full sequence once when inheriting or reviewing any server you don’t already know well, don’t wait for an incident to force the question
- Re-run Edition Feature Usage and Linked Servers specifically before any migration or downgrade, both surface dependencies that are otherwise invisible until something breaks
- Keep Patch Level current across an entire estate on a schedule, a patch compliance inventory that’s months stale is only slightly better than none
- Treat a low Instance Configuration Score or a
blocks_downgrade = YESfinding from Edition Feature Usage as a finding to resolve, not just document
See Also
This pillar is one of ten in DBA Scripts: The Complete Guide, the map across the whole series organized by the question you’re actually asking.
Summary
Server inventory isn’t a single script, it’s five related questions that together tell you what a server is, what it’s running on, whether it’s configured sensibly, what licensing constraints apply, and what else depends on it being there. Answer all five before reasoning about performance, security, or a migration plan, and the findings from every other diagnostic on this server will make a lot more sense.
Start with Version and Edition and OS and Hardware Info on any unfamiliar server, then work down to Configuration, Edition Feature Usage, and Linked Servers as the migration or review actually calls for them.
Leave a Reply