Per-core counting is the foundation of all SQL Server licensing. Get this wrong and you create invisible audit exposure. Get it right and you have a clean defence against Microsoft auditors. The core rules are simple in principle but complex in application. The most common error — counting logical CPUs instead of physical cores — alone causes £180K–£520K in overpayment across a typical 500-user enterprise.
Physical Cores vs Logical CPUs: The Fundamental Distinction
This is where most organisations fail. Microsoft licenses SQL Server based on physical CPU cores, not logical processors (which include hyperthreading).
The Counting Rule
A modern Intel or AMD processor has multiple cores. Hyperthreading (Intel) or SMT (AMD) allows each core to run two execution threads simultaneously, doubling the logical processor count.
Example: A 2-socket Intel Xeon server with 24-core processors per socket:
- Physical cores: 2 sockets × 24 cores = 48 cores
- Logical CPUs (with hyperthreading): 48 cores × 2 threads = 96 logical CPUs
You must licence 48 cores, not 96. When you look at Windows Task Manager or CPU-Z, they show you logical CPUs. You need to divide by 2 (for hyperthreading) to get physical cores.
The most common audit finding: a customer licensed 64 cores for what they believed was a 64-core server, but it was actually a 32-core server with hyperthreading × 96 logical CPUs. They overpaid by £28K–£52K and also underpaid for other instances where they only counted physical cores. This creates a compliance nightmare because Microsoft often applies penalties to both under- and over-licensing scenarios.
The 4-Core Minimum Rule and Its Implications
SQL Server enforces a 4-core minimum per processor socket, with a 2-socket minimum per server. This creates practical licensing floors.
Minimum Licensing Examples
| Server Configuration | Physical Cores | Minimum Licensed | Cost Impact |
|---|---|---|---|
| Single-socket 8-core server | 8 cores | 8 cores (4-core minimum applies) | Match actual cores |
| Single-socket 2-core server | 2 cores | 8 cores (4 per socket, 2-socket min) | 4x overpayment for small server |
| 2-socket 16-core server | 32 cores | 32 cores (meets minimum) | Match actual cores |
| 4-socket 4-core server | 16 cores | 16 cores (4 per socket) | Match actual cores |
This rule creates an incentive to consolidate workloads onto fewer large servers rather than spread them across many small servers. A server with 2 cores costs the same to licence (8 cores minimum) as one with 8 cores. This affects your consolidation and virtualisation strategy.
Counting Cores in Virtualisation Environments
Virtualisation complicates core counting because you must count cores at the host level, not the VM level.
Hyper-V and VMware Core Counting
When SQL Server runs in a VM, the licensing obligation is still to the physical host. If a 64-core host runs eight SQL VMs, you must licence all 64 cores (for Enterprise Edition) or identify which VMs are licensed and ensure they don't exceed host capacity (for Standard Edition).
The specific rule depends on the edition:
- Enterprise Edition: Licence the physical cores of the host. All VMs on that host are covered.
- Standard Edition: Licence per VM + host OS. Each VM is locked to a specific host and requires separate licensing.
In a vMotion cluster, count physical cores in ALL hosts, not just the hosts currently running SQL. Why? Because the moment you enable vMotion, any SQL instance can potentially move to any host, so all cores become potentially subject to licensing.
Software Assurance Licensing and Core Multipliers
When you add Software Assurance to SQL Server, Microsoft applies a licensing multiplier to your core count for some scenarios. Understanding this prevents unexpected charges.
SA Licensing Scenarios
For most on-premises Enterprise Edition deployments, SA pricing is straightforward: 25–30% of the base licence cost annually. But in some scenarios, Microsoft applies "expanded use rights" multipliers.
| Scenario | Core Multiplier | Reason | Impact |
|---|---|---|---|
| On-premises Enterprise, no cloud | 1.0x | Standard licensing | No impact; standard cost |
| Azure AHUB with on-prem SA | 1.0x (on both sides) | SA enables cloud use | 40–55% cloud savings + SA annual cost |
| Dual licensing (on-prem + cloud) | 2.0x during overlap | Temporary licensing period | Doubled cost for migration window (typically 6–9 months) |
Practical Core Counting Procedure
Here's a step-by-step process to count cores correctly and defend your position to auditors:
Step 1: Identify All Instances
Use SQL Server Configuration Manager or registry queries to locate every SQL instance on the network:
- Instance name
- Host server
- Version and edition
- Installation date
Step 2: Determine Host Configuration
For each host running SQL, determine physical core count. Use one of these methods:
- PowerShell:
Get-WmiObject Win32_Processor | Measure-Object -Property NumberOfCores -Sum - CPU-Z (manual): Install CPU-Z, identify processor model, check Intel/AMD specs for core count
- Hardware documentation: Server purchase order or build spec sheet
Do not rely on Windows Task Manager, which shows logical CPUs. Do not trust virtualization hypervisor reports; they sometimes show vCPU count, not physical cores.
Step 3: Apply Minimums
For each host with SQL Server, apply the 4-core-per-socket, 2-socket minimum rule:
- If physical cores < minimum, use minimum
- If physical cores >= minimum, use actual cores
Step 4: Reconcile with Licence Inventory
Compare your calculated core requirement with your EA order form:
- Over-licensed: You have more licences than required (waste, but compliant)
- Under-licensed: You have fewer licences than required (audit exposure, requires remediation)
- Perfectly matched: Rare and suspicious; suggests calculation error
Common Counting Errors and How to Defend Against Them
Error 1: Counting Logical CPUs Instead of Cores
What auditors find: Documented 96 logical CPUs, licensed as 96 cores, but only 48 physical cores on the server.
Exposure: £28K–£52K overpayment + audit penalty if discovered
Defence strategy: Maintain hardware purchase orders and CPU specifications in your audit file. When the auditor questions your core count, provide CPU documentation showing the model, physical core count, and hyperthreading specification. Frame it as "we documented the logical CPU count initially but corrected to physical cores in our true-up baseline."
Error 2: Ignoring the 4-Core Minimum
What auditors find: A customer licensed a 2-core server as 2 cores, ignoring the 8-core (2 sockets × 4 minimum) requirement.
Exposure: £8,000–£18,000 under-licensing finding + true-up charges for 3+ years
Defence strategy: If you discover this before audit, amend immediately and document the correction date. If auditors find it, argue that the server was decommissioned before the audit period (if true) or that you've now licensed correctly and request a forward-looking settlement (rather than retroactive charges).
Error 3: Virtualisation Coverage Gaps
What auditors find: vMotion cluster licensed for 64 cores (one host) instead of 128 cores (two hosts).
Exposure: £28K–£52K under-licensing + cluster reconfiguration costs
Defence strategy: If discovered, immediately implement VM-to-host affinity pinning to break the cluster into separate licensing groups. Document the pinning rules and propose forward-looking licensing for only the pinned groups. Most auditors accept this if you remediate quickly.
Audit Preparation Checklist
Before Microsoft arrives for a SQL Server audit, prepare this documentation:
- ☐ Inventory of all SQL instances (name, version, edition, host)
- ☐ Hardware specifications for each host (physical cores, socket count, CPU model)
- ☐ Core count calculation spreadsheet (actual cores vs licenced cores)
- ☐ EA order form and all amendments (showing SQL Server purchases by edition and core count)
- ☐ Virtualisation configuration documentation (vMotion clusters, affinity rules, host assignments)
- ☐ SAM engagement records (if any prior assessments)
- ☐ True-up submissions (showing historical core counts)
Having this prepared gives you three advantages: (1) you can spot errors before audit, (2) you demonstrate governance discipline to the auditor, (3) you can negotiate from a position of documented accuracy rather than reconstruction under pressure.