DBA Scripts: Get Version and Edition

🔧Part of the DBA-Tools Project, copy/paste SQL Server scripts and health checks.In: Server & Configuration › Server Inventory

Version and edition are two of the most basic facts about a SQL Server instance, and two of the easiest to get wrong when you’re relying on memory or an out-of-date wiki page. Whether a feature is available, whether a security patch has actually landed, and how many cores or how much memory the edition will actually use, all depend on getting this right.

This script returns the instance’s version, edition, patch level, and clustering status in a single query, no digging through SSMS dialogs required.


Why Version and Edition Matters

Edition determines hard limits: Standard Edition caps usable memory and core count well below what Enterprise allows, and features like Always On Availability Groups (beyond basic 2-node), online index rebuilds, and Query Store hints differ by edition. Version and patch level determine which security fixes and bug fixes are actually applied, not just which ones should be. Check the result against the SQL Server builds reference to see how far behind an instance actually is.

  • Confirms the edition matches what was licensed and what the workload actually needs
  • Confirms the instance is patched to a supported, secure build
  • Surfaces whether the instance is clustered, relevant for any failover or maintenance planning
  • The starting point for any inventory, audit, or migration assessment

When to Run This Script

  • Routine SQL Server health checks
  • Building or refreshing a server inventory
  • Before planning a migration or upgrade
  • Auditing a server or estate you’ve just inherited

The Script

Run the following script against your SQL Server instance.

/*
Script Name : Get-VersionAndEdition
Category    : configuration-and-environment
Purpose     : Display core instance version, edition, cluster status, and patch level.
Author      : Peter Whyte (https://sqldba.blog/dba-scripts-get-version-and-edition/)
Requires    : Public (no special permissions required)
HealthCheck : Yes
*/
-- SAFE:ReadOnly
-- IMPACT:Low
SET NOCOUNT ON;

SELECT
    SERVERPROPERTY('MachineName') AS machine_name,
    SERVERPROPERTY('ServerName') AS server_name,
    SERVERPROPERTY('InstanceName') AS instance_name,
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('BuildClrVersion') AS clr_version,
    SERVERPROPERTY('IsClustered') AS is_clustered,
    SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS physical_hostname;

The script reads a handful of SERVERPROPERTY values and returns them as a single row: machine name, server name, instance name, product version, patch level, edition, CLR version, cluster status, and physical hostname.


How To Run From The Repo

Clone DBA Tools, initialize and run the script:

# Clone dba-tools repo:
git clone https://github.com/peterwhyte-lgtm/dba-tools

# Initialize environment:
cd dba-tools
.\Initialize-Environment.ps1

# Check version, edition, and patch level:
.\run.ps1 Get-VersionAndEdition

# To run against a remote sql server:
.\run.ps1 Get-VersionAndEdition -ServerInstance SQLSERVER01

This script lives in the repo at:


Example Output

Get-VersionAndEdition script output showing version, edition, patch level, and cluster status

This instance is running build 17.0.4045.5, RTM, Enterprise Developer Edition, standalone (not clustered).


Understanding the Results

The script returns a single row. Every column it returns, and what it is actually telling you:

machine_name
server_name
The Windows computer name and the name SQL Server itself reports. On a standalone default instance they read the same; a named instance carries the instance suffix on server_name.
instance_name
NULL means this is the default instance; anything else is a named instance sharing the machine with others.
product_version
product_level
The build number and patch level (RTM, SP, or CU). Cross-check the build number against Microsoft’s official build reference to confirm exactly which cumulative update is applied.
edition
Determines hard limits on memory, cores, and feature availability. Standard Edition caps usable memory well below Enterprise, and several HA/DR and performance features are Enterprise-only.
clr_version
The .NET CLR build the instance was compiled against. It follows the SQL Server version and is not something you configure, so read it as a version fact rather than a setting.
is_clustered
1 means the instance is a Failover Cluster Instance and 0 means it is standalone. Relevant for planning maintenance windows and understanding failover behaviour.
physical_hostname
The NetBIOS name of the machine the instance is running on right now. On a Failover Cluster Instance that is the owning node rather than the virtual network name clients connect to, and it changes as the instance fails over, so it answers “which node am I actually on” in one query.

Best Practices

  • Keep an inventory of version and edition across every instance in your estate; don’t rely on memory or an out-of-date spreadsheet.
  • Re-run this after every patch cycle to confirm the update actually applied, rather than trusting the installer’s success message alone.
  • Cross-check product_version against Microsoft’s build reference when investigating whether a specific CVE or bug fix is present.

Related Scripts

You may also find these scripts useful:


Frequently Asked Questions

How do I know which cumulative update is actually installed?

product_version gives the exact build number. Cross-reference it against Microsoft’s SQL Server build version reference page to identify the specific CU or security update.

Does edition affect performance, not just features?

Yes, indirectly. Standard Edition’s memory and core caps mean a workload that would perform well on Enterprise hardware can be memory- or CPU-constrained on the same hardware under Standard Edition’s limits.


Summary

Version and edition sound like trivia, but they’re the foundation every other check builds on: what features are available, what’s patched, what the licensing actually allows. Getting this wrong, or not knowing it at all, undermines confidence in everything else you find during a health check.

Run this script as the starting point for any inventory, audit, or migration assessment, and re-run it after every patch cycle to confirm the update actually took.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *