By focusing on high availability, your environment will be able to survive the small day-to-day events that occur. However, you'll still need to have a solid backup strategy that kicks in when there is a major disaster or component failure.
Focus your back ups on the unique data. Since there should be no user data stored on a Terminal Server, you shouldn't need to back up the Terminal Servers the way you do normal servers. You do need to back up:
- User profiles.
- User home drives.
- Application data.
- Terminal Services Licensing Service Database.
- One Terminal Server from each load balanced group (if you do not use server imaging to deploy new servers).
If you don't use server imaging, backup a single server that you can use as a master to restore a failed server. Since Terminal Servers should not contain any unique data, you should be able to restore any server image to any target server within the same silo. (See Chapter 5 for more information about silos.) This allows you to have a quick recovery in the event of a Terminal Server failure. Store the server images on the SAN or the network. Then, if one should fail, kick off an automated process to restore it.
Make a bootable DOS floppy disk with an autoexec.bat file that connects to the SAN and kicks off the server imaging process. You can configure it so that a server is imaged with a generic name and IP address and then a lookup file is accessed based on the server's MAC address and the proper server name and IP address are automatically set after the imaging process is complete.
Many companies print step-by-step restore instructions and put them and the bootable floppy disk in a safe location. That way, they are always available in the event of an emergency. You might use a red-colored floppy disk and place it behind glass, for an "in case of emergency, break glass" effect.
Alternately, many of the new blade servers have auto-provisioning software available that can automatically detect a failed server and initiate the rebuilding process. Some environments that use this have less than a one hour turnaround time from the instant a server fails until it is rebuilt and ready to go.
Backing Up the License Database
Fortunately, it's easy to back up most of the components of Terminal Server environments that require it. However, backing up the license database is not intuitive. If you ever lose the server that is hosting the Terminal Services Licensing Service, you're officially supposed to contact the Microsoft license clearinghouse to get your licenses restored.
This is generally acceptable, because if you have a disaster you can easily build and activate new a TS Licensing Server. (Remember that for good redundancy you should already have an "extra" licensing server ready to go.) As soon as you do this it will immediately start handing out 90-day temporary TS CALs, meaning that you essentially have 90 days to get everything straightened out before your environment would stop working.
However, it is possible to back up the TS licensing database by backing up the "LServer" directory on the license server. This directory is in the location that you specified during the installation of the TS Licensing setup, %systemroot%\System32\LServer by default. The TS licensing database is similar to a Microsoft Exchange database. The LServer directory contains a couple of .edb files, a few .log files, and a .chk file.
If you ever need to restore a TS licensing server, rebuild the server with the same name as the old server; install the TS licensing service; stop the service; copy the contents of your backed-up LServer directory into the new LServer directory; and start the service.