LoadGen add-in
Your test sees the application, not just the pixels.
Driving a remote desktop by its screen means finding a button by its picture or its position, and waiting for pixels to stop changing. That breaks when the resolution, the theme, the language or the layout changes, and it cannot tell a slow application from a slow screen.
The LoadGen add-in is a small Windows service in your session host or desktop image. It opens a private channel inside each user's own Citrix, Remote Desktop, Azure Virtual Desktop or Omnissa Horizon session, so LoadGen works with the application's real controls.
What it does inside the session
Finds controls by name, ID and type in the application's own control tree, and clicks them, types into them and sets their values.
Reads the value of a control, so a validation checks what a field really contains.
Stops a timer when the window or control actually appears, closes or changes its caption, so measurements time the application.
Starts, checks and stops applications inside the session, with a time limit.
Why it matters
The difference between testing an application and testing a screen.
Steps survive a new screen
Steps that find controls by name and type keep finding them after a new resolution or screen layout.
A workload moves with you
A workload moves to a new gold image or a desktop in another language: LoadGen Studio heals the blocks that changed instead of you recording them again.
Timings measure the application
Response times are the application’s, not the time it took the screen to repaint.
One way of working for four technologies
The Citrix add-in for Citrix in Enhanced mode, and one add-in for Remote Desktop Services, Azure Virtual Desktop and Omnissa Horizon.
The AI Builder uses the same control tree
LoadGen Studio's AI Builder uses the same control tree, so the steps it writes click named controls instead of screen positions.
Screen only, or with the LoadGen add-in.
| Screen only | With the LoadGen add-in | |
|---|---|---|
| Finding a control | Its picture or its position | Its name, ID and type in the control tree |
| Checking a result | Pixels or on-screen text | The real value of the field |
| End of a step | The screen stops changing | The window or control appears |
| Starting an application | Click its icon and wait | Started and checked inside the session |
| New resolution or layout | Record again | Steps found by name and type keep finding their controls |
| New gold image or language | Record again | Heal the blocks in LoadGen Studio and run |
What it takes
Install it once in the image, or push it from LoadGen.
Install it once in your golden image, or push it to the session hosts from LoadGen over WinRM or SMB. The Session Host Add-ins page shows the status of every machine, such as Running, Outdated or Unreachable, with the fix underneath, and after an update LoadGen lists any add-in that is behind.
Where Citrix or Horizon virtual channel security is on, add one allow-list entry. The add-in only talks over the user's own session: nothing in the desktop connects back to LoadGen.
How the add-in differs from a Full AgentRequired, not optional
The add-in is required for Remote Desktop Services, Azure Virtual Desktop and Citrix in Enhanced mode. Without it those users fail.
Nothing dials out of the desktop
The add-in talks over the session the test user already opened. Nothing inside the session host or desktop connects back to LoadGen.
It runs the workload; the agent opens the session
A Full Agent opens the session with the built-in client. The add-in, inside the image, carries out the steps in your real applications.
What the add-in does not do.
- It does not measure logon phases. Logon phases are read in the analysis after a run, and they need LoadGen Insight in the image.
- It does not configure Citrix or Omnissa Horizon virtual channel security for you. Where that security is on, your team adds one allow-list entry.
- It is not a replacement for an agent. The Full Agent opens the session; the add-in works inside it.
Put it in one image and see the difference.
We install the add-in on a session host of yours, run the same workload with and without it, and show you what each one measures.
