Tevron

Also published on the product site: sla-breaches-while-noc-sleeps-citratest-apm.aspx

CitraTest APM continuous overnight watch – when WaitForImage timers breach SLA after hours, alerts and failure screenshots become the morning handoff, not another green Director tile.

Direct answer: CitraTest APM® keeps scoring on-the-glass SLA limits overnight with the same WaitForImage + StartTimer/StopTimer path daytime ops trust. When a Monitor/Timer breaches while the NOC is asleep, the page carries failure screenshots of where the business screen stopped – so morning handoff starts from glass proof. Playback uses real mouse and keyboard on Citrix, Microsoft RDS, Azure Virtual Desktop, browsers, and thick Windows clients. No CitraTest agents on production session hosts for the glass path. Green overnight Director is not usable glass.

At 03:41 an SLA limit tripped. Login-to-shell crossed the band the shift already agreed to. Nobody was live in the NOC chair – and that is normal for overnight coverage. The morning question is not whether someone watched a chart turn red in real time. The question is whether the alert pack already holds on-glass proof of where the path stopped, so the day shift does not reopen a green workbook and stop there.

That is the overnight SLA problem: breaches still happen when eyes are elsewhere, so the watch has to page with evidence, not optimism.

Green Director overnight ≠ usable glass

Control-plane health overnight is useful – and incomplete. Brokers can answer. Hosts can report calm CPU. Gateways can return 200. None of that times whether the published app, shell, or in-session transaction still appeared on screen inside the SLA. Related: Director Watches Brokers. APM Watches the Screen.

After hours the temptation is to treat green infrastructure as "quiet success." Overnight SLA breaches on the glass reject that shortcut. Success is still a timed screen state – even when the floor is dark.

Illustrative / method diagram – not Tevron customer results. Overnight green brokers do not prove usable glass.

Same glass contract – SLA bands that survive the quiet shift

CitraTest APM does not invent a midnight measurement model. Per User Guide / Quick Start guidance, overnight SLA watches use the same contract as any continuous watch:

1. Scripts encode the workflow on a Windows desktop.
2. Playback sees the UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties between capture and playback machines so overnight "image not found" is a real delay, not theme drift that only shows up on the quiet shift.

Illustrative method diagram – not customer results. That pipeline is what overnight SLA limits actually score.

Publish the path so overnight breaches are actionable

An SLA limit only helps if the Scenario that scores it is the known published version – not a laptop copy someone forgot before the weekend. Apply the same Publish → Scenario → SLA lifecycle used for continuous watches, with overnight breach handoff in mind:

Availability for summary reporting can still track successful iterations (Monitor Required Availability) separately from response-time bands. Failover agents can stand by when a primary is silent; they still need Group/Scenario membership so an overnight breach does not depend on a single quiet desktop.

For the full fleet lifecycle, see Publish → Scenario → SLA: Running CitraTest APM as a Continuous Watch. For the unattended-eyes operational question, see Overnight Shift Watch: When Nobody's Looking at the Dashboard. This article is the breach-and-handoff question those posts set up: when the quiet-hour timer exceeds SLA, morning must inherit proof.

Illustrative fleet flow based on the Quick Start APM Web Console chapter – not customer results.

Design the overnight alert as the morning handoff

When the NOC sleeps, the alert is the ticket starter. Design it that way:

• Name timers after moments of truth – first useful pixel / login-to-shell, app or workspace ready, key transaction ready – not after protocol hop labels the day shift will not reopen.
• Set SLA bands from agreed operational limits – what the shift already treats as too slow – then let overnight iterations report whether the path still meets them.
• Treat failure screenshots as first evidence – on-glass proof of where WaitForImage stopped, so dawn triage does not begin with a green Director screenshot and a shrug.
• Page for glass breach, not only for host red – overnight infrastructure calm and overnight glass late can coexist; the alert must say which one happened.
• Do not invent accuracy percentages or fictional ROI – the value of overnight SLA watches is honesty across successive iterations and a clean handoff pack.

Illustrative method diagram – not customer results. Geo shapes are example scenario layouts, not benchmarks.

Hygiene so 03:00 breaches are real

Quiet-shift "breaches" that are really environment debt waste the morning. Keep the overnight SLA watch trustworthy:

• Restore a clean desktop between iterations so leftover windows do not poison the 03:00 run.
• Publish cleanup scripts as standalone monitors when residue would strand the next schedule.
• Use script versioning for phased rollout – avoid assigning conflicting versions of the same script to one agent before a long weekend.
• Match display contracts – resolution, color depth, theme, font smoothing – between capture and playback so night-only "image not found" noise stays rare.

If you already sized concurrency with CitraTest VU, reuse the same visual definition of success in APM. VU answers "how many?" under load; APM answers "did tonight's path still meet SLA – and did the alert pack survive until morning?" Related method posts: Control Plane ≠ Farm, What is on-the-glass APM?.

Closing: let overnight breaches arrive with proof

SLA Breaches While the NOC Sleeps is not a different product mode. It is CitraTest APM continuous monitoring under the assumption that quiet-hour timer breaches still need a morning-ready evidence pack – encode the path with WaitForImage and timers, publish it, schedule it across playback endpoints, score SLA limits, and page with failure screenshots when the glass path is late. Infrastructure metrics still matter for hosts and brokers. They do not replace overnight glass proof that the business screen appeared on time – or the screenshot that shows it did not.

FAQ

What does an overnight SLA breach mean in CitraTest APM?
An overnight SLA breach is a published glass Monitor/Timer that exceeds the response-time limit your Scenario scores while the NOC is thin or asleep. CitraTest APM pages with the failure screenshot of where WaitForImage stopped – so morning handoff starts from on-glass proof, not from reopening a green control-plane workbook.

Why can Director stay green overnight while the glass path breaches SLA?
Director, Azure workbooks, and gateway checks report brokers, hosts, and front-door health. They do not time whether login-to-shell or a key in-session screen appeared inside the SLA. Overnight, that gap widens: control plane green is not usable glass.

How should timers be placed for overnight SLA watches?
Place StartTimer immediately after the initiating action. Confirm readiness with WaitForImage (prefer static bitmaps for sync). Place StopTimer after that wait succeeds. OCR may read or assert dynamic text afterward; OCR is not a wait/sync.

Do overnight SLA watches require agents on production session hosts?
No. For the glass path, CitraTestAPMAgent runs on playback machines with Windows access to the client path. No CitraTest agents are required on production session hosts.

How does this differ from Overnight Shift Watch and Publish → Scenario → SLA?
Publish → Scenario → SLA is the fleet lifecycle that turns a glass script into a continuous watch. Overnight Shift Watch is the unattended operational question – keep proving the path when nobody is staring at a dashboard. This article is the breach-and-handoff question: when an overnight timer exceeds SLA, the alert and screenshot must carry morning-ready proof.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: autoscale-hides-sessions-per-host-citratest-vu.aspx

CitraTest VU density testing for Citrix Virtual Apps and Desktops and Citrix DaaS – prove sessions-per-host with Autoscale OFF first, then measure scale-out lag on the glass so scale-out cannot mask a bad host SKU.

Direct answer: Autoscale can hide a bad sessions-per-host number. If every density run lets Citrix Autoscale (on-prem or Citrix DaaS) keep adding session hosts, each machine may never reach the pack you claim to support – while Workspace, StoreFront, Gateway, and the broker stay green. CitraTest VU® load-tests from the glass: run density with Autoscale OFF (or pinned) first, size the host from WaitForImage / StartTimer/StopTimer moments of truth, then run a second test that measures scale-out lag. Do not let scale-out mask a bad sessions-per-host.

Teams that only ever "ramp until Autoscale catches up" often leave Monday morning with a false capacity story. New hosts absorb overflow; Director and the control plane look fine; nobody measured what a full session host feels like on screen when the catalog stops growing. That is not SKU truth. That is scale-out covering for density debt.

This post is the Autoscale-specific density method for CitraTest VU on Citrix Virtual Apps and Desktops and Citrix DaaS. It builds on The Control Plane Is Not the Farm and Logon storm vs density. It is not a how-to for splitting automated regression scripts (Control Plane ≠ Farm for automated testing), not APM continuous watch (Publish → Scenario → SLA), and not the general profile-then-scale sequencing article (Profile the User Journey, Then Scale the VUs). Same glass contract; this article is the order of operations when Autoscale is in the picture.

By Jay Labadini, Tevron

Why Autoscale can hide a bad sessions-per-host

Autoscale is useful operations. It is a poor substitute for density proof.

• Scale-out dilutes pack. When new session hosts keep joining under load, concurrency spreads across more machines. You never force the sessions-per-host number your SKU and image are supposed to carry.
• Broker green is not glass ready. Delivery Controllers / cloud brokers can place sessions and report healthy capacity while published-app first paint and in-session click-to-ready stretch on a packed host.
• Front door ≠ farm. Workspace, StoreFront, and Gateway are the control-plane front door. Session hosts are the farm. A green launch path does not prove density on the host.
• Storm-only runs miss sustain. A steep login storm may pass because Autoscale spun hosts in time – then mid-day density still hurts when everyone is already connected and working.
• Unnamed timers hide the host. If you only clock "session connected" or a single stopwatch, you cannot tell whether scale-out lag or packed-host glass latency broke first.

