Overview
After you've completed the CAS Deployment Wizard and your resources have been provisioned, there are a few more tasks that need to be completed before your users can begin using their Cloud Desktops. Additionally, there are some tasks you may wish to perform to customize your environment before making it available to end-users. This article will describe post-deployment tasks in two sections: required and optional.
Required Tasks
When the Deployment Wizard completes and your new deployment has a green status icon (see illustration below), your infrastructure resources in Google Cloud will be ready for use. However, before your end-users can begin using their Cloud Desktops, administrators must complete a few more steps.
Create the First Collection Pool
Most deployments will have also created their first Collection Pool during the Wizard; however, if this step was not completed in the wizard, at least one Collection Pool must be available in the deployment. A Collection Pool is a unique configuration of Cloud Desktops for a group of your users; you can use a single Collection Pool for all your users or maintain multiple Collection Pools for different users based on their needs.
For more information and instructions, refer to Collection Pool Configuration.
Add Users
Before your users can access their Cloud Desktops, you must add them CAS and assign them to Collection Pools. You can create new users directly within the CAS admin console (cas.itopia.com) individually or in bulk, or import existing Active Directory users.
For more information and instructions, refer to Creating, Importing, and Managing Users.
Optional Tasks
In addition to the tasks above, many organizations choose to perform the following additional configuration before using their Cloud Desktop environments. These optional tasks can be performed at any time after a deployment is created.
Create Custom OS Images
When you create a Collection Pool, you must specify an OS image to be used by your Session Hosts. By default, CAS offers public OS images provided by Google Cloud; these images are "vanilla" operating systems that contain no applications or customizations, only the drivers necessary to run in Google Cloud. You may use these images and use third-party package management apps to install your required applications on each new Session Host as it is created, however many organizations find it easier to create customized images that contain their applications and assign these to Collection Pools so that Session Hosts are created with the applications preinstalled.
For more information on creating and deploying custom OS images, refer to Images Module.
Set a Custom External Name
When you create a new Cloud Desktop deployment, CAS automatically assigns an external DNS name to your deployment; this DNS name is the public access point for your deployment:
The RD Gateway servers accept RDP connections at this address
For RDS-based deployments, the RD Web and RD Web Access interfaces are accessible at this address
The external DNS name that CAS assigns is unique to your deployment, in the format [deployment code].cloudvdi.net. CAS secures this endpoint with a trusted SSL certificate to ensure that all connections are encrypted and secure.
NOTE: In a multi-region deployment, each region gets a unique external DNS name, in the format [deployment code]-[GCP region].cloudvdi.net |
If your users leverage the MyRDP Portal to access their Cloud Desktops, it is very likely that they may never see this external DNS name. However, if your users access the RD Web or RD Web Client, they must use this external DNS name to do so. If your organization wishes to customize this address, you may specify a custom name for each region.
Configuring a Custom External Name
After a Cloud Desktop deployment is created, you can change the external domain name for each region to a custom value. For example, a multi-region deployment could be configured as remote.contoso.com and remote-backup.contoso.com, or even as remote.contoso.com and remote.fabrikam.com.
Prerequisites
When configuring a custom external domain name, you will need the following:
Approximately 10-15 minutes of downtime, during which users cannot connect to their Cloud Desktop, and existing connections may be disconnected
A public DNS domain your organization owns
Access to create DNS A records in your domain
Server names for each region
An SSL certificate for the External Domain Names in PFX format. See additional information on certificate requirements below.
SSL Certificate Requirements
The type of SSL certificate depends on your deployment and the external domain names you are configuring:
For a single-region deployment, a standard "single-subject" SSL certificate is adequate, with the subject matching the External Domain Name you have chosen for your deployment such as remote.contoso.com
For a multi-region deployment where all regions will use the same DNS domain, a wildcard or subject alternative name (SAN) certificate can be used. For example, if all regions will use external domain names in the contoso.com domain, you may either use a wildcard certificate for *.contoso.com or a SAN certificate with the specific external domain name for each region, such as remote-us-east.contoso.com, remote-us-west.contoso.com, remote-europe.contoso.com
For a multi-region deployment where regions will use different DNS domains, a subject alternative name (SAN) certificate can be used. For example, if your chosen external domain names are remote.contoso-us.com and remote.contoso-europe.com, you can use a SAN certificate with each of these names explicitly defined as either the subject or a subject alternative name.
In every scenario above, you must upload the certificate separately for each region; you could therefore use different SSL certificates for each region, rather than using wildcard or SAN certificates. For ease of management, itopia recommends using a single certificate for all regions, but this is not required.
itopia recommends using the newer ECC SSL certificate type rather than RSA SSL certificates; ECC is a newer algorithm that is more secure and more efficient. However, very old operating systems such as Windows XP and Windows Server 2003 do not support ECC; if you may have end-users connecting from older operating systems (10+ years), you should continue to use RSA certificates. itopia recommends a minimum RSA-2048 or ECC-256 certificate.
NOTE: Remember that wildcard SSL certificates do not apply to subdomains. For example, a wildcard certificate for *.contoso.com WILL NOT be valid for remote.us.contoso.com and remote.europe.contoso.com. This is an inherent and intended limitation of SSL certificates. |
Configure a Custom External Domain Name
Log into the CAS admi console (cas.itopia.com) as a Deployment Editor or Owner.
Go to the deployment’s Dashboard.
In the left-side menu, expand the Settings module and select Regions.
Expand the desired region by clicking the expand icon (▾).
In the External DNS Name field, enter your chosen custom name.
Copy the External IP Address value. You will need this value to create the DNS A record later.
Click Upload and locate your SSL certificate on your local device.
A new Password field will appear. Enter the SSL certificate password.
Click Save.
Create a DNS A record in your public DNS zone for your chosen domain name. The A record should point to the IP address you noted in Step 6.
Repeat this process for other regions as desired.
CAS will begin updating the configuration for that region, resulting in approximately 5-15 minutes of service disruption; this may be longer if your new DNS records require time to propagate across public DNS servers around the world. If any failures occur, the CAS admin will be notified in the Notifications module in the CAS portal.
NOTE: If any users had saved their RDP connection file prior to this change, the settings in those files will continue to point to the previous external name, which will no longer be valid. Please make sure that after changing the deployment's external domain names, users download new RDP connection files at myrdp.download. |