ANAVEM
Reference
Languagefr
How to Deploy and Configure Remote Desktop Services (RDS) on Windows Server

How to Deploy and Configure Remote Desktop Services (RDS) on Windows Server

Deploy a complete RDS infrastructure on Windows Server 2025 with session-based desktops, web access, and RemoteApp publishing. Configure collections, licensing, and secure gateway access.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
March 17, 2026 15 min 8
mediumrds 8 steps 15 min

Why Deploy Remote Desktop Services on Windows Server?

Remote Desktop Services (RDS) transforms how organizations deliver applications and desktops to users, enabling secure access from virtually any device and location. With Windows Server 2025 providing the latest RDS capabilities, you can create a robust virtual desktop infrastructure that scales from small businesses to enterprise environments.

RDS offers several deployment scenarios, but the session-based desktop deployment covered in this tutorial provides the most cost-effective solution for most organizations. Users connect to shared Windows Server sessions, accessing either full desktops or individual applications through RemoteApp technology. This approach maximizes server resources while providing users with familiar Windows experiences.

What Components Make Up an RDS Infrastructure?

A complete RDS deployment consists of several interconnected roles that work together to deliver remote access capabilities. The RD Connection Broker manages user connections and load balancing across session hosts. RD Web Access provides the web-based portal where users discover and launch remote resources. RD Session Host servers actually run user sessions and applications. The RD Licensing server manages Client Access Licenses required for legal operation beyond the grace period.

Optional components like RD Gateway enable secure external access through HTTPS tunneling, while RD Virtualization Host supports virtual machine-based VDI scenarios. For this tutorial, we'll focus on the core session-based deployment that provides immediate value with minimal infrastructure requirements.

Related: How to Install and Configure DHCP Server on Windows Server

Related: How to Install Active Directory Domain Services on Windows

How Does RDS Compare to Other Remote Access Solutions?

Unlike VPN solutions that provide network access, RDS delivers actual applications and desktops to remote users. This approach offers better security since data remains on your servers, improved performance for bandwidth-limited connections, and simplified client device management. Compared to cloud-based virtual desktop solutions, on-premises RDS provides complete control over your environment, data sovereignty, and often lower long-term costs for established organizations with existing Windows Server infrastructure.

Implementation Guide

Full Procedure

01

Prepare the RDS Infrastructure Servers

Start by preparing your Windows Server environment. You'll need at least three servers for a proper RDS deployment: one for RD Connection Broker, one for RD Web Access, and one for RD Session Host. For production environments, consider separate servers for each role.

First, ensure all servers are domain-joined and have static IP addresses. Open Server Manager on your designated Connection Broker server (this will be your management server).

# Verify domain membership on each server
Get-ComputerInfo | Select-Object CsDomain, CsName

# Check network configuration
Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -notlike "127.*" -and $_.IPAddress -notlike "169.*"}

Add all RDS servers to Server Manager for centralized management. Navigate to Manage > Add Servers > Find Now. Select all servers that will participate in your RDS deployment and click OK.

Pro tip: Use descriptive server names like Contoso-CB1 (Connection Broker), Contoso-WA1 (Web Access), and Contoso-SH1 (Session Host) to easily identify roles during deployment.

Verification: In Server Manager, confirm all servers appear in the All Servers view with green status indicators.

02

Deploy the Standard RDS Infrastructure

Now deploy the core RDS infrastructure using Server Manager's deployment wizard. This creates the foundation for your Remote Desktop Services environment.

In Server Manager, click Manage > Add Roles and Features. Select Remote Desktop Services installation and choose Standard Deployment. Select Session-based desktop deployment for traditional desktop sessions.

Assign servers to each role:

  • RD Connection Broker: Your management server (e.g., Contoso-CB1)
  • RD Web Access: Web gateway server (e.g., Contoso-WA1)
  • RD Session Host: Server hosting user sessions (e.g., Contoso-SH1)
