Windows Server CAL: when they’re needed and how to track them without mistakes

Why bother with Windows Server CALs

Windows Server CALs are often thought of as something related to installing a server, but that's not accurate. A CAL is the right for a user or device to access Windows Server services. A server can be perfectly configured, yet if people and computers connect without the proper access rights, you'll have a licensing gap.

CALs are rarely considered during deployment. A domain is set up “for order,” a file share created “temporarily,” remote access enabled “until we buy a VPN.” Technically everything works, and licensing is postponed until procurement, an auditor or management asks: “How many do we need and why?”

What this can lead to

Incorrect accounting almost always hits budgets and timelines. It may seem possible to buy more later, but in practice budgets for the year are already allocated, needs grow unexpectedly, projects stall due to approvals and urgent purchases, and during an audit it's hard to prove access rights if documents and records are not in order. It's even worse when different teams count differently and arrive at different numbers.

Even without a formal audit this complicates IT management: planning hires, connecting branches and launching new services becomes harder.

Addressing this early helps not only administrators. Procurement can compare models (User vs Device CAL), finance can forecast costs, legal can understand the acquired rights, and leadership can reduce the risk of work stoppages caused by licensing issues.

If you have AD, file resources, remote workplaces or server applications, CALs will become a practical matter sooner or later. Better it happens on your terms, not in firefighting mode.

Basic concepts: server license vs CAL

A Windows Server license and a Windows Server CAL are different things.

A server license applies to the server itself: it grants the right to install and use the OS on hardware (or in a virtual environment). A CAL (Client Access License) applies to access: it confirms the right of users or devices to connect to Windows Server services.

A simple way to remember: the server license answers “Can we run Windows Server here?”, while a CAL answers “Who has the right to use what this server provides?”. Even if you have a single small server, employee access to the domain, shared folders or print services typically requires CALs.

There are two main CAL models:

• User CAL — tied to a person and suitable when an employee works from multiple devices.
• Device CAL — tied to a specific device and convenient when many people use the same computers in shifts.

Everyday examples usually make the choice obvious. If each employee has a desktop, a laptop and sometimes a phone for email, User CALs usually win. If work is shift‑based, a classroom or an operator workstation is shared, Device CALs are typically more logical.

There is also External Connector, used when external users regularly connect to the server and counting a CAL per person is impractical. This is not a universal CAL replacement: you must clearly define who counts as “external” for your organization.

The Windows Server edition (Standard, Datacenter, etc.) does not remove the need for CALs. Editions affect features and deployment rules, but access rights to core services are confirmed by CALs separately. Some scenarios may add additional licensing layers (for example, for remote workplaces), but that is a separate topic.

When CALs are required: a simple rule and its boundaries

A simple rule: if a user or device accesses Windows Server services over the network, a Windows Server CAL is usually required. It doesn’t matter whether the server is on‑premises or in a data center, physical or virtual. What matters is access to server functions.

“Access” usually means more than being in the same room as the server — it means using it as a service: logging into the domain, opening a share, printing to a network printer, running an application hosted on Windows Server.

Typical cases where CALs are almost always required: domain sign‑in and authentication (Active Directory), access to file shares, network printing, use of applications hosted on Windows Server, and use of basic services (DHCP/DNS) as part of the corporate network.

Boundaries aren't always obvious. A public website hosted on Windows Server for anonymous internet visitors is typically considered separately from internal user access. But once authentication appears, access for employees is restricted, or domain accounts are used, CALs almost always become mandatory.

There are exceptions that are often overstated. Windows Server allows limited administrative connections for server management. These are not “free CALs” for normal user activity. As soon as an administrator uses file shares, applications or domain services as a user, CAL requirements apply.

Virtualization doesn’t change CALs. If you have 10 VMs on one host, CALs are counted by the number of users or devices accessing services, not by the number of VMs.

AD and file services: where CALs are commonly forgotten

Confusion around Windows Server CALs most often happens where a server “just works”: domain, shared folders, printers. It may seem that if you didn’t buy a separate server application, no additional access rights are required. But CALs cover the access of users or devices to Windows Server services.

Active Directory (AD DS): access exists even if it’s “just domain logon”

If a user or device joins a domain, authenticates, receives Group Policy Objects (GPOs), requests Kerberos tickets from a domain controller or changes a password, that is access to Windows Server services. The same applies to background AD scenarios: Wi‑Fi authenticated with domain credentials, proxy integration, or machines applying policies at boot.

CALs are often missed when only those who open shares are counted. In practice, almost all workstations contact AD even if a user never opens a single share.

File services (SMB) and printing: “basic” does not mean “no CALs”

Shared folders, home directories, network drives, scan‑to‑folder, user profiles and print services — all are access to Windows Server. If a device (for example, an MFD) connects to a share to deposit scans, it must be considered too.

