I was looking at the referrals this blog gets and I noticed that a lot of times people look for information on Client for NFS in Services for UNIX, Windows Server 2003 R2 or in Windows Vista and come to this blog, but I don't really have much useful information on installation, configuration and performance on Client for NFS. Now, that will not be the case.

I have received requests to put together something about Client for NFS since there doesn't seem to be a detailed single document which talks about it. There are KB articles which cover installation and configuration of Client for NFS. There are also some of them about issues and registry settings to help optimize the settings for CNFS.

Since it has also been a long time I have spent time on this blog, I guess it's high time I talk about Client for NFS and add some value to my blog.

Client for NFS is a very important offering from Microsoft for small and big enterprises to integrate their Windows systems with existing UNIX based environment. It now comes with RFC2307 support as well. It's one of the most simple component among Services for UNIX components. Client for NFS doesn't really ask for any configuration/restarts in most of the installations and offers true out-of-the-box NFS connectivity. You can see in the following screen shot how Client for NFS can be added/removed if Services for UNIX software is already installed -

In Windows Server 2003 R2, you can find CNFS listed in "Microsoft Services for NFS" under "Other File and Print Services" -

And, on a Windows Vista Enterprise/Ultimate systems, here's how you can add it -

Once you have installed Client for NFS, you are ready to start connecting to UNIX NFS shares where anonymous access is allowed. If your environment doesn't have any such shares to test connectivity, you now need to configure this system to fetch UNIX identity information from an existing User Name Mapping server or configure one if it is not already running.

See these posts to learn more about User Name Mapping, especially Configuring User Name Mapping, Configuring User Name Mapping - Part 1, Configuring User Name Mapping - Part 2 (Simple Mapping) and Configuring User Name Mapping - Part 3 (Advanced Mapping).

With Windows Server 2003 R2 and Windows Vista, you can configure Client for NFS to directly fetch this information from AD if it's already there since they offer RFC2307 support. In fact, you can use any RFC2307 compliant directory service.

Configuration for Client for NFS is over with this and you can start using it. To connect to NFS shares, you can use the same built-in mechanisms as you would with a normal Windows share. In fact, you also get to use the familiar mount command to use.

Run the nfsadmin client command to see what options Client for NFS is configured to use. It might show something like this and is self-explanatory -

The File Setting in the above screen shot is the UMASK value Client for NFS will use when you create a new file or a folder on an NFS mount.

You can use NET command, the mount command which comes with it or the "Map Network Drive..." to map a drive to remote NFS shares. You can also browse the network and look for system which export NFS shares using "Network Neighborhood" or "My Network Places" since Client for NFS adds "NFS Network" under "Entire Network" for people who find it easier to search for machines they would like to connect to.

The mount command is useful because it lets you override the default parameter which applies to the NFS connections from this computer. The help for mount command can be displayed by running it with /? command line switch -

It uses a similar syntax like the NET USE command but it's not completely identical. For example, following is what you can use to map z: drive a remote NFS export -

mount \\servername\sharename z:

On the performance side, Client for NFS is tuned with parameters which suit most of the environments, but still there are things which can be tweaked to see if it helps you the way you want it -

1. Read and Write buffers - This can tuned from the MMC snap-in or per mount using the mount command. If you do it using the mount command, the syntax will look like -
   mount -o rsize=16,wsize=16 \\servername\sharename drive
   The default is 32 KB and works perfectly in most of the scenarios.
   
   
2. Case-sensitive mounts - Since Windows is not case-sensitive, enabling case-sensitive option while mounting the NFS shares can reduces the time taken to look up a file on the server. When this is option is not turned on (which is the default behavior), Client for NFS can perform multiple lookups to locate a single file and that will show up as a performance problem
   This can only be done using the mount command and the syntax to do this is -
   mount -o casesensitive \\servername\sharename drive:
   
   
3. 8.3 name cache - As with Windows, Client for NFS also generates a 8.3 format name for the files on the NFS shares being accessed using Client for NFS. This adds up to the processing overhead. Turning off this option is recommended for performance gain. This is done with a registry change and this KB article explains the steps.
   8.3 name generation in Windows Server 2003 R2 and later releases are permanently turned off for the same reason.
   
   