Size the host from the glass, not the broker. Prove what one (or a fixed set of) session host(s) can sustain under honest on-screen work – then decide what Autoscale is allowed to buy you.

Illustrative / method diagram – not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs when density is never isolated.

Control plane ≠ farm (reminder)

Keep the vocabulary tight for Citrix Virtual Apps and Desktops / Citrix DaaS:

URL and broker checks stay necessary. They are not density. For the deeper framing under load, see The Control Plane Is Not the Farm.

Illustrative method diagram – not customer results. The front door is not the farm.

Method: density with Autoscale OFF first

Before you celebrate scale-out, pin the farm (or turn Autoscale OFF / hold a fixed host count) and run a density / sustain phase with CitraTest VU:

1. Encode the on-the-glass journey users cannot skip – Workspace / StoreFront / Gateway launch into the published app or desktop, then multi-step in-session work.
2. Sync with WaitForImage on static bitmaps; place StartTimer immediately after each initiating action and StopTimer after WaitForImage confirms the screen state users care about.
3. Hold concurrency at the sessions-per-host target you intend to claim – on that fixed host count – and exercise sustained work (not only logon).
4. Read density from glass timers – published-app first paint, chart/grid ready, save/post confirmation – not from "ICA connected" or broker session count alone.

Prefer static bitmaps for sync cues that do not change (icons, window chrome, confirmation glyphs). Reserve OCR for dynamic text (IDs, order numbers, timestamps). OCR is not a wait/sync – confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Under VU, OCR calls have no timeout for wait/sync.

That first run answers: can this host SKU and image carry N concurrent users through real glass work? If it cannot, Autoscale will only spread the pain – or hide it until the catalog cannot grow fast enough.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside the density run Autoscale must not dilute.

Second run: measure scale-out lag

After density is honest on a fixed farm, turn Autoscale back on (or un-pin) and run a second test aimed at scale-out behavior – not at redefining sessions-per-host:

• What you change: allow capacity to grow under the same glass scripts and the same moments of truth.
• What you learn: how long until new hosts deliver usable glass (logon-to-shell / published-app ready) during the rush – scale-out lag – without pretending that lag is a substitute for density proof.
• What you do not do: treat a pass that only worked because hosts kept joining as proof of the old sessions-per-host number.

Login storm and density/sustain remain distinct ramp shapes on both runs. Storm stresses steep concurrent logons through the front door and broker. Density holds concurrency and works inside the session. Autoscale OFF belongs on the density proof; Autoscale ON belongs on the scale-out lag measurement. Mixing them into one "ramp forever" curve hides which story failed. See Logon storm vs density.

Illustrative method diagram – not customer results. Apply storm vs density on a pinned farm first; then measure Autoscale scale-out lag separately.

CitraTest VU on the glass (architecture, brief)

Per the CitraTest User Guide (Chapter 11) and Quick Start VU overview:

1. A dedicated VU load server hosts many localhost RDP "CitraTest VU Sessions."
2. Each session runs the profiled CitraTest script and opens its own client connection to the Citrix environment under test – Workspace / StoreFront / Gateway into session hosts – just as real users would.
3. Scripts drive the remoted GUI with real mouse and keyboard, sync with bitmaps, and optionally use OCR for dynamic text after image sync.
4. Separate measurement machines record response timers under load.

Nothing invasive is required on the session hosts for the glass path: the load is client-side. You change ramp, concurrency, think time, and whether Autoscale may grow the farm – not the definition of success. Success remains: the image-confirmed UI state appeared within the timer threshold under the load you claim to support.

Illustrative architecture based on User Guide Ch 11 / Quick Start VU overview – not a performance result chart.

Illustrative method diagram – not customer results. Encode the journey, prove density on a pinned farm, then measure scale-out lag.

Size the host from the glass, not the broker

Broker session counts, CPU averages, and Autoscale rules answer capacity placement. They do not answer whether the published app was ready on screen at the density you sell to operations. Pin the host count, hold concurrency, time WaitForImage moments of truth, and only then interpret Autoscale as a way to buy more of a host size you already trust – or as a lag you must budget for during storms.

Related method hubs: How to load test Citrix, Best Citrix Load Testing Tools, What is CitraTest VU?.

How this sits next to related posts (brief)

• The Control Plane Is Not the Farm – glass-level VU framing; this post expands the Autoscale / sessions-per-host method called out there.
• Logon storm vs density – why storm and sustain must stay separate; Autoscale does not collapse that split.
• Profile the User Journey, Then Scale the VUs – encode the journey before concurrency; Autoscale OFF density still needs an honest journey.
• Control Plane ≠ Farm (automated testing) – build separate login-storm vs sustained-path scripts; VU sizes them under load.
• CitraTest APM – keep the same glass definition of success as a production watch after lab density is proven.

Closing: prove density, then trust scale-out

Autoscale can hide a bad sessions-per-host number. Run density with Autoscale OFF (or pinned) first – WaitForImage sync, StartTimer/StopTimer on the glass, bitmaps for static cues, OCR only for dynamic text (OCR is not a wait). Size the host from what users see, not from the broker. Then run a second test that measures scale-out lag. Login storm and density/sustain stay distinct. Control plane ≠ farm: Workspace / StoreFront / Gateway are the front door; session hosts are the farm. Capacity stories that only worked because hosts kept joining are not SKU truth.

FAQ

How can Citrix Autoscale hide a bad sessions-per-host number?
When Autoscale keeps adding session hosts under load, each host may never reach the sessions-per-host density you claim to support. Broker and front-door metrics can stay green while glass latency on a packed host is never measured. Prove density with Autoscale OFF (or pinned) first; run a second test that isolates scale-out lag.

What is the CitraTest VU method for Citrix density vs scale-out?
First run: hold concurrency on a fixed host count with Autoscale OFF and exercise multi-step on-the-glass work with WaitForImage and StartTimer/StopTimer. That run sizes sessions-per-host from the glass. Second run: allow Autoscale and measure scale-out lag – how long until new capacity delivers usable glass – without letting scale-out mask a bad density number.

Is Workspace or StoreFront green enough to prove session-host density?
No. Workspace, StoreFront, and Gateway are the front door (control plane). Session hosts are the farm. Control-plane green is not farm proof. Size the host from the glass, not the broker.

Can OCR be used as a wait or sync under CitraTest VU?
No. VU OCR calls have no timeout for wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Prefer bitmaps for static UI cues; reserve OCR for dynamic text.

How does this post differ from The Control Plane Is Not the Farm and Logon Storm vs Density?
Those articles establish control plane vs farm and the login-storm vs density split. This article is the Autoscale-specific density method: prove sessions-per-host with Autoscale OFF first, then measure scale-out lag on a second run so scale-out cannot mask a bad sessions-per-host number.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: profile-rds-journey-then-scale-citratest-vu.aspx

CitraTest VU load testing for Microsoft RDP / RDS / Remote Desktop – encode the on-the-glass journey (mstsc, RD Web, Session Hosts, RemoteApp) with WaitForImage and StartTimer/StopTimer first, then scale concurrent virtual users.

Direct answer: Do not ramp concurrency against a vague Microsoft RDS script. CitraTest VU® load-tests Remote Desktop Services from the glass – but the honest sequence is profile the RDS user journey first, then scale the VUs. Walk the real client path (mstsc, Remote Desktop app, RD Web / Gateway into a Session Host or RemoteApp), encode mouse and keyboard steps, sync with WaitForImage, time moments of truth with StartTimer / StopTimer, prefer static bitmaps, reserve OCR for dynamic text (OCR is not a wait). Only after that definition of success is stable do you raise concurrent virtual users.

Teams that start with "how many RDP sessions can we push?" often skip the harder question: what does a single successful RDS journey look like on screen? If the script stops at "RDP connected," hammers RD Web over HTTP, checks Connection Broker health, or sleeps for five seconds after credentials, concurrency only amplifies the wrong clock. A thousand virtual users with a bad RDS journey is not Session Host capacity planning – it is noise at scale.

This post is the RDP/RDS-specific sequencing method for CitraTest VU load testing: encode the Microsoft Remote Desktop journey on the glass, then scale. It is distinct from the general VU article Profile the User Journey, Then Scale the VUs (Citrix, RDS, and cloud together). It is not a production continuous-watch guide (that is CitraTest APM Publish → Scenario → SLA), not an after-hours APM watch (Overnight Shift Watch), and not a how-to for splitting automated regression scripts into login-storm vs sustained-path builds (Control Plane ≠ Farm for automated testing). For why control-plane / broker green is not farm proof under load, see The Control Plane Is Not the Farm. Same glass contract; this article is the order of operations for Microsoft RDS.

By Jay Labadini, Tevron

Why ramp-first fails on Microsoft RDS

Concurrency is a multiplier. It multiplies whatever your RDS script already treats as "done."

• RDP connected is not shell ready. The remoting channel can be up while profile attach, GPO, FSLogix (or equivalent), and the desktop or RemoteApp are still painting.
• RD Web HTTP is the front door, not the farm. Soaking the portal times the website – not Session Host density or in-session click-to-ready.
• Broker / host counters are not the wait the user feels. Connection Broker health and Session Host CPU can look fine while logon-to-shell and RemoteApp first paint stretch.
• Fixed sleeps hide variance. A pause that works for one calm mstsc session collapses under a Monday morning rush – or falsely passes when the glass was ready sooner.
• Unnamed timers cannot guide SKU decisions. If every step dumps into one stopwatch, you cannot tell whether broker spin-up, profile attach, or in-session work broke first.