Commonly missed items include shared terminals in a plant or warehouse, “guest” PCs, devices that use a shared account, MFDs and cameras that read/write to SMB shares, and contractors connecting to company resources.

Example: 1 file server, 120 employees and 30 shared terminals

First decide whether you license by users or devices. If 120 employees each use several devices (desktop + laptop), User CALs are usually simpler. Thirty shared terminals used in shifts are typically better covered by Device CALs, because you license the terminal itself rather than every person who uses it.

The main rule for AD and file services: count everyone who actually accesses the services, including devices and background scenarios — not the number of servers.

RDS and remote workplaces: a separate licensing layer

Confusion arises here: Windows Server CAL and RDS CAL are different rights. Windows Server CALs grant access to core Windows Server services (files, AD, printing). RDS CALs grant the separate right to use Remote Desktop Services — remote sessions and published applications.

RDS CALs are required not merely because someone connects over the network, but when you use RDS scenarios: signing into a Session Host, launching a published application, or connecting via RD Gateway to an RDS pool. If an admin connects by RDP for server maintenance, that is not the same as providing remote workspaces for employees.

A simple test: if a person uses a remote desktop session like a regular PC to do their work, that’s RDS and requires RDS CALs.

Choose between User and Device RDS CALs based on who uses the service. Shift scenarios (call centers, classrooms, guard posts) usually favor Device RDS CALs. When one person connects from multiple places (doctors, managers), User RDS CALs are often more suitable.

In projects, check not only concurrent sessions for capacity planning, but also the number of unique users or devices that use RDS. Licensing RDS CALs is tied to users or devices, not peak concurrent sessions.

Server applications: CALs vs application licensing

Confusion often appears when business buys an application license and assumes that covers server access. In reality an application license and Windows Server CALs address different rights: the former allows use of the software, the latter allows users or devices to access Windows Server services.

Imagine accounting software hosted on Windows Server. Some employees use a thick client, others a web interface, and others connect via terminal sessions. If the application runs on Windows Server and users in any way access files, print via the server, authenticate against the domain or use other server functions, CALs still apply even if the application itself is licensed.

Where application licensing ends and CALs begin

A simplified rule: the application license covers the app’s functionality; CALs cover access to Windows Server. If a user opens a program that reads data from the server, saves files to the server, prints through the server or authenticates via domain accounts, they use Windows Server services. That means Windows Server CALs may be required in addition to the application license.

Also remember RDS: if the application is accessed via Remote Desktop, RDS CALs are an extra layer.

Services that quietly trigger CAL requirements

CALs are often forgotten because the connection looks like “just running a program.” In reality dependencies can trigger CALs: domain authentication, storing documents on network shares, printing through the server, or accessing server data even with a thin client or web client.

Before purchasing, ask the software vendor: will the system require domain authentication, where will files and databases reside, how do users connect (locally, over the network, via RDS), and which Windows Server roles are involved. This helps separate what the app license covers and what must be acquired as CALs (and RDS CALs if needed).

How to count CALs in practice: a step‑by‑step approach

Counting CALs is easier if you don’t try to guess from headcount. CALs aren’t required because you bought a server; they’re required because users and devices access server services. So first document who accesses what, then count.

A practical workflow you can repeat in almost any organization:

• Describe services on each server: AD, file shares, printing, RDS, and any applications using server roles.
• List access consumers: user groups, device types, branches, contractors, warehouse terminals, POS systems.
• For each scenario choose a model: User or Device. Don’t mix choices by habit.
• Count and immediately record assumptions: who is a “user”, which devices are in scope, whether contractors are included, how shared accounts are treated.
• Reconcile counts with growth and seasonality: shift work, temporary staff, project teams, branch expansion.

How to pick User or Device

User CALs are typically better when one person connects from multiple devices (office PC, laptop, phone). Device CALs are often better where many people share the same workstation (shifts, call centers, classrooms).

Small calculation example

Domain + file server. Office has 60 employees, each with two devices, plus 10 shared PCs in meeting rooms. Compare: 60 User CALs vs 70 Device CALs (60 personal desktops + 10 shared). Often User CALs are cheaper.

Then check additional layers. If 15 people use terminal sessions, add 15 RDS CALs for those users or devices. Keep assumptions linked to the numbers so procurement and audits are straightforward.

Common mistakes and licensing traps

The most frequent mistake: buying a Windows Server license and assuming that’s enough. The server license allows installation; user or device access to services typically requires Windows Server CALs.

Second trap: counting only HR headcount. Access isn’t limited to “people” — shared workstations, reception PCs, classroom labs, warehouse terminals, kiosks and POS systems all consume access. If these points are used by different people in shifts, licensing the device may be more economical, but you must decide and record it.

