Maintaining terminal servers (or remote desktop session hosts as they are known now) in today’s world when users require access 24/7 is a challenge. Setting up an RDS farm, with a session broker will give you load balancing and fault tolerance. (I will write more about remote desktop server farms and session brokers in another article)
However notice I say “Fault Tolerance” this doesn’t mean that you can reboot session hosts without affecting users, it just means that your system will tolerate the failure of a session host. The users who were connected to the rebooted (or failed) session host will lose what they were working on and will have to reconnect.
The nature of a session broker is that it will try to distribute sessions evenly across all members of a farm; this is great, apart from when you want to reboot a session host without annoying your users.
There is no “live migration” of RDS sessions, once a user is on a host, that’s where they will stay until they log off.
So how do you free up a session host to perform maintenance on it? Firstly you will need to plan your work in advance.
You can then use the “chglogon” command to begin “draining” sessions. There are many ways sessions can be drained, but it basically means the session host will stop accepting new connections. Eventually once your users have logged off, they will not be able to establish a new log onto the draining session host, so will establish a new connection on another session host, which mean eventually the session host you are draining will have no users logged into it.
There are four switches for the chglogon command:
/query – this will tell you what mode the session host is currently in
/enable – allows users to establish connections to the session host
/disable – doesn’t allow any new connections, or reconnections to an existing session.
/drain – doesn’t allow any new connections, but does allow users to reconnect to an existing session
/drainuntilrestart – does the same as /drain, but reverts to /enable after a reboot
NOTE: when using the /disable switch, this will prevent you reconnecting to the server via RDP. You need to ensure you have access to the console via another method other than RDP, or use the RD configuration utility from another RDS server to change the setting.
These commands could be utilised to help with automated updates. You could configure RDS1 to automatically install updates on a Saturday at 6PM, then create a scheduled task to run on a Friday at 6AM to run the chglogon /drainuntilrestart command.
This would hopefully mean by Saturday at 6PM there were no users left on RDS1 and it would be safe to automatically reboot after an update installation.
You could then use the same method with RDS2, RDS3 etc, but on different days to ensure 100% uptime of your RDS farm