|Manuals

Connect to an Instance

This article describes the end-user experience when connecting to a Cloud Manager-backed instance through Thinfinity® Workspace. It covers the connection flow, what to expect at each step, and how to recognize the difference between a successful connection and a recoverable wait state.

For administrator setup, see Create an Access Profile for Managed VMs or Create an Access Profile for a VDI/DaaS Model.

Prerequisites for the End User

  • A valid Thinfinity Workspace account with at least one Access Profile that targets a Cloud Manager source.
  • A supported web browser (for the HTML5 client) or the Thinfinity Workspace native (desktop) client installed.
  • Network connectivity to the Workspace broker URL.

The Connection Flow

When a user clicks an Access Profile in Thinfinity Workspace, the following sequence occurs from their point of view:

  1. Profile Click — The user opens Thinfinity Workspace, locates the Access Profile, and clicks it.

  2. Instance Lookup — A loading indicator appears while the broker locates the target VM:

    • Managed VM Access Profile — checks the named VM is available.
    • VDI/DaaS Access Profile — finds an assigned, standby, or new instance to provision.

    For VDI/DaaS Access Profiles where on-demand provisioning is configured and no instance is available, this step may take longer (several minutes) while a new instance is provisioned.

  3. Power-On (If Needed) — If the target instance is powered off, Cloud Manager powers it on. This typically adds 30 seconds to a few minutes of wait time, depending on the cloud provider and OS boot time.

  4. Session Establishment — Workspace establishes the session via the configured Connection Mode (Public IP, Private IP, or Agent Id). The user is presented with the standard connection prompts (credentials) as per the Thinfinity Workspace deployment.

  5. Desktop or Application Delivery — The remote desktop or application is delivered to the user’s browser or native client.

Info

During step 3, users connecting to a powered-off instance see a “Starting your environment…” or similar message. This is normal behavior — the instance is being prepared. The wait time can be reduced by configuring Lazy Instances in the model’s Provisioning and Pooling Options.

If the Access Profile Requires a Booking

If the Access Profile is configured with Resource Reservation, the click-to-connect gesture is the same — the user clicks the profile tile — but access is granted only when a current booking exists for that profile.

The booking may have been made by the user themselves or by another user on their behalf. Depending on how the profile’s booking permissions are configured, the booking may also need approval from a user authorized to approve requests before access is granted.

Resource Reservation is entirely optional. Most Access Profiles are not bookable; users connect to those at any time without any reservation step.

For the bookable-profile end-user experience — opening the booking calendar, requesting a slot, and connecting during the reserved window — see Resource Reservation.

Reconnecting

If the user’s session is interrupted (network drop, browser refresh), they can reconnect by clicking the same Access Profile again. The behavior depends on whether the user is pinned to a specific instance.

User’s relationship to the instance Reconnect behavior
Pinned to a specific instance (via Manual Assignment) Reconnects to the same instance. Local state, open applications, and unsaved data are preserved. Pinning overrides the model’s routing — neither Pool Mode nor Allow Dynamic Assignment applies.
Not pinned, Allow Pool Mode = ON The broker assigns an available instance from the pool according to Pool Mode (Breadth First or Depth First). The user may land on a different instance than before — session-based pooling does not preserve user-to-instance affinity.
Not pinned, Allow Pool Mode = OFF, Allow Dynamic Assignment = ON The broker assigns a dedicated instance on first connection and remembers the binding. The user returns to the same instance on subsequent connections.
Not pinned, Allow Pool Mode = OFF, Allow Dynamic Assignment = OFF The user must be bound manually via the Manage Users dialog; without a binding they receive a connection error.
Info

For session-based deployments, advise users to store work on network drives or cloud storage rather than the local VM disk, since they may not return to the same instance.

Disconnecting and Logging Off

Action Effect
Close the browser tab Disconnects the session. The OS session may remain logged in (depending on protocol and OS settings).
Sign out from inside the OS Cleanly ends the OS session. The instance follows its configured power and idle policies.
Click “Disconnect” in Workspace Disconnects from the session without affecting the OS session state.

For session-based pools with On Demand power, the instance powers off automatically after the configured idle timeout once all sessions end. See Power and Scheduling Settings.

Common User-Facing Issues

Symptom Likely Cause
“No instance available” error The model is at maximum capacity and on-demand provisioning is disabled, or quota was exceeded at the cloud provider. See Access Profile Errors.
Long wait at “Starting your environment…” The target instance is being powered on or provisioned. Wait or contact the administrator if the wait exceeds expected boot times.
“Connection failed” after instance is ready Network connectivity issue between broker and instance. See Connectivity Issues.
Different desktop than last session The user is not pinned to a specific instance, and the model is configured with Allow Pool Mode = ON. Session-based pooling assigns whichever instance is available — expected behavior for shared pools.

See Also