DBA Scripts: Server Inventory

---

Start Here

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, what else is this instance connected to, and what databases actually live on it.

Those six 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_configure value 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 edition-dependent features (Resource Governor, readable AG secondaries, online index rebuilds, and more) and flags exactly what would break on a downgrade, version by version

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

What databases actually live on this server?

• Database Inventory: every database on the instance, compatibility level, recovery model, and state, in one plain list
• Database Summary: the same inventory carried one step further, backup recency and health flagged per database

For free-space and growth detail once you know what’s here, that’s a different question with its own cluster: see the Storage and Capacity pillar.

---

How They Fit Together

Run these roughly in this order when reviewing an unfamiliar server or building a migration plan:

1. 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
2. OS and Hardware Info, establishes the physical ceiling everything else gets read against
3. Instance Configuration Snapshot, then Instance Configuration Score, establishes whether the current setup makes sense for that hardware and edition
4. Edition Feature Usage, establishes what’s actually in use that depends on the current edition, critical before any downgrade
5. Linked Servers, establishes what else depends on this instance being here, the most commonly forgotten migration dependency
6. Database Inventory, then Database Summary, establishes what’s actually hosted here, before capacity or backup review goes any deeper

Each step narrows from “what is this” to “what does this depend on, and what does it hold.” Skipping straight to step 4, 5, or 6 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 = YES finding from Edition Feature Usage as a finding to resolve, not just document
• Run Database Inventory early, not as an afterthought, knowing what’s actually hosted on a server changes how every other finding on it should be read

---

Frequently Asked Questions

---

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

Server inventory isn’t a single script, it’s six related questions that together tell you what a server is, what it’s running on, whether it’s configured sensibly, what licensing constraints apply, what else depends on it being there, and what it actually holds. Answer all six 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, Linked Servers, and Database Inventory as the migration or review actually calls for them.