RDS CAL and VDI licensing: a checklist of questions for IT

Why you need a checklist before RDS and VDI

RDS CAL and VDI licensing almost always involve money, data access and accountability. Without an agreed checklist it’s easy to overpay for unnecessary licenses or, conversely, to be under-licensed and halt work at the worst moment — for example during an internal audit or inspection.

RDS and VDI are often confused because the user sees a remote desktop and works in familiar apps. But internally they are different approaches. In one case you give access to a session on a terminal server, in the other — to a dedicated virtual workstation. If you choose a model based on “feeling” rather than scenarios, you may later need to change the architecture, buy more licenses and explain schedule shifts.

Projects usually “break” in three places: no solution owner, no clear accounting of users and devices, and no common answer to who and how controls access. As a result, IT plans performance, procurement calculates the budget, and InfoSec learns details only after launch.

Before approving a project it’s useful to fix basic things on one page: who connects, from where and from which devices, what data will be accessible and where it must be stored, and how you confirm compliance with licenses and InfoSec requirements.

A simple example: accounting works from office-assigned PCs, while a contractor’s service team connects by request for 2–3 hours. These groups often need different access rules and different licensing solutions.

Below are questions to ask IT and InfoSec before choosing a model, procurement and deployment so the solution is legal, manageable and predictable in cost.

Basic concepts in plain language

RDS (Remote Desktop Services) — a role in Windows Server that allows people to work with applications and a desktop on a server remotely.

RDP (Remote Desktop Protocol) — the protocol used for the connection.

Terminal session — your individual working session on a server: you sign in with your account, run applications, save files and sign out.

CAL (Client Access License) is often confused with a “Windows Server license,” but they are different. A Windows Server license allows you to run the server itself. An RDS CAL gives a user or device the right to connect to RDS and work via terminal sessions. Therefore, when planning, count not only servers but also those who connect to them.

VDI (Virtual Desktop Infrastructure) — an approach where each user is given a dedicated virtual PC (VM) with their own desktop. In RDS users typically share one server (different sessions on the same hardware and OS). VDI provides more isolation and flexibility (different images and settings), but usually demands more from infrastructure and administration.

In practice there are several typical access variants, and they determine which licensing questions to ask next:

• shared terminal server: many users in sessions on one or several servers;
• VDI: one user — one VM;
• access from office PCs/laptops: important to know how many people and devices actually connect;
• access from “thin” endpoints (thin clients, old PCs, mini-PCs): these are often counted per device and require planning for login management.

Example: accounting uses 1C via a shared terminal server, while a group requiring stronger isolation gets VDI. From the outside it looks the same (“connected via RDP”), but internally they are different models: security, load and licensing are handled differently.

How to gather initial data: a step-by-step plan

To avoid turning licensing into guesswork, collect facts first. It’s most convenient in a single table showing who connects, from where, from which devices and to which resources.

1. Start with an inventory of what will actually be available remotely. This is not “terminal server in general,” but concrete applications (1C, HIS, CAD, browser systems), data types (personal, financial, medical) and operations (view only or also printing, file export, working with USB).

2. Then move to numbers and roles:

• record the number of people who need access and their working modes (day shifts, night shifts, rotating);
• separately note peak simultaneous connections;
• count devices: office PCs, laptops, thin clients, personal devices;
• split users into groups: employees, external contractors, partners, interns;
• list service accounts and technical accounts separately so they are not mixed with real users.

3. Describe entry points: office, branches, home network, business trips, access from another country (if applicable). These often affect MFA, VPN and segmentation requirements.

4. Agree InfoSec requirements and internal policies: logging, log storage, copy restrictions, regulatory and audit requirements.

A small example: a medical organization has 120 staff working in two shifts, but a maximum of 45 concurrent connections. Some doctors use laptops in departments, and a contractor connects once a week for updates. If this isn’t recorded immediately, you can easily make mistakes in choosing per user/per device and in access rules.