# Alternative PowerShell deployment method
New-RDSessionDeployment -ConnectionBroker "Contoso-CB1.domain.local" -WebAccessServer "Contoso-WA1.domain.local" -SessionHost "Contoso-SH1.domain.local"

Click Deploy and allow the wizard to complete. This process installs the necessary roles and configures basic connectivity between servers. The deployment may require server restarts.

Warning: The deployment process can take 15-30 minutes. Don't interrupt it or close Server Manager during installation.

Verification: After deployment, navigate to Remote Desktop Services in Server Manager. You should see an overview showing your deployed roles with green status indicators.

03

Configure RD Licensing Server

RDS requires proper licensing to function beyond the 120-day grace period. Add and configure an RD Licensing server to manage your Client Access Licenses (CALs).

In Server Manager, go to Remote Desktop Services > Overview > click the + next to RD Licensing. Select your Connection Broker server or a dedicated licensing server, then click Add.

Activate the licensing server by navigating to Remote Desktop Services > Servers, right-clicking your license server, and selecting RD Licensing Manager. In the licensing manager, go to Action > Activate Server.

# Add licensing server via PowerShell
Add-RDServer -Server "Contoso-CB1.domain.local" -Role RDS-LICENSING -ConnectionBroker "Contoso-CB1.domain.local"

# Configure license mode
Set-RDLicenseConfiguration -LicenseServer "Contoso-CB1.domain.local" -Mode PerUser -ConnectionBroker "Contoso-CB1.domain.local"

Complete the activation wizard by providing your company information and connection method (typically Automatic connection for internet-connected servers). After activation, install your RDS CALs through the licensing manager.

Configure the license mode in Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > RD Licensing. Choose between Per User or Per Device based on your CAL type.

Verification: Run Get-RDLicenseConfiguration -ConnectionBroker "Contoso-CB1.domain.local" to confirm licensing is properly configured.

04

Create and Configure Session Collections

Session collections define groups of resources and settings for user sessions. Create your first collection to enable user access to remote desktops.

In Server Manager, navigate to Remote Desktop Services > Collections > Tasks > Create Session Collection. Provide a descriptive name like "Production Desktop" or "Finance Collection".

Select your RD Session Host servers that will host user sessions. Add user groups that should have access to this collection (typically Domain Users or specific security groups).

# Create collection via PowerShell
New-RDSessionCollection -CollectionName "Production Desktop" -SessionHost @("Contoso-SH1.domain.local") -ConnectionBroker "Contoso-CB1.domain.local"

# Configure collection properties
Set-RDSessionCollectionConfiguration -CollectionName "Production Desktop" -MaxRedirectedMonitors 2 -ConnectionBroker "Contoso-CB1.domain.local"

Configure User Profile Disks (UPDs) for persistent user data. Specify a UNC path like \\Contoso-CB1\UserDisks and set an appropriate maximum size (typically 20-50 GB per user). Create this shared folder with proper permissions:

# Create and configure UPD share
New-Item -Path "C:\UserDisks" -ItemType Directory
New-SmbShare -Name "UserDisks" -Path "C:\UserDisks" -FullAccess "Domain Admins" -ChangeAccess "Domain Users"
Pro tip: Use Storage Spaces Direct or a file server cluster for UPD storage in production environments to ensure high availability.

Verification: Check that users can see the collection by accessing the RD Web Access portal at https://Contoso-WA1.domain.local/RDWeb.

05

Configure SSL Certificates for Secure Access

Proper SSL certificates are essential for secure RDS access, especially when enabling external connectivity. Configure certificates for all RDS roles that require encrypted communications.

Navigate to Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > Certificates. You'll need certificates for RD Connection Broker, RD Web Access, and RD Gateway (if deployed).

For internal deployments, you can create self-signed certificates, but production environments should use certificates from a trusted Certificate Authority:

# Create self-signed certificate for testing
$cert = New-SelfSignedCertificate -DnsName "contoso-wa1.domain.local" -CertStoreLocation "Cert:\LocalMachine\My"

