On-Prem – Non-Domain & Domain Join Template
Workspot made creation of template simple through build Template option in Control, however the way templates get created and cloning of templates done in the backend will differ based on environment (Azure, GCP, AWS or On-Prem). At a high-level following step involved to build a new Template.
Example of a Windows Template:
-
Install Workspot Agent
-
Provide Domain Joined details through Workspot Configuration Editor
-
Requires a Service account with appropriate permissions to Create and delete Computer Object in an OU in AD
-
Optional
-
In case there is a need to add users or Groups to VM local group, provide the details. We recommend our customer to use group policy to manage user & Group memberships.
-
In case there is a need to execute any script before domain Join, WSCompleteSetup can be used.
-
In case there is a need to execute any script after domain Join, WSRunOnce can be used.
-
In case there is a need to execute any script at every reboot or Agent restart, WSCustomeStartup can be used.
For more details, Please refer to https://community.workspot.com/workspot-agents-106/workspot-desktop-agent-installation-and-configuration-191
Most of our customers uses non-domain joined templates to provision VMs. However, in case a customer want to use a domain join Template, Workspot Agent install in the template takes care of renaming the cloned template and joining t
For a non-domain joined template
To make any changes in the template we recommend Customer admin to clone the existing template and make the changes before publishing the template and assigning it to a pool.
For a domain Joined Template, during VM Provisioning Workspot Agent remove the VM from the Domain and based on the Desktop name, rename the VM and rejoin the VM with the new desktop name.
Snippet from the Desktop Agent Log file:
When a template is cloned from Control (support for only Cloud environment) the Control and Agent takes care of registration process of new template. However, when a customer clone a Template at a Hypervisor level (Control does not know about the Clone), so for Hypervisor the process works like this at a high level.
VMWare Hypervisor example:
-
Clone the existing Template.
-
If the source template is domain joined a few extra steps, we need to consider:
-
Domain Joined template.
-
When powering on the first time, make sure NIC is disconnected. Thus, the VM should not communicate to AD. Else, the cloned VM change the SID in the AD as a result the first machine (template) won’t be able to communicate with AD.
-
Login to the Cloned template and change from Domain to Workgroup
-
Reboot the VM
-
Connect the NIC back. (MAC address should not be same, as Agent registration is closely affiliated with MAD id)
-
Join the clone VM to the domain with a unique Computer Name.
-
Uninstall the Desktop agent from the Cloned VM
-
Reinstall the Desktop Agent in the Clones VM with details to register with Control as a Template.