File Share 'Scoping' in Windows Server 2008 Failover Clusters

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 (1.53.0.187) 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 - https://technet.microsoft.com/en-us/library/cc534986.aspx

Windows 2003 - https://www.microsoft.com/windowsserver2003/enterprise/clustering.mspx

Microsoft Clustering Team Blog - https://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

Comments

• Anonymous
  January 01, 2003
  I am trying to add a share as described an getting an error message saying the resource is already exists eventhough I am creating a brand new folder. The same result if I try to share an existing folder. The Storage is a part of my file server resource, so the KB described the case when the storage is under "Available Storage" does not work :( ...
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  Cool. It's helpful!
• Anonymous
  January 01, 2003
  Hi Cluster Fans, The cluster team has been busy working on some great new features for Failover Clustering
• Anonymous
  January 01, 2003
  Nice Blog.
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  You may be wondering why, at this point in time, we are publishing a blog such as this. That is a good
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  PingBack from http://www.piratewebmaster.com/ask-the-core-team-file-share-scoping-in-windows-server-2008
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  Very cool thing.  I really like how it isolates the shares to the cluster.
• Anonymous
  January 01, 2003
  If a CNAME doesn't work, does the real FQDN work? I hope so, otherwise how would a multi-domain environment be able to access shares on clusters in domains other than their own?
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  July 16, 2010
  \contoso-FS1F$Acounting\1.53.0.187F$AcountingF$ = default share - WORKS!
• Anonymous
  August 07, 2010
  The comment has been removed
• Anonymous
  August 11, 2010
  The comment has been removed
• Anonymous
  October 22, 2010
  Hi,think also it's a good idea to seperate node and CAP.But what is the reason that the ip address of the CAP doesn't work? that's confusing and I see no advantage.RegardsCarsten
• Anonymous
  December 01, 2010
  I am sure the coding must have gone failure and things were not functional as expected on Release Date. At that time, coding team must have declared this as a 'feature' instead of resolving the issue itself. This is a major drawback; especially considering File-ServerDFS environments. I would have called it a 'great feature' only if this could be tunred offon at cluster level at our will, because accessing via IP becomes kind of must 'Accross' networks.
• Anonymous
  December 01, 2010
  I think it s serious disadvantage of Failover clustering fileserver mainly accessed by the clients outside the network who depended on IP Address.
• Anonymous
  April 20, 2011
  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.
• Anonymous
  October 19, 2011
  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 advanceAxel
• Anonymous
  February 11, 2013
  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.
• Anonymous
  May 01, 2013
  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.
• Anonymous
  September 11, 2013
  all the images in this article are not accessible!
• Anonymous
  January 21, 2014
  About 90% of our MFPs work fine, but we have several from different manufactures that will no longer work since we upgraded to a 2008 R2 cluster. The only way we can get them to work is using a unc of \clustervipd$ or the administrative shares. We cannot get them to work with \clusternamesharename, or \clustervipsharename. The huge problem with this is that we do not want to give an administrative account to our MFPs, and I cannot figure out a way to give them a local share that they can access without an admin account.