4. NFS Caching - NFS v3 uses caching to improve performance but this can be problematic in certain scenarios. Create "RemoteWriteCache" and "FileAttributeCache" DWORD values under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Client for NFS\CurrentVersion\Users\Default\Cache and set these to 0 to disable caching.
   
   
5. Folder Content Caching - Client for NFS also caches the folder contents for 30 seconds to avoid performing lookups to the NFS servers. This can sometimes result in delayed folder content refresh. Follow the steps in this knowledgebase article to disable it.
   Set this registry setting to a value between 5-25.

Something worth taking a note - although the settings related to different aspects of caching may improves things on the client side, they can have performance percussions on the server side because when caching is not at work, the client may place more calls to the server and depending on the server and network conditions, it may cause the server to sweat more than it would normally. It's completely up to you to decide who would you like to work more for you - NFS client or the server.

Configuring User Name Mapping - Part 3 (Advanced Mapping)

Simply said - when you map users and groups manually with their UNIX counterparts, it's called Advanced Mapping.

From the last post on User Name Mapping, you may be aware that Simple Mapping automatically creates maps for all users and group who have the same names in your Windows and UNIX environment. It is possible that you aren't lucky enough to have the same names for users and groups in both the environments. Sometimes, you would want better control on this aspect and may not want to map all the users and groups automatically.

Advanced mappings can be used in such cases. Easy to configure - turn off Simple Maps in User Name Mapping Configuration and map them manually. You can read this page to see how it can be done in a Windows Server 2003 R2 environment.

In Services for UNIX 3.x environments, you can do by using the Services for UNIX Administration console. Select User Name Mapping in the left pane, define the UNIX data source and click on Apply -

To proceed further, click on Mappings in the right pane. You can now click on Show User Mappings or Show Group Mappings depending on what you want to do -

Now, you can display the users/groups in both Windows and UNIX side. Select the objects in both lists and click on Add. You're done.

Configuring User Name Mapping - Part 2 (Simple Mapping)

Continuing the discussion from Configuring User Name Mapping - Part 1 -  I will explain how to get Simple Mappings done in this post.

To rephrase, User Name Mapping (UNM) bridges the gap between the different user identification used in Windows and UNIX worlds. It's SID which identifies an object in Windows and Active Directory environment but it's UID and GID when it's a UNIX system in question. UNM is also a core authentication component in SFU World. When we are using it in conjunction with Server for NFS, UNM authenticates the incoming NFS access requests. With Client for NFS, it determines the effective UID and GID to be sent with the NFS requests to UNIX NFS servers.

UNM also provides a single point identity mapping database for all the machines running Server for NFS, Client for NFS and Interix/SUA components. For people looking for availability and clustering capabilities - you can configure UNM Server Pools and you can also run UNM on cluster nodes to achieve load balancing.

More on it later, back to Simple Mapping...

To match the Windows and UNIX identities, UNM uses Windows SAM or Active Directory to identify Windows users and UNIX files (/etc/passwd and /etc/group) or NIS domains as sources for identifying user and group information from UNIX perspective. This information is then mapped using Advanced and Simple Maps. Advanced maps are the ones that you create manually using the Administration Console while the Simple Maps are created automatically between the users and groups which have same names in Windows and UNIX databases.

It doesn't take much when creating Simple Maps apart from configuring basic things (I am assuming that you have installed the User Name Mapping service already and it's started).

First, you need to copy over the /etc/passwd and /etc/group files from your UNIX systems. Filter/Merge them so that they don't have any system account and duplicate UID/GID allocations. Now you can run this command -

mapadmin adddomainmap -d NTDomain -f Passwd/GroupDirectory

This command enables the Simple Mapping between the users and groups in Windows domain which is specified in place of NTDomain and the UNIX passwd/group files which have been stored under the directory specified in place of Passwd/GroupDirectory.

Now, you can run the following command to list all the maps -

mapadmin list -all

This lists all the maps which have been created. From my lab system -

The first command we ran is equivalent of making the following changes using the GUI -

1. Defining the UNIX files as the data source -
   
   
   
2. Enabling Simple Maps -
   
   
   
3. Displaying the Simple Maps -
   
   

It also takes care of enabling and creating Simple Maps for groups.

This KB article talks about installation and more command line options. I will soon post information in the form of Part 3 on UNM and talk about Advanced Mappings.

