Remote Desktop Services: Session Host vs Virtualization Host

What Are RDSH and RDVH?

Remote Desktop Services (RDS) in Windows Server provides two distinct mechanisms for delivering remote workloads to end users: Remote Desktop Session Host (RDSH) and Remote Desktop Virtualization Host (RDVH). While both rely on the Remote Desktop Protocol (RDP) and share foundational infrastructure roles such as the RD Connection Broker, RD Gateway, and RD Web Access, their underlying compute models are fundamentally different.

Think of RD Session Host as an apartment building. All tenants share the same concrete foundation, plumbing, electrical grid, and structural roof—the single Windows Server operating system kernel, system drivers, and memory subsystem. Each tenant has a secure key to their own private apartment—their personal user session, desktop shell, user profile, and application space—but they reside within one collective physical structure.

Think of RD Virtualization Host as a suburban housing subdivision. Instead of sharing a common roof and plumbing, every resident owns a completely detached, standalone house on their own parcel of land. In technical terms, each user connects to an independent Hyper-V virtual machine running a dedicated client operating system such as Windows 10 or Windows 11, with its own dedicated virtual disk, memory allocation, and isolated operating system kernel.

Selecting between RDSH and RDVH is one of the most consequential decisions when designing enterprise end-user computing infrastructure. It dictates hardware purchasing, hypervisor capacity, storage performance, software licensing, and administrative operational overhead.

Architectural Differences: Shared Kernel vs Hypervisor

The architectural split between RDSH and RDVH centers on where operating system isolation occurs. RDSH isolates users at the user-session boundary, whereas RDVH isolates users at the hypervisor virtualisation boundary.

On an RD Session Host, Windows Server reserves Session 0 exclusively for non-interactive system services, background daemons, and device drivers. When users log in through RDP, the Local Session Manager (LSM) creates separate interactive user sessions (Session 1, Session 2, and so forth). Each session runs its own instance of csrss.exe (Client Server Runtime Subsystem), winlogon.exe, and explorer.exe. However, all sessions execute against a single running kernel (ntoskrnl.exe). System DLLs, core operating system binaries, and shared applications reside in memory once and are mapped into each session’s virtual memory address space.

On an RD Virtualization Host, the physical server runs Windows Server with both the Hyper-V role and the RDS-Virtualization role service installed. The RD Virtualization Host does not host user desktop sessions directly. Instead, it acts as a Hyper-V hypervisor node managed by the RD Connection Broker. When a user requests a connection, the Connection Broker queries RDVH, powers on or identifies an available guest virtual machine, and directs the client’s RDP connection straight into the guest VM.

# Architectural flow: RDSH vs RDVH connection routing

[ Client Device ] ─── HTTPS / 443 ───▶ [ RD Gateway / Web Access ]
                                                 │
                                      RDP Routing / 3389
                                                 │
                                                 ▼
                                     [ RD Connection Broker ]
                                     (Queries Active Session DB)
                                                 │
                 ┌───────────────────────────────┴───────────────────────────────┐
                 │                                                               │
                 ▼                                                               ▼
     [ RD Session Host Farm ]                                      [ RD Virtualization Host ]
  ┌─────────────────────────────┐                               ┌─────────────────────────────┐
  │ Windows Server (Shared OS)  │                               │ Windows Server + Hyper-V    │
  │ ├─ Session 0: Services      │                               │ ├─ Parent Partition         │
  │ ├─ Session 1: User A        │                               │ ├─ VM 101: Win 11 (User A)  │
  │ ├─ Session 2: User B        │                               │ ├─ VM 102: Win 11 (User B)  │
  │ └─ Session 3: User C        │                               │ └─ VM 103: Win 11 (User C)  │
  └─────────────────────────────┘                               └─────────────────────────────┘

Because RDSH shares a single OS instance, it cannot run client-only operating systems like Windows 11 Enterprise. All users receive a Windows Server desktop experience. RDVH, on the other hand, runs genuine client editions of Windows inside each virtual machine, ensuring full client feature parity, including consumer media codecs, Xbox gaming runtime dependencies, and client-specific graphics subsystem behaviour.

