Windows Services for UNIX Version 3.0

  • Article

Abstract

Microsoft® Services for UNIX version 3.0 provides a full range of supported and fully integrated cross-platform network services geared towards enterprise customers needing to integrate Windows® into their existing UNIX-based environment. It allows enterprise customers seamless access to information stored in multiple platforms, consolidates network management across platforms, and reuses UNIX applications and scripts on Windows.

On This Page

Introduction Introduction
New in Version 3.0 New in Version 3.0
Why Services for UNIX? Why Services for UNIX?
Interix Interix
Custom Installation choices Custom Installation choices
Use Scenarios Use Scenarios
Summary Summary

Introduction

Since its introduction in 1999, Windows Services for UNIX has played a major role for those of us trying to make Windows and UNIX networks co-exist peacefully. With the introduction of Version 3.0 of Services for UNIX (SFU), Microsoft has not only made SFU easier to use and faster with enhancements to all of the features of version 2.0, but added significantly new technology with the addition of the Interix subsystem – a fully POSIX compliant subsystem that lets you compile and natively run UNIX programs and scripts on Windows NT/2000/XP.

Version 3.0 of Services for UNIX includes a full set of UNIX utilities and an SDK that supports over 1,900 UNIX API's, giving developers the ability to easily migrate existing UNIX legacy applications to Windows. The Interix subsystem and utilities replace the previously provided UNIX Korn Shell and utilities with a new, native POSIX compliant subsystem and a full set of utilities and shells (both C and Korn are provided). The Interix subsystem includes full support for a single rooted file system, symbolic links and much more. Additionally, the GNU SDK and utilities can be loaded to provide the broadest range of interoperability and developmental tools.

Version 3.0 of Windows Services for UNIX works with a broad range of UNIX and Linux platforms, using industry standard protocols and utilities. It has been explicitly tested for interoperability with Solaris 7, Solaris 8, HP-UX 10.2, HP-UX 11.0, AIX 4.3.3 and Red Hat Linux 7.0 & 7.2. Windows Services for UNIX Version 3.0 runs on Windows NT 4.0 (Workstation and Server) SP6a or higher, Windows 2000 (Professional and Server versions), Windows XP Professional and Windows Server 2003s.

New in Version 3.0

Version 3.0 of Services for UNIX adds significant new features and enhancements over version 2.0, and includes a major change in the handling of interoperability of scripts and programs. With the introduction of SFU Version 3.0, Microsoft has replaced the MKS derived UNIX workalike utilities and Korn Shell with the fully POSIX compliant Interix subsystem technology, utilities and SDK, providing a rich interoperability and migration environment that behaves exactly as a UNIX administrator or programmer would expect. Table 1 has a summary of some of the major new features in Version 3.0 of Services for UNIX.

Table 1 New and Enhanced Features in Services for UNIX version 3.0

Feature

Description

NFS Client

Supports sticky/setuid/setgid bits

 

Support for symbolic links

 

Performance improvements

 

Internationalization: Additional language options

NFS Server

Significant performance enhancements

 

Support for active-active clustering of NFS shares

 

setuid, setgid, sticky bit support

 

Per share handing of root and anonymous access

 

Improved model for mapping Windows NT<-> UNIX permissions

 

Internationalization improvements

NFS Gateway

Internationalization improvements

Mapping Server

Cluster-enabled mapping server

 

Performance, security and scalability improvements

 

Support for redundant mapping servers

 

Internationalization improvements

Server for NIS

Support for MD5 encryption

 

Scalability and performance improvements

 

Administration and usability improvements

Password Sync

New support for setting passwords using Pluggable Authentication Model on UNIX.

Telnet Server

Security and scalability improvements

 

IPv6 support

 

Dumb terminal support (handhelds)

Telnet Client

IPv6 support

 

Internationalization

Interix

New to Services for UNIX. Enhanced since version 2.2 of Interix

Interix SDK

New to Services for UNIX. Enhanced since version 2.2 of Interix

Why Services for UNIX?

With the growing adoption of the Microsoft Windows NT® operating system in established UNIX environments, the need for the two platforms to interoperate has increased. Services for UNIX version 3.0 provides a set of additional features to Windows NT and Windows 2000/XP that allow for greater interoperability with existing UNIX-based systems in the enterprise. The Interix technology included with Services for UNIX version 3.0 greatly increases the ability to migrate applications originally written for UNIX and/or Linux and retarget them to run on Windows.