SFU hot fixes in email

Like any other Microsoft hot fix, you can also receive SFU hot fixes in your inbox - http://go.microsoft.com/?linkid=6294451

All you need is the KB article number which describes the fix you need. While we are talking about it, the following is also important to note -

"Hotfix Information

A Hotfix is a single package that includes one or more files that is used to address a very specific customer problem with a product. A supported Hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in the previous mentioned article. Only apply it to systems that are experiencing this specific problem. This Hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next service pack that contains this Hotfix."

Why am I talking about it here?
At first, it doesn't sound like has anything to do with SFU or UNIX Interoperability components shipped with Windows. But, then users who use these components know that hot fixes get them out of many problems. I am sure a lot of them would prefer getting the hot fix using this form instead opening a case.

Before you rush to request the latest and greatest fixes for SFU or R2 components - be informed that there are a few of them which have very specific prerequisites and if they are not fulfilled, you may run in to other issues. Read below to know about them -

KB913030 - Applies only to Services for UNIX 3.5
You can install this hot fix on any system that's running Interix Subsystem, Server for NIS or Password Synchronization. It doesn't create any problems but is mentioned here since it contains some stability and reliability update for Interix subsystem and some utilities. You should install this fix before you install any other Interix subsystem hot fix which is newer than this one.

KB921599 - Applies only to Services for UNIX 3.5
Many people get confused with the information in the Kb article. This hot fix again applies only to Services for UNIX 3.5 Server for NIS and Password Synchronization components. You need this hot fix only if you have added a Windows Server 2003 R2 DC (or upgraded one of the DCs to R2) AND have also installed Server for NIS Identity Management for UNIX (IdMU) component which comes with Windows Server 2003 R2.

Since IdMU components in R2 use RFC2307 schema classes and attributes, when you install these components in SFU 3.5 environment, the installation process upgrades all of the NIS objects (NIS Domains, maps, users, groups etc.) to use R2 schema enhancements. This breaks Services for UNIX 3.5 Server for NIS and Password Synchronization components since they use a different schema. Installing this hot fix updates the SFU 3.5 Server for NIS and Password Synchronizarion binaries to use RFC2307 classes and attributes and helps SFU 3.5 and R2 IdMU components to co-exist.

KB936529 - Applicable to Services for UNIX 3.5
The previous post talks about it. Windows Server 2003 Service Pack 2 installation breaks SFU 3.5 Interix Subsystem and Password Synchronization components and this hot fix helps you to undo that. This hot fix should not be installed on Windows Server 2003 R2 SP2 systems because if you are using Password Synchronization IdMU component, this hot fix replaces the pswdsync.dll file with the one meant for SFU 3.5. As a result, Password Synchronization stop working.

If you have any questions about any SFU hot fixes, please use the Email button on the blog side bar and shoot me a mail.

This post discussed about a problem with SFU 3.5 Interix and Password Synchronization components which break when you install Windows Server 2003 Service Pack 2. It also lists steps to fix it manually using files from another hot fix.

Microsoft has released a new hot fix - KB936529 - which fixes this issue and removes the burden of replacing the correct files manually.

If you've installed Windows Server 2003 Service Pack 2 and running in to this problem, please get this hot fix from PSS and install it. Make sure you don't install this hot fix on an R2 system because that may break correponding R2 components.

Configuring User Name Mapping - Part 1

On this page, I have put some information about how you can configure User Name Mapping. It doesn't have the complete step-by-step kind of touch to it since that article was all about getting Server for NFS to work.

To do justice to User Name Mapping, I am beginning a series of posts which discusses different UNIX environments and how they can be used with User Name Mapping to allow Windows systems to interoperate with UNIX environment and help migrating data from UNIX systems to Windows. This post, again, will not have step-by-step guide to configure User Name Mapping. That's something to follow in the next posts.

A typical UNIX environment may use local files (/etc/passwd and /etc/group) to manage authentication and manage access. In addition to local files, a UNIX system can also make use of NIS and LDAP to authenticate users centrally. Having centralized authentication make more sense if people need to access data on NFS servers – more so because all NFS cares about is UIDs and GIDs to allow access to data.

