For the poor souls who remotely administer Windows NT networks, I have a real treat: a Telnet server. Remote NT administration is a great irritant compared with UNIX administration. Many of the GUI-based NT administration tools let you remotely administer other servers, but using these tools isn't practical on any line slower than 128Kbps (the tools are noticeably sluggish even over 128Kbps).
Consider having the User Manager program on machine A control machine B's user accounts: Machine A does a tremendous amount of work to request a hunk of data from machine B; machine A then massages and ships the data back to machine B. This process keeps both machines busy. A better solution is for machine B, the remote system, to do all the computing, shipping of graphical output, and sending of keystrokes back and forth—the same process Windows NT Server 4.0, Terminal Server Edition uses. Terminal Server, however, is graphical. If you don't want delays and you're using a 28.8Kbps line, you need the simple, text-only interface that a Telnet server provides.
Installing Telnet's Services
When you install the Windows NT Server 4.0 Resource Kit into a directory, the resource kit's Setup program creates another directory named Telnet. The Telnet directory contains two services called the Remote Session Manager and the Telnet daemon. You install them as you would install any network service: From Control Panel, Network, Services, click Add. When the system prompts you to pick a service, click Have Disk. Then you need to locate and point to the directory in which you installed the resource kit; this directory now has \Telnet appended to it. For example, if you told the resource kit to install to D:\Reskit, point Control Panel to D:\Reskit\Telnet. First, install the Remote Service Manager service, and then, without rebooting, install Telnet Service Beta (Inbound Telnet). Then, reboot.
Put to the Test
To test the Telnet server, go to any machine on your network and click Start, Run; then in the text box, type
telnet <machine name>
where machine name is the name of the server on which you installed the Telnet server. The system prompts you for a username, and you must use explicit domains. If Janet is your username, for example, and the domain name is Dorians, specify dorians\janet (i.e., don't just specify janet). The system then prompts you for a password; enter the password, and you see a regular command prompt such as D:\Winnt>. Type any command-line command, and notice how quickly you get a response! Network overhead doesn't exist because the remote server does all the hard work and provides you with only a small amount of ASCII output.
The resource kit obviously provides needed relief from graphical tools for remote NT administration. Here are a few suggestions to replace your missing GUI tools. To administer user accounts, use Adduser. To control machine accounts and trust relationships, use Netdom. To create or delete file shares, or to modify their permissions, use Rmtshare. To control Windows Internet Naming Service (WINS), Dynamic Host Configuration Protocol (DHCP), or Domain Name System (DNS) servers, use Winscl, Dhcpcmd, and Dnscmd. To see which processes are running on a system and to stop runaway processes, use Tlist and Kill. (I know I haven't covered all these utilities in this column, but I will in the future.)
Proceed with Caution
Unfortunately, you'll pay a price for this cool tool: security. Telnet clients pass their text in clear text, so someone could easily sniff your password when you log on. So even though the Telnet daemon is neat, it's not for everyone. Although you could put Point-to-Point Tunneling Protocol (PPTP) on the server with the Telnet daemon and require everyone to PPTP into it, PPTP adds enough overhead to a server that you may end up losing more response time than you gain.
