Highlights
Status
Currently in production. As of this writing, both the Preview and Production Rings are set to release 5.1.0.
Posture Check
Support for additional posture-check features. All these tests are enabled in Control and run on the Client device. Enabled tests can be configured to either prevent the user from accessing Workspot resources or give them a warning and allow them to proceed. Failures are logged in Control and Watch.
Check to see if specified applications or services are running.
Check to see if the Client device is joined to your organization’s domain.
Run a custom posture-check script.
Support for Reduced Prompts in Azure AD and Okta
Customers using OIDC (Azure AD or Okta) sign-in can now specify the frequency with which end-users are prompted to provide credentials when signing into the Workspot Client. Previously, users were prompted for their credentials every time they signed in and when the Client exited screen-lock mode. Two additional settings are available in Control in addition to this “Strict” setting: “Normal” and “Less Strict.” (This selection is made in Control under “Setup > Configuration > Authentication and Registration > Credential Caching.”)
This frequency is adjusted depending on whether the client device is trusted or non-trusted. A device is trusted if it is domain-joined to one of your organization’s AD domains (if it is known to Control) or if its Azure AD tenant ID matches one known to Control.
There are cases where the Client will always prompt the user for credentials and cases where it will attempt to use saved authentication tokens. If the saved tokens are missing, expired, or otherwise invalid, the user is prompted for their credentials.
Strict Prompting: Always prompt the user for credentials.
Normal Prompting: Prompt the user for credentials on non-trusted endpoints, try to use saved tokens on trusted endpoints.
Less Strict Prompting: Always try to use saved tokens.
Debug Log Improvements
Client logs are now retained longer and rolled over less aggressively to allow more effective debugging.
Control administrators can now request Client logs directly with the “Get Client Logs” button in “Users > username > Active Devices > Details.” The request is queued and the logs are uploaded when the user signs in if they aren’t signed in already. The request expires after seven days.
Improved Sign-in Support
Previously, the Client saved user identifiers in domain\username format even if the user entered them in user@company.tld format. For increased flexibility, this conversion is no longer done.
Windows Hello is supported on the Workspot desktop if enabled in both Control and the desktop.
The Client now supports the OIDC (Azure AD and Okta) “Alternate Claim” field for specifying an alternate field to the email field as the user identity.
FIDO2/Yubikey Passthrough Support
The Client now supports Yubikey passthrough, allowing Workspot desktops/apps that require a Yubikey to access the one on the local Device. Yubikey passthrough is enabled in Control’s Security Policies under “Protocol Settings > Allow Authentication Passthrough” (default is “no”).
Supported Platforms
Windows 10 and Windows 11.
Installation
Installing the Release Manually
The Client is available for manual installation from Workspot's download site (https://download.workspot.com) using the links below:
64-bit Windows Client: WorkspotClientSetup64(5.1.0.5149).msi.
32-bit Windows Client: Not Available.
Installing the Release Automatically
Automatic updates via the (highly recommended) Deployment Ring option work as follows:
The Stable Ring (recommended for most users) is always set to the most recent production release.
The Preview Ring (recommended for beta testers and early adopters) is always set to the most recent beta release or production release, whichever is newer.
See Automatic Updates via Deployment Rings for more information.