RDS 2025 licensing now enforces a hard compatibility rule that many teams only discover after they have already stood up new session hosts. Windows Server 2025 session hosts will not accept CALs issued from 2022, 2019, or earlier packs. The reverse works fine: 2025 CALs issued to older hosts—but the forward direction is blocked. This single change drives most of the friction I see in mid-2026 migrations.

The rest of the licensing model stays familiar, yet the practical details around choosing between per-user and per-device CALs, placing and maintaining the license server, and planning for the 120-day grace period still trip up deployments that should otherwise run smoothly. What follows expands on the basic role installation covered in our earlier RDS on Windows Server post and focuses on the licensing and operational decisions that actually determine whether a rollout stays on schedule and in compliance.

RDS CAL Basics: Per-User vs Per-Device in Current Deployments

Every user or device that connects to a Remote Desktop Session Host on Windows Server 2025 still needs a valid RDS CAL. Microsoft offers two models, and the choice affects both cost and day-to-day management more than most people expect.

Per-device CALs attach to the hardware ID of the connecting machine. They suit shift-work environments or shared kiosks where the same physical devices serve multiple people across different times of day. The license server tracks issuance, supports temporary CALs that last 90 days before converting to permanent, and allows revocation of up to 20 percent of the pool when devices are retired. Over-allocation is not possible; if no CAL is available, the connection is blocked after the temporary period ends.

Per-user CALs attach to an Active Directory user account. They work best when people connect from multiple personal devices—laptops, home desktops, tablets—and you want to avoid buying a separate CAL for each endpoint. The model allows over-allocation in the tracking database, which means you must actively monitor usage through the Remote Desktop Licensing Manager reports. There is no easy revocation path, and per-user CALs do not function reliably in pure workgroup environments. If the server is not domain-joined, stick with per-device.

In practice, most organizations I work with end up hybrid: per-device for factory or call-center floors and per-user for knowledge workers who move between office and home. The key is to decide before you purchase, because converting large numbers later creates administrative overhead and potential compliance gaps during audits. For the core Windows Server CAL requirements that always sit alongside RDS CALs, see our Windows Server 2025 CALs guide.

The 2025 Version Lock-In That Changes Upgrade Math

Microsoft documentation updated for Windows Server 2025 makes the compatibility rules explicit. A 2025 session host will only accept 2025 RDS CALs. A 2022 or 2019 host happily accepts 2025 CALs, but the reverse is not true. The license server itself follows the same pattern: a 2025 license server can host and issue every older CAL generation, yet an older license server cannot issue or manage 2025 CALs.

This matters during phased rollouts. If you move even one session host to 2025 while the rest remain on 2022, you need at least some 2025 CALs to cover the users or devices that land on the new host. Many teams budget only for the operating system upgrade and then face an unexpected CAL purchase mid-project. The cleanest path is to treat the CAL refresh as part of the 2025 migration budget from the start.

I have supported several environments where the team planned to reuse existing CALs because the server upgrade was already in place. The first connections after the cutover immediately hit the grace-period countdown or outright denial once the 120-day window closed. Rebuilding the licensing database and reinstalling the correct 2025 packs solved it, but only after users had already experienced disruption. These improvements align with the performance and security enhancements we outlined in our RDS 2025 new features post.

Activating and Running the RDS License Server

Install the Remote Desktop Licensing role through Server Manager on a server that will remain stable—ideally a dedicated low-utilization VM rather than a busy session host. After installation, open Remote Desktop Licensing Manager, right-click the server name, and choose Activate Server. You will need accurate company information that matches your Microsoft volume licensing agreement. Internet activation is fastest; phone activation works when outbound access is restricted.

Once activated, install your CAL packs using the same wizard. Enter the license key or agreement number supplied by your reseller. The tool shows both installed packs and currently issued CALs. Set up regular reporting—weekly or monthly—to catch per-user over-allocation early.

One operational detail that still catches experienced teams is the exact company information required during activation. It has to match what Microsoft has on file for your volume licensing agreement, or the process stalls and forces a support ticket or phone follow-up.

