A Window into the Unix World - Software Review - Evaluation

ENT, Dec 13, 2000 by Stephen Swoyer, Christopher Demarco

When Microsoft announced plans to build interoperability bridges from its Windows 2000 operating system to heterogeneous operating system platforms, some industry watchers were skeptical. After all, when had Microsoft ever concerned itself with interoperability?

As it turns out, Microsoft has made good on its promise. Not only did the company release its long-awaited Windows 2000 Services for Unix in early April, but it also took the wraps off its much anticipated Windows 2000 Services for NetWare in July. Not bad, eh?

How, then, does Windows 2000 Services for Unix -- renamed Windows Services for Unix 2.0 -- measure up? Does it provide IT managers with the tools they need to effectively manage Unix environments from Windows 2000 and -- more importantly -- to manage their Windows 2000 environments from Unix? How does it compare with other freely available open source software (OSS) tools from both the open source community and established vendors?

To answer these and other questions, we put Windows Services for Unix 2.0 through its paces.

Installation

We installed Windows Services for Unix 2.0, MKS Toolkit, and Cygnus Solutions' Cygwin on an AMD Athlon 600-MHz system with 256 MB of RAM running Windows 2000 Advanced Server with Service Pack 1 (SP1) installed. Our lab environment consisted of a hodgepodge of Windows NT 4.0 client machines; a Windows NT 4.0 Server with SP5 running Oracle8; a Sun Solaris box running Netscape Enterprise Server 3.0; and a variety of Debian Linux servers -- six in all -- that handled tasks ranging in scope from simple Web serving with Apache, to firewall and IP masquerading, to DNS.

Windows Services for Unix 2.0 does not install remote shell (rsh) by default. This is good because rsh is generally considered less secure than the legacy Telnet protocol.

On the other hand, it doesn't install the Unix cron scheduling utility by default either. This means administrators will have to use cron on Unix systems and AT.EXE on Windows NT/2000 systems to schedule tasks. We installed cron after installation was complete, which allowed us to manage scheduling on our Windows 2000 and Windows NT systems from our Solaris and Linux servers. Very nice. Perl fans out there will also want to note the fact that Windows Services for Unix 2.0 doesn't install Microsoft's ActivePerl implementation by default. We like Perl, so we installed ActivePerl during our post-install configuration of Windows Services for Unix.

On the Treadmill

Two stars of the Windows Services for Unix's portfolio are its support for Network File System (NFS) -- the Unix standard for network file sharing -- and its integration, by way of Active Directory, with NIS, a pseudo-directory naming service first developed by Sun Microsystems that has become a de facto Unix standard.

We didn't have a chance to put MS through its paces -- we don't use it internally, and we weren't too keen on rolling out Active Directory to test the integration and interoperability between the two -- but we did take advantage of Windows Services for Unix's NFS gateway support. In all, we found that administrators and users who would rather mouse in a GUI than cat from a Unix command line will love the integration of NFS with the now-familiar Network Neighborhood. NFS shares are easily mapped just like SMB shares, and the NFS Gateway translates NES shares to Windows-native SME shares, for easy exporting to 9x clients.

We also found Windows Services for Unix's new Telnet client to be a godsend: We would have much rather instructed a monkey to carry index cards to a terminal and enter commands manually than use the old Windows Telnet client. But the client shipping with Windows Services for Unix 2.0 is as close to a standard RFC-compliant implementation as Microsoft will probably ever get. For anyone who is not interested in preserving network security by encrypting terminal emulation settings -- using secure shell (ssh), for example -- the new Telnet client is a huge improvement over what was previously available.

Microsoft's ActivePerl implementation seems to be the real deal, as well. Although we didn't get to play around with it extensively, it seemed to offer a fundamental reduplication of the feature set found on Unix platforms. More importantly, our noses could barely detect a whiff of the proprietary embrace-and-extend odor that hovers around many of Microsoft's other adoptions of OSS technologies, such as Kerberos.

As far as overall manageability is concerned, we found the management tools included with Windows Services for Unix to be exactly what we expected: simple yet powerful, and requiring a minimum of interaction with the command line. This has always been Windows' strong suit We do have more than our fair share of gripes about Windows Services for Unix 2.0, however. Although the Telnet daemon that it ships with provides enhanced support for more simultaneous multiuser sessions -- up to 50 -- it still supports only the legacy Telnet protocol. With this in mind, we have to wonder to what extent enterprise IT organizations are still using vanilla Telnet. It sends passwords in clear-text over the wire and consequently poses a significant security risk. Why, then, couldn't Microsoft have provided an ssh daemon for Windows Services for Unix 2.0? This would have been of real value to mixed Windows and Unix shops alike -- and it alone could have justified the deployment of Windows Services for Unix 2.0 in many enterpris e IT organizations.