If you have a distributed network of branches and mixed user groups, a system integrator often starts the project with such an “access map.” It simplifies procurement, access control configuration and later audits. In Kazakhstan, such projects, including server and workstation selection, are carried out by GSE.kz.

Per user or per device: questions for the right choice

Choosing between per user and per device seems simple until you start counting people, devices and real scenarios. Mistakes here usually lead to extra costs or to a situation where access “seems to exist” but legally and in license accounting things are bad.

First determine the scale: how many unique employees connect to remote access in a typical month and in a year. The annual number is often more important if you have temporary projects, interns or occasional connections.

Next look at the “device map.” One person may work from an office PC, a laptop and occasionally from home. In this model per user is usually easier to justify and support. If you have many shared workplaces (rotating posts, reception desks, a classroom, call center) where different people use the same PC in shifts, per device often looks more natural.

To decide without guessing, ask several direct questions:

• how many unique users actually connect in a typical month and at peak;
• how many devices does one employee use and which of them are “mandatory”;
• are there shared workplaces and how many shifts/people use a single spot;
• is access from personal devices allowed and under what conditions (for example only via corporate VPN or VDI);
• what seasonal peaks are expected (reporting, admissions, inventory) and how long they last.

A small example: a clinic has 40 staff. 15 doctors connect from both the office and home, while the registry has 10 workstations used in two shifts (20 people). Often a mixed picture emerges: per user is convenient for doctors, per device for the registry. This is a reason to agree on a mixed approach in advance and how you will account for it to avoid disputes at audit time.

External contractors and temporary access

External contractors are almost always the riskiest area in remote access. A common mistake is “let them use an employee account to make it faster.” That removes personal accountability, proper auditing and the ability to quickly revoke access without side effects.

First decide: does the contractor work under their own identity or “as an employee.” A practical option is a separate contractor account tied to a specific contract, project and contact person within your company.

Next clarify access boundaries. Temporary access should be limited not only by dates but also by scope: which systems, which roles, which actions are permitted. If a contractor services servers or workstations, they often only need access to specific admin consoles or groups of servers, not the full terminal environment.

A separate question is whether you need a separate network segment or a separate farm for external connections. This is often justified if there are many contractors, they work from unpredictable networks, or you separate critical systems (finance, medical, government) from normal services. Segmentation reduces lateral movement risk and simplifies InfoSec rules.

To avoid disputes during incidents, agree in advance on the access operation: who requests access and on what basis, who approves, who issues access and for how long, who revokes access and how revocation is verified, and how one-off connections and maintenance windows are recorded.

Example: a contractor updates software on several servers once a month. They are given a separate account with access only to those servers, only for 24 hours in an agreed window, with mandatory action logging. If the connection isn’t needed, access closes automatically at expiry.

Terminal access scenarios and where VDI is chosen more often

The choice between RDS and VDI usually depends on how people work: how many users you have, which applications, how roles change, and how strict data requirements are — not on “fashion.”

Scenario 1: shared terminal server for office tasks

If most users need email, a browser, office documents and 1–2 internal systems, a shared terminal server is usually sufficient. It’s easier to support: updates and settings are done once on the server and users connect from various devices.

Decide in advance how they will connect: per user (person) or per device. Also immediately fix whether personal laptops and thin clients will be allowed. Otherwise licensing calculations will diverge from reality.

Scenario 2: dedicated desktops (VDI) by roles

VDI is often chosen when different groups have very different software sets and rights, or when isolation is required. Example: accounting needs one set, engineers another, contact center a third. VDI is also convenient where quickly issuing a “clean” workstation to new employees or project teams is important.

A separate split is persistent vs non-persistent desktops. The first behave like personal PCs: settings persist but maintenance is harder. The latter are easier to update and restore, but you must plan where user data and profiles live.

Before choosing, answer a few questions:

