After having deployed hundreds of thousands of Terminal Services seats worldwide, I still see all the time people asking me that same old question: "If TS/RDS is that reliable why are you telling me I should reboot it that often? My DC/SQL/Exchange/You_Name_it is never rebooted!!!"
To understand the reason for this you must first understand what a TS (Terminal Server, usually called RDS -- Remote Desktop Server) is. In laymen terms, it is simply a PC that allows multiple people to use it at the exact same time, each one with its own, unique environment (desktop, start menu, etc).
Compared to a regular PC, the main difference is one allows a single user to work and the other one, several (as many as the hardware can handle). So now, you must ask... What these users do?
Normally users will use their application programs. Off the shelf (Office, etc) and in-house ones, websites with plugins/applets and so on. The problem is, most applications will have their issues, several with memory leaks as an example. If you are using your PC, that you might reboot every week or month, and these issues may not show up because you are a single user.
On the other hand, a Terminal Server may have 50 users that are constantly using that one PC and its resources. So whatever leak you had on your PC -- say a small memory leak that might not become an issue for 50 days -- may become a problem in less than 24 hours on the TS! If 50 people are using the exact same app, over and over.
It is clear then the problem is not TS per se, but what you actually run on it. It is almost impossible to predict how every single application, printer driver and so on will behave under heavy load in a TS environment; you might need to spend months doing application monitoring/debugging to trace a memory leak, for example). The best and quickest fix is to have the TSs in a reboot schedule, so they can start fresh for your users. If you have multiple TSs (and you should, for redundancy purposes) this can be easily achieved without disrupting any users.
If you think this issue is not real, Citrix even added a feature on their XenApp/Presentation Server years ago to allow administrators to set a reboot schedule, exactly for this reason. The results offset the possible downtime (if any) and greatly enhance the user experience on the TSs.
How often should Terminal Servers be rebooted?
The bottom line is: That heavily depends on your applications and how they interact. As this is completely different from environment to environment, there is no "silver bullet" that will address everyone's needs.
To minimize the impact applications may have on the server stability, we recommend that you reboot as often as your business allows, without causing disruption. So for example if you have a daily window from 3:00am to 4:00am where you could reboot all TSs, go for it.
If you are a 24/7 shop what you can do is disable logons on some servers (let's say 1/3 of them) using something like "CHANGE LOGON /DISABLE", send a message to the users saying the server will be rebooted in 15 minutes, wait 15 minutes and then reboot it. All this can be acomplished using a scheduled task and a command file (batch). You would then move to the next 1/3 and finally the final 1/3 of your servers. This always gives you 2/3 of your servers up and running during a reboot window what potentially addresses your 24/7 needs.
Going one step further, in a properly setup TS environments we usually rebuild the TSs on a monthly basis using totally automated procedures. As an example, in one of my customers, with 32 TSs serving over 1400 users, we rebuild all of them in under 2 hours over the weekend, with no manual intervention whatsoever. The entire sequence is automated. So every 30 days users do get fresh TSs. That may be the subject for another article.
This course is ideal for IT System Administrators working with VMware vSphere and its associated products in their company infrastructure. This course teaches you how to install and maintain this virtualization technology to store data, prevent vuln…
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online)
The email signat…