Why Finding Your SQL Server Product Key Matters

You can find the SQL Server product key by querying the Windows registry directly from within SQL Server using the xp_regread extended stored procedure. This is the fastest and most reliable method, and it works without needing physical access to the original installation media or licence documentation.

Licence audits, server migrations, and disaster recovery scenarios all have one thing in common: someone needs to produce a valid product key, usually under time pressure. If your organisation has grown through acquisitions, hardware refreshes, or ad-hoc SQL Server deployments over the years, tracking down licence keys for every instance can be genuinely difficult. Installation media gets lost. Licence emails get deleted. The person who set up the server left three years ago.

This is a common situation. Having a reliable script to extract the SQL Server product key directly from the registry saves time and prevents compliance headaches.

What Is xp_regread and Is It Safe to Use?

xp_regread is an undocumented extended stored procedure that reads values from the Windows registry. Microsoft hasn't officially documented it, but it has been available since SQL Server 2000 and remains functional through to SQL Server 2019 and 2022.

A few practical points worth knowing:

  • It requires membership in the sysadmin fixed server role, or explicit EXECUTE permission on the procedure.
  • It reads from the registry in read-only mode. It won't modify anything.
  • It works on both 32-bit and 64-bit installations, provided you reference the correct registry path.
  • It is not a substitute for proper licence management, but it's an excellent diagnostic and recovery tool.

Use it when you need to retrieve a product key quickly and don't have access to the original licence documentation.

How to Find the SQL Server Product Key by Version

The registry path for the product key changes between SQL Server versions. Use the script that matches the version you're running. If you're not sure which version is installed, run SELECT @@VERSION first.

SQL Server 2005

USE master
GO
EXEC xp_regread
    'HKEY_LOCAL_MACHINE',
    'SOFTWARE\Microsoft\Microsoft SQL Server\80\Registration',
    'CD_KEY'
GO

SQL Server 2008 and 2008 R2

USE master
GO
EXEC xp_regread
    'HKEY_LOCAL_MACHINE',
    'SOFTWARE\Microsoft\Microsoft SQL Server\100\BIDSSetup',
    'ProductCode'
GO

SQL Server 2012

USE master
GO
EXEC xp_regread
    'HKEY_LOCAL_MACHINE',
    'SOFTWARE\Microsoft\Microsoft SQL Server\110\Registration',
    'DigitalProductId'
GO

SQL Server 2014

USE master
GO
EXEC xp_regread
    'HKEY_LOCAL_MACHINE',
    'SOFTWARE\Microsoft\Microsoft SQL Server\120\Registration',
    'DigitalProductId'
GO

SQL Server 2016, 2017, 2019, and 2022

From SQL Server 2016 onwards, the registry path follows a consistent pattern using the major version number. The internal version numbers map as follows:

  • SQL Server 2016 = 130
  • SQL Server 2017 = 140
  • SQL Server 2019 = 150
  • SQL Server 2022 = 160
USE master
GO

-- Replace 150 with the appropriate version number for your instance
EXEC xp_regread
    'HKEY_LOCAL_MACHINE',
    'SOFTWARE\Microsoft\Microsoft SQL Server\150\Registration',
    'DigitalProductId'
GO

What If the Registry Query Returns NULL or No Results?

This happens more often than you'd expect, particularly on newer installations or volume-licensed environments. There are a few reasons why the query might return nothing useful:

Volume Licence (VL) installations - In many enterprise environments, SQL Server is deployed using volume licensing through a KMS or MAK activation model. The product key may not be stored in the registry in the same location, or it may be managed centrally through a Volume Activation Management Tool (VAMT).

Evaluation or Developer editions - These don't require a traditional product key. If you installed SQL Server as an Evaluation or Developer edition, there's no retail key to retrieve.

Upgraded instances - If the instance was upgraded in place from an older version, the registry path may reflect the original installation rather than the current version.

Permissions - If you're not running the query as a sysadmin, xp_regread will return no results without throwing an obvious error. Always verify your permissions first.

In cases where the registry method doesn't return a usable key, check with your software asset management team or Microsoft Volume Licensing Service Centre (VLSC) at https://www.microsoft.com/licensing/servicecenter. If your organisation uses Microsoft 365 or has an Enterprise Agreement, licence keys are managed through that portal.

A Note on SQL Server Express

SQL Server Express is a free edition and does not have a product key. If you're running Express and the query returns nothing, that's expected behaviour. Express editions are identified by the edition string in @@VERSION, not by a licence key.

Should You Store Product Keys Somewhere Safe?

Yes. Absolutely. Retrieving a product key from a running instance is useful in a pinch, but it's not a licence management strategy. At minimum, your organisation should maintain a software asset register that includes:

  1. The SQL Server edition and version for each instance
  2. The licence type (retail, OEM, volume, subscription)
  3. The product key or licence reference number
  4. The date of purchase or licence renewal
  5. The name of the licence holder or purchasing entity

SQL Server licences are tied to the physical or virtual cores on which SQL Server runs, not just to a product key. If you're migrating to new hardware or a new VM, understanding your licence type matters as much as having the key itself.

Key Takeaways

  • The SQL Server product key can be retrieved using xp_regread against the Windows registry, with the specific path varying by SQL Server version.
  • You must be a member of the sysadmin role to execute xp_regread successfully.
  • Volume licence and Evaluation edition installations may not store a retrievable product key in the standard registry location.
  • From SQL Server 2016 onwards, the registry path uses a version number (130, 140, 150, 160) that corresponds to the major release.
  • Registry retrieval is a useful recovery tool, but it's not a substitute for maintaining a proper software asset register.

Need Help Auditing Your SQL Server Environment?

Licence compliance is just one part of keeping a SQL Server environment in good shape. If your organisation is preparing for a migration, a hardware refresh, or an audit, a structured SQL Server health check can surface licence gaps, unsupported versions, and configuration issues before they become problems.

DBA Services provides SQL Server health checks and managed support for organisations across Australia. If you need a clear picture of what's running in your environment and whether it's properly licensed and configured, get in touch with our team.