Services for UNIX version 3.0 provides a full range of supported and fully integrated interoperability components and a complete SDK that supports over 1,900 UNIX API's, making it easy for customers to integrate Windows NT 4.0 and Windows 2000/XP operating systems into their existing UNIX environments. Services for UNIX version 3.0 provides:

  • Interoperability components that leverage existing UNIX network resources and expertise within organizations

  • Manageability components that enable organizations to simplify network administration and account management across both platforms

  • Development components that provide a full featured development environment that leverages existing UNIX developmental expertise

  • Migration components that enable organizations to retarget existing UNIX applications and scripts to Windows, providing a robust and resource sparing home for legacy UNIX applications while providing a clear path forward to the features of .NET

Services for UNIX provides four compelling scenarios for the heterogeneous UNIX and Windows NT/2000/XP network that allow you to take the best advantage of both environments to simplify and manage your enterprise. The four scenarios are:

  • Leverage Existing UNIX Network Resources

  • Simplify Network Administration

  • Simplify Account Management

  • Leverage Existing UNIX Expertise

In this section, we'll look at the first three of these in greater detail, and then in the next section, we'll examine Interix and how it can provide better business value and better IT management across diverse environments by letting you leverage your existing UNIX expertise and applications on Windows.

Leverage Existing UNIX Network Resources

Services for UNIX gives you four important tools to allow you to leverage your existing UNIX network resources for your Windows clients and servers while also letting your UNIX clients utilize the resources of Windows servers. These four tools are:

  • Client for NFS – Enables Windows clients to access the resources of NFS servers on the network.

  • Server for NFS – Enables NFS clients on the network to access the Windows Server resources through NFS. The NFS Service is now fully cluster-aware, supporting active/active clusters.

  • Gateway for NFS – Enables any Windows client to access the NFS resources of the network without any additional components on the client.

  • Server for PCNFS – Enables Windows NT/2000/XP to act as PCNFSD servers, providing user authentication for file access to NFS servers.

Management and Configuration

The Services for UNIX Administration MMC console is used to administer the Client for NFS and Server for NFS services, but not the Gateway for NFS service. To open the console, you can either launch it from the Start menu or by opening the sfumgmt.msc snap-in from within an MMC console. Alternately, you can administer most NFS options from the command line. Complete command line syntax is available from the command line by typing:

nfsadmin [client | server | gw] /?

Client for NFS

The properties you can modify for the Client for NFS are:

  • Authentication – The mapping server to use for authentication

  • File Permissions – The default file access permissions. Defaults are:

    • 



rwxr-xr-x


    

  • Performance – The settings for the following performance related factors (and their default values):
    

    Transport Protocol – UDP
    

    Mount Type – Soft
    

    Retries – 1
    

    Timeout – 0.8 seconds
    

    Read Buffer Size – 32 Kb
    

    Write Buffer Size – 32 Kb
    

    • 



Connecting to an NFS Export


Connecting to an NFS export can be done in a variety of ways, using either standard Windows syntax (\\server\share) or standard UNIX syntax (server:/share). From the command line you can use the standard Windows NT/2000 "net" commands, or the more UNIX-like "mount" command with either syntax. Or simply browse your Network Neighborhood in the Explorer. From the command line, the following are equivalent:


net use * server1:/home
net use * \\server1\home
mount server1:/home *
mount \\server1\home *


Tip When you are sure you are connecting to an NFS export, use the UNIX server:/share syntax for a faster setup of the connection.


Server for NFS


SFU provides a robust Server for NFS that provides disk resources from your Windows NT/2000/XP machines to any machine on your network that supports NFS. To administer the Server for NFS, use the Services for UNIX MMC console or from the command line, use nfsadmin. Complete command line syntax is available from the command line by typing:


   nfsadmin [client | server | gw] /?


From the SFU MMC console, you can set the following options:


    

  • Logging – the size and location of the logging file, and the operations to audit
    

    • 

  • Locking – the grace period for locks and a list of current locks
    

    • 

  • Client Groups – used to group client machines for easier setting of permissions
    

    • 

  • Server Settings – settings that affect performance
    

    • 



Shares


Shares are created by selecting the NFS Sharing tab from the Properties page using Explorer. You can share either individual directories or entire drives. To share a directory from the command prompt, type:


   nfsshare sharename=drive:Path


Where drive:path is the location of the folder you want to share. As in UNIX, you can't share a subfolder of an existing share. For this purpose, each drive letter is treated as a separate root directory. Complete command line syntax is available from the command line by typing:


   nfsshare /?


Permissions


Server for NFS uses Discretionary Access Control Lists (DACLs) to simulate the permissions that are typical in the UNIX and NFS world. The default permissions are read/write for all users.


To set permissions, open the properties dialog box for the folder you are sharing, click the NFS Sharing tab, then click the Permissions button.


Caution: It is important to understand that there are inherently different permissions sets in the UNIX and Windows 2000/NT security models and that any attempt to align them is merely an approximation. For example, the "Take Ownership" permission doesn't exist in UNIX, but in UNIX the superuser (root) can change the ownership of any file to any user.


Gateway for NFS