# Export certificate with private key
$pwd = ConvertTo-SecureString -String "P@ssw0rd123" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Temp\RDSCert.pfx" -Password $pwd

Apply certificates to each role:

  • RD Connection Broker: Use internal FQDN for SSO and Publishing certificates
  • RD Web Access: Use external FQDN if accessible from internet
  • RD Gateway: Must use external FQDN matching public DNS

For each certificate, click Create new certificate, specify the appropriate FQDN, and save the certificate to a secure location. Import the certificate on the target server and apply it through the deployment properties.

Warning: Certificate subject names must exactly match the FQDNs users will use to connect. Mismatched names cause connection failures and security warnings.

Verification: Test certificate installation by running Get-ChildItem -Path Cert:\LocalMachine\My on each server to confirm certificates are properly installed.

06

Deploy and Configure RD Gateway (Optional)

RD Gateway enables secure external access to your RDS environment through HTTPS. Deploy this role if users need to connect from outside your corporate network.

In Server Manager, go to Remote Desktop Services > Overview > click the + next to RD Gateway. Select your Web Access server or a dedicated gateway server.

Provide the external FQDN that users will use to connect (e.g., rds.contoso.com) and select or create an SSL certificate for this FQDN. The certificate must be trusted by client computers.

# Add RD Gateway via PowerShell
Add-RDServer -Server "Contoso-WA1.domain.local" -Role RDS-GATEWAY -ConnectionBroker "Contoso-CB1.domain.local" -GatewayExternalFqdn "rds.contoso.com"

Configure gateway policies by opening RD Gateway Manager from Server Manager. Create Connection Authorization Policies (CAP) and Resource Authorization Policies (RAP):

Connection Authorization Policy:

  • Allow connections from specified user groups
  • Configure authentication methods (password, smart card, etc.)
  • Set session timeout values

Resource Authorization Policy:

  • Define which internal resources users can access
  • Specify computer groups or individual servers
  • Configure port restrictions if needed
# Configure gateway bypass for local network
Set-RDDeploymentGatewayConfiguration -GatewayMode Custom -LogonMethod Password -UseCachedCredentials $True -BypassLocal $True -ConnectionBroker "Contoso-CB1.domain.local"
Pro tip: Configure the gateway to bypass local connections to improve performance for internal users while still providing secure external access.

Verification: Test external connectivity by connecting from outside your network using the RD Gateway FQDN.

07

Enable and Configure RemoteApp Publishing

RemoteApp allows users to run individual applications remotely instead of full desktop sessions. This provides a more seamless experience for specific application access.

Navigate to your session collection in Remote Desktop Services > Collections > select your collection > RemoteApp Programs > Tasks > Publish RemoteApp Programs.

Select applications from the list of installed programs on your session hosts. Common choices include Microsoft Office applications, line-of-business applications, or specialized software.

# Publish RemoteApp via PowerShell
New-RDRemoteApp -CollectionName "Production Desktop" -DisplayName "Calculator" -FilePath "C:\Windows\System32\calc.exe" -ShowInWebAccess $True -ConnectionBroker "Contoso-CB1.domain.local"

# List published RemoteApps
Get-RDRemoteApp -CollectionName "Production Desktop" -ConnectionBroker "Contoso-CB1.domain.local"

Configure RemoteApp properties for each published application:

  • Display Name: User-friendly name shown in RD Web Access
  • Description: Helpful description for users
  • Icon: Custom icon for the application
  • Command Line Parameters: Default parameters if needed

For applications requiring specific user permissions or registry settings, configure these on the session host servers. Install applications in a way that makes them available to all users who will access them remotely.

# Configure RemoteApp to show in web access
Set-RDRemoteApp -CollectionName "Production Desktop" -DisplayName "Calculator" -ShowInWebAccess $True -ConnectionBroker "Contoso-CB1.domain.local"

