Routine Maintenance Tasks

In this section we'll outline several routine tasks that you will need to perform when administering your Terminal Servers. First we will look at tasks that should be done on a regular schedule, and then we'll examine those that can be performed on an as-needed basis.

Scheduled Tasks

These tasks outline a simple maintenance plan that will allow you to keep your Terminal Servers in a stable and known state, predict performance problems, and allow you to do some trend analysis on our servers. No maintenance plan in a book can be completely comprehensive for any specific environment, so we're just attempting to impart some of the industry standards that are used in other Terminal Server environments.

Daily Maintenance Tasks

These are routine tasks that should be performed on a daily basis. For the most part they amount to simple monitoring, but this monitoring keeps you on top of your environment.

• Verify that you can connect to each server in your Terminal Server cluster. This ensures that the servers are up and responding to client requests.

• Check the server event logs. Checking the event logs on a daily basis lets you determine if there are system or application problems on a server prior to it being reported by the user. Often a problem is reported and a check of the event logs reveals that the problem has been happening for some time. You can also automate the process of event log checking with something as simple as TNT Software's Event Log Monitor or a higher-end solution from BMC orNetIQ. With even basic scripting skills, you can also these log files out on a scheduled basis and then view them from a single location instead of logging into each server or selecting the servers in Event Viewer.

• Check the help desk tickets for the day to see if any new problems are arising. If you have a large help desk using help desk management software, see if they are able to denote any problems with the Terminal Servers and send a report to you. This way you can identify problems with your server prior to them affecting everyone in the organization.

• Clear out any hung or disconnected sessions to keep them from eating up valuable CPU and Memory on your server. If you have short timeouts on these settings, this could be changed to a weekly task.

Weekly Maintenance Tasks

The following tasks should be completed on a weekly basis. These tasks generally fall into the "monitoring and trend analysis" set of tasks, but should be done to ensure that the servers are running properly and not seeing a huge increase in utilization.

• Based on the monitoring tools you've set up (see the previous section on Server Monitoring), gather a weekly report that shows the utilization for the week. It should include daily averages and a weekly average that can be compared against the previous weeks' reports.

• If you don't have an automated system for it, update your antivirus definitions. Most companies offer new updates once a week unless a severe virus is detected that requires an immediate update to the definitions. Your best bet is to ensure that your Terminal Servers are updated at least once a week. As always, remember that you should test new updates to be sure there is no ill effect on the Terminal Servers.

• Like it or not, you'll still need to reboot your Terminal Servers about once a week. Remember that these are not servers at all, but really workstations. Can you imagine not rebooting a user workstation for months on end? Now take that idea and multiply it by the number of users that use each server. Rebooting a Terminal Server flushes the system, keeps memory leaks at bay, unlocks "hung" profiles, and kills errant software processes. This ensures that a server doesn't "seem" to run fine for months only to blue screen one day because it is out of memory. In clustered environments, it's a good idea to stagger these reboots within the cluster. This allows the servers to be pulled out of the cluster one or two at a time and still lets users to connect to the remaining servers. To reboot a server, you'll probably have to disable logons several hours before the reboot takes place to ensure that no users will be affected.

• Immediately after a reboot is a perfect time to "clean up" the server. Generally what is done to the server at this point will depend on the applications you're running. Clean up tasks can be scripted and hooked directly into the reboot. It is impossible to say which tasks you will need to perform or which directories will need to be cleaned up, but a few industry standards are to clean out the spool folder, delete any unused profiles, and clean out any temp folders.

Monthly Maintenance Tasks

Check for any new hotfixes, security updates, print driver changes or other system updates that are required once a month or so.

• If you're still not using third-party printer software, install any new print drivers into the cluster. Once a month take that list of print drivers people have been asking for and test them, then add them to they cluster. Doing this once a month ensures that the number of drivers added simultaneously won't overwhelm your driver replication scheme.

• Check the current hotfixes and service packs that are available from Microsoft. Finding the new security fixes and "critical updates" can be done using Windows Update. Most people let Windows Update run on a test server so that they're constantly informed, and then they manually download and install them to the Terminal Servers. (Remember to test them in your lab first!)

• Schedule applications updates or changes. A common problem in Terminal Server environments is that changes are not scheduled, but instead applications and changes are just installed "whenever." This leads makes it hard to backtrack to the offending update when new issues are found. See the section in this chapter about Change Management for more information.

Quarterly Maintenance Tasks

Every few months you should take a look at the overall utilization of the environment and perform cleanup on the servers themselves.

• Perform some trend analysis. This is where all those weekly reports come in handy. Once a quarter is the time to sit down and look at the utilization on your servers. Compare your servers' usage from last quarter to determine if utilization is up and if you need to expand. These reports will also show you if certain servers are being underutilized and if there are inconsistencies in utilization across the cluster.

• Do some "spring cleaning" on the servers. A practice that is becoming more and more common in the industry is to completely rebuild or reimage your servers once a quarter. Just like workstations, a good rebuild helps to keep things running smooth. If feel that this is extreme, at least make sure that you have an up-to-date base image for the cluster to ensure that the image is up to date and ready to use for the deployment or recovery of servers.

Replacing a Terminal Server in a Cluster

Every so often it will become necessary to replace a Terminal Server in your cluster because a server had a hardware failure or because a server is being upgraded to a more powerful server.

The deployment method you choose for deploying your Terminal Servers (discussed in Chapter 14) will ultimately decide how easy it is to replace a Terminal Server. If you image your servers and you're replacing an existing server with a new piece of hardware, you may have to create a new image. If your server builds are completely scripted, you may have nothing to do other than simply to start the unattended installation process on new hardware. If you're handbuilding your servers, you'll need to ensure that the new server is configured identically to the other servers in the cluster (at least from the end users' perspective) so that they do not notice the change when load balancing routes them to the new server.

In any case, the following steps can be applied to bringing the new server into the cluster:

1. Build the new server and install all required applications (this can be hand built, scripted, or imaged). It may be a good idea at this point to build the server outside of its production OU if you're using policies to manage its Terminal Server settings.

2. Ensure the server accepts RDP connections and the applications are configured properly.

3. Ensure required print drivers are installed if they are not configured in the base image.

4. Bring the new server into its Terminal Server cluster by configuring the load balancing settings (as discussed in Chapter 7).

5. Configure the connection listener port settings, session directory settings, and license server settings (if these are not configured automatically via a GPO).

6. Move the server into its production OU to apply the GPOs.

7. Verify the server accepts connections via the cluster name.

Your environment might require more specific steps, but these basics shouldn't be missed. You wouldn't believe how often people add new servers to clusters only to find out weeks later that a slight misconfiguration meant that the server never started accepting user connections.