Profile the RDS journey until a single VU (or a small interactive playback) proves the same moments of truth a real Remote Desktop user would recognize. Then scale.

Illustrative / method diagram – not Tevron customer results. Control-plane and broker indices can remain "healthy" while glass-level RDS response climbs with concurrency.

Profile the RDS journey on the glass

Per CitraTest User Guide / Quick Start measurement guidance, an on-the-glass Microsoft RDS journey uses one contract:

1. Scripts encode the workflow on a Windows desktop – including the real RDP client path.
2. Playback sees the remoted UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard into mstsc / Remote Desktop / RD Web launch and the Session Host session.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Walk the path a shift cannot skip on your farm:

• Logon-to-shell – credentials (or RD Web / Gateway launch) until a usable desktop or RemoteApp window is ready: shell, icons, no logon animation. Not "the broker returned a session."
• RemoteApp / published app launch – icon or Start-menu click until first paint of the business app. Not "the process started on the Session Host."
• In-session transactions – click or key until the ready state: open record, save, print, switch RemoteApps. The wait behind "the desktop is slow" tickets after everyone is already connected.

Name each timer after what the user sees on the glass, not after an RDP round-trip or broker hop label. Pin the Session Host image, collection, client (mstsc / Remote Desktop app), and RD Web or Gateway build. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback so "image not found" failures are real application delays, not environment drift.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside the RDS journey you will later scale.

Bitmaps for sync; OCR only for dynamic text

While you profile – and later under VU concurrency on RDP pixels – keep OCR in its lane:

• Prefer static bitmaps for sync cues that do not change (shell icons, RemoteApp window chrome, toolbar glyphs, confirmation marks).
• Reserve OCR for values that are unknown ahead of time (IDs, MRNs, order numbers, timestamps on the remoted app).
• OCR is not a wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Under VU, OCR calls have no timeout for wait/sync; flaky "OCR problems" on RDS are usually sync problems in disguise.

Related: Advanced OCR for Automated Testing.

Then scale: CitraTest VU concurrency on RDS

Once the RDS journey is honest in interactive playback, scale it with CitraTest VU. Per the CitraTest User Guide (Chapter 11) and Quick Start VU overview:

1. A dedicated VU load server (Windows Server with Remote Desktop Services) hosts many localhost RDP "CitraTest VU Sessions."
2. Each session runs the profiled CitraTest script and opens its own client connection to the Microsoft RDS farm under test – mstsc / Remote Desktop / RD Web path into Session Hosts or RemoteApp – just as a group of real users would.
3. Scripts continue to drive the remoted desktop with real mouse and keyboard, sync with bitmaps, and optionally use OCR for dynamic text.
4. Separate measurement machines record response timers under load; results land in a results database and VU Results Console.

Nothing invasive is required on the Session Hosts or brokers for the glass path: the load is client-side. You change ramp, concurrency, and think time – not the definition of success. Success remains: the image-confirmed UI state (shell, RemoteApp, in-session ready) appeared within the timer threshold under the load you claim to support.

Illustrative architecture based on User Guide Ch 11 / Quick Start VU overview – not a performance result chart.

Illustrative method diagram – not customer results. Encode the RDS journey, then raise concurrent VUs against the same WaitForImage timers.

After the RDS journey is honest: storm vs density (brief)

Scaling is not one blunt ramp. Once the glass journey is profiled for Microsoft RDS, Tevron’s 2026 method guidance still separates two load phases – with the same scripts and the same moments of truth:

Do not invent a second definition of success for each phase. Change how many VUs arrive and how long they stay busy on the Session Hosts. For the deeper control-plane-vs-farm framing under load, see The Control Plane Is Not the Farm and Logon storm vs density. For the broader Microsoft RDS method hub, see Microsoft RDS Load Testing.

Illustrative method diagram – not customer results. Apply the same split after the RDS journey is profiled for Session Hosts and RemoteApp collections.

Sizing note (after the journey, before the big run)

Current User Guide Chapter 1 and Quick Start align on:

8 GB baseline + 8 GB additional RAM per 200 VU sessions, quad CPU minimum, 200 GB disk minimum, RDS configured per Chapter 11.

Also operational: do not minimize VU RDP windows during a run – RDP can blank the display, and scripts need a visible desktop to see. Profile with a visible desktop; scale with a visible desktop. If the generator desktop is pegged, you are measuring the lab, not the Session Host farm.

How this sits next to APM, automated testing, and the general VU post (brief)

One glass definition of success travels across Tevron products without turning this article into those playbooks:

• CitraTest VU – profile the Microsoft RDS journey, then size it under concurrency (this post). General sequencing across Citrix / RDS / cloud: Profile the User Journey, Then Scale the VUs.
• CitraTest – build regression scripts with the same WaitForImage / timer contract; see Control Plane ≠ Farm (automated testing) when login-storm and sustained-path need separate encodings.
• CitraTest APM – schedule the same class of glass transaction in production (Publish → Scenario → SLA), including after-hours watches.

Related: What is CitraTest VU?, Microsoft RDS Load Testing, How to load test Citrix.

Closing: encode the RDS journey, then raise concurrency

Profile the Microsoft RDP / RDS user journey on the glass until WaitForImage and StartTimer/StopTimer name the moments a real Remote Desktop shift would recognize – logon-to-shell, RemoteApp launch, in-session ready. Prefer bitmaps for static sync; reserve OCR for dynamic text; never treat OCR as a wait. Then scale CitraTest VU concurrent sessions against that same definition of success – login storm and density/sustain as ramp shapes, not as new guesses about what "ready" means on a Session Host. Capacity numbers only earn trust when the RDS journey they multiply was honest at one user.

FAQ

Why profile the Microsoft RDS journey before scaling CitraTest VU concurrent users?
Concurrency amplifies whatever the script already measures. If the RDS journey is vague – RDP connected, RD Web HTTP 200, broker green, or fixed sleeps instead of on-screen shell and RemoteApp readiness – a thousand VUs only produce a louder wrong answer. Encode WaitForImage sync and StartTimer/StopTimer for logon-to-shell, RemoteApp launch, and in-session moments of truth first, then ramp.

What does profiling an on-the-glass RDS journey mean in CitraTest VU?
A CitraTest script walks the real Microsoft RDP path – mstsc, Remote Desktop app, RD Web / Gateway launch into a Session Host or RemoteApp – drives the remoted GUI with mouse and keyboard, syncs with WaitForImage on static bitmaps, optionally uses OCR for dynamic text after image sync, and places StartTimer immediately after each initiating action and StopTimer after WaitForImage confirms the screen state users care about.

Can OCR be used as a wait or sync under CitraTest VU for RDS?
No. VU OCR calls have no timeout for wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Prefer bitmaps for static UI cues; reserve OCR for dynamic text.

How does this post differ from Profile the User Journey, Then Scale the VUs?
That article is the general CitraTest VU sequencing method across Citrix, RDS, and cloud VDI. This article is RDP/RDS-specific: mstsc and RD Web paths, Session Hosts, RemoteApp collections, RDP connected versus shell ready, and the same profile-then-scale order applied to Microsoft Remote Desktop Services.

Do you need agents on Session Hosts for CitraTest VU RDS load testing?
No. For the glass path, load is client-side from VU sessions on a dedicated load server. Each virtual user opens a real Remote Desktop connection to the environment under test. Nothing invasive is required on the Session Hosts or brokers themselves.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: overnight-shift-watch-citratest-apm.aspx

CitraTest APM continuous monitoring for after-hours and unattended shifts – same WaitForImage contract, SLA alerts when the glass path slips and the NOC is empty.

Direct answer: CitraTest APM® keeps an on-the-glass watch running overnight and across unattended shifts by scheduling the same WaitForImage + StartTimer/StopTimer path that daytime ops already trust – then paging when an SLA limit breaches or an iteration fails. Playback uses real mouse and keyboard on Citrix, Microsoft RDS, Azure Virtual Desktop, browsers, and thick Windows clients. No CitraTest agents on production session hosts for the glass path. The dashboard can be empty; the watch still has to be honest.

At 02:17 the workbook is still green. Host CPU is calm. The gateway answered. Nobody is staring at those tiles – and that is normal for overnight, weekend, and thin-NOC coverage. The question is not whether a chart was watched. The question is whether tonight’s login-to-shell, published-app first paint, or in-session transaction still landed on screen inside the SLA your shift already agreed to.

An overnight shift watch answers that without inventing a second definition of success. Same glass path. Same timers. Different operational assumption: eyes may be elsewhere, so the alert has to carry the proof.

Daytime eyes vs overnight witnesses

Daytime monitoring often leans on people: someone notices a pie chart turn, opens a report, correlates a ticket. After hours that habit breaks. Batch windows, maintenance, quiet hours, and follow-the-sun handoffs all leave stretches where the only reliable witness is a scheduled synthetic that still drives the client the way a person would.

Control-plane green does not fill that gap. Director, Azure workbooks, and gateway HTTP checks remain useful for brokers and hosts – they do not time whether the business screen appeared. Related: Director Watches Brokers. APM Watches the Screen.

