*Cube-Host– full cloud services!!

How to connect and configure Remote Desktop Services (RDS)

How to connect and configure Remote Desktop Services (RDS) on Windows Server

Remote Desktop is the most convenient way to administer a Windows server. If you need multiple users, RemoteApp, or a full “terminal server” experience, you’ll use Remote Desktop Services (RDS) instead of just basic RDP administration.

For stable performance and predictable latency, start with a reliable Windows VPS on fast VPS hosting and then build your RDS setup on top.

RDP vs RDS: what’s the difference (and why it matters)

RDP is the protocol and client connection method (mstsc / Microsoft Remote Desktop). RDS is the Windows Server role set that turns your server into a shared desktop / RemoteApp platform.

In practice, there are two common scenarios:

  • Admin access (basic Remote Desktop): usually used by 1–2 administrators to manage the server.
  • User access (Remote Desktop Services): used when you want many users to work on the same server (session-based desktops or RemoteApp). This requires proper RDS roles + licensing planning.

Important: If you’re building a real multi-user terminal server, plan licensing and security from day one. The goal is to provide access to users without exposing your server to brute-force attacks.

What you will need before you start

  • A deployed Windows VPS with administrator access.
  • Server OS: Windows Server 2019/2022/2025 (recommended for modern security and RDS tooling).
  • Stable public IP (and optionally a DNS name if you plan RD Gateway / certificates).
  • Open ports at two layers: provider firewall (panel / security groups) and Windows Firewall.
  • If you plan a full RDS environment: decide between standalone (small) vs standard deployment (scalable).

Step 1 — Connect to the server with Remote Desktop (RDP)

On Windows, the fastest option is the built-in client: press Win + R → type mstsc → enter the server IP/hostname. On macOS, use Microsoft Remote Desktop from the App Store.

In the RDP client settings, it’s useful to enable:

  • Clipboard (copy/paste between PC and server)
  • Local drives (for secure file transfer when needed)
  • Display scaling (for high-DPI monitors)

Step 2 — Enable Remote Desktop and harden the baseline

If Remote Desktop is not enabled yet, turn it on and immediately enforce safer defaults.

Recommended baseline: enable Remote Desktop, require Network Level Authentication (NLA), and allow access only to the users/groups you actually need.

# Enable Remote Desktop (RDP) in the registry
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' -Name 'fDenyTSConnections' -Value 0

# Require Network Level Authentication (recommended)
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -Name 'UserAuthentication' -Value 1

# Enable built-in Windows Firewall rules for Remote Desktop
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Do not keep RDP open “to everyone”. If possible, restrict inbound RDP by your IP address (or use RD Gateway over 443) before you put the server into production.

Quick screenshot: where RDS is built in Server Manager

Server Manager example: preparing servers for an RDS deployment

Step 3 — Choose your RDS deployment type

There are two realistic approaches for most Windows VPS use-cases:

Option A: Standalone Session Host (simple, small setups)

This is the simplest path when you only need a single server to host multiple sessions. Typically you install:

  • Remote Desktop Session Host (where user sessions run)
  • Remote Desktop Licensing (license server role)

This option is popular for small teams, dev environments, or when you don’t need a full portal (RD Web) and gateway.

Option B: Standard RDS deployment (recommended when you scale)

If you need cleaner user onboarding, RemoteApp publishing, a web portal, and safer external access, use a standard deployment with these roles:

  • RD Connection Broker — coordinates logins and collections
  • RD Session Host — runs user sessions
  • RD Web Access — web portal for desktops/apps
  • RD Licensing — manages RDS CALs
  • RD Gateway (optional but highly recommended) — secure access over HTTPS (443) without exposing 3389

For a minimal “production-shaped” setup, many admins place Broker + Web Access + Licensing on one server and keep Session Host on another (or multiple Session Hosts if you scale).

RDS deployment wizard example: selecting RD Connection Broker server

Step 4 — Install the RDS roles

You can install roles via Server Manager (recommended for clarity) or via PowerShell (useful for automation).

PowerShell example for a standalone host

# Installs Session Host + Licensing roles
Install-WindowsFeature -Name RDS-RD-Server, RDS-Licensing -IncludeManagementTools

# Reboot is often required after role installation
Restart-Computer

Tip: For a standard deployment (Broker/Web/Gateway), install using the RDS deployment wizard first, then adjust with PowerShell if needed. This reduces the chance of missing role dependencies.

Step 5 — Configure RDS licensing correctly

RDS licensing is not “optional configuration” — it’s a core part of a stable environment. The practical goal is simple:

  • Activate the RD Licensing server
  • Install your RDS CALs (Per User or Per Device)
  • Tell your Session Host / deployment where the licensing server is and which mode to use

Per User is often chosen for “one person → many devices”. Per Device is often chosen for shared workstations / thin clients. Pick one mode and document it.

To open the licensing console:

# RD Licensing Manager
licmgr.exe

After activation and CAL installation, validate that the Session Host can reach the licensing server and that the deployment is not stuck in a misconfigured mode.

Step 6 — Create a Session Collection and assign users

In RDS, users connect to a collection (a managed pool of session hosts with policies). Collections are where you set session limits, user groups, and (optionally) user profile disk behavior.

RDS console example: Create Session Collection

PowerShell example: create and tune a collection

# Create a basic collection
# Replace placeholders with your server names and AD group
New-RDSessionCollection -CollectionName "RDS-Users" `
  -SessionHost @("RDSH01.domain.local") `
  -ConnectionBroker "RDCB01.domain.local" `
  -CollectionDescription "User sessions for the team"

# Example: set session limits (idle/disconnect)
Set-RDSessionCollectionConfiguration -CollectionName "RDS-Users" `
  -ConnectionBroker "RDCB01.domain.local" `
  -IdleSessionLimitMin 30 `
  -DisconnectedSessionLimitMin 60

Best practice: grant access through a group (e.g., “RDS-Users”), not by adding users one by one. This keeps onboarding/offboarding predictable.

Step 7 — Publish RemoteApp (optional, but very popular)

RemoteApp allows users to run a specific application without providing a full desktop. It reduces confusion (“where are my files?”), lowers support load, and often feels faster for end users.

Typical RemoteApp candidates:

  • Accounting / ERP / CRM clients
  • Legacy Windows apps
  • Admin tools for internal teams

Step 8 — Secure external access: prefer RD Gateway over open 3389

Exposing RDP (3389) to the public internet is one of the most common reasons Windows servers get attacked. A stronger approach is to publish access through RD Gateway over HTTPS (443) with a proper certificate.

If you’re deploying RDS for business users, RD Gateway is usually worth it: you get TLS-protected access, cleaner auditing, and you can keep 3389 closed from the outside.

# Example: assign a certificate to RDS roles (certificate must match DNS name)
# Run on the Connection Broker, replace thumbprint and FQDN
Set-RDCertificate -Role RDGateway -Thumbprint "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" -ConnectionBroker "RDCB01.domain.local" -Force
Set-RDCertificate -Role RDWebAccess -Thumbprint "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" -ConnectionBroker "RDCB01.domain.local" -Force

Ports cheat sheet (what to open and where)

Always think in two layers: provider firewall (panel) and Windows Firewall.

  • 3389/TCP — RDP (avoid exposing publicly; restrict by IP if you must use it)
  • 443/TCP — HTTPS (RD Gateway / RD Web Access)
  • 3389/UDP — optional performance path for modern RDP clients (only if you intentionally allow it)

Troubleshooting: the fastest checks

  • Connection fails immediately: check provider firewall + Windows Firewall + correct port/IP.
  • NLA errors: ensure time sync, correct credentials, and that NLA is supported by your client.
  • “Licensing mode not configured” warnings: set licensing server and mode (Per User / Per Device), then re-check.
  • Black screen / slow logon: often disk I/O or profile issues; move profiles, tune AV exclusions, or scale resources.

# Quick connectivity test from a client / jump host
Test-NetConnection <server-ip-or-hostname> -Port 3389
Test-NetConnection <server-ip-or-hostname> -Port 443

When to upgrade your Windows VPS for RDS workloads

RDS performance depends heavily on RAM and disk I/O. If logins are slow, apps freeze during peak hours, or multiple users complain about lag, it’s usually time to scale resources.

  • Upgrade RAM when users frequently hit paging / swapping (slow “everything”).
  • Upgrade CPU when single-threaded apps max out cores or login storms occur.
  • Upgrade to faster storage (NVMe) when profiles, app caches, or databases are I/O-bound.

Conclusion

A correct RDS setup is not just “turn on Remote Desktop”. It’s a controlled environment: secure access, proper licensing, collections for users, and clean publishing for desktops/apps.

If you want predictable performance for remote work and Windows applications, deploy on a reliable Windows VPS with scalable resources on VPS hosting and build your RDS stack the right way from day one.

Prev
Menu