Citrix shipped XenDesktop and XenApp 7.15 this month, and it carries the three letters that matter more to us than any feature in the release notes: LTSR. Long Term Service Release. Five years of mainstream support plus five extended, cumulative updates that don't move functional ground under your feet, and a compatibility statement that stays true for longer than a hardware refresh cycle. For the estates we run — including a multi-tenant platform that has to hold 10,000-plus concurrent users at a contractual 99.95% — this is the release we've been waiting to standardize on, and this post is the build sheet.
Some context on why we're opinionated about this. We've been delivering VDI since the XenDesktop 5.6 days, we run Citrix alongside Microsoft RDS and VMware environments, and we have watched more than one client bleed weekends chasing the Current Release treadmill — 7.12 to 7.13 to 7.14, each with its own quirks, each obsolete in months. Current Release is fine for a lab or a team that genuinely needs the newest HDX feature. It is the wrong posture for an enterprise VDI estate where the objective is boring, repeatable, defensible uptime. A citrix vdi architecture at scale should change deliberately, not quarterly.
The last LTSR was 7.6, and it's showing its age — no full Windows Server 2016 VDA story, an older HDX stack, and a management plane that predates a lot of what Director can do now. 7.15 LTSR resets that baseline. Here is the reference build we're standardizing across engagements, and the reasoning behind each choice.
Why LTSR is an architecture decision, not a version preference
The distinction sounds bureaucratic until you operate at scale. On the Current Release track, Citrix expects you to be within roughly six months of the newest build to stay in support. Across a large estate — Delivery Controllers, StoreFront, hundreds or thousands of VDAs, Provisioning servers, Director — that's a perpetual upgrade project running in the background of your operations team, forever. Every upgrade window is risk. Every VDA revision is an image rebuild, a test cycle, a pilot ring, and a rollback plan.
LTSR inverts that. You take cumulative updates — fixes, not features — on a cadence you control, and the platform stays supported for years. When we model the operational cost for clients, the delta is real: on a 5,000-seat estate we priced this spring, staying honest with Current Release meant roughly six significant platform maintenance events per year; the LTSR plan needs two. That difference is an FTE's worth of change management, and every one of those avoided windows is an outage that can't happen.
The tradeoff is equally honest: you give up new features for the life of the baseline. If your business case depends on a bleeding-edge HDX capability, take Current Release for that silo and isolate it. Nobody's SLA ever depended on a feature that shipped last quarter.
The reference topology
For a 10,000-user multi-site estate, the shape we deploy looks like this:
| Layer | Build | Sizing rule of thumb |
|---|---|---|
| Delivery Controllers | 2+ per site, Server 2016 | N+1; one controller per 5,000 sessions is comfortable |
| SQL (site database) | Always On availability group | The site database is your real single point of failure — treat it like tier 0 |
| StoreFront | 2+ per site behind NetScaler | Server group with propagated config; no snowflake stores |
| NetScaler Gateway | HA pair per site, GSLB across sites | ICA Proxy only from the DMZ; no full VPN on the same vServer |
| VDA — desktops | Windows 10 1607 (LTSB where the client insists) | Density measured, not assumed |
| VDA — apps | Server 2016 RDSH | Start at 40–60 users per host and measure |
| Director + Monitoring | Director for helpdesk, SCOM management pack for platform | Our SCOM discipline carries over from the server estate |
Nothing exotic. The value is in the discipline around it: config as documentation, every controller rebuildable from notes in under an hour, and a quarterly failover test that actually fails things over. We inherited an environment last year where the "HA pair" of NetScalers had been running with a dead secondary for eight months. Nobody knew because nobody tested. That estate now fails over on the first Tuesday of every quarter, during business hours, on purpose — because an HA design you haven't tested during load is a diagram, not a design.
MCS vs PVS in the 7.15 era
The eternal Citrix argument, so here's where we've landed after running both at scale.
Machine Creation Services got materially better through the 7.x line, and 7.15 consolidates that. For most virtual desktop estates on decent shared storage — and especially on hyperconverged platforms where the storage fabric eats the I/O concern — MCS is now our default. It has no extra infrastructure to operate, image updates are a catalog operation, and the failure modes are simple. The old "MCS can't do full-scale" folklore dates from storage arrays that couldn't handle boot storms; modern all-flash tiers don't blink.
Provisioning Services still earns its keep in two places: very large single-image server workloads (hundreds of RDSH hosts streaming one vDisk is genuinely elegant, and the cache-in-RAM-with-overflow model turns disk I/O into memory), and shops that already have PVS operational maturity — the wire format, the TFTP/BDM bootstrap, the versioning workflow. If a client runs PVS well today, we don't rip it out. But we no longer start new estates there by default, because PVS is its own farm to design, patch, and troubleshoot, and every component you operate is a component that can page you at 3 a.m.
The honest decision matrix is one line: MCS unless you can articulate the specific reason it's PVS.
Profiles: the part that actually breaks user experience
Ask users what "the Citrix is slow" means and it's logon time, and logon time is profiles. Our standard on 7.15 is Citrix User Profile Management — included in the license, mature, and predictable — with folder redirection kept deliberately minimal: Documents and Desktop redirected, AppData left local to the profile, because redirected AppData over a WAN link is how you turn a 20-second logon into a two-minute one.
The UPM settings that matter, from estates that hold under 30-second logons at the 95th percentile:
- Profile streaming on; active write-back on for pooled desktops.
- Aggressive exclusion lists — browser caches, temp, crash dumps, anything a vendor app writes that it doesn't need back. We maintain the exclusion list as a living config item, reviewed when logon telemetry drifts.
- Profile store on a file cluster sized for IOPS, not just capacity, in the same datacenter as the VDAs. Cross-site profile access is forbidden by policy.
Outlook cached mode on non-persistent desktops remains the industry's open wound — the OST doesn't roam, so you choose between online mode against Exchange (fine on LAN-quality links to Office 365 with sensible geography) or third-party container tools like FSLogix, which we've deployed where search performance was a hard requirement. Watch that space; containers feel like where profiles are heading.
NetScaler, GSLB, and the 99.95% math
Availability at four-and-a-half nines isn't produced by any single component — it's produced by making every layer independently survivable and then testing the seams. The access tier is where most estates quietly concentrate risk, so: HA pairs per site, GSLB between sites, and certificate/STA configuration treated as code. Two specifics that bite people:
# The boring checks that prevent the exciting outages
show ha node # secondary actually healthy, not just present
show ssl certKey # nothing expiring inside 45 days
First, Secure Ticket Authority entries on the Gateway must track your Delivery Controllers exactly — a stale STA after a controller rebuild produces intermittent launch failures that look like gremlins. Second, GSLB failover must be tested with real sessions, not ping monitors; an ICA session's tolerance for a datacenter flip is a user conversation you want to have in a pilot, not an incident bridge.
Density, GPU, and what we're not deploying yet
On Server 2016 RDSH with Office and a line-of-business mix, we're seeing healthy density in the 50-user-per-host range on current dual-socket hardware — but we size from a pilot's measured CPU-per-user and steady-state RAM, never from a vendor ratio. Windows 10 desktop VDAs land wherever the application portfolio dictates; the spread between a task-worker image and an engineering image is 3x, which is why "how many users per host" is a question we refuse to answer without telemetry.
GPU: NVIDIA GRID vGPU on 7.15 is solid for the CAD and clinical-imaging use cases that justify the card cost. For general knowledge workers, we're not there yet on price — though the way browsers and Office lean on GPU rendering each year, we expect to revisit that position within a couple of hardware cycles.
Skipped on purpose in this baseline: AppDisks (layering strategy in flux industry-wide), and the Citrix Cloud control plane — interesting trajectory, not yet where our government and regulated clients can put a management plane. We'll re-evaluate both at the first cumulative update.
If you're facing this
If your Citrix estate is drifting on an old 7.6 baseline, stuck on the Current Release treadmill, or failing its logon-time SLA every Monday morning, 7.15 LTSR is the right moment to rebase — and the design decisions above are most of the project. We've built and operated this platform at 10,000-user scale and can usually tell you within a day of looking at your Director data where the pain actually lives. Get in touch.