Windows Server licensing starts before server selection

A Windows Server estimate does not start with the number of virtual machines or employees. First, record the physical hosts, processors, and cores, then determine the maximum number of Windows Server instances that can run on each host. Only then should you count client access licenses. Change that order and you will almost always miss one of the multipliers.

The calculation has two independent axes. Core licenses grant the right to run server software on specific hardware or, under special conditions, to license individual virtual machines. CALs give users or devices the right to access that software. Buying one does not replace the other. An installed hypervisor, a light workload, or a single domain does not cancel this model.

The calculations below use the physical licensing rules for Windows Server Standard and Datacenter, with virtual machine licensing noted separately. This is a purchasing worksheet, not a replacement for the Product Terms or the terms of a particular Microsoft agreement. The final specification must always state the edition, version, purchasing channel, and any Software Assurance or subscription rights.

Cores and CALs cover different rights

Core licenses cover the compute host, while CALs cover access by people and devices to server services. You cannot combine these quantities in a single unexplained line called "Windows Server licenses."

Under physical core licensing, Standard and Datacenter licenses are assigned to a physical server. You count every physical core in every installed processor, subject to the minimums. The vCPU count of guest machines does not reduce that base. A core disabled in the BIOS does not disappear from the calculation either: Microsoft's Windows Server licensing FAQ addresses this directly and requires all physical cores to be covered.

CALs work differently. A Windows Server User CAL is assigned to a person, who can access licensed servers from different devices. A Windows Server Device CAL is assigned to a device, which different people may use. One CAL of the appropriate type grants access to Windows Server instances in the organization within the version rights, not just to one selected server. Adding a second file server therefore does not automatically double the CAL count if the licensed population of users and devices stays the same.

Access can be direct or indirect. If an employee opens an internal application and that application uses an intermediary service to read SQL data, a directory, or files on Windows Server, the intermediary usually does not reduce the required access license count. Microsoft documents call this situation multiplexing. Counting only the technical service account is dangerous because licensing follows the people or devices that receive server functionality through the chain.

Keep three separate groups in the estimate:

• Core licenses for each physical host and each Standard layer;
• base Windows Server CALs for users and devices;
• additive access licenses, such as RDS CALs, when the corresponding functions are used.

This lets procurement see where every number came from and lets the architect check it when the configuration changes.

Minimums change the count even on a small server

A physical server must be licensed for its actual cores, with a minimum of eight cores per processor and sixteen cores per server. Both restrictions apply at the same time.

A useful formula for one host is:

лицензируемые ядра =
max(16, сумма по процессорам max(8, физические ядра процессора))

A one-processor server with 6 cores requires 16 Core licenses because the per-server minimum applies. A one-processor server with 12 cores also requires 16. Two 6-core processors produce 16, not 12: each processor is raised to the eight-core minimum, after which the server minimum has also been met. Two 12-core processors require 24 Core licenses. Two 24-core processors require 48.

Microsoft sells Core licenses in two-core packs and, as a convenient option, sixteen-core packs. A 16 Core pack does not mean "one server license." It is simply a bundle of sixteen core licenses. A host with 24 cores can use one 16 Core pack and four 2 Core packs. A host with 26 cores needs one 16 Core pack and five 2 Core packs. You cannot round 26 down to 24 because of pack size.

The opposite mistake also occurs: buying two 16 Core packs for every two-processor server. The processor count alone does not require one sixteen-core pack per socket. Two 8-core processors fit within 16 Core licenses for the server. Two 18-core processors require 36 Core licenses, which could be two 16 Core packs and two 2 Core packs.

Before requesting a price, take the figures from the approved host specification, not from the processor's marketing name. You need the number of installed processors and the number of physical cores in each. Threads, logical processors, and Hyper-Threading do not enter this formula. Empty spare sockets do not count until processors are installed, but a later CPU installation changes the licensing requirement.

On a running Windows host, you can quickly check the source figures with PowerShell:

Get-CimInstance Win32_Processor |
  Select-Object DeviceID, NumberOfCores, NumberOfLogicalProcessors

