Thin clients and virtual desktops

In Manage → Agents → Add an agent, select the device OS and architecture, then choose Thin client / virtual desktop under Deployment preset. This uses the normal agent with a smaller initial workload.

Choose the gateway and baseline

Optionally enter a gateway as desktop.example.com:443, 192.0.2.10:3389 or [2001:db8::10]:443. Enter a host and port, not a URL, and choose the actual service port used by your deployment.

The preset configures host metrics every 60 seconds, including the top five processes, and a TCP connection check when a gateway is supplied. A hostname also gets a system-resolver DNS check using the A-query default; edit it for AAAA when appropriate. IP literals do not get a DNS check. Agent health and local network context remain enabled.

Local ceilings are five probes/second, two concurrent checks and a 32 MiB telemetry spool. This spool limit excludes binaries, plugins, credentials, configuration caches and logs. These settings are not CPU/RAM guarantees; validate on the lowest-spec endpoint before rolling out.

Custom scripts remain opt-in. JavaScript uses the bundled engine; native interpreters require their runtimes on the device. TCP connection timing does not measure session responsiveness, render latency or frame rate. This preset does not include a separate VDI protocol collector.

Manage the lifecycle

Supported starter checks become ordinary, directly assigned tests after the agent reports its capabilities. Edit the actual test to change cadence or target. Changing the gateway label does not overwrite existing tests, and removing the deployment profile does not delete already-created checks.

Use a separate identity for each endpoint and virtual desktop. Never clone an enrolled credential or used one-time pack into a golden image. Follow ephemeral agent guidance for cloned desktops, and keep identity and spool files on writable storage that survives reboot.

For VDI host coverage, assign checks to the clones using their pool label; pool creation does not create a network scope. The physical endpoint needs its own agent for endpoint-side test results. Automatic session matching compares its inventory name (normally the hostname) with the Windows session’s reported client name, not with its pool label. See the pool targeting and matching guide for exact selectors, separate history-reporting setup, and the limits of inferred matching.

IGEL OS 12 and Dell ThinOS 10

When a Linux amd64 runtime is published, the platform selector offers x86_64 deployment kits for these systems. These are inputs to vendor signing workflows, not signed or certified applications. Browser and native-interpreter options are unavailable; optional JavaScript extensions are supported.

Follow the generated README to build and sign the IGEL recipe in App Creator for UMS deployment, or the ThinOS Debian package in Dell App Builder for WMS/APT deployment. Upload only publishable/ contents. The separate device-only/ folder contains private one-time enrollment material and must never be included in a fleet app or sent for vendor signing.

Reuse the signed app with a unique bootstrap for each device. Bootstraps expire after 24 hours, so get a fresh kit when signing takes longer. Preserve the vendor-approved state directory across upgrades. ThinOS Isolated Mode reports application-environment metrics, not verified physical-host measurements; also verify which network namespace is visible.

Physical-device validation and vendor signing remain deployment prerequisites. ChromeOS, zero clients, ThinOS 9 and arbitrary embedded operating systems are outside this preset’s supported kit scope.