Remote administration has long been a challenge for administrators of Windows-based networks. Windows NT and its associated resource kits provide limited tools for performing remote administration, and the included tools don't offer much functionality or are not completely secure (e.g., NT's Telnet service). The problem isn't necessarily with the tools; rather, the problem is the lack of remote-administration support from the underlying OS and its services and components. Although graphical remote control tools, such as Symantec's pcAnywhere32, offer a solution, they're hampered by the additional per-server cost that they incur. In addition, these tools are limited by the significant bandwidth requirement of Windows' GUI.
Besides instability and rebooting requirements, the lack of command-line tools and built-in remote-administration support is the most common complaint I hear about NT. Windows 2000 Magazine contributing editor Mark Minasi sums up this troublesome predicament with a humorous observation, which I've heard him share at conferences: What do you use to administer a remote UNIX server? Telnet. What do you use to administer a remote NT server? A plane ticket.
Although the contrast between Windows-based OSs and command-line-friendly OSs such as UNIX is humorous to observe, the need for better remote administration in Windows-based servers is a serious matter. Fortunately, pressure from customers about NT's poor remote-administration support drove Microsoft to address this problem in Win2K.
Terminal Services to the Remote Rescue
Microsoft's solution for providing better remote-administration support was twofold. First, provide better command-line tools in the Win2K OS to reduce the number of tasks that require GUI access. To do so, the company introduced new command-line utilities, such as NetShell (Neth), and enhancements to NT command-line utilities. Second, accommodate GUI-based access to servers by leveraging and extending technology slated for the Win2K Server product family: Win2K Server Terminal Services.
Under NT, thin-client terminal services take the form of NT Server 4.0, Terminal Server Edition (WTS). This version of NT Server 4.0 has a multiuser-capable kernel that is significantly different from that of the other NT versions. You can augment WTS with additional services and features that Citrix MetaFrame provides. Although the primary focus of these products is to provide remote clients and Windows-based terminals (WBTs) with access to NT and Windows-based applications, they also offer administrators access so that they can remotely support the terminal server.
In Win2K, Microsoft included support for terminal services in the OS kernel for all the Win2K Server variants. In addition, Microsoft developed a special mode of operation specifically to provide remote administration capabilities to any Win2K server. This administrative mode doesn't have the licensing requirements of the regular terminal services mode, application server mode; you can simply enable Terminal Services in remote administration mode on any Win2K server without additional client-licensing costs. Although Terminal Services provides client support for only Windows machines, Win2K also provides 16-bit and 32-bit versions of the RDP 5.0 terminal services client. This inclusion means that Windows servers finally have full-featured built-in remote administration and control capabilities. Thus, buying remote control software and plane tickets is no longer a requirement for remote Windows server administration. (For information about remote administration options for non-Win2K Server machines in your network, see the sidebar "Remote Administration for the Rest of Your Network.")
Installing Terminal Services
Installing Terminal Services is a fairly straightforward process. You can install the service during the Additional Components portion of the Win2K Setup process or after the initial Win2K installation by using the Add/Remove Windows Components section of the Control Panel Add/Remove Programs applet. To install Terminal Services, simply select the Terminal Services check box, as Figure 1 shows. By default, selecting this option also installs the Terminal Services client software onto the server, as well as a utility for creating client installation disks. If you want to disable the installation of the client software and client installation disk creation utility, click the Terminal Services option and select Details. In the resulting window, you can clear the Client Creator Files check box. If you let Win2K install the client software, the OS will copy the software to the server's %Systemroot%\system32\clients\tsclient folder, which you can then share so that client installation files are accessible to remote clients.
After you select the Terminal Services check box and click Next, a configuration wizard, which Figure 2, page 44, shows, is launched and asks which mode of operation you want to configure: remote administration mode or application server mode. Unless you intend to license the server to run applications for users, select remote administration mode. Doing so configures the server to support two administrative remote client sessions without additional licensing requirements. Furthermore, this selection configures Terminal Services to minimize its impact on the server's performance.
Performance is an important consideration because remote control and terminal services software are traditionally resource-hungry applications. Remote administration mode assumes that you want to provide remote administration capabilities on the server without exacting a major performance penalty on users while administrative terminal server sessions are active.
Any Terminal Services installation onto an existing Win2K server (i.e., through the Add/Remove Programs applet) requires a system reboot before remote administration is possible. Although Win2K requires signfificantly fewer reboots than NT, Terminal Services is an exception to this rule.
Another Terminal Services installation option is that you can use unattended installation scripts to automate the process. This option particularly is useful if you're already using unattended installation scripts to deploy Win2K servers. You can perform unattended Win2K installations through unattended installation scripts launched using the winnt or winnt32 Setup /u option or through a Remote Installation Services (RIS)-based script. For information about unattended Win2K installations and RIS, see "Related Articles in Previous Issues," page 50, and Douglas Toombs, "Superior RIS," page 79.
To install and enable Terminal Services through an unattended installation, you use the \[Components\] and \[TerminalServices\] sections of an unattended setup file (e.g., unattend.txt). If these sections don't exist, you must create them. The \[Components\] section controls the installation of Terminal Services and the client software, and the \[TerminalServices\] section controls the Terminal Services configuration mode. Table 1 lists the keywords and default values for both sections. The following example shows these sections as they appear in a typical unattended installation file used to configure a remote administration mode-enabled server.
TSEnable = ON
TSClients = ON
Terminal Session Options
Although Win2K's Terminal Services works well under its default configuration, you might benefit from modifying the default settings. To configure a Terminal Services connection, you use the Microsoft Management Console (MMC)-based Terminal Services Configuration utility, which Figure 3, page 46, shows. This utility is in the Administrative Tools program group on a Terminal Services server or in the Win2K Support Tools installed from the Win2K Professional CD-ROM on a Win2K Pro system.
For example, you might want to change the encryption the connection uses for RDP client session data to and from the server. By default, Win2K terminal server client sessions use medium-level encryption, which means Terminal Services uses 56-bit standard key strength encryption to encrypt the terminal server client session data to and from the server. Low-level encryption also uses a 56-bit key strength, but Terminal Services encrypts only data sent from the client to the server. Using high-level encryption, Terminal Services encrypts data to and from the server by using a 128-bit key strength (assuming both the server and client support this key strength). As you might imagine, the penalty for increasing the encryption strength is performance—stronger encryption means slower client sessions. In contrast, setting the encryption level to low will improve performance but might impose undesirable security risks because data that Terminal Services sends from the server to the client is unencrypted.
To change the encryption level, right-click the RDP-Tcp connection listed in the console's right pane and select Properties. In the resulting RDP-Tcp Properties window, which Figure 4 shows, you set the encryption level in the Encryption section on the General tab.
Other remote-administration-related settings that you might want to modify include options on the Sessions tab of the RDP-Tcp Properties window. Sessions options relate to how Terminal Services handles client session timeouts and disconnections. For example, you can configure Terminal Services to override client-side settings for values such as session time limits for active or idle sessions, whether to end or disconnect expired sessions, and how and when to end user-disconnected sessions. Other useful tabs include the Permissions tab, which lets you configure which users and groups have access to the Terminal Services server, and the Remote Control tab, which lets you configure session shadowing.
Another Terminal Services management activity you'll need to occasionally perform is managing remote client sessions. To do so from a Terminal Services-enabled server, you use the Terminal Services Manager, another utility in the Administrative Tools group. This utility, which Figure 5 shows, lets you perform administrative duties on the server, such as resetting active, idle, or disconnected user sessions; ending running processes; sending messages to connected users; and getting user session status. You can also use this utility to perform session shadowing, the ability to remotely view or control a user's terminal session from the terminal server. (Citrix first introduced this functionality in its ICA-based terminal service products; Microsoft mimics the functionality in Win2K's RDP-based Terminal Services.) This feature might be useful, for example, if you discover a suspicious administrator connection that you want to observe or for training a new administrator from a remote location. Another useful aspect of the Terminal Services Manager is that, like most Win2K administration tools, it's enterprise-friendly and lets you manage not just the local server but all Terminal Services-enabled servers in your enterprise.
TSAC: RDP Terminal Services Meet the Web
Microsoft sometimes over-hypes products that turn out to be whopping disappointments, and other times the company slips crucial and useful features into new service packs or upgrades without fanfare. An example of the latter is the Terminal Services Advanced Client (TSAC), which Microsoft ships on the Win2K Service Pack 1 (SP1) CD-ROM and provides for download at http://www.microsoft.com/windows2000/downloads/recommended/tsac. (TSAC isn't part of the service pack installation and isn't in the Web-downloadable version of SP1.) TSAC provides Win2K's RDP-based Terminal Services with a Web-based client, a feature that earlier Windows versions lack.
TSAC is an add-on for any Win2K or NT 4.0 server running Microsoft Internet Information Server (IIS) 4.0 or later. Installing TSAC on an IIS server enables the server as a Terminal Services gateway of sorts; a system that can distribute and direct Web-based Terminal Services client sessions.
The client side of TSAC works as follows: A remote client using Microsoft Internet Explorer (IE) connects to a TSAC-enabled IIS server that connects the client to a page, which Figure 6, page 48, illustrates, that lets the client connect to a Terminal Services server within the organization. At that point, the IE client also downloads an ActiveX version of the RDP Terminal Services client that ships with Win2K (if the client doesn't already have it). After downloading the software, the client can run terminal server sessions within the browser window or full-screen.
What makes the TSAC client particularly useful is its accessibility. You can easily distribute the client to and run it from within any IE browser that permits downloading and running ActiveX controls. In addition, TSAC extends the accessibility of Terminal Services for administrators because you can theoretically perform remote administration from any IE Web browser that can access the server.
Be aware that TSAC doesn't fundamentally change the way that clients connect to Terminal Services-enabled Win2K servers. Although the TSAC-enabled IIS server provides a connection point to Terminal Services servers, the TSAC-hosting IIS server doesn't need to be running Terminal Services. The IIS server is simply a distribution and connection point for remote clients. In addition, although clients connect through this TSAC-enabled gateway Web server, the final connections between the remote client and the server are ultimately made directly and not passed through the Web server. As typical RDP Terminal Services traffic does, these sessions use TCP port 3389, which you'll need to permit through your firewall if you're supporting Internet-based TSAC or typical Terminal Services connections.
TSAC isn't the only Web-based RDP client. HOB's HOBLink JWT (Java Windows Terminal) is a Java-based RDP 5.0 client that can access any RDP-based terminal server, including Win2K Server and WTS (see Jonathan Chau, "HOBLink JWT 2.1," January 2001). This solution provides an alternative for non-IE users and those interested in additional features that TSAC doesn't provide. For more information about TSAC, see "Related Articles in Previous Issues," page 50.
Four Heads Are Better than One
By default, TSAC connections use an HTML file called default.htm, which contains VBScript code sufficient to display a terminal server session within the browser window. However, while perusing my Web server's TSAC-related files, I happened upon another file called manyservers.htm. A quick review of the TSAC documentation revealed that Microsoft included this file as an example of how to display multiple Web servers within one browser window. I thought this capability might be useful for administrative purposes, so I connected to the TSAC server, this time specifically referencing the manyservers.htm file in the URL.
Manyservers.htm displayed four terminal server windows in one browser page. However, all four connections were to the same server, which isn't very useful. In reading the documentation and examining the HTML file, I discovered that this file is an incomplete product that isn't well documented and doesn't quite work as advertised. Unwilling to be daunted by the disappointing performance of manyservers.htm, I decided to attempt to modify the file to work the way I originally expected it to: Display four windows representing connections to four servers in one browser page. My experiment was successful, and after some tweaking, I managed to get the page to query for and display as many as four separate servers on one page. I have since used this page, which Figure 7 shows, on the road in situations in which I want to examine several servers at once.
The modified manyservers.htm code that I created, which Listing 1 shows, generates this four-server administration console. If you decide to similarly customize your manyservers.htm file, before you start, rename the original file or at least back it up. Also, if you want to display your company's logo, change the HTML tag in Listing 1 that refers to MYLOGO.bmp to the file of your choice. You can also simply omit this tab if you don't want to display a graphic on the page.
A New Day for Remote Administration
The introduction of Terminal Services and remote-administration mode as standard offerings in the Win2K Server product family brings a new level of manageability to Win2K. The SP1-provided TSAC further enhances the usability of Terminal Services by providing a Web-based client that you can use to remotely support your servers from virtually any location. Although Terminal Services doesn't resolve the desktop-side of the remote-administration equation, third-party freeware, shareware, and commercial products on the market provide these features at little or no cost. If you haven't done so already, I highly recommend enabling Terminal Services remote-administration mode on every Win2K server in your enterprise.
|Related Articles in Previous Issues|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com.|
Terminal Services and TSAC
"Tools for the Control Freak," May 2000, InstantDoc ID 8400
Remote Possibilities, "Win2K Server Terminal Services and TSAC," December 2000, InstantDoc ID 16014
RIS and Customized Installations
"Advanced RIS Management," March 2001, InstantDoc ID 19678
"Understanding Remote Installation Services,"
February 2001, InstantDoc ID 16432
"Customizing Unattended Win2K Installations,"
January 2001, InstantDoc ID 16219
Inside Out, "Using Win2K's Remote Installation Service,"
September 1999, InstantDoc ID 7109
Virtual Network Computing
Reader to Reader, "Remotely Control Any NT Machine," January 2001, InstantDoc ID 16162 LARRY SELTZER
"Virtual Network Computing 3.3.3r7," Winter 2000, InstantDoc ID 15673