Illustrative / method diagram – not Tevron customer results. Overnight coverage still needs glass timing, not only broker health.

Same glass contract – even when the floor is dark

CitraTest APM does not switch measurement models at midnight. Per User Guide / Quick Start guidance, the overnight Scenario uses the same contract as any continuous watch:

1. Scripts encode the workflow on a Windows desktop.
2. Playback sees the UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties between capture and playback machines so "image not found" is a real delay, not theme drift that only shows up on the quiet shift.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside every published overnight monitor.

Schedule the watch for unattended hours

Building the script is not enough. After-hours coverage needs operational shape in the APM Web Console – the same Publish → Scenario → SLA lifecycle described in the continuous-watch guide, applied to overnight cadence:

Availability for summary reporting can still track successful iterations (Monitor Required Availability) separately from response-time bands. Failover agents can stand by when a primary is silent for an extended period; they still need Group/Scenario membership so the overnight watch does not depend on a single quiet desktop.

For the full fleet lifecycle – Publish, Scenario membership, SLA scoring – see Publish → Scenario → SLA: Running CitraTest APM as a Continuous Watch. This article is the after-hours operational question that lifecycle answers when nobody is looking.

Illustrative fleet flow based on the Quick Start APM Web Console chapter – not customer results.

Alerts replace eyes – screenshots replace guesswork

When the dashboard is empty, the alert is the handoff. Design it that way:

• Name timers after moments of truth – first useful pixel / login-to-shell, app or workspace ready, key transaction ready – not after protocol hop labels.
• Set SLA bands from agreed operational limits – what the shift already treats as too slow – then let overnight iterations report whether the path still meets them.
• Treat failure screenshots as first evidence – on-glass proof of where the path stopped, so on-call does not reopen a green workbook and stop there.
• Do not invent accuracy percentages or fictional ROI – the value of the overnight watch is honesty across successive iterations.

Illustrative method diagram – not customer results. Geo shapes are example scenario layouts, not benchmarks.

Hygiene for unattended iterations

Quiet-shift failures are often environment debt, not mysterious outages. Keep the overnight watch trustworthy:

• Restore a clean desktop between iterations so leftover windows do not poison the 03:00 run.
• Publish cleanup scripts as standalone monitors when residue would strand the next schedule.
• Use script versioning for phased rollout – avoid assigning conflicting versions of the same script to one agent before a long weekend.
• Match display contracts – resolution, color depth, theme, font smoothing – between capture and playback so night-only "image not found" noise stays rare.

If you already sized concurrency with CitraTest VU, reuse the same visual definition of success in APM. VU answers "how many?" under load; APM answers "is it still true this hour – including the hours nobody is watching?" Related method posts: Control Plane ≠ Farm (how to build the automated tests), Profile the User Journey, Then Scale the VUs, What is on-the-glass APM?.

Closing: keep the quiet hours honest on the glass

Overnight Shift Watch is not a different product mode. It is CitraTest APM continuous monitoring under the assumption that the dashboard may be empty – encode the path with WaitForImage and timers, publish it, schedule it across playback endpoints, and page when the steps users feel breach SLA. Infrastructure metrics still matter for hosts and brokers. They do not replace a scheduled proof that the business screen appeared on time while nobody was looking.

FAQ

What is an overnight shift watch in CitraTest APM?
An overnight shift watch is a scheduled glass-level Scenario that keeps proving login-to-shell and key in-session steps while the NOC is thin or empty. CitraTestAPMAgent playback machines run WaitForImage-timed paths on a schedule; SLA limits and failure screenshots alert when the business screen is late – without requiring someone to stare at a dashboard.

How do overnight APM watches differ from daytime dashboard monitoring?
Daytime often assumes eyes on charts. Overnight and unattended shifts need the watch itself to be the first witness: scheduled iterations, SLA response-time bands, and alerts with on-glass proof. The measurement contract does not change – WaitForImage sync and StartTimer/StopTimer – only the operational assumption that nobody may be looking.

How should timers be placed for after-hours glass scenarios?
Place StartTimer immediately after the initiating action. Confirm readiness with WaitForImage (prefer static bitmaps for sync). Place StopTimer after that wait succeeds. OCR may read or assert dynamic text afterward; OCR is not a wait/sync.

Do overnight watches require agents on production session hosts?
No. For the glass path, CitraTestAPMAgent runs on playback machines with Windows access to the client path. No CitraTest agents are required on production session hosts.

How does this relate to Publish → Scenario → SLA?
Publish → Scenario → SLA is the fleet lifecycle that turns a glass script into a continuous watch. This overnight article is the operational question that lifecycle answers after hours: keep proving the path and page someone when the screen is late, even when the dashboard is empty.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: profile-user-journey-then-scale-citratest-vu.aspx

CitraTest VU load testing for Citrix, RDS, and cloud VDI – encode the on-the-glass journey with WaitForImage and StartTimer/StopTimer first, then scale concurrent virtual users.

Direct answer: Do not ramp concurrency against a vague script. CitraTest VU® load-tests Citrix, Microsoft RDS, AVD, and cloud multi-user sessions from the glass – but the honest sequence is profile the user journey first, then scale the VUs. Encode real mouse and keyboard steps, sync with WaitForImage, time moments of truth with StartTimer / StopTimer, prefer static bitmaps, reserve OCR for dynamic text (OCR is not a wait). Only after that definition of success is stable do you raise concurrent virtual users.

Teams that start with "how many users can we push?" often skip the harder question: what does a single successful user journey look like on screen? If the script sleeps for three seconds, checks a Workspace URL, or stops at "ICA connected," concurrency only amplifies the wrong clock. A thousand virtual users with a bad journey is not capacity planning – it is noise at scale.

This post is about that sequencing for CitraTest VU load testing: encode the journey on the glass, then scale. It is not a production continuous-watch guide (that is CitraTest APM Publish → Scenario → SLA) and not a how-to for splitting automated regression scripts into login-storm vs sustained-path builds (that is Control Plane ≠ Farm for automated testing). For why control-plane green is not farm proof under load – and how login storm differs from density/sustain as ramp phases – see The Control Plane Is Not the Farm. Same glass contract; this article is the order of operations.

Why ramp-first fails

Concurrency is a multiplier. It multiplies whatever your script already treats as "done."

• Protocol-ready is not user-ready. HDX and RDP can be up while the published app, chart, or order line is still painting.
• Fixed sleeps hide variance. A three-second pause that works for one calm session collapses under a Monday morning rush – or falsely passes when the glass was ready in half a second.
• URL / control-plane checks stop at the front door. They do not prove the business step completed on screen under load.
• Unnamed timers cannot guide SKU decisions. If every step dumps into one stopwatch, you cannot tell whether broker spin-up or in-session work broke first.

Profile the journey until a single VU (or a small interactive playback) proves the same moments of truth a real user would recognize. Then scale.

Illustrative / method diagram – not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs with concurrency.

Profile the journey on the glass

Per CitraTest User Guide / Quick Start measurement guidance, an on-the-glass journey uses one contract:

1. Scripts encode the workflow on a Windows desktop.
2. Playback sees the UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Walk the path a shift cannot skip – for example login-to-shell, published-app first paint, then one or two in-session steps (open chart, submit order, post invoice). Name each timer after what the user sees, not after a protocol hop label. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback so "image not found" failures are real application delays, not environment drift.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside the journey you will later scale.

Bitmaps for sync; OCR only for dynamic text

While you profile – and later under VU concurrency – keep OCR in its lane:

• Prefer static bitmaps for sync cues that do not change (toolbar icons, window chrome, confirmation glyphs).
• Reserve OCR for values that are unknown ahead of time (IDs, MRNs, order numbers, timestamps).
• OCR is not a wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Under VU, OCR calls have no timeout for wait/sync; flaky "OCR problems" are usually sync problems in disguise.

Related: Advanced OCR for Automated Testing.

Then scale: CitraTest VU concurrency

Once the journey is honest in interactive playback, scale it with CitraTest VU. Per the CitraTest User Guide (Chapter 11) and Quick Start VU overview:

1. A dedicated VU load server (Windows Server with Remote Desktop Services) hosts many localhost RDP "CitraTest VU Sessions."
2. Each session runs the profiled CitraTest script and opens its own client connection to the environment under test – Citrix, RDS, or cloud – just as a group of real users would.
3. Scripts continue to drive the desktop with real mouse and keyboard, sync with bitmaps, and optionally use OCR for dynamic text.
4. Separate measurement machines record response timers under load; results land in a results database and VU Results Console.

Nothing invasive is required on the session hosts for the glass path: the load is client-side. You change ramp, concurrency, and think time – not the definition of success. Success remains: the image-confirmed UI state appeared within the timer threshold under the load you claim to support.

Illustrative architecture based on User Guide Ch 11 / Quick Start VU overview – not a performance result chart.

Illustrative method diagram – not customer results. Encode the journey, then raise concurrent VUs against the same WaitForImage timers.

After the journey is honest: storm vs density (brief)

Scaling is not one blunt ramp. Once the glass journey is profiled, Tevron’s 2026 Citrix / RDS / cloud method guidance still separates two load phases – with the same scripts and the same moments of truth:

Do not invent a second definition of success for each phase. Change how many VUs arrive and how long they stay busy. For the deeper control-plane-vs-farm framing under load, see The Control Plane Is Not the Farm and Logon storm vs density.