Mixing User and Device CALs chaotically is another problem. Don’t do “as it happens”: define rules (office by users, production by devices) and stick to them. Otherwise it’s hard to justify the approach during an audit.

RDS adds another layer: Windows Server CALs and RDS CALs are separate. If employees use remote desktop sessions as workspaces, they typically need both types of CALs.

Contractors and external workers are often forgotten. If an outsourced accountant connects to files or the domain, that’s access requiring licensing unless there is a separate legal arrangement.

Quick checklist of places where gaps often appear:

• Shared PCs, terminals and shift workstations
• RDS and published applications
• Service accounts used by applications
• Contractors, temporary staff and external support
• No documented choice between User vs Device

Example: a company with 60 employees and 10 shared PCs on the shop floor. Counting only “60 people” may miss access from shared devices, or lead to overpaying if it would be better to license the shop devices separately while keeping office users on User CALs.

How to build a CAL register: a simple template

A CAL register gives IT and procurement a single source of truth: what was bought, what it covers, how much is available and who is responsible. When an audit, contractor change or infrastructure expansion happens, the register answers questions quickly.

Keep it as a spreadsheet or in ITSM with consistent fields. Minimum columns:

• Product (e.g. Windows Server 2022) and role/service (AD, file server, RDS)
• CAL type (Windows Server CAL, RDS CAL)
• Model: User or Device
• Quantity (purchased, available, reserved)
• Purchase date and vendor
• Supporting document (invoice, act, contract, order number)
• Service owner (name or role: AD admin, RDS owner, IT manager)

Group allocations are easier to manage than individual names, especially if headcount changes. For example: “office staff,” “call center operators,” “branch terminals,” “classrooms.” Then you change group sizes instead of editing hundreds of rows.

Update the register on events, not “when someone remembers.” A short procedure works well: on hiring, PC purchase/decommission, new branch connection, RDS or new server app deployment — update the register. If you have a month‑end close calendar, add a register check there.

Store the register where it won’t be lost or edited by everyone: a protected shared resource with versioning. Split responsibilities: IT maintains actual usage and service owners, procurement or finance confirms supporting documents and amounts. This keeps the register useful for operations and audits.

Realistic example: a company with a domain, files and RDS

Company: one head office and two small branches. There’s a domain for accounts, one file server for shared folders, and a separate RDS server where accounting runs 1C and a couple of business apps.

People/devices: 35 office employees with personal laptops. Branches have 8 employees each, but workstations are shared: 6 desktops per branch used in shifts. Six accountants use RDS from the office and sometimes from home.

Windows Server CALs are needed for AD and file access. A typical logic: issue User CALs for office employees (one person, multiple devices) and Device CALs for shared PCs in branches (one device, many people).

RDS CALs are required only for those who connect to Remote Desktop Services — in this case 6 accountants. Other employees who only use domain and file services don’t need RDS CALs.

Record everything separately in the register with explanations, for example:

• Windows Server User CAL — 35 units (office users)
• Windows Server Device CAL — 12 units (6 PCs in each of 2 branches)
• RDS User CAL — 6 units (accounting via RDS)

Before purchasing ask manager questions to avoid buying just enough:

• Will headcount grow in the next 6–12 months?
• Will new branches or additional shifts be opened?
• How many people truly work remotely and how often?
• Will shared workstations appear in the office (call center, reception)?
• Are there plans to add server roles or move apps to RDS?

This way the register reflects not only numbers but the logic behind them, which is easier to defend in audits.

Checklist and next steps for procurement and audit

Before procurement or an internal review record facts quickly: what roles run on servers, who connects and how this is supported by documents. This avoids the situation where Windows Server CALs “exist somehow” but it’s unclear what they cover.

Short infrastructure self‑check:

• List roles and services: AD DS, file services, printing, RDS, applications (1C, SQL, terminal farms).
• Mark who connects: employees, contractors, service accounts, external users.
• Reconcile numbers: active users in the domain, registered devices, RDS remote connections.
• Check access boundaries: are there shared folders everyone uses, unregistered branches or shift workstations?
• Separate normal Windows Server access from the RDS layer.

Then check the register. It should answer: “How many licenses do we have?” and “Why do we think this is enough?” If documents exist but no rules (for example, you decide by user not device and when you switch) the risk remains.

Next steps for calm procurement and audit:

• Gather supporting documents: invoices, acts, licenses, correspondence, legal entity and department allocation.
• Approve a rule for recalculation: quarterly and whenever changes occur (new branch, RDS, app migration).
• Build a buffer for growth and seasonal users but document why it’s needed.
• When planning server upgrades include licenses and support in the project. If necessary, discuss calculations with integrators and server vendors such as GSE.kz so hardware, roles and licenses align.

If questions remain (who counts as a user, where RDS begins, how to treat contractors), record assumptions in writing and attach them to the register. During audits this is often more important than perfect numbers.