Cloud Automation Stack orchestrates the creation and management of Cloud Desktop environments in Google Cloud. Each environment, called a deployment, consists of several key components that work together to deliver a rich end-user experience for remote computing. The article describes the components at a high level; comprehensive details can be found in Technical Reference section of our documentation.
At its most basic, a Cloud Desktop deployment consists of the following key components:
- A Microsoft Active Directory domain
- Microsoft Remote Desktop Services
- A network file share for storing user profiles and shared drive data
Microsoft Active Directory is a identity and authentication platform (IdP/IAP) that is commonly used in Windows environments. Active Directory is a complex and powerful platform, but for the purposes of Cloud Desktop, it is used to store user account data and authenticate users when they log in. CAS also leverages Active Directory to apply group policy objects (GPOs) and perform some management activities such as using group membership to assign users to their respective Cloud Desktops.
Active Directory is a requirement for a CAS deployment. CAS offers several options for fulfilling this requirement; for more information, refer to Active Directory in CAS Deployments.
Remote Desktop Services
Remote Desktop Services (RDS) is the foundational pillar of Cloud Desktop. RDS enables multiple users to each have a dedicated, secure computing session on a single computer simultaneously. RDS also provides the underpinnings of certain CAS functionality such as Collection Pools and application publishing.
RDS has several distinct roles that must be present for the system to work; these roles are:
- Remote Desktop Session Host - A Session Host is a server that runs Cloud Desktop sessions. When a user runs a Remote Desktop or RemoteApp, a Session Host is the server where the desktop or application is actually running; the desktop or application is "streamed" to the end-user's client device via the Remote Desktop Protocol (RDP), allowing them to interact with the session as it if was running on their local device.
- Remote Desktop Session Broker - The Session Broker is the "brains" of an RDS environment. The Session Broker maintains the mapping of users to Session Hosts, monitors the status of Session Host servers, and routes users to the correct Session Host. The Session Broker also maintains the primary settings database for the RDS environment.
- Remote Desktop Gateway - The RD Gateway role acts as a "proxy" device that provides a secure way of accessing Session Hosts, particularly across the public Internet. When a user accesses their Cloud Desktop, they actually connect to a Gateway server using encrypted HTTPS; the gateway server then creates a separate, encrypted connection to a Session Host and "relays" the input and output between the end-user and their Cloud Desktop session. In this way, access to the internal network is extremely limited, and user sessions are protected via TLS when traversing the Internet.
- Remote Desktop Web - The RD Web role provides a browser-accessible web portal where users can log in to launch their RDS desktops and applications. The RD Web role also hosts the Remote Desktop Web Client, an HTML5 RDP client that allows users to access their Cloud Desktops directly from a web browser
- Remote Desktop Licensing - The RD Licensing role tracks the usage of Remote Desktop Subscriber Access Licenses (RDS SALs) in the environment.
CAS offers several predefined deployment types that configure these roles in different configurations, or administrators can create an Advanced deployment that allows full configuration of each role.
Network File Share
CAS deployments rely on a network file share to store users' roaming profiles and shared network drives created via the CAS console. In order to create a CAS deployment, an SMB file share must be available. CAS offers several options for satisfying this requirement, including:
- Dedicated Windows File Server - CAS can create a standalone Windows File Server with an expandable data drive that is automatically configured with secure network shares for user profiles and shared drives
- NetApp Cloud Volume Service - NetApp offers a managed solution for providing high-performance, maintenance-free SMB file shares in many Google Cloud regions.
- Shared Drive on a Session Host - For small deployments, CAS can configure the network file share role on a Session Host, although performance and scalability are slightly reduced
Depending on the configuration of your deployment, CAS will create and configure several other components in your GCP project. A more comprehensive list of deployment resources is available in the Technical Reference section of the documentation, but the following list provides an overview of several key components that may be part of your deployment.
- Google Cloud Load Balancer - If you deploy redundant RD Gateway servers, CAS will create an Internet-facing GCP load balancer instance for the RD Gateways in each region. The load balancer will be enabled for HTTPS traffic and will be configured as the connection point for your end-users
- Microsoft SQL Cluster - If you deploy redundant RD Broker servers, CAS will create a failover cluster instance of Microsoft SQL server in each region. A SQL instance is required to host the Connection Broker Database when the RD Broker is configured for high availability, and CAS configures a clustered SQL instance in order to eliminate any single points of failure.