Users can now access published RemoteApps through the RD Web Access portal or by downloading RDP files for direct application launch.

Verification: Access the RD Web Access portal and confirm published applications appear in the RemoteApp and Desktop Connections section.

08

Configure Web Access and Test User Connectivity

The final step involves configuring RD Web Access for user connectivity and performing comprehensive testing to ensure everything works correctly.

Access the RD Web Access portal by navigating to https://your-web-access-server/RDWeb. Users will see both published RemoteApps and desktop collections here.

Customize the web portal by modifying the RDWeb configuration. You can change the site name, add company branding, and configure default connection settings:



  
  
  

Test user connectivity by logging in with different user accounts that have been granted access to your collections. Verify that:

  • Users can successfully authenticate
  • Published RemoteApps launch correctly
  • Desktop sessions connect and function properly
  • User Profile Disks are created and persistent
  • External connections work through RD Gateway (if configured)
# Test RDS connectivity
Test-RDOUAccess -OU "CN=Users,DC=domain,DC=local" -ConnectionBroker "Contoso-CB1.domain.local"

# Check active sessions
Get-RDUserSession -ConnectionBroker "Contoso-CB1.domain.local"

Configure load balancing if you have multiple session hosts by adding additional servers to your collection:

# Add additional session host to collection
Add-RDSessionHost -CollectionName "Production Desktop" -SessionHost "Contoso-SH2.domain.local" -ConnectionBroker "Contoso-CB1.domain.local"
Pro tip: Create different collections for different user groups or application sets to provide better resource management and security isolation.

Verification: Have test users connect from various locations and devices to confirm full functionality. Monitor the deployment through Server Manager to ensure all services are running correctly.

Frequently Asked Questions

How many Windows Server licenses do I need for RDS deployment?+
You need Windows Server licenses for each physical server in your RDS deployment, plus RDS Client Access Licenses (CALs) for each user or device accessing the services. A typical deployment requires licenses for the Connection Broker, Web Access, Session Host, and optionally Gateway servers. RDS CALs are separate from Windows Server CALs and come in Per User or Per Device modes. The 120-day grace period allows testing before purchasing CALs.
Can I deploy RDS on virtual machines instead of physical servers?+
Yes, RDS fully supports deployment on virtual machines and is commonly implemented this way for flexibility and resource optimization. Ensure your virtualization host has sufficient CPU, memory, and storage resources to support the expected user load. Each session host VM should have adequate resources based on your user count and application requirements. Consider using VM templates for consistent session host deployment and easier scaling.
What's the difference between RDS session-based and VDI deployments?+
Session-based RDS provides shared Windows Server sessions where multiple users connect to the same server instance, sharing resources efficiently. VDI (Virtual Desktop Infrastructure) gives each user a dedicated Windows client virtual machine, providing complete isolation but requiring more resources. Session-based deployments are more cost-effective for most scenarios, while VDI is better when users need administrative rights or run incompatible applications.
How do I troubleshoot RDS connection failures and certificate errors?+
Common RDS connection issues stem from certificate mismatches, firewall restrictions, or licensing problems. Verify that certificate subject names exactly match the FQDNs users connect to, check that TCP port 3389 and HTTPS port 443 are open, and confirm RDS licensing is properly configured. Use Event Viewer on Connection Broker and Session Host servers to identify specific error messages. The RDS deployment grace period expires after 120 days without proper licensing.
What are the hardware requirements for RDS Session Host servers?+
RDS Session Host requirements scale with user count and application demands. Start with minimum 2 vCPUs and 4 GB RAM, then plan approximately 150-200 MB RAM per concurrent user for basic office applications. CPU requirements vary significantly based on applications - plan 0.1-0.2 vCPU per user for light workloads, more for intensive applications. Storage should be fast (SSD recommended) with adequate space for user profiles, applications, and temporary files. Monitor performance and scale horizontally by adding session hosts to collections.
Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...