NFS has been a native part of Windows since the Windows 2003 R2 release, some 18 months ago now. The version of NFS in Windows 2003 R2 is a descendant of the Services For Unix package that has been available for a number of years.

I've designed a fairly complex implementation of NFS on a Windows cluster; this cluster also hosts ordinary file/print services, SQL Server and Exchange. Part of designing a cluster like this is designing the filesystems that underlie the cluster capability. Since we obviously want to separate SQL Server logs and databases, Exchange logs and databases, the Quorum, DTC, network services and file stores, we have a number of different cluster groups and therefore, drive letters.

In this design, there are so many different drives required that we have to use Windows mount points to reduce the number of drive letters. SQL Server is S: drive, but there's also data, log and backup volumes mounted as S:\Data1, S:\Log1 etc.

Exchange is done the same way (Exchange is about 8 volumes), with X:\SG1\Logs, X:\SG1\Data1, X:\SG1\Data2 etc.

So it was a no brainer to make all the cluster groups work the same way. 9 cluster groups (3 x File, Exchange, SQL, Net Services, Print, DTC and Quorum) taking only 9 drive letters for 33 different volumes.

And everything works just fine ... except NFS.

NFS acts weird. If I create the cluster NFS resource to "share the root directory" I can see the contents of the root directory, but my mounted data volume is inaccessible. If I create the cluster NFS resource to "share subdirectories", I can't even mount the NFS share.

Turns out that Windows NFS will not work with mount points at all (and yes, it cost a support call to find that this limitation has been extensively documented within Microsoft). In fact, one of the unspoken and unwritten requirements for NFS on Windows is that there be a drive letter associated with the NFS share.

Don't get caught like I did ...