Illustrative method diagram – not customer results. Apply the same split after the journey is profiled for Citrix, Microsoft RDS, and cloud VDI / DaaS.

Sizing note (after the journey, before the big run)

Current User Guide Chapter 1 and Quick Start align on:

8 GB baseline + 8 GB additional RAM per 200 VU sessions, quad CPU minimum, 200 GB disk minimum, RDS configured per Chapter 11.

Also operational: do not minimize VU RDP windows during a run – RDP can blank the display, and scripts need a visible desktop to see. Profile with a visible desktop; scale with a visible desktop.

How this sits next to APM and automated testing (brief)

One glass definition of success travels across Tevron products without turning this article into those playbooks:

• CitraTest VU – profile the journey, then size it under concurrency (this post).
• CitraTest – build regression scripts with the same WaitForImage / timer contract; see Control Plane ≠ Farm (automated testing) when login-storm and sustained-path need separate encodings.
• CitraTest APM – schedule the same class of glass transaction in production (Publish → Scenario → SLA).

Related: What is CitraTest VU?, How to load test Citrix.

Closing: encode truth, then raise concurrency

Profile the user journey on the glass until WaitForImage and StartTimer/StopTimer name the moments a real shift would recognize. Prefer bitmaps for static sync; reserve OCR for dynamic text; never treat OCR as a wait. Then scale CitraTest VU concurrent sessions against that same definition of success – login storm and density/sustain as ramp shapes, not as new guesses about what "ready" means. Capacity numbers only earn trust when the journey they multiply was honest at one user.

FAQ

Why profile the user journey before scaling CitraTest VU concurrent users?
Concurrency amplifies whatever the script already measures. If the journey is vague – protocol hops, sleeps, or URL checks instead of on-screen readiness – a thousand VUs only produce a louder wrong answer. Encode WaitForImage sync and StartTimer/StopTimer for moments of truth first, then ramp.

What does profiling an on-the-glass journey mean in CitraTest VU?
A CitraTest script drives the real client GUI with mouse and keyboard, syncs with WaitForImage on static bitmaps, optionally uses OCR for dynamic text after image sync, and places StartTimer immediately after each initiating action and StopTimer after WaitForImage confirms the screen state users care about.

Can OCR be used as a wait or sync under CitraTest VU?
No. VU OCR calls have no timeout for wait/sync. Confirm readiness with image functions first (WaitForImage, ClickOnImage), then OCR. Prefer bitmaps for static UI cues; reserve OCR for dynamic text.

How does this post differ from the control-plane-is-not-the-farm VU article?
The front-door / control-plane article explains why Workspace green is not farm proof and how login storm differs from density/sustain under load. This article is the sequencing method: profile and encode the glass journey first, then scale concurrent VUs with that honest definition of success.

Do you need agents on session hosts for CitraTest VU?
No. For the glass path, load is client-side from VU sessions on a dedicated load server. Nothing invasive is required on the session hosts themselves.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: control-plane-farm-citratest-automated-testing.aspx

CitraTest automated testing on the glass – encode control-plane login storm and farm / sustained-path density as separate scripts with the same WaitForImage timer contract.

Direct answer: A green Workspace, Gateway, StoreFront, or RD Web check is not proof that the published app or business step is ready on screen. CitraTest® automated testing encodes two different paths on the glass: a login-storm / control-plane script that proves logon-to-shell (or first useful desktop), and a sustained-path / farm script that holds the session and exercises multi-step work users actually do. Sync with WaitForImage, time with StartTimer / StopTimer, prefer static bitmaps, reserve OCR for dynamic text – and never treat OCR as a wait.

Teams that collapse every regression into "log on, click around, hope" mix two failure modes. The control plane can absorb a rush of logons while the farm still paints a blank chart. The farm can look fine under a single calm session while Monday morning’s login storm still stalls on profile or broker spin-up. Control plane ≠ farm – and the automated tests should say so out loud.

This post is about CitraTest automated testing: how to build those scripts. It is not a concurrency sizing guide (that is CitraTest VU glass-level load testing) and not a production continuous-watch guide (that is CitraTest APM Publish → Scenario → SLA). Same glass definition of success; different operational question.

Illustrative method diagram – not customer results. The control plane is not the farm.

Two scripts, two questions

Separate the automation the same way operations separates the pain:

Reuse visual components where the UI is the same. Do not force one giant script to answer both questions every run. When login fails, you want a login-storm failure – not a vague "test red." When the chart never paints, you want a sustained-path failure – not another re-logon that hides density pain.

Illustrative method diagram – not customer results. Apply the same split when you automate Citrix, Microsoft RDS, AVD, browsers, and thick clients.

Automate the login storm (control plane) on the glass

Control-plane URL checks stay useful for HTTPS health and launch reachability. They do not prove the desktop is usable. A CitraTest login-storm automation script should:

• Drive the real client – Citrix Workspace, RDS / AVD client, thick client, or browser – with real mouse and keyboard.
• Define success as on-screen readiness – shell icons, start menu chrome, published-app tile that means work can start – not merely "ICA connected" or "HTTP 200."
• Sync with WaitForImage on static cues that survive theme and branding (prefer small, unique bitmaps).
• Time login-to-shell with StartTimer immediately after the initiating logon action and StopTimer after WaitForImage confirms the ready state.
• Keep the path short – prove the rush path, then hand off or stop. Do not bury three business transactions inside the same storm script.

When you later scale the same glass path under concurrency with CitraTest VU, the login-storm script is already honest about what "logged on" means. For automated testing today, honesty means the regression suite fails on the control-plane step that actually broke.

Automate the sustained path (farm) on the glass

Farm / density automation assumes a session is already usable – or starts from a known-good shell – then exercises the work that fills session hosts:

• Multi-step business flows – open chart, add line, submit, post, print, or whatever the shift cannot skip.
• One timer per moment of truth – app first paint, grid ready, confirmation screen – named after what the user sees.
• Stable sync cues – static toolbar icons and window chrome as bitmaps; dynamic IDs, MRNs, and order numbers via OCR after image sync.
• Clean desktop hygiene – close leftover windows so the next iteration does not inherit yesterday’s failure mode.

This is where "the farm" shows up for automated testing: inside the session, under the published app, on the pixels HDX and RDP deliver. URL green on the front door does not substitute for WaitForImage on the chart.

Illustrative / method diagram – not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs.

One measurement contract: see, wait, act, measure

Whether the script is login storm or sustained path, CitraTest keeps the same on-the-glass contract (User Guide / Quick Start guidance):

1. Scripts encode the workflow on a Windows desktop.
2. Playback sees the UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback so "image not found" failures are real application delays, not environment drift.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside every automated test.

How this sits next to VU and APM (brief)

One glass definition of success travels across Tevron products without turning this article into a load or APM playbook:

• CitraTest – build and run the automated tests: login-storm scripts and sustained-path scripts as separate, honest paths.
• CitraTest VU – size those same paths under concurrency (login storm ramp, then density/sustain). See also Logon storm vs density.
• CitraTest APM – schedule the same class of glass transaction in production (Publish → Scenario → SLA).

Related reading: Advanced OCR for Automated Testing, The Control Plane Is Not the Farm (VU load testing), Publish → Scenario → SLA.

Closing: automate what the user feels – twice

Control plane ≠ farm. Automate the login storm so logon-to-shell failures stand alone. Automate the sustained path so density work inside the session stands alone. Keep WaitForImage as the sync, StartTimer/StopTimer as the clock, bitmaps for static cues, and OCR only for dynamic text. Then the suite tells you which path broke – before you confuse a green front door with a ready farm.

FAQ

Why should login-storm automation differ from sustained-path automation?
Login storm stresses steep concurrent or repeated logons through the control plane (broker, profile, session spin-up, first useful desktop). Sustained-path automation holds a session and exercises multi-step business work on the glass. Mixing them into one brittle script hides which failure mode broke.

What does CitraTest on-the-glass automated testing measure?
CitraTest drives the real client GUI with mouse and keyboard, syncs with WaitForImage (prefer static bitmaps), optionally uses OCR for dynamic text, and captures StartTimer/StopTimer for on-screen moments of truth such as login-to-shell, published-app first paint, or key transaction ready.

Can OCR be used as a wait or sync in CitraTest scripts?
No. Confirm readiness with image functions first (WaitForImage, ClickOnImage). Prefer bitmaps for static UI cues; reserve OCR for dynamic text. OCR is not a wait/sync.

How does this automated-testing post differ from CitraTest VU load testing and CitraTest APM?
This article is about building CitraTest automated tests for control-plane login storm vs farm sustained path. CitraTest VU sizes those paths under concurrency. CitraTest APM schedules the same class of glass path as a continuous production watch. Same WaitForImage and timer contract; different operational question.

Do CitraTest agents need to run on production session hosts?
No. For the glass path, CitraTest plays back from Windows machines with access to the client path. Nothing invasive is required on production session hosts for on-the-glass automation.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Also published on the product site: publish-scenario-sla-citratest-apm-continuous-watch.aspx

How a glass-level script becomes scheduled monitoring with SLA limits on the steps users actually feel.

