Using DFS for Centralized Access to Multiple NFS Servers

Lately, we have seen customers who are trying to utilize DFS to publish NFS shares from a single DFS server to centralize the access for the clients.

This has several benefits. It removes the problem of keeping a note of what NFS server is hosting a given NFS share and also the need to mount them. While you can still map a DFS link to a drive letter, I think it would be easier to browse to the DFS server using UNC and use the shares.

So, the DFS capability was added to SFU 3.0/3.5 via hot fix in KB837197 and this functionality exists in the NFS clients that ship with W2K3 R2 and later Windows releases.

The requirement to be able to create a DFS Link on a DFS server and to be able to access from a DFS client is that these machines should have the NFS client installed. Another requirement is about the identity mapping - all such systems should be using the same information store to match the Windows and UNIX identities.

With these things in place, you can go ahead and create a DFS root. You can create a single DFS root for all UNIX-based NFS shares that you want to publish using DFS or you can create multiple DFS roots depending upon on your requirement and design.

Next step would be to add a DFS link that is UNC path to NFS share on NFS server. We recommend that you should avoid using multi-path NFS shares (like /usr/local or /export/home etc) here. If you must use multi-path share, you will have to first mount them on a drive letter on the DFS server to avoid any service disruptions.

Once the link has been added and verified, your clients are pretty much ready to access it. Just browse to your server-based or domain-based DFS namespace and start using them.

If you have symlinks on your NFS shares or if you are not sure about them - there're some registry settings that need to be created and modified so that symbolic links work as expected.

The following registry entries should be added on the DFS servers -

• MountSymlinkDfsMaps - This entry takes care of resolving the target of the symlink when they are accessed from a DFS link. This is a Multi-String (MULTI_SZ) type and the values in this entry should in the following format -
  /NFSShare:\\DFSServer\DFSRoot
  This registry entry should be created at HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Client for NFS\CurrentVersion\Users\Default\Defaults
  
• DisplayAllLinks - This is REG_DWORD type and unless this entry is set to 1, any remote or unresolved symbolic links will not be displayed on the DFS clients.
  This registry entry needs to be present at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Client for NFS\CurrentVersion\Default
  
• MountSymlinkTargetShare - This also is a REG_DWORD and this allows the MS NFS client to traverse the target of a symbolic link if the target is not on the same NFS share.
  This registry entry should be created at HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Client for NFS\CurrentVersion\Users\Default\Defaults

Of the above, only the MountSymlinkTargetShare registry entry needs to be present on the clients so they can access the symlinks that point the targets on a different NFS share. You can read more about the above registry entries in KB837197.

Note: Symbolic links that point to an absolute path do not work over NFS and they must be recreated with relative target paths.

Getting AD Lookup to work without UNIX Attributes tab

The previous post talks about how to get the UNIX Attributes tab to work without installing IdMU components. In this post, I would like to talk about what attributes the NFS components expect to be populated in AD for user and group object before it can recognize them and use the information.

The UNIX Attributes tab populate a lot of other attributes because it is primarily designed to assist administrators to populate the attributes that are needed to build the NIS maps - NFS components look up just the uidNumber and gidNumber attributes for a user and the gidNumber attribute in case of a group. None of the other attributes are required to have any values.

If we leave the UNIX Attributes tab, we have two options to populate these attributes - programmatically or using ADSIEdit MMC snap-in.

 Using ADSIEdit snap-in can be feasible when you don't have a lot of objects to work with and it's not repeatative. Follow the steps below to populate these attributes using ADSIEdit -

• In the Run... dialog box, type ADSIEdit.msc and press Enter
• Right click on the ADSI Edit item in the snap-in and select Connect to...
• Under the Connection Point section, check the Select a well known Naming Context radio button and from the drop down box, select Default naming context and click on OK
• Expand Default naming context and then your domain container
• Locate the user or group object that you want to work with
• Right click on the object and select Properties
• Now, in the Attribute Editor tab, locate the uidNumber (not in case of a group) and gidNumber attributes and populate them with the desired values. Now click on OK on save the values.

You're done.

There are several programmatical methods available to do this. Following is a vbs script that I use for my tests -