The Gateway for NFS Sharing application (gwconfig.exe) can be used to create gateway shares. Start the Gateway for NFS Shares application from the Services for UNIX program group, or the command line. From here you can create a gateway share that will be available to all Windows clients as if it were a local share from the gateway computer. Each gateway share uses a drive letter from the gateway computer, limiting the number of shares to the maximum number of free drive letters available on the gateway computer.


From the command line, Gateway for NFS shares are managed using the gwshare.exe utility. For details on using gwshare, see the Windows Help or type:


   gwshare /?


Tip Gateway for NFS shares are limited by the number of available drive letters on the gateway server. But if you need additional shares beyond this number, you can (and should) use more than one gateway server to provide the additional shares in order to distribute the load.


Server for PCNFS


The Server for PCNFS provides PCNFSD support. You can enter the necessary information to create users and groups using the Services for UNIX MMC that will allow Server for PCNFS to handle the authentication of NFS file resources for all NFS clients.


Simplify Network Administration


Services for UNIX provides important tools to enhance and simplify the administration of your network. These tools include:


    

  • Telnet Client – Enables character and script based remote access and administration across a variety of platforms.
    

    • 

  • Telnet Server – Enables character and script based remote administration of Windows 2000 and Windows NT servers from a variety of clients.
    

    • 

  • Microsoft Management Console (MMC) Snap-in – Enables a consistent and central management point for all SFU functionality.
    

    • 

  • ActivePerl – Enables existing and new scripts to take advantage of the Windows Management Interface (WMI) to automate network administration tasks.
    

    • 



Telnet Client


SFU provides a character mode telnet client that is both faster and more robust than the default graphical mode client provided by Windows NT. In Windows 2000, Microsoft integrated this telnet client, replacing the old version. The telnet client supplied with SFU goes beyond the one in Windows 2000 to support both stream mode and console mode, and provides for logging and additional configuration settings (see the set command, below) and commands (see the send command, below) that make it more robust in a mixed environment.


The telnet configuration is done from within a telnet session by escaping to the telnet prompt. Press ^] (that's Control-right bracket) to bring up the telnet prompt when you've started a telnet session. From here you can type:


    

  • ?– to get help
    

    • 

  • close– to close the current connection
    

    • 

  • display– to show the current operating parameters
    

    • 

  • pen <machinename>– to open a connection to a machine (you can use an IP address here as well)
    

    • 

  • send – to send strings to the telnet server. The strings are sent as is, except for the following special strings:
    

      

    • ao – send the telnet command 'Abort Output' to the server
      

      • 

    • ayt – send the telnet command 'Are You There' to the server
      

      • 

    • esc – send the telnet escape character to the server
      

      • 

    • ip – send the telnet command 'Interrupt Process' to the server
      

      • 

    • synch – send the telnet command synch to the server
      

      • 

    

    • 

  • status – prints basic status information about the current session
    

    • 

  • quit– to exit the telnet client completely
    

    • 

  • set– to set an operating parameter. Takes the following parameters:
    

      

    • ?– get help on other set options
      

      • 

    • bsasdel – Backspace key will be sent as the Delete key
      

      • 

    • crlf – Return key sends both a carriage return and a linefeed (0x0D,0x0A)
      

      • 

    • escape x – x is the escape character to enter telnet client prompt (default is ^])
      

      • 

    • localecho – turns on local echo of characters typed.
      

      • 

    • logfile filename – sets filename to be the current logfile
      

      • 

    • mode x – where x is console or stream
      

      • 

    • ntlm– turn on NTLM authentication
      

      • 

    • term <value>– set the requested terminal emulation. Choices are: ANSI, VT52, VT100, VTNT
      

      • 

    

    • 

  • unset– to unset the options set with the set command.
    

    • 



Tip if you use the telnet client to primarily connect to UNIX systems, set term to ANSI and NTLM off, but if you frequently connect to both Windows 2000- and UNIX-based systems, or primarily to Windows 2000-based systems, you'll find the VTNT emulation a better preferred choice and you'll still fall back to ANSI when connecting to a system that doesn't support VTNT.


Telnet Servers


Services for UNIX version 3.0 includes two telnet servers – the default, Windows based telnet server which is similar to the one included in earlier versions of Services for UNIX, and the Interix telnet server, which is controlled by inetd. Only one of these telnet servers can be enabled at a time – by default the regular Windows telnet server is enabled.


As installed, the Windows based telnet server works optimally for most installations. It will accept logins from a variety of clients, including the telnet clients shipped with Windows 2000, Windows NT and Windows 95/98 as well as a variety of character mode terminal clients from virtually any operating system. Additionally, it can be configured to meet specific site requirements to improve security, simplify logins, support stream or console mode, and so forth.


Differences