For two 12-core processors, the result has this shape:

DeviceID NumberOfCores NumberOfLogicalProcessors
CPU0                12                        24
CPU1                12                        24

The calculation uses the NumberOfCores column: 12 plus 12 equals 24. NumberOfLogicalProcessors helps reveal enabled multithreading, but you should not add 24 and 24 and buy 48 Core licenses for this example. Run the command on every physical node and retain the dated output, because nominally identical server models sometimes arrive with different CPU configurations.

The command has limits: it shows installed hardware, but it does not prove commercial rights or explain how many VMs the host can receive. Compare its output with the order specification and cluster management settings. If inventory shows one CPU while the specification shows two, resolve the discrepancy before calculating. The second processor may not be installed yet, may be disabled after a fault, or may not be detected correctly. You cannot choose whichever conflicting source produces the most convenient license base.

Standard is paid in complete layers

One complete Windows Server Standard layer covers every physical core in a host and grants the right to run up to two virtual Windows Server operating system environments. To run the next two VMs, you must cover every core in that host again.

This is where calculations often go wrong. A buyer sees six guest systems with 4 vCPU each and orders 24 Core licenses. Under the physical model, vCPU does not enter the calculation. If the host has 24 physical cores, one layer equals 24 Core licenses regardless of VM size. Six VMs require three layers, or 72 Core licenses assigned to that host.

The formula for Standard under physical licensing is:

слои Standard = ceil(максимум Windows Server ВМ на хосте / 2)
Core Standard на хост = лицензируемые ядра хоста * слои

One VM still requires one complete layer. Two VMs require one layer. A third VM moves the calculation to two layers, which permit up to four VMs. A fifth requires a third layer, which permits up to six. Unused room in a pair cannot be transferred to another server.

Treat the right to a physical operating system environment carefully. When a physical Windows Server instance is used only to host and manage virtual environments, the rules grant the corresponding host right. If it also runs a normal production workload, such as file services or an application, the physical instance consumes one of the permitted environments. A sound design therefore keeps the Hyper-V parent environment limited to virtualization management.

After all physical cores are fully covered, Datacenter permits an unlimited number of virtual Windows Server operating system environments on that host. This does not make Datacenter automatically cheaper. Compare prices under the actual agreement and the expected maximum number of VMs per host. Microsoft's FAQ recommends Datacenter for 13 or more OSEs, but that purchasing threshold is not a universal break-even price. Discounts, editions, Step-Up, and contract composition change the economics.

In a cluster, license possible placement

Every host in a cluster needs rights for the maximum number of Windows Server VMs that can land on it, not only the normal distribution today. Live migration does not carry an ordinary perpetual Standard license with a VM whenever an administrator chooses.

Consider two hosts that normally run three Windows Server guests each. During maintenance of the first host, all six VMs move to the second. Buying two Standard layers per host covers the normal three-VM state because two layers permit up to four. It does not cover maintenance mode on the receiving host. To allow all six VMs to move, each node needs three Standard layers.

You cannot fix this with a shared pile of six layers and a plan to put three wherever needed. Licenses are assigned to servers. Microsoft's general rules restrict reassignment of perpetual licenses between devices to once every 90 days, except where an exception applies. Planned migrations and automatic failover happen more often and must not depend on manual reassignment.

The practical calculation should follow configured cluster restrictions:

• if any VM can run on any host, cover every host for the entire possible set;
• if VM groups are firmly restricted by affinity rules and cannot technically gather on one node, calculate the documented maximum for each node;
• if some VMs shut down during disaster operation, document the list and shutdown order instead of assuming it;
• if a cold standby node can start production VMs, calling it "standby" does not exempt it from licensing.

Customers with active Software Assurance or subscription licenses have another route: virtual machine licensing under the Flexible Virtualization Benefit. In that case, count the virtual cores of each VM with a minimum of eight per VM, and the licenses receive expanded mobility rights within the server farm. You cannot silently apply this method to ordinary perpetual licenses without Software Assurance. Treat it as a separate purchasing scenario and verify the agreement rights.