If an environment doesn't have centralized control on user and group accounts, it presents many challenges when it comes to security and managing unique UIDs and GIDs across all UNIX systems. NIS and LDAP reduce this overhead and provide easy to manage repository of user and group accounts. They also provide mechanisms such as netgroups to further strengthen security on NFS shares.

If your environment doesn't use NIS or LDAP for authentication and if your users and groups are scattered on different UNIX systems having their own user and group naming conventions and the UIDs and GIDs are duplicated between them – you really need to make a lot of changes before you can reap the benefits of UNIX interoperability components shipped with Windows and Services for UNIX 3.5 product.

To start with – you would need to ensure that your users and group have unique UIDs and GIDs and there are no conflicts across all systems.
You, of course, need to ensure that the user and group names are unique too.

Most difficult part is to plan and change UIDs and GIDs on UNIX systems. It’s not easy but you follow some simple steps to get it done sooner than later -

1. Allocate a range of UIDs and GIDs for each of your UNIX system. This range needs to be calculated based on the number of users and groups created on them.
2. Changing the UIDs and GIDs can be done quickly using the awk command. A simple awk script can scan the /etc/passwd and /etc/group files and change the UIDs and GIDs based on the range you allocated in first step.
3. Changing UIDs and GIDs will immediately result in access being revoked on the local and remote file system resources since it’s based on UIDs and GIDs and not names of the users and groups. However, you can run a find command with the right syntax to search for the files and directories owned by a user’s old UID and change it to the new UID. Same applies for groups.
   It becomes really easy if you can put together a script which searches and changes UIDs and GIDs on files and folders simultaneously when changing the UIDs and GIDs in /etc/passwd and /etc/group files.
4. Depending upon how it worked earlier, you might also have to look for accounts which belong to same users and groups on different UNIX systems and match their UIDs and GIDs so that they have same values on all of those systems.
5. Last and most important part is to now combine /etc/passwd and /etc/group files from all of the systems and form a single master database.
   You can very well use this database to implement a centralized authentication using NIS. Check back later on this blog to look for the steps to do that.

For now, you need to move this master database to the server running the User Name Mapping service and use it configure appropriate user and group mappings.

On the other hand, things become really easy if you have NIS or LDAP already running in your environment – User Name Mapping can directly connect to your NIS servers and fetch the details to create mappings for user and group accounts.

Server for NFS and Client for NFS which ship with Windows Server 2003 R2 and Windows Vista can also talk to your RFC2307-compliant LDAP store to fetch the UID and GID information directly. This will also be featured in Windows Server 2008. It also helps you eliminate User Name Mapping service from your setup and stop worrying about mapping users and groups manually when adding new accounts (if you are not making good use of Simple Mappings).

"Network Error 53", "The data area passed to a system call is too small" or "Unknown Error"

Client for NFS included with Windows Server 2003 R2 returns different errors when trying to access NFS shares on UNIX-based NFS servers. The exact error message may depend on your environment - you might get one or more from the ones mentioned above. And, at the same time, SFU 3.5 Client for NFS may work just fine.

Analyzing the network traffic may show MOUNT or NFS calls being "rejected for security reasons (5)".

The R2 Client for NFS uses high ports (>1024) to connect to NFS servers and that's known to cause the above errors. There are two ways to fix this -

• Change how your NFS servers export the NFS shares and make them allow connections from high ports, or,
• Add UseReservedPorts DWORD value under HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Default and set it to 1. Restart the Client for NFS service to allow the change to take effect.

Should you worry about security when you change your NFS server to allow connection from high ports? The answer is NO. An excerpt from RFC2623 says so -

Many NFS servers will require that the client send its NFS requests
from UDP or TCP source ports with values < 1024. The theory is that
binding to ports < 1024 is a privileged operation on the client, and
so the client is enforcing file access permissions on its end. The
theory breaks down because:

*    On many operating systems, there are no constraints on what port
     what user can bind to.
*    Just because the client host enforces the privilege on binding
     to ports < 1024 does not necessarily mean that a non-privileged
     user cannot gain access to the port binding privilege. For
     example with a single-user desk-top host running a UNIX
     operating system, the user may have knowledge of the root user
     password. And even if he does not have that knowledge, with
     physical access to the desk-top machine, root privileges are
     trivially acquired.

On the other hand, turning off low ports check on the NFS servers ensures compatibility with NFS clients irrespective of clients using high or low ports to access the NFS servers.