The default Windows based telnet server should be familiar to users of Windows XP and Windows 2000. It is essentially the same as the server included in Windows XP Professional, and a close relative of the one included in Windows 2000 editions. It uses the Windows Command Shell (cmd.exe) as the default shell. This server can be started and stopped from either the Services MMC or from the Services for UNIX Administration MMC (sfumgmt.msc). See below for details about the server settings and what they mean.


The Interix telnet server, telnetd, is normally run under the control of inetd. It uses the Interix shell as the login shell. For options when using this version of telnet, see the man pages for telnetd.


Enabling Interix Telnetd


To enable the Interix telnet server, first stop the Windows telnet server and set it to manual startup using the Services MMC. Next edit /etc/inetd.conf to uncomment the following line:


#telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd –I


Then, from the Interix shell, issue the command:


  $ kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " \   " " | cut –f2 –d " ")


For the detail oriented, this will find the process ID for the inetd process and then issue a "kill -1" (NOHUP) to that process, causing inetd to re-read its configuration file.


Authentication


The SFU telnet server supports Windows NT Lan Manager (NTLM) for authentication of client logins. Using NTLM allows users to be automatically authenticated to the telnet server based on their Windows NT login. This makes using telnet completely transparent to users, while ensuring that clear text passwords don't pass over the network. NTLM must be supported on the client side of the login as well, however.


Note: The use of NTLM only in a mixed UNIX- and Windows NT/2000 environment will effectively lock out UNIX users from the Windows NT/2000-based servers, because they will not have a client that supports NTLM authentication.


When using NTLM login, users are restricted to local drives on the machine they are logged in to. If they need to map network resources, they can do so by explicitly mapping with full credentials. For example:


   net use g: \\server\share /user:domain\username


Administration


The telnet server is administered using the SFU MMC snap-in, or the tnadmin program. To see the options for tnadmin.exe type:


   tnadmin /?


The available options that can be set are:


    

  • Authentication – choices are NTLM and Username/Password.
    

    • 

  • Auditing – set event logging to a separate log file, or the Event Log, and set what events to log.
    

    • 

  • Server Settings – Set the following options:
    

      

    • Maximum Number of Simultaneous Connections – default is the number of licensed connections to the server. On Professional, default is 1.
      

      • 

    • Maximum number of failed login attempts – default is 3.
      

      • 

    • Map Alt Key to CtrlA – default is yes
      

      • 

    • Telnet Port – default is 23
      

      • 

    • Mode of Operation – Choose Console or Stream. Default is Console.
      

      • 

    • Default Domain Name – Type in a domain name that is automatically added to the login username. Default is ".", disabling this feature.
      

      • 

    • Idle Session Timeout – Time until an idle session is forcibly disconnected.
      

      • 

    • Terminate all programs when disconnecting – a toggle with the next option.
      

      • 

    • Continue to run programs started with bgjob command – allows jobs to continue to run after the session has ended. Default is 'no'.
      

      • 

    

    • 

  • Sessions – Allows you to see data about the currently active sessions (like user, domain, machine, logon date/time) and either send a message to the session or terminate it.
    

    • 



Services For UNIX MMC Console


Services for UNIX version 3.0 includes a single MMC for managing all of SFU except the Gateway for NFS. This MMC provides an easy to use, cohesive management interface that lets you administer all SFU machines on the network from any console. Further, because SFU supports the Windows Management Interface (WMI), management can be fully scripted from the command line.


ActiveState ActivePerl 5.6


Services for UNIX v3.0 includes ActiveState's ActivePerl 5.6, a full featured port of Perl 5.6 and Perl Script to Windows NT/2000/XP. Among a host of other improvements, ActivePerl 5.6 includes full support for the fork() command, vastly improving the portability of scripts and modules from the general Perl distribution. ActivePerl also provides full support for the Windows Script Host, making it an excellent tool for system administration tasks.


Simplify Account Management


Services for UNIX provides important tools to help simplify the account management in a mixed Windows and UNIX network. These tools include:


    

  • NIS Migration Wizard – provides the ability to move UNIX NIS source files from the NIS domain into Windows 2000 Active Directory in order to consolidate account management.
    

    • 

  • Server for NIS – allows a Windows 2000 domain controller to act as the primary Server for NIS, integrating NIS domains with Windows 2000 domains, and allowing administrators to manage both domains using Active Directory.
    

    • 

  • Password Synchronization (2-way) – provides the ability to synchronize passwords for both platforms, making it easier for users to maintain one password for both Windows and UNIX.
    

    • 

  • User Name Mapping – associates Windows and UNIX user names, allowing users to connect to NFS resources without having to log on to UNIX systems separately.
    

    • 



NIS to Active Directory Migration Wizard