Direct answer: CitraTest APM® turns an on-the-glass scenario into a continuous watch by publishing the script to the APM Web Console, attaching it to a Scenario (schedule + groups + monitors), and scoring WaitForImage timer steps against SLA response-time limits. Playback uses real mouse and keyboard on Citrix, Microsoft RDS, Azure Virtual Desktop, browsers, and thick Windows clients – with no CitraTest agents on production session hosts for the glass path.

Host CPU looks calm. The gateway answered. The workbook is green. None of that proves that today’s login-to-shell, published-app first paint, or in-session transaction still lands on screen inside the SLA your shift agreed to.

A continuous watch answers a different question than a one-off lab run: is the end-user path still true under the limits we published? That is the operational lifecycle behind CitraTest APM – Publish → Scenario → SLA – described in the CitraTest Quick Start APM Web Console chapter and User Guide timer guidance.

What Publish → Scenario → SLA means

Building the script is necessary. Operations still needs a fleet path. In CitraTest APM the path is concrete:

Availability for summary reporting can track successful iterations (Monitor Required Availability) separately from response-time bands. Screenshots on failure give ops on-glass proof instead of another abstract counter. Failover agents can stand by when a primary is silent for an extended period; they still need Group/Scenario membership.

Illustrative fleet flow based on the Quick Start APM Web Console chapter – not customer results.

Build the glass scenario first

Before you publish, define success the way a user would recognize it. A practical APM scenario usually covers:

• Login-to-shell (or equivalent first useful desktop / client chrome)
• Published-app or thick-client first paint – the window or workspace that means work can start
• One or two key in-session steps – open chart, submit order, post invoice, run payroll step – whatever the shift cannot skip

Per User Guide / Quick Start measurement guidance:

1. Scripts encode the workflow on a Windows desktop.
2. Playback sees the UI with bitmap images (and OCR when text is dynamic).
3. Playback acts with real mouse and keyboard.
4. WaitForImage synchronizes and verifies expected screen state before the next step.
5. StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.

Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback machines so "image not found" failures are real application delays, not environment drift.

Illustrative method diagram – not customer results. That pipeline is the measurement contract inside every published monitor.

Turn the scenario into a continuous watch

Once the glass path is honest in interactive playback, publish it and attach operational shape:

• Schedule – how often the path must prove itself (shift cadence, overnight, or tighter intervals for critical transactions).
• Groups and monitors – which published script (and which timers) each agent runs.
• Playback endpoints – Windows machines running CitraTestAPMAgent with access to the real client path (Citrix Workspace, RDS/AVD client, thick client, browser).
• SLA limits – response-time bands per Monitor/Timer (up to four limits) that match what the business already treats as acceptable.
• Alerting – notify when a glass step breaches or iterations fail; use failure screenshots as the first evidence pack.

Operational hygiene keeps the watch trustworthy: restore a clean desktop between iterations, use script versioning for phased rollout (avoid assigning conflicting versions of the same script to one agent), and publish cleanup scripts as standalone monitors when leftover windows would poison the next run.

Illustrative method diagram – not customer results. Geo shapes are example scenario layouts, not benchmarks.

What to measure (without inventing numbers)

Name timers after moments of truth, not after protocol hop labels:

• First useful pixel / login-to-shell – when the desktop or client chrome is actually usable
• App or workspace ready – published app or thick client first paint
• Key transaction ready – the screen state that means the business step completed for the user

Set SLA bands from agreed operational limits – what the shift already treats as too slow – then let the watches report whether today’s path still meets them. Do not invent accuracy percentages or fictional ROI. The value of the watch is honesty: successive iterations either prove the glass path or surface the screenshot that shows where it stopped.

If you already sized concurrency with CitraTest VU, reuse the same visual definition of success in APM. VU answers "how many?" under load; APM answers "is it still true this hour?" Related: Director Watches Brokers. APM Watches the Screen., What is on-the-glass APM?, Advanced OCR for Automated Testing.

Closing: keep production honest on the glass

Publish → Scenario → SLA is how CitraTest APM becomes a continuous watch rather than a script that only runs when someone remembers. Encode the path with WaitForImage and timers, publish it, schedule it across playback endpoints, and score the steps users feel. Infrastructure metrics still matter for hosts and brokers – they do not replace a scheduled proof that the business screen appeared on time.

FAQ

What does Publish → Scenario → SLA mean in CitraTest APM?
Publish sends the script exe and images to the APM Web Console. A Scenario combines schedule, groups, and monitors so CitraTestAPMAgent playback machines run the glass path. SLA response-time limits score each Monitor/Timer against thresholds you define.

How should timers be placed in an APM glass scenario?
Place StartTimer immediately after the initiating action. Confirm readiness with WaitForImage (prefer static bitmaps for sync). Place StopTimer after that wait succeeds. OCR may read or assert dynamic text afterward; OCR is not a wait/sync.

What should a continuous APM watch measure?
Time moments of truth on the glass: login-to-shell or first useful pixel, published-app first paint, and the key in-session transactions your shift depends on. Score those timers against SLA limits; availability can be tracked separately via successful iterations.

Do CitraTest APM agents run on production session hosts?
No. For the glass path, CitraTestAPMAgent runs on playback machines with Windows access to the client path. No CitraTest agents are required on production session hosts.

How does APM relate to CitraTest VU for the same path?
VU can size the path under concurrency in the lab. APM watches the same glass definition of success on a schedule against production SLAs. Same WaitForImage and timer contract; different operational question.

When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.

Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.

Moving the broker to a cloud control plane does not turn a virtual desktop into a website. Citrix DaaS, cloud-hosted Citrix Virtual Apps and Desktops, Azure Virtual Desktop (AVD), and Windows 365 still deliver a session: HDX or RDP paints pixels, and the work happens on a session host in a resource location. Finance will still ask how many concurrent users that host SKU can carry. Autoscale is not the answer to that question.

This is a 2026 method for EUC and VDI admins sizing cloud session hosts and DaaS catalogs. A website test of the Workspace URL is not a farm test.

HDX and RDP still deliver pixels

A Workspace URL test is not a farm test.

The cloud did not change the protocol contract. Citrix Workspace, the AVD web client, and the Windows 365 portal are web applications. The session that follows is not. HDX — the current name for the ICA family — and RDP send a bitmap. There is no DOM and no REST payload that means “the chart appeared.”

If you only load-test the Workspace or RD Web URL, you have exercised the front door and the identity hop. You have not exercised the VDA, the session host, FSLogix, GPO, or the published application. The events users wait on — logon, shell, first paint of the app — exist on the glass. Treat HDX and RDP as remoting protocols with a human on the other end, not as another API to replay.

Control plane is not the resource location

In Citrix DaaS the control plane lives in Citrix Cloud. Session hosts live in a resource location: Azure, AWS, Google Cloud, or a remaining on-premises datacenter. Cloud Connectors (or Connector Appliances) are the bridge. They sit in the path for VDA registration, brokering, and many hybrid identity designs. They are not the farm.

AVD has the same split: Microsoft’s control plane versus your host pools and session hosts. Windows 365 Cloud PCs are one user per PC, but the path still includes the gateway, the Cloud PC SKU, profiles, and the app. A green control-plane dashboard means the broker answered. It does not mean forty task workers on a D4s_v5 multi-session host can open the line-of-business app in eight seconds.

Pin the path in the test record: client version, Cloud Connector count, region, host SKU, image hash, profile storage, Gateway or RDP Shortpath, and MFA. Skip the Connector because “it is just a proxy” and you will be surprised on go-live morning.

Autoscale and bursting hide density problems

Cloud catalogs are built to grow. Citrix Autoscale, AVD scaling plans, and similar bursting add session hosts when concurrency rises. That is useful in production. It is a trap in a capacity test. If the pool scales out as you ramp, you can “pass” 400 users while each host is actually miserable at 25. You learned that the subscription can provision VMs. You did not learn sessions-per-host on that SKU — the number that sets max sessions, buffer capacity, and the monthly compute bill.

Run density with autoscale off, or with a fixed host count, until the experience budget breaks on that SKU. Run a second test with autoscale on to measure scale-out lag and cold-boot time. Bursting can also hide a saturated profile share, a slow Cloud Connector, or a GPO that only hurts when twenty logons hit one host at once — until the region is out of quota at 8 a.m.

What a defensible cloud number actually is

A defensible number is not “the catalog launched N sessions before the cloud returned a quota error.” It is the highest concurrency at which defined user transactions still meet a defined experience budget, on a named host SKU and image, with autoscale behavior written down separately. Write the acceptance line before the first ramp:

• Logon to a usable desktop: 45 seconds at p95, 60 seconds at p99.
• Launch the published line-of-business app, search, open the record: 8 seconds at p95.
• Fewer than 1% of sessions fail, disconnect, or hang during the sustain.
• Per-host CPU, memory, and profile IOPS stay inside production alert bands — on that SKU, not averaged across a bursting pool.
• If autoscale is in scope: a new host is ready and taking sessions inside a written budget (for example, six minutes from power-on to first successful logon).

When the run crosses that line, that concurrency per host is the number. ICA RTT, RDP round-trip, and a green Monitor or Azure workbook are useful. They are not “the chart appeared.”

Measure from the user’s screen

On HDX and RDP there are no client-side objects to bind to. The practical way to know a step finished is to watch the screen: image recognition and OCR against a baseline of what “done” looks like. Time the interval from the click or key until that image or text is visible.