Note that above mentioned errors can be caused by number of other factors as well so if the solutions mentioned above don't work for you - focus your troubleshooting on other aspects.

How User Name Mapping works?

User Name Mapping is the core NFS authentication component in Services for UNIX, Windows Server 2003 R2 and Windows Vista. It bridges the gap presented by difference in user identification methods used by Windows and UNIX systems. It plays equally important role for Server for NFS and Client for NFS both.

When Server for NFS receives NFS access request from a UNIX client, all it gets is UID, GID and a set of auxiliary GIDs (which represents the secondary group memberships of that user in the UNIX world). Server for NFS then typically performs the following actions to authenticate the UNIX user who’s trying to access Windows NFS share –

• Server for NFS uses User Name Mapping to obtain the corresponding Windows user name or group name.
• After the user name is obtained, Server for NFS connects to a domain controller (for a domain account), or to local security authority for a local user –
• The domain controller authenticates the domain account using Kerberos extension called Service-For-User (S4U).
• Server for NFS Authentication is needed if the user account in question is a local account. Without Server for NFS authentication, the local security authority cannot authenticate the user and access to the UNIX client will be denied.

UNIX Interoperability and Windows Vista

There was SFU 3.5 Interoperability components. It got ported to Windows Server 2003 R2. And now we have similar interop components packaged with Windows Vista too. Windows Vista Ultimate and Enterprise editions include the Client for NFS and Subsystem for UNIX-based Applications (SUA). These Vista editions are targeted towards power users and large enterprise customers who are more likely to be benefitted from these components. However, none of the server components from SFU product line (namely Server for NFS, User Name Mapping, Server for NIS, Password Synchronization etc) are included with Vista.

You can install these components using the Programs and Features in Control Panel and then using the Turn Windows Features on or off -

Installing SUA adds only the subsystem and a program group - Subsystem for UNIX-based Applications. You need to download the utilities and SDK separately. The newly-added program group has a link to the Utilities and SDK download page.

New additions are SVR-5 Korn shell and over 150 utilities (which are found in the /svr-5 directory) and a Visual Studio Debugger add-in. This release also enables development and porting of custom UNIX applications using the Windows OCI (Oracle Call Interface) and Windows ODBC libraries which are collectively referred to as Mixed Mode.

Shanmugam, Program Manager with Microsoft maintains a blog about SFU, SUA and IDMU. You read more about these components in his blog.

Installing Client for NFS adds a Services for Network File System (NFS) MMC Snap-in to manage the Client for NFS configuration. The noticeable difference from R2 (apart from the GUI itself) is that you have two check-boxes to selectively enable User Name Mapping and/or Active Directory lookup for the UNIX identity mapping information -

Another difference is that now you can use the GUI to instruct the Client for NFS to use (or not to) reserved ports. This was otherwise done by tweaking a registry key (HKLM\software\Microsoft\Client for NFS\CurrentVersion\Default\UseReservedPorts) in previous releases -

Client for NFS in Windows Vista and Windows Server 2003 R2 supports RFC2307 attributes so it can also fetch UIDs/GIDs etc from any LDAP store which is RFC2307 compliant. I have tested this feature with Active Directory and this really is a cool addition to this component.

Windows Server 2003 SP2 breaks SFU

We have already seen too many people reporting this - Windows Server 2003 Service Pack 2 installation breaks two functionalities in Services for UNIX 3.5 installations - Interix subsystem and Password Synchronization.

The root cause lies with SP2 unintentionally replacing the SFU 3.5 Interix binaries and Password Synchronization binaries with corresponding R2 binaries. The specific files that get replaced after installing SP2 are psxss.exe, psxdll.dll and pswdsync.dll. First two are part of the SFU 3.5 Interix subsystem and the last belongs to SFU 3.5 Password Synchronization component.

Microsoft is aware of this problem is working on a patch to address this issue.

Until the patch is ready, the only way out is to manually put the right binaries back in place. To do that, you can either copy the above mentioned files from some other working box that has SFU 3.5 installed or get the right drivers from Microsoft support.

While you ask Microsoft PSS for the right drivers, I would recommend asking for the binaries that were included with the Services for UNIX Security and Reliability rollup package 913030 since it contains the necessary SFU 3.5 binaries for Interix subsystem and Password Synchronization components.