On Error Resume Next

'Seting base DN here
Set objRootDSE = GetObject ("LDAP://rootDSE")
strBase = "<LDAP://" & objRootDSE.Get ("defaultNamingContext")&">;"

'Getting parameters and setting variables for later use
If WScript.Arguments.Count = 2 then
 objType = "group"
 samID = WScript.Arguments(0)
 gidNumber = WScript.Arguments(1)
ElseIf WScript.Arguments.Count = 3 Then
 objType = "user"
 samID = WScript.Arguments(0)
 uidNumber = WScript.Arguments(1)
 gidNumber = WScript.Arguments(2)
Else
 Wscript.Echo "Error: Insufficient Parameters"
 Wscript.Quit
End If

'Wscript.Echo objType & " " & samID & " " & uidNumber & " " & gidNumber
 
'Searching for the user in AD
Wscript.Echo "Searching for the object..."
strFilter="(&(objectClass=" & objType & ")(SamAccountName=" & samID & "));"
strAttrs="distinguishedname;"
strScope="SubTree"
Set objCon = CreateObject("ADODB.Connection")
objCon.Provider = "ADSDSOOBJECT"
objCon.Open "Active Directory Provider"
Set objRes = objCon.Execute(strBase & strFilter & strAttrs & strScope)

strDN = objRes.Fields("distinguishedname").Value
If Err.Number Then
    WScript.Echo "Error: No " & objType & " with name " & samID & " found."
 WScript.Quit
End If

set objDN = GetObject("LDAP://" & strDN)

'Writing information to the object
Wscript.Echo "Writing new values to AD..."
If objType = "user" Then
 objDN.Put "uidNumber", uidNumber
 objDN.Put "gidNumber", gidNumber
 objDN.SetInfo
ElseIf objType = "group" Then
 objDN.Put "gidNumber", gidNumber
 objDN.SetInfo
End If
 
'Fetch and display the newly updated UNIX values from AD
Wscript.Echo "Fetching new values from AD..."
Wscript.Echo "   samAccountName : " & objDN.Get("cn")
If objType = "user" Then Wscript.Echo "   uidNumber      : " & objDN.Get("uidNumber")
Wscript.Echo "   gidNumber      : " & objDN.Get("gidNumber")

'Clean up
Set objRes = nothing

Disclaimer: This sample is provided as is and is not meant for use on a production environment. It is provided only for illustrative purposes. The end user must test and modify the sample to suit their target environment. This code is provided here only as a convenience to you. No representations can be regarding the quality, safety, or suitability of any code or information found here.

Copy the code and save it in a file with .vbs extension. Following is the sytax that you can use to start using it -

To modify user objects - 

C:\>cscript <scriptname.vbs> samAccountName uidNumber gidNumber

To modify group objects -

Using UNIX Attributes tab without installing IdMU

Starting with the Windows Server 2003 R2 release, Microsoft has made it clear that the AD Lookup feature would be the preferred direction to go for identity mapping between Windows and *nix when it comes to NFS access - both server and client. AD Lookup uses the information populated in UidNumber and GidNumber attributes with user and group objects in AD to map the identity information between these platforms.

There's no tool that comes with NFS components in Windows we can use to populate this information. We have to either use scripts/ADSIEdit.msc to populate these attributes or use the infamous UNIX Attributes tab that comes with IdMU. This tab gets added to the ADUC snap-in when Server for NIS service is installed. This tab is easy to use and does the job using the familiar ADUC interface.

How to install UNIX Attributes tab? 

On the client workstations that use Windows XP, you can run the IDMU.EXE that ships with Windows Server 2003 R2 Media 2 under the ADMIN folder to install this tab and use the local ADUC snap-in to manage this information. On Windows Vista, you can install this extension by installing the Server for NIS Tools under Turn Windows features on or off > Remote Server Administration Tools > Role Administration Tools > Active Directory Domain Services Tools -

On my Windows 7 Ultimate RC, I don't see a way to install this tab. I hope it gets added by the time it's released.

