Ninety-nine point nine five percent sounds precise until you ask which layer of the VDI stack it covers. Brokers? Gateways? Session hosts? Profiles? Identity? The storage under FSLogix containers? We run multi-tenant and enterprise VDI estates that advertise high availability — including environments sized for ten thousand-plus concurrent users — and the only way that number stays honest is if you design for it as a budget of failure, not as a marketing vibe.
This post is how we allocate the nines, where they are usually lost, and the operational habits that keep an SLA from becoming a lawsuit slide.
What 99.95% actually means
Roughly twenty-two minutes of unplanned unavailability per month if you interpret it as a hard monthly budget — or about four hours per year if you annualize simply. Real contracts define measurement windows, excluded maintenance, and whether "degraded but logged on" counts as up. Write those definitions before you promise the number.
We refuse SLAs that measure only "the broker answers ICMP" while users sit at a black spinner because profiles or storage are dead.
Where the nines go to die
In order of how often they bite production:
- Profiles and login path. Storage latency or FSLogix mount failure equals "VDI is down" for the user even if every VM is green.
- Gateways and reverse proxies. NetScaler/ADC or RD Gateway capacity and certificate expiry — single points dressed as pairs.
- Identity. Azure AD or AD FS outages, domain controller locality, token issues — no desktop without auth.
- Capacity exhaustion. Not a hard crash: logon storm exceeds available session hosts; users queue or fail. N+1 was a slide, not a buffer.
- Image and control plane. Hosting the golden image update that reboots the only pool during payroll.
- Underlying hypervisor or Azure region issues. Real, but less frequent than the above in our post-mortems.
If your HA design starts and ends with "two brokers in an HA pair," you have designed the demo, not the service.
N+1 math across pools
For session hosts and Windows 10 multi-session pools:
- Size for peak concurrent, not average
- Add N+1 (or N+2 for large estates) hosts that can absorb a host failure and a patch ring
- Separate pools by workload class so a power-user pool cannot starve task workers
- Autoscale if you use it — test scale-out lag under morning spike; cold start is not infinite capacity
For Citrix: Delivery Controllers, StoreFront, SQL for site DB — each has an HA story; SQL especially is under-designed in shops that virtualize "a SQL Express somewhere."
Monitoring that matches user experience
SCOM or other platform green is necessary and insufficient. We watch:
- Logon duration percentiles (not averages alone)
- Gateway concurrent and CPU
- Profile share latency and failed mounts
- Failed launch rate by pool
- Synthetic transactions: log on, open published app, measure
Alert on the user path. Capacity plans use the same telemetry, not vendor seat-of-pants ratios.
The SLA post-mortem habit
Every miss gets a written post-mortem: timeline, user impact, layer that failed, detection lag, fix, and one design change. Without the last item, you are journaling, not operating.
We also schedule failure injection in non-prod: kill a gateway node, drain a host, throttle storage. Teams that never practice failover discover their runbooks are fiction during the real event.
Maintenance vs availability
Patch windows are not free. Announce them, exclude them from SLA if the contract allows, and use rolling drains so "maintenance" is not a simultaneous pool reboot. The estates that hold 99.95% treat change like a production deploy, not like a weekend hobby.
Multi-site and multi-tenant wrinkles
On multi-tenant Skype and VDI platforms we have run, noisy-neighbor and blast-radius rules matter as much as HA pairs. A certificate replacement that restarts a shared gateway can violate many customer SLAs at once. Change freezes, staggered maintenance, and per-tenant isolation boundaries are availability controls, not bureaucracy.
For single-enterprise estates spanning sites, decide whether users fail over across WAN to a second datacenter or accept site-local outage. Stretching profiles across high-latency links to chase nines often loses more user productivity than a clean site declaration.
Runbooks people can execute
At 3 a.m., prose architecture decks fail. We keep:
- One-page "service down" decision tree (gateway vs broker vs profiles vs identity)
- Named on-call for each layer
- Pre-approved actions (failover gateway, drain hosts, enable backup storefront)
- Comms templates for "degraded" vs "hard down"
The 99.95% design includes the human system.
Capacity example (simplified)
If peak concurrent is 2,000 task workers at 8 sessions per host, you need 250 hosts of capacity before buffer. N+1 at rack level might mean several extra hosts; N+1 at image-update level means more. Patch rings that take twenty percent of hosts offline require twenty percent spare or accepted degraded concurrency. Write the math on one page; argue about the math; then buy to the math. Feeling lucky is not an HA strategy.
User communication during incidents
Availability is also perception. A banner that says VDI degraded — logons slow, do not reboot twice — reduces duplicate load and ticket storms. Silence creates reboot storms that make outages worse. Pair technical HA with status communication.
Dependency map mandatory
Before signing any SLA, list dependencies: identity, DNS, DHCP, profile storage, app databases, licensing servers, gateways, internet path for Office. Each dependency needs an owner and an HA story. VDI cannot be more available than its weakest required dependency for logon.
If you're facing this
If leadership wants "four nines of VDI" and the design is a single file server for profiles, renegotiate either the number or the budget. We design Citrix, RDS, and Azure desktop HA with explicit failure budgets — bring your concurrent peak and your real dependency map.