System administration is an art of not getting paged. As a corollary, when the inevitable page comes, it's convenient to be able to fix problems. For this, you usually need remote access and the proper tools. In this column, I'll present some ways to make Windows just a little more Unix-friendly.

Remote Command Lines
The main problem is Windows' dependence on graphical user interfaces (GUIs). A given GUI is bound to perform slower than its text-based counterpart. To compound the problem, the default Windows text-based interface - a derivative of the MS-DOS shell - is relatively weak as a scripting language. Moreover, while you can log in to a Windows machine over the network, you're usually just authenticating yourself: You can't really issue commands to the machine, as you can in Unix. So, if you establish that there is a command-line way to accomplish the task at hand, how do you do it remotely and securely, and without having a Windows machine at hand?

Opening a MS-DOS prompt remotely is the simplest method. To this end, Microsoft offers a telnet server (standard with Windows 2000, part of the Resource Kit in previous releases). Microsoft telnet sessions are encrypted using standard Windows security, but this means you can't administer from Unix, which uses unencrypted telnet, unless you disable the encryption! Some Windows encryption methods are well known in the hacker community, so Microsoft telnet is to be avoided in any case. The hills, as they say, have eyes.

A better alternative is the recently released Secure Shell (SSH) server for Windows from Van Dyke Technologies, VShell. SSH, akin to strongly encrypted telnet, gives you a command prompt over a TCP/IP network. Van Dyke's implementation is compatible with standard SSH version 2 clients for Unix.

Several free Windows SSH servers are available, but, unfortunately, I can't recommend them since they have a nasty quirk: When a session is ended, some processes remain running and can't be killed. Like "zombie" processes in Unix, they become impervious to conventional weaponry and eat things-specifically, memory. The VanDyke product cleans up after itself much more nicely, leaving your machine zombie-free. Several competing products are also available, including Pragma SecureShell and Remote-NT.

Remote Control
Windows betrays its origins as a consumer operating system in that some tasks simply can't be accomplished via the command line. In these cases, you need to export the GUI over the network via a remote control application. The simplest of these is Virtual Network Computing (VNC), a product of AT&T laboratories. It's open source and free, so various enhanced versions featuring things like data compression and IP address restriction capability are available. A VNC server simply exports the display of a computer over any TCP/IP network; a small piece of client software on your desktop machine is used as a viewer.

Simple to setup and use, VNC has a few drawbacks: It's a bit slow, it's not encrypted, and no further development by AT&T seems forthcoming. Advanced features such as clipboard transfer and dial-in capability are missing, though the commercial spin-offs of VNC correct some of these deficiencies. VNC clients for every conceivable platform are available, though, so you can administer your Windows server from a Unix desktop, a Macintosh or even a PalmPilot. In the worst case, if you don't have access to the VNC client software, simply open up a window to http://your.machine.name:5800, and you have remote control in your browser (Java is required).

Of the numerous remote control applications (PC-Anywhere, Timbuktu Pro, etc.), I find none match VNC's broad platform coverage, simplicity, and price. Don't be deceived, though: VNC is not "X Windows for Microsoft." X Windows, the traditional Unix display mechanism, provides a separate virtual display for each user who logs in, thereby decoupling the concept of the display from the physical monitor. In contrast, a Windows machine has a single display, period: the monitor attached directly to that machine. VNC always exports this display, no matter who logs in.

Interlude
My best tip for the nascent Windows administrator is to never use anything prior to Windows 2000, if you can help it. Here's why:

• Better tools. Many utilities previously available only as separate products or downloads for Windows NT 4.0 are included with Windows 2000.
• Improved hardware support. I've only seen the "Blue Screen of Death" (indicative of a hardware driver error) twice on Windows 2000. Both times, I willfully disobeyed vendor warnings.
• Command-line equivalents for almost every GUI task. The next release of Windows 2000 (code named "Whistler," as in "in the dark") promises to correct the lapses.

I've found frustration is inevitable but less crushing with Windows 2000. Besides, why choose the lesser evil?

Unix Utilities
The deficiencies of the Windows scripting "languages" are legion. Luckily, you shouldn't have to deal with them, since most Unix utilities and scripting languages have been ported to Windows. Since we already know how to get a command prompt remotely, escaping the Windows environment entirely is the next logical step.

There are at least four implementations of a "standard" Unix operating environment for Windows. Cygnus Solutions, now absorbed by Red Hat, gives away the most popular of these, the open source CygWin utilities. Several hundred popular Unix utilities are included: grep, awk, sed, and popular shells including bash. An application programming interface (API) is provided for those so inclined. Although really intended for porting software from Unix to Windows, the CygWin suite or something similar is invaluable for leveraging your existing Unix skills. Not to be outdone, Microsoft bought a competing implementation, as is their wont, but Interix 2.2 is not available for free.

Once standard utilities are present, you may want a more advanced scripting language. Windows 2000 introduces the Windows Script Host service, which permits you to run ActiveX scripts by double-clicking. Visual Basic scripting is always included with Windows, of course. Neither option is attractive to the migrant Unix administrator, however. Luckily, Perl (Practical Extraction and Report Language), probably the most popular language for automating system administration, is available in a very capable free port from ActiveState. A Perl library for Windows-specific tasks such as event log manipulation is included.

Absent Friends
You can accomplish a great deal of system administration without knowing a lot about how Windows really operates - that's its strength and Achilles' heel. At some point, though, performance monitoring, real-time process monitoring and other tasks that require low-level interaction with the operating system will confound the migrated Unix tools, and you'll be forced to look for Windows-only versions of your favorite Unix standbys. At this point, you'll discover one of the strangest things about Windows: Unlike most Unix variants, low-level utilities that ought to be included as part of the default OS are missing. I surmise that this conspicuous absence is intentional, because it creates a large third-party industry devoted to filling the gaps.

The most important cottage industry tools are undoubtedly those provided by SysInternals. Coded by Mark Russinovich, co-author of "Inside Windows 2000, 3rd edition" -- the best book on the internal structure of Windows -- the utilities found at the SysInternals site are de rigueur for any Windows administrator. A short list of the essentials includes:

• FileMon and RegMon: Tools to monitor file and registry accesses in real-time. These are the Windows equivalents of the Unix "list open files" (lsof) and "trace system calls" (truss) commands. Extremely useful for figuring out permissions-related problems.·
• TCPView: An enhanced version of the Unix netstat command allowing you to see what process is talking on the network. Useful for seeing if you've been hacked and they left something behind. A less powerful version of netstat is included with Windows by default, by the way.
• NTFSDOS: A DOS-based driver for the Windows filesystem. A great way to get read/write access to a machine from a floppy in case the system won't boot at all.

Plus a variety of utilities for killing recalcitrant processes more powerful than any provided by Microsoft.

Some of the SysInternals utilities are of limited functionality unless purchased. If you want to get more in-depth than this (and, hopefully, as a reluctant Windows administrator and not a programmer, you won't have to), look into advanced debuggers, such as NuMega's SoftICE.

Though the concepts and problems from Unix remain unaltered -- automation, connectivity, security -- Windows system administration, like skydiving, can seem intimidating at first. Think of these tools as packing your own parachute. After all, you certainly don't want to entrust that task to some nut who jumps out of planes.

Questions for James? Tips to share? Post your questions and comments below!