Horizon, validated past the front door.
LoadGen runs Omnissa Horizon on the generic wizard with full control over connection, display, and workloads - published apps + desktops, with VDI agents handling per-session Activate / Reset / Kill operations.
New Load Profile
Select a technology to create a new load profile
Select Technology
Choose the connection technology for your new load profile. Each technology has its own guided wizard.
Omnissa Horizon
VMware Horizon View. Connection server-based testing for Omnissa environments.
VDI Technologies
Citrix Enhanced - StoreFront / Gateway
Citrix Basic - Direct ICA connection
RDP - Remote Desktop Protocol
Azure Virtual Desktop - Azure Virtual Desktop
Omnissa Horizon - Omnissa Horizon
Web & Automation
Web Testing - Browser automation
Core - Command-line execution
Special Modes
Local Client - Local VDI client
vWorkspace - Dell vWorkspace
The Problem
Horizon doesn’t break at the URL - it breaks under the URL.
Connection Server queues and Horizon concurrency are where Horizon actually bends. Generic probes don’t reach either.
Connection Server bottlenecks hide under "good enough" probes.
A 200 OK on a synthetic check tells you nothing about Connection Server queue depth or vCenter latency under real concurrency.
Generic load tools can’t script Horizon.
Published apps and desktops, RDSH session pools, and Omnissa-specific delivery - generic HTTP-only tools see only the front door.
Capacity plans built without measurement age fast.
Without parity testing across Connection Server tiers, every refresh cycle re-introduces the same right-sizing question - answered the same wrong way.
How LoadGen handles Horizon
Connect · Author · Execute · Monitor.
Four motions on the same scenario engine: author, run, measure, compare.
Connect
Generic wizard with Omnissa technology - Connection Server URL, credentials, and access captured once.
Author
Workload-based scenarios run against published apps and desktops. Display, scenario, and VDI-agent strategy captured in the same wizard.
Execute
VDI agents run Activate, Reset, Kill operations on every Horizon session - Full agents handle non-VDI sessions.
Monitor
Continuous E2E UX validation alongside Connection Server counters bound via SUT Monitoring - same audit trail as load.
Live · Generic Wizard · Horizon tab
One wizard. Every published target.
Author published apps and desktops on the generic wizard, run on VDI agents, validate against the same AVD scenarios. Horizon stops being a separate tool.
Outcomes · before / after
Right-size Horizon on data - not on a vendor reference architecture.
Drawn from teams that adopted scenario-driven Horizon load testing for one quarterly refresh cycle.
Before
6 days
After
4 hrs
Before
±35 %
After
±5 %
Before
6
After
1
Before
120
After
420
Horizon → Platform
Five features. One Horizon practice.
Horizon isn’t a separate tool - it’s the way these five features compose into a single VDI testing and validation loop.
Load Profile Wizard
Generic wizard with Omnissa Horizon support - published apps + desktops authored side by side.
/features/load-profile-wizard
Agents
VDI agents for Horizon pools - Activate, Reset, Kill batch ops on every session host.
/features/agents
SUT Monitoring
Bind any Windows performance counter through the SUT Monitoring step - Connection Server, host, or infra signals correlate with capacity.
/features/sut-monitoring
End-to-End Monitoring
Continuous Horizon UX validation from the real user perspective - same scenario shape as your load tests.
/products/monitoring
Analytics & AI
AI-flagged Connection Server queue-depth anomalies and Horizon-vs-AVD parity overlays.
/products/analytics-ai
Stop validating Horizon at the URL.
Connect to Connection Server this afternoon. Run a 200-user scenario this week. Resize Horizon on a measurement next quarter.