The NIS Migration Wizard provides a simple to use tool that allows you to easily migrate an existing NIS environment to Server for NIS. It takes your UNIX NIS source files and migrates them into the Active Directory.


You can either make the source files available to the Windows 2000 Server that will be running the NIS Migration Wizard by using NFS, or you can ftp them to a local directory on the server. All your map source files should reside in the same directory. You can run the Migration Wizard more than once to migrate the files in steps, or run all your migrations as a single step. But if you migrate files in steps, you need to migrate your passwd file before you attempt to migrate either the group or shadow files which depend on it.


Server for NIS


The Server for NIS allows a Windows 2000 domain controller to be an NIS master server, or an NIS subordinate(slave) server by integrating NIS into the Active Directory. If Server for NIS is used as a subordinate server, the master server must be a Windows 2000 Server. A Server for NIS master server can support both Windows 2000 and UNIX NIS subordinate servers.


For more information on NIS in general, see https://www.microsoft.com/technet/interopmigration/unix/sfu/servnis.mspx.


For a checklist and more information on using the NIS Migration Wizard, see the Services for NIS help file.


Password Synchronization


The password synchronization tool included with Services for UNIX version 3.0 is a two way synchronization utility that allows you to synchronize password changes between Windows NT/2000/XP and UNIX. Password changes can begin in either Windows or UNIX for:


    

  • HP-UX 11
    

    • 

  • Sun Solaris 7 , Solaris 8
    

    • 

  • IBM AIX 4.3.3 (Windows to UNIX only)
    

    • 

  • Red Hat Linux 6.2, 7.0
    

    • 



Tip If your UNIX platform is not on this list, you can still use 2-way password synchronization by compiling on your platform. SFU includes both source code and make files to facilitate the compilation.


2-Way Password Synchronization uses a single sign on daemon (SSOD) that runs on the UNIX server to accept password changes from Windows 2000/NT and a Password Authentication Mapper (PAM), also running on the UNIX server, to pass UNIX password changes to the Windows 2000/NT environment.


Deployment Notes


There are some things you should know if you're going to use the Password Synchronization feature of Services for UNIX:


Using With Windows 2000 Domains


When synchronizing Windows 2000 domains with UNIX computers, the Password Synchronization service must be installed and running on all domain controllers in the domain, as well as on all UNIX computers where the desired users can change their password. If you uninstall the service from one of the domain controllers, you may run into problems with the other servers.


Using With Standalone Servers or Workgroups


When using the Password Synchronization service to synchronize passwords between standalone or workgroup Windows 2000 computers and UNIX computers, you must install the service on all Windows 2000 computers. In this case, the password synchronization service synchronizes only the local accounts on each Windows 2000 computer with UNIX.


General Notes


In order to properly synchronize passwords between Windows 2000 systems and UNIX systems, user accounts need to be exactly the same on all Windows 2000 and UNIX computers using the service. Keep in mind that, unlike Windows 2000/NT accounts, UNIX accounts are case sensitive. In addition, all UNIX computers must be setup properly with the SSOD provided on the Services for UNIX CD. If you want to use Password Synchronization to synchronize a Windows domain with an NIS domain, you need to include the NIS master servers in the list of computers that may receive password changes. You will also need to configure your daemon on the UNIX server by making the appropriate changes to the configuration and make files to use NIS.


For more information on Password Synchronization in Services for UNIX, see Password Synchronization Whitepaper


User Name Mapping


The User Name Mapping provides a mechanism to map the dissimilar names that can exist between the UNIX and Windows environments. User Name Mapping is used even when the names are the same in both environments, but its real strength is to allow you to map users whose names are not the same in the two environments. Given that UNIX usernames are case sensitive, while Windows 2000/NT names are not, this can greatly simplify maintaining and managing accounts in the two environments.


The User Name Mapping Server is a highly available, cluster-enabled service that supports a redundant pool of User Name Mapping Servers.


Using User Name Mapping, you can create simple maps between Windows 2000/NT user accounts and the corresponding UNIX accounts, and use the Advanced Map feature to map accounts with dissimilar names. Further, User Name Mapping supports bi-directional one to many mapping, allowing you to let a single UNIX or Windows 2000/NT account be mapped to multiple accounts in the other environment, allowing you to map more than one administrative Windows 2000/NT account to the UNIX root account, for example.


User Name Mapping uses either NIS to authenticate users or local passwd/group files that are maintained and authenticated using the Server for PCNFS. These files are located in %windir%\system32\drivers\etc. Additionally, User Name Mapping Server now uses a .maphosts file to implement trusted hosts security.


For more information about the User Name Mapping Server, see User Name Mapping Server.


Interix


Services for UNIX Version 3.0 includes the Interix subsystem technology - a full featured, robust, UNIX application and scripting environment that runs as a native subsystem on top of the Windows kernel.