After you've obtained the above hot fix 913030, follow the steps below -

1. Download and extract the hot fix on your system.
2. Among other files, you will get SFU35-KB913030-X86-ENU.EXE which you need to install.
3. Double-click on this file and complete the installation. At the end, the installation will prompt you to reboot the server and this prompt features just the OK button. DO NOT click on it yet.
4. Open a Command Prompt window, change to the folder where you have the SFU35-KB913030-X86-ENU.EXE file and run this -
   
   SFU35-KB913030-X86-ENU.exe /x
   This command extracts the files from the hot fix instead of kicking the hot fix installation.
5. That'll again ask you a folder location where the files from this hot fix should be extracted. Type a path and click on OK.
6. After extraction is complete, open this new path in Windows Explorer. Open the sfu35eng folder and here you can see all the files this hot fix updates.
7. Depending upon which component is broken on your system, copy the psxss.exe, psxdll.dll and/or pswdsync.dll files after verifying the version number (it should be 8.0.1969.38) to your %systemroot%\system32 folder.
   
   Manual update of these drivers is needed since the wrongly replaced drivers have a version number corresponding to Windows Server 2003 R2 which is higher than that of the SFU 3.5 driver versions.
8. Come back to the hot fix window which is still waiting for you to click on the OK button. Click on OK and let your system reboot.
9. All should be fine now. If not, you probably need Microsoft PSS to help you with this.

There is likely to be a fix very soon. I would update this post whenever that happens.

Set up Server for NFS in Windows Server 2003 R2

In this post, I will talk about configuring Microsoft Services for Network File System, mainly Server for NFS and User Name Mapping, in Windows Server 2003 R2. You can follow the same steps for Services for UNIX (SFU) 3.5 except only a few of them because of some changes introduced with Windows Server 2003 R2.

As we move forward setting up things for us, I have tried to include information on likely problems that may be encountered and facts which help understand Server for NFS behavior which sometimes is confusing.

And to keep the post short, I have broken them into pages -

1. Introduction and installation of Services for NFS on R2
2. Sharing folders over NFS
3. Mouting NFS Share on NFS client
4. Who's 4294967294?
5. Configuring User Name Mapping
6. Using chown/chgrp from UNIX clients

You'll soon discover how Server for NFS makes life easier in heterogeneous environments.

GID on NTFS File System

Can you set group on a file or folder on NTFS file system? - No, ugh... Yes.

This question puzzled me for a long time but since it never really made it to my top priorities, I didn't look up for information on this. I thought of exploring this area more while I was researching something about NFS server.

I started with looking for the utilities (obviously, Windows-based ones) which can set this information for me. My search ended quickly with the chown.exe and chgrp.exe which you can install with Interix/SUA Base Utilities.

Using Process Monitor (replacement of Filemon and Regmon utilities) revealed that group information gets stored on the file system with an IRP_MJ_SET_SECURITY request -

The other interesting fact is this request originating from the POSIX subsystem (psxss.exe) which makes sense because chown.exe and chgrp.exe utilities are POSIX subsystem utilities.

This KB Article says -

In the Windows NT and Windows 2000 NTFS file system, each file also has an owner and a primary group. The primary group of a file is not used by the Win32 subsystem, but is present for programs that make use of the POSIX subsystem. When a file is created, the user who created the file becomes its owner and that user's primary group becomes the file's primary group. Access Control Entries (ACEs) are then added to the DACLs to assign permissions.

That makes it clear that none of other utilities I tried to use, could set this information because they were basically Win32 binaries and Win32 subsystem does not, in anyway, uses this information.

So the best practice would be to set correct primary groups for your users and then use Interix/SUA chown.exe and chgrp.exe utilities to manage them the way you want them to be seen by your UNIX clients.

Additional Note: The ls.exe and chmod.exe are other utilities which can help you do things the UNIX way.

Active Directory Lookup? Or, User Name Mapping? Or Both?

User Name Mapping in Windows Server 2003 R2 and Services for UNIX allows you map UNIX user and group accounts to their Windows counterparts (both local and domain accounts). This service is used by Server for NFS and Client for NFS (also by Windows Remote Shell Service in SFU 3.5).

