How to Deploy and Configure Remote Desktop Services (RDS) on Windows Server 2025
Deploy a session-based Remote Desktop Services (RDS) infrastructure on Windows Server 2025 - Connection Broker, Web Access, Session Host, Licensing, and optional Gateway - then create collections, publish RemoteApps, and choose a modern profile strategy (FSLogix).
- Difficulty
- Intermediate
- Time required
- 60 - 90 minutes
- Steps
- 8
- Platform
- Remote Desktop Services (RDS)
- Version
- Windows Server 2025
Table of contents
Quick Answer
Go to the stepsAdd the RDS servers to Server Manager, run the RDS Standard / Session-based deployment (or New-RDSessionDeployment), add and activate an RD Licensing server and set the CAL mode, create a session collection, apply certificates, optionally add an RD Gateway, then publish RemoteApps.
- Domain-join all RDS servers, set static IPs, and add them to Server Manager.
- Run the Session-based desktop deployment (wizard or New-RDSessionDeployment).
- Add and activate RD Licensing, then set Per User or Per Device mode.
- Create a session collection and assign user groups.
- Apply certificates, optionally add RD Gateway, and publish RemoteApps.
Server Manager > Manage > Add Roles and Features > Remote Desktop Services installation > Standard deployment > Session-based desktop deploymentNew-RDSessionDeployment -ConnectionBroker "cb1.corp.local" -WebAccessServer "wa1.corp.local" -SessionHost "sh1.corp.local"Expected result: The Remote Desktop Services overview in Server Manager shows Connection Broker, Web Access, and Session Host deployed, and users can reach https://<web-access>/RDWeb.
Key takeaways
- How to stand up a complete session-based RDS deployment on Windows Server 2025 - deploying the core roles, configuring licensing, creating a session collection, securing access with certificates and an optional RD Gateway, publishing RemoteApps, and choosing a modern user-profile strategy.
- RDS delivers shared desktops and individual apps to users on almost any device while keeping data on your servers. A correct deployment avoids licensing lockouts after the grace period, certificate warnings, and profile problems that generate help-desk tickets.
- A correct RDS deployment hinges on three things: activate licensing before the 120-day grace period ends, match certificates to the FQDNs users connect to, and use FSLogix (not just UPD) for portable, reliable profiles.
Introduction
This guide covers a session-based desktop deployment - the most cost-effective RDS model, where multiple users share Windows Server sessions and can receive either full desktops or individual apps via RemoteApp. You can run all roles on a single server for small deployments, or split them across dedicated servers for scale and resilience. Run the deployment cmdlets from a management machine (for example a domain controller or a management server) that has the target servers added to Server Manager - not necessarily from the RDS servers themselves.
Who this is for: Windows Server administrators and MSPs building an on-premises session-based RDS (session host) environment.
Before you start
- Access
- A domain account with local administrator rights on every RDS server, and permission to install roles. Domain Admin is simplest for the initial deployment.
- Environment
- Windows Server 2025 with static IPs; a file share for user profiles if using FSLogix or User Profile Disks; a certificate (internal CA or public) for production.
- Vendor
- Microsoft
- Tested environment
- Windows Server 2025 (domain-joined), RemoteDesktop PowerShell module
- Administrator permissions required
- Backup required
Commands target Windows Server 2025 and the RemoteDesktop PowerShell module; the same flow applies to Server 2022/2019 with minor UI differences.
Allow 60 - 90 minutes; the initial role deployment alone can take 15 - 30 minutes and may reboot servers.
This is a change-making deployment (not read-only): it installs roles, reboots servers, and configures licensing and access.
Warning: Back up each server before deploying
RDS deployment installs roles and can reboot servers automatically. Take a full backup or VM snapshot of every RDS server (system state, and the profile/UPD file share once created) before you start, and schedule a maintenance window so you can roll back if a role install or reboot fails.
Critical: Don't run Session Host on a Domain Controller
Installing RD Session Host on a domain controller is not recommended and creates security and performance problems. Use member servers for RDS roles.
Warning: Licensing grace period is finite
Without an activated RD Licensing server and installed CALs, connections stop working after the 120-day grace period. Plan licensing before go-live.
Warning: Certificate names must match
Certificate subject/SAN must exactly match the FQDNs users connect to (Web Access and Gateway especially), or users get security warnings or connection failures.
1Prepare the servers and add them to Server Manager
Get every RDS server domain-joined, statically addressed, and manageable from one console.
Server Manager > Manage > Add Servers > Find Now > select servers > OKDecide your topology: a single server can host Connection Broker, Web Access, and Session Host for small deployments, or split the roles across servers for scale. Ensure every server is domain-joined with a static IP, then add them all to Server Manager on your management machine via Manage > Add Servers > Find Now. Use descriptive names (e.g., CB1, WA1, SH1) so roles are easy to identify.
# Verify domain membership and IP on each server
Get-ComputerInfo | Select-Object CsDomain, CsName
Get-NetIPAddress -AddressFamily IPv4 | Where-Object { $_.IPAddress -notlike '127.*' -and $_.IPAddress -notlike '169.254.*' }Expected result: All RDS servers appear in Server Manager's All Servers view with a healthy (green) status.
Note
Run later deployment cmdlets from a machine that has all target servers in Server Manager; it doesn't have to be one of the RDS servers.
2Deploy the session-based RDS infrastructure
Install and wire together the core roles: Connection Broker, Web Access, and Session Host.
Server Manager > Manage > Add Roles and Features > Remote Desktop Services installation > Standard deployment > Session-based desktop deploymentIn Server Manager, choose Manage > Add Roles and Features > Remote Desktop Services installation > Standard deployment > Session-based desktop deployment, then assign your servers to the three roles and deploy. For a single-server lab, point all three roles at the same server. The PowerShell equivalent is New-RDSessionDeployment. Deployment installs roles and may reboot servers automatically.
Import-Module RemoteDesktop
# Multi-server deployment
New-RDSessionDeployment -ConnectionBroker "cb1.corp.local" -WebAccessServer "wa1.corp.local" -SessionHost "sh1.corp.local" -Verbose
# Single-server (all roles on one host) is also supported:
# New-RDSessionDeployment -ConnectionBroker "rds1.corp.local" -WebAccessServer "rds1.corp.local" -SessionHost "rds1.corp.local" -VerboseExpected result: The Remote Desktop Services > Overview page in Server Manager shows all three deployed roles. Deployment can take 15 - 30 minutes.
Note
Servers joined as RD roles must run the same OS version as the active Connection Broker. Don't interrupt the wizard.
3Add and activate the RD Licensing server
Enable licensing so connections keep working past the 120-day grace period.
Remote Desktop Services > Overview > RD Licensing (+) ; then Tools > Remote Desktop Services > Remote Desktop Licensing Manager > Activate ServerIn Remote Desktop Services > Overview, click the + on RD Licensing and add a licensing server (a dedicated server, or the Connection Broker for small deployments). Then activate it via RD Licensing Manager > Action > Activate Server and install your RDS CALs. Finally set the deployment license mode (Per User or Per Device) to match your CALs.
# Add the RD Licensing role service
Add-RDServer -Server "cb1.corp.local" -Role RDS-LICENSING -ConnectionBroker "cb1.corp.local"
# Set the deployment CAL mode (PerUser or PerDevice)
Set-RDLicenseConfiguration -LicenseServer "cb1.corp.local" -Mode PerUser -ConnectionBroker "cb1.corp.local" -Force
# Verify
Get-RDLicenseConfiguration -ConnectionBroker "cb1.corp.local"Expected result: Get-RDLicenseConfiguration returns your chosen Mode and LicenseServer, and RD Licensing Manager shows the server activated with CALs installed.
Note
Per User CAL tracking requires Active Directory. Activating and installing CALs is done in RD Licensing Manager, not purely via PowerShell.
4Create a session collection
Group session hosts and grant user access to desktops/apps.
Remote Desktop Services > Collections > Tasks > Create Session CollectionIn Remote Desktop Services > Collections > Tasks > Create Session Collection, name the collection, add your Session Host server(s), and assign the user groups allowed to connect. Note a Session Host can belong to only one collection, while a Connection Broker can manage many. Tune collection settings such as redirected monitors as needed.
New-RDSessionCollection -CollectionName "Production Desktop" -SessionHost @("sh1.corp.local") -ConnectionBroker "cb1.corp.local"
Set-RDSessionCollectionConfiguration -CollectionName "Production Desktop" -MaxRedirectedMonitors 2 -ConnectionBroker "cb1.corp.local"Expected result: The collection appears under Collections, and assigned users can see it at https://<web-access>/RDWeb.
Note
For multiple session hosts, add them to the same collection to enable Connection Broker load balancing.
5Choose a user profile strategy (FSLogix recommended)
Give users a consistent profile across session hosts without the pitfalls of older options.
Collection > Tasks > Edit Properties > User Profile Disks (for UPD) - or install FSLogix agent + configure via GPO (recommended)For persistent profiles you have two main options. The RDS collection wizard offers User Profile Disks (UPD) - simple and built in, but limited to a single collection and a single session, and it discards the search index at logoff. Microsoft's modern, recommended approach is FSLogix Profile Containers, which is included at no extra cost with RDS CALs and works across collections and hosts (and even physical PCs). For new deployments, prefer FSLogix: place VHDX profiles on a highly available SMB share, install the FSLogix agent on each session host, and configure it by GPO (set VHDLocations, exclude the profile paths from antivirus). Use UPD only for the simplest single-collection cases.
# Example: prepare a highly available SMB share for FSLogix profile containers
New-Item -Path "D:\FSLogixProfiles" -ItemType Directory
New-SmbShare -Name "FSLogixProfiles" -Path "D:\FSLogixProfiles" -FullAccess "CORP\Domain Admins"
# Grant the session host computer accounts and users modify rights on share + NTFS,
# then set the FSLogix 'VHDLocations' GPO to \\fs1\FSLogixProfiles and exclude the path from AV.Expected result: After logon, a user's profile mounts from the share; the same profile follows the user across session hosts (FSLogix) rather than being trapped in one collection (UPD).
Note
FSLogix is downloaded from Microsoft and configured via GPO or registry; there is no RDS collection setting for it. Excluding the VHDX path from real-time AV is essential to avoid profile corruption.
6Apply certificates for secure access
Remove certificate warnings and enable trusted, encrypted connections.
Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > CertificatesIn Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > Certificates, assign certificates for RD Connection Broker (SSO and Publishing), RD Web Access, and RD Gateway. For production use a certificate from a trusted CA whose subject/SAN matches the FQDNs users connect to. For a lab, generate one with PowerShell - note the wizard's self-signed certificate no longer works well with modern browser restrictions.
# Lab only: create and export a self-signed cert (production: use a CA-issued cert)
$cert = New-SelfSignedCertificate -DnsName "wa1.corp.local","rds.contoso.com" -CertStoreLocation "Cert:\LocalMachine\My"
$pwd = Read-Host -AsSecureString -Prompt "PFX password"
Export-PfxCertificate -Cert $cert -FilePath "C:\Temp\RDSCert.pfx" -Password $pwd
# Apply per role via PowerShell
Set-RDCertificate -Role RDWebAccess -ImportPath "C:\Temp\RDSCert.pfx" -Password $pwd -ConnectionBroker "cb1.corp.local" -ForceExpected result: Each role shows a trusted certificate with a matching FQDN; browsers and the RDP client no longer warn on connect.
Note
Avoid hardcoding passwords in scripts; prompt for them as shown. Certificate subject/SAN mismatch is the top cause of RDS connection warnings.
7Add and configure RD Gateway (optional, for external access)
Allow secure external connections over HTTPS without a full VPN.
Remote Desktop Services > Overview > RD Gateway (+) ; then Tools > Remote Desktop Services > RD Gateway Manager > Policies (CAP/RAP)Add the RD Gateway role (Overview > + RD Gateway, or Add-RDServer -Role RDS-GATEWAY), supplying the external FQDN users will connect to and a certificate trusted by clients. Then tune the deployment gateway settings, and in RD Gateway Manager create Connection Authorization Policies (CAP) and Resource Authorization Policies (RAP) to control who can connect and to which internal resources.
# Add the RD Gateway role with its external FQDN (this parameter is valid on Add-RDServer)
Add-RDServer -Server "gw1.corp.local" -Role RDS-GATEWAY -ConnectionBroker "cb1.corp.local" -GatewayExternalFqdn "rds.contoso.com"
# Configure deployment gateway behavior (bypass gateway for internal clients)
Set-RDDeploymentGatewayConfiguration -GatewayMode Custom -GatewayExternalFqdn "rds.contoso.com" -LogonMethod Password -UseCachedCredentials $True -BypassLocal $True -ConnectionBroker "cb1.corp.local" -ForceExpected result: External users reach the deployment via the gateway FQDN over HTTPS; internal users bypass the gateway. CAP and RAP policies exist in RD Gateway Manager.
Note
The external FQDN must resolve publicly and match the gateway certificate. Publish TCP/UDP 443 to the gateway; RDP (3389) stays internal.
8Publish RemoteApps and test connectivity
Offer individual apps (not just full desktops) and validate the whole path end to end.
Remote Desktop Services > Collections > (collection) > RemoteApp Programs > Tasks > Publish RemoteApp ProgramsIn your collection, open RemoteApp Programs > Tasks > Publish RemoteApp Programs and select installed apps, or use New-RDRemoteApp. Then test: sign in to https://<web-access>/RDWeb as a test user, launch a published app and a desktop session, and confirm profiles persist and (if configured) external gateway access works. Add more session hosts to the collection to scale.
# Publish a RemoteApp (Alias is required)
New-RDRemoteApp -CollectionName "Production Desktop" -Alias "calc" -DisplayName "Calculator" -FilePath "C:\Windows\System32\calc.exe" -ShowInWebAccess $True -ConnectionBroker "cb1.corp.local"
# Verify published apps and active sessions
Get-RDRemoteApp -CollectionName "Production Desktop" -ConnectionBroker "cb1.corp.local"
Get-RDUserSession -ConnectionBroker "cb1.corp.local"
# Scale out: add another session host to the collection
Add-RDSessionHost -CollectionName "Production Desktop" -SessionHost "sh2.corp.local" -ConnectionBroker "cb1.corp.local"Expected result: Published apps appear in RD Web Access; test users can launch apps and desktops, profiles persist, and Get-RDUserSession lists active sessions.
Note
New-RDRemoteApp requires -Alias. Create separate collections for different user or application groups for cleaner security and resource isolation.
Confirm the RDS deployment is healthy
Monitor deployment
A working deployment shows all roles green in Server Manager, an activated licensing server with the correct CAL mode, at least one collection with assigned users, trusted certificates, and successful test logons through RD Web Access (and the gateway, if deployed).
Normal result: Get-RDLicenseConfiguration returns your CAL mode and license server; RD Web Access serves published apps/desktops; Get-RDUserSession lists connected users; profiles persist across logons.
Abnormal result: Certificate warnings (name mismatch), connections dropping after 120 days (licensing not activated/CALs missing), users on temporary profiles (profile share permissions or a locked UPD across collections), or gateway failures (external FQDN/cert mismatch).
Troubleshooting
Connections stop working after ~120 days
Critical
Cause: RD Licensing server not activated or no RDS CALs installed - the grace period expired.
Activate the license server in RD Licensing Manager, install CALs, and confirm the deployment mode with Get-RDLicenseConfiguration.
Certificate warnings or connection failures
Warning
Cause: Certificate subject/SAN doesn't match the FQDN users connect to, or the client doesn't trust the issuer.
Issue a certificate (from a trusted CA in production) whose SAN matches the Web Access/Gateway FQDNs and reapply it in Deployment Properties > Certificates.
Users land on a temporary profile
Warning
Cause: Profile share permissions are wrong, or a UPD is locked because the user is in multiple collections/sessions.
Fix share/NTFS rights for the session host computer accounts and users; for cross-collection or multi-session needs, use FSLogix instead of UPD.
External users can't connect through the gateway
Warning
Cause: External FQDN doesn't resolve publicly, the gateway certificate doesn't match, or 443 isn't published.
Verify public DNS for the gateway FQDN, apply a matching trusted certificate, and publish TCP/UDP 443 to the gateway.
Test-RDOUAccess or similar cmdlet 'not recognized'
Note
Cause: That cmdlet does not exist in the RemoteDesktop module (a common documentation error).
Use the real cmdlets: Get-RDUserSession, Get-RDSessionCollection, Get-RDRemoteApp, and Get-RDLicenseConfiguration to validate the deployment.
Frequently asked questions
Can I deploy RDS on a single server?
Yes. For small deployments, RD Connection Broker, RD Web Access, and RD Session Host can all run on one domain-joined server. Split the roles across servers when you need scale or high availability.
How long is the RDS licensing grace period?
120 days. During that window RDS works without CALs so you can test, but you must activate an RD Licensing server and install RDS CALs (Per User or Per Device) before it ends, or connections stop.
Should I use User Profile Disks or FSLogix?
FSLogix Profile Containers are Microsoft's modern, recommended approach and are included at no extra cost with RDS CALs. Unlike UPD, FSLogix works across collections, hosts, and even physical PCs, and doesn't discard the search index. Use UPD only for the simplest single-collection cases.
Can I run RDS on virtual machines?
Yes, RDS is commonly deployed on VMs. Size each session host for your user count (plan roughly 150 - 200 MB RAM per concurrent user for light office use, plus CPU for the apps) and scale out by adding session hosts to a collection.
What's the difference between session-based RDS and VDI?
Session-based RDS shares one Windows Server instance among many users (efficient, cost-effective). VDI gives each user a dedicated virtual desktop (more isolation and flexibility, more resources). Session-based suits most workloads; VDI fits users needing admin rights or incompatible apps.
Do I need RD Gateway?
Only for secure external access over HTTPS without a VPN. Internal-only deployments don't need it. When used, its external FQDN must resolve publicly and match its certificate, and you control access with CAP/RAP policies.
Conclusion
You deployed a session-based RDS environment on Windows Server 2025 - core roles via Server Manager or New-RDSessionDeployment, an activated RD Licensing server with the right CAL mode, a session collection, trusted certificates, an optional RD Gateway for external access, and published RemoteApps - plus a modern FSLogix-based profile strategy.
A correct RDS deployment hinges on three things: activate licensing before the 120-day grace period ends, match certificates to the FQDNs users connect to, and use FSLogix (not just UPD) for portable, reliable profiles.
Server Manager > Manage > Add Roles and Features > Remote Desktop Services installation > Standard deployment > Session-based desktop deployment (or New-RDSessionDeployment).Sources5
- Add-RDServer (RemoteDesktop) - including -Role RDS-GATEWAY and -GatewayExternalFqdn
- Set-RDDeploymentGatewayConfiguration (RemoteDesktop)
- Windows Server 2025: Deploying an RDS Farm (session-based flow, UPD share, wizard cert caveat)
- FSLogix: alternative to roaming profiles and User Profile Disks (included with RDS CALs; overcomes UPD limits)
- Configuring FSLogix Profile Containers on Windows Server RDS