Choose User CAL or Device CAL by actual work

A User CAL is usually clearer and more economical when one employee uses several devices. A Device CAL fits a shared computer used by different employees. You do not have to choose one type for the whole organization: Microsoft permits a combination of User and Device CALs.

First, draw the access boundary. Count all internal users and devices that access Windows Server directly or indirectly, not just the company's headcount. Administrator accounts still belong to people. Service accounts do not replace CALs for end users. Concurrent sessions do not help either: a standard Windows Server CAL is not licensed by concurrency.

Consider an office and a shift-based facility:

• 25 office employees work from a laptop and occasionally from a home computer;
• 60 shift employees use only 20 assigned shared terminals;
• office employees do not sign in through the facility terminals, and shift employees do not use other devices;
• the servers support both groups.

A sensible combination is 25 User CALs for office employees and 20 Device CALs for the shared terminals. Buying User CALs alone would require 85 licenses. Buying Device CALs alone would require a count of every office device and would likely produce a total above 45. The mixed model works only while the boundary remains true. If a shift supervisor begins signing in from a personal laptop, cover that person with a User CAL or license that device separately.

CAL version matters too. A CAL for a newer version permits access to that version and earlier Windows Server versions. A CAL for an older version does not grant access to a newer server version. Server license downgrade rights do not repair an insufficient CAL version. Record server Core version and CAL version in separate fields even if the supplier shows them in one commercial line.

External users create a different choice. You can assign user or device CALs to them or purchase a Windows Server External Connector for each physical server they access when its terms fit. You cannot simply classify employees and certain onsite contractors as external users to justify an EC. The definitions in the Product Terms matter here.

RDS CAL sits on top of the base CAL

Access to full Remote Desktop Services sessions requires an RDS CAL in addition to a standard Windows Server CAL. Administrative access for server management and employees' working remote desktops belong to different categories.

If 30 employees run applications on an RD Session Host, they need base Windows Server CALs and the corresponding RDS CALs. Choose Per User or Per Device to match the deployment mode and actual access. Microsoft Learn specifically states that an RD Session Host in a workgroup must use Per Device mode and does not permit Per User mode. Both modes are available in a domain environment.

RDS CALs are installed and issued through an activated Remote Desktop license server. That is a technical control for RDS, but records in the licensing manager do not replace a purchasing register and contractual rights. Standard Windows Server CALs have no equivalent server that automatically counts every user of file, print, DNS, or application services.

Not every RDP connection means you must buy an RDS CAL. The Product Terms provide administrative access for a limited number of users to server instances, but you cannot use that mode as a cheap substitute for a production terminal server. If a user receives a desktop or application for regular work, budget for RDS CALs and check the exact terms for the version.

Check a two-host calculation in four lines

Take a configuration that can be attached to a purchase request. There are two identical hosts, each with two processors and 12 physical cores per processor. The cluster runs six Windows Server VMs. Any VM can move to either host, and one host receives all six during maintenance. Two more VMs run Linux and do not require rights to run Windows Server, so they do not increase the number of Standard layers.

The base for one host is 24 Core licenses: both 12-core processors exceed the eight-core processor minimum, and the total exceeds the sixteen-core server minimum.

Under Standard, each host must allow a maximum of six Windows Server VMs. Divide six by two to get three complete layers. One host requires 24 * 3 = 72 Core Standard. Two hosts require 72 * 2 = 144 Core Standard.

Pack sizes can be written without rounding:

На один хост: 4 x 16 Core + 4 x 2 Core = 72 Core
На два хоста: 8 x 16 Core + 8 x 2 Core = 144 Core

This is one way to combine the packs. You can build the whole quantity from 2 Core packs if the commercial program and price make that sensible. The number of assigned core licenses matters, not an attractive pack arrangement.

With Datacenter, cover each host once: 24 Core * 2 hosts = 48 Core Datacenter. Packaging across two hosts could be two 16 Core packs and eight 2 Core packs. Once fully covered, Datacenter permits unlimited Windows Server VMs on those hosts, so maintenance mode does not add layers.