A Native Subsystem, Not an Emulation


The Interix subsystem, unlike the Korn shell and utilities provided in early versions of SFU, is a fully integrated POSIX subsystem that runs natively under Windows NT/2000/XP. This subsystem provides complete support for compiling and running UNIX applications in Windows, allowing enterprises to easily leverage and migrate their existing custom applications. It also provides UNIX developers with full support for more than 1,900 UNIX APIs allowing scripts and applications written to run under UNIX to transfer to Windows easily and naturally.


Scripting


The Interix subsystem technology includes both Korn Shell and C Shell environments, more than 350 UNIX utilities, and Perl 5.6.0 compiled under Interix. These give UNIX developers and administrators the broadest, most familiar, and most compatible scripting environment possible. The utilities include awk, grep, sed, tr, cut, tar, cpio, and a host of others, all of which work exactly as the UNIX user, administrator or programmer expects. Also included are more than 40 GNU utilities and compilers, including gawk, gcc, g++, and g77.


Shells


Both Korn Shell and C Shell are available in the Interix subsystem, and both behave exactly as they do in a UNIX environment. Unlike the Korn shell provided in earlier versions of Services for UNIX, Interix subsystem and the Interix shells use a single rooted file system. The need to convert scripts to support drive letter syntax is gone. For example, in previous versions of SFU, the fully qualified path to a user's "build.ksh" script in their personal bin directory would be:


   U:/bin/build.ksh


In Version 3.0 of SFU, using the Interix subsystem, that script would be located at:


   /dev/FS/U/bin/build.ksh


Or, with the addition of a simple symbolic link, it could be located at:


   /home/$username/bin/build.ksh


Common scripts and programs can be located where most UNIX and Linux users would expect to see them. For example, vim/gvim installs to:


  /usr/local/bin/vim
   /usr/local/bin/gvim -> /usr/local/bin/vim


This listing shows a second important new feature provided as part of the Interix subsystem – symbolic links are now fully supported on NTFS file systems, and for NFS as well.


Support for a single rooted filesystem alone makes it far easier to port scripts from UNIX to Windows NT/2000/XP for two important reasons. Not only are applications, programs and system files located where UNIX programs and users would expect them to be, but also the colon character retains its normal meaning as a field separator in PATH variables, etc.


Another important difference is that the special files that control the shells behavior are the same names in the Interix environment as they are in UNIX. This makes it easy for users to maintain a single ".profile" and ".kshrc" (or .login and .environ for C Shell users) across multiple environments, even allowing users to use Client or Server for NFS to provide for a single, shared, home directory structure across a both Windows and UNIX environments.


Languages


The Interix subsystem provides a familiar and compatible scripting and programming environment with support for multiple scripting, programming languages, and libraries including Perl, C, fortran77 and C++ with support for both the GNU compilers -- gcc, g77 and g++ -- and the Microsoft Visual C/C++ as cc and c89. Perl 5.6 is supported both in the Interix subsystem and the Win32 subsystem.


Tools and Utilities


All the standard UNIX tools and utilities are part of the Interix subsystem – there's no need to purchase an add-on package from a third party to get the tools you expect and need to get your work done. Not only is there full support for the "r-utilities", but all the familiar tools are available and work exactly as the UNIX administrator would expect. The utilities include familiar text processing tools, such as grep, less, awk, sed, pr, tr, etc., batch processing tools such as at, cron and batch, as well as job control tools like ps, nice, kill, etc – they're all there and they work exactly as you would expect. Even man is just as ugly (but infinitely useful) as it's always been.


Programming


Services for UNIX 3.0 not only provides a full set of APIs, compilers and utilities for creating and migrating UNIX applications, including both XWindows and Curses based applications, but it also provides a complete environment that behaves exactly as UNIX applications expect. No special considerations for file locations or syntax are required. Symbolic links are fully supported on NTFS as well, providing maximum location flexibility. This makes it not only possible, but relatively easy to port an existing UNIX application to run on the Interix subsystem.


Differences with Earlier Versions of Interix


Interix has always provided an extremely familiar look and feel to the UNIX user moving to it, but traditionally was less forgiving of the expectations of the native Windows user. In earlier versions of Interix, for example, strict case sensitivity was enforced, making it difficult for the script writer who could not be sure the exact case of a native Windows utility. This has been significantly improved in the new version of Korn Shell in Interix, along with adding support for calling executable programs without having to add on their extensions. This has greatly increased the ease of use, because the NTFS file system will maintain case but is functionally case insensitive for Windows executables.


When running on Windows XP, Interix may be configured at install to enforce case sensitivity on NTFS filesystems.


SFU 3.0 includes full integration of the Interix subsystem with NFS and the User Name Mapping Server, supporting mount syntax, NFS file system traversal and user name mapping from within the Interix subsystem.


