Nobody writes conference talks about Remote Desktop Services. The VDI content mill runs on Citrix and VMware — HDX versus Blast, PVS versus MCS, NVIDIA GRID benchmarks — and if you formed your worldview from blogs alone you would conclude that every virtual desktop on earth rides a six-figure broker stack. Meanwhile, a very large share of the actual seats we operate sit on plain RDS 2012 R2 session hosts with App-V doing the application plumbing, and those environments are boring in the way infrastructure should be boring.
This post is the field-notes version of one such environment: a professional-services client, roughly 1,800 concurrent users, task-worker to knowledge-worker workloads, running on an RDS 2012 R2 deployment we designed in 2015 and have been quietly scaling since. It is part of a broader desktop-delivery portfolio that spans Citrix XenDesktop, VMware, and RDS at 10,000-plus concurrent users, so we get to compare the stacks against each other with production data rather than vendor decks. The short version: for a large class of workloads, RDS 2012 R2 deployment plus App-V is the correct answer, and the premium alternatives are solving problems this client does not have.
To be clear about scope — "VDI" here means session-based desktops on RD Session Host, not one-VM-per-user desktops. That distinction is exactly where the economics live, so let's start there.
The economics: session hosts versus full VDI
The arithmetic that sells RDS is density. On this estate, a session host with 8 vCPU and 64 GB of RAM comfortably carries 45 task-worker sessions at peak; the heavier knowledge-worker collection runs about 30 per host of the same size. A pooled one-VM-per-user design for the same population, at 2 vCPU and 4 GB per desktop, needs roughly four to five times the compute and dramatically more storage IOPS, before you have bought a single broker license.
Then the licensing. RDS needs RDS CALs and Windows Server licenses for the hosts — costs the client largely already carried. A Citrix stack layers XenDesktop or XenApp licensing plus NetScaler on top of the same Microsoft foundation (XenApp still needs RDS CALs underneath, a fact that surprises procurement every single time). For this client the delta penciled out to roughly a third of the per-seat cost over three years, consistent with the infrastructure-cost reductions in the 30–35 percent range we see when estates resist the reflex to buy the premium tier by default.
What you give up is real and listed honestly further down. But the starting position should be: session hosts until proven otherwise, full VDI for the users who demonstrably need a personal machine, premium brokers when a specific capability justifies them.
App-V is the discipline that makes shared hosts survivable
The classic failure mode of session-host estates is application sprawl: forty applications installed natively on every host, DLL conflicts, "temporary" one-off installs that live forever, and eventually a golden image nobody dares rebuild. App-V 5.1 is how we avoid that fate. Applications are sequenced into packages, published to users or to the collections that need them, and the session hosts themselves stay nearly naked — OS, Office, agents, and very little else.
The discipline that makes it work:
- A real packaging pipeline. Every application enters the estate through the sequencer, on a clean sequencing VM, with a documented recipe. No exceptions signed off below the service owner. This client runs about 140 packages; roughly 15 applications refused to sequence (drivers, shell extensions, one licensing dongle abomination) and those are the only things installed natively.
- Connection groups, used sparingly. Where suites must see each other — a line-of-business app and its Office add-in — connection groups handle it. Every connection group is a testing surface, so we keep the count in single digits.
- Shared Content Store mode. Packages stream from the content share rather than being cached to each host's disk. Host storage stays small, package updates propagate without touching hosts, and a rebuilt host is back in the pool in under an hour because there is almost nothing on it.
The payoff shows up at patch time. Hosts are interchangeable cattle: we drain, patch, and rebuild them on a monthly cadence with Set-RDSessionHost -NewConnectionAllowed No doing the draining, and application regression testing is scoped to whatever packages changed — not to the entire installed surface of a fat image.
The HA design: broker, gateway, and the parts people skip
RDS gets a reputation for fragility from deployments that skipped the high-availability homework. The 2012 R2 platform supports proper HA at every tier; it just doesn't force you into it the way an enterprise Citrix design guide does.
Our standard build for this estate:
- RD Connection Broker in active/active HA, backed by a SQL Server availability group rather than a lonely SQL Express. Broker HA is the single most-skipped item we find in inherited RDS estates, and it is the difference between "a broker VM died, nobody noticed" and "nobody can log on."
- Two RD Gateway servers behind a load balancer, handling all external access over 443. Gateway policies (CAPs and RAPs) are managed as configuration, not clicked into existence per-server.
- RD Web Access on the gateway pair, fronted by the same VIP, with the RemoteApp feed wired into clients so users launch published apps from the Start menu instead of a web page they will bookmark wrong.
- Collections per workload class, not per department. Task workers, knowledge workers, and one small "problem children" collection for the apps that refused to sequence. Department-based collections are how you end up with eleven collections at 40 percent utilization each.
Profiles are the honest weak spot. User Profile Disks are collection-bound and fragile under certain failure modes; classic roaming profiles plus folder redirection is what actually runs here, tuned hard, with Outlook in online mode against the client's Exchange because cached mode OSTs in roaming profiles are a war crime. Third-party profile-container products (FSLogix is the one we keep an eye on) solve this more elegantly, and we factor that into any greenfield design conversation.
When Citrix earns its premium — and when it doesn't
We run enough XenDesktop to say this without tribalism. Citrix is worth the money when:
- The network is hostile. HDX genuinely outperforms RDP over high-latency, lossy links. Our SfB-adjacent VDI estates with users on satellite and international links are Citrix for this reason alone.
- Scale makes provisioning the bottleneck. PVS streaming hundreds of hosts from one vDisk is operationally superior to anything native RDS offers once you are into the thousands of hosts.
- Peripheral and graphics requirements are exotic. Serious GPU workloads, medical imaging, complex USB redirection — the HDX stack has a decade of edge cases handled.
- You need granular, auditable policy. Citrix policies plus NetScaler give security teams the knobs regulated clients demand.
Citrix is not worth the money when the honest requirement is "1,800 office workers need Office, a browser, and a dozen LOB apps on the LAN or over decent VPN." That was this client. RDP 8.1 over a sane network is perfectly good, and every dollar not spent on broker licensing went into faster storage and another pair of session hosts — which users actually notice.
The uncomfortable question we make every client answer: which specific Citrix capability will your users consume? "It's the enterprise standard" is not a capability.
What has actually broken in three years
For balance, the incident log highlights: a broker/SQL patching mismatch that took HA down to single-broker for a weekend (process failure, not product); one App-V package with a leaky Excel add-in that degraded an entire collection until we found it (packaging review now includes a soak test); printer drivers, twice, because it is always printer drivers — Easy Print is now mandatory and native drivers are banned from hosts; and a gateway certificate expiry that the monitoring we inherited didn't watch (SCOM watches it now, with a 30-day warning).
None of these were platform ceilings. Availability for the last twelve months stands at 99.95 percent measured at the broker, which matches what we hold our premium-stack estates to. The platform is not the constraint at this scale. Discipline is.
If you're facing this
If you are staring at a VDI proposal with a per-seat price that made your CFO flinch, it is worth an afternoon to check whether session-based RDS with App-V covers eighty percent of your population for a third of the cost. We have designed and operated both ends of the spectrum at 10,000-plus concurrent users, and we are happy to tell you honestly which end your workload belongs on. Get in touch and bring your application list — that is where the answer usually hides.