Now, even when this extension is installed using one of the above methods, it doesn't work because the NISPROP.DLL file - the DLL behind the UNIX Attributes tab - expects the NIS domain information to be present in AD while that is added only when Server for NIS component is installed on at least one of the DCs in an AD domain. If that information is not present in AD, the fields in the tab remain disabled -

How to get it working? 

While that sounds like a big problem - it's not difficult to get it working without installing any of the IdMU components. All that is required is to execute the appropriate version of NISCNFG.EXE.

On the Windows Server 2003 R2 Media 2, you can find this file under the CMPNENTS\R2 folder. Just copy and execute this console app from a command prompt.

While on a Windows Server 2008 or Windows Server 2008 R2 system, you can find this file on the system itself by running the following command -

DIR NISCNFG.EXE /S/A

On my test boxes, it returned the following paths -

C:\Windows\winsxs\x86_microsoft-windows-server-for-nis_31bf3856ad364e35_6.0.6001.18000_none_48fb4ed1643883aa
And,
C:\Windows\winsxs\amd64_microsoft-windows-server-for-nis_31bf3856ad364e35_6.1.7100.0_none_160ce2b671abc629

- on a Windows Server 2008 and a Windows Server 2008 R2 RC systems respectively.

Please note that executing this binary doesn't produce any output or error message. The command will wait for some time while it is adding the necessary information in AD under System > RpcServices > YpServ30 container and then it comes back to the command prompt. You might also see another container called DefaultMigrationContainer30 on same level as System container.

NOTE: The user executing this binary needs to have administrative privileges in order to allow this tools to make the necessary changes.

This tool doesn't extend the AD schema in any way since all the necessary classes and attributes are already present in Windows Server 2003 R2 and later schema. It merely adds some containers and objects for the UNIX Attributes tab to function properly.

As you can see in the above screen shot, when we use this UNIX Attributes tab to populate the UNIX UID and GID information on user and group objects, it also adds some other information like NIS domain name, shell and home folder. Apart from the values present in UidNumber and GidNumber attributes, other information is redundant for AD Lookup and are used only when UNIX systems are authenticating against AD using NIS or LDAP/Kerberos.

The Technet content on Active Directoy Lookup and IdMU can be found on the following links -

• Specify How Server for NFS Obtains Windows User and Group Information in Windows Server 2008/2008 R2
• Configuring Services for Network File System to Use Active Directory Domain Lookup in Windows Server 2003 R2
• Integrated Identity Management in Active Directory Domain Services in Windows Server 2003 R2
• UNIX Interoperability in Windows Server 2008/2008 R2

AD Lookup with ADAM/ADLDS

With removal of UNM in Vista/W2K8, it became really problematic to map users in non-AD environments to use with Vista/LH NFS Servers and Clients. For client, a workaround was discovered which was essentially a registry tweak and did allow more than user to be able to access the resources. Now, a guide exists that details the steps to install and configure ADLDS (Active Directory Lightweight Directory Services) and to use it with NFS for UNIX identity information source. I have not worked on ADAM but I suppose the steps would apply to ADAM. Although, ADAM is not supported on Vista, the word is that it works so if it is absolutely necessary to use ADAM on Vista - it shouldn't be difficult to get it to work.

While one of my colleague got it to work, it seems that the point is easily missed that the NFS Server or Client system should have all the users accounts created locally as well as in ADLDS to get this solution to work. That's some extra work.

Using ADLDS also makes it easy to replicate one ADLDS instance with another instance running on another computer with little efforts. This can help avoiding a single point of failure and to provide a mechanism where the ADLDS administration can be centralized. ADLDS would also make case when NFS/ADLDS should be used in isolated environments. Isolation can also be achieved using proxy object in ADLDS.

I haven't worked on ADLDS extensively but planning it now. If you have something to add to this post, please do so by way of comments for the benefit of others.

BTW, the guide is accessible here.

Removal of technology: Services for Macintosh (SFM)

This seems a little strange and SFM is being talked about on this blog. Well, SFM is one of the technologies that we support along with UNIX Interoperability components like NFS, NIS and SUA.

Anyways, this is not news and people who have used SFM would have noticed by now that SFM is not part of Windows Server 2008 and later releases. This technology has been in the maintenance mode since long and didn't change much since the Windows NT 4.0 days. Nevertheless, it was a very useful component and even today we come across a lot of customers leveraging it for Mac intoperability.

