This is the step everything else is read against. A wait, a permission, a migration plan: none of them mean what they appear to mean until you know what the server actually is.
If you only run one thing: start with Version and Edition. It is the answer the other five questions get read against, so running it first stops them being asked about a server you have mis-identified.
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.
Start Here
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?
The answer everything else gets read against.
- Version and Edition, the fastest single-server snapshot: version, edition, cluster status
- Patch Level, the same version resolved into a friendly name, CU level and exact KB, built to run across an estate for patch compliance
What’s the OS and hardware underneath it?
The ceiling every performance finding is measured against.
- OS and Hardware Info, Windows release, logical and physical CPU counts, memory and uptime in one row
- Services Information, every SQL Server service, its state, start mode and the account it runs as
- CPU Topology and OS Config, sockets, cores and NUMA nodes with the OS settings that shape them, which is what MAXDOP decisions actually rest on
Is it configured sanely?
What someone changed, and whether it still makes sense.
- Instance Configuration Snapshot, every
sp_configurevalue and key trace flag in one readable pass - Instance Configuration Score, the same surface scored against known-good defaults, so drift is a number rather than a hunch
- Trace Flags and Resource Governor, the settings that change behaviour without changing any
sp_configurevalue, so they are easy to inherit and never notice
Does licensing allow what’s actually running?
The question that gets expensive if it is asked during a migration rather than before.
- Edition Feature Usage, audits twelve edition-dependent features, from Resource Governor to readable AG secondaries, and flags exactly what a downgrade would break
What else is this instance connected to?
The dependency no backup or login export will show you.
- Linked Servers, four scripts: plain inventory, a migration pre-check covering logins and jobs, credential risk level, and live connectivity testing
What databases actually live on this server?
What it holds, before anyone plans capacity or backups around it.
- Database Inventory, every database with compatibility level, recovery model and state, in one plain list
- Database Summary, the same inventory a step further, with backup recency and health flagged per database
- Database Snapshot Inventory, the snapshots sitting alongside them, which hold files and space of their own and are routinely forgotten
For free space and growth detail once you know what is here, that is 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:
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 = YESfinding 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
What is the fastest way to document a server I have just inherited?
Run the version, hardware and configuration snapshot scripts together and keep the output. That gives you a dated baseline, which is worth more than any single number: six months later it is the only way to answer what changed.
Why does edition matter more than version?
Version tells you what syntax works; edition tells you what you are licensed to run. Online index rebuilds, Resource Governor and readable secondaries are Enterprise-only on every version, so an identical script can be valid on one instance and a licensing problem on another. Edition alone is not the whole answer either, because several features moved: compression, partitioning, CDC and database snapshots came to Standard in SQL Server 2016 SP1, and TDE followed in 2019.
Is a linked server inventory really part of an inventory?
Yes, and it is the part people forget. Linked servers are how a problem on one instance becomes a problem on another, and they carry credentials, so they are a security question as much as an inventory one.
Do I need sysadmin to run these?
Mostly no. Version, edition, hardware and configuration reads need VIEW SERVER STATE, and the database inventory needs VIEW ANY DATABASE or you will silently get a short list. The linked server credential check is the one that genuinely needs more, because the permissions it reports are the ones it has to read.
How often is this worth re-running?
Version, edition and patch level on whatever schedule your patching runs, because that is the one that changes underneath you. Configuration and linked servers when something changes or before a migration. The hardware read only when the box does.
What does this pillar deliberately not cover?
Space and growth, which is the Storage and Capacity pillar, and anything about workload: waits, blocking and query performance all assume you have already been through this. Inventory tells you what a server is, not how well it is running.
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.
Leave a Reply