Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
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
PingBack from http://www.piratewebmaster.com/ask-the-core-team-file-share-scoping-in-windows-server-2008
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?
You may be wondering why, at this point in time, we are publishing a blog such as this. That is a good
Hi Cluster Fans, The cluster team has been busy working on some great new features for Failover Clustering
Very cool thing. I really like how it isolates the shares to the cluster.
GENIUS! Or at least you have really cleared up why I am having the problem I am. It appears that with several MFP devices that they present only the IP address to the server. Yes, they can use DNS to resolve a name if you put it in their set-ups, but they the device turns around and uses the IP address and not the name.
So, is there a work-around here, or am I up the creek without the paddle? I have moved all of my file servers to 2008 clustering and I need this scan to network on my current and new purchase MFP to work and I don’t want to use FTP inside the network again. Is this something the vendor (SHARP) needs to fix?
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 :( ...
Is there a way to revert to the old way where a DNS alias can be used to access the clustered file server client access point? This really throws a wrench in my migration plans. Surely this has caused many others pain as well. I understand how the other features of file share scoping are improvements (only seeing the clustered shares when connecting to the CAP), but why is taking away the ability to use a DNS alias an improvement?
Hi, is there a workaround to be able to use CNAME alias in DNS?
One side there is more security on cluster resources, the other less functionalities!!!!
F$ = default share - WORKS!
We need to migrate the existing shares, currently hosted on server1 but also using a CNAME as server2, to a high available server.
so at the moment we can access the files using:
we have a lot of unc path references in excel files to server \\server1\share\file and \\server2\share\file which cannot be changed. (more than 50k excel/access files)
I was planning to migrate to a Microsoft 2008 cluster file server.
after the migration to server3 (cluster resource) we still need to keep the possibility to access the files via the original unc paths.
so it needs to be accessible as follows:
with the new "scoping functionality of windows8" it will not be possible to use CNAME as mentioned above.
So, any suggestions on how to proceed? we need to have high availability.
The solution for this requirement is the introduction of an additional Client Access Point to the existing Windows 2008 file cluster group per required "CNAME". This can be achieved with the introduction of three additional cluster resource objects per supported "CNAME" to the existing cluster group. Put it in this way, let's assume that we have created a new Windows file cluster resource group "Server1". The file cluster group "Server1" contains a Client Access Point, a file File-Server resource object and a cluster share object. Windows clients can access the share via \\server1\share.
However the requirement is that data need to be migrated from server2 and server2 need to be decommissioned afterwards but the old UNC path \\server2\share need to be supported by the Windows file cluster group afterwards. CNAMES (disable strict name checking) is not supported anymore by Windows 2008 therefore the migrated data can only be accessed via \\server1\share but the following solution will solve the problem:
An additional Client Access Point resource object (server), an additional File Server resource object (FileServer-Server2) and an additional share (share) need to be added to the existing Windows 2008 file cluster group. These three objects need to be added per supported UNC path (CNAME). Cluster resource object dependencies need to be configured between the newly introduced Client Access Point, File-Server resource object and shared folder accordingly. DNS CNAME records will be obsolete, because the Client Access Points are introducing a DNS resource record which ensures backward compatibility for the old server name. Finally Windows clients and their business application's can access the migrated data without error message ("a duplicate name on the network exists") via the following UNC paths:
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.
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-Server\DFS environments. I would have called it a 'great feature' only if this could be tunred off\on at cluster level at our will, because accessing via IP becomes kind of must 'Accross' networks.
I think it s serious disadvantage of Failover clustering fileserver mainly accessed by the clients outside the network who depended on IP Address.