Deploy a Single Application Through Terminal Services

My entire company revolves around a Web-based application that manages everything from finances and payroll to clinical treatment plans and document management. The software started as just a character-based emulator connected to a UNIX database, but over the years, the system's developers converted it to a Web-based solution and started adding more and more business processes into the system. However, even though it's running in a Web browser, it still requires about 12 programs installed on each desktop to work properly. Even worse, in the beginning, these 12 programs didn't work so well most of the time, often requiring a reinstallation of one or more components before everything worked right. After a Microsoft Internet Explorer (IE) or Java update, they'd break again. Then, a couple months later, the developers would release an update and with it some additional or replacement software for the desktop. The software had to be installed as an administrator. To make matters worse, we're a non-profit company operating on a razor-thin budget, and the IT director assumed our four-man department would just drive to all 20 locations and manually install the desktop software. As a freshly crowned Windows 2000 Server MCSE, I decided I'd just slap together an MSI file and let Active Directory (AD) solve my problem. After a number of failed attempts at producing a working installation file with the free tool that came on the Win2K CD-ROM, I decided to see what kind of Microsoft Terminal Services solution I could find.

You've probably heard that one of the new features in Windows Server 2008 is the ability to present single applications from a terminal server. That new feature is merely a very nice improvement. In fact, Microsoft Terminal Services—without the aid of Citrix—has been able to provide access to single applications for quite a while, and for those of you who will be using Windows Server 2003 or even Win2K Server for the foreseeable future, here's how to do it.

Step 1: Install and Configure Your Server
Unless you already have a terminal server running, you'll need to build your server. With this type of server, you really need to focus on performance. We use HP DL385 servers with twin Opteron processors and 4GB of RAM to support about 60 users per server with a full desktop. You don't have to go overboard, but be sure to size the system correctly for your environment. (Hopefully, the quad-core systems will have a decent price point.)

I highly recommend using RAID 1 configuration because it gives you some nice options down the road. For example, with a mirror, you can remove a disk whenever you're running a major update or performing any type of risky change to the OS or software. If something goes wrong, you can shut the system down, switch disks, and boot the system off the unchanged disk. Then, simply pop the changed disk in and let it resynchronize with the unchanged disk. If you don't have hot-swappable hardware RAID, the steps will be different, but the idea is the same. In fact, if it's a small deployment and you're using a software mirror, you don't even have to remove a drive. Just break the mirror and make your changes. If everything goes well, simply add the unchanged drive back to the mirror and let it resynchronize. Another reason I like using mirrors is that it makes building future new servers a pretty quick process—provided you have matching hardware. You'll need to use Sysprep to prevent duplicate SIDs with existing servers, and change the name and IP address of the new server, but that's about it.

Sufficient RAM is essential to a terminal server. Memory is fairly cheap, so I start with at least 1GB. How much you need depends on the amount of memory required by the applications you plan to deploy, multiplied by the number of users you expect to have on the system. I use Task Manager to get an idea of how much memory each user will consume. After you finish sizing and scaling your server, set your page file to double the amount of RAM—it's very important that the server not run out of memory.

Next, you should disable unnecessary services. Letting unneeded services run only wastes system resources. For example, why leave the Windows Audio service running on a server that won't have any sound applications? Some services, such as the Remote Registry service, expose features that could make the server more vulnerable to attack. You can easily disable services through the Control Panel Services applet. For more information about which services are OK to leave running and which should be disabled, see the Learning Path.

At this point, you should have a working Windows server that's ready to be converted to a terminal server. Open the Add or Remove Programs applet, click Add/Remove Windows Components, and add the Terminal Server component. (You'll need to insert the CD-ROM, or you'll need to have access to the \I386 folder.)

As users log off the server and their sessions close, some applications won't remove their handles to registry hives that were in use while the user was logged on. The result can be sessions not ending completely. Install the User Profile Hive Cleanup Service. In Windows 2003, you can see this phenomenon in the event log as an error—event ID 1517 or 1524.

You'll need to install Secure RDP. Even if you don't use any of the settings of this program, its log file is much more useful than the information you'll find in the Windows event logs. Also, the tool has some great filters and options that you can use to lock down your system and change the way it behaves. You'll need some of the options later to make sure the system resets old connections as users log on.

Because you'll be launching a single application from your remote desktop connection, you'll need to install a second network card so that you can still administer the server remotely. You'll need to assign a static IP to each NIC. This way, you can be sure which interface you're connecting to later. After you're done, one interface will be offering your application to clients and the other will be your remote connection to the desktop for administration.

Keep in mind that you now have a system that presents a logon screen over the network. I would definitely consider changing the default port and changing the name of the local administrator, as well as whether a domain administrator should even be able to log on remotely. You'll find plenty of online information about securing a terminal server. The Learning Path contains two good resources.

   Previous  [1]  2  3  Next