Remote Desktop Services Configuration on Windows Server 2025

In short

Remote Desktop Services configuration on Windows Server 2025 starts with a domain-backed session deployment: add RD Connection Broker, RD Web Access, and RD Session Host, then configure licensing, create a session collection, restrict it to the correct Active Directory group, and decide how user profiles will persist. On Raff, treat the 120-day RDS grace period as deployment time, not a production licensing plan.

This tutorial is for administrators building a classic Windows Server RDS environment for multiple users. It assumes Windows Server is already deployed and patched. If you are still deciding whether you need RDS at all, read Multi-User RDP: 2 Admin Sessions vs RDS Session Host first.

Raff has deployed 15,000+ VMs for 3,000+ customers; this tutorial focuses on the configuration decisions that matter after Windows Server is running.

This tutorial owns the RDS configuration workflow

This page covers one specific path:

Windows Server 2025
→ Active Directory domain membership
→ Standard session-based RDS deployment
→ RD Connection Broker
→ RD Web Access
→ RD Session Host
→ RD Licensing
→ Session collection
→ User group assignment
→ User profile strategy
→ End-to-end verification

It does not duplicate the deeper decisions already covered elsewhere:

• RDS CAL Licensing on Windows Server owns Per User vs Per Device, BYOL, and Raff SPLA licensing decisions.
• Remote Desktop Gateway vs Direct RDP owns the external-access architecture.
• RDP Performance Tuning owns session performance.
• Windows Server Licensing on Raff owns Windows Server Evaluation, SPLA, and BYOL.
• Windows VPS for Remote Desktop owns the broader buyer/use-case decision.

Microsoft's Standard Deployment wizard can place the main RDS roles on separate servers or combine roles for a smaller environment. This tutorial uses a domain-joined Standard Deployment because it gives you Connection Broker, collections, centralized licensing configuration, and a clean path to add Session Hosts later.

Remote Desktop Services configuration starts with the right architecture

A small RDS environment still has separate responsibilities even when several roles share one VM.

For a lab or a very small deployment, you can combine Connection Broker, Web Access, Licensing, and Session Host roles. For production, decide whether role separation is justified by user count, maintenance windows, recovery requirements, and the need to scale Session Hosts independently.

Microsoft recommends keeping all RD Session Hosts inside one collection at the same Windows Server version. A Windows Server 2025 collection should therefore not mix 2025 and 2022 Session Hosts.

The prerequisites should be complete before you install RDS

Do not begin the RDS wizard until identity, DNS, patching, and recovery are in a known state.

Use this checklist:

• Windows Server 2025 is installed, patched, and has a stable hostname.
• The server is joined to the Active Directory domain used for RDS users.
• Forward and reverse DNS resolution works between the RDS servers and domain controllers.
• You have a domain account with the administrative rights needed to add and configure RDS roles.
• The intended RDS user group already exists, or you have a naming plan for it.
• You have decided whether users receive a full desktop, RemoteApp programs, or both.
• You have decided which licensing entitlement applies: customer-owned RDS CALs or Raff-provided SPLA RDS SALs.
• You have a backup or snapshot before major role changes.
• You know whether users will connect only over a private path or need RD Gateway for internet access.
• If you will use User Profile Disks, you have a central SMB share plan and backup plan for that share.

For a new Raff VM, complete the Windows Server initial setup before adding RDS roles.

Compatible with Raff: A prior Raff lab on May 24, 2026 used Windows Server 2025 Datacenter Evaluation, build 26100, and verified the main RDS role components could be installed and detected after restart. The complete workflow in this draft still requires a fresh end-to-end test before publication.

The prior lab gives us a real baseline for role availability. It does not justify claiming that the complete deployment, licensing, collection, profile, and user-access workflow below has been freshly tested.

Step 1 — Add the RDS servers to Server Manager

Open Server Manager on the server that will manage the deployment.

Go to:

Manage
→ Add Servers
→ Find Now

Add every Windows Server that will hold an RDS role.

For a small deployment, your inventory might look like this:

For a single-server lab, one domain-joined Windows Server can hold several roles. Keep the role names distinct in your documentation even when they live on the same VM.

Before continuing, confirm that Server Manager shows the target servers as Online and that there are no unresolved manageability errors.

Verification: Server Manager can discover and manage every server that will participate in the RDS deployment.

Step 2 — Create a Standard session-based RDS deployment

In Server Manager, go to:

Manage
→ Add Roles and Features
→ Remote Desktop Services installation
→ Standard Deployment
→ Session-based desktop deployment

Do not choose Quick Start for this article. Quick Start is useful for a lab, but Standard Deployment makes the role assignment explicit and maps better to a production design.

