Listed newest-first:
Helpdesk Admins can assign and unassign users from Custom Cloud Desktop Pools, which is outside the scope of the Helpdesk Admin role.
In Time Limits Policies, you can't select a "Max. Session Length" for Named (Persistent) desktops. To limit the session length in Workspot pools that don't support desktop Sleep, Hibernate, or Shutdown, use the Windows GPO settings in “Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.”
In Hyper-V, if a VM enters the "CreateFailed" state (as shown in the Hyper-V Console) on an App Server Pool with "In-Place OS Updates" enabled, it will remain unavailable until you use the following workaround:
On the "Edit Cloud App Pool" page, disable "In-Place OS Updates" temporarily.
Double-check that "Auto Create on Delete" is enabled.
Save these changes.
Delete the VM. It will be recreated automatically.
Re-enable "In-Place OS Updates."
When using Entra ID (Azure AD) as your SAML provider, the usual logout URL provided by Azure AD may result in an error message when signing out of Control. Workaround: Configure SAML in Control ("Setup > SAML > Signout Service URL") to use the following URL instead: https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
Control times out when provisioning a desktop takes longer than thirty minutes, which occasionally happens when a Cloud provider is running slowly. The error message in this case is "Timed out Waiting for Instance status to reach final state." Workaround: Delete and recreate the failed desktops.
When a desktop in one of the subpools of a non-persistent Global Desktop pool cannot be created and no warmed-up desktop exists in another subpool, a new one is supposed to be created. This does not work.
If a user's desktop is being migrated from one pool to another with the "Upgrade" command and the user loses their entitlement to the desktop (for example, by having their account deleted in Control or AD/Azure AD, or being moved out of their Workspot AD group), the Upgrade tab in the Control UI loses track of the desktop. In addition, it boots to the Error state instead of the Ready state.
Occasionally a pool that meets the requirements of a target pool for the Upgrade function is not displayed. Workaround: contact Workspot.
The Control UI allows you to migrate a user's desktop to a pool where they already have a desktop, but users cannot actually have two desktops in the same pool. When the migration is complete, the user has access only to their original desktop in that pool.
Significant non-persistent Global Desktop events are not currently logged, including manual and automatic desktop deletion and creation/deletion events related to pool failover.
Control will let you create a vCenter pool with a name consistent only of digits (such as "1234") but will not let you delete such a pool. Workaround: contact Workspot to rename the pool so it can be deleted.
If (a) you have one more pool than is displayed by Control (for example, you have 26 pools and Control is display 25 pools per page), and (b) You delete one of the pools on the first display page, you are taken a page that says, "Your Workspot installation is not yet ready to create desktops." This is incorrect. Click on the "Resources" tab to see your updated pools list.
The low command throughput of Amazon Workspaces Core may cause Control operations to fail at peak usage periods, such as when many users try to launch desktops at the same time.
The Time Limits Policy "Default Named Policy" shows some fields as "-- Select --" instead of reporting their values.
If a Control administrator deletes multiple desktops or performs an Image Update that deletes multiple desktops, and an error creates a discrepancy between the number of desktops that should exist and those that actually do exist, the pool is locked with a spinning icon and can no longer be managed by Control. Workaround: Contact Workspot.
Sometimes Control reports desktops as "Paused" when in fact they are still running. This can be misleading on hourly-rate desktops.
If you install a VPN that adds a virtual NIC to a Workspot desktop or template VM, the VM looks like a different, unregistered/imposter desktop to Control, which refuses to trust it and doesn't let it advance to the Ready state from the Online state.
Once you have set the Azure AD Control Administrator Group, you cannot reset it to "None." Workaround: Contact Workspot.
When pools using Azure AD sign-in are used, Azure's limit of 250 simultaneous Bulk Primary Resource Tokens can eventually be reached. Each pool and template consumes one BPRT, which is not released automatically upon deletion. It takes a long time to reach the 250-token limit, but when it happens, the unused BPRTs must be deleted manually via your Azure portal. The first symptom is Control Event messages that announce that BPRT renewal failed. New desktops will eventually become unable to join the domain.
Time Limits policies for persistent pools no longer show the "Connected Idle Timeout" value, but it still takes effect if it was set before Control R16.0. The symptoms of this are that idle user sessions are disconnected on a different schedule from the visible "Disconnect on Idle" timeout. Also, with Monthy and Annual desktops, the "Connected Idle Timeout" is always in force, unlike the "Disconnect on Idle" value, which inhibited during a worker's shift.
In a group's deployment ring settings, do not set the "Oldest Client Allowed to Connect" to the same value as the Stable Ring, Preview Ring, or the selected Custom Ring. If you do, users will get a "your version is no longer supported" warning instead of the "update available" warning. If you use the "Oldest Client" field, set it to a release older than the Stable ring.
Desktops in a given pool cannot be provisioned (such as by incrementing the pool size) during that pool's maintenance window.
When a Client user performs the "Refresh Configuration" operation, Control does not refresh the user's group memberships. This information is retrieved asynchronously with the Client heartbeat mechanism (about once every five minutes). Desktops/applications that the user is no longer entitled to will continue to be displayed until this information is retrieved.
Control reports the "Device OS" for Windows 11 Client devices as Windows 10.
In GCP persistent desktop pools, a "Pause" action appears to be available even for customers for whom pause/resume (sleep/wake) is not enabled ("Resources > VDI Pools > poolname > desktopname > Actions > Pause"). For such customers, the button is non-functional.
If the Control administrator puts a desktop to sleep with the "Pause" option ("Resources > VDI Pools > Manage VDI Pool > desktopname > Action > Pause") at the same time the user tries to reconnect, the connection fails.
When a power-managed desktop resumes from sleep, Control often informs the Client that the desktop is ready before it can actually accept Client connections, resulting in error messages that suggest that the desktop may need to be rebooted. Do not reboot the desktop until after retrying the connection.
Persistent desktops cannot be restored from backups after "Update Image" has reimaged them.
Persistent desktops in the "Suspended" state are not updated when "Update Image" is applied to the pool. If they are later returned to the desktop, they remain as before and don't use the new template.
On power-managed desktop pools, paused desktops may show as "Deallocated" instead of "Paused." The two states are equivalent.
If you schedule "Update Image" for a persistent desktop pool and then increase the number of desktops, the new desktops will not be provisioned until the pool is reimaged.
UI controls that are normal are hard to distinguish from ones that are grayed out.
If an administrator signs into a Workspot desktop using a Remote Desktop client other than the Workspot Client, when they sign out, Control will log the session with a username of "Unknown."
Control sometimes logs events out of order when they occur in rapid succession. For example, "Resume initiated" may be logged after "Resume succeeded."
If the same RD Pool server is deleted at roughly the same time by two different Control administrators, and the "Auto Create on Deleted Desktop" option is set, Control will recreate the deleted server twice, resulting in an extra server VM.
If power management is enabled, users may sometimes be told that they will be connected to their desktop when it becomes ready, but they never are. Workaround: Cancel the connection after a minute or two and try again.
When using UPN authentication, Control sends requests to the first available Workspot Enterprise Connector. If different Connectors serve different customer domains, some requests will fail.
Occasionally, a user might see a spurious error saying: "Your desktop connection was denied because the user account is not authorized for remote login." Workaround: retry the connection until it succeeds.
When you assign a new template to a non-persistent desktop pool with the “On Logoff” or “Schedule Now” options, all the desktops without active user sessions are shut down immediately, leaving no desktops available for users who sign in before the first desktop is reimaged. If you use the “Schedule At” option, the same is true at the specified update time.
When creating a GCP template, you are required to specify a region, but the template is available globally once published.
A single user who has two email addresses listed for the same AD account is treated by Control as two users. If they log in first using one email address and then the other, they will get different resources. This is most commonly seen as getting a persistent desktop with none of the personalization of the one they were expecting.
The "Users > Groups > groupname > Group Info" page lists members of the group without regard to whether another group membership takes precedence. Thus, when group policies don't seem to be working for a user, check the user's effective group membership, which is listed under "Users > username > User Details > Selected Group Name." To adjust group precedence, go to "Users > Groups > Precedence Order" and drag the desired group so it is above the other one.
Control sometimes reports prematurely that a Workspot desktop is in the Ready state. This prevents Workspot Clients from deferring their connection attempts until the desktop is actually ready, resulting in an "could not connect to the host machine" error. Workaround: Try the connection again.
You can't assign the same release to two software deployment rings.
When moving multiple desktops with the Control API's "moveDesktop" command, some moves may fail unless you add a delay between commands. See Using the Workspot Control APIfor more information.
If the Cloud provider has temporarily run out of VMs of the specified type when desktops are being created, the creation of some desktops will fail after a long delay (more than 30 minutes). The affected desktops will be shown in Control as "Failed" with a reason of "Async Operation failed with Provisioning state." Workaround: Reprovision the affected desktops.
When activating a Regional DR pool, a desktop that fails to provision remains unavailable for the entire Regional DR period.
In RD Pools created before Control R14.0, when one server in an RD Pool with multiple servers goes offline, its users aren't reconnected reliably to the surviving servers. Instead, they may receive "No Desktops are Available in Pool" errors. If you encounter it in an existing pool, please contact Workspot.
The Regional DR state of a pool is reported inadequately by the Workspot Clients in two cases: (1) When Regional DR is activating or deactivating, the Client displays a "Cannot connect" message that doesn't mention Regional DR. (2) While Regional DR is active, a user who is entitled to a desktop in the parent pool but doesn't actually have one is given an "Unable to contact Workspot Control" message instead of the correct "No desktops available" message.
When a desktop is in the Suspended state in the parent pool, a Regional DR event will enable the desktop in the Ready state (though unassigned) in the Regional DR pool. When Regional DR is deactivated, the parent-pool desktop will also be in the Ready state.
If you delete a user or remove the user's assignment to a non-persistent pool while the user has an active desktop session in that pool, but is not signed in, the desktop is not returned to the pool.
Provisioning a large GCP pool (hundreds of desktops) may fail with an error of: "Quota exceeded for quota group 'ReadGroup' and limit 'Read requests per 100 seconds' of service 'compute.googleapis.com' for consumer …" This is especially likely if you provision more than one large pool at the same time. Workarounds: (1) Provision fewer desktops at a time. (2) Set the "Auto Create on Desktop Delete" option for the pool and delete batches of failed desktops to recreate them.
The Redeploy command in the Control UI and the Control API doesn't always take effect the first time it is issued. Workaround: Issue every redeploy twice.
Only one administrative command is allowed at a time for a given pool. For example, you can't provision a new desktop and then delete a different desktop in the same pool until provisioning completes.
Creating a Windows 10 template can take approximately 20 minutes to complete.
A reboot requested by the end-user is logged in Control’s “Events” list with correct information in the “Event” column, but the data for the “Location,” “Network,” and “Device Type“ columns is not listed.