As networks grow and change, a problem that continues to plague administrators is how to deploy software to a certain number of desktops at a certain number of locations—with limited resources. IT guys have been coming up with creative solutions to this problem for quite some time. Some administrators fire up their Microsoft Systems Management Server (SMS) or Novell ZENworks servers, whereas others turn to Citrix server farms. These are great tools for pushing software to the desktop, but many of us don't need anything quite that comprehensive—not to mention expensive. If you need to deploy an in-house application, the option to make it Web-based might have been your decision from the start.
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.
|
SOLUTIONS SNAPSHOT SOLUTION: Build a Terminal Services environment to deliver these applications to end users at all locations WHAT YOU NEED: One server, Windows Server 2003/2000 license with CD-ROM, Terminal Services licensing server (can be installed on existing server), Terminal Services CAL for each user or device that will connect to the server DIFFICULTY: 3 out of 5 |
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.
Next, ensure that your new server is referencing a valid Terminal Services licensing server on your network. To do so, select Administrative Tools, Terminal Services Configuration, Server Settings. By default, your server will be in Automatic discovery mode. Terminal Services won't work after 60 days unless it can find a valid licensing server. Installing a licensing server isn't difficult, but it's outside the scope of this article. For information about setting up a licensing server, see the Learning Path.
If you're using Windows 2003, open the License server discovery mode setting under Server Settings. If you're in Automatic licensing server discovery mode, the server name will appear at the bottom of the window. You can also manually configure the licensing server. Win2K doesn't have a place to manually specify a licensing server. So, if you have trouble getting the server to recognize an existing licensing server, you'll need to specify a licensing server by accessing the HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters registry subkey. Add the value DefaultLicenseServer, of data type REG_SZ. Replace the ServerName data value with the NetBIOS name of the licensing server.
|
SOLUTIONS SNAPSHOT
|
Step 2: Set Up the Connections
Now, it's time to configure the connections. In Administrative Tools, open Terminal
Services Configuration and select the Connections folder. You should see the
default connection already installed.
For the purposes of this article, we'll use the default connection for administering the server and create a new connection for single application access. The trick is that each connection needs its own NIC. So, before you go any further, double-click the existing connection and go to the Network Adapter tab. Use the dropdown menu to assign this connection to one of the two NICs you installed during setup. Now is a good time to make all your other configuration changes, such as raising the encryption level on the General tab and permitting only administrators and members of the IT department to connect on this interface by changing the ACL to include only specific Windows users or groups on the Permissions tab.
At this point, you should be able to go back to your desk, connect remotely to the default interface, install your application, and complete the setup. To get connected to the server, open Remote Desktop Connection from Start, Programs, Accessories, Communications. On the Remote Desktop Connection screen, for Computer, enter the IP of the NIC you assigned to your connection. Click the Connect button and log on to your server.
Before beginning your installation, you need to open a command prompt and type
change user /install
This command moves user-specific .ini files to the system directory during the installation. Now, a master copy is available for other users. For more information, see the Microsoft article "Terminal Server Commands: CHANGE" (http://support.microsoft.com/kb/186504).
Now, install your application. After the installation is finished, go back to the command prompt and type
change user /execute
Go back to Control Panel, Administrative Tools, Terminal Services Configuration and right-click the Connections folder. Choose Create New Connection, which starts the Terminal Services Connection Wizard. Most of the wizard's options are self-explanatory. Just be sure to choose the second network adapter when you get to the end. Double-click the connection you just created to open the Properties window.
On the General tab, which Figure 1 shows, enter a comment that's descriptive enough to let other administrators know what the connection is for without having to tab through the properties. On this tab, you can also adjust the security settings and assign a digital certificate for running your connections over SSL.
On the Logon Settings tab, you can configure the type of logon you'd like to use. By default, the regular Windows logon screen will appear and users will need to enter their username and password to log on. However, if you're deploying an application with its own user-accounts database or you just don't care who uses it, you might want to configure this connection to automatically log on. Doing so will make your application launch more like a regular desktop application.
On the Sessions tab, which Figure 2 shows, you need to configure the options that tell the system what to do depending on the current state of the session. If you're not supplying logon credentials on the Sessions tab, select the first Override user settings check box and set the End a disconnected session check box to 1 hour. With these settings configured, end users who have closed the connection without logging off will be removed and memory will be returned to the system. If you're supplying a username and password for automatic logon, select the second Override user settings check box and click the End session radio button.
By default, once the user is logged on, the Windows desktop will appear and the user will need to launch the necessary application manually. On the Environment tab, you can configure the system to launch an application instead of showing the desktop. Select the Start the following program radio button, and enter the path to the application executable.
The Remote Control tab isn't useful for automatic logon, so skip to the Client Settings tab. Unless you're a singleLAN company, you'll want to adjust the color depth down from the default 16-bit to reduce the bandwidth your connection will require. For security reasons, many shops will want to also disable drive mapping. In fact, if you see something here that you don't think you'll need, just select the appropriate check box. (That's right, prepare yourself for some Microsoft backward-speak: You'll select items to disable them.)
If you're going to be using an account for automatic logon, you'll need to adjust the security access similar to the way you did before. Select the Permissions tab. Remove everyone but the Administrators group from the ACL, and add the account that will log on automatically. Click Apply, then Close.
There are just a few more details to take care of. From the MMC Terminal Services Configuration snap-in, select the Server Settings folder and ensure that Restrict each user to one session is set to No. If you forget this step, the automatic logon account will be able to log on only once. When the second person tries to log on, he or she will get a message stating that more than one logon is forbidden. Before you turn users loose, you should also take care of printers. Open an MMC console, and add the Group Policy Object Editor for the Local Computer Policy. Expand to Local Computer Policy, Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Client/Server data redirection, and click Terminal Server Fallback Printer Driver Behavior. Change the setting to Enabled, and configure the drop-down option to Show both PCL and PS if one is not found. Doing so will let your users print even if they don't have a recognized printer driver on their workstation.
Technically, everything is working and ready for end users to start logging on. However, if you're providing logon credentials, you need to make one more adjustment to ensure that sessions get closed in a timely manner. Open Secure RDP, and select Session Restrictions in the left pane. Click Sessions per User and select the check boxes to reset disconnected sessions. Next, choose to save and then apply the configuration from the File menu.
Step 3: Deliver to Users
Now, you've got a server ready to distribute an application that you'd otherwise
have to spend much time and energy determining how to deploy across the entire
network—not to mention updating and upgrading. To save a connection for
your end users, open Remote Desktop Connection again from Start, Programs, Accessories,
Communication; this time, type in the IP address or DNS name of the NIC associated
with the connection you created earlier. Click the Options button to expand
the window. Take a look at each of the tabs. Because users across a WAN will
be using this application, I recommend that you change the colors on the Display
tab to 256 Colors and allow only Bitmap caching on the Experience tab. On the
General tab, use the Save As button to save a shortcut to a location where users
will be able to access it. Make sure users have Read Only permissions.
You can now build a Web page on your intranet with a link to the shortcut you just created. As you deploy more applications this way, save shortcuts and add links to them on your new intranet application directory Web page. Once you've added the necessary links in your directory and verified that everything is working correctly, send an email message to the appropriate department managers with instructions for finding the link to the new terminal server connection.
Avoid Hassles
You now have a centrally deployed application directory. From this point on,
users will be able to access the software they need without requesting that
IT install it for them. Also, when the time comes to upgrade or update these
applications, you'll be able to do so by making the changes on your server—without
ever touching any of the desktops.