Assign the roles:

1. Select the server that will run RD Connection Broker.
2. Select the server that will run RD Web Access.
3. Select the server that will run RD Session Host.
4. Allow automatic restart if your maintenance window permits it.
5. Review the role mapping.
6. Start the deployment.
7. Wait for Server Manager to report a successful deployment.

After the required restart, sign back in with the same administrative account.

Run this PowerShell check from the Connection Broker:

Import-Module RemoteDesktop
Get-RDServer

Microsoft documents Get-RDServer as the cmdlet for listing RDS servers and their roles in a Remote Desktop deployment.

Expected result: The output lists the servers participating in the deployment and the RDS roles assigned to them.

Step 3 — Add RD Licensing without treating the grace period as production licensing

Open:

Server Manager
→ Remote Desktop Services
→ Overview
→ + RD Licensing

Select the server that will hold the RD Licensing role and complete the wizard.

Then open Remote Desktop Licensing Manager from the RDS server list or Server Manager tools.

The commercial entitlement path matters here:

Do not invent or reuse a license-pack key from another environment. The technical configuration must match the entitlement actually assigned to this deployment.

Microsoft documents a 120-day licensing grace period for a newly created RD Session Host. That window exists so you can deploy and configure RDS; it is not a reason to postpone the production licensing decision.

On the Connection Broker, open:

Remote Desktop Services
→ Overview
→ Tasks
→ Edit Deployment Properties
→ RD Licensing

Choose the licensing mode that matches the deployment.

For customer-owned RDS CALs:

• domain-joined RDS deployments can use Per User or Per Device;
• workgroup RDS deployments must use Per Device.

Specify the RD Licensing server and save the deployment properties.

Then verify the effective configuration:

Import-Module RemoteDesktop
Get-RDLicenseConfiguration

If you are running the command from another server, specify the broker explicitly:

Get-RDLicenseConfiguration -ConnectionBroker 'RDS-CB01.corp.example'

Verification: PowerShell returns the intended licensing mode and the RD Licensing server for the deployment.

Step 4 — Create an Active Directory group for RDS access

Do not leave a production collection open to every domain user just because the wizard makes broad access convenient.

Create a dedicated Active Directory security group for the people who should receive the desktop or application.

Example:

RDS-Office-Users

Add only approved users to that group.

A simple access model is:

User account
→ RDS-Office-Users
→ Session collection
→ RD Session Host

This keeps RDS authorization separate from local administrator rights and makes onboarding/offboarding easier to audit.

Microsoft's collection-management guidance uses Active Directory groups as the authorization source for RDS collections. It also warns that the collection's user-group list cannot be empty: add the narrow group first, then remove a broad group such as Domain Users.

Verification: The intended test user is a member of the dedicated RDS security group and is not being granted desktop access through an unrelated administrator group.

Step 5 — Create the RDS session collection

A session collection is the unit that ties together Session Hosts, authorized users, connection behavior, and profile settings.

In Server Manager, open:

Remote Desktop Services
→ Collections
→ Tasks
→ Create Session Collection

Create a collection with a clear workload name, for example:

OfficeUsers

Then:

1. select the RD Session Host server or servers that belong to the collection;
2. add the dedicated Active Directory security group;
3. decide whether User Profile Disks will be enabled now or after the base collection is verified;
4. review the settings;
5. create the collection.

You can validate the collection from PowerShell:

Import-Module RemoteDesktop

Get-RDSessionCollection `
  -CollectionName 'OfficeUsers' `
  -ConnectionBroker 'RDS-CB01.corp.example'

Then confirm which Session Hosts belong to it:

Get-RDSessionHost `
  -CollectionName 'OfficeUsers' `
  -ConnectionBroker 'RDS-CB01.corp.example'

Verification: The collection exists, the correct RD Session Host appears inside it, and no unintended Session Host was added.

Step 6 — Restrict the collection to the intended users

Open the collection:

Remote Desktop Services
→ Collections
→ OfficeUsers
→ Tasks
→ Edit Properties
→ User groups

Add:

CORP\RDS-Office-Users

Once the specific group is present, remove broader access that the deployment does not need.

You can inspect the collection authorization settings with PowerShell:

