--- myst: html_meta: "description lang=en": "Learn how to create and configure Windows AutoScale templates for Kasm Workspaces. This guide covers prerequisites, licensing considerations, image creation, domain joining, startup scripts, and the Kasm Desktop Service." "keywords": "Kasm, Windows AutoScale, RDP, Remote Desktop, Active Directory, VM, Windows VM, Kasm Desktop Service, AutoScale, licensing, domain join, startup scripts, sysprep" "property=og:locale": "en_US" --- ```{title} Windows AutoScale Template Creation ``` # Windows AutoScale Template Creation ## Overview Kasm Workspaces can AutoScale Windows VMs in supported Cloud Providers/Hypervisors. Servers AutoScaled by Kasm should be seen as individual servers connected to via RDP. Kasm Workspaces provides session handling and ensures users a distributed to the pool of servers. Kasm auto-scaling is not supported as a way to scale RDS deployments. Autoscaling of Windows servers requires one or more Windows template images to deploy from. ```{raw} html ``` ### Prerequisites #### Licensing > Any stated or implied licensing restrictions with respect to Microsoft products and services are to the best of our knowledge and may not represent the current state and may not be an accurate summarization of what are complicated licensing restrictions. Ensure to consult with Microsoft to fully understand your rights as a licensee of their products and services. First, it’s important to note that Microsoft has specific licensing requirements for accessing their software applications through remote desktop services (RDS) and virtual desktop infrastructure (VDI) solutions. These licensing requirements can be complex and may vary depending on the specific scenario and product being used. In general, if you are using Kasm Workspaces as an RDP connection to an RDP application or RDS Session host, you will need to ensure that you have the appropriate Microsoft licenses for the software being accessed. This may include licenses for Windows Server, Remote Desktop Services (RDS) Client Access Licenses (CALs), and/or Microsoft Office. Kasm Workspaces provides the ability to connect to RDP applications and RDS Session hosts using the internal Connection Proxy service, which allows for secure remote access to Windows-based applications and desktops from any device or browser. If the Windows VMs are in the cloud, you have the option to use pay-as-you-go (PAYG) licensing or bring-your-own-licensing (BYOL). When using PAYG licensing, the Windows licensing costs are built into your cloud costs. Some cloud providers charge the Microsoft licensing fee separately, so it may not be included directly in the estimated instance pricing. See your cloud provider for details on Microsoft licensing. If you decide to use the BYOL approach, you will be responsible for either manually licensing your servers or automating the licensing process of Windows servers. Kasm does not provide support or assistance with licensing Microsoft products. The following Microsoft licensing restrictions should be evaluated when selecting an architecture and/or cloud provider. * Microsoft explicitly disallows running versions of Office later than 2019 on a VM in any cloud provider other than Microsoft Azure. * Microsoft explicitly does not support Windows 10/11 multi-session images running in any cloud provider other than Microsoft Azure. The result is that running Windows 10/11 in any cloud provider, other than Azure, will require 1 VM per user, which will have profound licensing cost implications. * Running of Windows 10/11 in a cloud provider other than Azure is heavily restricted by Microsoft. While you will not find Windows 10/11 images in any cloud provider’s image marketplace, you can still create custom images on your own and handle licensing of the operating system yourself. Kasm does not provide support for licensing of Microsoft products. ### Image Creation #### Additional Drivers Depending on your target VM environment you may need to install additional drivers, such as the [VirtIO](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso) SCSI drivers, as part of the Windows template install process. These drivers should be mounted as an additional drive at install time so that they are available to the Windows installer. #### Guest Agents Ensure that you install the required guest tools for your target VM environment, such as VMware Tools or the QEMU Guest Agent, as well as any necessary additional boot-time services such Cloudbase-Init. #### Sysprep [Sysprep](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) is a Microsoft tool to generalise Windows installs for image deployments. While Kasm does not require Windows templates to be generalised, there are some scenarios where it is required. If you are deploying to Azure then running sysprep is required. If you are joining your Windows AutoScale VMs to Active Directory then running sysprep is recommended. Generalised images may require additional first run tasks to be performed by your AutoScale startup scripts to configure them for your use. #### Multi-User Environments If you intend to support multi-user environments on your Windows AutoScale VMs then you should ensure that the default user profile on the template has been configured to meet your requirements. You will also need to install the Kasm Desktop Service as part of your AutoScale startup script. #### Audio Services The Windows Audio (`Audiosrv`) service is not started by default on Windows Server and so if audio support is required this should be handled by your startup script or, if not using sysprep, by setting the service to Automatic startup on your template. #### Additional Software To improve the speed at which your Windows AutoScale VMs can be provisioned it is recommended where possible to install any required software onto the template, rather than installing at runtime. In scenarios where license keys or product activation is required, you may be able to install the unlicensed software onto the template and configure licensing at runtime. We recommend regularly rebuilding your templates to keep your software up to date and secure. #### Domain Join AutoScaled servers can be configured to automatically join Active Directory. This is a two step process which involves Kasm first creating a Computer Object in Active Directory, within a specified AD container. When the Computer Object is created, a random single use password is created, which can only be used to join the computer to the domain. The final step of joining the computer to the domain must be done from the Windows server itself. This is facilitated through the startup script of the VM Provider configuration. The Powershell startup script can then join the computer to the domain using the single use random password that was created by Kasm. * Create an LDAP Configuration that will be used for user authentication to Kasm. * Create an LDAP Configuration that will be used to create computer objects in AD. The service account used by this LDAP configuration must have permissions to create and remove computers from the domain. You can use the same LDAP configuration that is used to authenticate users or you can create a different LDAP configuration used specifically for joining and removing systems. If you use a separate LDAP configuration, leave it disabled so that it cannot be used for authentication purposes. * In the AutoScale Configuration, select `SSO User Accounts` for the Connection Credential Type. * In the AutoScale Configuration, check the Create Active Directory Computer Record box. * In the LDAP Config select the LDAP configuration created in step 2. * In the Active Directory Computer OU DN, enter the AD OU Distinguished Name. Example: `OU=Computers,DC=example,DC=local` * Enable Recursively Cleanup Active Directory Computer Record if you anticipate the Computer objects having child objects. This can prevent `notAllowedOnNonLeaf` errors when cleaning Azure VMs. * Click Next to save the AutoScale configuration. * The next page is the VM Provider configuration. Scroll down to the startup script and provide one which includes a domain join command, such as: ```powershell $joinCred = New-Object pscredential -ArgumentList ([pscustomobject]@{{ UserName = $null; Password = (ConvertTo-SecureString -String '{ad_join_credential}' -AsPlainText -Force)[0] }}) Add-Computer -Domain "{domain}" -Options UnsecuredJoin,PasswordPass -Credential $joinCred -Force -Restart ``` > If your script uses curly brackets, aside from Kasm variables, you must escape them by doubling them up. #### Startup Scripts Each VM Provider has special caveats around how their startup scripts are handled, see the VM Provider page for your target environment for more details. While each VM Provider may behave a bit differently or expect a slightly different format, they all support PowerShell scripts and that script will have access to Kasm managed variables. We provide some examples in our [AutoScale start scripts Github repo](https://github.com/kasmtech/workspaces-autoscale-startup-scripts). The following table lists variables that are accessible from the startup PowerShell script. > For VMware, due to the way VMware Tools operates, Kasm requires a direct network connection to the ESX host running a Windows VM in order to execute the startup script. All other AutoScale activities occur via connection to vCenter. ##### Startup Script Variables | Variable Name | Description | | --- | --- | | connection_username | If the AutoScale configuration is set to use a static username for Kasm user sessions, the username will be contained in this variable. | | connection_password | If the AutoScale configuration is set to use a static password for Kasm user sessions, this variable will contain the password. | | ad_join_credential | If the AutoScale configuration is set to join the VM to an Active Directory domain, Kasm creates the AD record and sets a random password that can only be used for joining the VM to the domain. This can then be used in a Powershell startup script to complete the process of joining the system to the domain. | | domain | If the AutoScale configuration is set to join the VM to an Active Directory domain, this variable will contain the name of the domain. | #### Kasm Desktop Service The Kasm Desktop Service is a Windows service that provides additional capabilities to users that are connected to the desktop through Kasm Workspaces: * Upload files to the remote desktop * Download files from the remote desktop * See a preview screenshot of the desktop in the Kasm Workspaces dashboard * Run PowerShell scripts on session start, session end, or service start * Kasm managed local Windows users and credentials * File Mapping * Supports multiple concurrent users on the same Windows system We recommend that you always install the Kasm Desktop Service as part of your AutoScale startup script. The example scripts in our [AutoScale start scripts Github repo](https://github.com/kasmtech/workspaces-autoscale-startup-scripts) demonstrate the unattended install process. The Kasm Desktop Service uses HTTPS/SSL to communicate with the rest of the Kasm Workspace services. The service installer will open the Windows firewall for TCP port 4902, ensure that firewalls and/or cloud security groups allow inbound TCP port 4902 coming from Kasm API server and Connection Proxy servers. The Kasm Desktop Service will talk outbound to the API Server on the port your deployment utilizes, TCP port 443 by default. Ensure security groups and our firewall rules allow this communication.