Microsoft Enterprise Platforms Support: Windows Server Core Team
Implementing highly available file servers in Windows Server 2008 is very different from how it was done in previous versions of Microsoft's clustering technology. One of the new pieces of functionality implemented in highly available file servers is 'scoping' of shared folders. What this means is when a shared folder is created in a Windows Server 2008 Failover Cluster, it is not only associated with two other resources in the same resource grouping - a Client Access Point (CAP) and a File Server Resource, but it will be accessible only by way of the Network Name resource which is one of two components of a Client Access Point (CAP) (the other being an IP Address). Now, one may say, "That has been the way we have always accessed file shares in the past". This is true, but things have changed a little and that is what we will be discussing here.
I will start by reviewing how things work in Windows 2003 Cluster Server and prior (termed legacy clusters). I configured a 2-Node Windows Server 2003 Server Cluster to illustrate. I created two separate resource groups containing all the required resources to support a file share (Physical Disk, IP Address, and Network Name resources). These resources were configured as described in KB224967 - How to create file shares on a cluster.
Using the Microsoft Server Message Block (SMB) protocol which uses a lower level protocol called NetBIOS over TCP/IP (NBT), we can construct a Uniform Naming convention (UNC) path to access the highly available file shares in the cluster (e. g. \\<NetBIOS_Name>\<share_name> ). In legacy clusters, there was no 'scoping' of file shares. The nature of the interaction with the local Server service was such that whatever shares were configured on the Custer node hosting the highly available resource group containing the file share being accessed (exclusive of admin shares), would be displayed if a connection was made to the NetBIOS (or Fully qualified Domain Name (FQDN)) name or IP address. The following example illustrates this point. A highly available file share resource group (TESTFS) is Online on a Cluster node (W2K3-CL1). The Cluster node has a locally shared folder (temp) configured as well which is not part of the cluster. When making a connection to either the local Cluster node name or the Network Name associated with the highly available file share, all shares configured on the Cluster node are displayed.
If I move the second highly available file share resource group (TESTFS2) from the second cluster node over to the node hosting the first group, I see the following display.
You can see that all SMB shares that now reside on the cluster node (exclusive of the admin shares) are displayed to the client making the connection. They can also be seen in the Computer Management interface -
The same information is displayed if a user connects using an IP address as opposed to a NetBIOS, or FQDN, name as seen here -
In Windows Server 2008 Failover Clusters, the interaction between the Cluster Service and the Server Service has changed. In Windows Server 2008 Failover Clusters, shared folders are now associated with a File Server resource and are 'scoped' to the Network Name resource which is part of a Client Access Point (CAP). To illustrate, I will step through the process of creating a highly available shared folder in a Windows Server 2008 Failover cluster (more detailed information on this process can be accessed using the content provided at the end of this blog).
In the Failover Cluster management snap-in, I create a highly available File Server using the built-in wizard-based process. When complete, a grouping of resources which consist basically of a CAP and a piece of storage that will be used to host the shared folder(s) is created. Next, in the Actions menu, select 'Add a shared folder.'
This initializes another wizard-based process that is part of the Share and Storage Manager functionality that is included as part of the Windows Server 2008 operating system. The first step is to select the location for the shared folder. By default, the storage located in the resource group is selected. In this case - Disk F.
Select the Browse button and look for a pre-created folder to use (or I could create a new folder if desired) for the share.
In this case I selected the Accounting folder.
Modify the NTFS permissions as needed.
Next, select either SMB or NFS share.
Note: Just as an FYI, if this were an NFS share, things would be quite different because we would be using an NFS Server to provide this share to NFS clients, but that is a topic for another day.
In the next step, choose to make additional configuration settings for the SMB share as needed.
For example, you could limit the number of connections allowed to the share, or you could enable Access-Based Enumeration (ABE) or setup client-side caching.
Next, modify the share permissions as needed.
Publish to a DFS Namespace, if required.
Review the information summary and Create the shared folder.
Hopefully, the result is as shown here -
In the end, the Failover Cluster management snap-in shows the shared folder and the new File Server resource created to support it.
Using the same process we used with the Windows 2003 Server Cluster, we can access the shares using a UNC path. However, you will notice that the displayed information is quite different. This clearly demonstrates the concept of 'scoping' where file shares are associated with specific access points. The shares associated with the cluster node are only displayed when connecting to the name of the cluster node. The share(s) associated with the cluster CAP are only displayed when connecting to the Network Name which is part of that CAP.
Next, we try using the IP address. Here we can see that 'scoping' of file shares does not apply when accessing them using an IP address as part of a UNC path. Using the IP Address (220.127.116.11) which is part of the CAP, the share that is returned is quite different. Even though I used the IP address which is part of the Cluster CAP, the information displayed corresponds to the local share of the Cluster node that is hosting that IP address and not the share that is supported by the File Server resource that is part of the highly available File Server group.
Another method that is sometimes used to access a file share is a Canonical Name Record (CNAME) alias in DNS that points to the Network Name registration for the CAP in DNS. This will not work in Windows Server 2008 Failover Clusters. As an example, I configured a CNAME record in DNS called 'cfileserver'. When I ping that name, I get the IP Address associated with the cluster network name resource. When I try connecting to it via a UNC path, I once again only see the local shares for the cluster node hosting that IP Address resource.
In summary, file share 'scoping' in Windows Server 2008 Failover Clusters changes the way the Cluster Service interoperates with the Server Service on a Custer node. Because of this new functionality, end users must rethink file share access when those shares are hosted in a Failover Cluster. Accessing file shares in a Windows Server 2008 Failover Cluster using SMB must be by way of the Network Name resource which is part of a cluster Client Access Point (CAP). Methods that previously used IP addresses or DNS CNAME records will not work.
For additional information on Microsoft clustering Technologies:
Windows 2008 - http://technet.microsoft.com/en-us/library/cc534986.aspx
Windows 2003 - http://www.microsoft.com/windowsserver2003/enterprise/clustering.mspx
Microsoft Clustering Team Blog - http://blogs.msdn.com/clustering/
Thanks for your attention and I hope this information has been helpful.
Chuck Timon, Jr. Senior Support Escalation Engineer Microsoft Enterprise Platforms Support
I agree with Ravikaneth P; this is a real issue to those with worldwide operations where acquisitions create multi-vendor, multi-domain support issues and the IP address is your lowest common denominator. This is a much larger issue than Redmond realizes.
Has anyone gotten this to work with CNAMEs in different domains?
I have 2 file server clusters (2008) that are in 2 different geographical sites.
We have a DNS CNAME that is a generic name like ***opsshare.corporate-wide-domain.com***.
In each cluster, folders are shared like opsshare.westcoast.com and opsshare.eastcoast.com and are accessible by those names. We want to redirect users trying to access the "site-agnostic" name by changing the cname entry appropriately.
So for example, if we are doing maintenance on the westcoast, we would change the ***opsshare.corporate-wide-domain.com*** cname to point to ---> opsshare.eastcoast.com.
I have not yet defined the additional Client Access Points, but should be doing so tonight. Any replies ASAP as to the feasibility are greatly appreciated. I am crossing my fingers that it will work.
Creating the CAP for my file shares raises a problem on SQL Server so I cannot predict what name SQL Server will respond to (the first CAP that comes online) while it should respond on both CAP's. How can we configure this?
Thanks in advance
I read that the argument for removing accessing to the IP addresses is that in Windows 2003, you could access the share via the node's IP address, then when you fail over the cluster, the share is suddenly gone. This apparently generated a lot of support calls.
At the same time, I will make the point that the cluster's NetBIOS name must be tied to an IP address. Therefore, you should be able to access that share via that name or IP address.
I have no problem removing access to a share by the node's IP address. And yes, there may be idiots out there that don't know the difference between those two ip addresses. But why, oh why, would you remove access to the share via the clustered IP address??
As an MCSA/MCSE/MCDBA that has been working with clusters since wolfpack clustering in Windows NT 4.0, I feel that this has taken cluster shares a step backwards.
This has got to be one of the poorest decisions MS has ever made from someone without much real world experience... Fixing a problem that arose because of misconfiguration that takes away functionality required by customers who actually know what they are doing. So idiotic, the law of unintended consequences in effect.
I've managed to implement the workaround, but really MS you should know better by now, surely?
Another reason, if one was needed, to move CIF Shares to the VNX.