Session Collections vs Virtual Desktop Collections

In Remote Desktop Services, resources are grouped and presented to users through Collections. The collection type depends entirely on whether the backend compute relies on RDSH or RDVH.

RD Session Host supports Session Collections. A session collection groups one or more RDSH servers into a load-balanced farm. Administrators can configure two deployment shapes:

RD Virtualization Host supports Virtual Desktop Collections. These collections represent Virtual Desktop Infrastructure (VDI) and fall into two distinct models:

1. Pooled Virtual Desktop Collections: A shared pool of identical virtual machines generated from a single master sysprepped virtual machine template. When users connect, the Connection Broker assigns them an available VM from the pool. At logoff, the virtual machine can be automatically rolled back to its pristine snapshot state, wiping any local modifications made during the session. User customization and files are preserved using central User Profile Disks (UPD) or FSLogix Profile Containers stored on an SMB file share.

2. Personal Virtual Desktop Collections: Dedicated virtual machines assigned permanently to specific user accounts. When an employee logs in, they always connect to their designated VM. Because the VM is permanently assigned, all application installations, configuration changes, and local files persist directly on the virtual machine’s virtual hard disk without requiring mandatory rollback.

Resource Density, Hardware Sizing, and Performance

The physical resource profile of RDSH differs substantially from RDVH. For standard office knowledge workers, RDSH delivers vastly superior density per physical host.

Consider a physical hypervisor node equipped with 32 CPU cores and 128 GB of RAM serving 50 standard task workers:

Under RD Session Host, the administrator can deploy two load-balanced Windows Server RDSH virtual machines, each configured with 16 vCPUs and 56 GB of RAM. The 50 users distribute across the two servers (25 sessions each). Because Windows Server caches shared code libraries and executables in memory once, the operating system overhead is amortised across all active sessions. If Microsoft Edge or an ERP client requires 400 MB of working memory per user, 25 users consume roughly 10 GB of application RAM plus base OS overhead, leaving ample buffer for background caching.

Under RD Virtualization Host (VDI), accommodating 50 users requires provisioning 50 separate virtual machines. Even if each Windows 11 VM is assigned a conservative 4 GB of RAM, the guest virtual machines require a combined 200 GB of memory—exceeding the physical host’s capacity before accounting for hypervisor overhead. Furthermore, 50 running instances of the Windows kernel generate 50 times the background thread scheduling, telemetry polling, and Windows Update scanning.

Storage performance requirements also diverge. RDSH creates predictable, consolidated I/O streams. In contrast, pooled VDI collections on RDVH are susceptible to boot storms and logon storms: when 50 virtual machines boot simultaneously or execute morning logons, parallel registry writes and disk queries can overwhelm shared storage arrays unless backed by high-IOPS NVMe storage tiers.

Application Compatibility and Security Boundaries

While RDSH leads in resource efficiency, RDVH excels when application compatibility and strict security isolation are mandatory.

RD Session Host is a shared multi-user environment. Applications must adhere strictly to multi-user design standards:

Applications that write license tokens, user preferences, or temporary caches to HKEY_LOCAL_MACHINE (HKLM) or C:\Program Files will fail or overwrite data when run concurrently by multiple users. Furthermore, applications that require specialized virtual display drivers, device drivers, or custom background services that register per-user will malfunction on RDSH.

Critically, users on an RD Session Host cannot be granted local administrator rights. Granting local administrative access on an RDSH server gives that user full control over the underlying operating system, enabling them to inspect other users’ memory spaces, terminate fellow users’ processes, read shared temp files, and compromise the server.

RD Virtualization Host eliminates these barriers. Because each virtual machine is an isolated sandbox running a standalone client OS:

Developers, data scientists, and engineers can be granted full local administrator privileges inside their personal virtual desktop without endangering any other user or the underlying hypervisor. If a user crashes their operating system with a buggy driver or blue screens their VM, only their isolated virtual machine is affected. The remaining virtual desktops on the RDVH node continue running uninterrupted.

Deployment and PowerShell Management