Now add access from the previous example. The organization needs 25 Windows Server User CALs and 20 Windows Server Device CALs. If the same people work through an RD Session Host, add 25 RDS User CALs and 20 RDS Device CALs to the base CALs, provided the chosen model is supported by the deployment and accurately describes access. If only part of the population uses RDS, count additive CALs only for that group, while retaining the base CALs.

The comparable totals are:

Вариант A: 144 Core Standard
Вариант B: 48 Core Datacenter
Доступ в обоих вариантах: 25 User CAL + 20 Device CAL
RDS при необходимости: отдельные RDS CAL поверх базовых

You cannot compare Core counts across editions as equally priced units. Request both prices from the supplier under the same channel and version. Then add expected VM growth. If the maximum rises to eight Windows Server VMs per host next year, Standard needs a fourth layer: another 24 Core licenses for each host.

The specification must survive a configuration change

A good specification records assumptions beside the license quantities. Without them, the supplier sees a SKU but cannot check the calculation, and the customer does not notice when a processor replacement or migration rule has changed the requirement.

For each host, record its role, installed CPU count, physical cores per CPU, Core licensing base, maximum Windows Server OSE count, and chosen edition. Add the number of layers for Standard. For a cluster, state what happens during maintenance of one node and during a failure. For CALs, attach two non-overlapping user and device groups with a description of their access boundaries.

A minimal working table looks like this:

HOST-01 | 2 CPU | 12 cores/CPU | base 24 | max WS OSE 6 | Standard layers 3 | Core 72
HOST-02 | 2 CPU | 12 cores/CPU | base 24 | max WS OSE 6 | Standard layers 3 | Core 72
CAL-U   | office users 25      | Windows Server User CAL 25
CAL-D   | shared devices 20    | Windows Server Device CAL 20

Record the version, license type, Software Assurance or subscription status, downgrade rights, RDS requirement, and external access separately. Do not replace these fields with "latest version license." Commercial programs change, and use rights are defined by the agreement, not by the installation image or activation key.

In Kazakhstan, GSE supplies and integrates Microsoft software with server infrastructure, so the core count, virtualization model, and CAL composition can be checked before the hardware specification is frozen. That check belongs before the order: moving from two 12-core CPUs to two 16-core CPUs increases every Standard layer on both hosts, not just one base pack.

I usually ask three data owners to sign the calculation. Infrastructure confirms the hardware and migration rules, the application owner confirms the Windows Server VM and RDS counts, and procurement confirms the licensing program. Legal counsel or a licensing specialist checks the definitions against the Product Terms. This is not a ceremonial approval loop. Each person owns a multiplier the others do not control.

Activation does not prove sufficient licensing

A product key and successful activation show that a software instance is activated, but they do not prove that the organization bought enough Core licenses and CALs. The technical system does not know every contract term, indirect access path, or possible VM placement in a cluster.

Keep the calculation with the configuration records. It should be backed by invoices and entitlement evidence, the cluster diagram, a physical CPU and core inventory, a VM list with operating systems, movement rules, access group lists, and the reason for choosing User or Device CAL. For RDS, add the licensing mode and license server data.

Recalculate when events occur, not as a calendar ritual. Triggers include replacing or adding a processor, increasing the number of Windows Server VMs, adding a node, changing failover rules, upgrading the version, launching RDS, adding external users, changing the purchasing program, or allowing Software Assurance to expire. Changing only RAM or disk capacity does not itself affect Core requirements, but it often accompanies virtualization growth that changes Standard layers.

I disagree with the common advice to "buy the minimum now and add more later." It sounds economical, but in a cluster the minimum must already cover the permitted failure mode, not average load. Buying later is reasonable for future growth that is still technically blocked. You cannot operate a configuration today if its rights depend on a future purchase.

The last check is simple. Pick the busiest or receiving host and reconstruct its Core count from the table without oral explanations. Then pick one employee and one shared device and show which CAL covers every access path for each. If both chains trace back to a SKU and an agreement term, the estimate is ready for procurement.