Compartilhar via

Services for UNIX vs Windows Server 2003 R2 UNIX Interoperability

  • Artigo

Services for UNIX vs Windows Server 2003 R2 UNIX Interoperability

Services for UNIX is a software package which helps integrating UNIX systems in your Windows environment. With Services for UNIX 3.5 (which is the latest version of this product line) you get the following components -

    • NFS Connectivity
      • Server for NFS
      • Client for NFS and Gateway for NFS
    • Authentication and Password Management
      • Server for NIS and Password Synchronization
    • POSIX Development Environment
      • Interix Subsystem and utilities
    • Remote Connectivity
      • Windows and Interix based telnet servers and clients
      • Windows Remote Shell Service and Interix rshd
    • PCNFS Authentication
      • Server for PCNFS

Read more aboure these components here.

Services for UNIX 3.5 is the latest version of this product line and also the last one. Well, that doesn't mean these components will not be there and will not be improved.

Windows Server 2003 R2 already ships with improved version of some of the above components. These components are categorized as -

    • Microsoft Services for Network File System
    • Identity Management for UNIX (IdMU)
    • And, Subsystem for UNIX-based Applications

With Windows Server 2003 R2, you can run these components in 64-bit (AMD64) systems.

Client for NFS, Server for NFS, User Name Mapping and Server for NFS Authentication make Microsoft Services for Network File System. Identity Management for UNIX (IdMU) comprises of Server for NIS and Password Synchronization. Interix has been renamed Subsystem for UNIX-based Applications.

So as you can see Gateway for NFS, Windows Remore Shell Service, Server for PCNFS and Telnet server couldn't make their way to R2. Although, you can still configure and use SUA telnetd and rshd for remote shell access.

NFS components in R2 also have improved performance benefits. Some major changes which are introduced in these components in R2 are -

    • Active Directory schema now includes RFC2307 attributes with some minor deviations and Server for NIS makes use of them. RFC2307 defines the standard for using LDAP as a Network Information Service. Read more about it here
    • Server for NFS, Client for NFS can now directly look up and UIDs and GIDs from Active Directory
    • Subsystem for UNIX-based Applications (SUA) now also contains SVR-5 utilities, supports connectivity to Oracle and Microsoft SQL Server using OCI and ODBC standard. More over, SUA is also available wih 64-bit version of Windows Server 2003 R2
    • Password Synchronization adds support for Solaris 9 and Redhat Linux 9
    • The utilities and SDK for SUA are separately downloadable from here
    • UNIX-side SSOD components are now separately downlodable from this link

Complete list of what's new in R2 can be found here.

