Sessions

A session is the binding between a user and a specific desktop VM, from the moment they request one until it's released. This page covers how that binding is created and ends, what state it moves through along the way, how users actually reach the desktop, and the controls you have as an administrator on the Sessions page.

How a user gets a desktop

A user needs an entitlement to a pool before they can request a desktop from it — owning capacity isn't the same as being allowed to use it. Once entitled, a user (from the user portal) or an administrator (from Sessions → Request desktop) requests a desktop from a pool:

• If a ready VM is free, it's claimed immediately and the session starts assigned.
• If none is free, the session stays requested ("Pending") until reconciliation fulfills it — a free VM appears, or a new one finishes provisioning.

What VM a user gets back depends on the pool's type: a Persistent pool gives the same user the same VM on every subsequent request; a Non-Persistent or Ephemeral pool hands out a different VM each time and recycles the one that was released.

Session states

The State column on the Sessions page (and the state shown in a session's detail timeline) is one of:

State	Shown as	Meaning
requested	Pending	Accepted, but no VM is bound yet.
assigned	Assigned	A ready VM is bound, but no one has logged into it yet.
active	Active	The bound user is observed logged on inside the guest.
disconnected	Disconnected	The user was active but is no longer connected — still logged on, just not connected (the classic "RDP disconnected" state).
ended	Ended	Terminal. The VM has been released per the pool's type.
failed	Failed	Terminal error, for example the bound VM disappeared.

A session normally moves requested → assigned → active, can flip between active and disconnected any number of times as the user reconnects, and finally reaches ended.

Browser access vs. native RDP

Which connection options a pool offers depends on its Connection methods setting (see Desktop pools). A ready session can offer either or both, and the user chooses:

• Connect in browser — a full desktop directly in a browser tab, no client install. Available when the pool's connection methods include browser RDP or VNC (Guacamole). The connection is opened with a one-time, short-lived token; the user's browser never sees the desktop's hostname, username, or password.
• Download .rdp — a generated .rdp connection file for a native RDP client. Available when the pool allows Direct RDP (same LAN) or RDP via RD Gateway (from outside the LAN, when the cluster has a gateway configured). The username is pre-filled as a hint; the client always prompts for the password, which Planeon never stores or forwards.

While a desktop is still provisioning, the user portal shows Preparing your desktop…; once a VM is bound and reachable it shows Ready to connect; while connected it shows In use; and after a disconnect it shows Disconnected — reconnect to resume.

Admin actions

The Sessions page lists every session (User, VM, Pool, State, Duration, Started) and lets you:

• Request desktop — broker a desktop from a pool to a user on their behalf.
• View details — open a session's detail panel, including its full event timeline.
• Connect in browser / Download .rdp — open a live session the same way the user would.
• Force disconnect — disconnect the user's live guest session over the guest agent. The user stays logged in and can reconnect.
• Force logoff — log the user out of the guest session over the guest agent. Unsaved work in that guest session is lost.
• End & release — end the session outright and release the VM per the pool's type (kept for the user if the pool is persistent, recycled otherwise).

Every one of these prompts for confirmation before it runs.

Idle and disconnect behavior

Each pool can optionally set automatic session limits under Session timeouts (see Desktop pools): Maximum session duration, Idle timeout, and Disconnected timeout. Each is independent, and each is off by default — a pool with no timeouts configured never ends a session automatically.

• Maximum session duration ends the session this long after it starts, regardless of activity.
• Idle timeout ends the session after this much inactivity — covering both "assigned but the user never connected" and "was active, then stopped being observed as connected."
• Disconnected timeout ends the session this long after the user disconnects without logging off — the classic "left it disconnected" cleanup.

Beyond ending a session outright, users have two self-service resets from the portal: Restart reboots their current desktop in place and is always available, for every pool type. Fresh desktop ends the current session and requests a new one, handing the user a different VM — available only for Non-Persistent and Ephemeral pools, since a Persistent pool's desktop keeps the user's data and offers only Restart.