Get-RDSessionCollectionConfiguration `
  -CollectionName 'OfficeUsers' `
  -UserGroup `
  -ConnectionBroker 'RDS-CB01.corp.example'

Verification: Only the intended RDS security group, plus any deliberately documented administrative exception, can access the collection.

For Raff RDS deployments, put users into scoped Active Directory groups before assigning collections; broad user access is harder to audit later.

Step 7 — Choose the user profile strategy before onboarding users

The profile decision becomes important as soon as you add a second RD Session Host or users need their settings to follow them.

Use this starting matrix:

Microsoft describes a User Profile Disk as a per-user, per-collection VHD/VHDX stored on a central share and mounted when the user signs in. UPDs can roam only inside the collection in which they are configured.

If you enable UPDs, prepare a dedicated central SMB share.

Example UNC path:

\\RDS-FS01.corp.example\RDSProfiles$

Do not place user profile disks on an ordinary shared folder with loose permissions. Microsoft requires the servers in the collection to have the access needed to manage the profile disks.

In Server Manager:

Remote Desktop Services
→ Collections
→ OfficeUsers
→ Tasks
→ Edit Properties
→ User Profile Disks

Enable User Profile Disks and specify:

• the central UNC path;
• the maximum profile-disk size;
• any include/exclude policy required for the workload.

Then inspect the configuration:

Get-RDSessionCollectionConfiguration `
  -CollectionName 'OfficeUsers' `
  -UserProfileDisk `
  -ConnectionBroker 'RDS-CB01.corp.example'

Verification: The collection reports the intended profile-disk path and size. After the first test-user sign-in, confirm a user profile disk is created on the profile share.

Step 8 — Configure the collection settings deliberately

A working collection can still be a poor production environment if session behavior is left unreviewed.

Open:

Remote Desktop Services
→ Collections
→ OfficeUsers
→ Tasks
→ Edit Properties

Review at least these areas:

Do not disable security controls simply to make an old client connect. Fix the client, certificate, identity, or access architecture instead.

For environments with several Session Hosts, keep them at the same Windows Server version inside a collection and use Connection Broker to manage user reconnection and distribution.

Verification: Export or record the final collection settings so another administrator can explain why each non-default value exists.

Step 9 — Verify the RDS deployment before adding business applications

Run the validation from the Connection Broker.

Import-Module RemoteDesktop

$Broker = 'RDS-CB01.corp.example'
$Collection = 'OfficeUsers'

Get-RDServer -ConnectionBroker $Broker

Get-RDSessionCollection `
  -CollectionName $Collection `
  -ConnectionBroker $Broker

Get-RDSessionHost `
  -CollectionName $Collection `
  -ConnectionBroker $Broker

Get-RDLicenseConfiguration `
  -ConnectionBroker $Broker

Get-RDSessionCollectionConfiguration `
  -CollectionName $Collection `
  -UserGroup `
  -ConnectionBroker $Broker