• how many users change devices or work in shifts;
• whether installed programs and desktop settings must be preserved;
• are there roles that must not be mixed by data and access;
• which applications do not work well in a multi-user session;
• how you connect branches and remote staff.

Scenario 3: publishing a single application instead of a full desktop

Sometimes it’s better to publish a single application rather than a whole desktop. This limits unnecessary actions and reduces leakage risk via clipboard or local drives. The approach often suits 1C, CRM, medical or accounting systems.

If you have branches and unstable channels, clarify what happens on disconnects: how sessions are restored, where temporary files remain, and whether many connection points will force an architecture review. In practice this can lead to separate servers for branches or a centralized cluster in a data center — for example on rack servers of the GSE S200 Series — with clear access and redundancy rules.

Questions for InfoSec: access control, logging, data

Security for RDS and VDI is often “tightened up” after launch when user habits and settings have already formed. It’s better to agree with InfoSec about rules in advance: they affect usability, the final access scheme and how you pass checks later.

Access and authentication

Decide what level of authentication is considered sufficiently secure. Requirements for admins and normal remote users are usually different.

Check:

• is MFA required for everyone, or only for external access and privileged roles;
• will there be device and network conditions: corporate laptop, trusted network, compliance with policy (updates, disk encryption);
• how rights are granted: role groups, least privilege principle, ban on shared accounts;
• how external contractors are handled: separate accounts, expiry dates, access only to specific applications;
• is a separate gateway/mediator for RDP needed so servers aren’t exposed directly.

Segmentation, logs and data protection

Network segmentation helps limit the consequences of errors and incidents. Clarify whether RDS/VDI should live in a separate segment: apart from user PCs and apart from admin workstations. A common compromise: users see only the broker or gateway, while internal servers are not directly accessible.

For logs it’s important not only what to log but how to use it. Define a minimum: login and logout events, session drops, brute-force attempts, privilege grants, admin actions. Agree on storage: where logs live, who can access them, how many months to keep them and how quickly they can be retrieved on request.

Discuss data exfiltration controls separately. In terminal scenarios debates usually focus on clipboard, printing, disk and USB redirection, and local folder mapping. Accounting may require printing but without copying files to a local disk.

Finally, agree on an incident response plan: who can revoke a user’s or contractor’s access at any time, how fast sessions are blocked, and how to verify that access is indeed closed. These answers help not only InfoSec but also license accounting because roles, user types and scenarios become described and verifiable.

Typical mistakes that lead to rework

The most expensive part of a project is usually not the licenses but the rework after launch. Mistakes often arise from small assumptions in counting users, devices and access rules rather than from complexity.

A common confusion is thinking that buying a server is enough. In practice server license and access (CAL) licenses solve different problems. The simple outcome: the terminal server runs, but user access is not legally covered, and during an inspection or expansion urgent purchases and model rework begin.

Another common story is counting only permanent staff. In reality you have external contractors, temporary teams, service accounts, monitoring or support accounts. If these are not considered up front, access is issued “on request” and in a couple of months no one remembers who and why had access.

People often forget shift workplaces and shared device pools. For example, in a call center or registry people work shifts on the same PCs. If the licensing model is chosen by habit, you can overpay or face license shortages when shifts increase.

Another risk is allowing connections from personal devices without clear rules. Even if convenient, without control (which devices, under what conditions, for how long) you lose manageability and complicate incident investigations.

Signs you are heading for rework:

• server licenses and access licenses are not separated;
• contractors and technical accounts are missing from calculations;
• shifts and shared workplaces are not described;
• personal devices are allowed without approved conditions;
• there is no access registry: who, to what, and until what date.

A practical minimum that saves the project: start a simple access and expiry registry, agree rules for contractors and BYOD, and separately fix how you count users and devices. If you deploy RDS/VDI in the public sector or a large organization, involve InfoSec and procurement early and, if needed, a system integrator experienced in such projects like GSE.kz.

Short checklist before procurement and audit

