Provisioning and Pooling Options

Provisioning and pooling settings control three related but distinct aspects of how Cloud Manager manages instances for a model: how users connect to them, how the instance pool is sized and replenished over time, and whether each user is consistently routed to the same instance.

The full set of settings lives in the model editor’s General tab (connection and pool routing) and Deploy tab (deployment trigger and instance counts). The model creation wizard captures the subset of these settings required to create a working model, in its Access and Deploy steps. Any setting not surfaced by the wizard takes its default value at creation and can be adjusted afterwards in the editor.

For a conceptual overview of how pooling strategies affect user experience and cost, see Pooling Strategies.

Connection Mode

Connection Mode determines how the Thinfinity® Workspace broker reaches an instance when brokering a user session.

Allow Pool Mode

The Allow Pool Mode switch determines whether the model behaves as a session-based shared pool or as a 1:1 dedicated deployment.

In the wizard’s Access step, the same setting is exposed as a single Pool Mode dropdown — the None value is equivalent to Allow Pool Mode off; Breadth First or Depth First are equivalent to Allow Pool Mode on with the corresponding Pool Mode selected.

Pool Mode

Pool Mode is visible only when Allow Pool Mode is enabled. It controls how incoming connections are distributed across the running instances in the pool.

Instance Naming Prefix

The naming prefix controls how instances provisioned from this model are automatically named. Optional, but recommended for environments with multiple models.

Deployment Trigger

The deployment trigger determines when Cloud Manager provisions new instances for this model. It is configured in the editor’s Deploy tab (or the wizard’s Deploy step).

When Scheduled is selected, additional fields appear to configure the schedule and counts:

• Create At — date and time at which the scheduled provisioning happens.
• Initial Instances, Lazy Instances, Max Instances — see Instance Count Settings below.

Instance Count Settings

Two near-identically-named fields control instance counts at different scopes — Max Instances in the Deploy tab and Max Instances Count in the General tab. They coexist as independent limits.

Allow Dynamic Assignment

The Allow Dynamic Assignment switch in the model editor’s General tab controls how a user is matched to an instance when they connect. This setting is editor-only — the wizard does not capture it; new models take the default and can be adjusted afterwards.

The switch is automatically disabled when Allow Pool Mode is enabled — the pool’s distribution logic (Breadth First or Depth First) takes over routing and is not compatible with strict per-user pinning.

For the per-instance pinning procedure, see Manually Assign an Instance to a User.

Editing Provisioning and Pooling Settings After Creation

To open the model editor, click the edit icon on the model in the left tree.

Settings Locked While the Model Is in Use

While the model has instances, the editor shows the In use banner and the following settings become read-only: the Model Name, Use naming prefix (with Prefix, Digits, and Start Index), Allow Pool Mode, and Allow Dynamic Assignment. These settings define the identity and routing strategy of the pool, so they cannot change while instances built under the current configuration exist.

A model counts as in use while any of its instances exists, whatever its power state — running, stopped, and disabled instances all count. Powering instances off is not enough to unlock the settings.

To change a locked setting, either:

• Remove all instances from the model — delete them from the instances view (or let the Destroy settings remove them). Once the last instance is gone, the settings unlock.
• Create a new model or model version with the desired configuration and migrate users to it, leaving the existing deployment untouched.

How Changes Take Effect

The new settings take effect immediately, with behavior depending on which fields changed:

• Connection Mode, Max users per instance, and Naming Prefix — apply to instances created from this point forward. Already-deployed instances keep their original connection routing and names.
• Pool Mode and Allow Dynamic Assignment — apply to the next user who connects. Existing sessions are not interrupted, but the new routing behavior governs every new connection.
• Deployment Trigger changes — apply at the next scheduled window (when switching to Scheduled) or at the next user request (when switching to On Demand). Switching from Scheduled to On Demand does not destroy instances already created by the prior schedule — they remain in the pool until removed by the Destroy settings, manual deletion, or model deletion.
• Initial / Lazy / Max Instances — apply to the next provisioning evaluation. Existing instances that exceed the new Max Instances ceiling are not removed automatically; lower the count and detach the excess manually if needed.

What’s Next

• Power and Scheduling Settings — Define when instances power on and off, and configure Staged Power On/Off for session-based pools
• Deploy an Instance — Start provisioning instances from this model
• Manually Assign an Instance to a User — Pin specific users to specific instances

See Also

• Model Settings Reference
• Pooling Strategies — Conceptual overview of session-based vs. 1:1 strategies
• Create a Model Using a Built-in Blueprint
• Instance States and Lifecycle