When the Licensing Manager suddenly shows temporary licenses or refuses to issue known-good CALs after a cumulative update, the reliable fix is to run the Rebuild the RD Licensing database option inside the licensing server properties, then reinstall the CAL packs. It takes only a few minutes and restores normal operation without data loss for active sessions. Workgroup deployments have an extra constraint: per-user CALs are not supported. Use per-device exclusively, or join the server to a domain before attempting per-user licensing.

How Windows Server 2025 Platform Changes Improve RDS Workloads

Core RDS role services have not been rewritten, yet the underlying platform delivers tangible gains for remote desktop and published application scenarios. Session responsiveness improves from storage and networking optimizations, including better NVMe handling and SMB compression. Denser user counts per host become realistic because of Hyper-V dynamic memory compression and improved processor scheduling when you run desktop VMs alongside session hosts.

Security posture strengthens by default. Credential Guard is enabled where hardware supports it, SMB signing and encryption are stricter, and RD Gateway benefits from tighter Entra ID integration for conditional access and MFA enforcement. These changes reduce the attack surface on any deployment that exposes remote access over the internet.

GPU partitioning in Hyper-V also opens cleaner paths for graphics-intensive published applications without dedicating entire GPUs to single VMs. Teams running CAD, medical imaging, or design tools notice the difference in frame rates and color fidelity compared with older hosts.

None of these require new RDS CALs, but they do reward organizations that already plan to refresh hardware or hosts during the 2025 cycle.

Practical Deployment Steps That Keep Licensing Straight

1. Inventory current CAL usage and types before any server changes. Export reports from the existing licensing server.
2. Decide per-user versus per-device mix based on actual connection patterns, not assumptions.
3. Purchase 2025 RDS CALs in the quantities and model you need. Authorized resellers can supply both small packs and larger volume agreements.
4. Stand up the 2025 license server first, activate it, and install the new CALs while the grace period on existing hosts is still healthy.
5. Migrate or build session hosts in a controlled order. Test a small collection with real users to confirm CAL issuance before moving production workloads.
6. Configure Group Policy or DNS for license server discovery so session hosts find the correct server automatically.
7. Document the rebuild-database procedure and schedule periodic compliance reports.

For anything beyond a handful of users, separate the Connection Broker role for load balancing and reconnection, place RD Gateway in a DMZ or use it with Azure Application Proxy, and keep Web Access on its own server or behind a reverse proxy. These separations make patching and scaling easier and reduce the blast radius if one role encounters issues.

Common Licensing Issues Teams Hit in 2026

• Licenses stop issuing after a cumulative update. Rebuild the licensing database and reinstall the CALs.
• Per-user CALs fail to issue on a workgroup server. Join the server to the domain or switch to per-device.
• Users receive temporary CALs even though permanent packs are installed. Check that the license server version matches or exceeds the session host version.
• Grace period warnings appear sooner than expected. Activate the license server and install CALs within the first 90 days of any new deployment.
• Reports show more issued CALs than purchased. Audit for over-allocation on per-user pools and adjust purchasing or user access policies.

Frequently Asked Questions

Do I need new RDS CALs when I upgrade to Windows Server 2025 session hosts? Yes. Only 2025 RDS CALs work with 2025 session hosts. Older CALs are not accepted.

Can I mix per-user and per-device CALs on the same license server? Yes. The server tracks both types independently. Just make sure your purchasing matches actual usage patterns.

How long is the grace period on a fresh Windows Server 2025 deployment? 120 days from the first remote connection. Plan to have the license server activated and CALs installed well before that window closes.

Can a single license server support both 2025 and older session hosts? Yes. A 2025 license server can issue to any supported older host. The reverse is not true.

Where should I place the license server for a multi-site deployment? In most cases, a pair of domain-joined license servers with discovery configured through Group Policy provides the best redundancy. Cross-forest or workgroup scenarios need additional planning around issuance rules.

The operational reality in mid-2026 is that RDS remains one of the most straightforward ways to deliver centralized Windows desktops and applications, provided the licensing layer is treated as a first-class part of the upgrade project rather than an afterthought. Get the CAL versions and the license server right early, and the rest of the deployment tends to stay on track.