In CAS, many changes to RD Collection Pool settings are applied instantly and take effect immediately, pending Active Directory replication within the environment. However, certain changes behave a little differently and rely on several factors to take effect. This article will describe these scenarios, and the behavior to expect when making such changes.
Assigning a New Image to User Session Servers (RD Session Hosts)
When you change the boot disk image in a Collection Pool, you have the option to re-deploy the existing User Session Servers (USS) with the updated image:
If you do not select this option, CAS will only use the new image for additional USS that are provisioned as you add users to the deployment (or to the Collection Pool if you use the Custom Collection Sizing feature); this is useful if, for example, you use a package management solution to deploy software and patches to your existing USS and therefore do not need to replace the image on those existing servers.
If you do select this option, you can also select whether to schedule the re-deployment or to begin it immediately (the option appears after you click Save):
If you choose to re-deploy the existing servers, CAS will re-deploy the Session Servers using the following process (either immediately or at the scheduled time):
CAS will provision new OS boot disks with the updated image. Up to 10 new disks will be configured at a time; therefore, if you have, for example, 22 Session Servers, the servers will be updated across 3 batches.
In small batches (3-5 servers), CAS will decommission your existing Session Servers by removing them from the RDS deployment and unjoining them from the domain. CAS will power off the VM instances, remove the existing boot disk, attach the new OS boot disk, power on the machine, and join it back to the RDS deployment. The Session Server will preserve the same name, IP address, and instance information as it had before.
If you have applications defined in the CAS Applications Module and assigned to the Collection Pool, CAS will perform one of the following: if you have specified a standard OS image (for example, the windows-2019 image from the GCP catalog), CAS will create tasks to install each of the published applications on each of the new Session Servers; if you have specified a personal image (for example, a customized system image that you created in the CAS Images Module), CAS will assume all applications are installed and will not create these tasks. If the tasks are created, the process will continue when they are marked "Complete".
Steps 1-3 are repeated until all Session Servers have been replaced.
Generally, each batch of re-deployed servers takes about 15-30 minutes; if applications must be installed as part of Step 2, it may take longer. It is important to consider several things when re-deploying an image:
Any customization performed on the old Session Servers will not be preserved and must be re-applied to the replacement Session Servers. For this reason, we strongly recommend performing all configuration in the custom image, or using Group Policy Objects (GPOs) or similar tools to perform additional configuration if necessary. Note that this only applies to re-deployments with new system images; changes to Collection Pool resource settings (such as CPU and RAM) do not rebuild the server, and thus all configurations are preserved.
In large deployments, there will be a period of time when users may connect to either a new Session Server or an old Session Server. For example, if a Collection Pool has 15 Session Servers, the re-deployment will occur in 3 batches, each taking approximately 30 minutes; thus, after the first batch is completed, there is a period of time when the new Session Servers and the old Session Servers are coexisting, and any new connections to the Collection Pool may be routed to any server.
Because the Session Servers are updated "in-place", the Collection Pool's user capacity will be reduced as each batch of servers is decommissioned, updated, and re-joined. Thus, it is highly recommended to perform OS image updates during scheduled maintenance windows or off-peak hours.
Changing Autoscale Settings
The Autoscaling feature in CAS functions on a queue mechanism, where any changes that are performed as part of Autoscale-- either automatically by CAS or manually by an administrator updating settings-- are added in sequential order to a list of changes to be made. In normal usage scenarios this provides the best experience for our customers, because CAS operates in a predictable manner and resources are scaled based on demand as needed.
However, in rare situations this queue model may introduce undesired behavior. Consider the following scenario: a Collection Pool is configured with the Autoscale values below.
The administrator creates 200 new users in the deployment and then, a few minutes later, decides to change the Autoscale settings to the following:
In this scenario, CAS will have already queued an Autoscale task to create 8 new Session Servers (200 users / 25 users per host) with the old values. Even though the new values would alter the requirement and perhaps not require any new servers (depending on how many Session Servers already exist), CAS will first perform the Autoscale task to resize the Collection Pool based on the new users, and then perform the task to resize the Session Servers as defined in the new settings. This will result in the creation of 8 additional servers and then, after a few minutes, the servers will be rebooted to use their new resource settings, and the unnecessary servers will be deleted. This produces a lot of unnecessary "churn" in the environment and may disrupt the user experience.
Although this may not be a common scenario, it is important to consider an "order of operations" when making changes to the resource requirements for a Collection Pool.