Windows Server is licensed based on edition and number of processor cores in the physical server. Since Windows Server 2016, Microsoft uses a core-based licensing model. The two primary editions are Standard and Datacenter, both of which require CALs for user or device access.
Core Licensing: You must purchase licences for all physical cores on each server. Core licences are sold in 2-core packs. Microsoft requires at least 16 cores per server (even if the machine has fewer) and at least 8 cores per physical processor. Even a small single-socket 4-core server needs 16 core licences.
Standard Edition: Allows up to 2 Windows Server VMs on the licensed server (plus one physical host instance for Hyper-V). For more VMs, you can purchase additional core licences in 16-core increments β called "stacking." Each additional set grants rights for 2 more VMs.
Datacenter Edition: Allows unlimited Windows Server VMs on the licensed server. Once all cores are licensed with Datacenter, you can run any number of VMs on that physical machine. No stacking required.
Client Access Licences (CALs): Each user or device accessing the server needs a CAL β either User CALs (licence a person to access any Windows Server) or Device CALs (licence a device used by any number of users). Exceptions: no CALs needed for internet-only external users (use External Connector instead), or for pure virtualisation hosts not providing services. Remote Desktop Services (RDS) requires additional RDS CALs.
Standard vs Datacenter decision: If you run a server with 2 CPUs Γ 10 cores (20 total), Standard covers 2 VMs. For 6 VMs, you must licence 20 cores three times. At that point, Datacenter β licensing 20 cores once for unlimited VMs β is typically more cost-effective.
Common Windows Server Licensing Pitfalls
Under-licensing cores
Forgetting the 16-core minimum or the requirement to cover all cores. Always double-check physical CPU counts and core counts when ordering licences.
Stacking Standard beyond its limits
Standard can quickly become more expensive than Datacenter if you need many VMs on a single host. If you need to stack Standard more than twice (>4 VMs on one host), calculate whether Datacenter would save money.
Ignoring CAL requirements
Purchasing server licences without accounting for CALs leaves you out of compliance. Every internal user or device accessing server services legally requires a CAL. Budget for CALs in addition to server licences.
Using the wrong CAL type
If employees use multiple devices (PC, laptop, phone), User CALs are usually more cost-effective. If many users share a few devices (shift workers, kiosks), Device CALs are better. Review periodically.
Deep dive into virtualisation licensing rules
Virtualisation Licensing βMicrosoft SQL Server offers two primary licensing models: Server + CAL and Per Core. The best choice depends on your usage scenarios (number of users vs. processor power) and SQL Server edition.
Standard Edition: Can be licensed either Server+CAL or Per Core. Has some feature and performance limitations but is sufficient for many departmental or mid-tier applications.
Enterprise Edition: Top-tier, full feature set, optimised for large-scale mission-critical deployments. Since SQL Server 2012, Enterprise has been licensed per core only β you cannot use the Server+CAL model.
Server + CAL Licensing: One SQL Server licence per server/VM/instance, plus a CAL for each user or device accessing any SQL Server. Cost-effective for a small, defined user population. Not practical for external/public users (CALs for each would be impractical). SQL CALs are separate from Windows CALs.
Per Core Licensing: Licence all CPU cores of the system/VM where SQL Server runs (sold in 2-core packs). No separate CALs needed β any number of users can access. Minimum of 4 core licences per instance. Advantageous for large/unpredictable user counts or external-facing databases. The only option for Enterprise edition.
High Availability: With Software Assurance, you're typically allowed one passive failover instance at no extra licence cost, as long as it's truly passive (not serving clients except during failover). Without SA, any secondary server running SQL must be fully licensed. A major incentive for SA on large SQL deployments.
SQL core minimum: Even a small 2-vCPU VM requires 4 core licences minimum per SQL Server instance. If you dynamically change a VM's vCPU count, update your licensing count accordingly. This is one of the most common audit findings.
Common SQL Server Licensing Pitfalls
Under-counting cores in virtual deployments
The 4-core minimum per VM is critical. If you allocate 2 vCPUs to a SQL VM and licence only 2 cores, you're not compliant β you still need 4 licences for that VM.
Misusing Developer Edition in production
SQL Developer Edition is free with all Enterprise features, but strictly for non-production use only. Organisations occasionally use it in production to save costs β which is a compliance violation. Ensure all production instances use Standard/Enterprise.
CAL overload
Using Server+CAL without tracking user/device counts leads to compliance issues as the organisation grows. There's no annual "CAL true-up notice" β it's on you to ensure you have a CAL for every user/device. Regularly review AD or application user lists vs. purchased CALs.
Mixing editions/features without proper licences
If you have a Standard licence but implement an Enterprise-only feature (like online indexing or certain BI features), that's a compliance problem. You must licence based on the edition of software bits installed/used.
SQL Server Licensing Models Compared
| Feature | Server + CAL | Per Core |
|---|---|---|
| Available For | Standard only | Standard & Enterprise |
| Licence Based On | Server instance + named users/devices | CPU cores of server/VM |
| User Access | Each user/device needs a CAL | Unlimited users β no CALs required |
| Best For | Small, defined user population (<25β30) | Large/unknown user counts, external users |
| Minimum | 1 server licence + CALs | 4 core licences per instance |
| External Users | Impractical β CAL per user | Ideal β no per-user tracking |
| HA (with SA) | 1 passive failover free | 1 passive failover free |
Practical Examples: Choosing the Right Approach
Small Business Scenario
Single physical server with 8 cores, running Windows Server 2022 Standard as Hyper-V host with 2 VMs: one for Active Directory/file sharing, one for a small SQL Server Standard database used by 15 employees.
Licence 16 cores (8 actual + minimum = 16) with Standard edition β covers host + 2 VMs. Purchase 15 User CALs for all employees accessing domain and file server.
15 users and one database VM β opt for SQL Standard Server+CAL model. Buy 1 SQL Standard server licence + 15 SQL CALs. Cost-efficient for small environment.
Mid-Size Virtualised Scenario
VMware cluster with 3 hosts (each 16 cores). ~10 Windows Server VMs, 2 SQL Server instances (one customer-facing with hundreds of web users, one internal with 200 employees).
Each host may run 6β8 VMs β stacking Standard becomes unwieldy. Licence each host with Datacenter edition (16 cores per host) β unlimited VMs, no counting needed. Acquire 200 User CALs for employees across all Windows Servers.
Customer-facing DB (external users can't be CAL'd) β SQL Enterprise Per Core mandatory. Internal DB (200 users) β Per Core more practical than 200+ CALs. Licence one host with 16 SQL Enterprise cores + SA for unlimited virtualisation rights. Internal Standard DB: 4 vCPUs = 4 SQL Standard core licences + SA for Licence Mobility.
Optimising and Managing Over Time
After deploying Windows and SQL Server licences, continuously monitor usage. For Windows Server, ensure new VMs don't exceed your licensed counts (with Datacenter, this isn't an issue). Track CAL usage β if your company hires more people, you'll need more CALs. If you switch from individual use to shared devices (or vice versa), consider changing CAL types at true-up or renewal.
For SQL Server, monitor performance and load. If you see one instance heavily used, confirm you've assigned enough core licences for any vCPU increases. Watch for Enterprise features accidentally enabled on Standard servers. Conduct periodic internal audits β perhaps annually or before a Microsoft true-up β to verify licence entitlements match deployments.
π Related Reading
Assess your environment's size and needs: How many cores? How many users? How many VMs now and in the future? Then choose the editions and licensing models that fit those parameters, balancing upfront cost with long-term flexibility. Always remember the CAL component β it's part of the total cost of ownership.
π Microsoft Licensing Case Studies
π§ Microsoft Advisory Services
Need Help With Windows Server or SQL Server Licensing?
Whether you need licence optimisation, compliance assessment, true-up preparation, EA renewal negotiation, or audit defence β our Microsoft licensing specialists deliver measurable savings and protect your interests as a fully independent advisor.
π‘ Download our Microsoft licensing white papers
View White Papers β