Before buying licenses and starting a pilot, agree on a simple rule: the process must have one owner. This can be IT, procurement or financial control, but responsibility for accounting, verifying figures and audit readiness should be assigned to a role, not left to habit.

If user groups and access types are not approved, any license estimate will be inaccurate. Therefore first fix scenarios and agree them with IT, InfoSec and department heads.

Check six things before procurement:

• an accounting owner is appointed: who maintains the user/device registry, who stores supporting evidence, who answers auditor questions;
• user groups are described: permanent, shift, shared workplaces, remote, branches, test accounts — and each group has a defined access scenario;
• the choice of per user or per device is justified with numbers: how many unique people, how many real devices, are there hot spots and how often employees change;
• contractor access is separated: how accounts are issued, duration, who approves emergency access and how quickly it is revoked;
• InfoSec requirements are fixed in writing: MFA, roles, logging, redirection restrictions (clipboard, disks, printers), bans on local data storage.

Also think about compliance checks. A good audit plan answers three questions: how often to check, who signs the result, and which sources provide data (e.g., AD lists, RDS/VDI reports, Service Desk requests).

A small example: a call center has staff in shifts using 40 shared PCs, and accounting connects from personal laptops. In the first case per device is often cheaper, in the second per user. This works only if shift patterns, actual device counts and contractor rules are confirmed by documents and logs.

Example real scenario: mixed users and branch access

Imagine an organization with a head office and six branches. The head office has 80 employees; some have laptops and sometimes work from home. Branches have shared service desks: 25 workstations in two shifts where different people use the same PC during the day. Plus there are 10 employees who almost always connect remotely.

In such a configuration two questions quickly show where per device is better and where per user is preferable:

• how many people actually use each specific device during the day;
• how many devices does one person typically use (office PC, laptop, home PC).

For shift posts in branches it’s often logical to consider per device: license the devices, not every temporary shift worker. For mobile employees per user is more convenient: one person connects from different devices without tracking each one.

Now add a contractor for two weeks to set up reporting. To avoid over-privileging, InfoSec usually requires: a separate account without access to mail and file shares by default, a time limit (start and end date), access only to the needed collection or pool, no local admin rights and mandatory action logging.

Minimal restrictions that help keep things working: decide in advance whether clipboard sharing, printing, disk mapping and USB access are needed. If not required, disable them.

What you end up with after this analysis are simple artifacts: a table of users and devices, an access matrix (who can connect where and with which rights), and a short description of scenarios for office, branches, remote and contractors.

Next steps: how to formalize the solution and who can help implement

Record the decision in one short one-page document. Its purpose is simple: IT, InfoSec, procurement and system owners should have the same understanding of who and how connects, which restrictions apply and what to buy.

A handy structure for that page:

• access scenarios (office, branches, remote, contractors) and required applications;
• user groups and device types (personal PCs, shared shift devices, thin clients);
• chosen licensing model (per user or per device) and justification;
• InfoSec requirements: MFA, roles, logging, data storage, log retention periods;
• constraints: maintenance windows, downtime, availability requirements.

Next, verify whether the current infrastructure supports the chosen scenario. Sometimes licenses are chosen correctly but CPU, RAM, disk subsystem, network or specialized storage are insufficient.

Minimum technical check before deployment:

• is there capacity headroom for peak hours and growth in sessions;
• are servers and workstations suitable for graphics, peripherals and needed applications;
• how external access will be organized (VPN or gateway) and who manages it;
• where user data will be stored and how backups are done.

Then appoint process owners: who monitors, who applies updates, who handles incidents, who helps users with access. If scaling is expected, allow headroom not only in hardware but also in regulations (access requests, periodic rights review, audit).

If the team lacks experience or time, involve a system integrator. GSE.kz, as a manufacturer of servers and workstations in Kazakhstan and a system integrator, helps design RDS/VDI, select servers and workstations, implement and support 24/7 with InfoSec and procurement constraints in mind.