UNIX uses UIDs and GIDs to identify user and group account while Windows uses SIDs. User Name Mapping provides a mechanism for Windows to correctly authenticate users and groups who access Windows NFS shares from UNIX clients or UNIX NFS shares from Windows clients.

This page talks more about why User Name Mapping is required. And, this link explains how NFS authentication works in Service for UNIX and Windows Server 2003 R2.

User Name Mapping is the only way Services for UNIX components can map UNIX UIDs/GIDs to Windows SIDs (and vice versa) but starting with Windows Server 2003 R2 and Windows Vista, Server for NFS and Client for NFS can also use Active Directory Lookup feature to query this information directly from AD. It adds another level of integration with Active Directory and Server for NIS for these components and can help you do away with User Name Mapping and therefore, reducing administrative overhead.

Note: User Name Mapping in R2 is the final release of this component. It’ll not be supported in future releases of Services for NFS.

If you have tried configuring Server or Client for NFS in R2, you might have noticed that you can use Active Directory Lookup and User Name Mapping at the same time.

Why? Don't they do the same thing? Why would I use them both at the same time?

Active Directory Lookup and User Name Mapping - both allow you to map Windows SIDs to UIDs and GIDs (and vice versa). However, there's big difference - User Name Mapping allows you to do advanced mappings where you can map users who have different login names on Windows and UNIX systems. It also allows you to map multiple Windows accounts to a single UNIX account to simplify NFS access.

If you have populated UNIX attributes for all of your user and group accounts in Active Directory, you should use Active Directory Lookup. But, if you still depend on the passwd and group files or UNIX-based NIS servers to determine UIDs and GIDs for user and group accounts, you are good to go with User Name Mapping.

Using both of them makes sense in a situation where you have a mix of Windows accounts with their UNIX attributes saved in AD and still have a need to map with UNIX sources for some of the accounts.

Using them both can also help you slowly move over to Active Directory for storing UNIX attributes.

Word of caution - if you think using both of them is necessary for your setup, take care that you don’t have accounts in AD with one set of UNIX attributes and then also map those same accounts to another set of UNIX attributes using User Name Mapping. That can lead to confusion while you determine effective permissions.

Important: A memory leak in the Lsass.exe process forces Lsass.exe process to use more memory than expected. This can result in domain controllers becoming unresponsive over time and may need a reboot. This problem can be fixed by installing hot fix 931307. Windows Server 2003 Service Pack 2 includes this fix so if you are already on Service Pack 2, you are safe.

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.

Welcome to the SFU Blog!

I am Ashish, working for the SFU support team at Microsoft. I’ll be talking here about interoperability between Windows and Unix worlds. Mostly using SFU software to achieve interoperability.

“Services for UNIX” (in short, SFU) is a collection of components that enable the Windows and UNIX systems talk to each other. Microsoft’s share growing in the server market every day leads to more and more companies having to cope up with running a heterogeneous environment of Windows and UNIX in their IT infrastructure.

As we all know, Windows and UNIX are two disparate worlds. Trying to establish a common communication protocol between these two is any system administrator’s nightmare. SFU is here to help and make their job easier.

For example, how would you copy log file from your UNIX web server to Windows machine? FTP (File Transfer Protocol) does the job, certainly not the friendliest way to do it often. If it was UNIX-to-UNIX one could use NFS (Network File System) protocol to achieve the same. If it was Windows-to-Windows, it would be CIFS/SMB. Would it not be nice if Windows could talk to UNIX over NFS or UNIX talking to Windows using CIFS/SMB?

Installing Services for UNIX on Windows enables it to understand NFS protocol. This means, Windows clients can now map to UNIX NFS shares or Windows can serve file shares over NFS protocol for UNIX clients to access them.

SFU is a software bundle and comes with the following major components –

• Client for NFS
• Server for NFS
• Gateway for NFS
• Server for NIS
• Password Synchronization
• Interix subsystem (and shell utilities)

I would be talking about each of these components in detail later. Keep watching this space for more posts on SFU and other interoperability information.

To start with, you can download the SFU software from this link and give it a try yourself -

http://www.microsoft.com/downloads/details.aspx?FamilyID=896c9688-601b-44f1-81a4-02878ff11778&DisplayLang=en

It’s a FREE download! :)