In modern enterprise environments, RDS deployments are typically configured using the Remote Desktop Services deployment wizard in Server Manager or automated end-to-end via the RemoteDesktop PowerShell module.

To stand up an RDS infrastructure, the required role services must first be installed. For an RD Session Host, install RDS-RD-Server; for an RD Virtualization Host, install RDS-Virtualization alongside Hyper-V.

# Install Remote Desktop Session Host role on a target server
Install-WindowsFeature -Name RDS-RD-Server -IncludeManagementTools -Restart

# Install Remote Desktop Virtualization Host role (enables Hyper-V container)
Install-WindowsFeature -Name RDS-Virtualization -IncludeManagementTools -Restart

Once the target host servers are prepared, initialize the deployment from the designated management server or Connection Broker using the appropriate deployment cmdlet:

# Initialize a standard Session-Based RDS deployment
New-RDSessionDeployment -ConnectionBroker "rdcb01.corp.example.com" `
  -SessionHost @("rdsh01.corp.example.com", "rdsh02.corp.example.com") `
  -WebAccessServer "rdweb01.corp.example.com"

# Initialize a Virtual Desktop (VDI) deployment with a virtual switch
New-RDVirtualDesktopDeployment -ConnectionBroker "rdcb01.corp.example.com" `
  -VirtualizationHost @("rdvh01.corp.example.com", "rdvh02.corp.example.com") `
  -WebAccessServer "rdweb01.corp.example.com" `
  -CreateVirtualSwitch

With the deployment structure established, create the collections that users will access. For RDSH, define a pooled session collection:

# Create a pooled session collection across the session host farm
New-RDSessionCollection -CollectionName "General-Staff" `
  -SessionHost @("rdsh01.corp.example.com", "rdsh02.corp.example.com") `
  -CollectionDescription "Standard corporate desktop and RemoteApps" `
  -ConnectionBroker "rdcb01.corp.example.com" `
  -PooledUnmanaged

# Inspect active user sessions across the session collection
Get-RDUserSession -ConnectionBroker "rdcb01.corp.example.com" -CollectionName "General-Staff"

For RDVH, create a virtual desktop collection linking either existing pre-created virtual machines (unmanaged) or defining a template-based automated pool (managed):

# Create an unmanaged virtual desktop collection from pre-staged VMs
New-RDVirtualDesktopCollection -CollectionName "CAD-Engineers" `
  -PersonalUnmanaged `
  -VirtualDesktopName @("VM-CAD-01", "VM-CAD-02", "VM-CAD-03") `
  -ConnectionBroker "rdcb01.corp.example.com" `
  -Description "Dedicated high-spec virtual desktops for CAD workloads" `
  -AutoAssignPersonalVirtualDesktopToUser `
  -GrantAdministrativePrivilege

RDSH vs RDVH Comparison Matrix

The following reference table summarizes the architectural, operational, and licensing distinctions between Remote Desktop Session Host and Remote Desktop Virtualization Host:

Troubleshooting Common Deployment Issues

When configuring and operating RDSH and RDVH infrastructures, several recurring architectural and configuration issues can prevent successful user connections.

Final Thoughts

The decision between RD Session Host and RD Virtualization Host comes down to a classic infrastructure trade-off: efficiency versus isolation. RD Session Host remains the uncontested champion for cost-effective, high-density desktop and application publishing. For the vast majority of task and knowledge workers who rely on web browsers, enterprise ERP clients, and productivity software, RDSH delivers the highest return on hardware investment.

Conversely, RD Virtualization Host serves specialized requirements where shared kernel multi-tenancy is unworkable—such as software engineering teams requiring local administrative privileges, legacy commercial software refusing to run on server operating systems, or regulatory mandates requiring complete operating system sandboxing.

When planning host server architecture, remember that server edition choices also interact with these roles. As detailed in our guide on Server Core vs Desktop Experience, your RD Virtualization Host hypervisors can be hardened on Server Core to minimize patch cycles, whilst your RD Session Hosts must run Desktop Experience to support the interactive Windows graphical shell.