Release LoadGen Api, Appliance and MCP Server: 1.0.0.12240
Release LoadGen Api, Appliance and MCP Server: 1.0.0.12240
LoadGen General
No general changes in this release.
LoadGen Api
[#9400], [#9397] Fixed VMware Horizon and AVD (WVD) load tests never actually generating load — sessions could sit at "ramping up… Agents (0 slots)" and time out because the in-session handshake was incomplete and the agents' dial-back was rejected. The platform now spawns a launcher session per user and completes the in-session handshake, so each session receives its workload and reports results; a run that still can't get sessions to connect now fails with a diagnosis of which step broke instead of hanging.
[#9423] Added a pre-flight check when starting a VMware Horizon / AVD / Citrix test: if the Launcher Appliance's Windows guest doesn't have the required client installed (for example the Horizon Client), Run Test now warns before starting instead of letting the run fail minutes later at the session-connect timeout.
[#9476]Remote agent and Insight installs now work from a Linux-hosted platform. Pushing a Core Agent, Full Agent or Insight install to a Windows machine over WinRM previously failed with an opaque "no supported WSMan client library" error; the platform now speaks WinRM directly. A push that still can't connect returns the exact enablement steps for the target machine.
[#9478] The Insight Data Health page now works — it previously showed "Data Health monitoring coming soon". It now reports, per machine and per feature, when each was last collected, and surfaces registered agents that have gone quiet.
[#9471] Fixed collecting applications from a Citrix StoreFront / PNAgent over plain http returning zero applications while reporting success. Enumeration over http now works; a missing CSRF token or a non-200 response is reported with an actionable message; and StoreFront URLs ending in config.xml plus all documented auth-method aliases are now accepted.
[#9482] Service-level business-hours policies now validate the time zone on save (rejecting an unresolvable value) and store it in a canonical form, so an objective's compliance calculation can no longer be silently thrown off by a bad or ambiguous zone. A new audit reports any already-stored zones that don't resolve.
[#9441], [#9444] Fixed a local InfluxDB datasource showing Unreachable with an empty reason, and the same condition logging an error every minute. The result now states the real cause (no response, or the server answered but a query timed out), and expected connectivity failures are logged less noisily.
[#9427], [#9428] Fixed deleting a Launcher Appliance leaving orphaned entries in Credential Profiles → Platform Tokens (a stale appliance key and a Windows Run-As profile) with no way to remove them. Deleting an appliance now cleans them up, a startup sweep collects any already-stranded entries, and such an orphan can now be deleted manually.
SessionSight — per-tenant access control. SessionSight access can now be restricted per user to specific tenants, enforced on every read path (sessions, visitors, heatmaps, identity profiles and replay). A user with no restriction assigned still sees all tenants — assign tenants to confine someone. This is managed on the Master API.
SessionSight — reliability and performance. A wave of fixes to the SessionSight data pipeline on busy or memory-constrained appliances: the analytics rollup no longer stalls or recycles healthy workers, raw events are no longer rejected on write (which had left dashboards empty), replay opens quickly and supports a live tail, reads no longer misparse values containing commas or exhaust memory on large ranges, and a brief worker restart no longer risks losing spooled recordings. Recording history is also mirrored to disk so it survives a datastore reset.
[#9437] Fixed opening a SessionSight replay timing out ("exceeded the 25s server budget") even on small containers; a replay now queries only the session's own time window.
[#9399] Added diagnostics to pinpoint a remaining case where a per-user Agent re-pin in a load profile can revert on reopen; a fix follows once the exact cause is confirmed.
LoadGen Appliance
[#9469] The Updates tab is rebuilt into a consistent tile layout that shows, per component, whether the appliance is current, behind, or can't be determined, and lets you move the whole appliance to a validated release set in one action (with a server-computed pre-flight of exactly what will change). The .NET runtime and Appliance Agent builds are now selectable rather than free-text.
[#9430] The Update Center's Appliance Agent build is now a dropdown of available builds, like the other components, instead of a free-text field where a mistyped build failed only at push time; air-gapped platforms can upload a build.
[#9431] Fixed Update OS packages reporting "Appliance agent call timed out" and failed when the update was in fact running. The action now returns promptly, and if a start does time out the page resumes tracking the update that is genuinely in progress.
Appliance memory tuning — InfluxDB no longer flapping "Unreachable". On smaller appliances InfluxDB could be killed by the host under memory pressure roughly hourly, surfacing as Influx datasources repeatedly going Unreachable. The appliance now gives InfluxDB a larger, bounded memory budget and caps its internal usage so it applies back-pressure instead of being killed. Existing appliances converge on the next agent restart (which recreates the affected containers once).
[#9442] Fixed the monitoring stack (InfluxDB / Grafana) not starting after a reboot in a case where monitoring had been disabled for one service while the other was momentarily down. The appliance now decides from configured intent and self-heals the monitoring stack on start.
[#9446] Fixed a freshly deployed appliance's boot console showing fwupd and Hyper-V (hv-kvp) service failures — one of which also cost about 90 seconds of boot time on non-Hyper-V hypervisors. These are now masked or gated to the hypervisor that needs them; appliances already in the field converge on the next boot.
LoadGen Launcher Appliance
[#9439] You can now resize an existing Windows guest's RAM, CPU and disk in place — previously the only route to more capacity was to destroy and rebuild the guest, losing the Windows install and everything configured in it. The resize preserves the install and product key, validates the request against the host's available resources (blocking with the shortfall named rather than silently clamping), and grows the guest's C: drive when the disk is enlarged.
[#9445] Fixed changing a Windows guest's password via Guest identity & credentials breaking auto-logon and the Logon / Unlock session actions (the guest stopped at the login screen). The guest's auto-logon credential is now updated together with the account password.
[#9302] Fixed Windows guest KMS activation reporting a failed edition conversion that had in fact succeeded (requiring a manual reboot and a second Activate). The evaluation → licensed edition conversion, reboot and activation now run as three clear sequential steps and complete in a single Activate.
[#9426] The appliance OVF deployment now includes a VMware installer script with a Core-only vs Core + Full Agent (Windows VM) preset, so an appliance that will host a Windows guest is sized correctly (CPU, memory, disk and nested virtualization) up front instead of needing three settings corrected after the fact.
[#9425] Clarified the wording of the remote-enrollment pre-flight message shown when an appliance is already claimed or its image predates remote enrollment.