Core-Based Licensing Mechanics
Introduction: Core-based licensing is at the heart of Windows Server licensing, dictating how many licenses you need for a given server.
This article provides a detailed look at the mechanics of core-based licensing – how to count cores, apply license packs, and deal with special cases like hyper-threading or virtual cores.
By understanding these mechanics, CIOs and SAM professionals can avoid costly mistakes and ensure every server is correctly licensed under Microsoft’s rules.
Read more about Microsoft Windows Server Licensing.
Counting Physical Cores and License Requirements
Under the core-based model, the number of core licenses required equals the number of physical cores in the server, with mandatory minimums in place. Here’s how to determine your needs:
- Identify Physical Cores: For each physical server, determine the number of processors (sockets) and the number of cores per processor. For example, a server might have 2 CPUs with 10 cores, totaling 20 physical cores.
- Apply the 8/16 Rule: Microsoft’s licensing policy mandates at least eight core licenses per processor and 16 core licenses per server as a minimum. Even if your server has a single 6-core CPU (6 cores total), you must still license eight cores for that one processor (and 16 cores for the server, but since 16 is the server minimum, you’re licensing 16 anyway). In practice, any modern server with 1–2 CPUs will likely hit the 16-core minimum unless it’s a very low-core-count machine. This rule ensures a minimum revenue for Microsoft per server, even for small ones.
- Licenses Sold in Packs: Windows Server core licenses are commonly sold in 2-core packs. Some channels offer 16-core pack SKUs (essentially 8×2-core packs bundled) for convenience. Pricing is typically proportional: e.g., one 16-pack costs about 8 times a 2-pack. You can use either pack size to assemble the total licenses you need. For instance, if you need to license 20 cores, you could buy ten 2-core packs or one 16-core pack + two 2-core packs – whichever aligns with your procurement channel. In volume licensing agreements, you might choose pack sizes based on how they count for points or discounts, but ultimately, the total core count matters.
- Example – Physical Core Calculation: Suppose you have a server with 2 CPUs, each with 12 cores, for 24 cores. According to the rules, you must license all 24 cores. The minimums (8 per CPU, 16 per server) are exceeded naturally since 24 > 16. You could purchase twelve 2-core license packs to cover 24 cores. Alternatively, if 16-core packs are available in your program, one 16-core pack + four 2-core packs would also equal 24. It’s important to document the calculation: server “XYZ” has 24 cores, therefore requires 24 core licenses (which might be delivered as 12 × 2-core licenses). All core licenses for a server must be assigned to that server – you cannot split a pack across multiple servers. Once assigned, that covers the Windows Server OS on that hardware.
- Disabled Cores: A question often arises – what if some cores are disabled (for example, via BIOS)? Microsoft’s rule is that all physical cores must be licensed, even if disabled. You cannot save on licensing by turning off cores, at least not without physically removing them. Licensing is based on the hardware capability, not how you choose to use it at a point in time. This is a compliance point to watch during true-ups or audits.
Hyper-threading:
Hyper-threading (Intel) or SMT (simultaneous multithreading) in CPUs creates two logical threads per physical core. Microsoft does not count hyper-threads as cores – only physical cores count. So if you have an 8-core processor with hyper-threading on (showing 16 logical processors in the OS), you still only need 8 core licenses for that CPU (subject to the eight minimum, which is exactly 8 in this case). This is an area of relief: enabling hyper-threading to boost performance does not double your licensing as it might in other vendor licensing models. Always count the physical cores.
Per-Server vs Per-CPU Perspective:
It’s easiest to calculate at the server level (total cores per server), then ensure you’ve met the per-processor minimum for that breakdown. For instance, a 24-core server with 2 CPUs implicitly has 12 cores/CPU, above the 8-core min each, so you’re fine. If a server had 2 CPUs with four cores each (8 total), the min 8 per CPU and 16 per server would force you to license 16 (meaning you’re effectively licensing some non-existent cores to meet the floor). In any case, the final number is typically the greater of the actual core count or the required minimum (16). Always round up to the minimums.
Read more Windows Server Licensing Models.
Licensing Physical vs. Virtual Environments
Microsoft provides two ways to apply core licenses in certain scenarios: physical-core licensing (the standard method described above) and, for certain customers, virtual-core licensing.
It’s crucial to understand when each applies:
- Physical Core Licensing (Default Method): In on-premises deployments without special Software Assurance (SA) or subscription rights, you must license all physical cores on the host hardware, even if you run only a few VMs. By doing so, you cover the permission to run Windows Server on that hardware (including a certain number of VMs, depending on edition, as discussed). This is the method most customers use. For example, a host with 24 cores running 2 Windows VMs under Standard edition: you license all 24 cores (which covers 2 VMs) – if you want more VMs, you license the cores again accordingly (or use Datacenter edition for unlimited VMs).
- Virtual Core Licensing (with SA or Subscription): Microsoft recognizes that in cloud and hybrid scenarios, you might want to license by virtual machine instead. If you have active Software Assurance or equivalent subscription licenses, you can assign licenses to VMs individually instead of to the whole host. In this case, you count the virtual cores (vCPUs) assigned to a VM and license those, with a minimum of 8 licenses per VM. For example, if you want to license a single VM running on a host you don’t fully control (like in certain hosting scenarios), you could assign eight core licenses to that VM (even if it only has four vCPUs, the minimum eight still applies). If the VM has 12 vCPUs, you’d assign 12 core licenses to cover it. This method is primarily used in Azure or authorized cloud environments – a key scenario is Azure Hybrid Benefit, where a customer brings their licenses to Azure VMs (we’ll explore that in the hybrid cloud article). Outside of Azure, recent licensing changes allow using this per-VM licensing on other cloud providers only if you have the proper subscriptions/SA and the provider is an “Authorized Outsourcer” (Microsoft’s program for third-party clouds). Notably, the option to license by virtual core is not available to customers without SA or subscription; those customers must license the physical cores of any server where they deploy Windows Server.
- Mixing Methods: You always license per physical core in your datacenter with purchased perpetual licenses (no SA). If you have an Enterprise Agreement with Windows Server Datacenter with SA, you could license a particular workload per VM (perhaps to spin up a VM on someone else’s host). But you wouldn’t normally mix on the same hardware – it’s one approach or another for a given deployment context. Many large organizations stick to physical licensing for on-prem and use per-VM only when extending to cloud platforms.
Reassignment Rules: Under standard rules, a core license cannot be reassigned to another server (physical or VM) for at least 90 days (except to retire the original server) once assigned to it.
This is important for scenarios like clustering or VM mobility. If you have a cluster of hosts and want to freely move Windows VMs between them (e.g., using VMware vMotion or Hyper-V Live Migration), you need to license each host for the maximum number of VMs that could run on it, or have Datacenter edition on all hosts.
You cannot “float” a single Windows Server license to whichever host is running the VM at a given moment without breaching the 90-day assignment rule. One benefit of Software Assurance is more flexibility: using the per-VM licensing with SA, you can move that VM license more frequently across hosts in a server farm (essentially treating it like a cloud scenario in your own datacenter). Still, careful tracking is required to ensure compliance.
Read Licensing Across Programs: EA, CSP, SPLA, Open Value, OEM.
Core Licensing and CALs
It’s worth reiterating that core licensing covers only the server installation itself. As described in the first article, you must still account for CALs (Client Access Licenses) for users/devices accessing the server.
The core license gives you the right to install and run Windows Server on the machine, but it does not grant users the right to connect to it. Ensure you calculate how many CALs are needed for those servers’ users alongside your core count calculations. (The number of CALs is not tied to cores or processors – it’s based on users or devices regardless of server size.)
In core-based licensing, every edition and channel uses the same core counting rules. Whether you buy via a volume license agreement, OEM, or cloud subscription, a “16-core license” always means it can cover up to 16 cores of one server. CAL requirements likewise remain the same across editions (Standard vs Datacenter) – the difference is just virtualization rights, not how many CALs are needed.
Practical Examples
Let’s walk through a couple of practical scenarios to solidify the mechanics:
- Scenario 1: Small Office Server – You have a single tower server with 1 CPU, eight cores, running Windows Server 2022 Standard to handle file sharing for 10 employees. According to core licensing rules, even though the server has eight cores, you must license 16 cores (minimum for one server). So you buy eight two-core packs to cover the 16 cores. This allows you to run Windows Server on that hardware (Standard edition, so you could run 1 physical + 2 VMs if needed, but in this case, maybe you just use the physical OS). You’ll also need 10 User CALs (one for each employee) since they all access it. Result: 16 core licenses (Standard) + 10 user CALs.
- Scenario 2: Highly Virtualized Host – You have a host with 2 CPUs, 20 cores each (40 cores total). It runs 10 Windows Server VMs via VMware. You need to decide between Standard and Datacenter. If you go with Datacenter edition, you license all 40 cores once with Datacenter, and you’re done – unlimited VMs on that host are allowed. If you go with the Standard edition, each set of core licenses (covering all 40 cores) allows 2 VMs. To cover 10 VMs, you would need five sets of 40-core licenses (5 × 2 VM rights). That means buying 5×40 = 200 core licenses, which is far more expensive than 40 Datacenter core licenses. So, Datacenter is the logical choice here. You would buy, for instance, twenty-five 2-core packs (which equals 50 cores worth – covering the 40 needed, extra 10 are just excess due to pack sizing) or some combination to get to 40, and assign them to that host as one Datacenter license. Ensure all users of these VMs have CALs as well. If internal employees mainly access the VMs, CALs will be needed per user/device. If one of the VMs is a public web server for external users, you might apply an External Connector on that VM’s instance instead of CALs for external visitors.
- Scenario 3: Licensing by VM in Cloud – You have a Windows Server workload you want to run on AWS or a third-party datacenter. You have an active subscription for Windows Server Datacenter from your CSP (Cloud Solution Provider) agreement, which grants you license mobility. Instead of using AWS’s license-included offering, you Bring Your Own License. You choose to license using a virtual machine because the cloud provider is part of Microsoft’s authorized outsourcers program. Your VM has eight vCPUs. According to the rules, you must allocate at least eight core licenses to that VM (8 vCPUs meets the minimum). If the VM had 12 vCPUs, you would allocate 12 licenses. You mark that license as assigned to that VM (perhaps documented via a license tracking tool or scripts provided by the cloud provider). Now, because you’re using Datacenter edition with SA, Microsoft’s rules allow simultaneous use – you could technically keep using your on-prem Datacenter server and use the same license in the cloud for a VM (Datacenter SA provides dual use rights for VMs). However, you must ensure that your total license count is not exceeded across all usage. This scenario is more advanced but shows how core licensing mechanics adapt to virtual contexts when you have enhanced use rights.
License Optimization Considerations
Understanding core mechanics also allows you to optimize costs. Some tips:
- Consolidation: Because each server has a 16-core minimum cost, consolidating workloads onto beefier servers can sometimes reduce licensing count compared to many small servers. For example, instead of two 8-core servers (which would require 2×16 = 32 cores of licenses due to minimums), one 16-core server could handle both workloads with 16 licenses, halving the requirement. (Hardware cost and fault tolerance considerations aside, from a pure license standpoint, bigger servers are more efficient to license.)
- Software Assurance Benefits: If you have SA, remember to use its options (like per-VM licensing in certain cases, or the ability to spin up new versions). SA also allows upgrade rights, so you don’t need to repurchase licenses for new Windows Server versions; you can upgrade covered licenses. This protects your investment as new versions like Windows Server 2025 arrive.
- Monitoring and True-ups: Monitor physical core counts in your environment inventory. If you add processors or enable additional cores (some servers ship with some cores disabled that can be enabled later), update your license counts accordingly. Regular true-up exercises (common in enterprise agreements) should reconcile any changes in hardware configuration to your licensed core counts.
- Avoiding Penalties: If audited, Microsoft will typically check that you have at least 16 core licenses and at least as many licenses as cores for each server. Non-compliance often happens when organizations spin up development or test servers and neglect to license them fully, or repurpose hardware without adjusting licenses. Even for short-lived servers, a license is required once the OS is installed (unless you’re using evaluation rights or Azure Dev/Test, which have their own rules). Having a centralized record mapping licenses to servers (license assignments) can save a lot of headaches demonstrating compliance.
Recommendations
- Document Core Counts: Maintain a hardware inventory with CPU and core counts for all Windows Server servers. Use this to calculate required licenses and ensure you meet each machine’s 8-core-per-proc, 16-core-per-server rule. Update this documentation whenever hardware is changed.
- Use the Right Licensing Mode: If you have Software Assurance or subscription entitlements, evaluate scenarios where per-VM licensing could be beneficial (e.g., deploying to cloud or mixed environments). Otherwise, stick to physical core licensing and ensure all cores are covered. Don’t try to under-license by partial coverage – Microsoft does not allow fractional licensing of a physical server.
- Plan for Growth: If you anticipate adding more VMs to a host, consider the tipping point for moving from Standard to Datacenter edition. It’s often around the point of needing more than 2–4 VMs on a host. Over-licensing with Standard (stacking many times) creates complexity and potential mistakes. Investing in Datacenter licenses for heavily virtualized hosts may be more strategic.
- Include CALs in Strategies: Align your CAL procurement with your core licensing. Even a perfectly core-licensed server is non-compliant if the users lack CALs. Make sure CAL management is part of your overall licensing strategy for Windows Server. For external-facing systems, determine if an External Connector is needed and procure it per server as appropriate.
- Seek Expert Review: Have your licensing counts and methods reviewed periodically by an independent licensing advisor or SAM consultant. An expert (such as Redress Compliance) can validate that you’re applying core licensing rules correctly and not overlooking any opportunities (or pitfalls). This is especially useful before a true-up or Microsoft audit – catching mistakes in advance can save significant cost and negotiation pain.