Additionally, in this version several important API's, have been added including ulimit, vfork and syscall while integrating support for NFS and DFS file systems, symbolic links, and better integration between the Interix and Windows process tables.


Custom Installation choices


Overview


Figure 1: SFU Installation


Figure 1: SFU Installation


Services for UNIX v.3.0 uses the familiar Microsoft Installer, shown in Figure 1. This installer allows for easy installation on demand, removal of SFU under fully scriptable control, and maintenance. When you choose a custom installation, you can choose which options are installed.


Services for UNIX provides a number of different choices for installation. The choices you make are, in large part, dependent on the type of heterogeneous network you are supporting. While there are many possible installation options and combinations you can make, four basic combinations make sense in different scenarios. The three basic scenarios, and the combinations they support are:


    

  • Primarily Windows 2000 with some UNIX servers and clients – Install the full Services for UNIX. Gateway for NFS may be suited best for environments where use of the NFS resources is relatively limited for at least some of the Windows clients. If most Windows boxes need access to UNIX NFS shares, Client for NFS is more suitable.
    

    • 

  • Substantial existing mixed UNIX and Windows 2000/NT – Install NFS (Server and Client/Gateway as appropriate) on your Windows 2000 servers and clients along with the NFS User Name Mapping Server to provide full access to the existing UNIX filesystem resources. Install NIS if you want to consolidate your directories and have a single point of administration.
    

    • 

  • Existing UNIX with new Windows 2000/NT – In environments where Windows 2000/NT is just going in, and you want to simplify account maintenance and leverage your existing UNIX expertise, and migrate UNIX applications to Windows 2000/NT, install the full Services for UNIX v3.0 product, including Interix and the Interix SDK, NFS to provide cross platform file resource sharing and Password Synchronization. Make sure you create your Windows 2000/NT usernames with identical case to match your existing UNIX environment.
    

    • 



Each of these types of installations installs the combination of options appropriate to the environment it's designed to support. In all of these scenarios, we expect you will want to install Interix. It provides a full set of UNIX utilities and shells, and provides a rich and robust interoperability and migration environment.


Let's look at the different types of installations and when you would choose them.


Full Installation including Server for NIS


In the large, enterprise environment where there are substantial UNIX resources and an existing NIS domain environment that is also implementing Windows 2000 Server and Active Directory, it may well make sense to install the full Server for NIS package on the Domain Controller. Using the NIS Migration Wizard, you can migrate your existing NIS domains to the Active Directory and provide a fully redundant, replicated, master Server for NIS as part of the Active Directory. Any Windows 2000 Domain Controller can be a Server for NIS. There can only be a single Master Server for NIS, but the other DCs in your Windows 2000 domain can be subordinate servers to an Active Directory based NIS master server. An SFU Server for NIS cannot, however, be a subordinate server to a UNIX NIS master server.


NFS and User Name Mapping


In environments where there are substantial NFS filesystem resources and UNIX NFS clients, but that are not running NIS or where the NIS Master Server will reside on UNIX, you should consider installing Server for NFS, Client for NFS or Gateway for NFS, and User Name Mapping. You only need to install a single User Name Mapping service, but you can install more if you are on a subnetted network or you have a large number of Windows NFS clients and you want to distribute the load appropriately.


Tip Gateway for NFS -- You can install either Client for NFS or Gateway for NFS on a Windows 2000 or Windows NT server but not both. If your use of NFS is relatively light, you'll likely find that Gateway for NFS is a cost effective choice. It provides a way for Windows clients to connect to the existing NFS filesystem resources without having to have a Client for NFS loaded on their machine. You should keep in mind, however, that heavy NFS use could overload the gateway server, creating a bottleneck in the system.


Tip Client for NFS -- You should install the Client for NFS on any server or Windows NT Workstation or Windows 2000 Professional machine that will make heavy use of NFS filesystem resources. If you have at least one server that is running Gateway for NFS, you can use that server to make NFS resources available to less demanding clients and Windows 9x clients, but you should install Client for NFS on all machines that will require substantial and regular use of files stored on NFS servers.


Tip User Name Mapping -- Install User Name Mapping on one or more servers if your username conventions are different between Windows 2000 and UNIX. This will allow you to map the different usernames in each environment in a way that is essentially transparent to the users. If you have a cluster available, User Name Mapping Server can be installed on it, providing for increased availability.


Password Synchronization (2-Way)


In an environment where you have a large number of both Windows and UNIX users, and where a substantial number of those users work in both operating systems, you should install password synchronization where your UNIX systems are on a supported platform.


If your UNIX systems are not running one of the supported platforms, you may still be able to run Password Synchronization by compiling the supplied daemons (SSOD and PAM) for your platform, using the supplied make file.


