RDS Session Host vs RemoteApp: Which Deployment Model Fits Your Users

Remote Desktop Services gives you two ways to deliver a Windows application: a full session host desktop, or a published RemoteApp that appears to the user as a local window. The resource and licensing model differs enough that choosing wrong costs real money every month.

Dimension	RDS Session Host (full desktop)	RemoteApp
User experience	Complete Windows desktop inside a session	Single app window, integrates with local taskbar
Typical RAM per user	1.5-3 GB	0.5-1.5 GB
Minimum practical instance	4 vCPU / 16 GB for 5-10 users	2 vCPU / 8 GB for a dozen light users
CAL requirement	RDS CAL per user or per device	Identical RDS CAL requirement
Attack surface	Large — explorer.exe, shell extensions, browsers	Small — only the published binary
Profile management	Mandatory — roaming or FSLogix	Minimal, often none
Deployment tooling	Session collection via Server Manager	RD Web Access + .rdp file or MSIX/RemoteApp package
Best for	Knowledge workers needing multiple apps	Line-of-business app delivery, contractors, BYOD

The Licensing Rule People Get Wrong

RemoteApp is not a lighter licensing tier. It is the same RDS role, the same Session Host role service, and the same RDS CAL requirement. Users still consume a session on the host — they simply see one window instead of a desktop. If anyone tells you RemoteApp avoids CALs, they are confusing RemoteApp with a web application published behind IIS.

What RemoteApp does avoid is support load. Fewer shell components mean fewer help-desk tickets about printer redirection, font rendering, and Start-menu, and a smaller memory footprint per user because explorer.exe and its shell extensions are largely out of the picture.

Deploying a RemoteApp Collection

Serve both models from one host first, then decide. Install the roles and create a collection with a published program:

Install-WindowsFeature RDS-RD-Server, RDS-Web-Access, RDS-Licensing

New-RDSessionCollection -CollectionName "LOBApps" -SessionHost vps01.contoso.com -ConnectionBroker vps01.contoso.com

New-RDRemoteApp -CollectionName "LOBApps" -DisplayName "Invoice Manager" `
  -FilePath "C:\Program Files\Contoso\Invoice\Invoice.exe" `
  -ShowInWebAccess $true -CommandLineSetting Require

Verify the published program resolves and that the collection is advertising:

Get-RDRemoteApp -CollectionName "LOBApps" | Select-Object DisplayName, FilePath, Alias
Get-RDSessionHost -CollectionName "LOBApps" | Select-Object SessionHost, NewConnectionAllowed

Session Limits You Must Plan Around

Without the RDS role, Windows Server permits two concurrent administrative sessions. That is the default in a plain Windows VPS and it is not the same as an RDS deployment. In production you need:

• A RD Licensing server with RDS CALs installed and the host pointed at it.
• A connection broker as soon as you exceed one session host, even if only for the licensing role delegation.
• An explicit session limit and idle timeout, otherwise disconnected sessions hold RAM indefinitely.

# enforce idle + disconnected limits so sessions release memory
Set-RDSessionCollectionConfiguration -CollectionName "LOBApps" `
  -EnableIdleTimeout $true -IdleTimeout 30 `
  -EnableDisconnectedSessionLimit $true -DisconnectedSessionLimit 10

# confirm the licensing mode the host expects
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core" |
  Select-Object LicensingMode

Sizing and Isolation Guidance

Session-host RAM is not linear. Ten users browsing the web in a full desktop consume far more than ten users running one published line-of-business application. Measure the two workloads separately on the same instance before you commit to a tier — and remember that this site’s own Windows Server vs Windows 11 comparison for remote desktop covers why Windows 11 is not a substitute here: the single-session restriction and the licence terms both block multi-user use.

Run RD Gateway on a separate host from the session host if user count exceeds roughly fifteen. Terminating TLS, RD Web Access, and the session load on one 4 vCPU instance gives you a single point of failure and a noisy-neighbour problem between the web endpoint and the sessions themselves.

Which Should You Choose?

Publish a RemoteApp when users need one or two specific applications and already have a working local desktop. Deploy a full session host when users need a managed, consistent desktop — contractors on untrusted machines, BYOD staff, or anyone needing several applications with a shared file and print configuration. When in doubt, publish both from the same collection and let users choose; the marginal cost of a RemoteApp alongside a desktop collection is close to zero.

Start with a Windows Server instance that gives you the full RDS role set and administrative control — InterServer Windows VPS includes licensed Windows Server with no restricted role installation, and code TRYINTERSERVER drops the first month to $0.01. For larger user counts where RAM-per-user dominates cost, Contabo offers the best price-per-GB, and Hostwinds is a solid middle option with managed support.

Profile Storage: The Hidden Blocker at Scale

Session host deployments fail on profile management long before they fail on CPU. A full desktop writes to the user profile constantly — browser caches, Outlook OST files, temporary application state. If profiles live on the session host’s system volume, that volume fills and every session starts failing at once.

Approach	Storage cost	Logon speed	Suits
Local profiles on session host	Highest (duplicated per host)	Fastest	Single host, under 10 users
Roaming profiles	Moderate	Slow — full copy at logon	Avoid for anything modern
Folder redirection only	Low	Fast	RemoteApp deployments, light use
FSLogix container profiles	Moderate	Fast — VHD mounted	Multi-host farms, 20+ users

For a RemoteApp collection, folder redirection of Documents and Desktop is usually sufficient — the published application rarely touches the profile shell. For a full desktop, FSLogix is now the standard answer because it mounts a per-user VHD rather than copying files, so logon time stays flat as profile size grows.

# enable per-session temp folders so apps don't collide in C:\Windows\Temp
Set-RDSessionCollectionConfiguration -CollectionName "LOBApps" `
  -EnableUserProfileDisk $true -MaxUserProfileDiskSizeGB 20 `
  -DiskPath "\\fileserver\Profiles"

Size the profile share generously and monitor it, because a full profile disk is a logon failure for every affected user simultaneously. Pair this with the session and idle timeouts above — an abandoned session holding its profile VHD open blocks the user’s next logon.

If you are evaluating how much RAM and storage your user count actually requires, the workload-to-spec mapping in our Windows VPS comparison table gives per-user guidance for session-host deployments.