GUI-level tools exist for this. CitraTest VU, for example, drives the real Workspace, AVD, or Remote Desktop client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the VDAs or session hosts.

Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 28 users per host, you want host CPU, Cloud Connector health, and profile IOPS on the same timeline. The screen tells you it broke. The control plane and the resource location tell you which layer. Put generators where they represent a real site. If generator CPU is pegged, you are measuring the lab, not the catalog.

Login storm versus sustain

A login storm — two hundred users authenticating in two minutes — is a real cloud event: shift start, failback, or Autoscale powering a cold pool. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, Cloud Connector and Workspace or Gateway CPU, broker latency, the profile store, and time waiting for hosts to boot. Steady state: slower ramp to target on a fixed host count, then a sustain long enough for memory growth, CPU ready time, profile I/O, and session reliability to show up. Thirty minutes is a demo. Two hours is closer to a shift.

If you only storm, you will size logon infrastructure and under-size the session hosts. If you only sustain, you will miss 8 a.m. If you only storm with autoscale on, you will size the cloud’s ability to boot VMs and still not know density.

A seven-step method you can take to a CAB

1. Freeze the catalog, the SKU, and the autoscale policy. Record host SKU, image hash, client, Cloud Connector count, Gateway or RDP path, profile solution, and whether Autoscale is on. Change any of those mid-test and start over.
2. Walk the path users actually take. Workspace, Gateway, or the AVD / Windows 365 front door, then Entra ID or Active Directory plus MFA, then launch, remoting session, profile and GPO, then the app. A Citrix result does not transfer to AVD. Rebuild the connection for each stack.
3. Script the business day, not only a login. Logon is mandatory. It is not the workload. Script five to ten real-hour transactions: launch, search, open, save, print, idle. Put think time in.
4. Take a single-user baseline, then a handful on one host. If one user already takes 40 seconds to a usable desktop, you have an image, profile, GPO, or Connector problem. Fix that before you add concurrency.
5. Measure density with autoscale off; measure scale-out with it on; run the login storm as its own test. Do not fold all three into one ramp. The last density step that still passed is sessions per host — the number you take to the business.
6. Watch the tail, the failures, and the scale-out lag. Report p95 and p99, plus fail, retry, disconnect, and “waited for a host” counts. Means hide the damage.
7. Re-test when the catalog, SKU, image, Connector, region, or autoscale schedule changes. Last quarter’s on-prem number does not travel with the catalog.

FAQ

Can we web-test the Workspace URL and call it a cloud VDI load test?

You can load-test Workspace, StoreFront, or the AVD web client that way. You cannot size session hosts, HDX or RDP, profiles, Cloud Connectors, or the published application that way. The URL belongs in the path. It is not the farm.

Does autoscale mean we can skip density testing?

No. Autoscale answers “can the pool grow.” Density answers “how many good sessions fit on one host.” You need both. Skip density and you will overpay for compute or discover the limit when the region will not give you another VM.

Do AVD, Windows 365, and Citrix DaaS share a concurrency figure?

No. Reuse the transactions and the budgets. Rebuild the connection for each stack. A Citrix DaaS figure is not an AVD host-pool figure, and Windows 365 is one Cloud PC per user — test the SKU and the logon path, not multi-session density.

Take the number the bill and the users can both survive

A cloud VDI load test that a CAB will accept has five traits: it walks the real Workspace, Gateway, or AVD path; it drives HDX or RDP from a real client; it measures density with autoscale off and scale-out with autoscale on; it ramps and then sustains, with a separate login-storm run; and it stops at a pre-written experience budget measured on the user’s screen.

When you need that GUI-level path — real client, image and OCR, no agents on the session hosts — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing.

Capacity conversations about Citrix still die in the same place: a vendor density spreadsheet on one side, last quarter’s peak from Director on the other, and no one who can say what the user actually saw on the glass. Finance and the CAB want a concurrent-user number they can defend. That number does not come from HTTP replay, and it does not come from a single login-storm screenshot.

This is a method for Citrix and VDI admins and QA who have to produce that number in 2026 — for Citrix DaaS, for Citrix Virtual Apps and Desktops, and for shops that also run Azure Virtual Desktop (AVD) or Windows RDS and need the same kind of answer. Citrix Virtual Apps and Desktops is the current name for the on-premises and hybrid platform many teams still remember as XenApp and XenDesktop.

HDX is not HTTP

Most load-testing practice grew up on websites. You record HTTP, correlate cookies, replay thousands of threads, and graph page time. That model does not describe a Citrix session.

If you only hammer StoreFront with a web generator, you have load-tested the store, not the farm.

StoreFront is a web application. Citrix Gateway is a web and SSL-VPN front door. The session that follows is HDX — the current name for the ICA protocol family. The published app or desktop does not send DOM or window handles to the endpoint. It sends pixels. The client sends keyboard and mouse.

A synthetic ICA stream that never paints a real Workspace app window can miss the events users wait on: the logon animation, the shell, the first paint of Epic or SAP, the modal after a click. Those events exist on the bitmap. Treat HDX as a remoting protocol with a human on the other end, not as another API to replay.

What a defensible concurrent-user number actually is

A defensible number is not the highest session count you can boot before the broker returns errors. It is the highest concurrency at which a defined set of user transactions still meets a defined experience budget, with a defined failure rate, on the image and hardware you intend to ship. Write the acceptance line before the first ramp:

• Logon to a usable desktop: 45 seconds at p95, 60 seconds at p99.
• Launch the published line-of-business app, search, open the record: 8 seconds at p95.
• Fewer than 1% of sessions fail, disconnect, or hang during the sustain.
• Session-host CPU, memory, and profile IOPS stay inside the same alert bands you already use in production.

When the run crosses that line, that concurrency is the number. Averages, “it still launched,” and a green Director dashboard are not. ICA RTT is useful. It is not the same as “the chart appeared.”

Test the path users actually take

Users do not appear already inside an HDX session. They hit StoreFront (internal) or Gateway (external and most hybrid designs), then authentication — Active Directory, MFA, SAML, FAS, or a mix — then store enumeration, resource launch, HDX to the VDA, profile and GPO processing (FSLogix or equivalent), and only then the business application.

Skip Gateway in the lab because “it is just a proxy” and you will be surprised on go-live morning. Skip MFA because the tool cannot type an OTP and you have tested a path nobody uses. If production is Gateway plus SAML plus a published desktop, that is the script.

Pin VDA version, Citrix Workspace app version, StoreFront and Gateway builds, GPO, profile solution, and the published resource. A load test of a moving image is a story, not a measurement. AVD and RDS have their own brokers and gateways; a Citrix result does not transfer. Reuse the transactions and budgets, and rebuild the connection script for each stack if you are comparing platforms.

Measure from the user’s screen

On HDX there are no client-side objects to bind to. The practical way to know a step finished is to watch the screen: image recognition and OCR against a baseline of what “done” looks like. Time the interval from the click or key until that image or text is visible.

GUI-level tools exist for this. CitraTest VU, for example, drives the real Citrix client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the VDAs or brokers. Protocol replay and in-guest workload agents scale on cheaper generators, but they are not a substitute for “did the chart actually appear.”

Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 280 users, you want host CPU, logon duration, and profile IOPS on the same timeline. The screen tells you it broke. The infrastructure tells you which layer.

In-guest agents that burn CPU and disk are a legitimate way to study raw host density. They are not how a nurse uses an EHR, and they can perturb the thing you are measuring. A client-side, image-and-OCR approach leaves the farm alone: each virtual user is a real Workspace app session from a generator desktop. You pay in generator hardware — those VMs must not become the bottleneck — and you gain fidelity. If generator CPU is pegged, you are measuring the lab, not the farm.

A seven-step method you can take to a CAB

1. Freeze the image and the client. Record the catalog, machine profile, VDA, Workspace app, StoreFront, Gateway, and Windows image hash. If you change any of those mid-test, start over. Capacity is always “on this build.”
2. Script the business day, not only a login. Logon is mandatory. It is not the workload. Script the five to ten transactions that represent a real hour for the actual population: launch, search, open, save, print, switch published apps, idle. Put think time in. Do not test a knowledge-worker desktop if 80% of sessions are task workers on one published app.
3. Take a single-user baseline, then a handful. One session, then five, on the same script. If one user already takes 40 seconds to a usable desktop, you do not have a capacity problem. You have an image, profile, or GPO problem. Fix that before you add concurrency.
4. Ramp, then sustain — and run a login storm as its own test. A login storm — two hundred users authenticating in two minutes — is a real event: shift start, a DR test, Monday at 8:00. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, broker and StoreFront or Gateway CPU, and the profile store. That is how you find the morning outage. Steady state: slower ramp to target, then a sustain long enough for memory growth, CPU ready time, profile I/O, and session reliability to show up. Thirty minutes is a demo. Two hours is closer to a shift. If you only storm, you will size the logon infrastructure and under-size the session hosts. If you only sustain, you will miss 8 a.m.
5. Watch the tail and the failures. Means hide the damage. Report p95 and p99 for every transaction, plus fail, retry, and disconnect counts. One stuck GPO or one saturated CIFS share will not move the average until the service desk is already taking calls.
6. Stop at the acceptance line. Add concurrency in steps — 25 or 50 users is typical — until a transaction budget or a reliability budget is breached. The last step that still passed is the number you take to the business. Write down hardware, image, client version, script name, and the exact pass/fail table. Launch without a usable desktop is not capacity. It is a queue.
7. Re-test when density-changing things change. New VDA, new Workspace app, Windows feature update, FSLogix policy, an extra published app, a move from on-prem Virtual Apps and Desktops to Citrix DaaS, a Gateway or MFA change. Capacity is not a one-time project.

