Overview
The Workspot Desktop Agent is a software service that runs on Workspot template images, Workspot desktops, and servers running Workspot RD Pools.
The Workspot Desktop Agent:
Registers the virtual machine (such as Workspot desktops) with Workspot Control if it is not registered already. This registration includes the virtual machine’s IP, Ethernet addresses, and everything else needed for Control and admins to identify the virtual machine.
Sends status, session information, device capabilities, and performance data to Control, including who is signed in, diagnostic messages, and performance information.
Receives information from Control, such as notifications that a new version of Agent is available or that the VM needs to shut down cleanly.
Auto-updates itself if running on a VM in persistent VDI Pools and RD Pools. (For VMs in non-persistent Pools, Workspot recommends upgrading to the latest Agent using the process described in this article: Control: Applying Updated Templates to Desktop Pools.)
Optionally runs a custom startup script after each system boot.
During VM provisioning (that is when a new desktop or RD Pool VM is cloned from a Workspot template), Agent:
Optionally joins the VM to your AD domain, using your domain server and the credentials that you provide.
Performs other setup tasks that you (optionally) specify. See the XML Template Configuration section.
If the Agent does not run successfully, Workspot Control is aware of the existence of the VM but lacks important information about it, and it is not available as a Workspot Desktop. Control knows its IP address, so you may be able to sign in and install, restart, or authenticate the Agent as needed.
Steps to install Agent on Linux Environment
The Agent Installer is on the Workspot download site: https://download.workspot.com.
On the new template VM, open a browser and navigate to the following link to download: https://cdn.us.document360.io/ad9153e1-c8de-4f56-94f2-b717a1fc3a68/Images/Documentation/workspot linux installer 1.5.0 ubuntu22.04.sh
Please execute the following command to switch to the root account
sudo su -
Next, run the installer script to download the agent onto the local disk by executing:
to run the command, you would need executable permissions. Hence, execute the below command to update the permissions:
chmod +x workspot_installer.sh
To install the Agent, please run
./workspot_installer.sh
Enter the Domain details when prompted as in the purple box.
In the 2nd screen, again provide your domain name in the screen below.
Enter the domain name again on the 3rd screen.
Please enter the DNS Server IP address when the below screen appears.
Select Yes when the below screen appears to join the VM to Domain.
The Agent should be registered with Workspot Control as part of the installation process. This can happen in two ways:
You can register the Agent during installation by providing the login/password of a Workspot Control administrative user.
You can also register the Agent with a template registration token obtained from Control.
Below are the steps for “Token-based” to register the Agent with Workspot.
Note: Use the up and down arrows on the Keyboard to Select “Token-based” and press enter.
Sign into Workspot Control as a user with Administrator privileges.
Go to "Setup > Configuration."
Find the Template Registration Token as shown in the screen capture below.
Note: The Template Registration Token does not expire, but you can create a new one with the “Regenerate” button if you choose. Regenerating the token does not affect existing templates.
Copy the Template Registration Token. This token allows you to register the Agent.
Enter the AD Domain FQDNS when the below screen is prompted.
Please enter the Organization Unit(OU) details when prompted.
Enter User ID and password to join the VM
After entering the above Credentials, please notice the Template registration status below when installing the package.
Troubleshooting the Agent:
If the WorkSpotAgent service status is Online on Workspot control, but not changing the status to ready state, then there might be a possibility of WS-Agent service status in an error state at the guest OS level.
SSH to Linux OS
Execute systemctl status workspotagent command to check the error. Please check “/var/log/workspotagent.log” file for a detailed log.
“/etc/krb5.conf If the Workspotagent errors have realmd/adcli errors like below.
May 03 07:31:27 ubuntu2204-010 adcli[1571]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
May 03 07:31:27 ubuntu2204-010 realmd[1565]: ! Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor c>
May 03 07:31:27 ubuntu2204-010 realmd[1565]: ! Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor c>
May 03 07:31:27 ubuntu2204-010 realmd[1565]: adcli: couldn't connect to csr.srikanth domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GS>
May 03 07:31:27 ubuntu2204-010 realmd[1565]: adcli: couldn't connect to csr.srikanth domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GS>
May 03 07:31:27 ubuntu2204-010 realmd[1565]: process exited: 1571
May 03 07:31:27 ubuntu2204-010 realmd[1565]: ! Insufficient permissions to join the domain
May 03 07:31:27 ubuntu2204-010 realmd[1565]: ! Insufficient permissions to join the domain
May 03 07:31:27 ubuntu2204-010 realmd[1565]: released daemon: current-invocation
May 03 07:31:27 ubuntu2204-010 realmd[1565]: stopping service
In this case, please follow the below steps:
Open “/etc/krb5.conf” file using Vi-editor
vi /etc/krb5.conf
and add the below entry under “libdefaults”
rdns = false
Make sure to restart the Workspot agent service.
Below is the reference link for the above resolution.