To save money and energy, non-persistent desktops enter sleep, are shut down, or even (in the case of non-persistent desktops) deleted when not in use. New desktops are awakened, powered up, or created as required.
When the desktop is in an active, running state, users wait only for the connection to be established, which takes a few seconds. If the desktop is in a power-saving state, the delay of resuming the desktop from sleep or shutdown is added. If no active or sleeping desktop is available, the desktop must be imaged, which can take minutes.
For non-persistent desktop pools (only), Workspot Control's Warmup Policies allow desktops to be created on a schedule, so they are ready before the users sign in. This prevents users from having to wait while their desktops are created (imaged, provisioned) and powered up. This is especially important with desktops that are reimaged after each use, which is typical for non-persistent desktops. Similarly, warmup policies allow you to reduce the number of unassigned, running desktops during off-peak periods.
Warmup policies have no effect on desktops currently assigned to a user.
Prerequisites
Warmup Policies apply only to non-persistent desktop pools, including non-persistent Global Desktop Pools.
Warmup Policies are not supported for every Cloud or with every billing type. When not supported, customers are not shown the option to define or apply Warmup policies.
How Warmup Policies Work
A Warmup Policy allows you to specify the number of desktops to have ready for users at any given time. This minimizes user wait time.
Tip: Warmup Policies are always optional. Users can always sign in, even when the policy specifies zero desktops. Signing in just takes longer. Users who are signed in can always keep working.
Note: This is different from Application servers, which use Server Scaling Policies alone, without booting on demand.
Variations with Cloud Providers
Warmed-up desktops may be put to sleep (paused) while waiting for a user to sign in, since resuming from sleep is much than reimaging. However, this behavior depends on the Cloud provider. See the Workspot Compatibility Matrices for variations in power-management support with Cloud providers.
Start-of-Shift Example
Suppose a shift starts at 08:00 and you expect 50 users to sign in between 08:00 and 08:30. You specify 50 desktops for the 08:00 time slot.
Control ensures that 50 desktops are available at 08:00 by:
Noting how many desktops are already populated, either in use or sleeping.
Booting or Provisioning (creating) enough new desktops to bring the total up to 50 by 08:00.
This process starts twenty minutes early, at 07:40.
Behavior by Cloud type:
GCP: Once the warmed-up desktops have booted fully, they are optionally to sleep (the default) and are awakened one by one as users sign in. This behavior can be disabled in the warmup policy, in which case the desktops run to the end of the time period.
Azure: Once the warmed-up desktops have booted fully, they are optionally shut down (the default). They are booted one by one as users sign in. This behavior can be disabled in the warmup policy, in which case the desktops run to the end of the time period.
AWS: Same as Azure.
Amazon Workspaces Core: Not supported.
Existing desktops count toward the total of 50:
The desktops of users who are already signed in.
Unassigned desktops that were already available for whatever reason.
If user #51 signs in, there are no remaining warmed-up desktops. This means the user has to wait until a new desktop is created. The user sees this as a connection delay, adding to the time between clicking on the desktop icon in the Workspot Client and the appearance of the desktop's sign-in screen.
End-of-Shift Example
Suppose the shift ends at 17:00 and you expect no one to sign in from that point on. You specify zero desktops for the 17:00 time slot. As users sign out, their desktops are shut down and not replaced, since the policy calls for zero warmed-up desktops. If everyone signs out (whether manually or through a Time Limits Policy), the number of running desktops falls to zero. If some users continue working, they continue as if nothing has happened (because, for them, nothing has).
Users who sign in after 17:00 will see the same delay as user #51 in the previous example.
You can specify zero desktops even earlier than the end of the shift if you expect that no one will sign in during the latter portion of the shift.
Other Details
When the next time slot calls for fewer warmed-up desktops, the excess desktops are either shut down (but can be booted again later) or deleted at the end of the current time slot.
When a user clicks on a desktop icon in the Workspot Client but fails to connect successfully, their desktop remains in the Ready state for approximately thirty minutes before giving up and being paused or shut down. If the user connects successfully, the desktop is paused or shut down when the user signs out (manually or through a Time Limits Policy).
Cost Savings
To ensure that the desktops are ready at the specified time, Control provisions the required number of new desktops twenty minutes early. After they are ready, Control pauses them unless you deselect the default “Pause warmed-up desktops immediately” option in the Warmup Policy.
You are billed for the time between the start of the provisioning process and the time the desktops are fully paused. In addition, when a user signs in and acquires a desktop, you are billed for the time they spend signed in.
Non-persistent desktops do not sleep or shut down when there is an active user session, even if the user is disconnected, so the entire session time is billed.
Effects Time Limits Policies
For user sessions, costs are controlled by setting both the "Idle Disconnect," "Sign Out After Disconnect,” and “Maximum Session Length” values in a Time Limits Policy:
Idle users are disconnected when the Idle Disconnect timer expires.
Disconnected users are signed out when the Sign Out After Disconnect timer expires.
They will also be disconnected and signed out if the Maximum Session Length Timer expires.
Once the user is signed out, billing stops.
Billing also stops when the user signs out manually or the desktop is shut down by Control.
Warmup Policy Page
Parameters
To add a new policy, go to “Policies > Add a New Policy” in Workspot Control. To edit an existing policy, go to “Policies > policyname.”
Enter the following:
Select a name for the Policy.
Specify “Warmup” as the Policy Type.
Select whether this Policy applies to a Cloud Desktop Pool or a Global Desktop Pool.
If desired, apply the Policy to a Pool now. You can also apply it from the “Add/Edit Pool” page.
Choose the time zone to use for the schedule (which defaults to Control’s time zone).
Warmup Policies Page, part 1 of 3.
The Warmup Schedule
The warmup schedule is the heart of the warmup policy. It is displayed as a table with the day of the week shown horizontally and the time of day vertically, creating an array of 48 half-hour time slots. Each time slot specifies the number of warmed-up desktops to be ready at the start of the half-hour period. This number includes the already-active users, so if you specify 50 desktops and the period starts with 10 users already signed in, 40 desktops are warmed up. The default is zero and the maximum is the size of the desktop pool.
Only six hours are visible at a time: use the scroll bar on the right to see more.
The desktops for the next time slot are warmed up twenty minutes before the specified time to ensure they will be ready.
Note: Some Cloud providers place limits on how quickly desktops can be ramped up or down. See the notice on the Warmup Policies Page for current recommendations (the sample below may be out of date).
.png?sv=2022-11-02&spr=https&st=2024-11-21T21%3A14%3A23Z&se=2024-11-21T21%3A32%3A23Z&sr=c&sp=r&sig=2hl6HOOhBHYbta47KZvGXnE6%2B3fmZNic%2BLvDjwYSlyM%3D)
Setting the Time Slots
Set each time slot to the minimum number of desktops you want ready for users during that period. You can select ranges of cells, copy them (such as with Ctrl-C), and paste them into another range of cells (such as with Ctrl-V). If the target range is larger than the source range, values are repeated to fill the whole target range.
Warmup Policies Page, part 2 of 3: the warmup schedule.
Actions When Slot Capacity is Changed
On increase. When the schedule calls for an increase in the number of warmed-up desktops, they can be either warmed up and left running or warmed up and paused (put to sleep, hibernated, or shut down, depending on the available power-saving options). Keeping them ready leaves them instantly available; pausing them saves money at the expense of an extra login delay.
On decrease. When the schedule calls for a decrease in warmed-up desktops, they can either be paused (put to sleep, hibernated, or shut down) or deleted. Paused desktops are available more quickly: they can be brought out of sleep or hibernation or rebooted. Deleted desktops must be imaged before use.
If there are no warmed-up or paused desktops when a user signs in, one will be imaged on demand and assigned to them.
Warmup Policies Page, part 3 of 3: pause vs. delete.
Notes and Best Practices
To minimize costs, leave the entries at zero for periods where you don’t expect anyone to sign in, and let users know that signing in during such periods will take longer.
This feature is at its most valuable at the start of a shift. Once everyone is signed in, the values make little difference.
The Warmup policy doesn’t track the size of the desktop pool. If you decrease the size of the pool below the largest entry, you have to manually edit all entries that are larger than the new pool size before you can save the downsized pool. If you increase the size of the pool, the entries remain the same and may be too small.
If any desktops are in the Failed or Error states, they are inactive by definition. On warmup, such desktops are deleted, reimaged, and powered up. On shutdown, such desktops are deleted. Thus, these problems are self-correcting.