Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

How to Reboot Terminal Servers

In this previous article I described why Terminal Servers should be rebooted on a regularly basis. Based on the reasons in that article creating a reboot schedule has become a best practice for Terminal Server environments. In this article I will describe the next step how to reboot the servers, which actions you should take during/after the reboot and how to create a reboot schedule.

Reboot the server Introduction




 

Rebooting a Terminal Server is not the most difficult task. But you should consider how noticeable he reboot should be performed in your infrastructure. For example what are you doing with logged on users. Do you warn the usage a defined time before the reboot, do you “close” the server a couple of hours before the real reboot or do you want to postpone the reboot if there are still users connected to the server. Determine the needs and wishes of your organization and add those in the rebooting process based on the following considerations.

Central v Locally

First of all you should consider the start location of the reboot scripts. This could be a central location or a locally on every server. Both ways have their advantages and disadvantages. Central stored location makes it easier to manage the scripts and to control the process. On the other hand if everything is stored in a central location and this location fails the complete process of rebooting is halted. For locally scripts the advantaged and disadvantages are reversible. A best practice I often use is to store the scripts in a central location and replicate those to the local servers and start the scripts locally.

Script Content

As mentioned before you should consider which options you would like to add in the reboot script.

Topics to consider are:

-          Disable logons on forehand

You should determine if you would like to disable logons on forehand before the server reboots and the time period before you reboot you disable the logons. This can be the first part of the script by simple use the change logon /disable command or use a specific load evaluator with the Scheduling rule activated using specific MFCom scripts (search on the internet for an example script). The time period should match with your connection settings (idle and disconnected times), so no users are logged on the server when the reboot will be performed.

-          Check if enough servers are available

You definitely also would like to have a minimum of available servers in your infrastructure to be online. It can happen (by a mistake) that something goes wrong and the servers which are rebooted are not getting in a production status or that servers are not available because of hardware disturbances. In such a case you would not to reboot other servers. An easy method to accomplish this is to perform a check in the reboot script to determine if the other servers are available. Although there is no method that 100% guarantees that the server is fully functional such checks are sufficient in most situations. For example you could create a text file with the names of the Terminal / Citrix server. Read the names out of this file and check if the server is available. For Citrix servers I use the SC command with the query option to check if the IMAservice is running, for Terminal Servers I use the result out of the QUERY TERMSERVER command to determine if the server is online. If a server does not respond correctly you should raise a counter. If the counter is above your defined maximum not available servers the reboot should be postponed.

-          Logging of the reboot process

When using locally executing of the reboot script I normally create a simple log file on a central location to easily determine if the reboots are carried out (or to see why the reboot did not run).

-          The executable to reboot the machine.

The best way to reboot the servers is using the default tsshutdwn.exe command available default in Windows 2003 or higher, because this executable is especially creates for reboot the servers.

Startup-script

Although starting up is pretty different then rebooting, it is strictly connected to each other. The best period to do automated maintenance is directly after the reboot, because no users are logged in and no files are locked. When creating a reboot strategy I also build a start-up script in which I clean the profile directory, temp directories, spool directories, replicating printer drivers, force an update of GPO’s and similar tasks.

Reboot Schedule (Creation)

Finally you should determine how many times and in which time period you would like to reboot the servers. There are several methodologies available like:

-          Rebooting an amount of servers a day (dividing the available servers over the available days).

-          Reboot the even server on the even days, while the odd servers are rebooted on the odd days (not using the 7th day).

-          Reboot the first half on Saturday and the other half on Sunday.

Whichever system you use you should not reboot all the scheduled servers at exactly the same time. If something goes wrong all those servers are not available anymore (and the check does not have much effort). I often use a 10 minute schedule to the other server is already available again, before the next server is rebooted. Again I use a file to set those time schedule so when the server is installed the reboot schedule is automatically added.

Conclusion

 

With this article I gave a brief overview which parts should be considered when implementing a reboot schedule. Also I gave some tips and tricks to add and use those components in your own infrastructure.