Removal of SFM - in a way paves - way for NFS to be used from Mac clients since Mac OS X comes with a NFS client. it also means that if you are using SFM now and have plans to upgrade to Windows Server 2008 - it's time that you derive a backup plan.

What can you do now?
You can switch to 3rd party AFP servers available out there if you have Mac applications that still look for resource forks. To the best of my knowledge - even though SMB is capable of handling alternate data streams such as resource forks found on Mac systems - the SMB client that ships with Mac OS X doesn't handle it well and splits the forks as separate files when copying. The NFS protocol is not an option since it doesn't handle the altername data streams as well.

Windows 7 SUA SDK

A lot of people have been enquiring about the Windows 7 SUA SDK. There is a lot of anticipation since Windows 7 has already raised the bar on the other fronts and now people have high expectations for SUA SDK that would be released for Windows 7 SUA.

The picture is not as good - there are no new features being added to SUA with Windows 7. You would not see any new ported utilities or libraries. It will be just the bug fixes that have been reported on previous SDK and not much. If you had high hopes - it's time to give them up.

The expected release is shortly after the Windows 7 is RTM and not during the RC phase as earlier anticipated.

It's not news anymore that the Interop Systems' forum has not received funding for FY10 and it will be offline after June this year. That is a serious setback to SUA adoption since that forum has been the most active and greatest source of information for people who use SUA and find it useful for their purpose. Let's hope that the Microsoft discussions groups see the experts switching over so that people looking for help are not disappointed.

UPDATE: Rodney's comment below indicates there is ray of hope and the SUA community forums may shine again :)

Can I Set Up User Name Mapping in Windows Vista?

Unfortunately, no if you don't have a SFU 3.5 or W2K3 R2 machines on the network that is running User Name Mapping service. This has been a major disappointment with NFS deployments using Windows Vista.

However, there is a tiny little good news for you if you are looking for a way to enable Client for NFS in Windows Vista to be able to do something other than anonymous mounts. There is a registry tweak that you can modify to tweak Vista NFS client to use a pair of UNIX UID and GID while mounting and accessing NFS shares.

Here's how you can do it -

• Start Registry Editor
• Locate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
• Create two DWORD values namely AnonymousUid and AnonymousGid
• Set these values to the UID and GID you would like this NFS client to use
• Restart your Client for NFS service using the Microsoft Services for NFS MMC snap-in

Go ahead and mount shares on this machine and now the Client for NFS driver will send those values as the UID and GID to the NFS server. You can also use the mount command without any parameters to verify if these values are being used. You should see something like this -

C:\>mount

Local    Remote                                 Properties
-------------------------------------------------------------------------------
x:       \\NFSSERVER\NFSSHARE                   UID=10012, GID=10011
                                                rsize=8192, wsize=8192
                                                mount=soft, timeout=1.6
                                                retry=1, locking=yes
                                                fileaccess=644, lang=ANSI
                                                casesensitive=no

Try creating a file on the share and on the UNIX box, you can see that they bear the same UID and GID values as we have mentioned in the above DWORD values. If you use the ls command that comes with SUA, you will not see the correct ownership information because the client is still doing anonymous mounts and as you might have guessed already - we are just changing the UID and GID that the client is sending to the server. It is more like squashing from a client side instead of doing it from the server.

There's a security consideration as well - Every user on this machine will start sending these same NFS credentials so if you are going to have multiple users using this machine - think carefully about using this registry tweak. You also will not be able to use any secondary groups. I guess that can also be a consideration for many environments.

BTW, this works the same way on Windows 7 Beta box ;)

NFS and SUA in Windows 7

Finally, the Windows 7 beta is released to the public and we can now experience it ourselves. The PSS people in Microsoft are always excited to try their hands on the latest betas and Windows 7 is not an exception.

The first thing that we did, after exploring the new GUI experience, was to add Client for NFS and Subsystem for UNIX-based Applications (SUA) components. The addition is completely alike Windows Vista so no surprises here but it was much faster than Vista. The management is also the same with almost no visible difference.

