|Manuals

Manually Assign an Instance to a User

The Manage Users dialog in Thinfinity® Cloud Manager lets you bind one or more Thinfinity® Workspace users to a specific instance. Once bound, the broker prefers that instance when routing those users’ sessions. Multiple users can be bound to the same instance — useful for a small team that must always land on the same machine.

This article covers when manual pinning is the right choice and how it interacts with Pool Mode and Dynamic Assignment. For pool behavior in the absence of pinning, see Provisioning and Pooling Options and Pooling Strategies.

Info

For Kubernetes models, user assignment is governed by Kubernetes scheduling and pod identity rather than by the Manage Users dialog.

When Manual Pinning Makes Sense

Manual pinning is the right choice when:

  • A user requires a persistent local environment — locally installed apps, local data, or persistent customizations.
  • A user has license entitlements bound to a specific machine identity.
  • Compliance or audit requirements mandate per-user, per-machine traceability.
  • A specific VM has hardware characteristics (GPU passthrough, attached storage) that only certain users should consume.

How pinning behaves depends on the instance source:

Context Pinning behavior
Managed VMs 1:1 by design. The Manage Users dialog is the primary access control.
VDI/DaaS Model (any configuration of • Allow Pool Mode and Allow Dynamic Assignment) The pinned user is routed to their bound instance. Pinning overrides both Allow Pool Mode and Allow Dynamic Assignment for the pinned user. Non-pinned users follow the model’s pool and assignment configuration — see Provisioning and Pooling Options.

Prerequisites

  • The instance has been deployed.
  • The user account exists in the Thinfinity Workspace identity provider.
  • You have the Manage permission on Instances. See Cloud Manager Permissions.

Edit the Assignment List

1

Open the Instance’s Row

In the left tree, expand Managed VMs (or VDI/DaaS Models) and click the connection or model that contains the target instance. Locate the instance in the Instances table.

Instances tab with a target instance row visible

2

Open the Manage Users Dialog

In the row’s Actions column, click the Manage Users icon. The dialog opens, listing the Workspace users currently bound to this instance.

Manage Users dialog — empty state with the user search input visible
3

Add Users

Use the search input at the top to find Workspace users by name, username, or directory attribute. Each user you select is added to the table below; the dialog accumulates users as you add them.

Manage Users dialog with four users in the assignment list
4

Remove or Replace Users

To remove a single user from the assignment list, click the trash icon at the end of that user’s row.

To remove several users at once, select their rows using the row checkboxes and click the bulk actions kebab (⋮) in the dialog header — choose Remove from the menu.

To replace a user, remove the previous one and add the new user.

Warning

Removing an assigned user from an instance does not delete their data. The local VM disk retains all user data. If the new user must not have access to the previous user’s data, detach the instance and provision a fresh one before adding the new user, or wipe the local data manually.

5

Save

Click Save to apply. The Assigned Users column on the Instances tab updates to show the bound users. From this point forward, when one of those users connects through an Access Profile that targets this instance’s source, the broker routes the session to this instance.

What Happens When an Assigned User Connects

  1. The user opens Thinfinity® Workspace and selects an Access Profile that targets a model or Managed VMs connection.
  2. The broker checks which instance(s) the user is bound to.
  3. If a bound instance is available and the configuration permits, the broker routes the session there.
  4. If the bound instance is powered off, the broker powers it on (when on-demand provisioning is allowed).
  5. If the bound instance is Disabled (Record State), the user receives an “access disabled” error and the broker does not fall back to another instance.
  6. If the bound instance is in an Error state or unreachable, the connection attempt fails when the broker tries to reach the VM. See Access Profile Errors.
  7. If the bound instance has been Detached (record removed), the user’s binding is cleared automatically and routing falls back to the model’s pool or dynamic assignment configuration — the user is treated as unbound for that session.

What’s Next

See Also