Since Horizon Cloud version 17.2 it’s mandatory (*) to configure an RDSH maintenance schedule for RDSH farms.

But what do all options mean? What settings are configured as default? And what are the recommendations?

In this blog post, I will explain all these options as well as some best practices!

Farm settings

Let’s create a new RDSH farm in the Horizon Cloud Admin Portal. We do this via the Inventory Menu, by selecting Farms.

Schermafbeelding 2018-03-22 om 18.35.09

Next, we click New. In the first tab, Definition, we fill in the Farm details, such as the farm name, the network, the number of servers and sessions, the Computer OU and so on.

Schermafbeelding 2018-03-22 om 18.36.23

Schermafbeelding 2018-03-22 om 18.38.57

Under Advanced Properties, we have to fill in the first field which can have an effect on the RDSH maintenance cycle:

  • Session Timeout interval – This option means the amount of time the user can have an idle session before the system forces a logoff, resulting in the loss of any unsaved data. An idle session can have a max lifetime of default 180 minutes before the session will be logged off. If no user activity occurs before the timeout interval is reached, a message indicates that the user will be logged off. If they do not click OK in the next 30 seconds, the logoff occurs. Any unsaved user data, such as documents or files, is lost. Please note, the user can still be active on his endpoint with this setting, except he’s not accessing his published resources from the Horizon Cloud environment.
    • Default value: 180
    • Recommended:  180 or 240 minutes. The default value is actually quite good, but in most projects, we agreed with the customer to increase the default value a little bit, to 240 minutes for example.

Rolling Maintenance

The second tab shows the Management page. It’s here we can configure the RDSH maintenance options.

Schermafbeelding 2018-03-29 om 10.16.02

The first field we can change is Maintenance Type. There are two options here, Scheduled and Session. 

Schermafbeelding 2018-04-02 om 19.27.19

With Session, we can configure the number of total sessions the farm can reach before it will go into maintenance.

The Scheduled option allows us to create a scheduled maintenance window which occurs every day or every week.

In both options, the maintenance window will only start if the last user has logged off. In most cases, the preferred scenario is Scheduled. Configure this to once a week in non-business hours, for example Sunday at midnight.  This way we are in control when the maintenance window occurs. This is especially helpful when there are monitoring solutions in place, because you can configure these solutions to disable monitoring during the maintenance cycle, so they do not trigger any events.

As stated above, if you choose the Scheduled day you can configure the Scheduled Hour.

Schermafbeelding 2018-04-02 om 19.37.58

Valid hours between 00 and 23 is required for Scheduled Hour. Please note, the configured Scheduled Hour is in the timezone of the endpoint you configure this setting. It can well be you configure this setting in a different region the Horizon Cloud service is consumed by the end-user.

We move on to Concurrent Quiescing Servers. This option configures the number of total servers in the farm which are allowed to start the maintenance cycle. At first, the RDSH server will go in “Draining Mode”, meaning the servers continue to work but do not accept any new connections. After the last user has logged off, the server will restart or rebuild (see below). The recommendation is to configure at least 30% of your farm to allow in quiescing state, because if you set this number too low, the total time of the maintenance cycle will increase. I have seen customer environments where the maintenance cycle was still busy when entering business hours.

The next field, Server Action, allows us to choose between:

  • Restart – Restarts the servers during the maintenance cycle.
  • Rebuild – Rebuilds the servers from the assigned Golden Image you have configured in the farm settings. This means the server(s) will get deleted and re-created during the maintenance cycle.

The Rebuild option doesn’t make any sense if you are managing the RDSH servers in a traditional way and push application and windows updates directly to the servers (with the SCCM client for example).

If you are updating the Golden Image on a monthly basis, as explained in my previous blog post, you can configure this option to Rebuild to ensure the RDSH servers are always in the exact same state. But please be aware, if you have installed any ad-hoc security updates, these can also be removed with this option.

Timeout Handling

The next fields we can configure are for the Timeout Handling.

Schermafbeelding 2018-04-02 om 20.14.12

We can configure the following settings:

  • Empty Session Timeout – The time in minutes for when the user is idle on his endpoint device. Please note, This isn’t the idle timeout for the session-based desktop or application. This setting can be configured to either “Timeout After” or “Never”
    • Default Value: Timeout After: 1 minute
    • Recommended Value: Timeout After: 60 minutes. The default value of 1 minute is a bit too low. Increase to one or two hours.
  • When Timeout Occurs – Configures the idle session to completely log off, or get in “disconnected” state. Disconnected means the user session is still preserved in memory and users are able to re-connect to their current session. Log off means the user will loose the activate session with the risk to lose their unsaved work. In this case, the user will have to re-logon and start a new session.
    • Default & Recommended Value: Disconnect. As stated above, the user can lose their unsaved work with the Logoff setting.
  • Log Off Disconnected Sessions – Determines when a disconnected session is automatically logged off. The options are: Never, Immediate and Timeout After.
    • Default Value: Never
    • Recommended Value: Timeout After: 120 minutes. If you configure the idle timeout in the previous setting to automatically reach a disconnected state in one or two hours, you can configure this setting to preserve the disconnected state for an additional two or three hours for example. This will give the user some additional time to reconnect to his session, should this be needed. Please note, If you configure this to Never, you might risk the sessions are never logged off and the maintenance cycle will never begin.
  • Max Session Lifetime – The total number of minutes the session can exist for each user.
    • Default Value: 10080 minutes (one week)
    • Recommended Value: One (1380) or Two (2760) days. Leave this value lower than your configured maintenance cycle Server Action. One day or a maximum of two days is usually more than enough.

Additional configuration

In addition to the RDSH maintenance configuration, there is another Best Practice you should take into account: Automatically log off disconnected direct RDP sessions.

In some cases, for example during troubleshooting, an administrator can have a direct RDP connection to a Horizon Cloud RDSH server using local administrator credentials.  As only BLAST and PCoIP sessions are being monitored by the DaaS agent, this means if an RDP session is still active or disconnected, the maintenance cycle will not begin.

The maintenance for (direct) RDP sessions cannot be configured through the Admin Portal. Instead, we configure the automatic logoff for disconnected RDP sessions through Group Policy:

Schermafbeelding 2018-04-03 om 17.21.48

Changing/Renewing the RDSH image

Another good thing to know is the procedure to change or renew the Golden Image in an RDSH farm.

If you change the Image, the RDSH farm rebuild process will start immediately. There is currently no way to schedule this in the RDSH maintenance cycle. Please be sure to perform this activity outside business hours.

Schermafbeelding 2018-04-06 om 11.25.49

Conclusion

VMware has made it very easy to configure and implement the RDSH maintenance in Horizon Cloud. The maintenance schedule is mandatory (*) so you must really think about what you need to configure before you do anything. Document (design) these steps and most importantly; discuss the options and agree with your customer before you implement anything.

(*) The schedule itself can only be avoided using this workaround (courtesy of Ela in the comments)