Get-RDSessionCollectionConfiguration `
  -CollectionName $Collection `
  -UserProfileDisk `
  -ConnectionBroker $Broker

The deployment is ready for a controlled user test when all of these checks are true:

• Connection Broker reports the expected RDS servers and roles.
• The session collection exists.
• The correct Session Host belongs to the collection.
• The licensing mode and license server match the intended entitlement.
• The intended Active Directory group is authorized.
• The profile configuration matches the design.
• A non-administrator test user can sign in.
• The user receives only the desktop or resources intended for the collection.
• Sign-out completes cleanly.
• If UPDs are enabled, the user profile disk is created and remounts on the next sign-in.

Do this verification before installing accounting software, ERP clients, Office applications, or other business workloads. That separates an RDS infrastructure problem from an application problem.

Public internet access should be a separate security decision

A successful Session Host deployment does not mean you should expose RDP broadly to the internet.

If end users connect from external networks, review Remote Desktop Gateway vs Direct RDP before rollout.

The clean sequence is:

Build RDS
→ verify users and collections
→ configure licensing
→ verify profiles
→ design external access
→ harden and monitor
→ onboard production users

Keeping RD Gateway out of this tutorial prevents two different jobs from becoming one oversized procedure.

Scaling should add Session Hosts without changing collection ownership

Once the first collection works, scaling should be deliberate.

Microsoft supports adding RD Session Hosts to an existing deployment and collection. The Connection Broker can then reconnect users to existing sessions and distribute new connections across available hosts.

Before adding another Session Host:

• keep the Session Hosts in the collection at the same Windows Server version;
• confirm the applications support multi-session use;
• make sure the profile strategy is no longer tied to one local host;
• document how application updates will stay consistent across hosts;
• confirm the license entitlement covers the authorized users or devices;
• test maintenance mode and user reconnection behavior.

Do not add a second Session Host as a performance fix until you know whether the actual constraint is CPU, RAM, storage, profile I/O, an application, or the network path. Use the RDP performance tuning guide for that diagnosis.

Common RDS configuration mistakes

Building RDS before the server has working domain and DNS configuration

Connection Broker, collections, user groups, and profile shares depend on reliable identity and name resolution. Fix the base Windows environment first.

Treating the 120-day grace period as a licensing strategy

The grace period is a technical deployment window. Production still needs the correct customer CAL or Raff SPLA RDS SAL entitlement.

Leaving Domain Users on every collection

Broad collection access is easy to create and hard to audit. Use named security groups that match the workload.

Mixing Windows Server versions inside one collection

Microsoft requires Session Hosts in a collection to stay at the same OS level. Create another collection when a staged upgrade needs a different version.

Using local profiles after adding multiple Session Hosts

A user who lands on another Session Host can get a different local profile. Choose a roaming profile strategy before scaling.

Putting profile disks on an unprotected share

The profile share is user-state infrastructure. Back it up, restrict access, monitor capacity, and include it in recovery planning.

Installing applications before the base RDS deployment works

First prove that Connection Broker, licensing, collection access, user sign-in, and profiles work. Add the application layer afterward.

Publishing direct internet RDP as the final user-access design

Direct RDP and RD Gateway are separate architecture decisions. Use a controlled external-access design for production users.

Raff's recommended build order keeps troubleshooting simple

For a small multi-user Windows environment, build the platform in layers:

1. deploy and patch Windows Server;
2. join the domain and verify DNS;
3. create the Standard session-based RDS deployment;
4. add and configure RD Licensing;
5. create a dedicated RDS user group;
6. create the session collection;
7. configure the user profile model;
8. validate one non-admin user end to end;
9. configure external access and hardening;
10. install the production business applications;
11. onboard users gradually;
12. measure CPU, RAM, storage, login time, and session behavior before scaling.

This order gives each failure a smaller search area.

A login problem before the application is installed is an RDS, identity, profile, or access problem. A login that works until the business app starts gives you a different diagnostic path.

Remote Desktop Services configuration is complete when users can be verified end to end

A complete Remote Desktop Services configuration is more than installing the Session Host role. Connection Broker must know the deployment, licensing must match the real entitlement, the collection must authorize the right users, and the profile model must survive the way users actually connect.

On Raff, finish the RDS platform first, then add RD Gateway, hardening, backups, monitoring, and the business workload as separate layers.

FAQ

What is Remote Desktop Services configuration on Windows Server 2025?

Remote Desktop Services configuration combines RD Session Host, Connection Broker, licensing, collections, user authorization, and profile settings so multiple users can run managed Windows sessions.

Does an RDS deployment need Active Directory?

A Standard RDS deployment with Connection Broker and collections is designed around domain-backed identity. Microsoft also documents limited Session Host configurations without Connection Broker for workgroups, but recommends Standard Deployment when possible.

Do I need RDS CALs for every Raff RDS user?

Customer-owned Windows Server RDS uses the applicable RDS CAL model. Raff-provided hosted licensing uses the applicable SPLA RDS SAL model. Administrative RDP sessions are a different use case.

How long is the RDS licensing grace period?

Microsoft documents a 120-day grace period for a newly created RD Session Host. Use that window to deploy and validate licensing, not as a permanent production licensing method.

Should I use User Profile Disks for RDS?

Use User Profile Disks when users need their Windows profile to follow them between Session Hosts in the same collection. A one-host environment can stay simpler with local profiles if that matches the recovery plan.

Can I put all RDS roles on one Windows Server?

You can combine roles for a small or lab deployment, but production architecture should consider maintenance, recovery, user count, and future Session Host scaling before placing every role on one VM.

What's next

• RDS CAL Licensing on Windows Server — choose the correct RDS entitlement and licensing mode.
• Remote Desktop Gateway vs Direct RDP — design the external user-access path.
• Multi-User RDP vs RDS Session Host — confirm RDS is the right access model.
• RDP Performance Tuning — diagnose slow or unstable sessions after rollout.
• Windows Server Licensing on Raff — understand Evaluation, SPLA, and BYOL for the operating system.
• Raff Windows VM — review the Windows VM product and deployment path.

Sources

• Microsoft Learn — Deploy your Remote Desktop environment
• Microsoft Learn — Build and deploy your Remote Desktop Services deployment
• Microsoft Learn — Remote Desktop Services roles
• Microsoft Learn — Supported configurations for Remote Desktop Services
• Microsoft Learn — License Remote Desktop Services with Client Access Licenses
• Microsoft Learn — License Remote Desktop session hosts
• Microsoft Learn — Manage users in your RDS collection
• Microsoft Learn — Secure data storage with User Profile Disks
• Microsoft Learn PowerShell — RemoteDesktop module
• Microsoft Learn PowerShell — Get-RDServer
• Microsoft Learn PowerShell — Get-RDLicenseConfiguration
• Microsoft Learn PowerShell — Get-RDSessionCollectionConfiguration