But, things are really better underneath – there have been a lot of bug-fixes in both – Client for NFS and SUA – both.

On the NFS front, the User Name Mapping support (not the UNM component itself – like Vista) is there. Perhaps, the biggest change to notice is newly added support for KRB5/KRB5i security mode to come up to the mark with latest technologies available. More information is not available on this as of now and I will post new information as soon as it is available.

On SUA front, there are talks of a lot of improvement in terms of bug fixes. The SDK for Win7 is not released as of now and we expect it to be available only during Win7 RC phase.

Limitation with Active Directory Lookup feature in Microsoft Services for NFS

The Active Directory Lookup feature that was introduced with Windows Server 2003 R2. This feature greatly simplifies the UNIX identity information management but has its own set of limitation. I thoughy I'll document them here -

1. If you are using Client for NFS in conjunction with Active Directory lookup, the client will not send the secondary groups information of the user to the server. This is a limitation in the RFC2307 specifications because it doesn't define a place to store this information with the user object itself. The only way to get this information would be to query all the groups and maintain a cache of this information for future use. This is expensive on the performance side. I have not had exposure to 3rd party NFS servers offering RFC2307 support so not sure how it works with them. You are welcome if you can share some information on this aspect. Please use the comments form to do so.

2. The UIDs and GIDs fetched seems get lost after a while and unless you unmount and remount the share, it doesn't list the correct user and group names on the file. A user can get his information to be refreshed by doing something as simple as running cat command on the files he owns but it will still show the other files owned by nobody/nogroup which belong to other users. This is being worked on and I hope there's a fix for this soon.

UPDATE 06/24: The hot fix for the AD Lookup issue mentioned above has been released publicly. The associated knowledgebase article number is 969874 and this can be accessed here. Please note the fix is only required on Windows Server 2008 systems. In Windows Server 2003 R2, this problem can be worked around by changing the domain name to NETBIOS domain name in the NFS configuration.

Set up Services for Network File System in Windows Server 2008

The Microsoft Services for NFS continues to be the part of the operating system in Windows Server 2008 and seems we will see more improvements when Windows Server 2008 R2 is released.

In Windows Server 2008, a major change from the Windows Server 2003 R2 is the elimination of User Name Mapping service. Although, you can still use an existing UNM server to fetch the UNIX Identity information on a Windows Server 2008 system, it doesn't provide an option to install it on W2K8 system.

The other and newer option to use is Active Directory Lookup that debuted with Windows Server 2003 R2 and is yet to get accepted widely.

Using this feature, you can configure the Server for NFS and Client for NFS to directly fetch the UNIX identity information from Active Directory. This feature simplifies the identity management because now you just have to populate the information in just your Active Directory backend and it can be used to identify the UNIX users accessing the Windows NFS shares.

There are some glitches with this feature that I'll talk about in a post of its own. For now, let's move on to find out how we can enable the NFS services on a Windows Server 2008 box.

You can install Services for Network File System using the Add Roles Wizard from the Server Manager. To install Services for Network File System feature, the File Server role must be installed if it has already not been done. If the File Server role has not been added already, you can add this role and the Services for Network File System feature in a single go.

To get started, start Server Manager and click on the Add Roles link to start the Add Roles wizard. After you have followed the screens below, the necessary components and services will be added to your system -

From now on, you can manage most of the server and client configuration option from the Services for Network File System MMC snap-in -

To configure how it should fetch the UNIX identity information, right click on the top most node in the left pane in this MMC snap-in and click on Properties. You will be presented with the following dialog box and you can make your choices to use Active Directory Lookup by providing your Active Directory domain name and/or the server name of the system running User Name Mapping service -

Note: Active Directory Lookup feature is RFC2307 compliant and will work only when you have populated the RFC2307 attributes for the user and group objects in Active Directory. The attributes uidNumber and gidNumber contain the unique UID and GID information for users and groups.

The sharing of the folders over NFS remains more or less same as seen in the following screen shots -

UNIX side activities after you have installed the Services for Network File System and have exported some folders over NFS are same as documented here - http://blogs.msdn.com/sfu/pages/mounting-nfs-share-on-nfs-client.aspx

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.