Tip Password Synchronization does not support dissimilar names so in any environment where you want to use password synchronization, you should make every effort to align your usernames (including case – UNIX is case sensitive) on the two platforms to facilitate central management of passwords.


Use Scenarios


Central Password Administration


One of the largest sources of pain and frustration for users and administrators in a mixed UNIX and Windows environments is managing and maintaining the different accounts in the two domains. This is especially true in large, security conscious environments where regular password changes are required and enforced. Services for UNIX version 3.0 gives you the tools to simplify this process.


There are several ways to handle central password maintenance, depending on how your environment is configured and what your specific needs are. The three basic mechanisms are:


    

  • Active Directory based NIS Master Server
    

    • 

  • User Name Mapping and Server for PCNFS
    

    • 

  • Password Synchronization (2-way)
    

    • 



Each of these mechanisms approaches the problem of central password administration from a slightly different perspective, but they each have their place, and can complement each other.


In a large enterprise environment where there is a well-established base of UNIX users and administrators, it may not be possible to implement NIS as part of Active Directory. In these environments, you can use a combination of password synchronization and User Name Mapping to achieve much the same result. User Name Mapping will help you leverage your existing UNIX resources by making it easier for users to connect to the NFS filesystems even when they have different account names in the two environments, while the password synchronization will work with those accounts that have the same name in both environments to keep the passwords synchronized – regardless of whether the UNIX environment is using NIS or /etc/passwd as its primary authentication mechanism.


In environments that are adopting Windows 2000 and Active Directory, there is a major opportunity to simplify and consolidate all account maintenance into a single, easy to manage and maintain location – the Active Directory. Using the NIS Migration Wizard you can migrate your existing NIS domain to the Active Directory, converting your existing NIS master server into an NIS subordinate server that points to the new Active Directory based NIS master server. Where dissimilar accounts exist in the two environments, User Name Mapping provides a simple mechanism to map accounts between the two.


Tip The Server for PCNFS provides full support for PCNFSD and user authentication for accessing NFS file resources to all NFS clients that can't use User Name Mapping (such as Services for UNIX version 1.0 clients), while providing authentication resources for User Name Mapping. You should install Server for PCNFS on the same server as User Name Mapping for simplicity and ease of maintenance.


Common File Systems


Many enterprises have significant storage resources already committed in the UNIX environment and would have a substantial cost associated with either moving those resources to Windows 2000/NT or worse having to replicate them in both environments. Services for UNIX provides the mechanism to unify the filesystems between the two environments, giving you a single, common filesystem that both sides can take advantage of. Use the Server for NFS on your Windows 2000/NT servers to provide easy access to the Windows filesystems for your UNIX servers and clients, while using a combination of Gateway for NFS and Client for NFS to provide transparent access to existing UNIX storage resources to your Windows servers and clients.


One important consideration when implementing Client for NFS or Gateway for NFS in the enterprise is deciding which one is appropriate for each situation. SFU's Gateway for NFS is appropriate where you need to support occasional and relatively light use of the NFS storage resources to Windows clients in a completely transparent way to users. It is not, however, appropriate for heavy or frequent use where the user will be either running programs from the Server for NFS, or storing large data files or documents on the server. In this case, the full Client for NFS is more appropriate, preventing the Gateway for NFS from becoming a bottleneck. In most environments, a mixture of Gateway for NFS and the Client for NFS is the best and most cost effective choice, using the full Client for NFS on those machines where the users will require the extra bandwidth while using Gateway for NFS to support the occasional or light duty user in a way that provides a seamless and easy to support common file system between the two environments.


Application and Script Migration


The addition of the Interix subsystem technology to Services for UNIX version 3.0 makes it an excellent way to migrate UNIX applications and scripts to bring them to the Windows platform. With the full Interix SDK and the popular and widely supported GNU SDK and compilers in SFUv3, enterprises can re-target their existing UNIX applications to run natively under Windows.


Interix uses a single rooted filesystem, giving UNIX applications and scripts the environment they expect, with files and directory structures that are familiar and require little or no change to source code to compile and run successfully.


Summary


Microsoft Services for UNIX provides a full range of cross-platform services geared toward integrating Windows and UNIX environments. With the addition of the Interix subsystem technology, SFU 3.0 now provides platform interoperability and application migration components in one fully integrated and supported product from Microsoft. SFU 3.0 provides the tools to give you better business value while implementing better IT management across the enterprise. It provides robust cross platform filesystem support, central user administration, and, with the Interix subsystem technology, a POSIX environment that runs on top of the Windows kernel, enabling UNIX applications and scripts to run natively on the Windows platform side by side with Windows applications.


For More Information


For more information on individual components of Services for UNIX, refer to https://www.microsoft.com/windows/sfu.


For the latest information on Windows 2000 Server, check out these Web sites: