Windows' native management tools have improved over the years, letting administrators control most network services from their workstation. Even administrators who work with Windows NT, which lacks Windows 2000's all-in-one Microsoft Management Console (MMC), can manage remote DNS, DHCP, WINS, and other services from their desktops. Yet despite Microsoft's improvements, you might still need to perform some tasks (e.g., hotfix installation, server restarts, file management) from the server console.
That's where remote control tools come in. Remote control tools are invaluable for managing the servers in your company's branch offices and for responding to late-night server problems from the comfort of your home office. In today's atmosphere of heightened security, remote control tools can also let your servers stay safely locked in a data center while you perform maintenance and management tasks from your desk.
Remote Control vs. Remote Administration
Remote control tools fall into the larger category of remote administration tools. Remote administration tools, as the name implies, let you perform administrative tasks on remote servers. For example, you can use the Microsoft Windows NT Server 4.0 Resource Kit's Shutdown utility (shutdown.exe) to shut down and restart network servers and the rkill.exe utility to terminate processes that are running on a remote server. Remote control tools give you control of a server's desktop across the network to let you perform remote administration tasks. Instead of running commands on your workstation that affect the server, you run commands on the server itself, even though you might be miles away from the server's keyboard and monitor.
Several useful remote control tools—many of which are free or inexpensive—are available that let you perform common or crucial server-administration tasks without leaving your seat. I divide these tools into two subcategories:
Terminal Services
Win2K Server included Microsoft's first built-in remote control technology, Terminal Services. Previously, Terminal Services was available only in a special edition of NT called NT Server 4.0, Terminal Server Edition (WTS). Although Microsoft intended Terminal Services primarily as an application server technology (like the Citrix WinFrame product from which it's descended), Terminal Services also offers a remote administration mode that lets up to two administrators simultaneously control a server's console across a network connection.
Win2K Server doesn't install Terminal Services by default, although you can install and use the service in remote administration mode as part of your basic product license. (Windows .NET Server—formerly code-named Whistler—makes remote administration mode a default installation component.) Since Win2K's introduction, I've recommended that administrators install Terminal Services in remote administration mode on every Win2K Server machine they deploy unless they're using VNC, which I discuss later. Installing Terminal Services is easy. Just open the Control Panel Add/Remove Programs applet, then click Add/Remove Windows Components. Select the Terminal Services check box, then click Next. When the Windows Components Wizard asks which Terminal Services mode you want to use, select the Remote administration mode option.
After you've used Terminal Services, it's hard not to love it. The Terminal Services client lets you launch multiple windows to remotely administer several servers at once. You can run the Terminal Services client software on most versions of Windows, including NT 3.51 and Windows 95. Third-party vendors (e.g., Citrix) provide client software for non-Windows platforms. You can also run the client full screen, which makes your desktop computer seem to be the server's console. For more information about Terminal Services, see "Related Reading."
Virtual Network Computing
VNC is one of the quiet hits of the systems administrator world: Either you know about it and love it, or you've never heard of it and don't know what all the fuss is about. In a nutshell, VNC is a cross-platform remote administration tool that brings a server's desktop display to your workstation, no matter which OS the server is running. Figure 1 shows VNC connected to a remote Win2K Server machine.
AT&T Laboratories Cambridge cre-ated VNC, and the tool is free under GNU General Public License. (For information about the GNU General Public License, go to http://www.gnu.org/copyleft/gpl.html.) You can download VNC from http://www.uk.research.att.com/vnc/index.html. Documentation, source code, and other information are also available at that site. When you download and unzip the distribution file, you'll find subfolders for
Launching the viewer is easy: Just double-click it and type the name of the server to which you want to connect. If the remote server is already running the VNC server software, you'll be remotely controlling it in a couple of seconds.
Installing the VNC server is only slightly more complicated. Double-click setup.exe and follow the installation wizard's prompts to install both the server and the viewer. At this point, you can use the server only in interactive mode, which means you have to launch it manually. Having to manually launch the tool isn't desirable for remote server administration: You really want the VNC server to run automatically. Fortunately, clicking an icon in VNC's Start Menu folder installs VNC for Windows (WinVNC) as a service configured to run under the Win2K or NT 4.0 LocalSystem account and start automatically when the server starts. (Automatic starting is a function of the OS and doesn't work on every system; for example, the functionality isn't available on Macintosh.) Restart your server or, if you're using the service for the first time, start the service manually; VNC will prompt you to set its session password and other configuration settings, as Figure 2, page 30, shows.
Your new VNC server is now ready for use. Open the VNC viewer on your workstation, provide the VNC server's name and session password, and you're ready for remote administration. By default, VNC allows only one remote connection to each server. If a new connection is requested, the VNC server automatically disconnects the existing session to allow the new one. This behavior can be disconcerting if you're in the middle of a task on a server and another administrator connects. In addition, VNC doesn't log you off when you disconnect, so the other administrator will see what you've been up to. VNC's documentation explains how to configure a VNC server to accept shared connections. If you follow those steps, additional administrators will be able to connect to the server at the same time as you, and you'll all see the same remote desktop.
This behavior is the biggest difference between Terminal Services and VNC. With Terminal Services, two administrators can connect to a server at the same time, and each administrator can work in a unique desktop environment. With VNC, two administrators can connect, but they'll have to share control of the mouse and keyboard on the same desktop.
Terminal Services or VNC?
In light of Win2K's bundled Terminal Services technology, should Win2K administrators care about VNC? Absolutely.
In a pure Win2K environment, Terminal Services is probably the best answer. After all, it's free, bundled on the Win2K Server CD-ROM, and provides a decent remote administration experience. These days, though, very few environments are built around one OS. VNC's biggest advantage is its cross-platform support, which lets you use one remote administration client to administer servers running Win2K, NT, Linux, and various flavors of UNIX. That kind of flexibility is hard to beat, especially for free.
From a performance standpoint, both VNC and Terminal Services offer low-impact remote administration. These tools typically use a fraction of the CPU, very little memory, and almost no additional disk I/O. They're head and shoulders above more desktop-oriented solutions (e.g., Symantec's pcAnywhere). VNC also provides strong security by using a challenge-handshake authentication protocol not unlike Microsoft Challenge Handshake Authentication Protocol (MSCHAP), NT's native authentication protocol. Also, both VNC and Terminal Services offer a Windows CE—based client, opening possibilities for truly portable remote administration.
VNC and Terminal Services do have a few important differences, however. These differences lie in the areas of remote desktop control, product support, OS restrictions, and speed.
Remote desktop control. As I mentioned earlier, VNC provides only one remotely controlled desktop, regardless of how many connections you allow. Terminal Services allows two remote administrators to connect and provides each administrator with a unique desktop.
Product support. Unlike Terminal Services, which comes backed by Microsoft's substantial support services, VNC is an unsupported technology. However, you can download VNC's source code, which lets you customize the tool. Terminal Services' source code is obviously harder to obtain.
OS restrictions. The Terminal Services server software is available only on Win2K Server and later. However, the client software runs on almost any 32- or 16-bit platform. VNC viewer and server run on almost any 32-bit Windows OS, including NT Server 4.0, NT Workstation 4.0, and Win9x. The viewer and server also run on NT 3.51 (in a limited fashion). I was even able to run the VNC server successfully on .NET Server beta 3. VNC server and viewer also run on Linux and UNIX systems.
Speed. Remote administration with VNC is a bit slower than with Terminal Services. Sometimes, you have to wait while VNC updates the remote screen display.
Remote Command
Microsoft has included Remote Command (rcmd.exe) in Windows Server resource kits for quite a while. You can think of Remote Command as the command-line version of Terminal Services or VNC: It lets you execute commands on remote servers. If you're the type of administrator who would much rather fire off a Net Use command than use the UI to map a drive, you'll love Remote Command. Also, for quick tasks that you can accomplish from the command line, Remote Command is much faster than establishing a Terminal Services or VNC connection, logging on, and using the UI.
Remote Command has two components: rcmd.exe (the client-side component) and rcmdsvc.exe (the server-side component). Together, these two components let you log on to a remote server's command line, execute commands, and log off again. You can also initiate a single-command session that automatically logs on, executes one command, and logs off. For example, the command
logs you on to Server1 and share D:\users\maryj as MaryJ$. Remote Command also lends itself to scripting, letting you execute on your workstation scripts that perform administrative tasks on one or more remote servers. Because most Microsoft products offer command-line alternatives to their GUIs, you can use Remote Command to perform most tasks.
Remote Command uses fairly simple security. On the client side, users log on to the remote machine by entering the same credentials they use to log on to their local machine. Users must have the right to log on interactively to the remote computer, and anything they do is executed under their credentials. On the server side, Remote Command runs under the LocalSystem account by default. Remote Command allows up to 10 simultaneous connections, providing a unique and independent command-line shell for each connection.
Because Remote Command runs under the LocalSystem account on the server side, the tool has difficulty executing commands that require it to connect to a different server. For example, if you want to use Remote Command to execute a Net Use command and map a drive to a network share, you need to specify alternative credentials for the Net Use command to execute properly.
Telnet
Telnet comes to us from the UNIX world, in which it's considered a standard administrative tool. Telnet works much like Remote Command: It lets you use a command-line interface to access remote servers. However, unlike Remote Command, which is unique to Microsoft, Telnet is open-standards based. You can get Telnet clients for Palm PDAs, Windows CE—based devices, and almost any other client that runs TCP/IP; Remote Command runs only on Windows XP, Win2K, and NT.
If you work with network devices such as routers and switches, you're probably familiar with Telnet because it's the primary means of administering such devices (although many manufacturers are beginning to include embedded Web-based administrative interfaces with network devices). If you like the way Telnet works, you'll be happy to know that you can also run a Telnet service on your Windows servers.
In fact, Win2K comes with a built-in Telnet service. For security purposes, the service is set to manual start-up by default. You can either set the service to automatic start-up or leave it on manual start-up and start it only when you need it.
The Win2K Telnet service permits up to two connections, which should be sufficient for remote administration purposes. If you need more connections, you can purchase Microsoft Windows Services for UNIX (SFU), which offers a more robust Telnet service that you can license for more connections. Microsoft also provides a command-line Telnet Server Administration utility that lets you configure the service's authentication options, TCP port, and so forth. You'll find an icon for the utility in the Control Panel Administrative Tools applet. Microsoft doesn't offer an NT Telnet server, but free and inexpensive NT-compatible Telnet servers are widely available on the Internet.
If you work in a mixed-OS environment, Telnet might seem like an ideal tool for Windows because it's probably already running on your non-Windows servers. Keep in mind, though, that Telnet was created in the early days of the Internet when security wasn't the concern it is today. Telnet doesn't provide any kind of data encryption—it sends everything in clear text.
By default, Microsoft's Telnet service uses MSCHAP authentication, which is reasonably secure. But you can also configure it to accept clear-text passwords, which is completely insecure but necessary for accessing Telnet from a computer that doesn't support MSCHAP, such as a UNIX desktop. Telnet is fine for internal servers, but few organizations would consider it acceptable for servers connected to the Internet, largely because Telnet's default TCP port (23) is the first port most malicious users try to attack.
Remote Shell
Remote Shell is a remote command-line tool much like Remote Command and Telnet. Remote Shell has two components: a server-side component called rshsvc.exe and a client-side component called rsh.exe. Both components are available in the Microsoft Windows 2000 Server Resource Kit and the NT Server 4.0 resource kit.
Remote Shell is a cross-platform tool. Most UNIX servers provide support for Remote Shell, and most OSs with TCP/IP support have a Remote Shell client. This support makes Remote Shell a good alternative to Remote Command in heterogeneous (i.e., mixed-OS) environments. However, Remote Shell is less secure than either Remote Command or Telnet.
In the \%systemroot%\system32\drivers\etc folder, you must create a file named RHOSTS that lists the computer names on which rsh.exe can run and the usernames of those users permitted to use rsh.exe on that machine. Rshsvc.exe performs a reverse lookup whenever someone tries to connect and must be able to find the computer and username in RHOSTS before the tool will allow a connection. Remote Shell doesn't require users to provide a password.
Because Remote Shell doesn't pack a lot of built-in security, many administrators prefer to use a third-party version of the tool that includes more security. One popular pick is SSH Communications' Secure Shell. For information about this product, see Mark Bradshaw, "SSH for Windows," September 15, 2001, InstantDoc ID 21992.
Remote Console
Similar in function to Telnet, Remote Console's claim to fame is that it doesn't just redirect the command line from a server to a computer. Instead, the tool takes control of the video memory on the remote server, letting you run full-screen command-line applications such as MS-DOS Edit. By default, Remote Console is restricted to members of the server's Administrators group, although you can lift this restriction and let other users connect to the service. You can obtain the Remote Console service and its documentation in the Win2K Server or NT Server 4.0 resource kit.
Which Tool Is Right for You?
With so many remote administration options, which tools should you pick? Think carefully about your needs, and consider the ability to perform cross-platform remote administration if your environment uses server OSs other than or in addition to Win2K or NT.
Use at least one graphical remote administration tool, such as Terminal Services or VNC. The sidebar "So Many Remote Control Options," page 32, provides advice about distinguishing between other graphical remote administration solutions.
Also select one command-line remote administration tool. Telnet is ubiquitous in UNIX environments and makes sense if you already have UNIX in your organization. Remote Command lets you perform single-command remote administration and lends itself to scripting and automation. Remote Shell also provides cross-platform support, although managing its security on a per-server basis can become time-consuming. Remote Console provides full-screen command-line support if you need to run MS-DOS—based applications remotely.
Whatever solutions you choose, make sure you have the appropriate client software with you at all times. Install clients on your management workstation in the office and on your home computer. Burn a CD-ROM with the various client-installation programs so that you can easily distribute the clients to other administrators or carry the clients with you on business trips (just in case). With the right selection of remote administration tools, you'll always be able to solve server problems and perform server maintenance, no matter where you are.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows & .NET Magazine's Web site at http://www.winnetmag.com. CHRISTA ANDERSON "Keeping Up with Terminal Services" series beginning January 2001, InstantDoc ID 16504 "Preparing for Windows 2000 Server Terminal Services," August 2000, InstantDoc ID 8998 SEAN DAILY "Remotely Manage Your Win2K Servers," April 2001, InstantDoc ID 20043 Remote Possibilities, "Win2K Server Terminal Services and TSAC," December 2000, InstantDoc ID 16014 SEAN DEUBY "What's New in Windows .NET Server's Terminal Services?" May 2002 Web Exclusive, InstantDoc ID 24316 ROBERT MCINTOSH Windows 2000 Ready, "Using Terminal Services for Administration," October 2000, InstantDoc ID 15813 |