Comments

  • Anonymous
    May 07, 2007
    Can you give any specifics regarding improving NFS Clinet performance running on Windows Server 2003 R2?  Initial access of my UNIX NFS server from a win2003 server NFS client takes about 25 seconds - is there something that can be done to modify this behavior?

  • Anonymous
    May 08, 2007
    Hey Ed, The client in SFU/R2 doesn't have much (almost none) to customize. Are you using UNC paths to access them? Try mapping them first to a drive letter and then try opening using the UNC paths. If you don't map them first, every UNC access requires fresh mounting/portmapping/nfs calls which add to delays. Get in touch with me using the Email button on the sidebar. I would like to take a look at the network traces to see what other thing contributes to this delay.

  • Anonymous
    September 05, 2007
    I was recently asked to consolidate the company's UNIX and AD environment. We're using Windows 2003 R2 and all flavors of UNIX as the UNIX servers and desktops are not regulated. Any engineer is allowed to setup their own environments with UNIX. I can't seem to find any detail on what the min. requirements are for UNIX clients and servers. I can't find any config docs. I believe that R2 has a wizard for all of this. I would like user ID and password sync at the very least but cannot find any docs that tell me what the impact on the UNIX environment will be or what the min. requirements are or even how to configure this feature. Can you please point me to some docs that shed some light on this area? Thanks in advance. Ivor

  • Anonymous
    September 06, 2007
    Hi Ivor, If you are using NIS on the UNIX clients - almost every flavor and version of UNIX would be ok. Some information about installation and configuration is here - http://technet2.microsoft.com/windowsserver/en/library/ad4f834e-5886-4d21-b377-bbf3efbf4f8a1033.mspx

  • Anonymous
    September 25, 2007
    Currently my AD server is Windows 2003 R2 and the Client for NFS with AD look up works great for that machine.  Is there a Client for NFS with AD lookup for an XP client?  All the documentation I can find says that it is only available for 2003 R2.  It does not make sense to have a client utility only available on a server OS.  I am probably missing something though.  Any clarification would be most appreciated.

  • Anonymous
    September 25, 2007
    Hello Alan, AD Lookup feature is found on Windows versions which were released after Windows Server 2003. It uses RFC2307 schema. On Windows versions prior to that it is required that you use Client for NFS from SFU 3.5 which is not RFC2307 aware. It will not be incorporated in SFU 3.5 but if you can move to Vista (only Ultimate & Enterprise)- you can find this feature in that.

  • Anonymous
    September 27, 2007
    Thank you for your earlier response.   I have chosen to use the User Name Mapping service.  One issue I am having is that the local Administrators, in the OU that this DC is located, are unable to see a list of domains in the drop down menu when adding a user map.  This domain is segregated based on location, so local admins don't have full domain admin, but are delegated administrative privileges for the specific OU and DC.  I am assuming that these administrator are missing a delegated permission.  Could you tell what the relevant permission is?   Thanks in advance.

  • Anonymous
    September 27, 2007
    First of all, I am not sure if this possible. Can they add a map using the mapadmin command? I am looking for more information in the meantime.

  • Anonymous
    September 27, 2007
    The mapadmin command returns "Access is denied."  

  • Anonymous
    September 27, 2007
    Alan, please drop me a mail using the Email link above.

  • Anonymous
    December 05, 2007
    Hi Alan, I have a problem with SFU on SBS 2003: I use the nfs client to access a directory on an UNIX server. I use mount \unixdir1dir2 u: That works fine. But when I try to access a file via UNC-names from explorer,from the dos-shell or from an application like dir \unixdir1dir2 I get an error that the path does not exists. What´s wrong here ? Thanks, Harald

  • Anonymous
    December 05, 2007
    Harald, This is happening since Client for NFS cannot handle the multi path share names i.e. /dir1/dir2 or dir1dir2 as seen from Windows. In such cases, UNC access alone doesn't work. It works only if the share has been mounted on a drive letter already. You can either export the dir1 itself instead of exporting /dir1/dir2. Or, move dir2 out of dir1, on the root directory and share that. I understand this is not expected but the "/" (or "" as seen from Windows) character has special meaning to Windows and that causes this problem.

  • Anonymous
    December 05, 2007
    Hi Alan, thanks for your quick answer ! >>In such cases, UNC access alone doesn't work. It works only if the share has been mounted on a drive letter already. I did already mount the share on a drive letter, but UNC access still is not successful. OK, tomorrow I try to move my directorys out to the UNIX root and see what happens. Other problem is: if I access the mounted directory via drive letter from explorer or dos shell, everything works fine. But when I try to access the drive from my own piece of software via FindFirst / FindNext, I ´m getting a windows error 3 from FindFirst. Kind regards, Harald

  • Anonymous
    December 05, 2007
    > I did already mount the share on a drive letter, but UNC access still is not successful. In that case, we will have to take a look at the network packets to see why it isn't working. FindFirstFile API doesn't work well with SFU NFS Client. BTW, my name is Ashish ;)

  • Anonymous
    December 06, 2007
    >FindFirstFile API doesn't work well with SFU NFS Client. What else function I could use to program a file-scanservice on an NFS mounted directory ? Thanks, Harald

  • Anonymous
    December 07, 2007
    Hi Harald, Unfortunately, there's no other API for this purpose. Anyways, how is this software run - is it a service? Or, it running in a desktop session where you have mapped the drive already?

  • Anonymous
    December 08, 2007
    Hi, >Anyways, how is this software run - is it a service? Yes, I have programed it as a service application. But in my tests, the drives are already mapped. What I dont´t understand: I have a email client software (Tobit David) what does scan the same NFS mounted  directory for files and with this software everything works fine. So I´m confused. I can access the Dir and files from explorer and DOS-shell , so I am wondering which API function windows uses for that to get it working ? Kind regards, Harald

  • Anonymous
    December 10, 2007
    The comment has been removed

  • Anonymous
    April 23, 2008
    How is the security IDMU? Does it carry the same security weakness of NIS?

  • Anonymous
    April 23, 2008
    well, Yes.

  • Ashish

  • Anonymous
    January 02, 2009
    We are in a situation where our first R2 server (and the associated schema update) was installed some time ago, but until quite recently have only been configuring the "UNIX attributes" via the older machines with SFU installed.  When we started using IDMU, we soon noticed that the various UNIX machines weren't picking up the new users properly. In the interim we can continue to use the SFU3.5-era "UNIX Attributes" tab, but going forward we would prefer to start using the RFC2307-compliant attributes.  Are there any pre-existing tools or scripts you know of that can 'synchronise' the existing msSFU* attributes to their RFC2307-compliant counterparts (and vice-versa, ideally) ?

  • Anonymous
    January 02, 2009
    The comment has been removed