RDS

This guide will walk you through the benefits of using RDS to manage your RDS farm, and how to connect to those resources via Kasm’s secure RDP capabilities with Data Loss Prevention (DLP) features. RDS is a collection of Microsoft tools and services that allow multiple users to access a shared desktop or applications on a server. RDS is designed to allow users to connect to a server and use shared resources, such as files and applications, in a secure and controlled environment. RDS provides features such as load balancing, remote app publishing, and session virtualization.

RDS application/session/desktops pools give users access to applications that run on servers in a data center instead of on their personal computers or devices. RDS Farms are logical groupings of RDS-enabled Windows Server operating systems that contain common configurations and installed applications. The RDS Connection Broker Service is the communication point for the RDS Farm. Application pools and RDS desktop pools use RDS farms to deliver hosted desktops and applications to multiple instances of Kasm Agents. These are RDS Collections where Session hosts or Application server reside. RDS farms can be used to silo applications for effective application performance and load management, deliver groups of RDS Hosted Applications using a single RDP session, or to deliver RDS hosted virtual desktops. RDS farms can contain physical or virtual servers.

See Microsoft’s RDS Documentation for assistance with configuring an RDS deployment.

Kasm Configuration

Kasm integrates with RDS as a single fixed server, follow the Fixed Server guide to add a Kasm Server that points to the RDS deployment. You will need to set the Maximum Simultaneous Sessions and Maximum Simultaneous Users on the server as appropraite for your deployment. Kasm only allows 1 desktop session per user per individual server, however, Kasm does allow for multiple concurrent RemoteApp sessions per user per individual server. Microsoft RDS CALs and other Microsoft licensing restrictions may apply.

In order for Kasm to support multiple concurrent users to the same backend deployment, single sign-on must be configured. See the Windows Authentication guide for details on configuring sign sign-on.

Desktops

From Kasm Workspaces perspective, an RDS deployment appears as a single fixed server that supports multiple users. For this reason, Active Directory integration is required so that Kasm users login to Workspaces with their Windows domain credentials and Kasm facilitates single sign-on to the Windows RDS deployment. Follow these steps to configure a Server that points to the RDS deployment and then a Workspace to provide users access.

Create a Server

  1. In the Kasm Admin Dashboard, navigate to Infrastructure->Servers.

  2. In the Server list, click Add

  3. Check the Enabled box.

  4. Provide a friendly name.

  5. Provide an IP address or hostname for the RDS deployment.

  6. Select RDP as the Connection Type.

  7. Provide a Connection Port, RDP uses 3389 by default.

  8. Follow the Active Directory integration guidance for the Connection Credential Type, Connection Username, and Connection Password fields.

  9. The Connection Info field allows you to optionally override settings that are not exposed in the UI.

  10. Specify a maximum number of concurrent user sessions that the RDS deployment can support. The number should be greater than 1.

  11. Choose a Deployment Zone.

  12. Optionally specify a server Pool. Using a pool will cause Kasm to distribute users between the servers in the pool.

Create a Workspace

  1. In the Kasm Admin Dashboard, navigate to Workspaces -> Workspaces

  2. In the Workspaces list, click Add Workspace

  3. Select Server from the Workspace Type drop down, unless you added the server to a pool in step 12 in the previous section.

  4. Provide a Friendly Name that will be displayed to users.

  5. Provide a description that will be displayed to admins.

  6. Optionally provide a URL to a thumbnail that will be displayed on the user dashboard.

  7. Check the enabled box.

  8. Select the Server/Pool from the dropdown.

  9. In the RDP Client Options dropdown, select one of:

    • Web native client to access the Windows instance using Kasm’s in browser access method.

    • RDP local client to access the Windows instance using the client endpoint’s RDP thick client software authenticated through the Kasm RDP gateway.

  10. Click Save

Users should now see the Workspace on their dashboard and be able to create sessions.

RemoteApps

Kasm supports connecting to RDS deployments configured with RemoteApps. Microsoft RemoteApp is a technology allowing users to work with remote applications. Coupling Kasm Workspaces with an RDS deployment and RemoteApp allows administrators to provide remote users access to Windows applications through a web native portal. The following walks through adding a server and adding a Workspace that uses the defined server to create a RemoteApp session.

Create a Server

  1. In the Kasm Admin Dashboard, navigate to Infrastructure->Servers.

  2. In the Server list, click Add

  3. Check the Enabled box.

  4. Provide a friendly name.

  5. Provide an IP address or hostname for the RDS deployment.

  6. Select RDP as the Connection Type.

  7. Provide a Connection Port, RDP uses 3389 by default.

  8. Follow the Active Directory integration guidance for the Connection Username and Connection Password fields.

  9. Specify a maximum number of concurrent users and maximum number of concurrent sessions that the RDS deployment can support. Both numbers should be greater than 1. For RemoteApp Workspaces, you may desire a configuration where the server can only have one concurrent user, but 10 concurrent sessions, allowing the user to utilize the same server for up to 10 RemoteApps at once. Microsoft RDS CALs and other licensing restrictions may apply.

  10. Choose a Deployment Zone.

  11. Optionally specify a server Pool. Using a pool will cause Kasm to distribute users between the servers in the pool.

Create a Workspace

  1. In the Kasm Admin Dashboard, navigate to Workspaces -> Workspaces

  2. In the Workspaces list, click Add Workspace

  3. Select Server from the Workspace Type drop down, unless you added the server to a pool in step 12 in the previous section.

  4. Provide a Friendly Name that will be displayed to users.

  5. Provide a description that will be displayed to admins.

  6. Optionally provide a URL to a thumbnail that will be displayed on the user dashboard.

  7. Check the enabled box.

  8. Select the Server/Pool from the dropdown.

  9. In the RDP Client Options dropdown, select one of:

    • Web native client to access the Windows instance using Kasm’s in browser access method.

    • RDP local client to access the Windows instance using the client endpoint’s RDP thick client software authenticated through the Kasm RDP gateway.

  10. Turn on the Enable RemoteApp setting.

  11. Provide a RemoteApp Friendly Name, which may be displayed to the user.

  12. Provide a RemoteApp Program Name/Path. Registered RemoteApp names must be prepended with double pipes, such as ||Microsoft Excel. See the Workspaces RemoteApp section for details.

  13. Provide any optional arguments to be passed to the RemoteApp program.

  14. Click Save

Group Policy Configurations

There are certain behaviors of Kasm Workspaces that may require GPO configurations.

Remove Logout

This setting will remove the logout button from the Windows desktop. Users should instead destroy their Kasm session from the session control panel or the Kasm user dashboard. An auto logout policy should be in place.

Remove Disconnect Button

Users should logout using the Kasm control panel. When the user uses the Windows disconnect button, it will disconnect the session and Kasm will display a disconnected blue screen. The user would then need to use the Kasm control panel to return to the dashboard. The Windows disconnect button can lead to confusion and it is recommended to be removed by GPO.

Auto logout

As of the current version of Kasm, when a user destroys a session, the user is not logged off the Windows server. If the VMs are static or multi-session, administrators should configure an auto logout policy, to automatically log a user out of Windows after an inactivity timeout.