FAQ

Can we web-test StoreFront and call it a Citrix load test?

You can load-test StoreFront that way. You cannot size VDAs, HDX, profiles, or the published application that way. StoreFront and Gateway belong in the path. They are not the path.

How is Citrix DaaS different from on-prem Virtual Apps and Desktops for this?

The user path is the same idea: Workspace or Gateway, HDX, VDA, app. Cloud connectors and the shared control plane are extra moving parts. Include them. Do not assume a density number from the old resource location still holds after you move the catalog.

What about AVD and RDS in the same environment?

Reuse the transactions and the budgets. Rebuild the connection for each protocol. A Citrix concurrency figure is not an RDS or AVD figure.

When is protocol-level ICA replay enough?

For a quick broker or Gateway soak, sometimes. For a number you will print on a capacity plan and live with at 8 a.m., measure the screen.

Take the number you can stand behind

A Citrix load test that a CAB will accept has four traits: it walks the real StoreFront or Gateway path, it drives HDX from a real client, it ramps and then sustains (with a separate login-storm run), and it stops at a pre-written experience budget measured on the user’s screen.

When you need that GUI-level path — real client, image and OCR, no agents on the Citrix servers — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing.

This post is about load testing Microsoft Remote Desktop Services on Windows Server — concurrent RDP sessions on Remote Desktop Session Hosts — not Amazon RDS, the Relational Database Service. Search engines treat “RDS load testing” as a database topic. If you are here to soak a SQL instance, stop. If you need a concurrent-user number for Windows Server RDS that a CAB will accept, keep reading.

This is a 2026 method for VDI and RDS admins and QA. The stack is Windows Server Remote Desktop Services, Remote Desktop Session Host (RDSH) collections, RD Gateway, RD Web Access, and the real Remote Desktop client. Azure Virtual Desktop (AVD) is a cousin: same RDP family, different control plane. An AVD density figure is not an on-prem RDS figure.

RDP is not HTTP

Most load-testing practice grew up on websites. You record HTTP, replay thousands of threads, and graph page time. That model does not describe a Remote Desktop session.

Hammer RD Web Access with a web generator and you have load-tested the portal, not the session hosts.

RD Web Access is a web application. RD Gateway is an HTTPS front door that wraps RDP. The session that follows is Remote Desktop Protocol. The published desktop or RemoteApp does not send DOM or window handles to the endpoint. It sends pixels. The client sends keyboard and mouse.

A synthetic RDP stream that never paints a real Remote Desktop client window misses the events users wait on: the logon animation, the shell, the first paint of Epic or a line-of-business RemoteApp, the modal after a click. Those events exist on the bitmap. Treat RDP as a remoting protocol with a human on the other end, not as another API to replay.

What a defensible concurrent-user number actually is

A defensible number is not the highest session count you can boot before the Connection Broker returns errors. It is the highest concurrency at which a defined set of user transactions still meets a defined experience budget, with a defined failure rate, on the image and hardware you intend to ship. Write the acceptance line before the first ramp:

• Logon to a usable desktop: 45 seconds at p95, 60 seconds at p99.
• Launch the RemoteApp or in-session line-of-business app, search, open the record: 8 seconds at p95.
• Fewer than 1% of sessions fail, disconnect, or hang during the sustain.
• Session-host CPU, memory, and profile IOPS stay inside the same alert bands you already use in production.

When the run crosses that line, that concurrency is the number. Averages, “it still launched,” and a green RDSH CPU chart are not. RDP round-trip time is useful. It is not the same as “the chart appeared.”

Test the path users actually take

Users do not appear already inside an RDP session. They hit RD Web Access (internal) or RD Gateway (external and most hybrid designs), then authentication — Active Directory, MFA, smart card, or a mix — then collection enumeration, resource launch, RDP to the Remote Desktop Session Host, profile and GPO processing (FSLogix or a roaming profile), and only then the business application.

Skip RD Gateway in the lab because “it is just a proxy” and you will be surprised on go-live morning. Skip MFA because the tool cannot type an OTP and you have tested a path nobody uses. If production is Gateway plus MFA plus a published desktop collection, that is the script.

Pin Windows Server version, RDSH image, RDP client version, Connection Broker and Gateway builds, GPO, profile solution, and the published resource. A load test of a moving image is a story, not a measurement. AVD and Citrix have their own brokers and gateways; an RDS result does not transfer. Reuse the transactions and budgets; rebuild the connection script if you are comparing platforms.

Measure from the user’s screen

On RDP there are no client-side objects to bind to. The practical way to know a step finished is to watch the screen: image recognition and OCR against a baseline of what “done” looks like. Time the interval from the click or key until that image or text is visible.

GUI-level tools exist for this. CitraTest VU, for example, drives the real Remote Desktop client with keyboard and mouse, compares the live screen to baseline images, and does not install agents on the session hosts, the Connection Broker, or RD Gateway. Protocol replay and in-guest workload agents scale on cheaper generators, but they are not a substitute for “did the chart actually appear.”

Correlate the two views. When p95 “open chart” jumps from 6 seconds to 14 seconds at 180 users, you want RDSH CPU, logon duration, and profile IOPS on the same timeline. The screen tells you it broke. The infrastructure tells you which layer. If generator CPU is pegged, you are measuring the lab, not the session hosts.

FSLogix and profiles deserve their own watch. A session host that looks fine at 80 users can fall over at 81 if the profile store cannot keep up with concurrent logons. Measure container attach time, profile IOPS, and the delay from credentials accepted to a usable shell. That interval is often the real login-storm bottleneck, not RDSH CPU.

A seven-step method you can take to a CAB

1. Freeze the image and the client. Record the collection, machine profile, Windows Server build, RDP client, RD Web Access, RD Gateway, Connection Broker, and image hash. If you change any of those mid-test, start over. Capacity is always “on this build.”
2. Script the business day, not only a login. Logon is mandatory. It is not the workload. Script the five to ten transactions that represent a real hour: launch, search, open, save, print, switch RemoteApps, idle. Put think time in. Do not test a knowledge-worker desktop if most sessions are task workers on one RemoteApp.
3. Take a single-user baseline, then a handful. One session, then five, on the same script. If one user already takes 40 seconds to a usable desktop, you do not have a capacity problem. You have an image, profile, or GPO problem. Fix that before you add concurrency.
4. Ramp, then sustain — and run a login storm as its own test. A login storm — two hundred users authenticating in two minutes — is a real event: shift start, a DR test, Monday at 8:00. It is not the same as two hundred users already in session doing work. Run both shapes. Storm: steep ramp; measure logon time, Connection Broker and RD Gateway CPU, and the profile store. Steady state: slower ramp to target, then a sustain long enough for memory growth, CPU ready time, profile I/O, and session reliability to show up. Thirty minutes is a demo. Two hours is closer to a shift. If you only storm, you will size the logon path and under-size the session hosts. If you only sustain, you will miss 8 a.m.
5. Watch the tail and the failures. Means hide the damage. Report p95 and p99 for every transaction, plus fail, retry, and disconnect counts. One stuck GPO or one saturated CIFS share will not move the average until the service desk is already taking calls.
6. Stop at the acceptance line. Add concurrency in steps — 25 or 50 users is typical — until a transaction budget or a reliability budget is breached. The last step that still passed is the number you take to the business. Write down hardware, image, client version, script name, and the exact pass/fail table.
7. Re-test when density-changing things change. New Windows Server feature update, new RDP client, FSLogix policy, an extra RemoteApp, different RDSH hardware, an RD Gateway or MFA change, a move from on-prem RDS to Azure Virtual Desktop. Capacity is not a one-time project.

FAQ

Can we web-test RD Web Access and call it an RDS load test?

You can load-test the portal that way. You cannot size session hosts, RDP, profiles, or the published application that way. RD Web Access and RD Gateway belong in the path. They are not the path.

How is Azure Virtual Desktop different from Windows Server RDS for this?

AVD is a cousin, not the same stack. Users still get an RDP session, but the broker, gateway, and host pool live in Azure. Do not assume an on-prem RDSH density number still holds after you move the workload. Rebuild the connection script; reuse the transactions and the budgets.

What about Citrix in the same environment?

Reuse the transactions and the budgets. Rebuild the connection for each protocol. An RDS concurrency figure is not a Citrix or AVD figure.

When is protocol-level RDP replay enough?

For a quick Connection Broker or RD Gateway soak, sometimes. For a number you will print on a capacity plan and live with at 8 a.m., measure the screen.

Take the number you can stand behind

A Microsoft RDS load test that a CAB will accept has four traits: it walks the real RD Web Access or RD Gateway path, it drives RDP from a real client, it ramps and then sustains (with a separate login-storm run), and it stops at a pre-written experience budget measured on the user’s screen.

When you need that GUI-level path — real Remote Desktop client, image and OCR, no agents on the session hosts — Tevron’s CitraTest VU is built for the job. See CitraTest VU load testing and Tevron’s notes on RDP load testing.