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). 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):

  1. CAS will provision new VM instances with the updated image. Up to 5 new instances will be configured at a time; therefore, if you have, for example, 22 Session Servers, the servers will be updated across 5 batches. This is to help mitigate CPU limits that you may have in your GCP project (more information below).
  2. 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".
  3. CAS will add the new Session Servers to the Collection Pool and make them available for connection. Up to 3 new servers are added to the Collection Pool at once, to ensure that the RD Broker has time to process the changes; therefore, if 5 new Session Servers were created in a batch, they will be added to the Collection Pool in two groups, with about a 2-minute delay between each group.
  4. Once all the new servers are successfully added to the Collection Pool, the old servers are removed from the Pool. Users that are still connected to the old Session Servers will receive alert messages in their session at 15, 10, and 5 minutes before they are automatically logged off. Once all users are disconnected, the old Session Server is removed from the pool and the VM instance is deleted.
  5. Steps 1-4 are repeated until all Session Servers have been replaced.

Generally, each batch of re-deployed servers takes about 10-15 minutes; if applications must be installed as part of Step 2, it may take longer. It is important to consider two 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 15 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.

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.

Google Cloud Project Limits

When you choose to re-deploy your Session Servers with a new image, there is a period of time that your deployment will effectively have twice as many Session Servers as normal. Depending on your Google Cloud Project quotas, this may cause you to reach a quota limit during the redeployment, even if your quota is adequate for normal operations. In these scenarios, itopia has found CPU quotas to be the most common limit that is exceeded; however, other resources may be subject to limits as well.

For most events that will affect your CPU count, CAS attempts to verify your quota limit before making changes; however, this is sometimes unsuccessful and you may receive an error on the event in the CAS console. If this occurs, you will need to increase your quota settings in GCP before resuming the task and in some cases you may need to request the quota increase from Google, which can take time. itopia recommends verifying your quota limits prior to making significant changes to your Collection Pool resources or redeploying a large number of Session Servers, as this will ensure that CAS can quickly perform the changes without waiting on quota increases.

Did this answer your question?